Re: Don't require proof of waste! (was: Idea: DoS prevention by proof-of-work in Initial packet)

[Christian Huitema <[e-mail]>]

On 9/1/2022 11:59 PM, libor.peltan wrote:
> Hi all,
>
> I'm developing DNS-over-QUIC implementation in authoritative Knot DNS. 
> I'm highly concerned about DoS resistance. According to our findings 
> so far, the situation around authoritative DNS-over-QUIC (ADoQ) is 
> following:
>
>  - The server can try to defend by requiring Retry packet, which 
> prevents source address spoofing and too simple Initial packet floods, 
> but also cripples legitimate connections by an additional RTT for the 
> whole duration of attack (possibly all the time).

You can mitigate the impact on legitimate connections by having the 
server provide "NEW TOKEN" frames to the clients that have been 
validated. The clients can then use the tokens in the next connection to 
directly validate their IP address.

>
>  - A determined attacker can simply proceed with complete connections, 
> including Retry packets. We have developed even the tools to perform 
> such attacks.

Yes. This is a general attack against TLS. The initial handshake 
includes extensive public key operation. Attackers can force the server 
to create lots of new connections, each time requiring the public key 
operations.

Note that this is mostly a connection setup issue. The public key 
operations require lots of CPU during the handshake, but once that is 
done, the cost of AEAD encryption of the QUIC packets is a small part of 
the overall total -- typically much less than the cost of the UDP socket 
operations.

>  - Opposed to plain DNS, the bottleneck is no longer any connection 
> bandwidth. When both sides encrypt and decrypt all the packets, what 
> matters is the CPU power.
>
>  - QUIC protocol seems to be balanced in the way that it gives no 
> advantage to client or server side. If (and only if) the attacker has 
> more CPU power available, it's able to exhaust the server computing 
> resources, leading to DoS.

Servers can mitigate the issue somewhat by using hardware acceleration, 
e.g., a specialized cryptographic engine.

>
> I must admit I'm a "DNS guy" and I might have imperfect insight in 
> QUIC nuances. Is there any tactic that would help defend the server 
> against DoS? I always think that HTTP-over-QUIC servers must face the 
> same issues. But it's also possible that they just rely on CDNs and 
> stuff, which is not really appliable on common authoritative DNS.

Your initial subject line mentioned grafting some kind of "proof of 
waste" (aka proof of work) in the initial exchange, to force the clients 
to slow down. We have seen proposals like that for a long time, starting 
with the idea of adding proof-of-waste token to e-mail as a way to fight 
spam. This does not work. DDOS attackers typically use someone else 
servers, and don't mind wasting energy and raising electric bills on the 
bots. Also, consider that the DoQ client sometime run on mobile devices, 
and that wasting energy there is not practical. Plus, generally, 
protocols that deliberately waste energy are bad for the planet, and 
should be avoided.

>
> I looked also at Retry packet offload, but this does not make much 
> sense for ADoQ.

You should try using the combination of Retry and NEW TOKEN.


>
> Thank you for any replies, suggestions and ideas!


There is no good "local" solution to DDOS. Once your servers are 
attacked by a large enough botnet, all bets are off. Indeed, attacks 
using UDP would work too. The only defenses that work involve getting 
help from a big CDN or similar. Or building very large server 
configurations, like the DNS root.

-- Christian Huitema