Valery Smyslov writes: > Paul Hoffman writes: > > All good points, Valery. Here's another attempt; please check carefully. > > > > A single CHILD_SA negotiation may result in multiple security > > associations. ESP and AH SAs exist in pairs (one in each direction), > > so two SAs are created in a single Child SA negotiation for them. > > Furthermore, Child SA negotiation may include some future IPsec > > protocol(s) in addition to, or instead of, ESP or AH (for example, > > ROHC_INTEG). In any case, keying material for each child SA MUST be > > taken from the expanded KEYMAT using the following rules: > > > > o All keys for SAs carrying data from the initiator to the responder > > are taken before SAs going from the responder to the initiator. > > > > o If multiple IPsec protocols are negotiated, keying material for > > each Child SA is taken in the order in which the protocol headers > > will appear in the encapsulated packet. > > > > o If an IPsec protocol requires multiple keys, the order in which > > they are taken from the SA's keying material needs to be described > > in protocol specification. For ESP and AH, [IPSECARCH] defines > > the order, namely: the encryption key (if any) MUST be taken from > > the first bits and the integrity key (if any) MUST be taken from > > the remaining bits. > > Looks fine to me.
Looks good for me too. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
