Hello Yogendra, 2014-02-20 6:52 GMT+01:00 yogendra pal <[email protected]>:
> 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 <[email protected]> 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 <[email protected]>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 <[email protected]> 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 >>> > <[email protected]> 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 <[email protected]>: >>> >> >>> >>> 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 <[email protected]> >>> 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 >>> >>>> <[email protected]> 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 >>> >>>>> [email protected] >>> >>>>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>> >>> >>> >>> >>> >>> >> >>> > >>> > >>> > >>> > -- >>> > Thanks and Regards, >>> > Yogendra Pal >>> > +919686202644 >>> > >>> > _______________________________________________ >>> > IPsec mailing list >>> > [email protected] >>> > 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
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
