Re: Greasing more of QUIC

"Brian Trammell (IETF)" <ietf@trammell.ch> Thu, 07 December 2017 09:11 UTC

Return-Path: <ietf@trammell.ch>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524EB120454 for <quic@ietfa.amsl.com>; Thu, 7 Dec 2017 01:11:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 xg3UgMafO0Wy for <quic@ietfa.amsl.com>; Thu, 7 Dec 2017 01:11:42 -0800 (PST)
Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC93F1200C1 for <quic@ietf.org>; Thu, 7 Dec 2017 01:11:41 -0800 (PST)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 3C638340E11; Thu, 7 Dec 2017 10:11:40 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.14314); Thu, 7 Dec 2017 10:11:40 +0100 (CET)
Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Thu, 7 Dec 2017 10:11:40 +0100 (CET)
Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 38487100; Thu, 07 Dec 2017 10:11:40 +0100
From: "Brian Trammell (IETF)" <ietf@trammell.ch>
Message-Id: <68B6C3D7-243D-4E0A-B8D1-34AE5E08468A@trammell.ch>
Content-Type: multipart/signed; boundary="Apple-Mail=_FAAD140C-C1CF-4FF4-865F-52B1B16EBBBC"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: Greasing more of QUIC
Date: Thu, 07 Dec 2017 10:11:39 +0100
In-Reply-To: <CABkgnnUxr3cAv81m5PfzRb+LWbiUq1qaASMnLkG+hEokHR714A@mail.gmail.com>
Cc: QUIC WG <quic@ietf.org>
To: Martin Thomson <martin.thomson@gmail.com>
References: <CABkgnnUxr3cAv81m5PfzRb+LWbiUq1qaASMnLkG+hEokHR714A@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/AitMy2-WhxP-pm6bE0-Oh7cc_cQ>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Dec 2017 09:11:45 -0000

hi Martin,

> On 7 Dec 2017, at 06:03, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> I've sort of promised a few times, to a few people, that I'd write up
> the state of play regarding greasing.  I just did that and it got
> somewhat lengthy.  So I decided that I'd put the words in a draft.
> Sorry.  That's what you get when publishing drafts gets easier...
> 
> https://datatracker.ietf.org/doc/html/draft-thomson-quic-grease

First, I'll note that draft focuses on runtime adaptations: how can we scramble the wire image to resist analysis by vendors who will implement the results of that analysis in ways that might break future QUIC versions by dropping packets? This is only part of the space of mitigations available to us. There are also design- and deployment-time adaptations: exercising the version negotiation mechanism, for instance, by making the V2 header beyond the invariants gratuitously incompatible with the V1 header and deploying it very, very soon after V1.

When you said "this got lengthy", what I was hoping I'd see here, and didn't, is an explicit statement of the threat model the greasing we apply is meant to counter. "Ossification", yes, great, but in order to be able to evaluate the tradeoffs (especially between XOR and FFX), we need to get a bit more specific about what that means.

I can think of a couple of axes along which we can classify these models:

(1) Adversary intent: what is the middlebox trying to do? Block QUIC? Whitelist QUIC traffic to block non-QUIC UDP garbage? Track QUIC flow state to whitelist QUIC traffic on a per-flow basis? Classify QUIC traffic by version? Classify QUIC traffic by overlying application layer protocol? Infer end-user activity through the analysis of QUIC traffic? Break QUIC in subtle ways for evil fun? We should be clear about what we're trying to keep from happening *with greasing* (as opposed to with packet protection).

(2) Adversary information: Does the middlebox's creator participate in the standardization process? Does it passively consume the final or intermediate products of the standardization process? Does it statically or dynamically analyze the behavior of open-source implementations of the protocol in a controlled envionment? Does it statically or dynamizally analyze traffic captured from experimentation with open- and closed-source deployments of the protocol on the open Internet? The method by which the adversary figures out what the protocol does

(3) I'm trying to come up with a non-pejorative way to say this but I can't, so, adversary competence: Much of the trouble we've run into with TCP is with lazy or simply bad implementation of well-meaning intent ("we never see options so eh, why write that code?"), or with poor design based on a fundamental misunderstanding of the problem space ("this 2G network sucks, but it was expensive, so it must be TCP's fault; let's screw around with ACK timing, which worked in our experiments with $STACK_X, which is fine because clearly nobody will ever run anything other than $STACK_X on this network"). In general the assumption that laziness is a virtue holds -- designed systems in state-intensive environments tend to try to minimize their state requirements at the expense of correctness, and in any case, it makes economic sense to minimize the effort and expense in designing and implementing said systems, so corner cases will lead to cut corners. But it is very hard to model the laziness of other people, so this is the fuzziest and most guess-prone axis of the three.

Greasing is of most utility, IMO, when it is used to prevent lazy, somewhat-competent middlebox creators with access to but little interest in reading the specs from expanding the set of invariants beyond those which we prescribe, whether intentionally or unintentionally (indeed, a non-lazy adversary working to intentionally expand the set of invariants would just send a pull request on the invariants doc. :) ).

Doing something to protect the ability to expand/change the location and semantics of the packet type switching mechanism and the packet number space and encoding in future versions seems like it's worth doing. Attempting to make these mechanisms resistant to analysis, though, doesn't seem like it has a benefit commensurate with effort and proneness to error.

> Based on this, I'm a little more enthusiastic about protecting packet
> numbers, mainly for the secondary benefits that come with it.  But
> I'll let others reach their own conclusions about that.

I'm also a *little* more enthusiastic, depending again on what the threat model is, and whether we want the packet numbers to be decodable at all along the path by devices which do understand the protocol (i.e. for one- and two-point loss measurement, as well as to reject bad spin bit samples, on which see https://tools.ietf.org/html/draft-trammell-quic-spin-00#section-3.3).

Cheers,

Brian