I think extensions such as RoHC that change (or extend) the way keying material is generated, should and do specify how it is done. Leaving that text there becomes a recommendation for future draft writers, which I think is superfluous.
I think we should leave the text as it is. On Jan 19, 2010, at 4:26 AM, Paul Hoffman wrote: > 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. > > Also: > > 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. > > --Paul Hoffman, Director > --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
