From owner-freebsd-net@FreeBSD.ORG Thu Nov 3 13:27:46 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 633B1106564A for ; Thu, 3 Nov 2011 13:27:46 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 165E48FC08 for ; Thu, 3 Nov 2011 13:27:45 +0000 (UTC) Received: from astro.zen.inc (astro.zen.inc [192.168.1.239]) by smtp.zeninc.net (smtpd) with ESMTP id 2832A2798BD for ; Thu, 3 Nov 2011 14:09:05 +0100 (CET) Received: by astro.zen.inc (Postfix, from userid 1000) id BC5F517055; Thu, 3 Nov 2011 14:09:04 +0100 (CET) Date: Thu, 3 Nov 2011 14:09:04 +0100 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20111103130904.GA50156@zeninc.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: All mail clients suck. This one just sucks less. Subject: Re: Doubt regarding key_do_allocsa_policy in ipsec path X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 13:27:46 -0000 On Thu, Nov 03, 2011 at 11:46:41AM +0530, Reji Thomas wrote: > Hi, Hi. > The key_do_allocsa_policy searches and deletes the non preferred sas if > there are multiple sas that match the search parameters . I see that if > there are multiple sas of same parameters established between end points, > this end up in deletion of all "outbound sa" but the preferred sa. Yes. > Since > the deletion occurs only on the outbound sa, this ends up in a scenario > where the corresponding inbound ipsec sas gets unpaired and not cleaned up > particularly when the ike daemon doesnt send a delete notification of sa to > the other peer. ( racoon2 ikev1 doesnt seem to do this). Yep, some peers may generate that situation. > In such a scenario, what should be the proper thing to do?. Nothing :-) To be more exact: just wait until the lifetime of the old SA expires..... > 1. Make sure that a delete notification is sent by the iked so that the > peers can cleanup the unpaired sa. You can make sure you sent a DELETE_SA, but you can't be sure peer received it and correctly handled it. And if you're takling about sending a DELETE_SA for your inbound SA..... yes, you could do that, but why ? And what will you do if your peer doesn't get/handle the DELETE_SA and continue using the old SA for it's outgoing packets ? > 2. Since ipsec sas are always paired, should we delete the unpaired sa in > the kernel at the same time? In the real world, almost all SAs are "paired" when you negociate them. But you can't just consider SAs will always be aired. For example, if you have "use_oldsa == 0" and your peer have "use_oldsa == 1" (or whatever else which will generate a similar result), you're right when you decide to delete your outbound SA, because you are sure that you won't use it again, but your peer will still use it's old outbound SA, which is your old inbount SA. The only situation I see where this may become a real issue is if you start negociating with no lifetime, but only lifebyte.... just forget that kind of situation, it will lead you to other issues ! Yvan.