Subject: [Gen-art] Gen-ART review of draft-ietf-v6ops-ipsec-tunnels-04.txt

From: [email-masked]
Date: Sat, 9 Dec 2006 20:55:34 -0500

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-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Fred Baker <[email-masked]>
Date: Sun, 10 Dec 2006 13:16:31 -0800

Thanks, David...

Authors, initial comments from the doc shepherd (aka your truly)...

please engage in conversation with David and either address his  
issues or convince him he's wrong :-)

---

From: Pekka Savola <[email-masked]>
Date: Tue, 12 Dec 2006 15:33:12 +0200 (EET)

Hello and thanks for review!

I believe the comments look reasonable, and most of them should be 
addressed easily. Two comments below, the first for my fellow co-authors 
and the second as a general comment to you and to Mohan.

>> be rephrased to: "In contrast, [RFC4301] does allow ..."

Mohan or Richard, could you clarify this?  I thought the idea was that 
RFC2401 does not explicitly mention IP as the possible next layer 
protocol, while many implementations do support it (and we aren't quite 
sure whether such support is mandatory-to-implement)?  On the other hand 
RFC4301 explicitly requires support for all next layer protocol values.

Maybe we forgot to to reword the text above since this become clearer 
after earlier iterations.  If so, suggestions to reword?

>> goes wrong if they're not met) with reference to the scenarios

We could easily shuffle the text around a bit.  Now that I read this, only 
the first one seems to be clearly worded as a "requirement" rather than a 
general observation.  While the third one needs clarification (Mohan?), 
only the first one (IMHO) can easily be expanded why that is so:

    1.  All of IPv6 traffic should be protected, including link-local
        (e.g., Neighbor Discovery) and multicast traffic.

    2.  In router-to-router tunnels, the source and destination addresses
        of the traffic could come from a wide range of prefixes that are
        normally learned through routing.  As routing can always learn a
        new prefix, there is no way to know all the prefixes a priori
        [RFC3884].

    3.  Source address selection depends on the notions of routes and
        interfaces.  This affects scenarios (2) and (3).

1) is required so that every form of traffic that is supported by RFC4213 
IPv6-in-IPv4 tunnels is supported.  A more general explanation is 
mentioned in 2nd paragraph of Section 6 (in effect, "we want link local, 
e.g., routing protocols, multicast, etc.") but it doesn't mention why we 
want them (explanation above).  On the other hand Appendix A describes the 
tunnel mode setup if this is not felt to be a requirement and Tunnel mode 
is felt better in the particular scenario.

As for 3), I'm not 100% sure what point it wants to convey and how it's 
relevant here (does that refer to a multihomed endpoint with multiple 
addresses?) Mohan?

Pekka