Subject: Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

From: Christian Huitema <[email-masked]>
Date: Wed, 9 Oct 2019 07:32:31 -0700

As the draft mentions:

   The use of transport layer authentication and encryption exposes a

   tussle between middlebox vendors, operators, applications developers

   and users

Much of the draft reads like a lamentation of the horrible consequences
of encrypting transport headers, which looks very much like embracing
the point of view of the middlebox vendors. Expressing that point of
view is of course fine, and it might be enough to change the title,
abstract and introduction to reflect that this is an opinion piece. But
as a transport working group document I would like something a bit more
balanced. It should spend more time acknowledging the ossification and
privacy issues. It should ideally lay the ground work for alternative
management solutions, such as controlled exposure like the spin bit in
QUIC, IP header information, or standardized logs like the QLOG effort.

-- Christian Huitema

On 10/8/2019 2:08 PM, Black, David wrote:
>
> FYI – some OPS area and SEC area eyes on this TSVWG draft now (during
> WGLC) would be a good thing ;-).
>
>  
>
> Thanks, --David (TSVWG co-chair)
>
>  
>
> *From:* Black, David <[email-masked]>
> *Sent:* Tuesday, October 8, 2019 5:06 PM
> *To:* [email-masked]
> *Cc:* Black, David
> *Subject:* WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23
> October 2019
>
>  
>
> This email announces a TSVWG Working Group Last Call (WGLC) on:
>
>  
>
> The Impact of Transport Header Confidentiality on Network Operation and
>
>                        Evolution of the Internet
>
>                  draft-ietf-tsvwg-transport-encrypt-08
>
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/
>
>  
>
> This draft is intended to become an Informational RFC.
>
>  
>
> This WGLC will run through the end of the day on Wednesday, October 23.
>
> That should allow time before the Singapore draft submission cutoff for
>
> the authors to revise the draft with any changes that result from WGLC.
>
>  
>
> Comments should be sent to the [email-masked] <mailto:[email-masked]>
> list, although purely
>
> editorial comments may be sent directly to the authors. Please cc: the
>
> WG chairs at [email-masked] <mailto:[email-masked]>  if
> you would like the chairs to
>
> track such editorial comments as part of the WGLC process.
>
>  
>
> No IPR disclosures have been submitted directly on this draft.
>
>  
>
> Thanks,
>
> David, Gorry and Wes
>
> (TSVWG Co-Chairs)
>
>  
>
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Joe Touch <[email-masked]>
Date: Wed, 9 Oct 2019 07:38:52 -0700

+1

IMO, this isn’t a “tussle” so much as “I really want to do something I know I shouldn’t be doing”.

A lot of what transport security prevents is - from the middlebox view - a problem.

For many of us users, preventing middleboxes from doing things like hijacking web, email, and DNS is *exactly* the protection we were seeking.

Joe

> On Oct 9, 2019, at 7:32 AM, Christian Huitema <[email-masked]> wrote:
> 
> As the draft mentions:
> 
> Much of the draft reads like a lamentation of the horrible consequences of encrypting transport headers, which looks very much like embracing the point of view of the middlebox vendors. Expressing that point of view is of course fine, and it might be enough to change the title, abstract and introduction to reflect that this is an opinion piece. But as a transport working group document I would like something a bit more balanced. It should spend more time acknowledging the ossification and privacy issues. It should ideally lay the ground work for alternative management solutions, such as controlled exposure like the spin bit in QUIC, IP header information, or standardized logs like the QLOG effort.
> 
> -- Christian Huitema
> 
> 
> 
>> FYI – some OPS area and SEC area eyes on this TSVWG draft now (during WGLC) would be a good thing ;-).
>>  
>> From: Black, David <[email-masked]> <mailto:[email-masked]> 
>> Sent: Tuesday, October 8, 2019 5:06 PM
>> To: [email-masked] <mailto:[email-masked]>
>> Cc: Black, David
>> Subject: WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019
>>  
>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/ <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/>
>>  
>> Comments should be sent to the [email-masked] <mailto:[email-masked]> list, although purely
>> WG chairs at [email-masked] <mailto:[email-masked]>  if you would like the chairs to
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/saag <https://www.ietf.org/mailman/listinfo/saag>

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 09 Oct 2019 16:12:35 +0100

On 09/10/2019, 15:38, Joe Touch wrote:
> For many of us users, preventing middleboxes from doing things like 
> hijacking web, email, and DNS is *exactly* the protection we were seeking.
>
I do not understand this particular comment with respect to this 
document: How does "hijacking web, email, and DNS" relate to whether 
transport headers are encrypted or not? I would have expected a comment 
like this had the document been talking about transport payload (e.g. 
whether to use TLS).

Could you point me at some text that leads you to think the transport 
header encryption impacts application hi-jacking ?

Gorry

> Joe
>
>> On Oct 9, 2019, at 7:32 AM, Christian Huitema <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> As the draft mentions:
>>
>> Much of the draft reads like a lamentation of the horrible 
>> consequences of encrypting transport headers, which looks very much 
>> like embracing the point of view of the middlebox vendors. Expressing 
>> that point of view is of course fine, and it might be enough to 
>> change the title, abstract and introduction to reflect that this is 
>> an opinion piece. But as a transport working group document I would 
>> like something a bit more balanced. It should spend more time 
>> acknowledging the ossification and privacy issues. It should ideally 
>> lay the ground work for alternative management solutions, such as 
>> controlled exposure like the spin bit in QUIC, IP header information, 
>> or standardized logs like the QLOG effort.
>>
>> -- Christian Huitema
>>
>>
>>> *From:*Black, David<[email-masked]>
>>> *Sent:*Tuesday, October 8, 2019 5:06 PM
>>> *To:[email-masked]
>>> *Cc:*Black, David
>>> *Subject:*WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 
>>> October 2019
>>> Comments should be sent to [email-masked] 
>>> <mailto:[email-masked]>list, although purely
>>> WG chairs [email-masked] <mailto:[email-masked]>  if

---

From: Joe Touch <[email-masked]>
Date: Wed, 9 Oct 2019 08:25:13 -0700

> On Oct 9, 2019, at 8:12 AM, Gorry Fairhurst <[email-masked]> wrote:
> 
> I do not understand this particular comment with respect to this document: How does "hijacking web, email, and DNS" relate to whether transport headers are encrypted or not? I would have expected a comment like this had the document been talking about transport payload (e.g. whether to use TLS).
> 
> Could you point me at some text that leads you to think the transport header encryption impacts application hi-jacking ?

The doc mentions IPsec (encryption the transport headers and payload), TCP AO (authenticating the header and contents), and TLS/DTLS (authenticating contents based on headers).

Any of these prevent HTTP from being hijacked and redirected, e.g., as can occur on public WiFi. IMO,

DTLS or DNS over TCP with TLS would protect against DNS hijacking.

Encrypted is only one part of the equation; authenticated is another (TLS/DTLS doesn’t encrypt headers). But all of these help protect against hijacking.

I’m supporting Christian’s position - the doc is too biased towards “intermediate boxes have rights” than “endpoint users have rights”.

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 09 Oct 2019 16:36:23 +0100

On 09/10/2019, 16:25, Joe Touch wrote:
>
>> On Oct 9, 2019, at 8:12 AM, Gorry Fairhurst<[email-masked]>  wrote:
>>
So, in this respect we agree - but where did the text say otherwise?
> DTLS or DNS over TCP with TLS would protect against DNS hijacking.
Again, we agree, which text do you think needs improved.
Gorry

---

From: Joe Touch <[email-masked]>
Date: Wed, 9 Oct 2019 18:45:09 -0700

> On Oct 9, 2019, at 8:36 AM, Gorry Fairhurst <[email-masked]> wrote:
> 

It doesn’t quite, but...

> Again, we agree, which text do you think needs improved.

I’m sorry to say it starts with the title - the impact of security on network ops and the evolution of the Internet, which starts off on the assumption that “security is getting in the way”, rather than “exposure of TRANSPORT information to the network is a privilege”.

Throughout, the assumption is that the network should have access to this information and/or be able to modify it, rather than that users have the right to lNOT let the network have that info or change it.

Encryption and privacy are spoken of as “benefits” and of “interest”, rather than as rights. Access to transport is spoken of necessary and denial of that access a threat to providing services.

IMO, this is both incorrect and inappropriate to promote as an IETF position.It leads to the very behavior discussed - that development of legitimate transport protocol mechanisms being hampered by middleboxes that violate whatever standard or policy interferes with their revenue model.

