Subject: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-13

From: Tom Herbert <[email-masked]>
Date: Mon, 23 Mar 2020 07:58:07 -0700

Regarding new text on Ipv6 extension headers, the draft states:

"o On the one hand, protocols do not necessarily have an incentive to
expose the actual information that is used by the protocol itself and
could therefore manipulate the exposed transport header information to
gain an advantage from the network. The incentive to reflect actual
transport header information has to be considered when proposing a
method."

I think this is a mostly irrelevant argument because:

- The QUIC spin bit, which is touted as the best example of a non-TCP
protocol exposing transport layer information, is not used by the end
protocol hence hosts can set it to try to gain an advantage as the
argument suggests. It's even worse than that, since the spin bit is in
UDP payload it's quite possible that the network misinterprets a
packet that is not QUIC (but uses the same port number), in which case
such packets may be at a disadvantage.
- STT (https://tools.ietf.org/html/draft-davie-stt-08) is an example
of how the TCP protocol itself can be spoofed explicitly for the
purpose of fooling the network into provide TCP-level service for
something not at all TCP (in this case IP tunnels).
- The argument precludes the possibility that the transport layer
information in Hop-by-Hop options could be authenticated by the
network and hence a contract is established between hosts and network
that the information is honest and correct. FAST
(https://tools.ietf.org/html/draft-herbert-fast-04) gives a
description of that.

Fundamentally, transport layer is end-to-end information. There is no
contract between end hosts and the network that hosts have to be
honest or correct in setting information in the transport layer-- the
only contract is between the endpoints. There is incentive for hosts
to set transport information per the networks implicit requirements,
but that's not because we are interested in getting any of the
benefits listed in the draft, it's simply because if we don't abide by
the networks implicit requirements our packets get will likely get
dropped somewhere in the path. Ultimately, this is what has driven
host stacks and applications to the least common denominator, and is
exactly why any new transport protocols will encrypt as much as
possible.

Tom

---

From: Joseph Touch <[email-masked]>
Date: Mon, 23 Mar 2020 08:20:06 -0700

> On Mar 23, 2020, at 7:58 AM, Tom Herbert <[email-masked]> wrote:
> 
> only contract is between the endpoints. 

+1

Another point worth mentioning:

- if endpoints can lie or mislead about transport info to get their way, they can, will, and IMO *SHOULD*.

That goes for using port 53 for nearly anything anyone wants to. Transport info isn’t there to make things nice for network operators - that’s what the network layer is for.

Oh, yeah, I know - network operators don’t want “heavy” stuff in *their* headers because it slows them down when they don’t want it. Too bad, IMO. If they want the info, they need to deal with the pain.

Joe

---

From: "Black, David" <[email-masked]>
Date: Mon, 23 Mar 2020 22:19:31 +0000

[writing as draft shepherd]

Point taken – would it be reasonable to rework that paragraph to observe that there should be incentives for endpoints to expose transport information, e.g., otherwise implementers may simply not bother?

Thanks, --David

From: tsvwg <[email-masked]> On Behalf Of Joseph Touch
Sent: Monday, March 23, 2020 11:20 AM
To: Tom Herbert
Cc: tsvwg
Subject: Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-13

[EXTERNAL EMAIL]

On Mar 23, 2020, at 7:58 AM, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

+1

Joe

---

From: Joseph Touch <[email-masked]>
Date: Mon, 23 Mar 2020 16:07:33 -0700

> On Mar 23, 2020, at 3:19 PM, Black, David <[email-masked]> wrote:
> 

That sounds like it’s leaning towards extortion - the kind we have now, in which “if you don’t let us see your ports and we don’t like them, we’ll block you”.

I’d lean the other way - that the network really shouldn’t be doing anything based on information gleaned from transports - explicitly given or not - because it only serves to create mutual escalation of misinformation.

Joe

>  
> Thanks, --David
>  
> From: tsvwg <[email-masked] <mailto:[email-masked]>> On Behalf Of Joseph Touch
> On Mar 23, 2020, at 7:58 AM, Tom Herbert <[email-masked] <mailto:[email-masked]>> wrote:
>

---

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

> Point taken – would it be reasonable to rework that paragraph to observe that there should be incentives for endpoints to expose transport information, e.g., otherwise implementers may simply not b…
David,

I think the draft is trying to highlight the benefits of exposed
transport layer information, and presumably the opportunity to reap
those is the incentive to expose the information. I believe that those
benefits are real. The problem is that all the benefits of exposed
transport layer information are anecdotal and general. As I type this
email, which I assume is sent over TCP, I cannot tell you if I'm
getting any benefit from TCP having plaintext headers. Maybe I'm
personally benefiting, maybe I'm not, I don't know. If the exposure
was innocuous it wouldn't matter, but it has not been established that
exposure of transport layer information is not a privacy or security
risk. Unfortunately, all this degenerates to the only real incentive
for exposing transport layer information is that if we don't expose it
then the network may our drop packets.

Tom

---

From: Joseph Touch <[email-masked]>
Date: Mon, 23 Mar 2020 16:17:11 -0700

> On Mar 23, 2020, at 4:11 PM, Tom Herbert <[email-masked]> wrote:
> 
> Unfortunately, all this degenerates to the only real incentive

Indeed - like I said, extortion.

That’s exactly how many NATs and other types of port/service blockers work now. I don’t think we should be increasing that capability.

I haven’t seen a reason to expose headers that isn’t of this type…

Joe

---

From: "Black, David" <[email-masked]>
Date: Tue, 24 Mar 2020 01:48:28 +0000

> That sounds like it’s leaning towards extortion - the kind we have now, in which
> “if you don’t let us see your ports and we don’t like them, we’ll block you”.
That sounds like a networking version of turning Spinal Tap’s amps up to 11 ...

> I’d lean the other way - that the network really shouldn’t be doing anything based on information
> gleaned from transports - explicitly given or not - because it only serves to create mutual escalation of misinformation.
... and that looks like other end of the spectrum.

What I had in mind was something more balanced about benefits to exposing some information to the network that motivate endpoints and endpoint implementers to do so ... where motivate is not intended to imply extortion-like threats, and the benefits aren’t necessarily the network doing something immediate based on the exposed information (there are several examples in Section 2.3 of the draft).

To be concrete, here’s one possible text change, based on taking out the words that seems to be the focus of this discussion:

OLD
   o  On the one hand, protocols do not necessarily have an incentive to
      expose the actual information that is used by the protocol itself
      and could therefore manipulate the exposed transport header
      information to gain an advantage from the network.  The incentive
      to reflect actual transport header information has to be
      considered when proposing a method.
NEW

   o  On the one hand, protocols do not necessarily have an incentive to

      expose information that is used by the protocol.  The incentive

      to expose transport header information has to be considered when

      proposing a method to do so.

Which leaves room to argue that there is no incentive, or there is insufficient incentive, or the risks outweigh the benefits, etc.

Thanks, --David

From: Joseph Touch <[email-masked]>
Sent: Monday, March 23, 2020 7:08 PM
To: Black, David
Cc: Tom Herbert; tsvwg
Subject: Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-13

[EXTERNAL EMAIL]

On Mar 23, 2020, at 3:19 PM, Black, David <[email-masked]<mailto:[email-masked]>> wrote:

Joe

Thanks, --David

From: tsvwg <[email-masked]<mailto:[email-masked]>> On Behalf Of Joseph Touch
Sent: Monday, March 23, 2020 11:20 AM
To: Tom Herbert
Cc: tsvwg
Subject: Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-13

[EXTERNAL EMAIL]

+1

Joe

---

From: Tom Herbert <[email-masked]>
Date: Mon, 23 Mar 2020 20:21:58 -0700

David,

That's changing the meaning of the text. The original text was making
a point that if transport layer information is exposed there needs to
be an incentive for the host to set the information honestly and
correctly. This is true, not just for transport layer information but
for everything the host tells the network. An obvious example is TOS
in IPv4-- left to their own devices everyone would just request the
highest level of service of traffic for all packets. So we need some
tangible incentive for user to be honest and correct. For instance,
TOS might have worked if the user were explicitly charged for the
higher level of service, but that would imply a contract between the
network and the host is established and a whole bunch of mechanisms
that require far more than just anonymously volunteering some
arbitrary amount of transport layer information.

Tom

---

From: Joseph Touch <[email-masked]>
Date: Mon, 23 Mar 2020 20:49:16 -0700

+1

> On Mar 23, 2020, at 8:21 PM, Tom Herbert <[email-masked]> wrote:
> 
>> NEW
>>

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 24 Mar 2020 07:42:29 +0000

On 24/03/2020 03:49, Joseph Touch wrote:
> +1
>
>> On Mar 23, 2020, at 8:21 PM, Tom Herbert <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>> NEW
>>>

+1

Gorry

---

From: <[email-masked]>
Date: Tue, 24 Mar 2020 08:06:31 +0000

David,

don’t know, where this is heading to. Two observations, shared earlier on this list:

  *   I’ve distributed a link to a publication where Google gives advice to operators how to optimize access policer configuration. This optimization requires transport layer performance information.
  *   One result of encryption that I’m aware of are measurement applications residing in dedicated and consumer terminals, reporting results back to central servers. Reporting transport performance is one aspect.

Regards,

Ruediger

Von: tsvwg <[email-masked]> Im Auftrag von Black, David
Gesendet: Montag, 23. März 2020 23:20
An: Joseph Touch <[email-masked]>; Tom Herbert <[email-masked]>
Cc: tsvwg <[email-masked]>
Betreff: Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-13

Thanks, --David

[EXTERNAL EMAIL]

+1

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 24 Mar 2020 10:05:09 +0000

On 24/03/2020 08:06, [email-masked] wrote:
>   * I’ve distributed a link to a publication where Google gives advice
>     to operators how to optimize access policer configuration. This
>     optimization requires transport layer performance information.
>   * One result of encryption that I’m aware of are measurement
>     applications residing in dedicated and consumer terminals,
>     reporting results back to central servers. Reporting transport
>     performance is one aspect.
>
> Regards,
>
> Ruediger
>
Thanks Ruediger, I found this is helpful - I suspect as we gain more 
experience about what works well and what does not work so well, TSVWG 
will be able to write another document that identifies way(s) forward, 
and this sort of thing is what we should focus on next.

Gorry

> *Von:*tsvwg <[email-masked]> *Im Auftrag von *Black, David
> *Gesendet:* Montag, 23. März 2020 23:20
> *An:* Joseph Touch <[email-masked]>; Tom Herbert 
> <[email-masked]>
> *Cc:* tsvwg <[email-masked]>
> *Betreff:* Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-13
>
> Point taken – would it be reasonable to rework that paragraph to 
> observe that there should be incentives for endpoints to expose 
> transport information, e.g., otherwise implementers may simply not bother?
>
> Thanks, --David
>
> *From:* tsvwg <[email-masked] <mailto:[email-masked]>> 
> *On Behalf Of *Joseph Touch
> *Sent:* Monday, March 23, 2020 11:20 AM
> *To:* Tom Herbert
> *Cc:* tsvwg
> *Subject:* Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-13
>
> [EXTERNAL EMAIL]
>
> That goes for using port 53 for nearly anything anyone wants to. 
> Transport info isn’t there to make things nice for network operators - 
> that’s what the network layer is for.
>
> Oh, yeah, I know - network operators don’t want “heavy” stuff in 
> *their* headers because it slows them down when they don’t want it. 
> Too bad, IMO. If they want the info, they need to deal with the pain.
>
> Joe
>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 24 Mar 2020 08:09:17 -0700

On Tue, Mar 24, 2020 at 1:07 AM <[email-masked]> wrote:
> I’ve distributed a link to a publication where Google gives advice to operators how to optimize access policer configuration. This optimization requires transport layer performance information.

Hi Ruediger,

If you're referring to "An Internet-Wide Analysis of Traffic
Policing", I will point out that all of the analysis and
recommendations seem to be for TCP only. There's no mention of how
analysis or policing can be done for QUIC or any other transport
porotocol or cases where TCP resides in some encrypted tunnel.

Tom

> One result of encryption that I’m aware of are measurement applications residing in dedicated and consumer terminals, reporting results back to central servers. Reporting transport performance is one aspect.
>
>
>
> Regards,
>
>
>
> Ruediger
>
>
>

---

From: "Black, David" <[email-masked]>
Date: Tue, 24 Mar 2020 16:17:23 +0000

Dell Customer Communication - Confidential

Tom,

In 20/20 hindsight, I've clearly not fully understood your original comment.

Could you propose specific text changes that would address it?

Thanks, --David

> -----Original Message-----
> From: Tom Herbert <[email-masked]>
> Sent: Monday, March 23, 2020 11:22 PM
> To: Black, David
> Cc: Joseph Touch; tsvwg
> > > gleaned from transports - explicitly given or not - because it only serves to
> create mutual escalation of misinformation.
> >
> > What I had in mind was something more balanced about benefits to exposing
> some information to the network that motivate endpoints and endpoint
> implementers to do so ... where motivate is not intended to imply extortion-like
> threats, and the benefits aren’t necessarily the network doing something
> immediate based on the exposed information (there are several examples in
> Section 2.3 of the draft).
> >
> >
> >
> > To be concrete, here’s one possible text change, based on taking out the
> words that seems to be the focus of this discussion:
> >
> >
> >
> > OLD
> >
> > Which leaves room to argue that there is no incentive, or there is insufficient
> incentive, or the risks outweigh the benefits, etc.
> >
> >
> >
> > Thanks, --David
> >
> >
> >
> > Point taken – would it be reasonable to rework that paragraph to observe
> that there should be incentives for endpoints to expose transport information,
> e.g., otherwise implementers may simply not bother?
> >
> >
> >
> > That sounds like it’s leaning towards extortion - the kind we have now, in
> which “if you don’t let us see your ports and we don’t like them, we’ll block
> you”.
> >
> >
> >
> > I’d lean the other way - that the network really shouldn’t be doing anything
> based on information gleaned from transports - explicitly given or not -
> because it only serves to create mutual escalation of misinformation.
> >
> >
> >
> > Joe
> >
> >
> >
> >
> >
> > Thanks, --David
> >
> >
> >
> > That goes for using port 53 for nearly anything anyone wants to. Transport
> info isn’t there to make things nice for network operators - that’s what the
> network layer is for.
> >
> >
> >
> > Oh, yeah, I know - network operators don’t want “heavy” stuff in *their*
> headers because it slows them down when they don’t want it. Too bad, IMO. If
> they want the info, they need to deal with the pain.
> >
> >
> >
> > Joe
> >
> >

---

From: Tom Herbert <[email-masked]>
Date: Tue, 24 Mar 2020 09:31:06 -0700

David,

My original comment was that the following text in the draft is not
relevant for the reasons I mentioned. The change I suggest would be to
simply remove the paragraph:

Tom

> > which
> > based on information

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 24 Mar 2020 16:43:07 +0000

> transport header information has to be considered when proposing a

Why do you think this is not a view held by some people?

This is a point that has been included in the draft for some 
considerable time, and consideration of incentives to lie has been a 
recurrent theme in understanding deployment stories. The present text 
simply notes this point, and then says it should be "considered".  The 
story of why TOS was extremely difficult to deploy outside of controlled 
environments is a nice example of this.

This is part of a two-part construction. I see this point as balanced in 
the second part (which I assume you would agree with), and I chose this 
re-ordering so that the second point was mentioned last

Gorry

---

From: Tom Herbert <[email-masked]>
Date: Tue, 24 Mar 2020 10:50:24 -0700

> Why do you think this is not a view held by some people?
Gorry,

I'm only giving my opinion.

> recurrent theme in understanding deployment stories. The present text

It was not previously mentioned in the context of extension headers.
This is a general consideration for any unauthenticated plaintext data
in a packet that an intermediate node chooses to consume. As Joe said,
in the absence of any requirement or contract, it's the prerogative of
the host to manipulate packet contents as it sees fit to gain an
advantage (where sometimes the "advantage" is just that packets get
delivered and not dropped).

> re-ordering so that the second point was mentioned last

I provided text with three tangible benefits of exposing transport
layer information in Hop-by-Hop options, namely: 1) Hop-by-Hop options
work with any transport protocol, 2) Hop-by-Hop options are explicit
so that the end host or application control their content, 3)
Hop-by-Hop options are the only protocol conformant method to expose
arbitrary information to the network. I don't see that the latest
draft includes these, especially points #1 and #3. Why did you choose
to omit these in the latest draft?

