ipsec October 2009 archive
Main Archive Page > Month Archives  > ipsec archives
ipsec: Re: [IPsec] RFC4307 & ENCR_NULL & USGv6 profile &

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

From: <Pasi.Eronen_at_nospam>
Date: Fri Oct 30 2009 - 08:54:01 GMT
To: <kivinen@iki.fi>, <sheila.frankel@nist.gov>


Tero:

I think you're correct that RFC 4307 has a bug: ENCR_NULL should be MUST NOT, instead of MAY (note that ENCR_NULL in 4305/4835 is MUST). Go ahead and submit an errata about this!

Best regards,
Pasi

> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
> Of ext Tero Kivinen
> Sent: 22 October, 2009 11:39
> To: Frankel, Sheila E.
> Cc: ipsec@ietf.org; Eronen Pasi (Nokia-NRC/Helsinki)
> Subject: Re: [IPsec] RFC4307 & ENCR_NULL & USGv6 profile & Roadmap
> document
>
> 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).
> --
> kivinen@iki.fi
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec



IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec