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

[Daniel Palomares <[e-mail]>]

Hello Yogendra,

2014-02-20 6:52 GMT+01:00 yogendra pal <[e-mail]>:

> 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 <[e-mail]> 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 <[e-mail]>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 <[e-mail]> 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
>>> > <[e-mail]> 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 <[e-mail]>:
>>> >>
>>> >>> 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 <[e-mail]>
>>> 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
>>> >>>> <[e-mail]> 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
>>> >>>>>
>>> >>>>> [phone]
>>> >>>>>
>>> >>>>>
>>> >>>>> _______________________________________________
>>> >>>>> IPsec mailing list
>>> >>>>> [e-mail]
>>> >>>>> https://www.ietf.org/mailman/listinfo/ipsec
>>> >>>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>
>>> >>>
>>> >>>
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Thanks and Regards,
>>> > Yogendra Pal
>>> > [phone]
>>> >
>>> > _______________________________________________
>>> > IPsec mailing list
>>> > [e-mail]
>>> > https://www.ietf.org/mailman/listinfo/ipsec
>>> >
>>>
>>>
>>>
>>> --
>>> Daniel Migault
>>> Orange Labs -- Security
>>> [phone]
>>>
>>
>>
>
>
> --
> Thanks and Regards,
> Yogendra Pal
> [phone]
>


Thanks for the comments,

Regards
Daniel Palomares