Re: [IPsec] Draft: IKEv2/IPsec Context Definition

Daniel Migault <mglt.ietf@gmail.com> Wed, 19 February 2014 09: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 9E7E51A0582 for <ipsec@ietfa.amsl.com>; Wed, 19 Feb 2014 01:03:37 -0800 (PST)
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 ACW8hGWYPiVc for <ipsec@ietfa.amsl.com>; Wed, 19 Feb 2014 01:03:34 -0800 (PST)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id EDC4D1A0581 for <ipsec@ietf.org>; Wed, 19 Feb 2014 01:03:33 -0800 (PST)
Received: by mail-wi0-f176.google.com with SMTP id hi5so4409768wib.3 for <ipsec@ietf.org>; Wed, 19 Feb 2014 01:03:30 -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=M+q1X+EQN5p/xcNRD8UoL4FHCuZ62W3VicxLvucSbEk=; b=dt+NslEab0XrantvawtwttgJYqGuCcE0x33/hVK3Qki7TZwUDlyCWdLRGlQucggeVu z7+WR7TnKJg6k4BKtF/rtRaM0/XTgLShM0yptK0jJHKPRC5XrNrowe8iHar2v/CBN7ZQ rirsdl0l6G9Rvz9AKkVAZ4k6/lWN3M/dXtvSvb8kpB3ekmoQ9wmZL1JZWEs9zTbVDqi0 RU8yRKzfThI2JVhe/iDl39y/jVm/D71EK1rtO5/g4tTPGE2ZECFW/3M42x2S1OWfNvxj 5xUq4tnj9BmI+6iBaN4AY+uHgsfWU5xHQe1UR873b2pbEiRMOlTfYHZC2b/Vl9IZ2eOZ llBg==
MIME-Version: 1.0
X-Received: by 10.194.60.37 with SMTP id e5mr26392466wjr.32.1392800609950; Wed, 19 Feb 2014 01:03:29 -0800 (PST)
Received: by 10.194.171.129 with HTTP; Wed, 19 Feb 2014 01:03:29 -0800 (PST)
In-Reply-To: <CA+dB4X4EHrbF6xXGRUvNWxZdpaNqcO3gYyy-Sc5rNrH1UiWmJQ@mail.gmail.com>
References: <CAHf5+hrQ52GPKsAZJF4ZyhFNXgwZJOTEm8u-KKqVbta6Bj=N1g@mail.gmail.com> <CA+dB4X4iRjk9hH3wyX8Qj93Kd77BnvGpsm=FK3OHho=S-+Ngiw@mail.gmail.com> <CA+dB4X7Q0BgOhZ_FKKp6eYA7jhZn=CsqEZ6Mit4EruHPojt5aw@mail.gmail.com> <CAHf5+hqQ--k6DQsK9ChW6D18wpY6i4gUgN_dGoTR4CvexwGq-Q@mail.gmail.com> <CA+dB4X4EHrbF6xXGRUvNWxZdpaNqcO3gYyy-Sc5rNrH1UiWmJQ@mail.gmail.com>
Date: Wed, 19 Feb 2014 10:03:29 +0100
Message-ID: <CADZyTkkMTo88ccJsyVg_Z55Y=znNiFpbvApNTq_UY93M61g=AQ@mail.gmail.com>
From: Daniel Migault <mglt.ietf@gmail.com>
To: yogendra pal <jntupal@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/lf7Y22JbsczydTLYALvCmPD5roo
Cc: IPsecme WG <ipsec@ietf.org>, Daniel Palomares <daniel.palomares.ietf@gmail.com>
Subject: Re: [IPsec] Draft: IKEv2/IPsec Context Definition
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: Wed, 19 Feb 2014 09:03:38 -0000

Hi,

My understanding is that at the time a format will be defined for
embedding IKEv2 and IPsec context, we should be able to embed also
proprietary parameters similar to vendor-ID with IKEv2. Of course
these parameters will be most probably ignored by other
implementations.

Is there any format you like to see xml, jason, bytes format... ?

What is not clear to me is why a SA on a processing unit X of node A
MUST necessarily be also on processing unit X of node B. I understand
processing unit as a CPU or a specific core. Am I right?


BR,
Daniel

