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
