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

From: Eric Rescorla <[email-masked]>
Date: Fri, 13 Mar 2020 09:20:12 -0700

Document: draft-ietf-tsvwg-transport-encrypt-12.txt

I more or less concur with David's comments.

First, it's really not clear what purpose this document serves.  While
superficially an analysis of the impact of transport layer encryption
as a guide to designers, in the context of the design and deployment
of QUIC and SCTP/DTLS, both of which encrypt most or all of the
transport header, it's hard not to read this document as an implicit
critique of those decisions. It's not like there's some other big
transport protocol design effort going on in IETF that would be
informed by these considerations.

With that said, I don't think we should neutral on this topic: the
last two newish transport protocol stacks that the IETF has designed
(SCTP/DTLS and QUIC) both incorporate transport header encryption and
I haven't heard anyone propose that we design a new protocol without
that, so I think any document that we publish should state that this
is a good thing while also documenting the challenges it creates.

However, this document isn't really even neutral: it spends vastly
more time on the negative impacts to non-endpoint network actors than
it does on the benefits to the endpoints, and while it does
acknowledge those benefits, they are often framed in a sort of "people
say" framing, which isn't really applied to the practices which are
negatively impacted, which are largely taken at face value. Compare
the following passages:

   o  One motive to encrypt transport headers is in response to
      perceptions that the network has become ossified, since traffic
      inspecting middleboxes prevent new protocols and mechanisms from
      being deployed.  One benefit of encrypting transport headers is
      that it can help improve the pace of transport development by
      eliminating interference by deployed middleboxes.

and:

   In some cases, network-layer use of transport header information can
   be benign or advantageous to the protocol (e.g., recognising the
   start of a TCP connection, providing header compression for a Secure
   RTP flow, or explicitly using exposed protocol information to provide
   consistent decisions by on-path devices).  Header compression (e.g.,
   [RFC5795]) depends understanding of transport header and the way
   fields change packet-by-packet; as also do techniques to improve TCP
   performance by transparent modification of acknowledgement traffic
   [RFC3449].  Introducing a new transport protocol or changes to
   existing transport header information prevent these methods being
   used or require the network devices to be updated.

In the first passage, the use "in response to perceptions" creates
the impression that ossification is just some people's opinion,
whereas it seems to me that it is a commonly understood fact of
the network that has been an obstacle to deployment of everything
from DNSSEC to TLS 1.3. By contrast, the second passage implies
that tampering with acknowledgments is "benign or advantageous"
when there is actually quite a bit of debate about whether
this is a good idea (although I recognize that you are citing
a BCP which recommends it).

A second way in which this document is non-neutral is that it focuses
largely on network-side interventions which seem to be well-intended
(i.e., the operator is attempting to serve the users
interests). However, there are also a wide variety of interventions
which are adverse to the users interests (e.g., RST spoofing, as is
done by the Great Firewall [0]). By focusing on the downsides of encryption
while minimizing the harms that encryption is intended to prevent
this document again comes off as largely a critique of transport
layer encryption in general.

For these reasons, I don't think that this document should be published
without extensive revision.

-Ekr

[0] https://www.cl.cam.ac.uk/~rnc1/ignoring.pdf

On Thu, Feb 27, 2020 at 10:40 AM David Schinazi <[email-masked]>
wrote:

