Re: [L2tpext] Propagating IP/ECN field when L2TP sits between IP as both L2 payload and PSN

Bob Briscoe <ietf@bobbriscoe.net> Fri, 02 June 2017 13:24 UTC

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: l2tpext@ietfa.amsl.com
Delivered-To: l2tpext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD107129B75 for <l2tpext@ietfa.amsl.com>; Fri, 2 Jun 2017 06:24:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level:
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiYCAxLPpQAi for <l2tpext@ietfa.amsl.com>; Fri, 2 Jun 2017 06:24:02 -0700 (PDT)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3638A126DCA for <l2tpext@ietf.org>; Fri, 2 Jun 2017 06:24:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=NRCinc/Fn1UNrt6dPiIRe6gVZnmI0sqMpkDQBqPfTLE=; b=7k4q70FJtEdK2jLPeMvo0M2Bt 9t2tucrm8MTeTN71BOoLLqOwq4Es1lm8DW4/RhHrdeel9Cvo/geA8RV75iKup6pncP55/AuVMZzGn D1pnF/RXmrnYOGAfE03GeqEEGwpdrjZ7pT1BQmX9bbhmUaVnEnzCLnbnMv/4o22swNQEKqm39bjQX SHwvBj9pXAQrly48XdIeJgDA2GZUSFE93OYN3LdKxt480Y/ANnKJiildSPsUsIQ2rTm6ZZmICLugs WIzevuTri1cymHOGGlp8PtpX25UxsA27U4EgxMoy2Zi27q+TSk9FM6A+lq2n1iEs25jeIOMHyfAW/ tCzFxoHkA==;
Received: from 110.139.199.146.dyn.plus.net ([146.199.139.110]:33590 helo=[192.168.0.2]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from <ietf@bobbriscoe.net>) id 1dGmYZ-0000Eq-Ic; Fri, 02 Jun 2017 14:23:59 +0100
To: Ignacio Goyret <ignacio.goyret@nokia.com>
Cc: "Black, David" <david.black@emc.com>, l2tp IETF list <l2tpext@ietf.org>
References: <149618019740.19809.6421141487388928973.idtracker@ietfa.amsl.com> <435f45b8-9659-b06f-9adc-415f355ba743@bobbriscoe.net> <e4c97c52-36c9-3091-b005-06ef82ec58e3@bobbriscoe.net> <201705310154.v4V1sYQH013223@cliff.eng.ascend.com> <67456091-a3e0-2db1-5f8a-5210a1f870f1@bobbriscoe.net> <B00A6885-6EB1-4361-8412-C408F23DC5E0@cisco.com> <70866121-f350-d6d2-d89a-89ca1315f5ab@bobbriscoe.net> <31104AD6-BE38-45D1-A148-67DF4D73529C@cisco.com> <201706012026.v51KQpdI002347@cliff.eng.ascend.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <c4aeeafa-1f6b-afa9-4599-2a747259be22@bobbriscoe.net>
Date: Fri, 2 Jun 2017 14:23:59 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <201706012026.v51KQpdI002347@cliff.eng.ascend.com>
Content-Type: multipart/alternative; boundary="------------5702327C13CE5A71D7068A8B"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/l2tpext/FTV_6uJ-zFxULwemqSa8Kp6MoTc>
Subject: Re: [L2tpext] Propagating IP/ECN field when L2TP sits between IP as both L2 payload and PSN
X-BeenThere: l2tpext@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Layer Two Tunneling Protocol Extensions <l2tpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2tpext>, <mailto:l2tpext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/l2tpext/>
List-Post: <mailto:l2tpext@ietf.org>
List-Help: <mailto:l2tpext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2tpext>, <mailto:l2tpext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Jun 2017 13:24:05 -0000

Ignacio,

RFC6040 contains the following para:

    If an ingress claims compliance with this specification, it MUST NOT
    permanently disable ECN processing across the tunnel (i.e., only
    using compatibility mode).  It is true that such a tunnel ingress is
    at least safe with the ECN behaviour of any egress it may encounter,
    but it does not meet the central aim of this specification:
    introducing ECN support to tunnels.

To be safe, an L2TP ingress could permanently use compatibility mode. 
Compatibility mode simply involves the ingress clearing the 2-bit ECN 
field in the outer (setting to 00). This would not allow the L2TP 
endpoint to claim compliance with RFC6040, but at least it would be 
safe. I think it would be useful to add this as operational advice to 
draft-ietf-tsvwg-rfc6040shim-update.

I would imagine most implementations of L2TP could be configured to do 
this (do you agree?). I suspect some still allow config of the setting 
the whole 8-bit ToS bytes, in which the 2 lowest significant bits are 
the ECN field (distinct from the 6-bit Diffserv field).


Nonetheless, altho safety is important, the main purpose of this draft 
is to go beyond that - to say how an implementer would add ECN support 
to L2TP. See inline...

On 01/06/17 21:24, Ignacio Goyret wrote:
>>> Whereas, if one IP header encapsulates another, if the ECN field
>>> were processed in any way other than RFC6040, it would be invalid
>>> (unless another RFC were written to update RFC6040). Therefore,
>>> whenever L2TP is tunnelling IP in IP, it is mandatory to comply
>>> with RFC6040. So I am asking the L2TPext WG for advice on how you
>>> guys would make a mandatory update to L2TP, rather than 'just' an
>>> optional extension.
>>>
>> I think first we probably need to understand the applicability because
>> it is not an IP-in-IP encap, there's a Layer 2 header in between, not
>> tightly coupled but rather part of the transported payload.
> And an IP header (if present) may be down various layers and not easily
> accessible.
>
> So far, LCCEs do not need to decapsulate all the stacked layers trying
> to look for a potential IP header. Adding that requirement as a MUST is
> a tall order that may be too onerous and impossible to satisfy.

As recently discussed on int-area, I am going to widen the applicability 
of draft-ietf-tsvwg-rfc6040shim-update to include cases where a L2 
header is being encapsulated. But this wider scope would not be as 
mandatory.

I definitely do not want to make this a MUST. I made this point myself, 
in response to Tom Herbert on the int-area list a couple of days ago, 
pasted here:

> On 31/05/17 02:45, Bob Briscoe wrote:
>> One way to include all these cases in the scope of the draft is to 
>> say the tunnel endpoint SHOULD check the L2 payload for an IP header, 
>> even when the L2 header is not being added / removed. But that is 
>> rather an onerous requirement, don't you think? Especially given this 
>> would be asking the implementer to violate layering, we can only ask 
>> that it is done when feasible; it cannot be a hard requirement (e.g. 
>> L2 payload could be encrypted). 

I think MAY is too weak, but SHOULD is too strong, so how about this 
form of wording:
"If feasible, the tunnel endpoint SHOULD check the L2 payload for an IP 
header"

And I intend to add something along the lines of: "Otherwise, if the 
outer is IP, it MUST zero the outer ECN field."

>
>
>> Now, what you describe in terms of level of mandatory applies to RFC 6040.
>> If an implementation does not comply with RFC 6040 it is, well, not
>> compliant with RFC 6040.
> Exactly.
>
> And that's why I believe this should be a _recommended_ extension when
> inner IP headers can be found easily but it cannot be a mandatory
> requirement for the L2TP protocol as a whole.
As above, I strongly agree with you.


Bob

>
> -Ignacio
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/