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

[Tom Herbert <[e-mail]>]

On Sun, Jun 2, 2019 at 6:15 AM Ingemar Johansson S
<[e-mail]> wrote:
>
> 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 ?.

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

>
> /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
> > **************************************