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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Gorry,

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

On Tue, Nov 20, 2018 at 2:51 AM Gorry Fairhurst <[e-mail]>
wrote:

> 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 <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     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:
> >     > 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.
> >     >
> >     #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.
> >     > Specific comments:
> >
> >
> > 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.
> >
> >     >
> >     > 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."
> >     >
> >     #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.
> >     > 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.
> >     >
> >     #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:"
> >     > 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.
> >     >
> >     #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.
> >     > 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.
> >     >
> >     #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]."
> >     "
> >     > 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.
> >     >
> >     #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
> >
> >
> > 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.
> >
> >     troubleshooting tools to be developed and deployed."
> >     > 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.
> >     >
> >     #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.
> >     >
> >     > 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
> >
> >
> > 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
> >
> >     > 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
> >
> 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?


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