Re: [Gen-art] [IPsec] Gen-ART review of draft-ietf-ipsecme-roadmap-08
<david.black@emc.com> Sun, 18 July 2010 23:30 UTC
Return-Path: <david.black@emc.com>
X-Original-To: gen-art@core3.amsl.com
Delivered-To: gen-art@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32BC83A6800; Sun, 18 Jul 2010 16:30:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.636
X-Spam-Level:
X-Spam-Status: No, score=-5.636 tagged_above=-999 required=5 tests=[AWL=-0.896, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JASMc2ZD06L; Sun, 18 Jul 2010 16:30:55 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 56FBB3A69AD; Sun, 18 Jul 2010 16:30:51 -0700 (PDT)
Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id o6INUrBa006982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Jul 2010 19:30:53 -0400
Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Sun, 18 Jul 2010 19:30:47 -0400
Received: from corpussmtp5.corp.emc.com (corpussmtp5.corp.emc.com [128.221.166.229]) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id o6INUPmv026034; Sun, 18 Jul 2010 19:30:43 -0400
Received: from CORPUSMX80B.corp.emc.com ([10.254.89.203]) by corpussmtp5.corp.emc.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 18 Jul 2010 19:30:41 -0400
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 18 Jul 2010 19:30:39 -0400
Message-ID: <C2D311A6F086424F99E385949ECFEBCB03237184@CORPUSMX80B.corp.emc.com>
In-Reply-To: <p0624080fc8665e2fb562@[10.20.30.158]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [IPsec] Gen-ART review of draft-ietf-ipsecme-roadmap-08
Thread-Index: AcslG8VaRvQa/RARSxCEej1h6SRt1ABs5X9A
References: <C2D311A6F086424F99E385949ECFEBCB03189077@CORPUSMX80B.corp.emc.com> <p0624080fc8665e2fb562@[10.20.30.158]>
From: david.black@emc.com
To: paul.hoffman@vpnc.org, gen-art@ietf.org, sheila.frankel@nist.gov, suresh.krishnan@ericsson.com
X-OriginalArrivalTime: 18 Jul 2010 23:30:41.0777 (UTC) FILETIME=[3CA6B610:01CB26D1]
X-EMM-EM: Active
Cc: ipsec@ietf.org, david.black@emc.com, yaronf@checkpoint.com
Subject: Re: [Gen-art] [IPsec] Gen-ART review of draft-ietf-ipsecme-roadmap-08
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Jul 2010 23:30:59 -0000
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:paul.hoffman@vpnc.org] > Sent: Friday, July 16, 2010 3:19 PM > To: Black, David; gen-art@ietf.org; sheila.frankel@nist.gov; suresh.krishnan@ericsson.com > Cc: ipsec@ietf.org; turners@ieca.com; Black, David; yaronf@checkpoint.com > Subject: Re: [IPsec] Gen-ART review of draft-ietf-ipsecme-roadmap-08 > > At 10:56 PM -0400 7/11/10, <david.black@emc.com> 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
- [Gen-art] Gen-ART review of draft-ietf-ipsecme-ro… david.black
- Re: [Gen-art] [IPsec] Gen-ART review of draft-iet… Paul Hoffman
- Re: [Gen-art] [IPsec] Gen-ART review of draft-iet… david.black
- [Gen-art] Gen-ART review of draft-ietf-ipsecme-ro… david.black