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

From: Tom Herbert <[email-masked]>
Date: Fri, 28 Feb 2020 12:30:22 -0800

While the draft certainly has improved both in tone and content, I
still feel like there is one area that is very under-represented.
Namely the possibility of using extension headers to carry necessary
transport information that the network needs. I have brought this up
several times, and don't believe it has been adequately addressed.

Section 5 discusses extension headers (in a rather offhand manner). It
is presented in a very negative light focused on the why they won't
work. The crux of the argument in the draft is that extension headers
are not deployable, RFC7872 is referenced as the basis for that
conclusion. But as we pointed out, and even acknowledged in the draft
text now, that is from 2016, so the data and questionable. But even if
it were still relevant the conclusion drawn from it that EHs are not
usable in any form is highly debatable.

What the draft fails to mention is that Hop-by-Hop extensions headers
are the ONLY protocol conformant way to signal intermediate nodes with
data, including transport layer information, other than what is
contained in the IP header. Intermediate nodes that parse packets
beyond the network layer are not protocol conformant. This is not just
an academic purist statement, this is DPI which is what has led to
protocol ossification and hence is a primary motivation for transport
headers being encrypted in the first place (see QUIC reasoning on
this). Extension headers are also being dismissed because of protocol
non-conformance in intermediate nodes. As often noted, RFC8200 has
relaxed requirements concerning HBH options so that intermediate nodes
can ignore. I believe that RFC8200 was published after RFC7828
potential impact of that change was not measured.

So then one interpretation of the draft is that it is trying to
justify one type of protocol non-conformance, on the basis it is
useful in practice, yet on the other hand rejects the correct solution
to the problem on the because of another type of protocol
non-conformance making it not deployable. There seems to be a
significant irony at work here.

Tom

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 28 Feb 2020 15:02:15 -0600

Hi, Tom,

> Section 5 discusses extension headers (in a rather offhand manner). It

You're talking about Section 5.2, right?

> significant irony at work here.

