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

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Tue, 04 June 2019 07:12 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B79A612011A for <tsvwg@ietfa.amsl.com>; Tue, 4 Jun 2019 00:12:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AU1xlOW8Djrz for <tsvwg@ietfa.amsl.com>; Tue, 4 Jun 2019 00:12:39 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id DEA131200A4 for <tsvwg@ietf.org>; Tue, 4 Jun 2019 00:12:38 -0700 (PDT)
Received: from MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 6ACBC1B00111; Tue, 4 Jun 2019 08:12:34 +0100 (BST)
Message-ID: <5CF619E0.30707@erg.abdn.ac.uk>
Date: Tue, 04 Jun 2019 08:12:32 +0100
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Reply-To: gorry@erg.abdn.ac.uk
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 <tom@herbertland.com>
CC: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
References: <HE1PR07MB4425E864408D88F09428DACEC21B0@HE1PR07MB4425.eurprd07.prod.outlook.com> <CALx6S35oXG9QbkzquwzArpLVfRN-LyQq8-J0SwgUXecSVWmi0w@mail.gmail.com>
In-Reply-To: <CALx6S35oXG9QbkzquwzArpLVfRN-LyQq8-J0SwgUXecSVWmi0w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/hk72OlW66AyJORgl8Ot--q6Ye38>
Subject: Re: [tsvwg] Extension headers in draft-ietf-tsvwg-transport-encrypt-06
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=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
> <ingemar.s.johansson@ericsson.com>;  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<tom@herbertland.com>;
>>> To: tsvwg<tsvwg@ietf.org>;
>>> 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
>>> **************************************