> Hi Gorry,
>
> Thanks for updating the document, and for slightly tweaking the
> tone to focus less strongly on the downsides of transport header
> encryption. It's much appreciated.
>
> However, I'm now pretty confused by the latest version (-12).
> Could you help me answer these two questions please:
> 1) Who is the target audience for this document?
> 2) What should that audience walk away with?
>
> I initially assumed that the answer to (1) was "designers
> of new transport protocols". But considering myself in that
> category, I don't know what I'm supposed to take away
> from the draft. I was expecting the answer to (2) to be
> "you SHOULD or SHOULD NOT encrypt transport protocol
> headers (pick one)" but that's not the case.
>
> Here are excerpts from the draft's Conclusion section:
>
>    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.
>
>    This document does not make recommendations about what
>    information ought to be exposed, to whom it ought to be observable,
>    or how this will be achieved.
>
>    An appropriate balance will emerge over time as real instances
>    of this tension are analysed [RFC7258].
>
> The messages I'm walking away with are:
> A) there is a tension between folks who want to encrypt and
>     folks who don't
> B) we don't have enough information, it's too early to tell what the
>     impact of transport header encryption really is
>
> As such, I'm now more confused than I was before reading the
> draft, as it doesn't help me answer the question of "when designing
> a new transport protocol, should I be encrypting my transport
> headers or not?".
>
> I personally oppose publication of the document as it stands,
> because I find it confusing and non-actionable. I would like to see
> this useful content in a BCP document once we have enough
> information to actually recommend something.
>
> Thanks,
> David
>
> On Thu, Feb 27, 2020 at 1:09 AM Gorry Fairhurst <[email-masked]>
> wrote:
>
>> The editors have just uploaded a new revision of
>> draft-ietf-tsvwg-transport-encrypt following review comments. We are not
>> aware of further review comments and now think that this new version is
>> now ready to proceed.
>>
>> Best wishes,
>>
>> Gorry and Colin
>>
>> ---
>> A new version of I-D, draft-ietf-tsvwg-transport-encrypt-12.txt
>> has been successfully submitted by Godred Fairhurst and posted to the
>> IETF repository.
>>
>> Name: draft-ietf-tsvwg-transport-encrypt
>> Revision: 12
>> Title: Considerations around Transport Header Confidentiality, Network
>> Operations, and the Evolution of Internet Transport Protocols
>> Document date: 2020-02-26
>> Group: tsvwg
>> Pages: 48
>> URL:
>>
>> https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-transport-encrypt-12.txt
>> Status:
>> https://datatracker.ietf..org/doc/draft-ietf-tsvwg-transport-encrypt/
>> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/>
>> Htmlized:
>> https://tools.ietf.org/html/draft-ietf-tsvwg-transport-encrypt-12
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-transport-encrypt
>> Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-transport-encrypt-12
>>
>> Abstract:
>> To protect user data and privacy, Internet transport protocols have
>> supported payload encryption and authentication for some time. Such
>> encryption and authentication is now also starting to be applied to
>> the transport protocol headers. This helps avoid transport protocol
>> ossification by middleboxes, while also protecting metadata about the
>> communication. Current operational practice in some networks inspect
>> transport header information within the network, but this is no
>> longer possible when those transport headers are encrypted. This
>> document discusses the possible impact when network traffic uses a
>> protocol with an encrypted transport header. It suggests issues to
>> consider when designing new transport protocols, to account for
>> network operations, prevent network ossification, enable transport
>> evolution, and respect user privacy.
>>
>>

---

From: Martin Duke <[email-masked]>
Date: Fri, 13 Mar 2020 09:36:43 -0700

(With all hats off)

ekr,

I don't think the encrypt-or-don't decision is as binary as you suggest.
Today, QUIC implementers can decide whether or not they will implement the
spin bit. As you well know, QUIC loss bits are potentially coming down the
way and this draft, in some form, may inform that discussion.

I'll abstain from any position on the tone of the document until I have a
chance to re-read it.

Martin

On Fri, Mar 13, 2020 at 9:21 AM Eric Rescorla <[email-masked]> wrote:

