[tsvwg] Extension headers in draft-ietf-tsvwg-transport-encrypt-06

[Tom Herbert <[e-mail]>]

Hello,

Section 5 mentions possible use extension headers. I believe the text
underestimates their value and overstates the disadvantages as an
alternative method to signal transport related information to the
network.

Please consider the following advantages:

1) Extension headers work with _all_ transport protocols as well as
any combination of encrypted or encapsulated transport headers.
2) Intermediate devices that consume transport layer information no
longer need to perform DPI. They don't need to support every transport
protocol and every possible encapsulation method, i.e. we can get
beyond plain TCP and sometimes UDP as being the only transport
protocols we're allowed to use.
3) Extension headers can contain arbitrary transport related
information including that which isn't available in the transport
headers. For instance, packet loss rate is not easily derived from the
TCP header.
4) They're stateless to the network, but can convey stateful
information maintained at the endpoint nodes.
5) They can provide information about transport protocols whose
headers convey little or no information, UDP for instance.
6) They avoid the problem in parsing transport protocols that are
carried in UDP payload, QUIC for instance, where the port number may
be misinterpreted [RFC7605], and hence the transport data may be
incorrectly interpreted.
7) Extension headers can carry information about the application
protocols that may be of interest the network that is not conveyed in
transport layers. For instance, an intermediate node might figure out
some flow is a video stream and if it can figure out the frame rate it
might be able to optimize the flow.
8) Other uses of extension headers for host to network signaling are
being defined and deployed (e.g. Hop-by-Hop options for IOAM).
9) The _user_ controls what information that is exposed per _their_
secuirity policy!

As for the listed disadvantages:

"some IPv6 networks are also known to drop packets that set an IPv6
header extension (e.g., [RFC7872])".

Yes, some networks drop such packets, but on the other hand some
networks also drop SCTP, DCCP, UDP, and even IPv6. The draft seems to
being drawing a far reaching conclusion that extension headers are not
viable, nor will never be viable, for this nor presumably any purpose.
That's a pretty big extrapolation from one snapshot of data (now three
years old BTW), and I don't believe that's the consensus of IETF. Even
if the argument is that extension headers don't work on the Internet,
they will work in restricted domains (e.g. IOAM EH and SRH are being
deployed).

"Another disadvantage is that protocols that separately expose header
information do not necessarily have an incentive to expose the
information that is utilized by the protocol itself, and could
manipulate the exposed header information to gain an advantage from
the network."

This presumes that fields in transport protocols are immune to
manipulation. That's not necessarily true. Consider STT, or how easy
it would be to spoof a QUIC packet just by setting the right
destination port number.  This also becomes a problem when fields are
added to the transport layer header just for the purposes of making
data visible to the network (e.g. the spin-bit in QUIC). Where is the
incentive for a host to not manipulate that information?

If the network is sensitive to plain text data in packets that could
be manipulated and doesn't trust communicating nodes to be honest,
that is a _security_ problem not a transport problem. For instance in
FAST, the network authenticates the ticket for services set by a host.

Tom