It’s disingenuous to present this problem as merely two competing viewpoints, and it’s hard to find a single way to address this issue the way the document has evolved. It reads more like a warning to the rest of us not to interfere with whatever middleboxes or network operators want to do. 

I don’t know how to fix it, but I can’t stand idly by and endorse it either.

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 10 Oct 2019 09:45:38 +0100

Thanks Joe for this, I'm keen to see if any of your understanding can be 
translated into a change, so I'd liek to continue this thread a little...

On 10/10/2019, 02:45, Joe Touch wrote:
>
>
>> On Oct 9, 2019, at 8:36 AM, Gorry Fairhurst <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>>> On Oct 9, 2019, at 8:12 AM, Gorry Fairhurst<[email-masked] 
>>>> <mailto:[email-masked]>>  wrote:
>>>>
>>>>> For many of us users, preventing middleboxes from doing things 
>>>>> like hijacking web, email, and DNS is *exactly* the protection we 
>>>>> were seeking.
>>>>>
>>>> document: How does "hijacking web, email, and DNS" relate to 
>>>> whether transport headers are encrypted or not? I would have 
>>>> expected a comment like this had the document been talking about 
>>>> transport payload (e.g. whether to use TLS).
>>>>
>>>> Could you point me at some text that leads you to think the 
>>>> transport header encryption impacts application hi-jacking ?
>>> The doc mentions IPsec (encryption the transport headers and 
>>> payload), TCP AO (authenticating the header and contents), and 
>>> TLS/DTLS (authenticating contents based on headers).
>>>
> I’m sorry to say it starts with the title - the impact of security on 
> network ops and the evolution of the Internet, which starts off on the 
> assumption that “security is getting in the way”, rather than 
> “exposure of TRANSPORT information to the network is a privilege”.
>
That was not intended. The scope we were given was not to describe what 
we think must be done, but to focus on what is currently being done with 
respect to how transport information is used.

The first para explicitly says "this document strongly supports the 
increased use of encryption in transport protocols". This document is 
intended to explicitly NOT say "don't encrypt" "don't use IPsec", "don't 
use other encryption".

- It should read more like if the majority of the traffic uses headers 
encryption, then there are some implications - (e.g. This news is not 
exactly new for those running networks that heavily use IPsec..) it this 
means some people need to think and do some things differently.
> Throughout, the assumption is that the network should have access to 
> this information and/or be able to modify it, rather than that users 
> have the right to lNOT let the network have that info or change it.
>
Wait!  Where does it say "should be able to modify it" ... that was also 
NOT intended as a part of this message, and if that can be read into 
what is said, then I'd like to re-address that.
> Encryption and privacy are spoken of as “benefits” and of “interest”, 
> rather than as rights. Access to transport is spoken of necessary and 
> denial of that access a threat to providing services.
>
> IMO, this is both incorrect and inappropriate to promote as an IETF 
> position. It leads to the very behavior discussed - that development 
> of legitimate transport protocol mechanisms being hampered by 
> middleboxes that violate whatever standard or policy interferes with 
> their revenue model.
>
I suggest such "middlebox" issues are covered in RFC 8404, and this was 
not the scope of this document. I had hoped that was already clear, but 
will look again.

The intended the focus is on providing transport and using network paths 
(which some SDO's also call "transport"). Examples of inputs received 
concern:  how to debug router queuing; understand congestion/VoIP 
performance/QoS/QoE/etc; detect and predict traffic patterns; layer 2 
interactions with radio; etc.
> It’s disingenuous to present this problem as merely two competing 
> viewpoints, and it’s hard to find a single way to address this issue 
> the way the document has evolved. It reads more like a warning to the 
> rest of us not to interfere with whatever middleboxes or network 
> operators want to do.
>
Sorry to hear that. We will take any comments and try to improve the words.

Gorry

---

From: Joe Touch <[email-masked]>
Date: Fri, 11 Oct 2019 11:14:21 -0700

Popping up a level:

- the issue with transport header mods is basically talking about NATs (port rewriting)
- there’s also a ref to the Trammel ID on mutable transport headers
	although this is intentional from the draft, IMO it’s a bad idea because it requires access to and ability to modify transport headers

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 12 Oct 2019 08:48:55 +0100

I'm intrigued by how far we can understand opportunities for open client 
logs to replace pcap dumps, and would like to delve a little deeper into 
what we understand - there seem many possible actors and that may be 
interesting to look at a few viewpoints:

* a user of a transport protocol (e.g., understanding cost/benefit of 
feature choices);
* a protocol developer (e.g.,  debugging transport interactions end to end);
* a service provider (e.g., trying to understand performance impairments 
in the network);
* researchers/equipment developers seeking to correlate/tune transport 
timing with network policies (e.g., interactions between congestion 
control and link scheduling);
* exploring traffic archives (e.g., trends in what is supported or 
determine when an anomoly appeared).

I've taken all of these viewpoints at some time using pcap to look at TCP.

Clearly when we use QUIC, there can be alternatives and there is now 
some experience with client (and server) logs, what do you think we can 
usefully say in addition to or instead of what the draft says about 
logging (currently mentioned only briefly in section 6.1) ?

The text on spin-bit could indeed be developed a little (the present 
text predates the spin bit being incorporated as an optional part of the 
base spec). What do you think should be said (currently at the end of 6.4)?

Gorry

On 09/10/2019, 15:32, Christian Huitema wrote:
> that point of view is of course fine, and it might be enough to change 
> the title, abstract and introduction to reflect that this is an 
> opinion piece. But as a transport working group document I would like 
> something a bit more balanced. It should spend more time acknowledging 
> the ossification and privacy issues. It should ideally lay the ground 
> work for alternative management solutions, such as controlled exposure 
> like the spin bit in QUIC, IP header information, or standardized logs 
> like the QLOG effort.
>
> -- Christian Huitema
>
>

---

From: Tom Herbert <[email-masked]>
Date: Sat, 12 Oct 2019 09:01:44 -0700

> IMO, this isn’t a “tussle” so much as “I really want to do something I know I shouldn’t be doing”.
+1.

I don't see a tussle here. Transport headers are E2E protocols and
were never designed to be consumed by intermediate nodes. Any use case
of intermediate nodes consuming information in the transport layer
header, with the possible exception of NAT, is ad hoc and
non-conformant with the standard. Per the Internet architecture
exposure of this information is not required for routing packets
through intermediate devices, encrypting transport headers is
consistent with the architecture and closes a security hole. As a
transport protocol developer, the _only_ reason I wouldn't encrypt the
transport header is if that is the only way to get packets to a
destination; the possibility there _might_ be some benevolent node in
the network providing some ad hoc benefit users is not enough
justification for sending transport headers in plain text.

I do believe that there will be valid use cases for hosts to signal
the network for services. There is a least one robust, explicit, and
transport agnostic method to allow hosts to signal the network with
transport related information and even application layer information--
that's Hop-by-Hop Options extension header. A critical difference with
parsing transport layers, is that the end host is in control of what
information is exposed in HBH options. As I've said several times, I
believe this draft is missing on the opportunity to propose this as
the "solution" to middleboxes losing visibility because of encryption.
Also, I think the encryption and the perceived loss of visibility is
inevitable anyway so we do need a real solution. (this story is eerily
and the arguments from middlebox view is eerily similar to when TLS
was turned up in the Internet).

Tom

> From: Black, David <[email-masked]>
> To: [email-masked]
> Comments should be sent to the [email-masked] list, although purely
> WG chairs at [email-masked]  if you would like the chairs to

---

From: Tom Herbert <[email-masked]>
Date: Sat, 12 Oct 2019 12:11:22 -0700

> determine when an anomoly appeared).
For this to be a complete list the viewpoints of potentially
malevolent actors also needs to be considered.

---

From: Joe Touch <[email-masked]>
Date: Sat, 12 Oct 2019 20:59:55 -0700

Hi, Gorry,

> On Oct 12, 2019, at 12:48 AM, Gorry Fairhurst <[email-masked]> wrote:
> 
> I'm intrigued by how far we can understand opportunities for open client logs to replace pcap dumps, and would like to delve a little deeper into what we understand - there seem many possible actors and that may be interesting to look at a few viewpoints:

> * a user of a transport protocol (e.g., understanding cost/benefit of feature choices);

There’s only one viewpoint that drives this conversation. It’s the user’s.

