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

From: [email-masked]
Date: Fri, 31 Jan 2020 10:35:06 -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           : Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols
        Authors         : Godred Fairhurst
                          Colin Perkins
	Filename        : draft-ietf-tsvwg-transport-encrypt-11.txt
	Pages           : 48
	Date            : 2020-01-31

Abstract:
   To protect user data and privacy, Internet transport protocols have
   supported payload encryption and authentication for some time.  Such
   encryption and authentication is now also starting to be applied to
   the transport protocol headers.  This helps avoid transport protocol
   ossification by middleboxes, while also protecting metadata about the
   communication.  Current operational practice in some networks inspect
   transport header information within the network, but this is no
   longer possible when those transport headers are encrypted.  This
   document discusses the possible impact when network traffic uses a
   protocol with an encrypted transport header.  It suggests issues to
   consider when designing new transport protocols, to account for
   network operations, prevent network ossification, enable transport
   evolution, and respect user privacy.

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-11
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-transport-encrypt-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-transport-encrypt-11

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: Fri, 31 Jan 2020 10:48:11 -0800

One comment:

>From the draft:

"Observing the protocol sequence number pattern of network usage.
Measurements can be per endpoint or for and packet size offers one way
to meausre this (e.g., measurements an endpoint aggregate (e.g., to
assess subscriber usage). observing counters in periodic reports such
as RTCP"

Misspelling measure. Note that tracking sequence numbers in the
network, flow tracking general, typically presumes that all packets
for a flow take the same path and consistently traverse the node
tracking transport state information. There's no requirement in IP for
that to hold.

Tom

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 31 Jan 2020 18:56:27 +0000

On 31/01/2020 18:48, Tom Herbert wrote:
> Misspelling measure.
Ah - thanks for noting - we edited after spell-check, so we'll make sure 
to fix that.
> Note that tracking sequence numbers in the

True. I assume this appears as jitter or loss, but yes any view from the 
middle

wouldn't know that other packets have taken a different path; and similarly

wouldn't know whether any packets were later reodered/lost/etc after

the measurement point. I'd expect people to understand this sort of thing.

Gorry

---

From: Tom Herbert <[email-masked]>
Date: Fri, 31 Jan 2020 11:10:43 -0800

> the measurement point. I'd expect people to understand this sort of thing.
Gorry,

A host can influence the path a packet takes in several ways. For
instance, one method is to modulate the flow label used for an IPv6
flow. We've implemented this in Linux where if we see a connection is
failing, i.e. multiple retransmits seen, it will change the flow label
used for the flow in hopes of finding a better path by ECMP. This
causes problems if the network maintains state for flows and when a
different path is taken no state is encountered (for instances packet,
might just be dropped in case of a stateful firewall).

The problem is that not only does the sending host not know a priori
what transport information the network might need, it doesn't know
what the implicit requirements the network has assumed with regards to
how it uses the transport information (like requirement for consistent
routing through a stateful device).

Tom