Tom

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 24 Mar 2020 19:43:06 +0000

See below.

> On 24 Mar 2020, at 17:51, Tom Herbert <[email-masked]> wrote:
> 
OK, thanks for taking the time to detail this. I will try a reply  - forgive me, if I repeat things I have said in other rounds of discussion, but I will do my best to answer... see below.

> delivered and not dropped).

Agree this text is more general. I will look at that text and see if these two paras can be moved.

> work with any transport protocol,

True - but actually, I suggest this is true of any generalised header. It is true of a GRE tunnel header and other encaps.

> 2) Hop-by-Hop options are explicit
> so that the end host or application control their content,

Perhaps ... I would really encourage support this, APIs, protocols and the authentication methods to protect integrity of info, etc. The reason I keep pushing back a little is because I don’t know of people saying they are actually using extensions to manage and operate their networks, am I missing something? 

 I would like to stick with a scope that the document describes things that have been done. I know that both you and I, and others, have int area drafts that we’d like to see use of extension headers. Am I missing something? I didn’t see people running networks explain how they are using this. I would be really happy to understand deployment experience....

... if anyone else on the list also has this experience of reading and using extensions headers, let me know - off list if you prefer.

> 3)
> arbitrary information to the network.

Not sure “only” and “conformant” are so helpful words here.

