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.
Sheila
________________________________________
From: Tero Kivinen [kivi...@iki.fi]
Sent: Tuesday, October 20, 2009 9:40 AM
To: ipsec@ietf.org
Cc: Frankel, Sheila E.; pasi.ero...@nokia.com
Subject: RFC4307 & ENCR_NULL & USGv6 profile & Roadmap document
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.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
