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, 02 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/
- [L2tpext] Propagating IP/ECN field when L2TP sits… Bob Briscoe
- Re: [L2tpext] Propagating IP/ECN field when L2TP … Ignacio Goyret
- Re: [L2tpext] Propagating IP/ECN field when L2TP … Bob Briscoe
- Re: [L2tpext] Propagating IP/ECN field when L2TP … Carlos Pignataro (cpignata)
- Re: [L2tpext] Propagating IP/ECN field when L2TP … Bob Briscoe
- Re: [L2tpext] Propagating IP/ECN field when L2TP … Ignacio Goyret
- Re: [L2tpext] Propagating IP/ECN field when L2TP … Bob Briscoe
- Re: [L2tpext] Propagating IP/ECN field when L2TP … Bob Briscoe
- Re: [L2tpext] Propagating IP/ECN field when L2TP … Carlos Pignataro (cpignata)
- Re: [L2tpext] Propagating IP/ECN field when L2TP … Ignacio Goyret
- Re: [L2tpext] Propagating IP/ECN field when L2TP … Bob Briscoe
- Re: [L2tpext] Propagating IP/ECN field when L2TP … Bob Briscoe
- Re: [L2tpext] Propagating IP/ECN field when L2TP … Bob Briscoe