Sorry for the lack of subject in the first one (stupid Outlook stunt), here it is with a subject. FYI, --David
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 18, 2007 10:31 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [email protected]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: [Gen-art] (no subject) > > Pekka and Brian, > > The -05 version is much better - it's sufficiently improved to remove > the Discuss in the draft's current form. Nonetheless, I > suggest that an > RFC Editor note be used to insert the following text (much of which > Fred Baker wrote) to explain what "modeled as an interface" means: > > An important consideration in determining whether to use > IPsec tunnel > mode is whether the IPsec tunnel mode SA is modeled as an interface. > This notion of interface is logical - any time a system, host or > router, sends a datagram, it has to account for having done so using > the RFC 2863 Interface MIB. To do so, the system derives > ifIndex from > the route entry (see InetCidrRouteEntry in RFC 4292) that it uses to > forward the datagram, or from the IpDefaultRouterEntry described > in RFC 4293. The management information accessed via the ifIndex > is "the interface" from a management and configuration perspective. > > This text should be inserted immediately following this sentence in > Section 5: > > The IPv6 traffic can be protected using transport or tunnel mode. > > This will also entail adding informative references to RFCs 2863, > 4292 and 4293. This is close to the limit of what I'd be comfortable > doing with an RFC Editor Note, but I think this would significantly > improve the clarity of the "what is an interface?" confusion that > I stumbled over in the original review. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > [EMAIL PROTECTED] Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > > -----Original Message----- > > From: Pekka Savola [mailto:[EMAIL PROTECTED] > > Sent: Thursday, January 18, 2007 3:11 AM > > To: Black, David > > Cc: [email protected]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > > [EMAIL PROTECTED]; [EMAIL PROTECTED]; > > [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: Re: Gen-ART review of draft-ietf-v6ops-ipsec-tunnels-04.txt > > > > Hello David (B.), Brian, > > > > A new version of the draft has been submitted. We believe it > > addresses > > your comments. Please check it out. This was the only DISCUSS. > > > > http://tools.ietf.org/wg/v6ops/draft-ietf-v6ops-ipsec-tunnels/ > > > > Below are a few notes where it isn't 100% clear whether the > > desired impact > > was achieved. > > > > - section 5.0 almost in its entirety (most text moved from > > deleted section 5.2). > > > > NOTE: I think section 5 is still a bit unclear of when > > "interface" refers > > to "IP interface" and when "tunnel interface". > > > > NOTE: we also now explicitly state that ingress filtering > > configuration > > must be applied manually [it cannot be negotiated as part of > > IKE or IPsec > > configuration, for example]. This is likely good enough, > but I think > > David Black was looking for a bit more than that -- > unfortunately, I > > don't think any IPsec-side automation can be provided.. > > > > On Sat, 9 Dec 2006 [EMAIL PROTECTED] wrote: > > > 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 > > > [EMAIL PROTECTED] Mobile: +1 (978) 394-7754 > > > ---------------------------------------------------- > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/gen-art > > _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