If the user wants to encrypt, that’s their prerogative. We should not be recommending or assuming otherwise, 

> * a protocol developer (e.g.,  debugging transport interactions end to end);

That’s fine for them to do ON THEIR TRAFFIC. Not everyone else’s.

> * a service provider (e.g., trying to understand performance impairments in the network);

They should never need to look at others’ transport headers to do this.

> * researchers/equipment developers seeking to correlate/tune transport timing with network policies (e.g., interactions between congestion control and link scheduling);

And if we’re part of their experiment, it needs to be by opt-in and with full understanding of what data they use and how they use it.

> * exploring traffic archives (e.g., trends in what is supported or determine when an anomoly appeared).

That’s just more reason to encrypt.

> Clearly when we use QUIC, there can be alternatives and there is now some experience with client (and server) logs, what do you think we can usefully say in addition to or instead of what the draft says about logging (currently mentioned only briefly in section 6.1) ?
> 
> The text on spin-bit could indeed be developed a little (the present text predates the spin bit being incorporated as an optional part of the base spec). What do you think should be said (currently at the end of 6.4)?
> 

The doc currently states, in that area (sec 6) largely as somewhat of a conclusion:

   The choice of whether future transport protocols encrypt their
   protocol headers needs to be taken based not solely on security and
   privacy considerations, but also taking into account the impact on
   operations, standards and research.

That, in a nutshell, is the problem. 

NO. Security does NOT need to “take into account” the impact on the supposed “rights” of others to make our traffic part of an experiment.

Joe

>>> *Subject:* WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019
>>>

---

From: "Scharf, Michael" <[email-masked]>
Date: Sun, 13 Oct 2019 05:58:48 +0000

+ Students

I guess many generations of young engineers and future software developers have learnt TCP/IP by looking at the IP and TCP headers in PCAP files. Apparently, it has worked to some extend in the last 35 years or so… Of course, there are alternatives in teaching transport protocols to those who are not on IETF e-mail list (so far). But do we really know whether it will work well?

Anyway, Gorry and others on the list may understand that „use case“ much better than me ;-) So I’ll better shut up.

Michael

Von: Gorry Fairhurst<mailto:[email-masked]>
Gesendet: Samstag, 12. Oktober 2019 09:49
An: Christian Huitema<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Betreff: Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, -> logging

Gorry

---

From: Joe Touch <[email-masked]>
Date: Sun, 13 Oct 2019 08:58:52 -0700

FWIW, I’m wondering:

a) how these students study IPsec

b) what you’re teaching you’re students about ethics by snooping on other peoples data without asking
	(if you ask, you can log the key and encryption wouldn’t matter)

Joe

> On Oct 12, 2019, at 10:58 PM, Scharf, Michael <[email-masked]> wrote:
> 
> + Students
>  
> Von: Gorry Fairhurst <mailto:[email-masked]>
> An: Christian Huitema <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>
> >> *From:* Black, David <[email-masked] <mailto:[email-masked]>>
> >> *To:* [email-masked] <mailto:[email-masked]>
> >> *Cc:* Black, David
> >> Comments should be sent to the [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> 
> >> list, although purely
> >>
> >> WG chairs at [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>  if 
> >> https://www..ietf.org/mailman/listinfo/saag <https://www.ietf.org/mailman/listinfo/saag>

---

From: "Scharf, Michael" <[email-masked]>
Date: Sun, 13 Oct 2019 18:40:33 +0000

I guess almost every university with EE or CS study programs has a networking 101 course, and there are hundreds of textbooks. So, my own preferences may not matter. But since you ask:

  1.  There are well-known open source alternatives. Having said this, I think VPNs are often introduced in networking courses after the unencrypted network and the transport layer (and, e.g., after TLS). So the encryption may not be so much of an issue for understanding the overall concept.

  1.  I think in Europe that there are laws in this space, so it is not an ethical question only. The solution is to capture own traffic. Now, which existing undergraduate textbook introduces how to extract keys in the chapter on the Internet transport layer? As far as I can tell, this assumes that encryption, key management, and security is introduced in that course before the Internet Transport layer. Well, that is not impossible, but most existing textbooks I am aware of have a different table of content…

Anyway, others know that space better than me. But to me it is not clear how easy it will be to replace PCAPs in teaching the basics of the Internet.

Michael

Von: Joe Touch<mailto:[email-masked]>
Gesendet: Sonntag, 13. Oktober 2019 17:59
An: Scharf, Michael<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Christian Huitema<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Betreff: Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, -> logging

FWIW, I’m wondering:

Joe

On Oct 12, 2019, at 10:58 PM, Scharf, Michael <[email-masked]<mailto:[email-masked]>> wrote:

+ Students

Michael

Gorry

On 09/10/2019, 15:32, Christian Huitema wrote:
>> *From:* Black, David <[email-masked]<mailto:[email-masked]>>
>> *To:* [email-masked]<mailto:[email-masked]>
>> *Cc:* Black, David
>> Comments should be sent to the [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>> list, although purely
>>
>> WG chairs at [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>  if
>> [email-masked]<mailto:[email-masked]>
>> https://www..ietf.org/mailman/listinfo/saag<https://www.ietf.org/mailman/listinfo/saag>

---

From: Lars Eggert <[email-masked]>
Date: Sun, 13 Oct 2019 22:05:54 +0200

Hi,

On 2019-10-13, at 7:58, Scharf, Michael <[email-masked]> wrote:
> I guess many generations of young engineers and future software developers have learnt TCP/IP by looking at the IP and TCP headers in PCAP files.

my guess is that most students would be in control of one of the endpoints (sending or receiving the traffic of interest), in which case they can still dissect the protocol. Wireshark can decode QUIC traffic just fine if you provide it with the keys.

Lars

---

From: Christian Huitema <[email-masked]>
Date: Sun, 13 Oct 2019 14:17:00 -0700

Thanks, Gorry. First, let me say that I appreciate your approach to not
start a debate about whether encryption is good or bad, but rather to
assume that encryption is deployed, and then study how we perform a set
of functions.

On 10/12/2019 12:48 AM, Gorry Fairhurst wrote:
> I'm intrigued by how far we can understand opportunities for open
> client logs to replace pcap dumps, and would like to delve a little
> deeper into what we understand - there seem many possible actors and
> that may be interesting to look at a few viewpoints:
>

I don't understand this specific use case very well. Do you mean an
application developer, or an end user? If you do mean an application
developer, then the features will be selected by using options exposed
by the API of a protocol implementation. I assume that the
implementations have a logging option, ideally providing a standard
logging format like Qlog. This is somewhat similar to the protocol
developer problem listed below.

> * a protocol developer (e.g.,  debugging transport interactions end to

We do have a fair bit of experience handling that issue during the
development of QUIC. At the very beginning, each implementation had its
own logging format. During tests, we would turn on logging at both the
client and the server, study the traces, and rapidly find the causes of
the interoperability problems -- and potentially add additional logging
options to the code if we could not find the issue.

As we progressed, the tests became more complex, looking for example at
debugging issues in error recovery and congestion control. We saw the
development of two tools:

1) Plugins for Wireshark, and an API between the plugin and protocol
stacks. The API provides the plug-in with the decryption key, so
Wireshark traces can include complete traces of the protocol.

2) Standardized log formats such as Qlog, and then a set of tools for
visualizing this traces and obtain graphs similar to those common with TCP.

The QUIC interop tests involve 20 different implementations, so I would
say that developers have been quite successful using these tools.

I assume that the "student" use case mentioned later in the thread is
very similar to the developer use case.

> impairments in the network);

I think we need to split that scenario in two: debugging following a
customer complaint, and general network monitoring.

For the client case, the solution would be to gather logs on the
client's machine. For example, using Chrome, turn on the Quic logging
options and then send these logs to the support center. This supposes
that the applications used by the client do have an option to turn on
logging, similar to what Chrome does. Calling for that support in the
draft could be useful!

For general network monitoring, tools like Netflow will provide
statistics at the 5-tuple granularity. We have seen work reported in the
Quic WG about using the spin bit to monitor end to end delays in that
scenario. Then there are of course tools developed in the IPPM working
group, such as OWAMP and TWAMP. If I understand correctly these tools
enable measurements between test points without requiring observation of
transport headers in transit.

> control and link scheduling);

This seems quite similar to the protocol developer problem.

> determine when an anomoly appeared).

