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

[Gorry Fairhurst <[e-mail]>]

On 03/06/2019, 15:48, Tom Herbert wrote:
> 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
>
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
>> /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
>>> **************************************