RE: Is the invariants draft really standards track?

[Mike Bishop <[e-mail]>]

Negotiating the 5-tuple in-band is problematic in the client-server direction; in the presence of a NAT, the client doesn't know what address/port the server is going to see when it uses a new path.  For the same reason (NAT opening), the client always goes first with connection migration, even if it's the server's address changing.  However, we're assuming that the server has the ability to provide the client a directly-reachable address, so that probably covers your in-band negotiation.

-----Original Message-----
From: QUIC <[e-mail]> On Behalf Of Paul Vixie
Sent: Saturday, June 20, 2020 2:35 PM
To: IETF QUIC WG <[e-mail]>
Subject: Re: Is the invariants draft really standards track?

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.

--
Paul