Some traffic properties are observable on the encrypted flow. Timing of
connection establishment, duration of sessions,  or volume of data are
obvious to measure. The spin bit can also be observed. Fingerprinting
techniques can be used to identify application profiles. It should even
be possible to assess application timing. That's probably enough to
detect macroscopic changes and flag anomalies.

Of course, you will not see which specific features the encrypted
transport deploys, not by simply taking traffic traces. But those
features can probably be obtained by other means, such as instrumenting
servers.

> some experience with client (and server) logs, what do you think we
> can usefully say in addition to or instead of what the draft says
> about logging (currently mentioned only briefly in section 6.1) ?
>
> text predates the spin bit being incorporated as an optional part of
> the base spec). What do you think should be said (currently at the end
> of 6.4)? 

I would need to write a detailed review of your draft. That will take
some time...

-- Christian Huitema

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 14 Oct 2019 16:10:53 +0100

> developer problem listed below.
Yes, and in many cases I can see these people who could have used 
wireshark to see what happens when they turn something on in the API, 
will now look to local (and possibly server) logs to find that out. If 
that's the case, the WG needs/will get the logging correct and the 
people could well be happy; or could learn how to use a wireshark plugin.
> logging, similar to what Chrome does. Calling for that support in the
Yes, I agree, if the API as well as the log were standardised it would 
be helpful - I don't think we discuss standardising the API. Would you 
like to suggest text, or should Colin and I work something out?
> scenario.
The spin bit is mentioned, and thsi text could certianly be updated. I'd prefer to avoid commenting on other proposals that have yet to gain IETF consensus.

> Then there are of course tools developed in the IPPM working
Yes - if I do have equipment that supports these (perhaps more likely 
with major service
providers, than in an enterprise), these could provide some 
measurements, I'm not sure of the maturity of tools and their interop - 
but that's a bigger topic.
> This seems quite similar to the protocol developer problem.
Except it's not really... in this case, the network device/segment being 
observed is moving traffic, and observers often don't have much clue 
about the client's platform, app setups, etc. Why would they? (They also 
don't have away to turn-on debug or logging at clients) - if I look at a 
queue, I see packets. If I know these packets are using a well-known 
protocol TCP, RTP, etc, I can look to see how the CC is being impacted 
by the way that I configure my device (I could tune things if I had 
incentive), if it's IPsec-encrypted traffic, I would generally not 
bother looking more. I think some people  contributed text to an earlier 
revision in this direction, please see if that seems to be heading in a 
useful direction.
> detect macroscopic changes and flag anomalies.
I don't know. There are going to be cases where this would not be enough 
to derive useful outputs, e..g, I suspect looking at the QoE impacts of 
link layers would be challenging.
> features can probably be obtained by other means, such as instrumenting
Maybe I'm not understanding. I'd have thought this was most useful if 
you wanted to test what a specific client used. But also, perhaps it is 
not feasible for someone working on firewall or a router config within a 
company of ISP.
> I would need to write a detailed review of your draft. That will take
Thanks for this feedback - and I'm sure we both look forward to more 
comments. It is helpful to expose issues were they can be described, but 
to avoid proposing solutions that we don't yet have operational 
experience about.

Fow what is worth as an inidvidual, I'd be keen to see "new solutions" 
collected in some future document, but this isn't the place to propose 
those.

Gorry

---

From: Christian Huitema <[email-masked]>
Date: Mon, 14 Oct 2019 13:57:28 -0700

On 10/14/2019 8:10 AM, Gorry Fairhurst wrote:
> Except it's not really... in this case, the network device/segment
> being observed is moving traffic, and observers often don't have much
> clue about the client's platform, app setups, etc. Why would they?
> (They also don't have away to turn-on debug or logging at clients) -
> if I look at a queue, I see packets. If I know these packets are using
> a well-known protocol TCP, RTP, etc, I can look to see how the CC is
> being impacted by the way that I configure my device (I could tune
> things if I had incentive), if it's IPsec-encrypted traffic, I would
> generally not bother looking more. I think some people  contributed
> text to an earlier revision in this direction, please see if that
> seems to be heading in a useful direction. 

OK. I did raise the issue about end-to-end transports experimenting with
new and improved congestion control algorithms, and actually did a
presentation about that in Montreal in the TCPM WG. The feedback was
really a push back. My fears were not grounded they said, because if
this was a problem the network would have collapsed long ago, said in so
many word a queue of distinguished speakers at the microphone. What of
servers adopting IW=gigantic, or video streamers doing no congestion at
all. The network has defenses, etc.

That kind of feedback means that experimenting with congestion control
algorithm in encrypted transports is going to become the norm. And
indeed, I am seeing some of that in the Quic Interop taking place right
now. One of the tests compares downloading a 10MB file with Quic and
downloading the same file with HTTPS/HTTP2. Many implementations manage
much better times with Quic. The download times vary per server, but I
saw results like  3.5 sec with Quic versus 8.5 sec with HTTPS. Against
my own server, I get 3.6 seconds with Quic versus 7.5 with HTTPS. This
did not imply cheating, but merely attention to details in the
implementation of Hystart or Cubic, including filtering of delay
measurements and management of spurious retransmit.

But my point is not to bore you with details of implementations, but to
show that it is very hard for an observer in the middle of the network
to reason about how generic client implementations will react to a
specific network tuning  link management policy. All implementations
will not react in the same way. A given implementation may also react
differently over time: the developers will learn by experience about the
new management policy. They are likely to tune their implementation to
benefit from your tuning of the network.

If you really want to observe an implementation's reaction, the best way
is to perform a controlled test, in which you instrument the client or
the server and run them against your proposed tuning. You will probably
need to do that for a couple of client and servers -- say Chrome and
Firefox, Apache and NGINX. And you will get a snapshot of behavior.

But the real change is that you should consider game theory, and see
what kind of Nash equilibrium results from the combination of your
proposed changes and the implementations' responses. This requires a
change of mindset, and that should probably be explained in the draft.

-- Christian Huitema

---

From: "Lubashev, Igor" <[email-masked]>
Date: Tue, 15 Oct 2019 21:10:31 +0000

> From: Joe Touch <[email-masked]> on Sunday, October 13, 2019 12:00 AM
>
> Hi, Gorry,
>
>> On Oct 12, 2019, at 12:48 AM, Gorry Fairhurst <[email-masked]<mailto:[email-masked]>> wrote:
>>

Most users would likely say that they want Internet that is as fast as possible (low latency/high throughput), very reliable, secure (passwords and emails are safe from peeping toms) and reasonably private. Different people will make different trade-offs between the above, especially about the degree of privacy vs performance and reliability.

I see this draft to be about the trade-off between benefits of an attempts at extreme privacy at a single layer and the effects of these design choices on performance and reliability of the Internet.

> They should never need to look at others’ transport headers to do this.

What else should they look at?  They have to look at packets flowing via their networks and make sense of what’s going – both proactively in terms of monitoring QoS that their customers are getting and reactively in terms of troubleshooting specific issues.  AOM only works within a single network (when it works) and does not help at all with identifying problems and narrowing down responsibility for a problem upstream or downstream from own network.

<snip>

> And if we’re part of their experiment, it needs to be by opt-in and with full understanding of what data they use and how they use it.

We should add “network operators” to the list of entities trying to tune network policies.  Users expect their ISPs (and their upstreams) to do traffic engineering (including running experiments) to improve their network performance/reliability. Browser vendors and server operators do the same all the time.  No opt-in expected/required.  As Christian points out elsewhere, it is no easy task in the face of diverse and sometimes selfish players, but that’s the Internet we have. Everyone has to be able to keep optimizing their part of the Internet ecosystem or users’ experience will suffer.

<snip>

> NO. Security does NOT need to “take into account” the impact on the supposed “rights” of others to make our traffic part of an experiment.

It is, indeed, very hard to compromise on security “a little bit” and still have much of any security left.  There are many aspects to privacy (which sites you visit, when you go online, where you are located – geo-location/ISP/city/country, which devices you use, who else uses your devices, what bandwidth cap you have, are you on a lan or wifi, how many devices you have at home, etc).  It is reasonable to discuss a balance of performance/reliability and degrees of privacy afforded by a general-purpose transport. Users who need extreme privacy already know to use specialized transports like TOR/VPNs/etc (and use specialized measures to protect their privacy on other layers).

I think it is unfortunate that security is even mentioned in this draft. Header encryption is not about security; it is about privacy and protocol ossification resistance.

  *   Igor

As the draft mentions:

-- Christian Huitema

https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtsvwg-2Dtransport-2Dencrypt_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=HduWXlNCmvkQ42KzIrfSRc8yuu5e4n6FRGCSP2KvqnY&s=4lneLr-2pNpCj281Rh3n0bRTCIG65oeyvN0gNwOC1kI&e=>

Comments should be sent to the [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> list, although purely

WG chairs at [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>  if you would like the chairs to

Thanks,

David, Gorry and Wes

(TSVWG Co-Chairs)

---

From: "Lubashev, Igor" <[email-masked]>
Date: Tue, 15 Oct 2019 21:32:22 +0000

> On Sat, Oct 12, 2019 at 12:02 PM Tom Herbert <[email-masked]> wrote:
> 
> I do believe that there will be valid use cases for hosts to signal the network
> for services. There is a least one robust, explicit, and transport agnostic
> method to allow hosts to signal the network with transport related
> information and even application layer information-- that's Hop-by-Hop
> Options extension header. A critical difference with parsing transport layers,
> is that the end host is in control of what information is exposed in HBH
> options. As I've said several times, I believe this draft is missing on the
> opportunity to propose this as the "solution" to middleboxes losing visibility
> because of encryption.

+1
An explicit signal-to-network, such as IPv6 HBH option, is architecturally far superior to a hotch-podge of protocol-specific signals.  I think it would be great for this draft to encourage design and standardization of such explicit signal.

We know too well, unfortunately, that such signal, IPv6 HBH option, will not work for most of Internet traffic today (IPv4 traffic and IPv6 traffic flowing over links blocking IPv6 HBH option). The speed with which we can deploy encrypted-header protocols (i.e. QIUC) and a reliable explicit-signal-to-network HBH option differ greatly. What are we to do in the interim?

> Tom

- Igor

---

From: Tom Herbert <[email-masked]>
Date: Tue, 15 Oct 2019 16:22:10 -0700

> We know too well, unfortunately, that such signal, IPv6 HBH option, will not work for most of Internet traffic today (IPv4 traffic and IPv6 traffic flowing over links blocking IPv6 HBH option). The…
Hi Igor,

The statement that IPv6 HBH will not work for most of the Internet
traffic today is a rather broad generalization. In a sense, we could
also that IPv6 doesn't work for most of the Internet traffic. I will
accept that there is not ubiquitous support for HBH EH in all
networks, but in the same way that IPv6 can be deployed before there's
100% support we need to be able to deploy things like HBH options.
Similarly, asking what to do in the "interim" seems a bit presumptuous
as that implies there is a defined path to getting to ubiquity.
Analogously, one could say that NAT is an interim solution until IPv6
is fully supported-- but NAT has been going on for more than twenty
years, at what point is that not considered an interim solution? :-)
In other words, we can't wait for everyone to be on the same page to
deploy something.

So to me the fundamental question is more about how do we deploy new
protocols or existing protocols that are hard to deploy because of
ossification. The answer lies in answering these two questions: 1) how
do we work around the existing brokenness 2) how do we motivate fixing
the brokenness.

