Re: Greasing the QUIC Bit

Paul Vixie <> Thu, 02 July 2020 15:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1FACA3A087B for <>; Thu, 2 Jul 2020 08:16:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B2K4ZpzMzONn for <>; Thu, 2 Jul 2020 08:16:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3ECE93A0838 for <>; Thu, 2 Jul 2020 08:16:13 -0700 (PDT)
Received: from linux-9daj.localnet ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (1024 bits) server-digest SHA256) (Client did not present a certificate) by (Postfix) with ESMTPSA id 0F83EB0588 for <>; Thu, 2 Jul 2020 15:16:10 +0000 (UTC)
From: Paul Vixie <>
Subject: Re: Greasing the QUIC Bit
Date: Thu, 02 Jul 2020 15:16:08 +0000
Message-ID: <4717330.G4jNEy2Xmo@linux-9daj>
Organization: none
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <>
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: Thu, 02 Jul 2020 15:16:16 -0000

On Thursday, 2 July 2020 13:18:59 UTC Brian Trammell (IETF) wrote:
> ...
> I continue to fear that the demand for on-path discrimination of QUIC
> traffic will remain such that if:
> - there is no intentional invariant for distinguishing QUIC traffic from
> non-QUIC traffic by arbitrary on-path devices; AND - there is a trivially
> deployable method for blocking QUIC traffic which will result in negligible
> end-to-end availability risk and low impact on quality of experience, i.e.
> that blocking will come at no cost to access networks that choose to do so
> (which given TCP fallback is indeed the case in the majority of networks,
> unless things have changed since I last looked)
> then we remain at risk of a rapid reversal of fortune on deployment. Sorry,
> hadn't said that at a mic for about a year now, felt a need to repeat it
> for the record. :)
> As this view is incapable of gaining consensus within this working group,
> I'm fully in support of this approach to greasing the QUIC bit: we should
> be intentional about our invariants, and back them up with running code.
> And this appears to be a perfectly reasonable way to do that.

among the SASE (secure access service edge), such as enterprise, home, and 
other privately operated networks, QUIC is going to face accidental reverse 
discrimination. UDP is privileged here, only permitted if it is recognizably 
permitted. if QUIC offers no way to be recognized, then the fortunes of its 
deployment will be moderate.

when i say privileged, i mean default-deny in both host-based firewalls and 
perimeter gateways. i hope to be able to use QUIC on such networks, but i 
won't do so if it's an all or nothing proposition-- allow any unknown traffic 
or disallow QUIC, means to me, disallow QUIC. my position will be typical 
among CISO's. if QUIC is intended only for public (ISP or mobile IP), then i 
withdraw my concern.

the QUIC bit isn't enough to hook onto, so greasing that doesn't hurt the SASE 
use case. but i think we'll all be better off if we don't have SASE networks 
using destination UDP port number as the hook for "allow this traffic".

see also: