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

[Mohan Parthasarathy <[e-mail]>]

Pekka,

If you include this in section 1.0 (where the phrase "interface" is clarified), then the text
needs modification.  In that case, we can keep it  more general and simple by adding 
reference to RFC 2863. 

-mohan


----- Original Message ----
From: Pekka Savola <[e-mail]>
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Sent: Thursday, January 18, 2007 10:22:12 PM
Subject: Re: Gen-ART review of draft-ietf-v6ops-ipsec-tunnels-04.txt

Hi,

Does anyone else have preference on this?

To me, it seems that if more (general) information is added on interfaces, 
it should probably go near the last (added) paragraph in Section 1.  That 
said, at least to me (personally) the proposed text below seems too 
lengthy and too detailed for this document.

I'm also not sure how helpful the text is in the sense that nodes quite 
often have a lot of various virtual and pseudointerfaces (just for these 
kinds of purposes) which are shown in SNMP MIB modules (such as Interface 
MIB) but there is no (easy) way to see them otherwise.

On Thu, 18 Jan 2007 [e-mail] wrote:
> 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