|Main Archive Page > Month Archives > ipsec archives|
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). -- email@example.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec