Frankel, Sheila E. writes: > I interpreted RFC 4307 slightly differently than Tero does, and I > stand by the wording of both the USGv6 Profile and the IPsec > Roadmap. Although RFC 4307's domain is limited to IKEv2, it clearly > specifies both those algorithms used within IKEv2 and also those > algorithms that IKEv2 negotiates for use by IPsec. That is why there > are 2 separate lists of algorithms: Section 3.1.1 (Encrypted Payload > Algorithms) specifies those algorithms that are used BY IKEv2 in its > Encrypted Payload. Sections 3.1.3 (IKEv2 Transform Type 1 > Algorithms) and 3.1.5 (IKEv2 Transform Type 3 Algorithms) lists > those algorithms that IKEv2 should be able to negotiate for use > within IPsec/child SAs. One detail that supports this interpretation > is the inclusion of NULL encryption in section 3.1.3 - clearly, this > is not appropriate in the IKE Encrypted Payload. If the > applicability of Sections 3.1.3 and 3.1.5 is limited to IKEv2 SAs, > then there is no need for the more constrained list in Section > 3.1.1, which clearly applies only to IKEv2's payloads.
Hmm... Yes, it could be interpreted so also, but what is the relationship between RFC4307 and RFC4305/4835 then. Would RFC4305/RFC4835 then cover only manual keying and IKEv1? I always assumed that RFC4307 talks about IKEv2 SAs and RFC4305/4835 talks about ESP and AH (i.e. IPsec SAs aka Child SAs). One reason I think this is the correct interpretation is that RFC4307 section 3.1.4 lists Transform Type 2 Algorithms (Pseudor-random functions, PRFs), and those are applicable ONLY to IKEv2. IPsec SAs/Child SAs/ESP/AH cannot have PRFs. Also section 3.1.5 does not give any status for NONE authentication (as it cannot be used for IKEv2 SAs), but for example RFC4305/RFC4835 both give requirement for it (MUST / MAY). -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
