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

[Paul Hoffman <[e-mail]>]

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