Re: [IPsec] RFC4307 & ENCR_NULL & USGv6 profile & Roadmap document

[Tero Kivinen <[e-mail]>]

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).
-- 
[e-mail]