Re: [IPsec] IKEv2 initial contact handling?
Tero Kivinen <kivinen@iki.fi> Thu, 11 April 2013 13:12 UTC
Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F7621F8AC2 for <ipsec@ietfa.amsl.com>; Thu, 11 Apr 2013 06:12:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17Jgp8u77QId for <ipsec@ietfa.amsl.com>; Thu, 11 Apr 2013 06:12:15 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6B06D21F85BF for <ipsec@ietf.org>; Thu, 11 Apr 2013 06:12:13 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r3BDBpS9015817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Apr 2013 16:11:51 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r3BDBlew007075; Thu, 11 Apr 2013 16:11:47 +0300 (EEST)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <20838.46739.562430.596310@fireball.kivinen.iki.fi>
Date: Thu, 11 Apr 2013 16:11:47 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Kanaga Kannappan <kanaga_k@yahoo.com>
In-Reply-To: <1365570965.81158.YahooMailNeo@web141003.mail.bf1.yahoo.com>
References: <1365526990.17344.YahooMailNeo@web141003.mail.bf1.yahoo.com> <alpine.LFD.2.10.1304091448550.3283@bofh.nohats.ca> <1365570965.81158.YahooMailNeo@web141003.mail.bf1.yahoo.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 23 min
X-Total-Time: 26 min
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, Paul Wouters <paul@cypherpunks.ca>
Subject: Re: [IPsec] IKEv2 initial contact handling?
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2013 13:12:16 -0000
Kanaga Kannappan writes: > Yes, we can retain the IPsec SAs on responder to avoid blackholing. > > But in IKEv2, IKE & IPsec SAs are tied together and, in this case we > would have to create an exception, where IPsec SA would live without > a parent IKE SA. No. First of all INITIAL_CONTACT is never sent rekeying so that is not a problem. It is only sent when the end does not have any IKE or IPsec SAs with the other end. Secondly, you are only supposed to delete IKE SAs you have with the other end, i.e. not the ones you are middle of negotiating with. Also as this notification is included in the IKE_AUTH, it can only happen if the IKE_AUTH payloads really cross each other on the wire. As it might be possible that the first packets did cross on the wire, but one of them got lost, and thats why it looks like the other peer is sending INITIAL_CONTACT notification even after the first IKE SA has already been created, you still need to take care of that situation. I.e. the generic case you need to take care of is: Host A Host B ------ ------ 1) IKE_SA_INIT request --> <-- IKE_SA_INIT request 2) IKE_SA_INIT reply --> <-- IKE_SA_INIT reply 3) IKE_AUTH request --> (the IKE_AUTH of host B got lost) 4) Host B receives IKE_AUTH request, sends reply 5) <-- IKE_AUTH reply 6) Host A gets IKE_AUTH reply, finishes IKE SA 7) <-- IKE_AUTH request retransmission 8) Host A gets IKE_AUTH request with INITIAL_CONCACT notification 9) Host A replies to it 10) IKE_AUTH reply --> 11) Host B gets IKE_AUTH reply and finishes 2nd IKE SA Now the problem would be in the step 8, where the Host A has already finished the IKE SA, and gets INITIAL_CONTACT notification from the other end. There are few ways to solve this, either it can check that as the IKE SA it has was not ready at the point when this IKE SA negotiation started, and detect that this is exchange collision. With this exchange collision, it might simply continue normally and not to delete the IKE SA it already has as this is exchange collision. After this it has two IKE SAs and that is not a problem. Other options the Host A could do is when it detects exchange collision is to remove one of the IKE SAs, but in that case it needs to send IKE SA delete to inform the other end that it has deleted it, as this is not the case of leftover IKE SAs, but it is the case of exchange collision. Other option is to simply not to delete "recently" created IKE SAs, and simply assume all of those are collisions. What it could do for those "recently" created IKE SA is to assume that they might be dead, and it could start dead peer detection for them, or it can simply wait for the normal dead peer detection to kick up when there is no traffic from the other end. The definition of recently could be something like last 30 seconds. Note, that it should not be considered a problem to have multiple IKE SAs between two peers. The INITIAL_CONTACT notification is not supposed to be preventing that, it is supposed to clear out old unused IKE SAs the other end might have. If both ends are configured to automatically initiate connections immediately when the there is on IKE SA (which can cause this setup), then it is best to configure SAs so that they do not send INITIAL_CONTACT notifications. If the IKE SA is kept alive all the time, then normal dead peer detection and other methods will take care of the old SAs. INITIAL_CONTACT was much more important in the IKEv1 world where there was no reliable deletes, or other ways of knowing whether the other end was alive or not. In IKEv2 there is less need for it, so leaving it out does not cause that much problems. -- kivinen@iki.fi
- [IPsec] IKEv2 initial contact handling? Kanaga Kannappan
- Re: [IPsec] IKEv2 initial contact handling? Paul Wouters
- Re: [IPsec] IKEv2 initial contact handling? Yoav Nir
- Re: [IPsec] IKEv2 initial contact handling? Kanaga Kannappan
- Re: [IPsec] IKEv2 initial contact handling? Tero Kivinen
- Re: [IPsec] IKEv2 initial contact handling? Paul Wouters
- Re: [IPsec] IKEv2 initial contact handling? Tero Kivinen
- Re: [IPsec] IKEv2 initial contact handling? Paul Wouters
- Re: [IPsec] IKEv2 initial contact handling? sandeep kampati