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

Gorry Fairhurst <> Tue, 04 June 2019 07:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B79A612011A for <>; Tue, 4 Jun 2019 00:12:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AU1xlOW8Djrz for <>; Tue, 4 Jun 2019 00:12:39 -0700 (PDT)
Received: from ( [IPv6:2001:630:42:150::2]) by (Postfix) with ESMTP id DEA131200A4 for <>; Tue, 4 Jun 2019 00:12:38 -0700 (PDT)
Received: from MacBook-Pro.local ( []) by (Postfix) with ESMTPSA id 6ACBC1B00111; Tue, 4 Jun 2019 08:12:34 +0100 (BST)
Message-ID: <>
Date: Tue, 04 Jun 2019 08:12:32 +0100
From: Gorry Fairhurst <>
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Tom Herbert <>
CC: Ingemar Johansson S <>, "" <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [tsvwg] Extension headers in draft-ietf-tsvwg-transport-encrypt-06
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 04 Jun 2019 07:12:42 -0000

On 03/06/2019, 15:48, Tom Herbert wrote:
> On Sun, Jun 2, 2019 at 6:15 AM Ingemar Johansson S
> <>  wrote:
>> Hi
>> Last time I heard of it in a similar context was when IPv6 destination
>> options was outlined for ConEx ( ).
>> 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.

>> /Ingemar
>>> ------------------------------
>>> Message: 2
>>> Date: Fri, 31 May 2019 08:57:12 -0700
>>> From: Tom Herbert<>
>>> To: tsvwg<>
>>> Subject: [tsvwg] Extension headers in
>>>        draft-ietf-tsvwg-transport-encrypt-06
>>> Message-ID:
>>>        <CALx6S35NiQJ1etmhBjkCuXc8wdsW2O4b3+MtEyJfYjtiNkxeFQ@
>>> 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
>>> **************************************