Re: [IPsec] IKEv2 initial contact handling?

Yoav Nir <> Wed, 10 April 2013 05:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A88A121F8D2A for <>; Tue, 9 Apr 2013 22:11:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.701
X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[AWL=-8.701, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, URIBL_SBL=20]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0zwlgGgtx9cS for <>; Tue, 9 Apr 2013 22:11:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F071521F8C3C for <>; Tue, 9 Apr 2013 22:11:51 -0700 (PDT)
Received: from ([]) by (8.13.8/8.13.8) with ESMTP id r3A5BoiV008157; Wed, 10 Apr 2013 08:11:50 +0300
X-CheckPoint: {5164F46C-0-1B221DC2-1FFFF}
Received: from ([]) by ([]) with mapi id 14.02.0342.003; Wed, 10 Apr 2013 08:11:49 +0300
From: Yoav Nir <>
To: Kanaga Kannappan <>
Thread-Topic: [IPsec] IKEv2 initial contact handling?
Thread-Index: AQHONUQjOyZyB07NbE6zMjx8VDexcZjOtwCA
Date: Wed, 10 Apr 2013 05:11:49 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: multipart/alternative; boundary="_000_141C986B330F41D78FF57C70DE68BA0Bcheckpointcom_"
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [IPsec] IKEv2 initial contact handling?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Apr 2013 05:11:53 -0000

On Apr 9, 2013, at 8:03 PM, Kanaga Kannappan <<>> wrote:

Hi All,

How to handle "Initial Contact Notification" during simultaneous IKEv2 SA negotiation?

The simplest answer is not to handle it. It makes sense that peers will do a simultaneous negotiation for rekeying an IPsec SA. Most gateways do this proactively, but only in response to traffic. So if both are configured to expire SAs after 1 hour, but renegotiate after 55 minutes, then if there's a packet when the SA is 56 minutes old, it could trigger a simultaneous re-negotiation.

OTOH when initiating the first IKE SA, it's not likely to start from both sides at the same time. You could probably reproduce such a case in the lab. What you're supposed to do when presented with an Initial Contact, is delete all "other" IKE SAs.My code only erases established SAs (not things that are in the middle of the initial exchanges) so if they're simultaneous either both will be set up or only one based on the tie-breaker logic in RFC 5996.

But suppose your code is different. The worst case is that each side has deleted the IKE SA that it has initiated, and both gateways end up with one IKE SA each (different SAs). If your code has a recovery mechanism such as RFC 6290, that issue gets resolved quickly.

I don't think this edge case is something to worry about.