> which are adverse to the users interests (e.g.., RST spoofing, as is
>>> https://datatracker.ietf...org/doc/draft-ietf-tsvwg-transport-encrypt/

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 13 Mar 2020 09:40:47 -0700

> way and this draft, in some form, may inform that discussion.

Perhaps, but what fraction of the practices in this document would be
enabled by even the loss bits?

-Ekr

---

From: Martin Duke <[email-masked]>
Date: Fri, 13 Mar 2020 10:30:22 -0700

I have no idea, but the draft isn't meant to be a point solution to loss
bits. I suspect loss bits are not the last time someone will want to expose
more info.

On Fri, Mar 13, 2020 at 9:41 AM Eric Rescorla <[email-masked]> wrote:

>>> On Thu, Feb 27, 2020 at 10:40 AM David Schinazi <
>>> [email-masked]> wrote:
>>>
>>>> Hi Gorry,
>>>>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 15 Mar 2020 06:19:04 -0700

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.

As I indicated in my review, I'm not aware of any significant new
transport protocol that doesn't have this property. It's true that
some protocols (QUIC, primarily) are deliberately exposing some
information in the clear, but they're not doing it by not encrypting
signals intended for the endpoint. Rather, as contemplated by RFC
8558, they are adding *extra* signals, such as the spin bit, that are
intended only for the middle (indeed this is what makes them optional
from the endpoint perspective).

-Ekr

On Fri, Mar 13, 2020 at 10:30 AM Martin Duke <[email-masked]>
wrote:

>>> I'll abstain from any position on the tone of the document until I have
>>> a chance to re-read it.
>>>
>>> Martin
>>>

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 16 Mar 2020 09:19:11 +0000

Catching-up just on the following: We could strongly agree that 
ossification is an impediment about which there has been a general 
growing awareness. I do not mind changing the words here at all:

> whereas it seems to me that it is a commonly understood fact of

e.g.:

OLD:

       One motive to encrypt transport headers is in response to
       perceptions that the network has become ossified, since traffic
       inspecting middleboxes prevent new protocols and mechanisms from
       being deployed.

NEW:

       One motive to encrypt transport headers is in response to
       growing awareness of the implications of network ossification 
from traffic
       inspecting middleboxes that prevent new protocols and mechanisms from
       being deployed.

... or make a suggestion?

Gorry

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 16 Mar 2020 09:36:27 +0000

Ekr,

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

There has additionally also long been a viewpoint that transport layer 
information should not have only been used end to end. IPSec in the 
past, QUIC now, provide protocols that match that view. This is not that 
document.

> from the endpoint perspective).
I like the IAB contributing documents like this, but it's information to 
help see a view of the future. I hope RFC 8558 provides useful input to 
this. This is not that document, either.

Personally, I'd be keen to see clearer differentiation about what 
infromation is to be used in what way - whether this is below or at the 
transport.

Hope that helps explain a little,

Gorry

>
> On Fri, Mar 13, 2020 at 10:30 AM Martin Duke <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I have no idea, but the draft isn't meant to be a point solution
>     to loss bits. I suspect loss bits are not the last time someone
>     will want to expose more info.
>
>     On Fri, Mar 13, 2020 at 9:41 AM Eric Rescorla <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>
>         On Fri, Mar 13, 2020 at 9:36 AM Martin Duke
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>             (With all hats off)
>
>             ekr,
>
>             I don't think the encrypt-or-don't decision is as binary
>             as you suggest. Today, QUIC implementers can decide
>             whether or not they will implement the spin bit. As you
>             well know, QUIC loss bits are potentially coming down the
>         Perhaps, but what fraction of the practices in this document
>         would be enabled by even the loss bits?
>
>         -Ekr
>
>
>             I'll abstain from any position on the tone of the document
>             until I have a chance to re-read it.
>
>             Martin
>
>             On Fri, Mar 13, 2020 at 9:21 AM Eric Rescorla
>             <[email-masked] <mailto:[email-masked]>> wrote:
>
>                 On Thu, Feb 27, 2020 at 10:40 AM David Schinazi
>                 <[email-masked]
>                 <mailto:[email-masked]>> wrote:
>
>                     Hi Gorry,
>
>                     On Thu, Feb 27, 2020 at 1:09 AM Gorry Fairhurst
>                     <[email-masked]
>                     <mailto:[email-masked]>> wrote:
>
>                         A new version of I-D,
>                         draft-ietf-tsvwg-transport-encrypt-12.txt

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Mar 2020 05:53:47 -0700

> growing awareness. I do not mind changing the words here at all:

This was intended as an example of my concerns, not the totality of them.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Mar 2020 06:06:51 -0700

On Mon, Mar 16, 2020 at 2:36 AM Gorry Fairhurst <[email-masked]>
wrote:

> 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

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 16 Mar 2020 14:51:41 +0000

On 16/03/2020 13:06, Eric Rescorla wrote:
>
>
> On Mon, Mar 16, 2020 at 2:36 AM Gorry Fairhurst <[email-masked] 
>     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".
>
>
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.

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

---

From: Tom Herbert <[email-masked]>
Date: Mon, 16 Mar 2020 08:21:29 -0700

