Subject: Re: [tsvwg] New rev: draft-fairhurst-tsvwg-transport-encrypt (10)

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sun, 2 Sep 2018 12:11:15 +0000

I support adoption, thanks for adding more examples,
Al

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of Gorry Fairhurst
> Sent: Wednesday, August 29, 2018 3:39 AM
> Cc: Colin Perkins <[email-masked]>; [email-masked]
> Subject: [tsvwg] New rev: draft-fairhurst-tsvwg-transport-encrypt (10)
> 
> We have just uploaded a new revision of the draft following WG meeting
> comments on the motivation for encryption to avoid ossification, and the
> examples preople provided after that discussion. Thanks to people who
> sent email. This is a minor edit, but it adds some specific examples and
> checked the existing text describing these problems.
> 
> Thge WG adoption is scheduled to complete at the end of thsi week -
> please do continue to send any comments on the draft - or it's
> suitability for adoption.
> 
> Best wishes,
> 
> Gorry & Colin.

---

From: Tom Herbert <[email-masked]>
Date: Sun, 2 Sep 2018 09:41:22 -0700

I support adoption.

A few comments:

- The draft is too TCP centric. The fact that TCP is the only
transport protocol we can reliably use in the Internet is a major
outcome of ossification and a major reason we need to encrypt
transport layer to move back to E2E model. For the purposes of this
draft, TCP should just be considered one protocol. Goal should be that
QUIC, SCTP, DCCP, IPsec, and encryped tunnels are as useful on the
Internet as TCP.

- It seems like the effects of transport layer proxies should also be
discussed in this draft. They break end-to-end security, and they make
it much herder to change transport protocols or deploy new options.

>From the draft: "Over this period, the transport protocol headers have
mostly changed slowly, and so also the need to develop tools track new
versions of the protocol." This is rather subjective. For instance,
there have been several major changes to TCP like TFO, MPTCP, EDO,
etc. over the past few years, not in the core protocol header, but in
the addition of new options. At any given time there are more being
proposed and developed. It may be true that deployment of new stuff is
slow because of ossification.

- Please look at Firewall and Service Ticket (FAST) with regard to
section 5. https://tools.ietf.org/html/draft-herbert-fast-02. The idea
of FAST is to place transport layer information in network layer
headers (HBH options). The mechanism is transport protocol agnostic,
scoped (not globally interpretable), secure. The end application
controls how much information about the specifics of the
communications that it is willing share with third parties in order to
get better service.

- From the draft:

"The outcome could have significant implications on the way the
Internet architecture develops.  It exposes a risk that significant
actors (e.g., developers and transport designers) achieve more control
of the way in which the Internet architecture develops.In particular,
there is a possibility that designs could evolve to significantly
benefit of customers for a specific vendor, and that communities with
very different network, applications or platforms could then suffer at
the expense of benefits to their vendors own customer base.  In such a
scenario, there could be no incentive to support other
applications/products or to work in other networks leading to reduced
access for new approaches."

I find this paragraph very subjective and unnecessarily
confrontational. Ossification of the Internet wasn't caused by
application developers and transport designers, it was caused by
non-conformant implementation or ad hoc assumptions made in
middleboxes that break the end-to-end model. I'd also point out that
NONE of the use of Transport Headers within the network are required,
ubiquitous across Internet, or provide benefits to _all_ users. At
best they might benefit some users in some networks.

I suggest this paragraph to be rewritten in a more productive tone.
The goal should be clearly stated up front that the Internet
architecture first and foremost is to benefit users (all of them),
secondly the architecture needs to allow innovation to bring new
benefits to users. To the latter point, ossification needs to be
resolved. We know that encryption is a powerful tool to address
ossification, and TLS and QUIC have already gone a long way in that
regard. The Internet needs to evolve and there will be more
encryption. I don't believe that these trends are going to be reversed
because networks can't do what they've always done before. Networks
still will want to provide services and security to their customers,
but IMO the only way to do that is to have hosts and network devices
work together to provide those services. As an application developer,
I have little incentive to not encrypt as much of the packet as
possible because some random network node _might_ provide a service
that _might_ give my users benefit. But, if I had a way to explicitly
request service from the netwrok without divulging details of
communication, then that is compelling.

Tom

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 3 Sep 2018 08:50:40 +0200

+1. I (still! :) ) support adoption.

Cheers,

Brian

> On 2 Sep 2018, at 14:11, MORTON, ALFRED C (AL) <[email-masked]> wrote:
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 03 Sep 2018 09:19:47 +0100

> I support adoption.

Thanks.

 > A few comments:
 >
 >- The draft is too TCP centric.
 >
That was not the intention.

 > The fact that TCP is the only
On IPSec, We didn't find much I was allowed to share on the specific 
practices of operating networks where most traffic uses IPsec - I'd be 
really interested if there was useful experience that someone could 
contribute on manageability.

 > slow because of ossification.
I agree MPTCP has needed to work hard to find a way to be deployed, and 
has its
own story. Are you arguing that progress within the IETF has not been slow?
I guess we could discuss new RTP extensions and the impact on 
measurement, etc. Does it
really help?

