Re: Is "Version Greasing" a new benfit or a new obstacle?

Christian Huitema <huitema@huitema.net> Fri, 12 April 2019 16:14 UTC

Return-Path: <huitema@huitema.net>
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 ACDC41202EA for <quic@ietfa.amsl.com>; Fri, 12 Apr 2019 09:14:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 9eJzWZlcisKa for <quic@ietfa.amsl.com>; Fri, 12 Apr 2019 09:14:39 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D86A5120006 for <quic@ietf.org>; Fri, 12 Apr 2019 09:14:29 -0700 (PDT)
Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx62.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1hEyoi-0001pr-FA for quic@ietf.org; Fri, 12 Apr 2019 18:14:19 +0200
Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp05.mail2web.com with esmtp (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1hEyo3-0002ek-Hd for quic@ietf.org; Fri, 12 Apr 2019 12:14:10 -0400
Received: (qmail 28258 invoked from network); 12 Apr 2019 16:13:34 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.204]) (envelope-sender <huitema@huitema.net>) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for <john.border@hughes.com>; 12 Apr 2019 16:13:33 -0000
To: Ian Swett <ianswett=40google.com@dmarc.ietf.org>, Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org>
Cc: "Gorry (erg)" <gorry@erg.abdn.ac.uk>, Roberto Peon <fenix@fb.com>, Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, "quic@ietf.org" <quic@ietf.org>, "Border, John" <john.border@hughes.com>
References: <5CADADDD.7010005@erg.abdn.ac.uk> <EBF1BF30-62A5-4659-8AEC-0D5B3F2D65C6@fb.com> <BL0PR11MB3394294313F8F54A3D0CF4A3902E0@BL0PR11MB3394.namprd11.prod.outlook.com> <CAN1APdcm0hnT_Mu7D7x5QM6pApOQw1RdWCBkgY16bd5YWNtFkA@mail.gmail.com> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <CAN1APdeSF0-_N=mb1xkoe_qLwoVqP+X9_Wawi=Zu__6wdHtbOQ@mail.gmail.com> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> <CAN1APde2SO6fkNzyznbv2-xNuXkkuC=bN3p8xRgwmRAmsZxrgA@mail.gmail.com> <MW2PR2101MB104902B6BC7C67D8688EA852B6280@MW2PR2101MB1049.namprd21.prod.outlook.com> <MW2PR2101MB104996C29680DF7B79230C8CB6280@MW2PR2101MB1049.namprd21.prod.outlook.com> <CAKcm_gMwcwZ0VzK4vDt-sCQctHVrwOm9ekPPi3O3Y2UnRrZaBw@mail.gmail.com>
From: Christian Huitema <huitema@huitema.net>
Openpgp: preference=signencrypt
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <02f27c4e-2d1e-29ab-6891-236442436a3c@huitema.net>
Date: Fri, 12 Apr 2019 09:13:31 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <CAKcm_gMwcwZ0VzK4vDt-sCQctHVrwOm9ekPPi3O3Y2UnRrZaBw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------383F252D8F60216B31D21C00"
Content-Language: en-US
Subject: Re: Is "Version Greasing" a new benfit or a new obstacle?
X-Originating-IP: 168.144.250.245
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5heXGUEY33L3SuqRq/B1/dh602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVib4FXaeYWzXqH4yGi5ZkOXM7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBCnY1T4UEFfy74vbELeG6IB/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8l4YBmPrqPoeRXD34azf1rYZv5uZUEePrXZkexHL9EC3AAJAfA 9MMVcQ9WVjD1q+Rbd9IPG/DQ2p+GU04sTuYFs91jhnM/Mbva2XLV/LIEzaKyLm0zESXAkIAT8ZKA DvsGI5uh86ZVnyOrYkLMWyEaRt9fxN2oReTDHAyOynaY0CmHJLVH4DfVNbPXJmiLfub/IRFsicyJ MEhQFtD8PLoiniWmsFByBoXAuCZEyg59LM/9rUJrEbVA84BZVscMTXpbpuxXJTL417vaJWq5kk+j cuidX4Ts4xdG+C13IyWeZaIKaP92kYvCAgLvXDsJxwwjBghaQhmflKrDNyY/iPwMaIsqSF1qfykN oXQMKwAQL5iAImxrekFydH4DojSCKJXVXfdz0+Q1eHsqtFQKXUaZ+h596SWGosiQ15/fAFUBngWU swziTuoonQBgr0dS5AZLiwQzKw+6v3CaIMG6s7LqJB5zW4lvOt7yZYITzR9pjE5SyaRgIwuFZktu hI3SFVknr3KOT4rLUOf5LEA9gpTWpQ+EK/9ZZ/oAb/nWI9xFQs3tOuTWXXIj0TpQpfUxR/zGwdBB Bfh3x3VaPNtdo70DPj5Gegm2Di+XkC+U0gjMGGKacOVTXotsdlkDAl5HBq84rNLMkKiSx4DbX99P +gh4iWPT5m4OdqWMdE0b4Joz08+J+cv73CChOPjKA0/DVd830vHLIFSGGMV7x6CHvZpJG/9P/4OG qJ5dkO1xTEy0joEwyGTHIAoNFX+jcW7DGmdEezpuI9IICsCKA/p66v7fhw==
X-Report-Abuse-To: spam@quarantine9.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/7kH7llpWjOMqakUrflcOwx8TT0I>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 12 Apr 2019 16:14:41 -0000

On 4/12/2019 8:57 AM, Ian Swett wrote:
>
> *From:* Praveen Balasubramanian
> *...*
>
> Version greasing will create problems for DDoS protection. The DDoS
> protection middlebox will have to treat all traffic with unknown
> version numbers as plain old QUIC and rate limit it. Any solution that
> requires per connection state to track version numbers doesn’t scale.
> Especially in the cloud scenario customers bring their own web servers
> so this makes any opt-out solution not good enough. So I do think this
> is an obstacle for many deployments.
>
Don't we have an example of middle-box ossification just there?

Praveen's example points to the perils of the "shortest path" approach
to middle-box design. Taking the shortest path means finding something
that works now, and once you have found it deploy it without worry about
consequences -- which very often include ossification. If the DDOS
protection box looks for "QUIC versions that it knows" and just rate
limits the other types of packets, then the box will by design prevent
deployment of versions that it does not know.

I assume that big organizations like Azure will update their protections
once a new version is out, but the experience shows that many other
organizations don't. And even when they do, the focus on published
versions will block experimenting with new versions, not to mention
interfering with other features like connection migration. I take
Praveen's example as an argument why we should in fact standardize
version greasing, precisely to avoid this "shortest path middle-box
design".

In the case of DDOS protection, I will point out that DDOS protection
also needs to work with short header packets, which do not carry any
version number. In order to avoid DDOS by short header packets, the
boxes have to be able to distinguish between packets that belong to
authorized connections and packets that don't. And if you do that, then
you don't really need to look at the version numbers, you can simply
rely on the invariants.

-- Christian Huitema