[Gen-art] Gen-ART review of draft-ietf-v6ops-ipsec-tunnels-04.txt
Black_David@emc.com Sun, 10 December 2006 01:56 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtDvD-0008Hh-VO; Sat, 09 Dec 2006 20:56:07 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtDvC-0008Hc-By for gen-art@ietf.org; Sat, 09 Dec 2006 20:56:06 -0500
Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtDvA-0000tO-Ux for gen-art@ietf.org; Sat, 09 Dec 2006 20:56:06 -0500
Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBA1tgWs008444; Sat, 9 Dec 2006 20:55:42 -0500 (EST)
Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBA1tafN021931; Sat, 9 Dec 2006 20:55:36 -0500 (EST)
From: Black_David@emc.com
Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Dec 2006 20:55:36 -0500
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: Sat, 09 Dec 2006 20:55:34 -0500
Message-ID: <F222151D3323874393F83102D614E055068B89BB@CORPUSMX20A.corp.emc.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Gen-ART review of draft-ietf-v6ops-ipsec-tunnels-04.txt
Thread-Index: Accb/kfOLVlhcqJjROCOPNoBnWjU/A==
To: gen-art@ietf.org, rfg@acm.org, mohanp@sbcglobal.net, psavola@funet.fi, Hannes.Tschofenig@siemens.com
X-OriginalArrivalTime: 10 Dec 2006 01:55:36.0006 (UTC) FILETIME=[48C80660:01C71BFE]
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.12.9.171432
X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CP_NOT_1 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb
Cc: david.kessens@nokia.com, Black_David@emc.com, fred.baker@cisco.com, kurtis@kurtis.pp.se
Subject: [Gen-art] Gen-ART review of draft-ietf-v6ops-ipsec-tunnels-04.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Errors-To: gen-art-bounces@ietf.org
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-v6ops-ipsec-tunnels-04.txt Reviewer: David L. Black Review Date: 9 December 2006 IESG Telechat date: 14 December 2006 Summary: This draft is on the right track, but has open issues, described in the review. Comments: As an informational document whose primary purpose is to explain how to use protocols specified elsewhere, clarity is of primary importance. While I was able to figure out what the draft is trying to say, it needs attention. The open issues include the clarity problems in Section 4 that rise to the level of possible or actual technical misstatements, the lack of explanation of requirements in Section 5.2, and the missing IPsec details. My detailed comments are as follows: The recommendation against tunnel mode should be included in the abstract. Section 4 has some wording problems: 1. [RFC2401] does not allow IP as the next layer protocol in traffic selectors when an IPsec SA is negotiated. [RFC4301] also allows IP as the next layer protocol (like TCP or UDP) in traffic selectors. The "also" is susceptible to misreading. The second sentence should be rephrased to: "In contrast, [RFC4301] does allow ..." 2. [RFC4301] assumes IKEv2, as some of the new features cannot be negotiated using IKEv1. It is valid to negotiate multiple traffic selectors for a given IPsec SA in [RFC4301]. This is possible only with [RFC4306]. If [RFC2409] is used, then multiple SAs need to be set up for each traffic selector. The last sentence is incorrect as written ("set up" needs to be replaces by "set up, one for each" to correct it) and the use of RFC numbers for protocol names is semi-opaque. The following would be much clearer: 2. [RFC4301] assumes IKEv2, as some of the new features cannot be negotiated using IKEv1. It is valid to negotiate multiple traffic selectors for a given IPsec SA in [RFC4301]. This is possible only with IKEv2. If IKEv1 is used as specified in [RFC2409], then each traffic selector requires a separate SA. I strongly recommend use of the protocol names instead of just RFC numbers for clarity throughout the draft, and using both (e.g., "IKEv1 [RFC2409]") is an acceptable alternative. Table 1 in Section 5 uses acronyms for addresses in the "Contains" column that need to be defined before they are used. Section 5.2 discusses the consequences of whether the endpoint of an IPsec tunnel-mode SA is modeled as an IPv6 interface or not. It should say that there is always an IPv6 interface at the endpoint of a IPv6-in-IPv4 tunnel, and the discussion of whether to model the SA as an interface is concerned with whether the functionality of an IPv6 interface is realized by the IPsec SA or outside of it. It should also be stated that all uses of the word "interface" refer to an IPv6 interface, and that the phrase "tunnel interface" refers to an IPv6 interface at the endpoint of an IPv6-in-IPv4 tunnel, independent of whether the tunnel is realized by IPsec tunnel mode. The end of Section 1 would be a good place to do this. The use of the phrase "IP interface" in Section A.1 is considerably clearer than the use of "interface" without "IP" in Section 5.2 - using "IP interface" throughout Section 5.2 (and for that matter the entire draft) would improve readability. The three requirements in Section 5.2 are generally applicable, and should not be buried in Section 5.2's discussion of IPsec tunnel mode. The requirements also lack explanations of why they are requirements. At a minimum, the statement of the requirements should be moved into Section 5 (before 5.1), but I would suggest moving them to the end of Section 3 and adding a discussion of why these requirements are important (e.g., what goes wrong if they're not met) with reference to the scenarios described in Section 3. Cross-checking this draft against the elements in Section 8 of draft-bellovin-useipsec-05.txt, I find some things that need attention: a) Selectors - Yes, specified in Section 5.1 b) IPsec protocol and mode - Yes, ESP vs. AH is at the end of section 4 and tunnel-vs-transport is a major portion of this draft. c) Key management - Almost. The numerous mentions of IKE indicate a preference for automatic keying, but there should also be a strong recommendation against manual keying, due to the amount of IPv6 traffic that may use an IPv6-in-IPv4 tunnel. Manual keying of IKE needs to be clearly distinguished from manual configuration of the IPv6-in-IPv4 tunnel. The end of Section 2 would be a good location for these topics. d) SPD entries - Yes, specified in Section 5.1 e) Identification forms - Yes, but. The first bullet in Section 5.3 has a weak recommendation for IPv4 addresses as identities. The "but" is that ingress filtering is discussed entirely in the abstract, and additional discussion is needed about how to determine what IPv6 ingress filter to use with which IPv4 address (this may be part of tunnel configuration). f) Authentication form - Yes, second bullet in section 5.3 g) IKE versions and modes - No. Section 4 implies that both IKEv1 and IKEv2 can be used, although IKEv2 is somewhat preferred - this should probably be stated explicitly. There is no discussion of IKEv1 Main vs. Aggressive mode - it would suffice to say that if IPv4 addresses are used as identities, identity protection is not required (it's obvious where the traffic is coming from), making Aggressive mode an acceptable alternative to Main mode. h) IPsec support availability - No. This can be side- stepped to some extent by noting that the IPv6 RFCs require IPsec support. Note that I am not asking that this draft meet all the requirements in Section 8 of the bellovin-useipsec draft, and in particular, I'm giving this draft significant slack against the usual IETF requirement that sufficient mandatory-to-implement elements be specified for interoperability. With the possible exception of IKEv1 vs. IKEv2, interoperability requirements belong in the RFCs that specify the protocols involved. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
- [Gen-art] Gen-ART review of draft-ietf-v6ops-ipse… Black_David
- [Gen-art] Re: Gen-ART review of draft-ietf-v6ops-… Fred Baker
- [Gen-art] Re: Gen-ART review of draft-ietf-v6ops-… Pekka Savola
- [Gen-art] Re: Gen-ART review of draft-ietf-v6ops-… Mohan Parthasarathy
- [Gen-art] Re: Gen-ART review of draft-ietf-v6ops-… Mohan Parthasarathy
- [Gen-art] RE: Gen-ART review of draft-ietf-v6ops-… Black_David
- [Gen-art] Re: Gen-ART review of draft-ietf-v6ops-… Fred Baker
- [Gen-art] Re: Gen-ART review of draft-ietf-v6ops-… Mohan Parthasarathy
- [Gen-art] RE: Gen-ART review of draft-ietf-v6ops-… Black_David
- [Gen-art] Re: Gen-ART review of draft-ietf-v6ops-… Pekka Savola
- [Gen-art] Re: Gen-ART review of draft-ietf-v6ops-… Mohan Parthasarathy
- RE: [Gen-art] Re: Gen-ART review ofdraft-ietf-v6o… Black_David