[tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-14

[Tom Herbert <[e-mail]>]

Hi, a few comments.

I don't understand this statement from the draft:

"The value of this information would be enhanced if the exposed
information could be verified to match the internal state of the
transport by observing the transport behaviour."

I assume this means that the network nodes would need to understand
the internal state of transport protocols. How would this work?

If the idea is that the exposed information is somehow verified with
the endpoints that securely provide the information then maybe I
understand that. But, if the idea is that intermediate nodes need to
autonomously deduce the internal state themselves, I think that is
problematic. Aside from all the known problems that stateful network
devices have caused, there seems to be a circular dependency here.
AFAIK the only way to deduce the internal state of a transport
connection in the network would be by inspecting the exposed transport
information, but this statement seems to be saying the exposed
information can't be trusted unless the internal state has been
deduced. Am I missing something?

>From the draft:

"An endpoint/protocol could choose to expose transport header
information to optimise the benefit it gets from the network
[RFC8558]."

There is also the possibility that the endpoints didn't expose
transport layer information, but the network incorrectly thinks it
did. The network may simply misinterpret bits in packets as being
transport layer information when in fact the data can be something
completely different and unrelated. The canonical example of this is
QUIC or any transport encapsulated in UDP payload. Per, RFC7605,
transport port numbers only have meaning at end points. So for example
a network device may think a packet with UDP destination port 80 is
QUIC, when in fact it is something completely different, hence the
network device may misinterpret the payload as being QUIC. I suspect
it's unlikely that this situation will benefit the user, and more
likely the network would not treat such packets well. There's been
some work on this problem, like magic numbers in SPUD or analysis to
mitigate the effects of misinterpretation like done for QUIC spin bit,
but I don't believe anyone has proposed a general solution (other than
moving the necessary information into the network layer and have
intermediate nodes stop doing DPI).  I believe this problem should be
mentioned in the draft with a reference to RFC7605 .

Tom