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

From: [email-masked]
Date: Sun, 25 Nov 2018 11:45:32 -0800

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/

---

From: Tom Herbert <[email-masked]>
Date: Mon, 26 Nov 2018 08:28:07 -0800

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.

>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).

>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.

Tom

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 26 Nov 2018 17:32:26 +0000

> encryption can transport header encryption be a RECOMMENDED
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.
> community?
> I'd point out that we've made substantial changes to TCP
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.
> 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<[email-masked]>  wrote:
>>

---

From: Tom Herbert <[email-masked]>
Date: Mon, 26 Nov 2018 11:34:54 -0800

> headers to help operate their service.

Gorry,

Understanding that is relevant only if a list of requirements can be
derived as to what transport layer information needs to be exposed to
the network and what the correct mechanism is to expose such
information.

Tom

---

From: Kyle Rose <[email-masked]>
Date: Mon, 26 Nov 2018 15:11:34 -0500

> the network and what the correct mechanism is to expose such

This is sort of what I was getting at in the first two paragraphs of my
review. But I speculate that the answer is not simply binary, i.e.,
'such-and-such information is both sufficient and necessary to operate our
network in the presence of this traffic', but that there's a spectrum: each
bit of revealed metadata offers the operator some additional insight that
provides some increment of management ability in some areas.

I think the fundamental problem with an analysis of this sort is this:
assuming you could reduce manageability to a single number, then the
formula computing it would be a complex combination of insights revealed by
different pieces of metadata in different combinations that intrinsically
depends on the current state of the art of traffic analysis, and possibly
on the availability of statistics or emergent data from observing lots of
flows under various conditions. This feels like research, not practice.

So maybe the only feasible way to bound the scope is to make clear the
limits of scope with reference to the difficulty of knowing which
combinations of metadata might possibly reveal which insights about the
traffic, and to stick to analyzing known practices based on historically
available metadata. I think the draft already does the latter, though I
haven't looked into how systematically it does so; but clearly there's some
disagreement about what the document is trying to achieve, which might call
for some wordsmithing of the abstract and introduction.

Kyle

---

From: Tom Herbert <[email-masked]>
Date: Mon, 26 Nov 2018 13:14:04 -0800

On Mon, Nov 26, 2018 at 12:11 PM Kyle Rose <[email-masked]> wrote:
> This is sort of what I was getting at in the first two paragraphs of my review. But I speculate that the answer is not simply binary, i.e., 'such-and-such information is both sufficient and necessary to operate our network in the presence of this traffic', but that there's a spectrum: each bit of revealed metadata offers the operator some additional insight that provides some increment of management ability in some areas.

Correspondingly, each bit of revealed meta data could also provide
insights to a would-be attacker and has the potential to be ossified.

>
> I think the fundamental problem with an analysis of this sort is this: assuming you could reduce manageability to a single number, then the formula computing it would be a complex combination of insights revealed by different pieces of metadata in different combinations that intrinsically depends on the current state of the art of traffic analysis, and possibly on the availability of statistics or emergent data from observing lots of flows under various conditions. This feels like research, not practice.
>
> So maybe the only feasible way to bound the scope is to make clear the limits of scope with reference to the difficulty of knowing which combinations of metadata might possibly reveal which insights about the traffic, and to stick to analyzing known practices based on historically available metadata. I think the draft already does the latter, though I haven't looked into how systematically it does so; but clearly there's some disagreement about what the document is trying to achieve, which might call for some wordsmithing of the abstract and introduction.

Okay, then by "analyzing known practices based on historically
available metadata" that pretty much means the TCP header. So I can
clarify my question: What exact information from the TCP header is
necessary to be exposed to the network? Or to put it another way, if
someone were to figure out a way to encrypt the TCP header today, what
parts of the header would still need to be in plaintext so that the
network can properly function?

Tom