Re: [IPsec] IKEv2 initial contact handling?
Paul Wouters <paul@cypherpunks.ca> Tue, 09 April 2013 19:00 UTC
Return-Path: <paul@cypherpunks.ca>
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 5A6A721F97A9 for <ipsec@ietfa.amsl.com>; Tue, 9 Apr 2013 12:00:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 T5JRLvCRVCLD for <ipsec@ietfa.amsl.com>; Tue, 9 Apr 2013 12:00:18 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 35B8C21F977A for <ipsec@ietf.org>; Tue, 9 Apr 2013 12:00:18 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3Zld9V65dxz712; Tue, 9 Apr 2013 15:00:14 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id MlbWtYL2VOar; Tue, 9 Apr 2013 15:00:14 -0400 (EDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Tue, 9 Apr 2013 15:00:14 -0400 (EDT)
Received: by bofh.nohats.ca (Postfix, from userid 500) id E4A9E80BD7; Tue, 9 Apr 2013 15:00:14 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DCA58805AC; Tue, 9 Apr 2013 15:00:14 -0400 (EDT)
Date: Tue, 09 Apr 2013 15:00:14 -0400
From: Paul Wouters <paul@cypherpunks.ca>
X-X-Sender: paul@bofh.nohats.ca
To: Kanaga Kannappan <kanaga_k@yahoo.com>
In-Reply-To: <1365526990.17344.YahooMailNeo@web141003.mail.bf1.yahoo.com>
Message-ID: <alpine.LFD.2.10.1304091448550.3283@bofh.nohats.ca>
References: <1365526990.17344.YahooMailNeo@web141003.mail.bf1.yahoo.com>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
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: Tue, 09 Apr 2013 19:00:19 -0000
On Tue, 9 Apr 2013, Kanaga Kannappan wrote: > How to handle "Initial Contact Notification" during simultaneous IKEv2 SA negotiation? > > For example: A pair of gateways are initiating IKEv2 negotiation almost at the same time resulting in 2 > sets of IKEv2 SAs. In IKE_AUTH, both the boxes are sending "Initial Contact" notification and IKE_AUTH > almost cross each other. On receiving the IC, if both try to delete the other IKE SAs on the box, we end > up having different sets of IKE & child SAs on the both sides. Initial contact is a bad feature all around. A responder should just leave the old IPsec SA there to expire when its lifetime is reached. Anything else causes issues. For example, with IKEv1 if you delete the IPsec SA when you receive the payload, and then send back an IKE packet to handle things like XAUTH authenticatin, there is a time when you have no valid IPsec SA installed during a rekey, and thus tunnel downtime. Especially if XAUTH requires a human punching in things from a token. The only reason we (libreswan) implemented sending the payload (for IKEv1) is that Cisco can refuse to replace an IPsec SA when it did not receive Initial Contact, despite this new IKE having perfectly authenticated without a problem. Libreswan fully ignores receiving an initial contact payload. When it determines the peer ids match an existing IKE SA, it will replace it, but again leave the IPsec SA to expire of old age, as we cannot be sure when the other end switches from the old to the new IPsec SA. This all seems a remnant from configurations where the IDs are not unique, commercially known as 'Group PSK' configurations, which were always a bad idea as any member could pretend to be gateway and learn all the remaining XAUTH credentials of all other users. You should leave in the old IPsec SA despite the initial contact payload. If your implementation allows you to keep track, you could delete the old IPsec SA once you see traffic on the new IPsec SA. Paul
- [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