Re: [IPsec] Comment/Request on IKEv2bis Draft
Looks good! Thank you. BR, Emre On Mon, Aug 17, 2009 at 3:55 AM, wrote: > The original text in RFC 4306 was slightly confusing, but I think we > should leave room for ROHCoIPsec here. Perhaps adding something like > this after the bulleted list? > > If the Child SA negotiation includes some future IPsec protocol(s) > in addition to (or instead of) ESP or AH (e.g., ROHC_INTEG), then > (1) all keys for SAs carrying data from the initiator to the > responder are taken before SAs going in the reverse direction, and > (2) keying material for the IPsec protocols are taken in the order >in which the protocol headers will appear in the encapsulated >packet. > > Best regards, > Pasi > (not wearing any hats) > > > -Original Message- > > From: Emre Ertekin > > Sent: 15 August, 2009 00:54 > > To: ipsec@ietf.org > > Subject: [IPsec] Comment/Request on IKEv2bis Draft > > > Hi All, > > > > One comment/request on the IKEv2bis draft. > > > > > > One of the differences between RFC 4306 and the IKEv2bis draft is in > > Section 2.17, Generating Key Material for Child SAs. Appendix E.2 > > of the IKEv2bis draft indicates the following: > > > > In Section 2.17, removed "If multiple IPsec protocols are > > negotiated, keying material is taken in the order in which the > > protocol headers will appear in the encapsulated packet" because > > multiple IPsec protocols cannot be negotiated at one time. > > > > Is it possible to leave the quoted text in the spec? I agree that > > multiple IPsec protocols cannot be negotiated at one time; however, > > the text is useful for ROHCoIPsec implementers, where multiple keys > > may need to be generated for a ROHC-enabled Child SA. > > > > For example, if a ROHC-enabled Child-SA with ROHC_INTEG > > [draft-ietf-rohc-ikev2-extensions-hcoipsec-09] is instantiated, > > first the IPsec encryption/authentication keying material will be > > taken, then an additional key will be taken for the algorithm used > > to verify the proper decompression of packet headers. > > > > BR, > > Emre > > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Comment/Request on IKEv2bis Draft
pasi.ero...@nokia.com writes: > The original text in RFC 4306 was slightly confusing, but I think we > should leave room for ROHCoIPsec here. Perhaps adding something like > this after the bulleted list? > >If the Child SA negotiation includes some future IPsec protocol(s) >in addition to (or instead of) ESP or AH (e.g., ROHC_INTEG), then >(1) all keys for SAs carrying data from the initiator to the >responder are taken before SAs going in the reverse direction, and >(2) keying material for the IPsec protocols are taken in the order >in which the protocol headers will appear in the encapsulated >packet. That looks good for me. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Comment/Request on IKEv2bis Draft
The original text in RFC 4306 was slightly confusing, but I think we should leave room for ROHCoIPsec here. Perhaps adding something like this after the bulleted list? If the Child SA negotiation includes some future IPsec protocol(s) in addition to (or instead of) ESP or AH (e.g., ROHC_INTEG), then (1) all keys for SAs carrying data from the initiator to the responder are taken before SAs going in the reverse direction, and (2) keying material for the IPsec protocols are taken in the order in which the protocol headers will appear in the encapsulated packet. Best regards, Pasi (not wearing any hats) > -Original Message- > From: Emre Ertekin > Sent: 15 August, 2009 00:54 > To: ipsec@ietf.org > Subject: [IPsec] Comment/Request on IKEv2bis Draft > Hi All, > > One comment/request on the IKEv2bis draft. > > > One of the differences between RFC 4306 and the IKEv2bis draft is in > Section 2.17, Generating Key Material for Child SAs. Appendix E.2 > of the IKEv2bis draft indicates the following: > > In Section 2.17, removed "If multiple IPsec protocols are > negotiated, keying material is taken in the order in which the > protocol headers will appear in the encapsulated packet" because > multiple IPsec protocols cannot be negotiated at one time. > > Is it possible to leave the quoted text in the spec? I agree that > multiple IPsec protocols cannot be negotiated at one time; however, > the text is useful for ROHCoIPsec implementers, where multiple keys > may need to be generated for a ROHC-enabled Child SA. > > For example, if a ROHC-enabled Child-SA with ROHC_INTEG > [draft-ietf-rohc-ikev2-extensions-hcoipsec-09] is instantiated, > first the IPsec encryption/authentication keying material will be > taken, then an additional key will be taken for the algorithm used > to verify the proper decompression of packet headers. > > BR, > Emre ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
