Re: [tsvwg] New Version of draft-ietf-tsvwg-transport-encrypt (12)

Spencer Dawkins at IETF <> Thu, 27 February 2020 22:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 324943A0DE9 for <>; Thu, 27 Feb 2020 14:19:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cyKju5yueq-c for <>; Thu, 27 Feb 2020 14:19:33 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 15FB43A0E1A for <>; Thu, 27 Feb 2020 14:19:33 -0800 (PST)
Received: by with SMTP id d10so1012594ljl.9 for <>; Thu, 27 Feb 2020 14:19:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tGaPsUpmTgCkdFlOZRFVRCau5RQLWzDk2a8+hucxd+g=; b=dnPwbNr9L477X3vuKPx9z6aGwXvvkHCAzq7LhPA1ejo8+GVmKmoZ3NS+uVgbZvzYQX qcB2cElCAWdSxuLLPOb2SDHl6dCXRYEB5QNqrS1kWp421TiOZVKkgF4RrvmcyWZDSv+T jyfO7hgnwo4dzc+ILYqY1ZXWBQL1ByS4hH87BVi2PnZ6fmCVkUjzkxXw20WL0+5aAzHE bkWMOokHltjNAPHjW/Zwhupbd83R0nkMT/Wm1XxXJKKvmkNPQUHV8LlLHaMWJQR36j0o z4UMoQcmTzls8VTw3QXtcjOEOsOeLknT4MHe8CoQm9hbgqdd7IMYwJr5oZn4rynDkCxM HQfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tGaPsUpmTgCkdFlOZRFVRCau5RQLWzDk2a8+hucxd+g=; b=kd94+Wy/p2TSzlbkPwdMZYiqImYnQh7i50TlVSlEe5Rb7t4yntTHYXc0DW2ZfV8lQQ TMrdwSwgA49yvNnyCcZFE25MQNCNnEM+f5f5NV9cZtgg1DAjOUigpxARPDfquPHwQWmS 89KKdstK8zYyCvKpPwJSIr2aLazjA6lkc82xWC7PTeB84tRyTVwbwtq/jQ3PEmpp6/j/ sskMANu/GbFgar1w1nJdOXwaJ7iNoWQkxUTtvHIHfOPkHmMI46NqT7lPu9x5DyRsftDR V0tKCOj6Q+EQPlvQhfR2GQbCD04XxjQz3hyxU3ZEnNrQHbGvUPjo23BmjEdYX+nzbU9x zx1g==
X-Gm-Message-State: ANhLgQ3W5rVGnautXw+KTcJGjftqqPp7K63v21LONhxcrMSZ4Oc34n82 IgqC/KGdJKKpfY3VSrJwrGpZmFDKhMjdVBvXwnY8pFhqwzi7pg==
X-Google-Smtp-Source: ADFU+vvEeTsdj4edF5QUSGJRhaxhd6Jma3mxxIbPLYkWnSJZ9aoFPEXnd2LLx5t1T1n3wuXbxwbhpbWcm2vNUxv4nmU=
X-Received: by 2002:a2e:9c85:: with SMTP id x5mr806968lji.50.1582841971262; Thu, 27 Feb 2020 14:19:31 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Spencer Dawkins at IETF <>
Date: Thu, 27 Feb 2020 16:19:05 -0600
Message-ID: <>
To: Martin Duke <>
Cc: Gorry Fairhurst <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000006ec69c059f961d9e"
Archived-At: <>
Subject: Re: [tsvwg] New Version of draft-ietf-tsvwg-transport-encrypt (12)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Feb 2020 22:19:43 -0000

Hi, Martin,

Again, just as background so you folks can do the right thing :-)

On Thu, Feb 27, 2020 at 3:26 PM Martin Duke <> wrote:

