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

[Fred Baker <[e-mail]>]

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 :-)

On Dec 9, 2006, at 5:55 PM, [e-mail] 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
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------

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