|Main Archive Page > Month Archives > ipsec archives|
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.
I was reading the USGv6 profile, and it complained that RFC4307 and RFC4835 do not agree on status of NULL encryption. RFC4307 says MAY, and RFC4835 says MUST.
As far as I have understood the RFC4835 defines algorithm requirements for Child SAs (ESP and AH), and RFC4307 defines algorithm requirements for IKEv2 SAs, i.e. when IKEv2 protects its own traffic.
However while the roadmap document agrees on that ("[RFC4307] specifies the encryption and integrity-protection algorithms used by IKEv2 to protect its own traffic") it also final sentence which makes this not so clear: "It also specifies the encryption and integrity-protection algorithms that IKEv2 negotiates for use within IPsec."
I.e. that last sentence would indicate that RFC4307 would also define encryption and integrity-protection algorithms for Child SAs. On the other hand it does not list IPsec-v2 nor IPsec-v3 on the requirements level so that would indicate it does not apply to IPsec, only to IKE.
In the abstract RFC4307 does not clearly say whether it only covers IKEv2 traffic or if it also covers Child SA (IPsec, ESP/AH) traffic negotiated with IKEv2. But later in the section 3.1.1 it clearly says that "The IKEv2 Encryption Payload requires..." which indicates it only covers IKEv2 SA traffic not anything else.
If this is true, then the requirement level for ENCR_NULL is clearly wrong, as RFC4306 says that ENCR_NULL MUST NOT be used when protecting IKEv2 SA traffic (section 5. Security Considerations).
So I would suggest we remove the misleading last sentence from the draft-ietf-ipsecme-roadmap-04.txt section 5.1.2, and make an errata for RFC4307 saying that ENCR_NULL is "MUST NOT" instead of "MAY".
Also the USGv6 document might also distinguish the fact that RFC4835 and RFC4307 cover different protocols, thus they does not need to agree on the requirement levels, and NULL encryption cannot really be required for IKEv2 as it would go against MUST NOT in RFC4306. -- email@example.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec