Re: Is the invariants draft really standards track?

Paul Vixie <> Sat, 20 June 2020 18:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 35C183A08BB for <>; Sat, 20 Jun 2020 11:34:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nNLMAvJnSIC5 for <>; Sat, 20 Jun 2020 11:34:47 -0700 (PDT)
Received: from ( [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 75BC23A07EA for <>; Sat, 20 Jun 2020 11:34:46 -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 25C9AB07D0 for <>; Sat, 20 Jun 2020 18:34:44 +0000 (UTC)
From: Paul Vixie <>
Subject: Re: Is the invariants draft really standards track?
Date: Sat, 20 Jun 2020 18:34:41 +0000
Message-ID: <1621715.PBmxXT1aCC@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: Sat, 20 Jun 2020 18:34:49 -0000

On Friday, 19 June 2020 23:51:39 UTC Christian Huitema wrote:
> ...
> The DOS box does not have to worry about what kind of traffic is coming
> in. It just has to open a context for the 5 tuple, and check whether it
> sees 1-RTT packets coming back. And then maybe count the volume of 1-RTT
> packets coming back.
> The worry is that one of the bots might start a legitimate connection,
> then disclose its five tuple to the rest of the botnet. The whole botnet
> can then spoof the 5 tuple that was just pin-holed by the DOS box. A
> simple "open-close" logic is thus not good enough. The DOS box must also
> enforce some kind of rate limiting per 5 tuple.
> Which also means that if a botnet can predict the 5 tuple used by a
> legitimate connection and then spoof it, it can DOS it. Once you start
> digging that particular rabbit hole, the joy never stops...

pinholing based on outbound is the worst possible solution to DDoS, except for 
all the others. stateful firewalls of this kind create _almost_ as many 
problems as they solve, and would not be used if an alternative existed. this 
is a BCP38 problem not a QUIC problem. QUIC's only responsibility is to not 
make this known-bad situation worse.

there are two important ways that QUIC can avoid making the situation worse.

first, make connection mobility an outbound-first activity for initiators. the 
new 5-tuple would have to be negotiated in-band, and the first packet of the 
new flow would have to come from the initiator, to create the new pinhole.

second, make the new flow identifiable by the DOS box (or other filtering 
router such as a firewall box) using some low-entropy invariant. at the moment 
all we have to go on for detecting new outbound QUIC flows is a destination 
UDP port number, and that's both constraining and fragile.