Return-Path: 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 9CFCF12008A for ; Mon, 15 Apr 2019 02:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 9AjdYn_fnktQ for ; Mon, 15 Apr 2019 02:20:14 -0700 (PDT) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 A883212002F for ; Mon, 15 Apr 2019 02:20:12 -0700 (PDT) Received: from smtp6.infomaniak.ch (smtp6.infomaniak.ch [83.166.132.19]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x3F9Jn9h006245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 15 Apr 2019 11:19:50 +0200 Received: from [IPv6:2a00:79e1:abc:307:5d80:b383:7b80:b51b] ([IPv6:2a00:79e1:abc:307:5d80:b383:7b80:b51b]) (authenticated bits=0) by smtp6.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x3F9Jm05031695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 15 Apr 2019 11:19:48 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: Is "Version Greasing" a new benfit or a new obstacle? From: "Brian Trammell (IETF)" In-Reply-To: <5CB1C214.4030501@erg.abdn.ac.uk> Date: Mon, 15 Apr 2019 11:19:48 +0200 Cc: Roberto Peon , Praveen Balasubramanian , Ian Swett , Christian Huitema , Mirja Kuehlewind , =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "quic@ietf.org" , "Border, John" Content-Transfer-Encoding: quoted-printable Message-Id: References: <5CADADDD.7010005@erg.abdn.ac.uk> <9084B09D-5E13-49FA-BA93-0D7276CDE420@erg.abdn.ac.uk> <699E2135-A3CE-4D33-91F6-D3C96E66674F@ericsson.com> <02f27c4e-2d1e-29ab-6891-236442436a3c@huitema.net> <9C6D92FF-7635-48BD-A65B-FAB4B544476D@fb.com> <5CB1C214.4030501@erg.abdn.ac.uk> To: G Fairhurst X-Mailer: Apple Mail (2.3445.102.3) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 09:20:17 -0000 hi Gorry, all, > On 13 Apr 2019, at 13:03, G Fairhurst wrote: >=20 > Bringing this thread back - to me it seems there has been lots of = discussion about how "version greasing" can be added in various ways, = and very little on what makes this necessary and worth the impact on the = network. >=20 > I still don't do not see that the side effects are worse when the = protocol requires the version to be unobfusticated (as in most other = IETF transport protocols). +1. I continue to be confused about the amount of effort we're = apparently willing to put into version negotiation protection of a = protocol that is *explicitly* designed to be blockable outright (by = virtue of the TCP fallback requirement). I haven't seen anything in this = thread, or any of these discussions preceding it on this subject, that = indicates that the actual risk of harm with respect to version blocking = is discernibly worse (or even discernibly different) than the risk of = harm with respect to blocking of the entire protocol regardless of = version.=20 I can see two reasons a version negotiation process could get blocked in = the network: (1) As an explicit choice by a traffic inspection function that it must = have a specific version (or versions) of a protocol because it inspects = information only available in that version of the wire image. Note that QUIC is different from all other situations from which we = could derive experience, since there simply isn't that much wire image = for an inspection function to grab on to, and I can't imagine a future = in which a future version would omit information it'd be worth blocking = the version over (as opposed to all of QUIC, forcing TCP). Indeed, note = that we made the latency spin bit probabilistic, as opposed to = negotiated, in part to remove a potential incentive to ossify version = negotiation. It's possible that a device might want to block non-V1 versions because = the handshake protection keys are hardcoded into the device. I'm not = sure I see how dynamic aliasing could be reliably made to address this = problem, though publishing v1 with N aliases (i.e. static aliasing) with = different keys would at least ensure that devices with only one key slot = don't work. (2) As an overcorrection by a traffic inspection function that mistakes = thinks that a particular sequence of version negotiation packets is a = protocol identifier. As I see it, the current version negotiation proposals only make this = worse, not better, by creating a semantically indistinguishable set of = aliases for the same operation. This problem could be nicely sidestepped = by punting version negotiation into the future. Cheers, Brian > Gorry >=20 >=20 > On 12/04/2019, 17:41, Roberto Peon wrote: >>=20 >> I=E2=80=99m not sure that I agree there=E2=80=94there is no need to = have it standardized so long as the LB is involved in picking it. Each = LB system can choose whatever it wants. Thus, every LB **deployment** = could use a different scheme with different grease. Every LB deployment = could change the scheme it uses pseudo-randomly or according to the = lunar calendar, etc. >>=20 >> Because there is a dynamic (and controlling) component (namely the = part of the LB system which vends and then later routes CIDs), there is = no need for anything else. >>=20 >> -=3DR >>=20 >> *From: *Praveen Balasubramanian >> *Date: *Friday, April 12, 2019 at 9:28 AM >> *To: *Roberto Peon , Christian Huitema = , Ian Swett >> *Cc: *"Gorry (erg)" , Mirja Kuehlewind = , Mikkel Fahn=C3=B8e J=C3=B8rgensen = , "quic@ietf.org" , "Border, John" = >> *Subject: *RE: Is "Version Greasing" a new benfit or a new obstacle? >>=20 >> Re. Encoding in CID. Then it needs to be standardized and if it is = standardized what=E2=80=99s the point in greasing? Let=E2=80=99s not = ignore the smaller services who use the cloud i.e. people deploying say = NGINX web servers in AWS, Azure or GCP. Not every QUIC deployment is a = large first party service which controls all aspects how LB and DDoS are = done. In public clouds LB and DDoS protection are network functions = (services) and are middleboxes under a completely different = administrative domain. >>=20 >> Christian, this is about source address validation by the middlebox. = This is how it works for TCP (think SYN cookies) and we need to have = parity for QUIC. When under attack, short header packets will be dropped = for addresses that have not been validated, but this is the same for = non-SYN packets for TCP. I don=E2=80=99t understand how invariants can = be used here. If we don=E2=80=99t have parity for DoS protection in = network then QUIC traffic will be rate limited which is going to be = really bad for performance. FWIW there is already DoS traffic that looks = like QUIC. >>=20 >> *From:* Roberto Peon >> *Sent:* Friday, April 12, 2019 9:16 AM >> *To:* Christian Huitema ; Ian Swett = ; Praveen Balasubramanian >> *Cc:* Gorry (erg) ; Mirja Kuehlewind = ; Mikkel Fahn=C3=B8e J=C3=B8rgensen = ; quic@ietf.org; Border, John = >> *Subject:* Re: Is "Version Greasing" a new benfit or a new obstacle? >>=20 >> For any large deployment, I suspect they=E2=80=99ll need LB. >>=20 >> For most kinds of LB-ing, I=E2=80=99d expect the LB system to either = directly or indirectly be involved in choosing/vending connection IDs. >>=20 >> If it is involved in vending/choosing connection IDs, it can encode = version information into the CID. >>=20 >> -=3DR >>=20 >> *From: *Christian Huitema >> >> *Date: *Friday, April 12, 2019 at 9:13 AM >> *To: *Ian Swett >>, = Praveen Balasubramanian >> >> *Cc: *"Gorry (erg)" >>, Roberto Peon >>, Mirja = Kuehlewind >>, Mikkel Fahn=C3=B8e = J=C3=B8rgensen >>, "quic@ietf.org = >" >>, = "Border, John" >> >> *Subject: *Re: Is "Version Greasing" a new benfit or a new obstacle? >>=20 >> On 4/12/2019 8:57 AM, Ian Swett wrote: >>=20 >> *From:* Praveen Balasubramanian >> *...* >>=20 >> 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=E2=80=99t 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. >>=20 >> Don't we have an example of middle-box ossification just there? >>=20 >> 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. >>=20 >> 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". >>=20 >> 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. >>=20 >> -- Christian Huitema