On Wed, Feb 19, 2014 at 6:27 AM, yogendra pal <jntupal@gmail.com> wrote:
> Hi Daniel,
>
> I agree w/ what you said, let the ipsec mailing list discussion this out, I
> just opened the forum w/ my inputs "instance-id".  Since this draft is
> towards keeping IKEv2/IPsec session alive when any fault is detected on
> current node.
>
> Thanks,
> Yogendra Pal
> (Ericssson, India)
>
>
>
> On Tue, Feb 18, 2014 at 11:47 PM, Daniel Palomares
> <daniel.palomares.ietf@gmail.com> wrote:
>>
>> Hi Yogendra,
>>
>> Thank you for your comments and pointing out the lack of the IPComp
>> parameter.
>> I will update the draft including the IPComp flag , as well as the IPcomp
>> algo and the cpi-in/out values.
>>
>> I understand when you say  the draft "SHOULD capture at least instance-id
>> or flow-id". However, I'm not familiar with this definitions as IKEv2 or
>> IPsec standards. Please don't hesitate to address me to those documents if
>> they are actually standardized.
>>
>> On the other hand, I could understand that those parameters you just
>> mention (instance-id and flow-id), might be proprietary solutions to improve
>> IPsec treatment among several processing units. If it is the case, I believe
>> that our document may introduce supplementary information in the context
>> prior some negotiation, but I believe we should let the whole mailing-list
>> discuss about this.
>>
>> By now, our wish is to isolate the IKEv2 and IPsec mandatory parameters in
>> order to keep an IKEv2/IPsec session alive.
>>
>> KR,
>> Daniel Palomares
>>
>>
>>
>>
>> 2014-02-18 17:25 GMT+01:00 yogendra pal <jntupal@gmail.com>om>:
>>
>>> Hi Daniel,
>>>
>>> Given that ike and ipsec can runs on different context and nodes, context
>>> SHOULD capture at least instance-id or flow-id. This instance-id can help
>>> the node to identify which packet processing unit will process this ipsec
>>> traffic or which ipsec instance out of multiple ipsec processing unit will
>>> process this ipsec traffic.
>>>
>>> Let me take a simple example case to explain:
>>>
>>> On a node A, which has 10 processing unit (pu) = {1,2,3,4,5,6,7,8,9,10}
>>> and out of which ike is using single unit = {1} and ipsec is using 7
>>> processing unit(s) = {2,3,4,5,6,7,8} and other processing units = {9,10} for
>>> general purpose.
>>>
>>> Each IPsec SA processing can be tied with specific processing unit and
>>> can be called as instance-id or flow-id. This SA can hold instance-id or
>>> flow-id information. Upon sync up of context for each IPsec SA to other node
>>> B upon failure, it can process the same SA on specific instance-id or
>>> flow-id.
>>>
>>> P.S: If your need some text around this, I can provide you a example and
>>> usage of it.
>>>
>>> BR,
>>> Yogendra Pal
>>> (Ericsson, India)
>>>
>>>
>>> On Mon, Feb 17, 2014 at 11:20 AM, yogendra pal <jntupal@gmail.com> wrote:
>>>>
>>>> Hi Daniel,
>>>>
>>>> Quickly went through your draft, have one input for you,
>>>> [In section "5. IPsec Session parameters"]
>>>>  - Consider to have case of IPCOMP also for ipsec session parameters.
>>>>
>>>>
>>>> BR,
>>>> Yogendra Pal
>>>> (Ericsson)
>>>>
>>>>
>>>> On Thu, Feb 13, 2014 at 7:39 PM, Daniel Palomares
>>>> <daniel.palomares.ietf@gmail.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Please find a draft we have Posted. They concern the definition of
>>>>> IKEv2 and IPsec contexts.
>>>>> Comments are welcome,
>>>>>
>>>>> BR,
>>>>>
>>>>> Daniel Palomares
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Name:        draft-plmrs-ipsecme-ipsec-ikev2-context-definition.
>>>>>
>>>>> Revision: 00
>>>>> Title:       IKEv2/IPsec Context Definition
>>>>> Document date:    2014-02-12
>>>>> Group:        Individual Submission
>>>>> Pages:        8
>>>>>
>>>>> URL:http://www.ietf.org/id/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00.txt
>>>>>
>>>>> Status:https://datatracker.ietf.org/doc/draft-plmrs-ipsecme-ipsec-ikev2-context-definition/
>>>>> Htmlized:
>>>>> http://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00
>>>>>
>>>>>
>>>>> Abstract
>>>>>
>>>>>    IPsec/IKEv2 clusters are constituted of multiple nodes accessed via
>>>>> a
>>>>>    single address by the end user.  The traffic is then split between
>>>>>    the nodes via specific IP load balancing policies.  Once a session
>>>>> is
>>>>>    assigned to a given node, IPsec makes it difficult to assign the
>>>>>    session to another node.  This makes management operations and
>>>>>    transparent high availability for end users difficult to perform
>>>>>    within the cluster.
>>>>>
>>>>>    This document describes the contexts for IKEv2 and IPsec that MUST
>>>>> be
>>>>>    transferred between two nodes so a session can be restored.  This
>>>>>    makes possible to transfer an IPsec session transparently to the end
>>>>>    user.
>>>>>
>>>>>
>>>>>
>>>>> Daniel PALOMARES
>>>>>
>>>>> Orange Labs, Issy-les-Moulineaux
>>>>>
>>>>> +33 6 34 23 07 88
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> IPsec mailing list
>>>>> IPsec@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
> --
> Thanks and Regards,
> Yogendra Pal
> +919686202644
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>



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