Re: [IPsec] Gen-ART review of draft-ietf-ipsecme-roadmap-08

[<[e-mail]>]

Paul,

> >Section 2.2 lists the RFC # range for IPsec-v1.  Please also list the
RFC # ranges for IPsec-v2 and
> IPsec-v3.
> 
> Disagree. The definition of IPsec-v2 and -v3 is complicated, as is
clear from the document. Listing
> RFCs here will send the wrong message.

How about listing the RFC # for just the architecture RFCs (2401 for v2,
4301 for v3)?  It seems odd/inconsistent to indicate in this section
where in the RFC sequence one can find only the truly obsolete IPsec-v1.

> >** Sections 5.4.1 and 5.4.2 both contain a NOTE stating that combined
mode algorithms are "not a
> > feature of IPsec-v2" and hence lists them as N/A.  That's not
correct.  The correct situation is:
> >- Combined mode algorithms for ESP can be negotiated as encryption
> >	algorithms (the integrity protection algorithm would typically
> >	be omitted proposals that do this).
> >- Combined mode algorithms cannot be used with IKEv1, as they're
> >	incompatible with its design (see the Introduction section of
> >	RFC 5282 for a more detailed explanation).
> >Hence the N/A entries for IKEv1 are correct, but both AES-CCM and
AES-GCM should be "optional" for
> >ESPv2 (and the NOTE should be revised accordingly).
> 
> I am having a hard time following your logic here. Where in "IPsec-v2"
do you see combined modes
> as being defined? I agree that they can be negotiated for ESP; why
does that make them a feature
> for all of IPsec-v2?

The current "not a feature of IPsec-v2" language will be (mis)read as
"cannot be used with IPsec-v2."  Since we agree that the latter
implication is incorrect, the language should be edited to avoid
creating that incorrect implication.

[... snip ...]

> >Section 8.8.1 also appears to be IPsec-v2 only, and in addition to
stating that should comment that
> this was not widely adopted, and NAT traversal is the commonly used
mechanism to deal with NATs.
> 
> RFC 2709 was only a model, not a protocol. The model and protocol are
both part of IPsec-v3, but RFC
> 2709 was not "part of" IPsec-v2 in that it was suggestions for
deployment.

I suggest adding some form of the above two sentences to 8.8.1 for
clarity.

Thanks,
--David

> -----Original Message-----
> From: Paul Hoffman [mailto:[e-mail]]
> Sent: Friday, July 16, 2010 3:19 PM
> To: Black, David; [e-mail]; [e-mail];
[e-mail]
> Cc: [e-mail]; [e-mail]; Black, David;
[e-mail]
> Subject: Re: [IPsec] Gen-ART review of draft-ietf-ipsecme-roadmap-08
> 
> At 10:56 PM -0400 7/11/10, <[e-mail]> wrote:
> >Section 2.2 lists the RFC # range for IPsec-v1.  Please also list the
RFC # ranges for IPsec-v2 and
> IPsec-v3.
> 
> Disagree. The definition of IPsec-v2 and -v3 is complicated, as is
clear from the document. Listing
> RFCs here will send the wrong message.
> 
> >** Sections 5.4.1 and 5.4.2 both contain a NOTE stating that combined
mode algorithms are "not a
> feature of IPsec-v2" and hence lists them as N/A.  That's not correct.
The correct situation is:
> >- Combined mode algorithms for ESP can be negotiated as encryption
> >	algorithms (the integrity protection algorithm would typically
> >	be omitted proposals that do this).
> >- Combined mode algorithms cannot be used with IKEv1, as they're
> >	incompatible with its design (see the Introduction section of
> >	RFC 5282 for a more detailed explanation).
> >Hence the N/A entries for IKEv1 are correct, but both AES-CCM and
AES-GCM should be "optional" for
> ESPv2 (and the NOTE should be revised accordingly).
> 
> I am having a hard time following your logic here. Where in "IPsec-v2"
do you see combined modes as
> being defined? I agree that they can be negotiated for ESP; why does
that make them a feature for all
> of IPsec-v2?
> 
> >Section 5.4.3 - RFC 5282 is based on a combined mode framework in RFC
5116.
> 
> I think you meant this for 5.4.4. It is a reasonable addition.
> 
> >Section 8.4.1 appears to apply to IPsec-v2 only, and not IPsec-v3.
If that is correct, it should be
> stated.
> 
> Good catch, it should be stated.
> 
> >Section 8.8.1 also appears to be IPsec-v2 only, and in addition to
stating that should comment that
> this was not widely adopted, and NAT traversal is the commonly used
mechanism to deal with NATs.
> 
> RFC 2709 was only a model, not a protocol. The model and protocol are
both part of IPsec-v3, but RFC
> 2709 was not "part of" IPsec-v2 in that it was suggestions for
deployment.
> 
> >In Section 9.2.1, "Fibre Channel/SCSI" --> "Fibre Channel".
> 
> Agree.
> 
> >If you want to cite the RFCs involved, IP over FC is RFC 4338 and FC
over IP is RFC 3821.
> 
> I don't those help here.
> 
> >idnits 2.12.04 found some minor nits:
> >
> >  ** There are 4 instances of too long lines in the document, the
longest one
> >     being 3 characters in excess of 72.
> 
> These are non-visible gremlins; the RFC Production Center can squash
them easily.
> 
> --Paul Hoffman, Director
> --VPN Consortium