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

yogendra pal <jntupal@gmail.com> Thu, 20 February 2014 05:52 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 A4B1E1A054A for <ipsec@ietfa.amsl.com>; Wed, 19 Feb 2014 21:52:56 -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 YjdeMYErexlI for <ipsec@ietfa.amsl.com>; Wed, 19 Feb 2014 21:52:52 -0800 (PST)
Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 01D6E1A0263 for <ipsec@ietf.org>; Wed, 19 Feb 2014 21:52:51 -0800 (PST)
Received: by mail-qc0-f176.google.com with SMTP id e16so2557113qcx.35 for <ipsec@ietf.org>; Wed, 19 Feb 2014 21:52:48 -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=3PTYBE04T3wglShwOThdVtGER51/uVILwMBa+Z7iNjY=; b=oD5QVJFBYzqUeSnCEJUkJOH5V1eWTIJ5PqObr3f28y35m3159zMj+0EGbs1gowuS2m l225PQlT37z3rpdQC4s8nwprJca7zf9zH/cU5kGV249KpHNv1cI2BpPjjfRndBhPHq9k 0RwcgRbBViO1x9vGMHYXiSolCOMRU1chUmBflAvMCx8EIYC8XoWzE95ZycAHsCMaA2qh n52o2z/S6b8UUPbQi4YyIxRqOymTlt+o2Bi+nxnOnNkVcFQ4J7bJr/eDBpGFnN5Pa1pM QLwVhNnGaU8ScB6N6ZrJ0RoKWFG23Dv1SRqUnPdr8LtqmUgjJIwEJ+PNcRlPY7HcmZyL csFQ==
MIME-Version: 1.0
X-Received: by 10.236.91.201 with SMTP id h49mr36801009yhf.96.1392875568231; Wed, 19 Feb 2014 21:52:48 -0800 (PST)
Received: by 10.170.189.70 with HTTP; Wed, 19 Feb 2014 21:52:48 -0800 (PST)
In-Reply-To: <CA+dB4X58BSTHb6E0Fecz+bDptYuvXqYaewre3=D-E5tjB=yfLA@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> <CA+dB4X58BSTHb6E0Fecz+bDptYuvXqYaewre3=D-E5tjB=yfLA@mail.gmail.com>
Date: Thu, 20 Feb 2014 11:22:48 +0530
Message-ID: <CA+dB4X6mZK7390yZtWg0toSsqNqzggfRwYn+_QBHhdRs3L2XnA@mail.gmail.com>
From: yogendra pal <jntupal@gmail.com>
To: Daniel Migault <mglt.ietf@gmail.com>
Content-Type: multipart/alternative; boundary=20cf3011ddfd75fa9204f2d01dbf
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/ZoZY4S-KCGq_ROt1Kh4AgLv7qA4
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: Thu, 20 Feb 2014 05:52:56 -0000

Hi Daniel,

Few more queries/input I have.

1. When you say "IKEv2 Session parameters" and "IPsec Session parameters" ,
is it implicit that respective IKEv2 policy and IPsec policy governing
these sessions are also part of these session parameters or they get
explicitly synced between
nodes ?

2. I have NOT seen IKEv2 SA lifetime present in the "IKEv2 Session
parameters" similar to, IPsec SA lifetime present in "IPsec Session
parameters". Is this got missed or will be coming as part of explicit sync
of policy b/w nodes ? If it's implicit then we SHOULD add this into "IKEv2
Session parameters" to support IKEv2 SA rekey.

3. Similar to (2), Is ESN (extended sequence number) support will come in
into "IPsec Session parameters" ?

4. For IPsec SA, if PFS is enabled, does it need to reflect in "IPsec
Session parameters" ?

5. In IKEv2, there is option to support ike-window-size, will this also be
part of "IKEv2 Session parameters" ?

6. Message-ID for IKEv2 SA would be required to sync b/w nodes, will this
be synced as part of IKEv2 Session parameters" ?

6. For IRAS usecase, ip address assignment from tunnel address pool will be
synced separately and will NOT be covered as part of this document or will
it be part of "IKEv2 Sesssion parameters" ?


Thanks,
Yogendra Pal
(Ericsson, India)




On Wed, Feb 19, 2014 at 3:52 PM, yogendra pal <jntupal@gmail.com> wrote:

> 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;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>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
>>
>
>


-- 
Thanks and Regards,
Yogendra Pal
+919686202644