[tsvwg] Review of draft-ietf-tsvwg-transport-encrypt-01

[Kyle Rose <[e-mail]>]

The one overall comment I have is that the document talks about the
potential impacts of transport encryption to network operations, but does
not attempt to systematically distinguish the impact across different
levels of opaqueness. With the IP header in the clear (something that is
likely to remain true for the foreseeable future!), for bidirectional
(i.e., unspoofable) flows there exists at least information about the
source and destination that enables some kind of disincentive (i.e., blame)
for unmanageable behavior.

I'll repeat the same comment I had for Kathleen and Al when reviewing the
draft for RFC 8404, which is that I really would like an analysis (based on
the current state of the art, I guess) of what visibility is lost to
on-path observers when a particular piece of transport metadata is hidden,
and to what degree. Engineers are clever and will figure out ways to tease
out more information from limited data, so I'm not looking for
impossibility proofs, but maybe an attempt at tiering the potential levels
of analysis and what metadata is required to make each feasible based on
our current understanding. Probably a different document.

Specific comments:

In section 2, you have:

   "The increasing public concerns
   about the interference with Internet traffic have led to a rapidly
   expanding deployment of encryption to protect end-user privacy, in
   protocols like QUIC [I-D.ietf-quic-transport], but also expected to
   form a basis of future protocol designs."

These two clauses don't seem to fit each other. I wonder if one changed
without the other. I might say something like:

   "The increasing public concerns
   about the interference with Internet traffic have led to a rapidly
   expanding deployment of encryption to protect end-user privacy, e.g., in
   QUIC [I-D.ietf-quic-transport]. It is anticipated that future protocol
designs
   will follow suit."

Also in section 2, you say "It therefore prevents mechanisms being built
that directly rely on the information or seeks to imply semantics of an
exposed header field." I think you want to s/imply/infer/. This text is
also repeated verbatim in section 8.

A little further down in section 2, you have:

   "A level of ossification of the transport header can offer trade-offs
   around authentication, and confidentiality of transport protocol
   headers and has the potential to explicitly support for other uses of
   this header information."

I can't parse this, nor can I figure out what you're trying to say in the
first clause.

In section 3.1.2, you say "This has been used to locate a source of
latency, e.g., by observing cases where the ratio of median to minimum RTT
is large for a part of a path." Is there an informational reference for
this technique? I'm personally curious.

Regarding congestion control, section 3.2.4 states:

     "However, when anomalies are detected, tools can interpret the
      transport protocol header information to help understand the
      impact of specific transport protocols (or protocol mechanisms) on
      the other traffic that shares a network."

One important point, maybe only implied here, is that the ability to easily
pinpoint and blame a particular entity for the use of unfair congestion
control is key to the combination of politeness and (something like)
mutually assured destruction that maintains fairness among flows. Nothing
I've seen proposed in actual work (i.e., encrypted transports on top of IP)
renders this impossible because the real source of a bidirectional
negotiated flow is always evident.

The end of section 3.3 states:

   "Although many network operators utilise
   transport information as a part of their operational practice, the
   network will not break because transport headers are encrypted, and
   this may require alternative tools may need to be developed and
   deployed."

I'm not sure what this means.

Section 4, under "Authenticating the Transport Protocol Header", states:

      "An integrity check can not prevent in-network modification, but can
      avoid a receiving accepting changes and avoid impact on the
      transport protocol operation."

It can also not prevent ossification around expected values. This is the
principle behind GREASE: expose certain useful metadata, but make
ossification fail often enough that it is noticed early. In a certain
sense, it falls between cleartext and encryption in that it is
unpredictable enough not to be relied upon, but is still passively
observable. From one perspective, there's a spectrum: unprotected ->
authenticated -> GREASEd -> encrypted.

Speaking for myself, there exists a lot of metadata for which I don't care
about exposure, but I do care about modification and ossification. GREASE
is currently the best of both worlds (operator and user) for this
information. I think this spectrum could be used more comprehensively
throughout the document.

Section 7 has a somewhat offhand remark that might suggest a course of
action:

   "There are benefits in
   exposing consistent information to the network that avoids traffic
   being mis-classified and then receiving a default treatment by the
   network."

Many folks might be nonPLUSsed by the idea that a standard mechanism for
path-exposed metadata could be a good idea, but instead of playing defense,
operators might consider proposing and deploying (and hopefully
standardizing?) a mechanism for opt-in QoS. No pressure, no enforcement,
but tailored service for compliant transports that are willing to reveal
certain metadata. Probably heresy.

Kyle