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

From: Kyle Rose <[email-masked]>
Date: Sat, 17 Nov 2018 18:06:49 -0500

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 19 Nov 2018 08:16:07 +0000

Thanks Kyle for these comments, I am working on an updated version just 
now, please see below.

On 17/11/2018, 23:06, Kyle Rose wrote:
> 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.
>
#GF I agree, although I am not sure where or what to say about this. Do 
you have a suggestion we could start from?
> 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.
>
#GF This is interesting, although I wonder if it is beyond the current 
scope. To do this effectively probably needs a willingness of the 
operational community to talk about the topic and their plans.
> These two clauses don't seem to fit each other. I wonder if one 
> changed without the other. I might say something like:
>
>    QUIC [I-D.ietf-quic-transport]. It is anticipated that future 
> protocol designs
>    will follow suit."
>
#GF- Now included in the authors' version -02.
> 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.
>
#GF- Correct, that is now included in the authors' version -02.
> I can't parse this, nor can I figure out what you're trying to say in 
> the first clause.
>
#GF- I tried to rewrite this as:

"Specification of non-encrypted transport header fields explicitly 
allows protocol designers to make specific header information observable 
in the network. This supports other uses of this information by on-path 
devices, and at the same time this can be expected to lead to 
ossification of the transport header, because network forwarding could 
evolve to depend on the presence and/or value of these fields.  The 
decision about which transport headers fields are made observable offers 
trade-offs around authentication, and confidentiality. For example, a 
design that provides confidentiality of protocol header information can 
impact the following activities that rely on measurement and analysis of 
traffic flows:"
> 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.
>
#GF- I would be happy to include, but this came from discussion with a 
tool that observed TCP, used by cellular infrastructure provider, and I 
don't think there is an open reference to their practice.
> 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.
>
#GF - I agree. I'd like to add more, I started with this, additional 
suggestions are welcome:
"The ability to identify sources that contribute excessive congestion is 
important to safe operation of network infrastructure, and mechanisms 
can inform configuration of network devices to complement the endpoint 
congestion avoidance mechanisms  to avoid a portion of the network being 
driven into congestion collapse  [RFC2914]."
"
> I'm not sure what this means.
#GF - Is this better:
"A key need here is for tools to provide useful information during 
network anomalies (e.g., significant reordering, high or intermittent 
loss). Many network operators currently utilise observed transport 
information as a part of their operational practice. However, the 
network will not break just because transport headers are encrypted, 
although operators will require alternative diagnostic and 
troubleshooting tools to be developed and deployed."
> It can also not prevent ossification around expected values. This is 
> the principle behind GREASE: expose certain useful metadata, but make 
#GF - added a bullet to section 4, before encryption that now says:
"
Greasing
Transport layer header information that is observable can be observed in 
the network. Protocols often provide extensibility features, reserving 
fields or values for use by future versions of a specification. The 
specification of receivers has traditionally ignored unspecified values, 
however in-network devices have emerged that ossify to require a certain 
value in a field, or re-use a field for another purpose. When the 
speicfication is later updated, it is impossible to deploy the new use 
of the field, and forwarding of the protocol could even become 
conditional on a specific header field value.

A protocol can intentionally vary the value, format, and/or presence of 
observable transport header fields. This behaviour, known as GREASE 
(Generate Random Extensions And Sustain Extensibility), is designed to 
avoid a network device ossifying the use of a specific observable field. 
Greasing seeks to ease deployment of new methods. It can be designed to 
avoid in-network devices utilising the information in a transport 
header, or can make an observation robust to a set of changing values, 
rather than a specific set of values.
"
- does this seem to help address the problem?
> 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.
>
> 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.
>
#GF - I've reorganised the network-layer text to help bring out the 
trade-offs. Although I see traffic differentiation has the potential to 
be the next apps v network conflict. Hopefully this document can start 
to explain the tradeoffs but avoid inflaming this.
> Kyle
Gorry

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 19 Nov 2018 15:43:28 -0600

Dear All,

I'm fine if people need to tell me to buzz off until this document gets to
at least WGLC before "helping", but please let me offer a couple of words
of advice to consider at an appropriate time.

At this point in the process, I'm not speaking as the responsible AD, but I
can speak as the surviving editor of https://tools.ietf.org/html/rfc8462.
More details about that experience are available in Prague, upon request. I
don't drink, but if you ask for details, you will be drinking, before I
finish talking.

