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

[Daniel Migault <[e-mail]>]

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]