ISTM that the draft (if we're talking about 5.2) is talking about
interdomain use of hop-by-hop extension headers, which might reasonably be
deployed in a domain that you make decisions about (the subject of 5.1),
but are (let's say) more challenging to deploy if you're expecting them to
work between arbitrary endpoints attached to arbitrary domains,
interconnected over arbitrary topologies.

I don't disagree with the points you're making, but ISTM that if the
working group wants to say hop-by-hop extension headers can be a plan, that
should appear in 5.1, unless someone can point to at least one success
story of hop-by-hop extension headers being widely deployed and used across
domain boundaries.

Best,

Spencer

---

From: Erik Kline <[email-masked]>
Date: Fri, 28 Feb 2020 16:10:26 -0800

It also seems possible that some UDP options (
https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options) might come along
that could help things like QUIC effectively have a path-modifiable portion
that (a) isn't a HbH extension header and (b) isn't covered by something
cryptographic that would break if it were modified in-flight.

On Fri, Feb 28, 2020 at 1:03 PM Spencer Dawkins at IETF <
[email-masked]> wrote:

> Hi, Tom,
>
> On Fri, Feb 28, 2020 at 2:31 PM Tom Herbert <tom@herbertland..com
> <[email-masked]>> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 28 Feb 2020 16:17:42 -0800

On Fri, Feb 28, 2020, 4:10 PM Erik Kline <[email-masked]> wrote:

> https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options) might come
> along that could help things like QUIC effectively have a path-modifiable
> portion that (a) isn't a HbH extension header and (b) isn't covered by
> something cryptographic that would break if it were modified in-flight.
>

Erik,

"things like QUIC" would mean protocols encapsulated in UDP. The point of
HBH is that it works transparently for _all_ transport protocols whether
they are encrypted. Besides, UDP options hasn't yet been proven deployable,
so good chance it would just be trading one set of problems for another...

Tom

---

From: Joseph Touch <[email-masked]>
Date: Fri, 28 Feb 2020 18:03:47 -0800

> several times, and don't believe it has been adequately addressed.

Tom, 

I thought the draft explains (IMO correctly) that the transport layer can make info available to the network layer, but that’s how it works. We shouldn’t expect that the transport header itself is available (for security and privacy reasons).

Joe

---

From: Joseph Touch <[email-masked]>
Date: Fri, 28 Feb 2020 18:05:02 -0800

> On Feb 28, 2020, at 4:10 PM, Erik Kline <[email-masked]> wrote:
> 
> It also seems possible that some UDP options (https://tools.ietf..org/html/draft-ietf-tsvwg-udp-options <https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options>) might come along that could help things like QUIC effectively have a path-modifiable portion that (a) isn't a HbH extension header and (b) isn't covered by something cryptographic that would break if it were modified in-flight.

No; that header is not intended to be modified on-path (it can be authenticated, in particular).

On-path mods should happen at the IP layer. The transport layer should be seeing only the transport endpoints, not routers.

Joe

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 28 Feb 2020 18:06:33 -0800

> so good chance it would just be trading one set of problems for another...

Also, UDP options as specified in the current WG draft are not intended to
be modifiable in flight:

   >> Options MUST NOT be modified in transit. This includes those
   already defined as well as new options. New options MUST NOT require
   or intend optionally for modification of any UDP options, including
   their new areas, in transit.

 Mike Heard

---

From: Tom Herbert <[email-masked]>
Date: Fri, 28 Feb 2020 18:17:15 -0800

On Fri, Feb 28, 2020, 6:03 PM Joseph Touch <[email-masked]> wrote:

> I thought the draft explains (IMO correctly) that the transport layer can
> make info available to the network layer, but that’s how it works. We
> shouldn’t expect that the transport header itself is available (for
> security and privacy reasons).
>

Joe,

If I understand the draft correctly, it is describing a number of use cases
where intermediate nodes are extracting information directly from transport
headers. When transport layer header is encrypted that ability is lost and
the network can't use transport layer information to the benefit of the
user. The idea of putting the necessary information elsewhere in the packet
in cleartext is what HBH could provide.

Tom

---

From: Joseph Touch <[email-masked]>
Date: Fri, 28 Feb 2020 18:23:00 -0800

> On Feb 28, 2020, at 6:17 PM, Tom Herbert <[email-masked]> wrote:
> 
> 
> 
> On Fri, Feb 28, 2020, 6:03 PM Joseph Touch <[email-masked] <mailto:[email-masked]>> wrote:
> On Feb 28, 2020, at 12:30 PM, Tom Herbert <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> If I understand the draft correctly, it is describing a number of use cases where intermediate nodes are extracting information directly from transport headers. When transport layer header is encrypted that ability is lost and the network can't use transport layer information to the benefit of the user. The idea of putting the necessary information elsewhere in the packet in cleartext is what HBH could provide.

Certainly - but the HBH header would be at the network layer, not transport, right? (I got the impression you were hinting at a cleartext part of the transport header for this purpose)

Joe

---

From: Tom Herbert <[email-masked]>
Date: Fri, 28 Feb 2020 18:29:20 -0800

On Fri, Feb 28, 2020, 6:23 PM Joseph Touch <[email-masked]> wrote:

> If I understand the draft correctly, it is describing a number of use
> cases where intermediate nodes are extracting information directly from
> transport headers. When transport layer header is encrypted that ability is
> lost and the network can't use transport layer information to the benefit
> of the user. The idea of putting the necessary information elsewhere in the
> packet in cleartext is what HBH could provide.
>
>
> Certainly - but the HBH header would be at the network layer, not
> transport, right? (I got the impression you were hinting at a cleartext
> part of the transport header for this purpose)
>

Right, that's a proposal for sender to explicitly put transport related
information in network layer for consumption by the network. I think the
draft advocates that transport designers consider selectively not
encrypting fields in transport header for benefit of network.

Tom

---

From: Joseph Touch <[email-masked]>
Date: Fri, 28 Feb 2020 18:34:41 -0800

> On Feb 28, 2020, at 6:29 PM, Tom Herbert <[email-masked]> wrote:
> 
> 
> 
> On Fri, Feb 28, 2020, 6:23 PM Joseph Touch <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> ...
>> Joe,
>> 
> Right, that's a proposal for sender to explicitly put transport related information in network layer for consumption by the network. I think the draft advocates that transport designers consider selectively not encrypting fields in transport header for benefit of network.

AFAICT, the draft seemed to indicate either one was a possible way forward. Given it isn’t making recommendations, is there more missing?

Joe

---

From: Erik Kline <[email-masked]>
Date: Fri, 28 Feb 2020 19:27:41 -0800

>    their new areas, in transit.
I find that a little sad, actually.  I would expect UDP MSS clamping to be
a thing (in the absence of an AH it should be fine).

I understand the architectural impurity of it, but I also feel like TCP MSS
clamping is the only path MTU mechanism that has a great success rate of
working in the Internet -- for better or worse.  Forbidding UDP MSS
clamping seems to me to be ignoring this state of affairs.

---

From: Joseph Touch <[email-masked]>
Date: Fri, 28 Feb 2020 20:15:06 -0800

> On Feb 28, 2020, at 7:27 PM, Erik Kline <[email-masked]> wrote:
> 
> 
> 
> On Fri, Feb 28, 2020 at 6:06 PM C. M. Heard <[email-masked] <mailto:[email-masked]>> wrote:
> On Fri, Feb 28, 2020 at 4:18 PM Tom Herbert <[email-masked] <mailto:[email-masked]>> wrote:
> On Fri, Feb 28, 2020, 4:10 PM Erik Kline <[email-masked] <mailto:[email-masked]>> wrote:
> It also seems possible that some UDP options (https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options <https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options>) might come along that could help things like QUIC effectively have a path-modifiable portion that (a) isn't a HbH extension header and (b) isn't covered by something cryptographic that would break if it were modified in-flight.
> 
> "things like QUIC" would mean protocols encapsulated in UDP. The point of HBH is that it works transparently for _all_ transport protocols whether they are encrypted. Besides, UDP options hasn't yet been proven deployable, so good chance it would just be trading one set of problems for another...
> 
> Also, UDP options as specified in the current WG draft are not intended to be modifiable in flight:
> 
> I find that a little sad, actually.  I would expect UDP MSS clamping to be a thing (in the absence of an AH it should be fine).

As discussed on the UDP options draft, the option is more relevant to signal end host reassembly limits, which are not affected by the effects of on-path tunnels.

(That’s actually how MSS is defined for TCP as well, FWIW; the fact that it’s used for something else seems to be an error that hasn’t been consistently noted).

Joe

---

From: "Gorry (erg)" <[email-masked]>
Date: Sat, 29 Feb 2020 14:20:20 +0000

I’d expect the most likely method to work for detecting  path packet size for UDP would be an end to end proving method, such as: draft-ietf-tsvwg-datagram-plpmtud

See also:
1. Network layer style MSS-clamping:
- draft-hinden-6man-mtu-option

2. End to end UDP plpmtud probing using the UDP options space;
- draft-fairhurst-tsvwg-udp-options-dplpmtud

Gorry

> On 29 Feb 2020, at 04:15, Joseph Touch <[email-masked]> wrote:
> 
> 
> 
>>>>> It also seems possible that some UDP options (https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options) might come along that could help things like QUIC effectively have a path-modifiable portion that (a) isn't a HbH extension header and (b) isn't covered by something cryptographic that would break if it were modified in-flight.
>>>> 
>>>>