[tsvwg] draft-ietf-tsvwg-transport-encrypt & extension headers

["Black, David" <[e-mail]>]

Returning to Tom’s original comment, writing as draft shepherd (not as a WG chair) towards figuring out what to do, I believe Tom’s comment is focused on this paragraph in Section 5.2:

   Current measurement results suggest that it could currently be
   undesirable to rely on methods requiring end-to-end support of
   network options or extension headers across the Internet.  IPv4
   network options are often not supported (or are carried on a slower
   processing path) and some IPv6 networks have been observed to drop
   packets that set an IPv6 header extension (e.g., results from 2016 in
   [RFC7872<https://tools.ietf.org/html/rfc7872>]).

The rest of the material in Section 5 appears to be relatively neutral on this topic, and if one consults the other references cited in that section (RFC 8558, draft-ietf-ippm-ioam-data, and RFC 8250), one finds that all of them mention IPv6 extensions/options, and tend to do so without strongly opining on deployability.  Beyond that, I tend to view Tom’s (correct, AFAIK) statement about standards compliance as being peripheral to this draft’s focus on operational and other practical considerations.  So, the above paragraph could be reworded to improve balance while still conveying the important information, e.g.:

   Additional considerations apply to use of
   methods requiring end-to-end support of
   network options or extension headers across the Internet.  IPv4
   network options may not be supported (or may utilize a slower
   processing path) and some IPv6 networks have been observed to drop
   packets that set an IPv6 header extension (e.g., results from 2016 in
   [RFC7872<https://tools.ietf.org/html/rfc7872>]).

It would be helpful to cite a reference that covers IPv4 options and especially pitfalls in using them, e.g., the consequences of slower and resource-limited processing paths.  The extensive discussion of Router Alert in RFC 6398 (BCP 168) would be one possibility.

Thanks, --David (as draft shepherd, not as WG chair)

From: tsvwg <[e-mail]> On Behalf Of Spencer Dawkins at IETF
Sent: Friday, February 28, 2020 4:02 PM
To: Tom Herbert
Cc: tsvwg
Subject: Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt


[EXTERNAL EMAIL]
Hi, Tom,

On Fri, Feb 28, 2020 at 2:31 PM Tom Herbert <tom@herbertland..com<mailto:[e-mail]>> wrote:
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

You're talking about Section 5.2, right?

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.

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

Tom