For the workaround, we can apply the philosophy of IPv6 "happy
eyeballs" which is essentially using probing or external information
to determine if the path to the destination supports a certain
protocol (e.g. IPv6, HBH EH, UDP, etc.). I believe there's a general
solution that might some day involve mapping the Internet to provide
hosts information about what paths are known to support what protocols
based on a priori information from the experiences of other hosts.
This also relates to one of my complaints about RFC7872 being often
quoted as the evidence that EH is not supported in the Internet. It
was a good data point, but it was just one snapshot in time and now
it's over three years old so it's starting to become stale. We really
need up to date, real time measurements of the Internet for such
things to get meaningful guidance for protocol development (I think
there was some discussion in 6man and maprg along those lines). This
also serves as the basis for an argument that not encrypting transport
headers can't be considered an interim solution.

For motivation, this seems to be a matter of demonstrating incentive
for middlebox vendors to fix their solutions. Network signaling should
be a good incentive. If the host is explicitly signaling the network
that means it has reason to do so, meaning there's some value provided
by the network. So if the network wants to provide the value based on
signals, it needs to support the signaling mechanism-- hence this is
the incentive!

Tom

---

From: Tom Herbert <[email-masked]>
Date: Tue, 15 Oct 2019 18:09:46 -0700

> Most users would likely say that they want Internet that is as fast as possible (low latency/high throughput), very reliable, secure (passwords and emails are safe from peeping toms) and reasonably…
Sure, but who are the "people" making the tradeoff? If the tradeoff of
what information to expose is left up to the user then that is
reasonable. But if network operators or IETF are arbitrarily making
this tradeoff for the user that's a problem. As Joe stated, the only
viewpoint that really matters is that of the user; their needs and
wishes come first. So if a user wants strong security and privacy,
then that's their prerogative-- in no way should they be penalized for
that.

> What else should they look at?  They have to look at packets flowing via their networks and make sense of what’s going – both proactively in terms of monitoring QoS that their customers are getting…

As  mentioned several times, the arguments the network providers are
making against header encryption are nearly identical to the ones made
when payload encryption was being turned. This conversation is almost
an exact replay of those discussions! I'm still finding it hard to
believe the outcome will be any different, like it or not any new
transport protocols are likely to encrypt as much as possible. This
shouldn't surprise anyone, it's been known for years that encryption
resolves the tussle that lead to protocol ossification. So the open
question still seems to be what is the path forward to allow strong
user privacy and yet give the network the necessary visibility above
the network layer in a secure and robust fashion.

>From draft-ietf-quic-transport-23:

"QUIC authenticates all of its headers and encrypts most of the data
it exchanges, including its signaling, to avoid incurring a dependency
on middleboxes."

In other words to prevent middleboxes from ossifying the QUIC protocol.

> Igor

---

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 16 Oct 2019 19:01:28 +0000

> On Tue, Oct 15, 2019 at 9:10 PM Tom Herbert <[email-masked]> wrote:
> 
> > Most users would likely say that they want Internet that is as fast as
> possible (low latency/high throughput), very reliable, secure (passwords and
> emails are safe from peeping toms) and reasonably private. Different people
> will make different trade-offs between the above, especially about the
> degree of privacy vs performance and reliability.
> >
> Sure, but who are the "people" making the tradeoff? If the tradeoff of what
> information to expose is left up to the user then that is reasonable. But if
> network operators or IETF are arbitrarily making this tradeoff for the user
> that's a problem.

I completely agree with this.

What trade-off operators do when they block QUIC, rate limit QUIC, etc. is a different discussion.
This draft is about what trade-offs IETF is doing, when it is removing existing signals that network can use and not providing a substitute at the same time.

> As Joe stated, the only viewpoint that really matters is that
> of the user; their needs and wishes come first. So if a user wants strong
> security and privacy, then that's their prerogative-- in no way should they be
> penalized for that.

Yes.  And if the user believes that signals to the network are not desirable for their preferred level of privacy, they should be able to instruct their client to not send those signals. Moreover, IETF should ensure that their choice is harder for the network to discriminate against; hence the requirement that endpoints that do send these signals send them for no more than 80% of the connections.

<snip>

> So the open question still seems to be what is the path
> forward to allow strong user privacy and yet give the network the necessary
> visibility above the network layer in a secure and robust fashion.

I think you have a preferred approach, and I completely agree with it -- encrypt transport header and send explicit network signals.  I see this draft to be about the consequences of doing the former without the latter.  And the tussle is about an argument that any extra signal might weaken privacy.

<snip>

> > I think it is unfortunate that security is even mentioned in this draft. Header
> encryption is not about security; it is about privacy and protocol ossification
> resistance.
> >
> "QUIC authenticates all of its headers and encrypts most of the data it
> exchanges, including its signaling, to avoid incurring a dependency on
> middleboxes."
> 

Right, a trade-off between protocol ossification and network performance/reliability is an IETF concern in its entirety, and it should be a subject for IETF debate what the trade-off should be.

Privacy is also mentioned often here, since some signals may help correlate connections. This would be a user concern (as we discussed above).

- Igor

---

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 16 Oct 2019 21:49:12 +0000