Spencer

> operational community to talk about the topic and their plans.

Gorry, is the point here, that this document is focused on what operators
can (approximately) know with certainty now, rather than by guessing and
applying heuristics when cleartext transport header fields they have been
able to see, become encrypted?

I think you're gesturing correctly toward the difficulty of getting people
to describe their planned countermeasures before deploying them, at least
based on my experience with the IAB MaRNEW workshop and related seances.
After one of the extended conversations about the QUIC Spin Bit, probably
in London, an IETF participant told me that he expected the end game would
look like constant-length, fixed-interval encrypted packets as a
countermeasure to traffic analysis and other heuristics. I'm not betting
that IETF transport groups can predict what people will be willing to do in
the future, to make a living.

> although operators will require alternative diagnostic and

My experience from the MaRNEW workshop was that it's really helpful to
avoid the use of the phrase "operators will require" in contexts like this,
because that is likely to open the vortex on why operators think they
require this capability, which would be horrible enough if we had operators
explaining why they think they require this capability, but it's even more
horrible when we don't have them explaining.

The discussion about whether any of this stuff is "actually required"
probably slowed the publication of https://tools.ietf.org/html/rfc8462 by a
year, beginning when Natasha was collecting minutes from the workshop
itself. Make good choices.

> > Many folks might be nonPLUSsed by the idea that a standard mechanism

Kyle, I will ballot No Objection with comments instead of Discuss on one
document of your choice, as a reward for this reference to PLUS in your
review. Offer expires in March 2019.

(Yes, I am joking. Yes, I wish I wasn't joking!)

Spencer

---

From: Kyle Rose <[email-masked]>
Date: Mon, 19 Nov 2018 22:39:34 -0500

> operational community to talk about the topic and their plans.

It is definitely beyond the scope of the current document. This and the
preceding paragraph should probably be interpreted as wistful feedback
about the document I really want written to settle the operator vs. E2E
protocol designer conflict once and for all. As if that's even possible.
And frankly I'm not exactly volunteering to write it. ;-)

Skipping the comments you had clear resolutions for...

> impact the following activities that rely on measurement and analysis of

This makes a lot more sense. Thanks.

> don't think there is an open reference to their practice.

Heh... I imagine I won't be the only one to ask the same question, so maybe
add something about the technique being proprietary at the time of
authorship (so don't ask).

> driven into congestion collapse  [RFC2914]."

I think this addresses it at the right level for this document. I was
originally thinking something more along the lines of more blunt hammers
operators might employ to (ahem) encourage better behavior and/or policing
from source networks. There are a number of techniques networks employ at
layers 8 and above to enforce cooperation. (As a side note, it would be
interesting to understand whether non-technical measures such as networks
playing chicken with each other are required for the internet to find a
stable equilibrium that is usable. Tragedy of the commons is a powerful
force, but so is profit. Can good will or engineering purity compete?)

> troubleshooting tools to be developed and deployed."

Yes, this is a lot clearer.

> - does this seem to help address the problem?

This looks great. Thanks.

> to explain the tradeoffs but avoid inflaming this.

Curious to check this out when it's published. Or feel free to send me the
link to the repo.

Kyle

---

From: Kyle Rose <[email-masked]>
Date: Mon, 19 Nov 2018 22:47:41 -0500

On Mon, Nov 19, 2018 at 4:43 PM Spencer Dawkins at IETF <
[email-masked]> wrote:

> countermeasure to traffic analysis and other heuristics.
>

I've made observations like this in the past. This is one of the reasons
why I'm skeptical of the utility of pursuing privacy against (e.g.)
state-level actors on the public internet. On a private overlay a la TOR,
perhaps. The key difference is that opt-in overlays like TOR are willing to
tolerate significant performance penalties that would be a non-starter for
the public internet. I am skeptical that we can achieve real privacy at no
significant cost.

> review. Offer expires in March 2019.

I think I'd rather the opposite: a No Objection turned into a Discuss where
something hits one of my pet peeves. ;-)

Kyle

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 19 Nov 2018 22:34:04 -0600

Hi, Kyle,

On Mon, Nov 19, 2018, 21:47 Kyle Rose <[email-masked] wrote:

>> I think you're gesturing correctly toward the difficulty of getting
>> people to describe their planned countermeasures before deploying them, at
>> least based on my experience with the IAB MaRNEW workshop and related
>> seances. After one of the extended conversations about the QUIC Spin Bit,
>> probably in London, an IETF participant told me that he expected the end
>> game would look like constant-length, fixed-interval encrypted packets as a

Yeah. My definition of "win" at this point is that we have a common
understanding of the goals various people are trying to achieve, whether or
not we agree that any or all of those goals should be achieved.

> I think I'd rather the opposite: a No Objection turned into a Discuss
> where something hits one of my pet peeves. ;-)
>