> . I don't see that the latest

> Tom

Not because I specifically don’t want that to be the case, only because I didn’t hear people saying they had experience of using extensions for operations support, to traverse firewalls, run measurement tools, inform QoS/SLA policers/classifiers, whatever. We need to get networking people to support them in routers etc.

Gorry

---

From: <[email-masked]>
Date: Wed, 25 Mar 2020 06:14:37 +0000

Hi Tom,

You write: There's no mention of how analysis or policing can be done for QUIC or any other transport protocol or cases where TCP resides in some encrypted tunnel.

I think, bandwidth limitation by policing will not disappear due to encryption or due to new transport protocols. My take of the underlying issue "dimensioning of network buffers, burst-tolerance and AQM for optimized transport performance" was, that it motivates work like draft-ietf-tsvwg-transport-encrypt.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Tom Herbert <[email-masked]> 
Gesendet: Dienstag, 24. März 2020 16:09
An: Geib, Rüdiger <[email-masked]>
Cc: Black, David <[email-masked]>; tsvwg <[email-masked]>
Betreff: Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-13

Hi Ruediger,

If you're referring to "An Internet-Wide Analysis of Traffic Policing", I will point out that all of the analysis and recommendations seem to be for TCP only. There's no mention of how analysis or policing can be done for QUIC or any other transport porotocol or cases where TCP resides in some encrypted tunnel.