> On Tue, Oct 15, 2019 at 7:22 PM From: Tom Herbert <[email-masked]> wrote:
> 
> > > transport related information and even application layer
> > > information-- that's Hop-by-Hop Options extension header. A critical
> > > difference with parsing transport layers, is that the end host is in
> > > control of what information is exposed in HBH options. As I've said
> > > several times, I believe this draft is missing on the opportunity to
> > > propose this as the "solution" to middleboxes losing visibility because of
> encryption.
> >
> > +1
> > An explicit signal-to-network, such as IPv6 HBH option, is architecturally far
> superior to a hotch-podge of protocol-specific signals.  I think it would be
> great for this draft to encourage design and standardization of such explicit
> signal.
> >
> > We know too well, unfortunately, that such signal, IPv6 HBH option, will
> not work for most of Internet traffic today (IPv4 traffic and IPv6 traffic
> flowing over links blocking IPv6 HBH option). The speed with which we can
> deploy encrypted-header protocols (i.e. QIUC) and a reliable explicit-signal-
> to-network HBH option differ greatly. What are we to do in the interim?
> >
> Hi Igor,
> 
> The statement that IPv6 HBH will not work for most of the Internet traffic
> today is a rather broad generalization. In a sense, we could also that IPv6
> doesn't work for most of the Internet traffic. I will accept that there is not
> ubiquitous support for HBH EH in all networks, but in the same way that IPv6
> can be deployed before there's 100% support we need to be able to deploy
> things like HBH options.

I am NOT saying "don't define an IPv6 HBH EH that would solve this problem, because it would not work everywhere".  Quite the opposite -- we should do something like IPv6 HBH EH, because all traffic should be IPv6 w/ HBH EH working in the future.

The argument is that we should _also_ do something, possibly temporary, to take care of the very significant portion of the network where IPv6 w/ HBH EH does not work today.  (I know that temporary things have a tendency to last forever, and it stinks, but we are talking about a very large portion of the traffic today.)

<snip>

> ossification. The answer lies in answering these two questions: 1) how do we
> work around the existing brokenness 2) how do we motivate fixing the
> brokenness.
> 
> For the workaround, we can apply the philosophy of IPv6 "happy eyeballs"
> which is essentially using probing or external information to determine if the
> path to the destination supports a certain protocol (e.g. IPv6, HBH EH, UDP,
> etc.).

The "brokenness" this draft points to is the lack of network signals.  IPv6 HBH workaround is good, but it would not help for the majority of connections today.  So the workaround is incomplete.

<snip>

> For motivation, this seems to be a matter of demonstrating incentive for
> middlebox vendors to fix their solutions. Network signaling should be a good
> incentive.

Yes, complete agreement here. A useful signal that cannot be received by a device is a good incentive for the operators to fix the device or to buy a different one. But while filtering IPv6 HBH EH is up to the operators, the use of IPv4 instead of IPv6 on a dual-protocol network is out of operators' control, so operator incentives are not a complete solution, unfortunately.

- Igor

---

From: Tom Herbert <[email-masked]>
Date: Wed, 16 Oct 2019 15:24:45 -0700

> Yes, complete agreement here. A useful signal that cannot be received by a device is a good incentive for the operators to fix the device or to buy a different one. But while filtering IPv6 HBH EH…

That's why we're looking at HBH options for IPv4 also
(draft-herbert-ipv4-hbh-destopt-00).

Tom

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 17 Oct 2019 09:10:17 +0000

Hi,

In my view the draft expands the text in RFC7258 "Making networks unmanageable to mitigate PM is not an acceptable outcome,  but ignoring PM would go against the consensus documented here.  An  appropriate balance will emerge over time as real instances of this  tension are considered." . There is no more text in RFC7258 that discuss what should an unacceptable outcome.

It is not biased  since it complements RFC7258 and RFC7624 as described in the introduction "Encryption of transport layer headers and  payload data has many benefits in terms of protecting user privacy.

   These benefits have been widely discussed [RFC7258<https://tools.ietf.org/html/rfc7258>], [RFC7624<https://tools.ietf.org/html/rfc7624>], and  this document strongly supports the increased use of encryption in  transport protocols. "

In my view it represent not only the view of the middlebox vendors but also among others, the operators that need to manage their networks .

Roni Even

From: tsvwg [mailto:[email-masked]] On Behalf Of Christian Huitema
Sent: Wednesday, October 09, 2019 5:33 PM
To: Black, David; [email-masked]
Subject: Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

As the draft mentions:

   and users

-- Christian Huitema

On 10/8/2019 2:08 PM, Black, David wrote:
FYI - some OPS area and SEC area eyes on this TSVWG draft now (during WGLC) would be a good thing ;-).

From: Black, David <[email-masked]><mailto:[email-masked]>
Sent: Tuesday, October 8, 2019 5:06 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Black, David
Subject: WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

Comments should be sent to the [email-masked]<mailto:[email-masked]> list, although purely

WG chairs at [email-masked]<mailto:[email-masked]>  if you would like the chairs to

Thanks,

David, Gorry and Wes

(TSVWG Co-Chairs)

saag mailing list

---

From: "Lubashev, Igor" <[email-masked]>
Date: Mon, 21 Oct 2019 04:04:10 +0000

> On Wed, Oct 16, 2019 at 6:25 PM Tom Herbert <[email-masked]> wrote:
> 
> > > > > On Sat, Oct 12, 2019 at 12:02 PM Tom Herbert
> > > > > <[email-masked]>
> > > wrote:
> > > > >
> > > > > I do believe that there will be valid use cases for hosts to
> > > > > signal the network for services. There is a least one robust,
> > > > > explicit, and transport agnostic method to allow hosts to signal
> > > > > the network with transport related information and even
> > > > > application layer
> > > > > information-- that's Hop-by-Hop Options extension header. A
> > > > > critical difference with parsing transport layers, is that the
> > > > > end host is in control of what information is exposed in HBH
> > > > > options. As I've said several times, I believe this draft is
> > > > > missing on the opportunity to propose this as the "solution" to
> > > > > middleboxes losing visibility because of
> > > encryption.
> > > >
> > > > +1
> > > superior to a hotch-podge of protocol-specific signals.  I think it
> > > would be great for this draft to encourage design and
> > > standardization of such explicit signal.
> > > >
> > > not work for most of Internet traffic today (IPv4 traffic and IPv6
> > > traffic flowing over links blocking IPv6 HBH option). The speed with
> > > which we can deploy encrypted-header protocols (i.e. QIUC) and a
> > > reliable explicit-signal- to-network HBH option differ greatly. What are we
> to do in the interim?
> > > >
> > > Hi Igor,
> > >
> > > networks, but in the same way that IPv6 can be deployed before
> > > there's 100% support we need to be able to deploy things like HBH
> options.
> >
> > I am NOT saying "don't define an IPv6 HBH EH that would solve this
> problem, because it would not work everywhere".  Quite the opposite -- we
> should do something like IPv6 HBH EH, because all traffic should be IPv6 w/
> HBH EH working in the future.
> >
> > The argument is that we should _also_ do something, possibly
> > temporary, to take care of the very significant portion of the network
> > where IPv6 w/ HBH EH does not work today.  (I know that temporary
> > things have a tendency to last forever, and it stinks, but we are
> > talking about a very large portion of the traffic today.)
> >
> > <snip>
> >
> > > ossification. The answer lies in answering these two questions: 1)
> > > how do we work around the existing brokenness 2) how do we motivate
> > > fixing the brokenness.
> > >
> eyeballs"
> > > which is essentially using probing or external information to
> > > determine if the path to the destination supports a certain protocol
> > > (e.g. IPv6, HBH EH, UDP, etc.).
> >
> > The "brokenness" this draft points to is the lack of network signals.  IPv6
> HBH workaround is good, but it would not help for the majority of
> connections today.  So the workaround is incomplete.
> >
> > <snip>
> >
> > > for middlebox vendors to fix their solutions. Network signaling
> > > should be a good incentive.
> >
> > Yes, complete agreement here. A useful signal that cannot be received by a
> device is a good incentive for the operators to fix the device or to buy a
> different one. But while filtering IPv6 HBH EH is up to the operators, the use
> of IPv4 instead of IPv6 on a dual-protocol network is out of operators'
> control, so operator incentives are not a complete solution, unfortunately.
> >
> 
> That's why we're looking at HBH options for IPv4 also (draft-herbert-ipv4-
> hbh-destopt-00).

The concern expressed here is the encryption of usable signals and the lack of alternatives deployed within the same timeframe.  The language in draft-herbert-ipv4-hbh-destopt-00 states that "it is unlikely that packets with IPv4 Hop-by-Hop Options or Destination Options extension headers can be ubiquitously deployed over the Internet".

