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

From: Ingemar Johansson S <[email-masked]>
Date: Sun, 2 Jun 2019 13:15:31 +0000

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 <[email-masked]>
> To: tsvwg <[email-masked]>
> 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
> **************************************

---

From: Tom Herbert <[email-masked]>
Date: Mon, 3 Jun 2019 07:48:30 -0700

> enough can be implemented for application exposure as well ?.

Hi Ingemar,

Thanks for the reference. Indeed, ConEx is a good example of the
concept of hosts signaling transport related information to the
network in a generic and transport protocol agnostic manner.

RFC7837 defines a Destination Option for ConEx. Section 3 states that
the preferred solution is a Hop-by-Hop Option. I imagine that the
reason DO was chosen is because per RFC2460 all nodes in the path must
process HBH Options, but in practice that requirement has proven
impractical. RFC8200 subsequently relaxed the requirements to allow
nodes to ignore Hop-by-Hop Options.

Tom

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 04 Jun 2019 08:12:32 +0100

> nodes to ignore Hop-by-Hop Options.
Although it could be a nice exmaple of how this could be done, CONEX is 
not a mechanism that as far as I know has received much deployment to date.

Gorry
>>> From: Tom Herbert<[email-masked]>
>>> To: tsvwg<[email-masked]>