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

[[e-mail]]

I have no problem with this text going into Section 1.0 in
some form.

Thanks,
--David 

> -----Original Message-----
> From: Mohan Parthasarathy [mailto:[e-mail]] 
> Sent: Friday, January 19, 2007 8:31 PM
> To: Pekka Savola; Black, David
> Cc: [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]
> Subject: [Gen-art] Re: Gen-ART review 
> ofdraft-ietf-v6ops-ipsec-tunnels-04.txt
> 
> 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
> 
> 

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