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