The goal of any "for the network" signal is improved QoS.  Hence, if there is a non-trivial chance that inclusion of such signal will actually degrade QoS (by causing packets with the signal to be dropped), no sender will include such signals (and "happy eyeballs" style code is too complex and risky for the benefit).

As architecturally "ugly" as it sounds, I can only see the QUIC header and the most significant TTL bits as viable alternatives to be deployable widely on the Internet for IPv4.  For IPv6, even HBH and Dest Options are still too "risky" for packets, but that is likely to be improving.

(Tom, are you interested in something like ConEx RFC 7837, except with HBH Options instead of Destination Options?)

- Igor

---

From: Tom Herbert <[email-masked]>
Date: Mon, 21 Oct 2019 07:31:21 -0700

On Sun, Oct 20, 2019, 9:04 PM Lubashev, Igor <[email-masked]> wrote:

> The concern expressed here is the encryption of usable signals and the
> lack of alternatives deployed within the same timeframe.  The language in
> draft-herbert-ipv4-hbh-destopt-00 states that "it is unlikely that packets
> with IPv4 Hop-by-Hop Options or Destination Options extension headers can
> be ubiquitously deployed over the Internet".
>

Igor,

That misses the point of the statement. There are many protocols that don't
have ubiquitous support over the Internet-- EH, IP fragmentation, any
transport protocol other than TCP and sometimes UDP, and even IPv6. If
"ubiquitous support" is required for deployment then we can never deploy
new protocols or any protocol that is atypical to intermediate devices. So,
unless we're planning on never doing anything new on the Internet, we need
to address this.

> The goal of any "for the network" signal is improved QoS.  Hence, if there
> is a non-trivial chance that inclusion of such signal will actually degrade
> QoS (by causing packets with the signal to be dropped), no sender will
> include such signals (and "happy eyeballs" style code is too complex and
> risky for the benefit).
>
> As architecturally "ugly" as it sounds, I can only see the QUIC header and
> the most significant TTL bits as viable alternatives to be deployable
> widely on the Internet for IPv4.  For IPv6, even HBH and Dest Options are
> still too "risky" for packets, but that is likely to be improving.
>

You forgot to mention efforts to encode information in IP addresses,
overload bits in the flow label, or other DPI parsing of UDP payload (like
tunnels over UDP), and other creative ways to "find" bits that can be
repuposed. There're all hacks! IP is designed to be an extensible protocol
without the need for these. Pursuing such hacks, instead of using the
defined mechanisms of extensibility, ostensibly solves some short term
problems, but in the long run perpetuates protocol ossification and stifles
evolution of the Internet.

Tom

---

From: Christian Huitema <[email-masked]>
Date: Mon, 21 Oct 2019 11:19:57 -0700

On 10/21/2019 7:31 AM, Tom Herbert wrote:
> Igor,
>
> That misses the point of the statement. There are many protocols that
> don't have ubiquitous support over the Internet-- EH, IP
> fragmentation, any transport protocol other than TCP and sometimes
> UDP, and even IPv6. If "ubiquitous support" is required for deployment
> then we can never deploy new protocols or any protocol that is
> atypical to intermediate devices. So, unless we're planning on never
> doing anything new on the Internet, we need to address this.
>
>
>     The goal of any "for the network" signal is improved QoS.  Hence,
>     if there is a non-trivial chance that inclusion of such signal
>     will actually degrade QoS (by causing packets with the signal to
>     be dropped), no sender will include such signals (and "happy
>     eyeballs" style code is too complex and risky for the benefit).
>
>     As architecturally "ugly" as it sounds, I can only see the QUIC
>     header and the most significant TTL bits as viable alternatives to
>     be deployable widely on the Internet for IPv4.  For IPv6, even HBH
>     and Dest Options are still too "risky" for packets, but that is
>     likely to be improving.
>
>
> overload bits in the flow label, or other DPI parsing of UDP payload
> (like tunnels over UDP), and other creative ways to "find" bits that
> can be repuposed. There're all hacks! IP is designed to be an
> extensible protocol without the need for these. Pursuing such hacks,
> instead of using the defined mechanisms of extensibility, ostensibly
> solves some short term problems, but in the long run perpetuates
> protocol ossification and stifles evolution of the Internet.

If we want to not rely on hacks, I believe that we have to somehow
change the network protocol. I have followed the development of the spin
bit in QUIC, and the attempts to use more bits and provide for example
indications of packet losses. There are typically two issues: privacy
and practicality. Let's not discuss privacy here, except by assuming
that privacy-sensitive deployments will find a need to "bleach" the
signals. The signals are still useful for connection management as long
as a large enough fraction of the connections are not bleached.

I think that solving the "practicality" issue requires moving the signal
to the IP layer. The experiments by Orange show that you only need a
small number of bits to monitor latency and loss rate from within the
network - 2 or maybe 3 bits would do. If these bits are in the transport
header, the network monitor has first to find out what transport
protocol is in use, and possibly what version. With encrypted
transports, that could soon become a daunting task. On the other hand,
if the bits are at some fixed position in the IP header, monitoring
becomes much simpler.

My personal preference would be to associate these bits with an IPv6
"flow" label, or for IPv4 the five-tuple. Latency is associated with
routing and with applications, and in theory all packets in a flow share
the same routing and the same kind of end-to-end processing. Of course,
there are deployment issues, bleaching issues, etc. But the logic
remains: associating latency and loss measurement with a packet flow
makes the most sense. Moving that to the IP header also makes sense --
after all, it is very similar to ECN signals. The broad line of the
solution would thus be:

1) Steal a couple of end to end bits, or maybe just 4 to 8 Diffserv code
points

2) Use these bits to encode the "spin" and "loss" indications, and
distinguish them from the "bleached" signal

3) Compute the "spin" and "loss" indications per end-to-end flow, and
make that part of the spec.

There are obvious deployment issue, bleaching paths and all that. But at
the same time, the information is meant to benefit network management,
so there will be a strong incentive for network managers to ensure that
it flows freely. Thus, it is not hopeless.

-- Christian Huitema

---

From: Kuhn Nicolas <[email-masked]>
Date: Thu, 24 Oct 2019 10:19:48 +0000

Hi,

As far as I can see, there are different ways of signaling losses that are being discussed.
Here is an attempt of discussing advantages and drawbacks of each approach.
I believe that going for : short-term QUIC-bits and long-term TSVWG-bits is a good way forward. Moreover, this does not prevent from also having layer IP solutions.

-              Using IP level bits
Advantage : long term solution that is compatible for any upper-layer protocol
Drawback : compatibility with L2 tunnel solutions, problems in making it for IPv4 and IPv6 and only Q bit (upstream loss) is doable (L bit must be sent by sender for end-to-end loss evaluation)
-              Using new QUIC bits
Advantage : quick deployment of the solution and simple solution
Drawback : specific to QUIC
-              Generic transport solution
Advantage : standard solution for any transport
Drawback : “time-to-market” and only Q bit (upstream loss) is doable (L bit must be sent by sender for end-to-end loss evaluation)
-              Using OAM information
Advantage : management plane focusing on management functions – clearer interfaces between control, data and management planes
Drawback : need for standard interfaces between the different equipment that may follow other standard (IEEE, 3GPP) and management of “old” network still in operation
The privacy issues that are said to be specific to QUIC solution are inherent to any solution IMHO.

My 2cts,

Nico

De : tsvwg <[email-masked]> De la part de Christian Huitema
Envoyé : lundi 21 octobre 2019 20:20
À : Tom Herbert <[email-masked]>; Lubashev, Igor <[email-masked]>
Cc : Joe Touch <[email-masked]>; [email-masked]
Objet : Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

That misses the point of the statement. There are many protocols that don't have ubiquitous support over the Internet-- EH, IP fragmentation, any transport protocol other than TCP and sometimes UDP, and even IPv6. If "ubiquitous support" is required for deployment then we can never deploy new protocols or any protocol that is atypical to intermediate devices. So, unless we're planning on never doing anything new on the Internet, we need to address this.

You forgot to mention efforts to encode information in IP addresses, overload bits in the flow label, or other DPI parsing of UDP payload (like tunnels over UDP), and other creative ways to "find" bits that can be repuposed. There're all hacks! IP is designed to be an extensible protocol without the need for these. Pursuing such hacks, instead of using the defined mechanisms of extensibility, ostensibly solves some short term problems, but in the long run perpetuates protocol ossification and stifles evolution of the Internet.

