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

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 27 Feb 2020 09:08:53 +0000

The editors have just uploaded a new revision of 
draft-ietf-tsvwg-transport-encrypt following review comments. We are not 
aware of further review comments and now think that this new version is 
now ready to proceed.

Best wishes,

Gorry and Colin

---
A new version of I-D, draft-ietf-tsvwg-transport-encrypt-12.txt
has been successfully submitted by Godred Fairhurst and posted to the
IETF repository.

Name: draft-ietf-tsvwg-transport-encrypt
Revision: 12
Title: Considerations around Transport Header Confidentiality, Network 
Operations, and the Evolution of Internet Transport Protocols
Document date: 2020-02-26
Group: tsvwg
Pages: 48
URL: 
https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-transport-encrypt-12.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/
Htmlized: https://tools.ietf.org/html/draft-ietf-tsvwg-transport-encrypt-12
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-transport-encrypt
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-transport-encrypt-12

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.

---

From: David Schinazi <[email-masked]>
Date: Thu, 27 Feb 2020 10:39:19 -0800

Hi Gorry,

Thanks for updating the document, and for slightly tweaking the
tone to focus less strongly on the downsides of transport header
encryption. It's much appreciated.

However, I'm now pretty confused by the latest version (-12).
Could you help me answer these two questions please:
1) Who is the target audience for this document?
2) What should that audience walk away with?

I initially assumed that the answer to (1) was "designers
of new transport protocols". But considering myself in that
category, I don't know what I'm supposed to take away
from the draft. I was expecting the answer to (2) to be
"you SHOULD or SHOULD NOT encrypt transport protocol
headers (pick one)" but that's not the case.

Here are excerpts from the draft's Conclusion section:

   This document has described some current practises, and the
   implications for some stakeholders, when transport layer header
   encryption is used.  It does not judge whether these practises are
   necessary, or endorse the use of any specific practise.

   This document does not make recommendations about what
   information ought to be exposed, to whom it ought to be observable,
   or how this will be achieved.

   An appropriate balance will emerge over time as real instances
   of this tension are analysed [RFC7258].

The messages I'm walking away with are:
A) there is a tension between folks who want to encrypt and
    folks who don't
B) we don't have enough information, it's too early to tell what the
    impact of transport header encryption really is

As such, I'm now more confused than I was before reading the
draft, as it doesn't help me answer the question of "when designing
a new transport protocol, should I be encrypting my transport
headers or not?".

I personally oppose publication of the document as it stands,
because I find it confusing and non-actionable. I would like to see
this useful content in a BCP document once we have enough
information to actually recommend something.

Thanks,
David

On Thu, Feb 27, 2020 at 1:09 AM Gorry Fairhurst <[email-masked]>
wrote:

> Status:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/
> Htmlized:
> https://tools.ietf.org/html/draft-ietf-tsvwg-transport-encrypt-12
> Htmlized:

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 27 Feb 2020 19:17:43 +0000

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.

Gorry

On 27/02/2020 18:39, David Schinazi wrote:
> On Thu, Feb 27, 2020 at 1:09 AM Gorry Fairhurst <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     https://datatracker.ietf..org/doc/draft-ietf-tsvwg-transport-encrypt/
>     <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/>
>     Htmlized:

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 27 Feb 2020 14:24:35 -0600

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 <[email-masked]>
wrote:

> 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).
>
> 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) https://datatracker.ietf.org/doc/rfc8462/
(2) https://datatracker.ietf.org/doc/minutes-92-spud/
(3) https://www.ietf.org/proceedings/95/minutes/minutes-95-accord
(4) https://datatracker.ietf.org/doc/minutes-96-plus/
(5) https://datatracker.ietf.org/doc/rfc8404/

---

From: Martin Duke <[email-masked]>
Date: Thu, 27 Feb 2020 13:26:20 -0800

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.

Martin

On Thu, Feb 27, 2020 at 12:25 PM Spencer Dawkins at IETF <
[email-masked]> wrote:

> 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
> 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
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 27 Feb 2020 16:19:05 -0600

Hi, Martin,

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

> 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
networks".

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!

Spencer

>> 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

---

From: Joe Touch <[email-masked]>
Date: Thu, 27 Feb 2020 15:02:52 -0800

On 2020-02-27 13:26, 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.

replace "how this info is used" with "why this info needs to be used",
and yeah - I'll claim to be one of them (if you can call me an expert). 

My concerns with the initial doc was that it was skewed towards "get out
of the way of network admins who need to snoop into your private
business to 'help them help you'". I think the current design is a much
better balance and reasonable as a way forward.  In particular, it seems
to say more "if you want that help, then be careful to make the needed
information available at some protocol layer", rather than "leave your
doors unlocked, because we really want to help you and that's the only
way we can". 

Joe

---

From: Colin Perkins <[email-masked]>
Date: Fri, 28 Feb 2020 00:04:54 +0000

Right – my goal with this draft is not to say ‘encrypt' or 'don’t encrypt' the transport headers, but rather to highlight various issues to consider when deciding whether, and what, to encrypt. It’s information to help transport designers make an informed choice. 

Colin

> On 27 Feb 2020, at 21:26, Martin Duke <[email-masked]> 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.
> 
> Martin
> 
> On Thu, Feb 27, 2020 at 12:25 PM Spencer Dawkins at IETF <[email-masked] <mailto:[email-masked]>> wrote:
> On Thu, Feb 27, 2020 at 1:18 PM Gorry Fairhurst <[email-masked] <mailto:[email-masked]>> 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) https://datatracker.ietf.org/doc/rfc8462/ <https://datatracker.ietf.org/doc/rfc8462/>
> (2) https://datatracker..ietf.org/doc/minutes-92-spud/ <https://datatracker.ietf.org/doc/minutes-92-spud/>
> (3) https://www.ietf.org/proceedings/95/minutes/minutes-95-accord <https://www.ietf.org/proceedings/95/minutes/minutes-95-accord>
> (4) https://datatracker.ietf.org/doc/minutes-96-plus/ <https://datatracker.ietf.org/doc/minutes-96-plus/>
> (5) https://datatracker.ietf.org/doc/rfc8404/ <https://datatracker.ietf.org/doc/rfc8404/>

-- 
Colin Perkins
https://csperkins.org/