Tom

---

From: Tom Herbert <[email-masked]>
Date: Wed, 25 Mar 2020 07:25:39 -0700

> I think, bandwidth limitation by policing will not disappear due to encryption or due to new transport protocols. My take of the underlying issue "dimensioning of network buffers, burst-tolerance a…

Ruediger,

Yes, but the transport layer information used by some network
mechanisms is disappearing with the use encryption or new transport
protocols. The draft establishes that. It seems like either these
mechanisms will need to be adapted to not rely on transport layer
information in a packet, or we need to define a generic method to put
the necessary information in plaintext somewhere in the packet that
can be consumed by intermediate nodes and the information exposure is
controlled by end nodes (which is the point of exposing the necessary
transport layer information in network layer).

Tom

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 25 Mar 2020 14:45:40 -0500

> Why do you think this is not a view held by some people?

I have some concern that one of the reasons
https://datatracker.ietf.org/doc/rfc8404/ and
https://datatracker.ietf.org/doc/rfc8462/ were such three-ring circuses was
because "view held by some people" was the criteria for opinions to be
included in the drafts. My hope for this draft was that it would be a
catalog of what unencrypted transport protocols were exposing, and not very
much more (and especially not including opinions about whether they should
be exposing it, or what the best way to expose it if the original transport
information was encrypted).

This discussion hasn't sunken into the depths that Last Call
for draft-mm-wg-effect-encrypt plumbed yet, but it certainly can.

Do The Right Thing, of course ...

Spencer

> observe
> >>>> - if endpoints can lie or mislead about transport info to get their
> way, they
> >>> can, will, and IMO *SHOULD*.
> >>>>
> >>>>
> Transport
> *their*