We can talk more about this over To, of course. Because I'm definitely
joking. Definitely. ;-)

Spencer

Kyle

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 20 Nov 2018 08:51:05 +0000

On 19/11/2018, 21:43, Spencer Dawkins at IETF wrote:
> Dear All,
>
> I'm fine if people need to tell me to buzz off until this document 
> gets to at least WGLC before "helping", but please let me offer a 
> couple of words of advice to consider at an appropriate time.
>
> At this point in the process, I'm not speaking as the responsible AD, 
> but I can speak as the surviving editor of 
> https://tools.ietf.org/html/rfc8462. More details about that 
> experience are available in Prague, upon request. I don't drink, but 
> if you ask for details, you will be drinking, before I finish talking.
>
> Spencer
>
> On Mon, Nov 19, 2018 at 2:16 AM Gorry Fairhurst <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Gorry, is the point here, that this document is focused on what 
> operators can (approximately) know with certainty now, rather than by 
> guessing and applying heuristics when cleartext transport header 
> fields they have been able to see, become encrypted?
>
> people to describe their planned countermeasures before deploying 
> them, at least based on my experience with the IAB MaRNEW workshop and 
> related seances. After one of the extended conversations about the 
> QUIC Spin Bit, probably in London, an IETF participant told me that he 
> expected the end game would look like constant-length, fixed-interval 
> encrypted packets as a countermeasure to traffic analysis and other 
> heuristics. I'm not betting that IETF transport groups can predict 
> what people will be willing to do in the future, to make a living.
>
>     >
>     > In section 2, you have:
>     >
> avoid the use of the phrase "operators will require" in contexts like 
> this, because that is likely to open the vortex on why operators think 
> they require this capability, which would be horrible enough if we had 
> operators explaining why they think they require this capability, but 
> it's even more horrible when we don't have them explaining.
>
> probably slowed the publication of https://tools.ietf.org/html/rfc8462 
> by a year, beginning when Natasha was collecting minutes from the 
> workshop itself. Make good choices.
>
> Kyle, I will ballot No Objection with comments instead of Discuss on 
> one document of your choice, as a reward for this reference to PLUS in 
> your review. Offer expires in March 2019.
>
Thanks both of you - I've polished-off the "operators will require", 
with a more neutral statement, and I've tweaked a few other places 
following the email from you and Kyle!

Your assumption "this document is focused on what operators can 
(approximately) know with certainty now, rather than by guessing and 
applying heuristics when cleartext transport header fields they have 
been able to see, become encrypted? " seems pretty much true. Do you 
think we should add something specific to the abstract to say this up 
front - or would that confuse?

Gorry

We can upload a new rev tomorrow.

Gorry

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 20 Nov 2018 12:20:04 -0600

Hi, Gorry,

At the risk of providing text that someone will have to translate into
"correct and coherent" ...

> front - or would that confuse?

I don't know that it's critical to say that in the Abstract, but wondered
about adding something after this text in Section 2:

    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]).  In turn, the network operations
   community relies on being able to understand the pattern and
   requirements of traffic passing over the Internet, both in aggregate
   and at the flow level.

Perhaps

   These operational practices have grown up based on the information
   available from unencrypted transport headers. If this information is only
   carried in encrypted transport headers, operators will not be able to use
   this information directly, but if operators still wish to use these
practices,
   they may turn to more ambitious ways of discovering this information.
   If an operator wants to know that traffic is audio traffic, and
   no longer has access to Session Description Protocol session
   descriptions that would explicitly say "this is audio", the operator
might
   use heuristics to guess that short UDP packets with regular spacing are
   carrying audio traffic. Operational practices aimed at guessing transport
   parameters are out of scope for this document, and are only mentioned
   here to recognize that encryption may not prevent operators from
attempting
  to apply the same practices they used with unencrypted transport headers.

? I'm sure there's s better way to say this, of course.

Spencer