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 <jntu...@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.i...@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 <jntu...@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 <jntu...@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.i...@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 mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
