Re: [Plus] Blog post on quic and tou

Jana Iyengar <jri@google.com> Wed, 07 December 2016 21:35 UTC

Return-Path: <jri@google.com>
X-Original-To: plus@ietfa.amsl.com
Delivered-To: plus@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF382129C02 for <plus@ietfa.amsl.com>; Wed, 7 Dec 2016 13:35:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.596
X-Spam-Level:
X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d50KCkp86LpL for <plus@ietfa.amsl.com>; Wed, 7 Dec 2016 13:35:37 -0800 (PST)
Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 882D7129BF5 for <plus@ietf.org>; Wed, 7 Dec 2016 13:35:36 -0800 (PST)
Received: by mail-vk0-x22a.google.com with SMTP id x186so219585377vkd.1 for <plus@ietf.org>; Wed, 07 Dec 2016 13:35:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+q2JDVdBUqwIhPtOv8mwCff76dbLKahTCc+cIzVf3wU=; b=GHkAzXgsS8co3WryQRZbwJZ77F6yj8xEW+9J2VusiiuIv5rAZe5wnTRTyEL+cHmHrB UYQiFLjSzMqO5QERHvK1/ZQMjejR2ES1Mp8JeMlDt7tCJ4UcmoXVOPS5t2vRGNqzpqGW Vlm40AastpOglRfW6HqL4WhHf0yBIjBWNY//6kNFdV0LXw6YaQ4VYEuX0VpURPbqhOef X5wH2Kj1YX+hNB6lfhHmz+mWUKa7y8Zfw8XxSibGiM/Cd5RD3/Z4eylVMiQJgA/svUGD 0XAJtEY6wmpTykNBNG0ZiJ7y0Y+XOSCuscVl9C7uy5k0O0qWREXlApQkIOYZcca6VKzF BDeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+q2JDVdBUqwIhPtOv8mwCff76dbLKahTCc+cIzVf3wU=; b=fyFYJ9E1eALKX0/o3oTIULWZGswt1cyfPXXCwJuSPfK+eM+Nof5tAkmwjJ9N+CSdSG cMCLuGEQ9stvLy0e4GDACFoyfZhI7hxdCcztejNJTH6pMGCjsJwuqWilT1KWBYxZmZHv Q+v+7SJ1FeESUHq1Iqt8MOk/CE7mNU5aUI6nJl0NJgBnBIy5zx6jnDwe5sJoqcDeoZsa vpTjI3uq+rzzpODO7SjKBMYs7VU1mhVeKY7WZaCf9aVqGleuwW5NVsxcosjJqoHl/MTn YBhZ6DZ2ikkJfsHTRD2wQGJ10Nu1FRBtRg/KgUik1Wk9M8eIttvfb58fzlrCgqKSukHT uSdw==
X-Gm-Message-State: AKaTC02cTWjiK4PtJ4KKn+JGE4JPBP5bsQM2rhz+wqAxw3+C6kqbkJrLMa0k2Pv7qoEl3oACcwMeXgGwyWwp5+aO
X-Received: by 10.31.52.145 with SMTP id b139mr22720681vka.151.1481146535307; Wed, 07 Dec 2016 13:35:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.51.132 with HTTP; Wed, 7 Dec 2016 13:35:34 -0800 (PST)
In-Reply-To: <6850cb85-6b26-e5b8-50a9-7565c39b0c28@tik.ee.ethz.ch>
References: <6850cb85-6b26-e5b8-50a9-7565c39b0c28@tik.ee.ethz.ch>
From: Jana Iyengar <jri@google.com>
Date: Wed, 7 Dec 2016 13:35:34 -0800
Message-ID: <CAGD1bZaXto+fq9A806ME1bonZv0639Yu5yazyp_eeeOQemeNzw@mail.gmail.com>
To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>
Content-Type: multipart/alternative; boundary=001a114348b6196f2a0543184d2d
Archived-At: <https://mailarchive.ietf.org/arch/msg/plus/YVDxzrttFJxTxPUEJVtiNWx2iFg>
Cc: plus@ietf.org
Subject: Re: [Plus] Blog post on quic and tou
X-BeenThere: plus@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussion of a Path Layer UDP Substrate \(PLUS\) protocol for in-band management of in-network state for UDP-encapsulated transport protocols." <plus.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/plus>, <mailto:plus-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/plus/>
List-Post: <mailto:plus@ietf.org>
List-Help: <mailto:plus-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/plus>, <mailto:plus-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2016 21:35:40 -0000

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 <
mirja.kuehlewind@tik.ee.ethz.ch> 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
> Plus@ietf.org
> https://www.ietf.org/mailman/listinfo/plus
>