I'm interested in real EDO experience: can you point me to measurement 
campaigns / operator feedback on deploying/managing EDO?

 > communications that it is willing share with third parties in order to
I saw your ID on FAST had emerged, and I'm intrigued by how the IETF 
will respond to FAST.

 > of the way in which the Internet architecture develops. In particular,
 > middleboxes that break the end-to-end model.
 >
My take is that some risks do exist. However, I think you have spotted 
something in the text that should be addressed. I see the last para of 
section 7 could benefit from some refactoring.  I confess some of this 
text belonged in bullet two.

 > I'd also point out that
I think I agree many operational networks have no need to read or modify 
transport headers, and think the draft does say so? However, I'd hope 
the document also notes that these header fields have been used in a 
range of networks - and in some cases were considered important to those 
who offered those services. If that's about to change, this is the place 
to record their current usage.

 > architecture first and foremost is to benefit users (all of them),
I agree if "all of them": includes end-users, operators of various 
shapes and sizes and people using a variety of technologies to realise a 
service, as well as apps developers, and content providers, etc - this 
is a diverse community.

 > work together to provide those services.

My hope would be here to look back at what experience we have and what 
we should consider as we see a way forward.

I do not think we have reached the correct time to evaluate QUIC, the 
tussle with firewalls etc. That's an interesting story that can be told 
later.

 > As an application developer,
 > request service from the network without divulging details of
I agree that explicit signalling to the network (TSV has seen many 
attempts in the past to do this) could have benefit, but I also see this 
is not easy to get correct and widely deployed.

Thanks again for the detailed read, and helping us think as we prepare 
the next revision,

Gorry

---

From: Tom Herbert <[email-masked]>
Date: Mon, 3 Sep 2018 09:50:36 -0700

On Mon, Sep 3, 2018 at 1:19 AM, Gorry Fairhurst <[email-masked]> wrote:
> I agree MPTCP has needed to work hard to find a way to be deployed, and has
> its
> I guess we could discuss new RTP extensions and the impact on measurement,
> etc. Does it
> really help?
>
Slow is a relative term. Deployment of IPv6 is going on 20+ years, but
defining protocol took much less time. Transport protocols are
conceptually much faster to both develop and deploy since only the
endpoints need to be considered (for instance, Google could deploy
QUIC quickly by making changes to Chrome/Android and its servers). In
reality though, intervening intermediate devices can slow or block
deployment of new transport layer protocols. Relative to the time to
update end devices, time to update middleboxes can be very long. For
instance, there are still many home routers in the wild that go for
years without being updated, if ever.

> campaigns / operator feedback on deploying/managing EDO?
I don't know, I believe that's still in development. We also have UDP
options coming, it will be very interesting to see how firewalls deal
with those.

> I saw your ID on FAST had emerged, and I'm intrigued by how the IETF will
> respond to FAST.
>
I'll post the next draft to tsvg. I'm not yet sure what appropriate WG would be.

> section 7 could benefit from some refactoring.  I confess some of this text
> belonged in bullet two.
>
>> I'd also point out that
> transport headers, and think the draft does say so? However, I'd hope the
> document also notes that these header fields have been used in a range of
> networks - and in some cases were considered important to those who offered
> those services. If that's about to change, this is the place to record their
> current usage.
>
Yes, the use cases are listed, but there are no tangible requirements
that are drawn from these.  Specifically, what specific information is
_required_ to be exposed in a transport protocol? Without
requirements, a transport protocol designer has nothing to start from
even if they wanted to to try to work with the network.

> I agree if "all of them": includes end-users, operators of various shapes
> and sizes and people using a variety of technologies to realise a service,
> as well as apps developers, and content providers, etc - this is a diverse
> community.
>
Sure, as long as end-users have top priority in that list :-)

> My hope would be here to look back at what experience we have and what we
> should consider as we see a way forward.
>
> I do not think we have reached the correct time to evaluate QUIC, the tussle
> with firewalls etc. That's an interesting story that can be told later.
>

Isn't this draft about the "implications of applying end-to-end
encryption at the transport layer"? And isn't QUIC a prime example of
a protocol that encrypts the transport layer information?

The draft says:

"As a part of its design a new protocol specification therefore needs
to weigh the benefits of ossifying common headers, versus the
potential demerits of exposing specific information that could be
observed along the network path to provide tools to manage new
variants of protocols."

However, QUIC draft says:

"QUIC authenticates all of its headers and encrypts most of the data
it exchanges, including its signaling.  This allows the protocol to
evolve without incurring a dependency on upgrades to middleboxes."

So it would seem that QUIC designers already determined that the
demerits of exposing information outweighed any benefits of ossifying
common headers. If that's true, what impact do you expect this draft
will have on QUIC?

> I agree that explicit signalling to the network (TSV has seen many attempts
> in the past to do this) could have benefit, but I also see this is not easy
> to get correct and widely deployed.
>
Maybe so, but I will argue that middleboxes that forcibly inject
themselves in transport layer protocols are _impossible_ to get
correct!

Thanks,
Tom

> Thanks again for the detailed read, and helping us think as we prepare the
> next revision,
>
> Gorry
>
>
>