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

Bob Briscoe <ietf@bobbriscoe.net> Thu, 01 June 2017 13:09 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 9024112EC34 for <l2tpext@ietfa.amsl.com>; Thu, 1 Jun 2017 06:09:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 zGJtvECPW14l for <l2tpext@ietfa.amsl.com>; Thu, 1 Jun 2017 06:09:08 -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 380E312EC35 for <l2tpext@ietf.org>; Thu, 1 Jun 2017 06:09:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:References:Cc:To:From:Subject:Sender :Reply-To: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=q6xv70Pk9bRS+JmqPk3OlrVWM/J8D4FWUIsT6tEX3e0=; b=5sltv4K4F7SAyh3zrDw4Ms4Ww0 Qp6NduLvpyiFTaT1HSrvGL5JKKYJLOqIeFLs0Xb4HSEMgYOfCys7YZSkqcf62aw6c/HEzzBQiQLx9 1wYlf4A0cb1djypBIZDp0ymWmAT7W+d2JKj93uvRGLSCgEqt8cSxCioXhVZ9hFz06n7PFFmehdZpc JH+9xdFadG9yWqwUEggpp09Vwl0oyc+P660hdV0HrHllZfGn9puITWhC+pDPUdeXHvp9x9BQQjqMQ rZbIEbAx38R7YAHFbj9AExOswK5B4uYlGVt6qiM5qkL9OOpdiddYGr/5kdrPoa3AnBEZN3Og18XLM kotgHdag==;
Received: from [31.185.135.175] (port=58824 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 1dGPqb-0007ya-M4; Thu, 01 Jun 2017 14:09:05 +0100
From: Bob Briscoe <ietf@bobbriscoe.net>
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> <201705312359.v4VNxHEU008912@cliff.eng.ascend.com> <096cc75b-0bfd-e2ec-d3a5-6b182040ff5a@bobbriscoe.net>
Message-ID: <a0803c13-c095-4250-227d-c1967d11f095@bobbriscoe.net>
Date: Thu, 1 Jun 2017 14:09:05 +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: <096cc75b-0bfd-e2ec-d3a5-6b182040ff5a@bobbriscoe.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
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/cOLjCrHVdN5a366NZXOWiuLEu4c>
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: Thu, 01 Jun 2017 13:09:10 -0000

Ignacio,

I realized that my previous email may have come across as critical of 
L2TP implementers that don't already comply with RFC6040. No criticism 
was intended - it is not at all easy to determine which specs to follow 
- one reason for this clarifying draft.

I've also corrected one sentence below...

On 01/06/17 05:02, Bob Briscoe wrote:
> Ignacio,
>
> On 01/06/17 00:55, Ignacio Goyret wrote:
>> At 15:11 5/31/2017, Bob Briscoe wrote:
>>
>>>> I do not understand however why "Update", or what that implies to
>>>> a compliant implementation. Many features of L2TP are specified in
>>>> various WGs, not "Updating" the base specs.
>>>>
>>> By my understanding of the word extension, if a implementation that
>>> is compliant with RFC3931 does not implement an extension, it is
>>> still compliant with RFC3931. Is this how the word "extension" is
>>> used in L2TP land?
>>>
>>> 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'm not sure you will get much traction for a "mandatory" update
>> because it would immediately invalidate any compliant deployed code
>> out there.
> I'm not asking for permission to make something mandatory. RFC6040 (or 
> its predecessors {Note 1}) is already mandatory.
> draft-ietf-tsvwg-rfc6040update-shim is just the "messenger", telling 
> L2TP implementers that RFC6040 is already mandatory.
>
> A mandatory update wouldn't invalidate any compliant deployed code, 
> because the only way that deployed code could be compliant would be to 
> already comply with RFC6040 or its predecessors. There is no other RFC 
> that says how to construct an ECN field during tunnelling. The 
> standards track predecessors of RFC6040 pre-dated L2TPv3 by 3.5 years. 
> And the experimental track predecessor of ECN tunnelling pre-dated 
> L2TPv2.
>
> The ECN field is in the main IP header (v4 and v6). It cannot be 
> omitted. When an L2TPv3 implementation creates an outer IP header 
> during encap, or forwards an IP header after decap, it has to set the 
> new ECN fields to some value. One would hope that an implementer would 
> try to find a spec to follow, rather than guessing this value. There 
> is only one RFC that says how to construct the ECN field during 
> tunnelling (RFC6040 or its predecessors). If an implementer has not 
> complied with one of these, she has not complied with the Internet 
> Protocol.
>
> draft-ietf-tsvwg-rfc6040update-shim is not changing the technical 
> effect of the ECN tunnelling spec [RFC6040]. All it is really doing is:
>
> a) Typing "Updates: 3931" at the top of a proposed RFC. This would 
> ideally have been typed at the top of the original ECN RFC [RFC3168]. 
> This flags to L2TP implementers that they need to take note of the 
> standards track update to IP tunnelling that happened in 2001. 
> Because, like you say, real life dictates there will be some L2TP 
> implementations that don't do it right.
>
> b) and helping to do it right, by providing the L2TP negotiation 
> machinery (that is also already mandatory for any tunnelling of IP in 
> IP).
>
>
> {Note 1}: The predecessors of RFC6040 are RFC3168 and RFC4301. They 
> all have the same technical effect - the deltas between them merely 
> altered trivia like handling combinations of ECN fields that wouldn't 
> normally be expected and other tinkering round the edges.
>
>> This goes back to the question of why negotiate it if it is mandatory.
>
> The standards action that is mandatory is compliance with RFC6040, 
> which made it mandatory to negotiate (or use configuration).
>
> Specifically, RFC6040 made it mandatory for a tunnel ingress to check 
> for (or be configured for) whether the egress supported ECN decap. In 
> the predecessors to RFC6040, negotiation was only specified for IPsec. 
> The only other type of tunnel considered was an RFC2003 tunnel, where 
> no negotiation of tunnel set up process had been defined, so 
> negotiation wasn't discussed for that case.
[BB adds:] RFC3168 did mention MPLS, GRE, L2TP and PPTP, but just said 
they "will be considered as the need arises"
>
>>
>> Real life says that there will be some L2TP deployments that will
>> support ECN and some that won't, thus, the negotiation is needed
>> to maintain interoperability.
>>
>> But if the negotiation is required, then this can't be an update
>> since it must allow for LCCEs that don't support ECN (which it must,
>> because some deployments may choose (or may have to) stay with
>> their non-ECN supporting code for a variety of reasons).
>
> As above, the update is to make negotiation mandatory.
>
> I hope this helps clarify.
Cheers



Bob
>
> Cheers
>
>
>
> Bob
>
>>
>> Yes, I know: it is sort of a circular argument but hopefully you
>> see what I mean.
>>
>> -Ignacio
>>
>

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