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.i...@gmail.com> 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 <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
