[Gen-art] draft-ietf-v6ops-ipsec-tunnels-05

[Brian E Carpenter <[e-mail]>]

OK. I'll clear my DISCUSS and put this in as a comment, for
use at David K's discretion. Thanks everyone!

    Brian

On 2007-01-18 16:30, [e-mail] wrote:
> 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
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------
> 
>> -----Original Message-----
>> From: Pekka Savola [mailto:[e-mail]] 
>> Sent: Thursday, January 18, 2007 3:11 AM
>> To: Black, David
>> Cc: [e-mail]; [e-mail]; [e-mail]; 
>> [e-mail]; [e-mail]; 
>> [e-mail]; [e-mail]
>> 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 [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
> 

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