[dns-operations] Tracking the DNS amplification attacks

[Florian Weimer]

* Florian Weimer:

> There is no inherent difficulty in securing TCP applications against
> low-bandwidth (!) attacks.  It's just that application and TCP stack
> writers have decided not to do anything about it, assuming that
> attackers would switch to high-bandwidth attacks if the vulnerability
> were addressed.

It occurred to me that this claim might be preceived as bold.  So
here's a back-of-the-envelope calcuation: you can keep TCP connection
state in around 300 bytes (including lookup table and LRU list
overhead; IIRC, this matches Netfilter per-connection overhead).
Instead of keeping a packet buffer for the reply, you store the
question, and regenerate the reply packet each time you receive an
ACK.  You can even avoid storing large (260 byte) questions if you are
willing to turn NXDOMAINs into FORMERRs and haven't got long names or
wildcards (you only need to do this if the the first response packet
does not receive an ACK).

Even with large questions, a 100 MB TCP connection store can keep
about 175,000 parallel connections.  At Fast Ethernet speeds, this
will last for about a second in the worst case, after that you need to
drop connections.  But a legitimate TCP connection which receives a
reply within a second would not be affected (three round-trips within
one second seem doable in most cases, provided that there is no
congestion--but we are talking about low-bandwidth attacks anyway).

Of course, this requires a very specialized TCP implementations which
you'll likely find only in purpose-built devices (whose makers have
benefited somewhat from the vulnerabilities inherent to the BSD
sockets API).