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

[Ingemar Johansson S <[e-mail]>]

Hi

Last time I heard of it in a similar context was when IPv6 destination
options was outlined for ConEx (https://datatracker.ietf.org/doc/rfc7837/ ).
I liked the idea but for various reasons it did not fly AFAIK, perhaps
because the possible congestion problem was not deemed as problematic enough
to justify the implementation cost ?
If the concept is still plausible then I guess something similar and generic
enough can be implemented for application exposure as well ?.

/Ingemar  

> 
> ------------------------------
> 
> Message: 2
> Date: Fri, 31 May 2019 08:57:12 -0700
> From: Tom Herbert <[e-mail]>
> To: tsvwg <[e-mail]>
> Subject: [tsvwg] Extension headers in
> 	draft-ietf-tsvwg-transport-encrypt-06
> Message-ID:
> 	<CALx6S35NiQJ1etmhBjkCuXc8wdsW2O4b3+MtEyJfYjtiNkxeFQ@
> mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
> 
> 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
> 
> 
> 
> End of tsvwg Digest, Vol 181, Issue 20
> **************************************