Re: Review of Keyed IPv6 Tunnel [draft-mkonstan-keyed-ipv6-tunnel-00]

Thanks, Maciek. Please submit a new revision now that the ID submission
tool opens on Monday.

Thanks,

‹ Carlos.

On 11/2/13, 8:54 PM, "Maciek Konstantynowicz (mkonstan)"
<[email protected]> wrote:

>Carlos,
>
>Thanks for your ack's and comments.
>
>More in line.
>
>On 26 Oct 2013, at 22:15, Carlos Pignataro (cpignata) wrote:
>
>> Hi, Maciek,
>> 
>> Thanks for your response! Please find two follow-ups inline and
>>implicit Ack for all the rest.
>> 
>>> On Oct 16, 2013, at 6:02 PM, "Maciek Konstantynowicz (mkonstan)"
>>><[email protected]> wrote:
>>> 
>>> Carlos,
>>> 
>>> Sorry, took a while to get back to you..
>>> 
>>> Many thanks for your comments. See inline.
>>> 
>>>> On 15 Aug 2013, at 21:13, Carlos Pignataro (cpignata) wrote:
>>>> 
>>>> Hi, Rainer, Giles, Maciek, Mark,
>>>> 
>>>> After the presentation of this draft in Berlin at the PWE3 meeting
>>>>(with thanks to the PWE3 chairs!) available at
>>>>http://tools.ietf.org/agenda/87/slides/slides-87-pwe3-2.pdf, I wanted
>>>>to provide some review comments with the chair hat off.
>>>> 
>>>> I hope these are useful and clear, they are prefaced with "CMP"
>>> 
>>> All useful and clear - thanks for your review !
>>> 
>>>> 
>>>> 
>>>> http://tools.ietf.org/html/draft-mkonstan-keyed-ipv6-tunnel-00
>>>> 
>>>> Network Working Group                                      R.
>>>>Schatzmayr
>>>> Internet-Draft                                       Deutsche Telekom
>>>>AG
>>>> Intended status: Informational                             G. Heron,
>>>>Ed.
>>>> 
>>>> CMP: I do not think that the intended status of this document should
>>>>be Informational, as you are proposing protocol changes.
>>>> 
>>>> 
>>>> Abstract
>>>> 
>>>> This document describes a simple L2 Ethernet over IPv6 tunnel
>>>> encapsulation with mandatory 64-bit authentication key for connecting
>>>> L2 Ethernet attachment circuits identified by IPv6 addresses.  The
>>>> encapsulation is based on L2TPv3 over IP.
>>>> 
>>>> and 
>>>> 
>>>> 3.  64-bit Authentication Key
>>>> 
>>>> All packets MUST carry a 64-bit authentication key in the L2TPv3
>>>> 
>>>> CMP: a cookie does not provide an authentication key. It is a simple
>>>>context lookup check.
>>> 
>>> Indeed the key in the cookie field is used for additional context
>>>check and to prevent spoofing and brute-force insertion attacks in line
>>>with RFC3931.
>>> 
>>> Will correct the current text and align with RFC3931.
>>> 
>>>> 
>>>> 1.  Introduction
>>>> 
>>>> CMP: It might be useful to mention in the introduction that there is
>>>>precedence with proposals to do away with the session id lookup when
>>>>considered redundant, as for example with draft-ietf-l2tpext-l2tphc.
>>> 
>>> Agree. Will add reference to draft-ietf-l2tpext-l2tphc.
>>> 
>>>> 
>>>> 
>>>> 2.  Static 1:1 Mapping Without a Control Plane
>>>> 
>>>> Use of the L2TPv3 Control Plane is optional.  When the control plane
>>>> is not used, local configuration creates a one-to-one mapping between
>>>> the access-side L2 attachment circuit and the IP address used in the
>>>> network-side IPv6 encapsulation.
>>>> 
>>>> CMP: I am not sure I understand how it would work *with* the L2TPv3
>>>>Control Plane. Instead of saying that it is optional, I would say that
>>>>it is out of scope or similar, and this behavior is specified for
>>>>static sessions only. Optional means it can be used, and they you
>>>>would have to say "how" (which new AVPs, etc).
>>> 
>>> Agree. The intention here is to use static tunnels mapping.
>>> Will update draft text accordingly.
>>> 
>>>> 
>>>> Further, circuit monitoring is
>>>> performed using Ethernet OAM mechanisms (802.1ag and/or Y.1731).
>>>> 
>>>> CMP: Why Ethernet OAM and not L2TPv3/PW OAM? e.g., [RFC 5085].
>>> 
>>> Based on feedback from network operators to keep things simple and
>>>universal, with consistent tooling :)
>>> 
>>> Most / all implementations of L2TPv3 / PW support Ethernet OAM with
>>>maintenance points at the tunnel endpoints, so it makes sense to use it
>>>to provide actual payload based connectivity verification.
>>> Transport connectivity verification is achieved using IPv6 toolset.
>>> 
>> 
>> Simple and universal is great. Using Ethernet OAM and IPv6 OAM are fine
>>for checking the AC and the PSN respectively -- but not the PW itself.
>>I'd explain this with more details than a single-liner.
>
>The idea is to use EOAM not only for AC connectivity verification, but
>also across the tunnel with UP MEPs placed at ACs. But I realized we
>didn't include this explicitly in the text.
>Will add in next rev.
>
>Hopefully this makes sense.
>
>> 
>>>> 
>>>> In the event that an IPv6 address used in L2TPv3 does not directly
>>>> correspond to one and only one attachment circuit on both sides of
>>>> the L2TPv3 tunnel, the Session ID may be used for additional
>>>> granularity.  This allows for other addressing schemes that may
>>>> require additional bits beyond those which can fit in the IPv6 header
>>>> address field.
>>>> 
>>>> CMP: Assuming there are some gains in processing the session context
>>>>from the IPv6 address instead of the session id, which could be
>>>>described, is that lost with this last paragraph? Why have both?
>>> 
>>> The idea here was to provide compatibility with existing RFC3931
>>>implementations.
>>> 
>> 
>> This is interesting. Perhaps the last sentence could be expanded into a
>>subsection explaining this backward compat.
>
>Ack. Will expand in the next rev.
>
>Thanks,
>Maciek.
>
>> 
>> Thanks!
>> 
>> Carlos. 
>> 
>>>> 
>>>> 
>>>> 4.  Encapsulation
>>>> 
>>>> o  Session ID.  In the "Static 1:1 mapping" case described in
>>>>    Section 2, the IPv6 address resolves to an L2TPv3 session
>>>>    immediately, thus the Session ID may be ignored upon receipt.  For
>>>>    compatibility with other tunnel termination platforms supporting
>>>>    only 2-stage resolution (IPv6 Address + Session ID), this
>>>>    specification recommends supporting explicit configuration of
>>>>    Session ID to any value other than zero.  For cases where both
>>>>    tunnel endpoints support one-stage resolution (IPv6 Address only),
>>>>    this specification recommends setting the Session ID to all ones
>>>>    for easy identification in case of troubleshooting.
>>>> 
>>>> CMP: Could you add that it is non-zero?
>>> 
>>> Yes, will add.
>>> 
>>>> 
>>>> 8.2.  Informative References
>>>> 
>>>> 
>>>> 
>>>> [RFC1700]  Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
>>>>            October 1994.
>>>> 
>>>> CMP: THis reference is not cited in the doc, please remove.
>>> 
>>> Yes, will remove the reference.
>>> 
>>> Thanks,
>>> Maciek.
>>> 
>>>> 
>>>> 
>>>> Thanks,
>>>> 
>>>> -- Carlos.
>>> 
>