IETF Logo Mail Archive

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

Daniel Migault <mglt.ietf@gmail.com> Tue, 11 March 2014 15:03 UTC

Return-Path: <mglt.ietf@gmail.com>
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 B15851A0479 for <ipsec@ietfa.amsl.com>; Tue, 11 Mar 2014 08:03:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 zZTZ0xb9Nyb8 for <ipsec@ietfa.amsl.com>; Tue, 11 Mar 2014 08:03:46 -0700 (PDT)
Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 877BB1A0755 for <ipsec@ietf.org>; Tue, 11 Mar 2014 08:03:46 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id m15so7897824wgh.27 for <ipsec@ietf.org>; Tue, 11 Mar 2014 08:03:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IyZt3W4zkYe2gX+sHC/DcqOQ5MBNVKJmj3KePV+/iOQ=; b=K5qHt16jIsIDjOeUnKP+58OHlzjhnWKfxdLb3DZOtuTetk6YBveFKd/hVkr2NgrwKy wNGxnVg1QiJ72eY+azgmWcBpPhsqC57qdlOuVC0EE2PVu4/Srbb3eipwbrKUkLtlYC4C XiIJnAHGKvMvU8a5c9BF/vkmu4g/sPcjzTeoRSPvI1HD/RjV3q0f8gOgQLIpyexNo3vy jdG6/Ud7Z9KO35vnYniob37SpTTaixJaeZprAJcL9H9hUXulkosBEP0xEY49eoQ1mAMV UD+ZCTSbTWE8oC54UEgtij19dbOi9wnFthwJOFruuGxRe4pLLDMsCn9fcSz53KYfIr7q 9CZA==
MIME-Version: 1.0
X-Received: by 10.180.13.33 with SMTP id e1mr3562338wic.38.1394550220400; Tue, 11 Mar 2014 08:03:40 -0700 (PDT)
Received: by 10.194.171.225 with HTTP; Tue, 11 Mar 2014 08:03:40 -0700 (PDT)
In-Reply-To: <C15270BA-74BC-449F-9CD1-B45960FFCA03@vpnc.org>
References: <21271.44610.414071.370642@fireball.kivinen.iki.fi> <C15270BA-74BC-449F-9CD1-B45960FFCA03@vpnc.org>
Date: Tue, 11 Mar 2014 16:03:40 +0100
Message-ID: <CADZyTk=Je5j+OVY9rXkZETgM7hQoCi6AyOJ9MXJ_wuYGo_LPFQ@mail.gmail.com>
From: Daniel Migault <mglt.ietf@gmail.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>, Tero Kivinen <kivinen@iki.fi>
Content-Type: text/plain; charset="ISO-8859-1"
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Ya77-BsC-TTRrgJWkFCf3SdIMAI
Cc: ipsec <ipsec@ietf.org>
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: Tue, 11 Mar 2014 15:03:48 -0000

Hi Paul and Tero,

Thanks for the comments we will clarify these points for the next
version, and explicitly describe the dependance between these context.
Thanks
Daniel

On Sat, Mar 8, 2014 at 11:47 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> 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
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec



-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

v2.23.0 | Report a Bug | By Email