Re: [tsvwg] New Version of draft-ietf-tsvwg-transport-encrypt (12)

Gorry Fairhurst <> Mon, 16 March 2020 17:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E1E1D3A0DB8 for <>; Mon, 16 Mar 2020 10:23:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TbFOACRLNaY3 for <>; Mon, 16 Mar 2020 10:23:55 -0700 (PDT)
Received: from ( [IPv6:2001:630:42:150::2]) by (Postfix) with ESMTP id C5A723A0DDE for <>; Mon, 16 Mar 2020 10:23:54 -0700 (PDT)
Received: from GF-MacBook-Pro.local ( []) by (Postfix) with ESMTPSA id 5145B1B0009C; Mon, 16 Mar 2020 17:23:50 +0000 (GMT)
To: Tom Herbert <>
Cc: Eric Rescorla <>, "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Gorry Fairhurst <>
Message-ID: <>
Date: Mon, 16 Mar 2020 17:23:49 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: <>
Subject: Re: [tsvwg] New Version of draft-ietf-tsvwg-transport-encrypt (12)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Mar 2020 17:24:07 -0000

Tom, please comment on David's proposed text - he's the shepherd for 
this WG document, and it would be useful to know you thoughts.


On 16/03/2020 17:21, Tom Herbert wrote:
> On Mon, Mar 16, 2020 at 10:10 AM Gorry Fairhurst <> wrote:
>> On 16/03/2020 16:28, Tom Herbert wrote:
>>> On Mon, Mar 16, 2020 at 8:54 AM Gorry Fairhurst <> wrote:
>>>> On 16/03/2020 15:21, Tom Herbert wrote:
>>>> On Mon, Mar 16, 2020 at 7:52 AM Gorry Fairhurst <> wrote:
>>>> On 16/03/2020 13:06, Eric Rescorla wrote:
>>>> On Mon, Mar 16, 2020 at 2:36 AM Gorry Fairhurst <> wrote:
>>>> Ekr,
>>>> On 15/03/2020 13:19, Eric Rescorla wrote:
>>>> Let me try to expand my point a bit.
>>>> Longstanding practice is for entities in the middle of the network to
>>>> use signals that were intended for the endpoint for their own
>>>> purposes.  With QUIC (and a lesser extent SCTP/DTLS), those signals
>>>> are being encrypted and thus unavailable to those non-endpoint
>>>> entities; this draft is mostly devoted to documenting the negative
>>>> impact of that change on the operations of those entities.
>>>> I disagree that this is "documenting the negative impact of that change".
>>>> The draft is about how this protocol information has and is being used. As long as I can remember, there has been devices that utilise some of this information, at the edge of an enterprise there is often at least one device with this role; within a managed network there are devices; etc. If the trend to use encrypted methods continues, some of these practices need to be re-assessed, and the functions more widely understood than in an era when nearly everything was thought to be TCP or "multimedia".
>>>> I'm not sure what you're arguing here. What I said above is that
>>>> this draft was "mostly devoted to documenting the negative
>>>> impact of that change on the operations of those entities."
>>>> In other words, it lists a bunch of things that people do now
>>>> that will stop working. Do you not think that much of the
>>>> material in this draft is of that form?
>>>> -Ekr
>>>> So the conclusion, para 2 states:
>>>> "   This document has described some current practises, and the
>>>>      implications for some stakeholders, when transport layer header
>>>>      encryption is used.  It does not judge whether these practises are
>>>>      necessary, or endorse the use of any specific practise.
>>>> Gorry,
>>>> Section 5.2 states:
>>>> "Current measurement results suggest that it could currently be
>>>> undesirable to rely on methods requiring end-to-end support of network
>>>> options or extension headers across the Internet."
>>>> That _is_ a subjective judgment
>>>> That would be better to reference 6Man debate - however, the words are chosen carefully: "to rely upon ... across the Internet"
>>>> Prievously David suggested to you:
>>>> "Additional considerations apply to use of methods requiring end-to-end support of network options or extension headers across the Internet.  IPv4 network options may not be supported (or may utilize a slower processing path) and some IPv6 networks have been observed to drop npackets that set an IPv6 header extension (e.g., results from 2016 in    [RFC7872])."
>>>> - if you think that needs more explanation, we could perhaps expand a little more about the IETF view on this, please suggest an alternative.
>>> Gorry,
>>> It's not clear to me what the intent is here. If the intent is to
>>> suggest that extension headers should be evaluated as a potential
>>> alternative then I think there should be some discussion on how they
>>> could work for exposing transport layer information and what the
>>> benefits are. AFAIK, extension headers are the _only_ protocol
>>> conformant method there is to expose arbitrary information to networks
>>> which would include transport layer information-- that should be
>>> mentioned.
>> This was discussed on the TSVWG list, and at the time we decided not to
>> speculate on new methods not currently deployed.
> Gorry,
> But that's exactly what the draft is doing wrt extension headers. IMO
> either this topic needs to be given more balanced discussion about the
> possibility of using the mechanism, or all discussion about it should
> be removed from the draft in the spirit that the draft is not making
> recommendations or judgments about alternatives.
> Tom
>>> Also, there is one question that really needs to be
>>> addressed and is mostly ignored by this draft: what specific transport
>>> information do networks needs and when do they need?
>> That's a good question. It's not this draft's remit.
>>> It should be
>>> obvious that even if hosts or applications are willing to expose
>>> transport layer information then they'll want to do that very
>>> selectively. Some data might be appropriate to expose, some not. There
>>> needs to be a lot more discussion on this.
>> Indeed.
>>> As for extension headers being dropped by some networks, that is true.
>>> But that is not the same thing as saying they are undesirable and that
>>> the problems, some of which are caused by the very network devices
>>> that might need the transport information, can't be fixed. Besides,
>>> extension headers are the first protocol that are dropped by networks,
>>> even just a couple of years ago IPv6 was also commonly dropped by a
>>> lot of networks, but that wasn't a reason for IETF to stop working on
>>> it. IMO, instead of accepting protocol ossification, we should fix it
>>> or work around it.
>>> Tom
>> I suggest we add a little to the text David' proposed and also cite the
>> references to uses of ext headers?
>> Gorry
>>>> (Editor-hat off: I'm pretty sure Extension Headers are viable in some places, and not currently in other places, expecting this to work end-to-end could be unduly pessimistic. Anticipating this would never work would be wrong also.)
>>>>    about a technique that is not
>>>> currently used with little discussion on why they're undesirable or
>>>> what needs to be done to make them desirable.  As I've said before, I
>>>> think the document is too easily dismisses this alternative.
>>>> You think this dismissses this? I don't believe that was an intent. Would it help to suggest text that includes: RFC6564
>>>> or perhaps: {RFC8250; draft-ietf-ippm-ioam-ipv6-options; draft-ietf-6man-segment-routing-header}?
>>>> If the
>>>> point of this document is to describe the implications of transport
>>>> header encryption without any diligent consideration of alternatives
>>>> to expose the necessary transport information to the network, then I
>>>> suggest that the discussion of extension headers and other
>>>> alternatives should be removed and deferred to other documents.
>>>> Tom
>>>> Gorry
>>>> I agree many existing tools would stop working if IPsec formed the majority of traffic, same for QUIC. I think when considering what to do next, it can be useful to work from the current position and understand the implications of changes that are being proposed/used/whatever.
>>>> At least from my personal position, this document was providing some input to that thinking. So, I do not understand your issue.
>>>> Gorry