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

Daniel Palomares <daniel.palomares.ietf@gmail.com> Thu, 06 March 2014 18:24 UTC

Return-Path: <daniel.palomares.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 C2C241A01FB for <ipsec@ietfa.amsl.com>; Thu, 6 Mar 2014 10:24:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 twht7ZvFohn5 for <ipsec@ietfa.amsl.com>; Thu, 6 Mar 2014 10:23:59 -0800 (PST)
Received: from mail-ie0-x241.google.com (mail-ie0-x241.google.com [IPv6:2607:f8b0:4001:c03::241]) by ietfa.amsl.com (Postfix) with ESMTP id 5724D1A01BE for <ipsec@ietf.org>; Thu, 6 Mar 2014 10:23:57 -0800 (PST)
Received: by mail-ie0-f193.google.com with SMTP id rl12so2171383iec.4 for <ipsec@ietf.org>; Thu, 06 Mar 2014 10:23:53 -0800 (PST)
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=Gk9zhrbTdNwV5AO4zBBmYY+ZuBAVS43zXplyzw9fZLA=; b=P366dhbVRpDIxrX74BURc2VM0pIxWaw3n+m9AeD5hOeOt0ND/NdJV3YB9T9aPY7BXe wyQ9J/+vXccW7AWXt4UcXAFlgWYfVUAPluZmcw35SlDnuFv1TSXEioXMNmmvCHfvSc0I nefA8lKh4lA2AC5BREi7vdkWbtxU+3WaLLp1ie8BCFUC57M8CKwpV0WepqjQ1Jox8SJN oo83UVVAzr9xPsAw/fLFKKcgG5A3Syjj/2PODasNq8RGgfwySndbS2Bze3wi0vdWSBnt sIystCSO4LrAueerEW6zV+wNcElT8Me2M5pMP9KMXw749o1wDOyg7dlCIqVAyOqm52+I f8Ig==
MIME-Version: 1.0
X-Received: by 10.43.46.3 with SMTP id um3mr10993451icb.1.1394130233342; Thu, 06 Mar 2014 10:23:53 -0800 (PST)
Received: by 10.50.40.131 with HTTP; Thu, 6 Mar 2014 10:23:53 -0800 (PST)
In-Reply-To: <21271.44610.414071.370642@fireball.kivinen.iki.fi>
References: <21271.44610.414071.370642@fireball.kivinen.iki.fi>
Date: Thu, 06 Mar 2014 19:23:53 +0100
Message-ID: <CAHf5+hpsbtGsZPeWEdBe2-SStNugUz5D0T7xChPM_S1w3TZXiQ@mail.gmail.com>
From: Daniel Palomares <daniel.palomares.ietf@gmail.com>
To: Tero Kivinen <kivinen@iki.fi>
Content-Type: multipart/alternative; boundary="bcaec52995a154401304f3f43dd1"
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/um1CJPomHH5dmzRjUYVDuph9T8E
Cc: IPsecme WG <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: Thu, 06 Mar 2014 18:24:06 -0000

Hi Tero,
Thank you for the comment.
In fact, I agree that is not so easy. Actually [ARORA] addressed these kind
of scenarios on his draft already. For example, one of the usage scenarios
described is: the IKEv2 signaling and the IPsec tunnel mode traffic on
different addresses for load balancing purposes.

So, would you think it is a good idea to add this information to the draft
(I mean the new requirements when IKE_SAs and IPsec_SAs are on separated
nodes)? ... Or instead, would you think it would be good to ignore how
applications are managing their IPsec_SAs and IKE_SAs and  just delete the
sentence " Note that IKEv2 and IPsec session do not need to be on the same
node as IKEv2 and IPsec context are different".

We could also just mention that we wish to make clear that there are
parameters related to the IKE_SA and others for the IPsec_SA.

KR
Daniel Palomares



2014-03-06 0:07 GMT+01:00 Tero Kivinen <kivinen@iki.fi>:

> 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.
> --
> kivinen@iki.fi
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>