On Mon, Mar 16, 2020 at 7:52 AM Gorry Fairhurst <[email-masked]> wrote:
> On Mon, Mar 16, 2020 at 2:36 AM Gorry Fairhurst <[email-masked]> wrote:
>>
>> Ekr,
>>
>> 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".
>
>
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 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. 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

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Mar 2020 08:33:40 -0700

On Mon, Mar 16, 2020 at 7:51 AM Gorry Fairhurst <[email-masked]>
wrote:

>> As long as I can remember, there has been devices that utilise some of this

I don't really see how this addresses the question we are presently
discussing, which is where I said

"this draft is mostly devoted to documenting the negative
impact of that change on the operations of those entities."

It seems like you disagree with that characterization, but it's not
clear to me why, and this text certainly doesn't address that.

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.
>
Well, it's pretty far upthread, but see the second paragraph of my review:

I'm not really sure how to state this more clearly.

-Ekr

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 16 Mar 2020 15:39:32 +0000

On 16/03/2020 15:33, Eric Rescorla wrote:
>
>
> On Mon, Mar 16, 2020 at 7:51 AM Gorry Fairhurst <[email-masked] 
>>     On Mon, Mar 16, 2020 at 2:36 AM Gorry Fairhurst
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         Ekr,
>>
>>         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".
>>
>>
>     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.
>
Well, thanks for trying. Either we don't understand one another, or we 
differ. Other people have commented in the same thread, and I concur 
with what Spencer said.

Gorry

Also: I will resolve that specific text issue you raised, because that 
was open to very wrong interpretation.

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 16 Mar 2020 15:54:31 +0000

