Re: Is the invariants draft really standards track?

[Paul Vixie <[e-mail]>]

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