Re: [IPsec] Draft: IKEv2/IPsec Context Definition
yogendra pal <jntupal@gmail.com> Wed, 19 February 2014 10:22 UTC
Return-Path: <jntupal@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 CB6E91A0457 for <ipsec@ietfa.amsl.com>; Wed, 19 Feb 2014 02:22:52 -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 62mPV0hhcioC for <ipsec@ietfa.amsl.com>; Wed, 19 Feb 2014 02:22:49 -0800 (PST)
Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) by ietfa.amsl.com (Postfix) with ESMTP id CD2081A03EE for <ipsec@ietf.org>; Wed, 19 Feb 2014 02:22:48 -0800 (PST)
Received: by mail-yk0-f174.google.com with SMTP id 20so456704yks.5 for <ipsec@ietf.org>; Wed, 19 Feb 2014 02:22:45 -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=AkQyVPtAKaEMXwq5nHFMAiIQQClQnMJ0FUuxkUjQgl8=; b=YHxBsZhBmHReimTibulbbZtkh4gYutXO8nzd17YixsXaWGVJ7PqhOdf0w1/7a6yHyL QO7M4IaeZQgIFKCpi7M1q4S8i8F1icUouPtFHdzBXYIn5vSUFOeUDoXzVlWIl0pv6rzN b/5w0S8a/58QroE8YJh5Pa3o/f6a3UWdGbwP8ZaDT/Udsks2qAjl+3ucB05nvETRcWZ2 MXEpl5YRcU7TCyZvr/pQyxVBUdDqhjlNwYK2/2HiVs/9yoWG4LcL9pHjU4YGyRMZFAQY 126WBaKOdzOUtFFVFyA2n+9B6lXJPUiXwthSskSEX90HcAiDdjmfxcyoQ2QSJxTFESc+ bOEA==
MIME-Version: 1.0
X-Received: by 10.236.100.235 with SMTP id z71mr37050824yhf.43.1392805365419; Wed, 19 Feb 2014 02:22:45 -0800 (PST)
Received: by 10.170.189.70 with HTTP; Wed, 19 Feb 2014 02:22:45 -0800 (PST)
In-Reply-To: <CADZyTkkMTo88ccJsyVg_Z55Y=znNiFpbvApNTq_UY93M61g=AQ@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> <CADZyTkkMTo88ccJsyVg_Z55Y=znNiFpbvApNTq_UY93M61g=AQ@mail.gmail.com>
Date: Wed, 19 Feb 2014 15:52:45 +0530
Message-ID: <CA+dB4X58BSTHb6E0Fecz+bDptYuvXqYaewre3=D-E5tjB=yfLA@mail.gmail.com>
From: yogendra pal <jntupal@gmail.com>
To: Daniel Migault <mglt.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="20cf301b65fb0c133904f2bfc588"
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Tipc_DxNrTtRG5PyTi4uhmV0ZIs
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 10:22:53 -0000
See inline comments >>Is there any format you like to see xml, jason, bytes format... ? [Yogendra Pal] instance-id or flow-id will be in bytes, atmost 4 bytes. >>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? [Yogendra Pal] 1. From end-user perspective, initiator may NOT know his tunnel is with A or B (since, operator would have configured A and B with same tunnel endpoint for redundancy). 2. Given that A and B are supporting redundancy for tunnel. Operator configure(s) node A and B as same h/w, however, B can be a low hanging node (asymmetric h/w). 3. Node A can be a device (e.g router) with multiple blades or linecard and each linecard doing ipsec processing. Similarly B also. In general, operator have load balancing/sharing which will dictates different tunnels hosted on different linecards and hence the steering logic/load balancing algorithm. This steering logic resulting into *flow-id or instance-id. * I hope I have answered your query Thanks, Yogendra Pal (Ericsson, India) On Wed, Feb 19, 2014 at 2:33 PM, Daniel Migault <mglt.ietf@gmail.com> wrote: > 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>: > >> > >>> 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 >
- [IPsec] Draft: IKEv2/IPsec Context Definition Daniel Palomares
- Re: [IPsec] Draft: IKEv2/IPsec Context Definition yogendra pal
- Re: [IPsec] Draft: IKEv2/IPsec Context Definition yogendra pal
- Re: [IPsec] Draft: IKEv2/IPsec Context Definition Daniel Palomares
- Re: [IPsec] Draft: IKEv2/IPsec Context Definition yogendra pal
- Re: [IPsec] Draft: IKEv2/IPsec Context Definition Daniel Migault
- Re: [IPsec] Draft: IKEv2/IPsec Context Definition yogendra pal
- Re: [IPsec] Draft: IKEv2/IPsec Context Definition yogendra pal
- Re: [IPsec] Draft: IKEv2/IPsec Context Definition Valery Smyslov
- Re: [IPsec] Draft: IKEv2/IPsec Context Definition Daniel Palomares
- Re: [IPsec] Draft: IKEv2/IPsec Context Definition Daniel Palomares
- Re: [IPsec] Draft: IKEv2/IPsec Context Definition Valery Smyslov
- Re: [IPsec] Draft: IKEv2/IPsec Context Definition Daniel Palomares
- Re: [IPsec] Draft: IKEv2/IPsec Context Definition Yaron Sheffer
- Re: [IPsec] Draft: IKEv2/IPsec Context Definition Daniel Palomares
- Re: [IPsec] Draft: IKEv2/IPsec Context Definition Daniel Migault