> One thing that came out of the spin bit discussion is that some transport
> protocol experts honestly do not understand how this information is used
> constructively in the network. That may be why the initial tone may have
> been a little unbalanced.
> To answer your question, David, I think your takeaway as a transport
> designer is to understand what you are sacrificing when you encrypt
> transport headers, and consider exposing specific items if the benefits
> would suit the use case. Other transport designers (though none that I
> actually know) might benefit from an explanation on why transport
> encryption is worth doing.

The other ball in play, for at least MARNEW, ACCORD, and RFC 8404, was an
IAB/IETF effort to get actual operator perspectives about their situation
with existing protocols - I remember several of us begging GSMA folk for
traces at the MARNEW workshop. Unfortunately, but surprising no one,
operators were loath to release traces from their production networks that
show problems that competitors might show to their customers, so we were
getting a lot of exchanges saying "we NEED to manage transport behavior,
but we can't tell you why"/"actually, you DON'T need to manage transport
behavior, but that statement isn't based on analyzing traffic on your

There was also a fairly widespread suspicion that people who had installed
TCP accelerators in the RENO-distant past didn't actually need them, unless
they were running satellite links, but when we asked people to pull their
TCP accelerators out of line to see what would happen, most operators
weren't willing to do that, either.

So Gorry was also trying to answer the question, "what COULD they be
looking at now?"

It was a complicated time, IIRC. I think we're 70 percent past that now.
And I seriously wish you folks the best, getting past the other 30 percent!


> Martin
> On Thu, Feb 27, 2020 at 12:25 PM Spencer Dawkins at IETF <
>> wrote:
>> Speaking as a non-area director (so, I don't have a hat to remove) ...
>> On Thu, Feb 27, 2020 at 1:18 PM Gorry Fairhurst <>
>> wrote:
>>> We discussed the scope a lot at the start, and the advice I received was
>>> that this is not the document to tell people about what they have to do.
>>> I think the decisions about whether to encrypt all transport fields or
>>> some or none isn't something I saw huge consensus upon. I did see many
>>> strong arguments, but what I heard often depended on which working group
>>> was speaking and the background of people involved. Had I asked a different
>>> question, e.g. do you think Privacy is important I would have got a
>>> different answer (we do have a BCP that notes that).
>>> The AD advice I recall at the time we asked to work on this, correct me
>>> Spencer if I am wrong, was to not attempt a BCP until the WG could first
>>> publish an informational document. This is that document. The purpose then,
>>> as I see, is to examine where we have arrived. Had we had a document like
>>> this, other discussions such as how to manage QUIC, whether PLUS could be
>>> useful, etc could have been more informed and focussed.
>> I believe I was the AD who gave this advice, and Gorry is recounting that
>> story the way I remember it.
>> From my perspective, we had just been through a great deal of
>> kerfluffling with MARNEW(1), SPUD(2), ACCORD(3), PLUS(4), and "Effects of
>> Pervasive Encryption on Operators"(5), all of which had various levels of
>> food-flinging, and all of which had various levels of assertions about
>> whether operators needed to manage transport protocols, with little
>> agreement on ground truths about what was, and was not, possible to manage
>> when looking at existing transport protocols.
>> I wasn't seeing anything that led me to expect that to change before the
>> earth fell into the sun, and the volume level was increasing (watching
>> Meetecho for the PLUS BOF would drive anyone to drink, even today). So I
>> encouraged Gorry to focus on ground truths, so that we would be able to
>> actually have discussions about what might go into a BCP for protocol
>> designers (as David reasonably points out, that would be great), and/or a
>> BCP for network operators.
>> One can debate whether I did the right thing (but that wasn't appealed,
>> and I wasn't recalled). I'd defer to the current ADs (both now and after
>> IETF 107) on what to do next, but I thought it would be useful to provide
>> background on how TSVWG got here.
>> Best of luck to Magnus, Mirja, and Martin, of course. And you don't HAVE
>> to have a name that starts with the letter "M" to stand as a nominee for
>> TSV AD this coming Nomcom cycle :-)
>> Best,
>> Spencer
>> (1)
>> (2)
>> (3)
>> (4)
>> (5)