Subject: [Gen-art] Gen-ART review of draft-ietf-ipsecme-roadmap-08

From: <[email-masked]>
Date: Sun, 11 Jul 2010 22:56:37 -0400

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq . 

Please resolve these comments along with any other comments you may receive.

Summary:
This draft is on the right track, but has open issues, described in the review.

This is a very useful summary of all of the RFCs (and some in-progress Internet-Drafts) that specify or are related to IPsec.  It will be very useful to those new to IPsec, as it describes the organization of the RFCs and relationships among them. 

I found one open issue - Sections 5.4.1 and 5.4.2 mis-state the applicability of combined mode algorithms to IPsec-v2.  All of the other comments in this review are minor.

Section 2.2 lists the RFC # range for IPsec-v1.  Please also list the RFC # ranges for IPsec-v2 and IPsec-v3.

** 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).

Section 5.4.3 - RFC 5282 is based on a combined mode framework in RFC 5116.

Section 8.4.1 appears to apply to IPsec-v2 only, and not IPsec-v3.  If that is correct, 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.

In Section 9.2.1, "Fibre Channel/SCSI" --> "Fibre Channel".  If you want to cite the RFCs involved, IP over FC is RFC 4338 and FC over IP is RFC 3821.

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.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 16 Jul 2010 12:18:39 -0700

>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.

>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.

>     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

---

From: <[email-masked]>
Date: Sun, 18 Jul 2010 19:30:39 -0400

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:
> >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:[email-masked]]
> Sent: Friday, July 16, 2010 3:19 PM
> To: Black, David; [email-masked]; [email-masked];
[email-masked]
> Cc: [email-masked]; [email-masked]; Black, David;
[email-masked]
> Subject: Re: [IPsec] Gen-ART review of draft-ietf-ipsecme-roadmap-08
> 
> >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:
> >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 8.4.1 appears to apply to IPsec-v2 only, and not IPsec-v3.
If that is correct, 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.