If we want to not rely on hacks, I believe that we have to somehow change the network protocol. I have followed the development of the spin bit in QUIC, and the attempts to use more bits and provide for example indications of packet losses. There are typically two issues: privacy and practicality. Let's not discuss privacy here, except by assuming that privacy-sensitive deployments will find a need to "bleach" the signals. The signals are still useful for connection management as long as a large enough fraction of the connections are not bleached.

I think that solving the "practicality" issue requires moving the signal to the IP layer. The experiments by Orange show that you only need a small number of bits to monitor latency and loss rate from within the network - 2 or maybe 3 bits would do. If these bits are in the transport header, the network monitor has first to find out what transport protocol is in use, and possibly what version. With encrypted transports, that could soon become a daunting task. On the other hand, if the bits are at some fixed position in the IP header, monitoring becomes much simpler.

My personal preference would be to associate these bits with an IPv6 "flow" label, or for IPv4 the five-tuple. Latency is associated with routing and with applications, and in theory all packets in a flow share the same routing and the same kind of end-to-end processing. Of course, there are deployment issues, bleaching issues, etc. But the logic remains: associating latency and loss measurement with a packet flow makes the most sense. Moving that to the IP header also makes sense -- after all, it is very similar to ECN signals. The broad line of the solution would thus be:

1) Steal a couple of end to end bits, or maybe just 4 to 8 Diffserv code points

2) Use these bits to encode the "spin" and "loss" indications, and distinguish them from the "bleached" signal

3) Compute the "spin" and "loss" indications per end-to-end flow, and make that part of the spec.

There are obvious deployment issue, bleaching paths and all that. But at the same time, the information is meant to benefit network management, so there will be a strong incentive for network managers to ensure that it flows freely. Thus, it is not hopeless.

-- Christian Huitema

---

From: <[email-masked]>
Date: Thu, 24 Oct 2019 14:38:13 +0000

Nico,

Please can you explain your comment about the L bit: “only Q bit (upstream loss) is doable (L bit must be sent by sender for end-to-end loss evaluation)” Surely both the Q & the L bit are set by the sender?

I’d prefer a generic solution rather than one for one transport protocol.

I think it’s worth looking at https://tools.ietf.org/html/rfc7837    This defined an IPv6<https://tools.ietf.org/html/rfc7837%20This%20defined%20an%20IPv6> destination option for carrying ConEx markings in IPv6 datagrams. I think its L bit is identical to your L bit. RFC7837 also has 4 reserved bits so a bis would have plenty of room for Q bit.

https://tools.ietf.org/html/rfc7837#section-3  discusses why the WG chose a destination option.

There seems to me a lot of similarity between the Conex work and this work, both in objectives & method. The Q bit is new since conex, and seems to offer some advantage of a clearer signal about upstream loss, under some assumptions.

Best wishes,
phil

From: tsvwg [mailto:[email-masked]] On Behalf Of Kuhn Nicolas
Sent: 24 October 2019 11:20
To: 'Christian Huitema' <[email-masked]>; Tom Herbert <[email-masked]>; Lubashev, Igor <[email-masked]>
Cc: Joe Touch <[email-masked]>; [email-masked]
Subject: Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

Hi,

-              Using IP level bits

My 2cts,

Nico

De : tsvwg <[email-masked]<mailto:[email-masked]>> De la part de Christian Huitema
Envoyé : lundi 21 octobre 2019 20:20
À : Tom Herbert <[email-masked]<mailto:[email-masked]>>; Lubashev, Igor <[email-masked]<mailto:[email-masked]>>
Cc : Joe Touch <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Objet : Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

-- Christian Huitema

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 24 Oct 2019 15:53:44 +0000

In ConEx, we also get upstream congestion by subtracting the ECN CE marks form the ConEx ECN marks, or count TCP seq# holes and subtract that number from the ConEx Loss marks. Of course the latter is not possible with QUIC and you would need something like the Q bit instead which however is basically Alternate-marking as defined in RFC8321.

From: tsvwg <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Thursday, 24. October 2019 at 16:38
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

Nico,

Best wishes,
phil

Hi,

-              Using IP level bits

My 2cts,

Nico

-- Christian Huitema

---

From: <[email-masked]>
Date: Thu, 24 Oct 2019 16:10:53 +0000

Hi,

My view on the draft is that a section is missing.

I suggest adding a section 7 named "end-to-end interdomain OAM" to bridge iOAM and OAM of end-to-end encrypted flows. The content of the section might relies on the following:

Fast interdomain troubleshooting requires a minimal interoperability to estimate delay and packet loss.
QUIC spinbit approach is an example which supports end-to-end interdomain OAM. The signal exposed is end-to-end protected and not encrypted; its enforcement is under the control of the endpoint; its activation is limited to a small percentage of the flows.

Here are other comments on the draft. I read the draft very quickly so several ones might be inappropriate:

·         Encryption and protection should be clearly separated;

o    TCPcrypt header protection (part end-to-end encrypted, part end-to-end protected and on-path readable) mechanism ;

o    QUIC spinbit protection (end-to-end protected and on-path readable);

·         QUIC spinbit on-path troubleshooting properties : applies to interdomain;

·         DTLS on-path troubleshooting properties might be described;

·         Not sure that the draft recall transport proxies usage, like for satco;

·         Security section should highlight the privacy risk when on-path probes have to do whole packet decryption to get header information ;

Regards
Emile

De : saag [mailto:[email-masked]] De la part de Black, David
Envoyé : mardi 8 octobre 2019 23:09
À : [email-masked]; [email-masked]
Cc : tsvwg-chairs
Objet : [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

Thanks,

David, Gorry and Wes

(TSVWG Co-Chairs)

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 24 Oct 2019 21:38:34 +0000

ConEx tries to address the right set of questions, albeit the only proposed solution was for IPv6.

I like ConEx’s including an ECN CE Echo bit, since that lets you determine upstream and downstream congestion (if it happens on an ECN-supporting device). It is valuable for protocols that encrypt transport’s CE Echo information (like QUIC).  The combination of Q-bits (as in RFC 8321) and L-bits (as in ConEx) would let you do the same for loss.  A Spin-bit would be a useful addition for measurement, albeit it would require cooperation of both endpoints.

  *   Igor

P.S.
  There is work in ippm (draft-cfb-ippm-spinbit-new-measurements) that also attempts to use bits to inform the network about loss. That alternative does not require observer inferring Q-bit period (some power-of-2), but it requires both endpoints cooperating (which affects deployability) and can only detect loss of a minority of packets (fewer than 1/4 of server-to-client packets will typically have markings whose loss can be detected).

From: Mirja Kuehlewind <[email-masked]>
Sent: Thursday, October 24, 2019 11:54 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Lubashev, Igor <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

From: tsvwg <[email-masked]<mailto:[email-masked]>> on behalf of "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 24. October 2019 at 16:38
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

Nico,

I think it’s worth looking at https://tools.ietf.org/html/rfc7837<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7837&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=e78wvO7sMQ1OPb7LbdJ_VnbfcyceRVPepLvIuj98Woo&s=XqGR97CccV-6CMMzb-eeKiHHqx7DZbA_0VA0Bs031y4&e=>    This defined an IPv6<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7837-2520This-2520defined-2520an-2520IPv6&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=e78wvO7sMQ1OPb7LbdJ_VnbfcyceRVPepLvIuj98Woo&s=Vo5lTS0Qy4xW-ioc1-o1zIfIXWlcw0gJpDabAPOuSOY&e=> destination option for carrying ConEx markings in IPv6 datagrams. I think its L bit is identical to your L bit. RFC7837 also has 4 reserved bits so a bis would have plenty of room for Q bit.

https://tools.ietf.org/html/rfc7837#section-3<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7837-23section-2D3&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=e78wvO7sMQ1OPb7LbdJ_VnbfcyceRVPepLvIuj98Woo&s=FTyahheiTLt2hB9tJ0CxCtWPdcYLYjB6qdaaInTFUSA&e=>  discusses why the WG chose a destination option.

Best wishes,
phil

From: tsvwg [mailto:[email-masked]] On Behalf Of Kuhn Nicolas
Sent: 24 October 2019 11:20
To: 'Christian Huitema' <[email-masked]<mailto:[email-masked]>>; Tom Herbert <[email-masked]<mailto:[email-masked]>>; Lubashev, Igor <[email-masked]<mailto:[email-masked]>>
Cc: Joe Touch <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

Hi,

-              Using IP level bits

My 2cts,

Nico

-- Christian Huitema