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

["Carlos Pignataro (cpignata)" <[e-mail]>]

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)" <[e-mail]> 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. 

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

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