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.