Re: [tsvwg] I-D Action: draft-ietf-tsvwg-transport-encrypt-03.txt

[Gorry Fairhurst <[e-mail]>]

On 26/11/2018, 16:28, Tom Herbert wrote:
> Hi, here's a few comments on the latest draft.
>
> > From the introduction:
>
> "These benefits have been widely discussed [RFC7258], [RFC7624], and
> them. There are also, however, some costs, in that the wide use of
> this document strongly supports the increased use of encryption in
> transport encryption requires changes to network operations, and
> transport protocols."
>
> I am not exactly sure what this means, but if this saying that the
> document strongly supports increased use of transport header
> encryption can transport header encryption be a RECOMMENDED
> requirement.
The document doesn't use RFC2119 language, and the goal is not to
make best current practice recommendations - its infromation to capture
what we know.
> > From the draft:
>
> "To achieve stable Internet operations the IETF transport community
> has to date relied heavily on measurement and insights of the network
> operations community to understand the trade-offs, and to inform
> selection of appropriate mechanisms, to ensure a safe, reliable, and
> robust Internet (e.g., [RFC1273],[RFC2914])."
>
> The two referenced RFCs are hardly recent (1991, 2000). Is there
> something more recent that describes how the transport community is
> "heavily" relying on transport layer measurements from the networking
> community?
> I'd point out that we've made substantial changes to TCP
> like ICWD=10, TFO, and BBR without needing input about the transport
> layer from network operators. Host endpoints have the necessary
> statistics and measurements to develop and validate such features. It
> seems the only time we needed to specifically consider the network was
> when packets for new transport layer features are blocked (like in the
> case of TFO when SYN packets with data were being dropped).
Excellent point about BBR and TFO - there were indeed many many 
presentations and many papers about  the protocol developments used by 
TFO. BBR is evolving. Recently BBR within TCP has been subject to quite 
a bit of analysis by people other than the authors. Hopefully there will 
also be analysis of how this interacts with AQM, etc. It's a bit hard to 
get third-party analysis of the use within QUIC. There's been some 
analysis of how BBR interacts with policiers and other-in network 
management (but I'm not sure how up to date this is). Is it safe for use 
in the general Internet? - I'll punt that question to ICCRG, where 
doubtless there will be more analysis to come.
> > From the draft:
>
> "transport designers have often ignored the implications of whether
> the protocol designers have often ignored the implications of whether
> the information in transport header fields can or will be used by in-
> information in transport header fields can or will be used by in-
> network devices"
>
> Actually, I believe the the opposite is true. Host developers and
> protocol designers are very much aware of the implications of
> intermediate devices consuming transport layer information. This is
> not because we're trying to help the network mechanisms, it's because
> we need to work around protocol ossification caused by non-conformant
> devices in order to maximize the chances of packet delivery.

The chances of a strandard TCP segment being delivered are still often 
higher than that of a new protocol using UDP. There are types of network 
where you will find performance is quite different - and can be better 
for TCP (see this IETF's proceedings), and places such as from within an 
enterprise (or some other controlled environment) where you may still be 
unable to use UDP without some form of proxy. This may be why QUIC is 
often seen as falling back to TCP.

To me, none of this is important to understanding why currently some 
network operators have and continue to use information from transport 
headers to help operate their service.

Gorry
> Tom
>
> On Sun, Nov 25, 2018 at 11:46 AM<[e-mail]>  wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Transport Area Working Group WG of the IETF.
>>
>>          Title           : The Impact of Transport Header Confidentiality on Network Operation and Evolution of the Internet
>>          Authors         : Godred Fairhurst
>>                            Colin Perkins
>>          Filename        : draft-ietf-tsvwg-transport-encrypt-03.txt
>>          Pages           : 41
>>          Date            : 2018-11-25
>>
>> Abstract:
>>     This document describes implications of applying end-to-end
>>     encryption at the transport layer.  It identifies in-network uses of
>>     transport layer header information.  It then reviews the implications
>>     of developing end-to-end transport protocols that use authentication
>>     to protect the integrity of transport information or encryption to
>>     provide confidentiality of the transport protocol header and expected
>>     implications of transport protocol design and network operation.
>>     Since transport measurement and analysis of the impact of network
>>     characteristics have been important to the design of current
>>     transport protocols, it also considers the impact on transport and
>>     application evolution.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-tsvwg-transport-encrypt-03
>> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-transport-encrypt-03
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-transport-encrypt-03
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>