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

Daniel Palomares <daniel.palomares.ietf@gmail.com> Mon, 24 February 2014 10:05 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 4151E1A0871 for <ipsec@ietfa.amsl.com>; Mon, 24 Feb 2014 02:05:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.702
X-Spam-Level:
X-Spam-Status: No, score=0.702 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_50=0.8, 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 s6J8h9ps3f7k for <ipsec@ietfa.amsl.com>; Mon, 24 Feb 2014 02:05:17 -0800 (PST)
Received: from mail-ie0-x243.google.com (mail-ie0-x243.google.com [IPv6:2607:f8b0:4001:c03::243]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEAC1A086A for <ipsec@ietf.org>; Mon, 24 Feb 2014 02:05:14 -0800 (PST)
Received: by mail-ie0-f195.google.com with SMTP id to1so1850474ieb.10 for <ipsec@ietf.org>; Mon, 24 Feb 2014 02:05:13 -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=DZ0ctJHaael4KUSFI4y/yxqKbhL6kb7hcKZzGM7qXIA=; b=E6UxAMhiGUKc5px3p8qQnzFmfcBLZdhxZc/2AbjMC/Nid7JN+444Gb50zWXf6Ywm9T 6uAY/rXYvyprVzvX0j0OJwx1aNQ3XnumtnO4K0UKFYtu2FM5Oz1Pt490kh52+8E/rTeA wqbdKVSVuIL5RSSMxgsH/sew8ktxW7y4FLWVa9lf3nZomigdVFcvDoVEHxge4zDCFJFR R7yx/SPXAirYzTGCyUH4+AMBUHjGZsO2K7ZsMa8/n0WAxkIedRKxMvVuMtg0XiahzcvZ nSJ9nmZle8eLyMxIZoUg9A5lQB7DFGRvd8rIIumAst8WcC0J0BrwgstB26VOKJUeU3dU XRXQ==
MIME-Version: 1.0
X-Received: by 10.50.55.6 with SMTP id n6mr12979310igp.45.1393236313659; Mon, 24 Feb 2014 02:05:13 -0800 (PST)
Received: by 10.50.40.131 with HTTP; Mon, 24 Feb 2014 02:05:13 -0800 (PST)
In-Reply-To: <CA+dB4X6mZK7390yZtWg0toSsqNqzggfRwYn+_QBHhdRs3L2XnA@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> <CA+dB4X6mZK7390yZtWg0toSsqNqzggfRwYn+_QBHhdRs3L2XnA@mail.gmail.com>
Date: Mon, 24 Feb 2014 11:05:13 +0100
Message-ID: <CAHf5+hr9kEd+Wu3FO_X-N-KHZWCnCOxwygpQUFBHcZECGLdFLQ@mail.gmail.com>
From: Daniel Palomares <daniel.palomares.ietf@gmail.com>
To: yogendra pal <jntupal@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b10c9b79061b104f3241ba5
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/2FpjN5NfzkOnCfqAG6LxpUhDffY
Cc: IPsecme WG <ipsec@ietf.org>, Daniel Migault <mglt.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: Mon, 24 Feb 2014 10:05:26 -0000

Hello Yogendra,

2014-02-20 6:52 GMT+01:00 yogendra pal <jntupal@gmail.com>om>:

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

Yes, these parameters are the IKEv2 and IPsec policies governing the
sessions.


>
> 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" ?
>
>
We have included all these parameters explicitly in the following version
01. The IETF Internet-Draft Submission is disabled until 3 march 2014, so
we haven't been able to upload a newer version.
The IKEv2 lifetime, Message IDs, the ike-window-size are part of the IKEv2
session parameters, and the extended sequence numbers support will also be
part of the IPsec session 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
>


Thanks for the comments,

Regards
Daniel Palomares