Re: [IPsec] Some comments to draft-plmrs-ipsecme-ipsec-ikev2-context-definition-01

Paul Hoffman <paul.hoffman@vpnc.org> Sat, 08 March 2014 10:48 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C230E1A0258 for <ipsec@ietfa.amsl.com>; Sat, 8 Mar 2014 02:48:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level:
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63qpykRL3_1h for <ipsec@ietfa.amsl.com>; Sat, 8 Mar 2014 02:48:04 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B53791A027B for <ipsec@ietf.org>; Sat, 8 Mar 2014 02:48:04 -0800 (PST)
Received: from [10.207.200.59] ([31.55.55.105]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s28AlvfI053371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <ipsec@ietf.org>; Sat, 8 Mar 2014 03:47:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host [31.55.55.105] claimed to be [10.207.200.59]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <21271.44610.414071.370642@fireball.kivinen.iki.fi>
Date: Sat, 8 Mar 2014 10:47:56 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <C15270BA-74BC-449F-9CD1-B45960FFCA03@vpnc.org>
References: <21271.44610.414071.370642@fireball.kivinen.iki.fi>
To: ipsec <ipsec@ietf.org>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/gNYg5uaqUrufbqwtkFO7RqAqynA
Subject: Re: [IPsec] Some comments to draft-plmrs-ipsecme-ipsec-ikev2-context-definition-01
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 08 Mar 2014 10:48:06 -0000

On Mar 5, 2014, at 11:07 PM, Tero Kivinen <kivinen@iki.fi> wrote:

> In section 2 it says:
> 
>   Note that IKEv2 and IPsec session do not need to be on the same node
>   as IKEv2 and IPsec context are different.
> 
> This is not so easy. The RFC5996 says:
> 
> ----------------------------------------------------------------------
> 2.4.  State Synchronization and Connection Timeouts
> ...
> 	An implementation needs to stop sending over any SA if
>   some failure prevents it from receiving on all of the associated SAs.
>   If a system creates Child SAs that can fail independently from one
>   another without the associated IKE SA being able to send a delete
>   message, then the system MUST negotiate such Child SAs using separate
>   IKE SAs.
> ----------------------------------------------------------------------
> 
> I.e. if any of the IPsec SAs fail, then all of IPsec SAs created using
> same IKE SA, and the IKE SA must also fail. If IPsec SAs and IKE SA
> are on separate nodes, that do set up new kind of requirements for
> those nodes. I.e. if one node having IPsec SAs fails, the node having
> IKE SA needs to detect this, and send delete notification for each
> IPsec SA that were in that node. Also if the node having the IKE SA
> will fail, then all the IPsec SAs associated with that IKE SA, must
> stop sending, i.e. they needs to be destroyed.	          

Tero's comment nails the concern I had when reading the document. IKEv2 ties Child SAs to their parent SA, and using the context of one without the other seems dangerous.

--Paul Hoffman