Re: [Plus] Blog post on quic and tou

[Jana Iyengar <[e-mail]>]

Thanks for forwarding the article. I'll offer some thoughts (and some
corrections.)

There's surely a solid argument to be made about network monitoring, as
this blog post makes. Operators' needs are real, and we need to ensure that
they are able to reasonably do the things that they need to do. At least
for QUIC, exposing a small additional bit of information addresses ~80% of
the use cases mentioned in the document: a "largest acked" ack number on
all packets (or at least packets that contain acks). I won't design this
mechanism on this list, but I'll note that it's a conversation that's
happening in several corners in the QUIC wg. It needs to be aired and
discussed, and I expect it to happen relatively soon.

The article though looks at real needs and current tools that operators
have, and over-generalizes to saying that the "entire header" should be
visible. My argument remains that only what is absolutely required should
be exposed, and that every bit exposed should be debated. This is not a
security argument, it's an ossification one.

The whole point of ossification is that there are third parties that are
unresponsive to changes in allegedly e2e protocols. Middleboxes are
reactive. If they see traffic shifting a particular way, they'll go build
something in response -- I've seen this happen several times. But, they are
not proactive. This creates a serious "deployment impossibility cycle"
where deploying a protocol change widely requires it to work through a huge
range of middleboxes, but even high-end middleboxes will not change
behavior in response until the protocol change is widely deployed. To the
extent that we want to be able to deploy end-to-end changes, unfortunately,
encryption is the only way to ensure that bits that ought not to be used by
a middlebox -- for fear of ossification -- should not be used by one. In Adam
Langley's words
<https://www.ietf.org/proceedings/90/slides/slides-90-httpbis-0.pdf>, "The
end-to-end principle is important, and cryptography is its strongest
guardian."

Having been deeply involved in both the TFO and QUIC efforts in Chrome, I
want to correct some things that the post mentions. First, even if they end
up taking the same amount of time to deploy, yield outcomes with
substantially different scales of benefit. After ~4 years of deployment
work, QUIC is now an open area for experimentation, but TFO is still
exactly one feature. Note that TFO is not yet deployed as widely as QUIC,
see Christoph Paasch's presentation at NANOG
<https://www.nanog.org/sites/default/files/Paasch_Network_Support.pdf> for
more.

On rollout:

"[1] There seems to be a bit of a difference in how this is rolled out. If
you want TCP Fast Open in Chrome, you'll need to enable it via a flag.
Meanwhile my understanding is that QUIC is effectively rolled out by
geographical regions; the flip that's getting switched is server side.
Presumably the latter rollout procedureincludes working with the main
service providers in that area to make sure any problems get fixed in
advance. A process like that would be a lot more tractable than trying to
fix the whole world at once."

This is incorrect. They were both rolled out using the exact same
framework. TFO and QUIC are both also available as flags for the user to
play with, but the experimentation framework is the same and rollout is the
same. Chrome pulled back TFO for a number of reasons. This is of course
still a WIP, and the hope is that we'll get TFO more deployed sooner than
later, but that hasn't happened yet.

On middleboxes:

"[0] Whoops, that's not quite accurate. There is one specific kind of
middlebox that a company like Google or Facebook needs: a load balancer.
And very conveniently, both protocols introduce a new field containing the
information a load balancer needs, and give it special treatment as the one
field that gets to live outside the encryption envelope."

The load-balancer needs to see the connection ID, but the load-balancer is
a trusted part of the serving infrastructure. Specifically, from a crypto
point-of-view, this load-balancer has access to various server keys. This
is quite different than an arbitrary middlebox. More importantly, from an
ossification perspective, a load-balancer ossifying would be equivalent to
the server ossifying.

- jana

On Wed, Dec 7, 2016 at 7:12 AM, Mirja Kühlewind <
[e-mail]> wrote:

> hi all,
>
> here is an interesting blog post on middleboxes:
>
> https://www.snellman.net/blog/archive/2016-12-01-quic-tou/
>
> Mirja
>
> _______________________________________________
> Plus mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/plus
>