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

[Pekka Savola <[e-mail]>]

Hello and thanks for review!

I believe the comments look reasonable, and most of them should be 
addressed easily. Two comments below, the first for my fellow co-authors 
and the second as a general comment to you and to Mohan.

On Sun, 10 Dec 2006, Fred Baker wrote:
> On Dec 9, 2006, at 5:55 PM, [e-mail] wrote:
>> 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 ..."

Mohan or Richard, could you clarify this?  I thought the idea was that 
RFC2401 does not explicitly mention IP as the possible next layer 
protocol, while many implementations do support it (and we aren't quite 
sure whether such support is mandatory-to-implement)?  On the other hand 
RFC4301 explicitly requires support for all next layer protocol values.

Maybe we forgot to to reword the text above since this become clearer 
after earlier iterations.  If so, suggestions to reword?

>> 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.

We could easily shuffle the text around a bit.  Now that I read this, only 
the first one seems to be clearly worded as a "requirement" rather than a 
general observation.  While the third one needs clarification (Mohan?), 
only the first one (IMHO) can easily be expanded why that is so:

    1.  All of IPv6 traffic should be protected, including link-local
        (e.g., Neighbor Discovery) and multicast traffic.

    2.  In router-to-router tunnels, the source and destination addresses
        of the traffic could come from a wide range of prefixes that are
        normally learned through routing.  As routing can always learn a
        new prefix, there is no way to know all the prefixes a priori
        [RFC3884].

    3.  Source address selection depends on the notions of routes and
        interfaces.  This affects scenarios (2) and (3).

1) is required so that every form of traffic that is supported by RFC4213 
IPv6-in-IPv4 tunnels is supported.  A more general explanation is 
mentioned in 2nd paragraph of Section 6 (in effect, "we want link local, 
e.g., routing protocols, multicast, etc.") but it doesn't mention why we 
want them (explanation above).  On the other hand Appendix A describes the 
tunnel mode setup if this is not felt to be a requirement and Tunnel mode 
is felt better in the particular scenario.

As for 3), I'm not 100% sure what point it wants to convey and how it's 
relevant here (does that refer to a multihomed endpoint with multiple 
addresses?) Mohan?

Pekka


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