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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Tom,

On Fri, Feb 28, 2020 at 2:31 PM Tom Herbert <[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
>
>