On 16/03/2020 15:21, Tom Herbert wrote:
> 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 ofmethods requiring end-to-end 
support of network options or extension headers across the Internet.  
IPv4network options may not be supported (or may utilize a slower 
processing path) and some IPv6 networks have been observed to 
dropnpackets that set an IPv6 header extension (e.g., results from 2016 
in [RFC7872 <https://tools.ietf.org/html/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.

(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
> 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
Gorry

---

From: Tom Herbert <[email-masked]>
Date: Mon, 16 Mar 2020 09:28:22 -0700

On Mon, Mar 16, 2020 at 8:54 AM Gorry Fairhurst <[email-masked]> wrote:
> That would be better to reference 6Man debate - however, the words are chosen carefully: "to rely upon ... across the Internet"
>
> "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. 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? 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.

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

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 16 Mar 2020 17:09:56 +0000

On 16/03/2020 16:28, Tom Herbert wrote:
> mentioned.

This was discussed on the TSVWG list, and at the time we decided not to 
speculate on new methods not currently deployed.

> Also, there is one question that really needs to be
> information do networks needs and when do they need?
That's a good question. It's not this draft's remit.
> It should be
Indeed.
> it. IMO, instead of accepting protocol ossification, we should fix it
I suggest we add a little to the text David' proposed and also cite the 
references to uses of ext headers?

Gorry

---

From: Tom Herbert <[email-masked]>
Date: Mon, 16 Mar 2020 10:21:25 -0700

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 16 Mar 2020 17:23:49 +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.

Gorry

---

From: Tom Herbert <[email-masked]>
Date: Mon, 16 Mar 2020 11:52:52 -0700

Hi Gorry,

David's text only softens the language that implies extension headers
are not considered a viable option.

May I suggest this text?:

IPv6 Hop-by-Hop options [RFC8200] could be used by hosts to convey and
signal arbitrary information to intermediate network devices. This
potentially includes the ability to selectively expose transport layer
information in network headers that is useful to network node. The use
of Hop-by-Hop options to expose transport information has several
advantages over the practice of extracting information directly from
transport layer headers:

* Hop-by-Hop options work with any transport protocol. Intermediate
nodes do not have to worry about parsing various transport protocols,
they only need to handle the Hop-by-Hop option. This facilitates the
deployment of new transport protocols, use of encrypted transport
protocols, arbitrary encapsulations that contain transport protocols,
etc. This eschews the use Deep Packet Inspection (DPI) since
intermediate devices only neet to process network layer headers
(Hop-by-Hop options immediately follow the IPv6 header).

* Hop-by-Hop options are explicit so that the end host or application
control their content. This means that the user can decide what
transport layer information is exposed and when. For instance, if the
destination of a communication is in the local trusted network then
the user may be willing to expose some transport information per the
network's request in order to receive some tangible benefit, but for
some random destination in the Internet minimal exposure of
information is more likely desired.

* Hop-by-Hop options are the only protocol conformant method to expose
arbitrary information to the network (IPv4 options also are, but they
are too limited). Their design conforms to the end-to-end architecture
of the Internet, and they are robust. Other methods, in particular DPI
to extract information from transport layer headers, are not
conformant nor robust and are a cause of protocol ossification which
is a primary motivation for encrypting transport headers.

Some networks drop extension headers because of non-conformant
intermediate devices. In order to make their use viable, fixes and
workarounds are needed. Once class of workarounds would involving
probing to destinations to deduce what paths are amenable use of
Hop-by-Hop options extension headers (this might be in the same spirit
of Happy Eyeballs for IPv6).

---

From: "Black, David" <[email-masked]>
Date: Wed, 18 Mar 2020 23:06:29 +0000

Hi Tom,
[writing as draft shepherd]

I understand where this is going, but I think that the initial proposed text (below) has gone over to unbalanced in the other direction, and the draft ought to wind up somewhere in the middle.

Here's the TL;DR summary of the two things I would suggest doing next:

[A-Draft authors] Edit draft with a goal of placing roughly equal emphasis on  <selective exposure of information from encrypted transport protocol headers> and <design of new transport protocols> as motivations and intended uses of this draft.  That looks like it will help respond to Ekr's comment.

[B-Tom] Edit/expand final paragraph of new text on network support for IPv6 Hop-by-Hop options to provide more details about what sort of devices are responsible for the observed problems.
----------------------------
In more detail ...backing out to a higher level, the proposed new text articulates three rationales for use of IPv6 Hop-by-Hop options:

	1.  Transport protocol independence.
	2.  Explicit control of exposed content.
	3.  Standards compliance by comparison to alternatives such as IPv4 options and DPI.

Of these three, I view rationale #2 (Explicit control of exposed content) as crucial, because it appears to also be related to Ekr's comment.  Digging into that comment and related discussion, my initial take is that the draft has (in 20/20 hindsight) not paid enough attention to selective exposure of information from encrypted transport protocol headers by comparison to design of new transport protocols.  In particular, I concur with Martin's observation: "I suspect loss bits are not the last time someone will want to expose more info [from QUIC transport headers]." ... and I would still concur even if he weren't an incoming Transport AD ;-).

So, I recommend editing the draft  to better balance <selective exposure of information from encrypted transport protocol headers> as a motivation for the draft with  <design of new transport protocols>.  These changes ought to start early in the draft, e.g., work selective exposure of encrypted header information into the first sentence of this paragraph of the Introduction:

   The direction in which the use of transport header confidentiality
   evolves could have significant implications on the way the Internet
   architecture develops, and therefore needs to be considered as a part
   of protocol design.  This include considering whether the endpoints
   permit network devices to observe a specific field of the transport
   header; whether the devices could modify that field; and whether any
   modification can be detected by the receiving endpoint.

Then, somewhere in or near Section 5 of the draft, it would be useful to add a brief discussion of the possible means of exposing such information.  That would be a good place to deal with transport-independence vs. transport-specificity of exposed information, which encompasses rationale #1, and including IPv6 Hop-by-Hop options [RFC8200] is a fine example of a transport-independent approach. 

Turning to rationale #3, I tend to take a dim view of standards compliance as an end in-and-of itself in a draft like this that has a strong network operational emphasis.  It would be reasonable to explain why the example of IPv6 hop-by-hop options is superior to IPv4 options, but DPI, which often goes well beyond the transport protocol headers, seems beyond the immediate focus of this draft.

One more thing ... the topic of network non-support for extension headers keeps coming up as something that needs carefully crafted text.   Starting from the paragraph proposed below:

I would want to see more details on what sort of non-conformant devices cause problems, in particular routers.  This is because to the extent that routers are responsible, there's a much steeper hill to climb for a good level of support (e.g., reduced likelihood of a Happy Eyeballs approach working well in general).

Thanks, --David

> -----Original Message-----
> From: tsvwg <[email-masked]> On Behalf Of Tom Herbert
> Sent: Monday, March 16, 2020 2:53 PM
> To: Gorry Fairhurst
> Cc: [email-masked]
> Subject: Re: [tsvwg] New Version of draft-ietf-tsvwg-transport-encrypt (12)
> 
> 
> [EXTERNAL EMAIL]
> 
> <[email-masked]> wrote:
> > >>>>
> > >>>> Ekr,
> > >>>>
> 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".
> > >>>>
> > >>>> That would be better to reference 6Man debate - however, the words
> are chosen carefully: "to rely upon ... across the Internet"
> > >>>>
> > >>>> "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])."
> > >>>>
> > >>>>
> > >>> As for extension headers being dropped by some networks, that is true..
> 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.)
> > >>>>
> > >>>> You think this dismissses this? I don't believe that was an intent. Would
> it help to suggest text that includes: RFC6564
> 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.
> > >>>>

---

From: Tom Herbert <[email-masked]>
Date: Thu, 19 Mar 2020 08:01:48 -0700

> [A-Draft authors] Edit draft with a goal of placing roughly equal emphasis on  <selective exposure of information from encrypted transport protocol headers> and <design of new transport protocols>…

I'm all for considering these, however wrt to "design of new transport
protocols" I think we need a better answer than saying new protocols
need to selectively determine which fields to encrypt and which do
not. Reality is that it's not relevant since intermediate devices
aren't going to support parsing new transports in any bounded time.
Consider, SCTP has been around for years with a completely plaintext
header, few network nodes process it, and so it has achieved little
deployment. This is why "Transport protocol independence", #1 below,
is crucial.

This mentioned in the draft, but again it's more accepted fact than
perception: "One motive to use encryption is a response to perceptions
that the network has become ossified by over-reliance on middleboxes
that prevent new protocols and mechanisms from being deployed."

> [B-Tom] Edit/expand final paragraph of new text on network support for IPv6 Hop-by-Hop options to provide more details about what sort of devices are responsible for the observed problems.

I think the problems associated with Hop-by-Hop options have been
pretty well documented, a solution to these would be general. I'm not
sure which WG this would belong in.

It's a general problem that has been discussed in other documents.
That comes back to the fundamental question that thus far no one has
been able to answer: "Exactly what transport information do we _need_
to expose to the network?".

> Turning to rationale #3, I tend to take a dim view of standards compliance as an end in-and-of itself in a draft like this that has a strong network operational emphasis.  It would be reasonable to…

Standard compliance is not an end in itself. That becomes readily
apparent when we consider the effects when compliance is not
practiced. The material effects caused by middelbox non-conformance in
being intrusive in transport protocols are protocol ossification,
weakened security, impeded Internet evolution, loss of robustness,
etc. In fact, forcing intermediate nodes back into standards
compliance is probably the biggest motivation for encrypting the
transport layer. The draft says exactly this: "This has lead to a
perception that there is too much "manipulation" of protocol headers
within the network, and that designing to deploy in such networks is
preventing transport evolution." Again, whether this is perception or
established fact is debatable.

> I would want to see more details on what sort of non-conformant devices cause problems, in particular routers.  This is because to the extent that routers are responsible, there's a much steeper hi…

Okay, but in that same vein I think there should be more discussion
about the pragmatics of developing and deploying a new transport
protocol especially if we expect that intermediate nodes are going to
handle the protocol. It's one thing for protocol developers to
carefully consider what fields to encrypt, it's an entirely different
problem to get support in intermediate devices to support the
protocol. This is why were stuck with deploying new protocols in UDP,
it gives us the best change to be conformant with the network.
Completely plaintext transport protocol haven't helped make them
deployable (again see SCTP).

Tom

---

From: "Black, David" <[email-masked]>
Date: Thu, 19 Mar 2020 18:26:23 +0000

Hi Tom,

Extracting brief excerpts to focus on what needs to be done to this draft, now ...

> to expose to the network?".

+1 - that question is important, but the problem is complex ... and (to paraphrase HL Mencken), the current situation is that we've found the two clear, simple and wrong answers, namely encrypt everything and encrypt nothing.   A longer, deeper discussion is in order to find more useful answers about what to encrypt vs. expose - this draft is intended as input to that discussion.

> This is why "Transport protocol independence", #1 below, is crucial.
> 
> perception:

Noted, expect better discussion of this topic in the next version of the draft, stay tuned ...

> sure which WG this would belong in.

That certainly does not belong in this draft.  What would you suggest as a reference that describes current problems with Hop-by-Hop options and/or their current state of deployability?

> > I would want to see more details on what sort of non-conformant devices
> > cause problems, in particular routers.  This is because to the extent that routers
> > are responsible, there's a much steeper hill to climb for a good level of support
> > (e.g., reduced likelihood of a Happy Eyeballs approach working well in general).
> >
> protocol.

I think the overall concern will be addressed by added discussion of transport protocol independent vs. dependent exposure of information to the network.

Beyond that, I would suggest that the design of TLS 1.3 and its use in QUIC suggests that there is no IETF expectation "that intermediate nodes are going to handle the [transport] protocol."

Thanks, --David

> From: Tom Herbert <[email-masked]>
> Sent: Thursday, March 19, 2020 11:02 AM
> To: Black, David
> Cc: [email-masked]
> > I understand where this is going, but I think that the initial proposed text
> (below) has gone over to unbalanced in the other direction, and the draft ought
> to wind up somewhere in the middle.
> >
> > [A-Draft authors] Edit draft with a goal of placing roughly equal emphasis on
> <selective exposure of information from encrypted transport protocol headers>
> and <design of new transport protocols> as motivations and intended uses of
> this draft.  That looks like it will help respond to Ekr's comment.
> 
> > [B-Tom] Edit/expand final paragraph of new text on network support for IPv6
> Hop-by-Hop options to provide more details about what sort of devices are
> responsible for the observed problems.
> 
> > In more detail ...backing out to a higher level, the proposed new text
> articulates three rationales for use of IPv6 Hop-by-Hop options:
> >
> > Of these three, I view rationale #2 (Explicit control of exposed content) as
> crucial, because it appears to also be related to Ekr's comment.  Digging into
> that comment and related discussion, my initial take is that the draft has (in
> 20/20 hindsight) not paid enough attention to selective exposure of information
> from encrypted transport protocol headers by comparison to design of new
> transport protocols.  In particular, I concur with Martin's observation: "I suspect
> loss bits are not the last time someone will want to expose more info [from
> QUIC transport headers]." ... and I would still concur even if he weren't an
> incoming Transport AD ;-).
> >
> > So, I recommend editing the draft  to better balance <selective exposure of
> information from encrypted transport protocol headers> as a motivation for
> the draft with  <design of new transport protocols>.  These changes ought to
> start early in the draft, e.g., work selective exposure of encrypted header
> information into the first sentence of this paragraph of the Introduction:
> >
> > Then, somewhere in or near Section 5 of the draft, it would be useful to add a
> brief discussion of the possible means of exposing such information.  That
> would be a good place to deal with transport-independence vs. transport-
> specificity of exposed information, which encompasses rationale #1, and
> including IPv6 Hop-by-Hop options [RFC8200] is a fine example of a transport-
> independent approach.
> >
> > Turning to rationale #3, I tend to take a dim view of standards compliance as
> an end in-and-of itself in a draft like this that has a strong network operational
> emphasis.  It would be reasonable to explain why the example of IPv6 hop-by-
> hop options is superior to IPv4 options, but DPI, which often goes well beyond
> the transport protocol headers, seems beyond the immediate focus of this
> draft.
> 
> > One more thing ... the topic of network non-support for extension headers
> keeps coming up as something that needs carefully crafted text.   Starting from
> the paragraph proposed below:
> >
> > I would want to see more details on what sort of non-conformant devices
> cause problems, in particular routers.  This is because to the extent that routers
> are responsible, there's a much steeper hill to climb for a good level of support
> (e.g., reduced likelihood of a Happy Eyeballs approach working well in general).
> >
> 
> > > On Mon, Mar 16, 2020 at 10:23 AM Gorry Fairhurst
> <[email-masked]>
> > > wrote:
> > > >
> used.
> Would
> some