[dns-operations] question for DNS being attacked

[Vernon Schryver]

> From: Michael Graff <mgraff at isc.org>

> > That conclusion does not hold, because it does not define the narrow
> > window alternative.  11 times as wide as what?
>
> With a slip factor of 2, every other packet will be dropped, and the =
> other packets returned will have the truncated bit set.  If this is =
> incorrect, please explain what it does do.
>
> This translates to a "normal" truncated response 50% of the time, and a =
> timeout the other 50%. 

That is true only if you modify the patch to accept a rate limit
threshold 0.  Otherwise the truncated responses and timeouts happen
only during attacks involving flooding, including what I assume are
meant by spoofing flood attacks.  I don't think running with a rate
limit threshold 0 makes any sense, but I've often been called lacking
in imagination.

If I should have understood "normal" as "normal during a spoofing
flood attack," then we can talk about what happens with IP instead 
of (IP,qname,type) rate limiting and the thresholds for particular
instances of the universal IP rate limiting.


>                         Ignoring the penalty BIND 9 and other servers =
> are likely to assign to this misbehaving server, the timeout keeps the =
> "Waiting for a response" window open much, much longer. 

Again, longer than what?  The alternative is *not* an absense of rate
limiting and so an absense of windows during which the target is
prevented from receiving responses from the real authoritative server.
As I said before, whether one uses (IP,qname,type), IP bandwidth rate
limiting or both, the target can be prevented from getting response
from authoritative servers.  The only things that vary are the contents
of the packets used by the attacker to blind the target, perhaps (but
not necessarily) the bandwidth used by the blinding packets, and whether
the thresholds for the rate limiting were consciously chosen to deal
with any kind of DNS issue.  It's a mere implementation detail of the
attack whether the window is held open by the authoritative server's
refusal to answer or by configured or de facto bandwidth rate limits
in the server or the path from the server to the target.

A separate aspect of this supposedly much, much longer window is that
it seems to assume that after the client has received a truncated or
TC=1 response and is going through the DNS/TCP dance, it will still
accept forged, evil DNS/UDP responses from the attacker.  Is that true
of common resolving servers and resolver libraries?  It's not how I'd
write a resolver.  Instead I'd discard all of the state needed to
accept apparently stale UDP responses before the TCP SYN is sent.


> "Waiting for a response" window open much, much longer.  This timeout is =
> largely server-dependent, and some may wait multiple seconds.  This =
> leaves the window open for a spoofing flood attack to sneak in.

Again, longer than what?

> While I commend you and Paul on the RLL work you've made, I think it is =
> improper to not mention this in the documents you write.  It may be "not =
> a big deal" to the administrator of the zone, but it is up to them to =
> decide that.  Some may prefer to be a flooding source rather than make =
> their zone more prone to spoofing, even if the actual odds are low.  The =
> biggest problem here is that the zone publisher's goals of not being =
> spoofable are entirely dependent on the resolver asking the questions, =
> without DNSSEC in the mix.

The notion that there is an alternative to rate limits is wrong.
There are rate limits in the path from the server and to the client
whether anyone has consciously configured them below the limits
imposed by service bit rates.  The lowest limit might be in firewalls
near the server or the client or in intermediate router queues, but
it will exist and can often (almost always?) be utilized by an
attacker using the 20x-50X amplification of DNSSEC.


Vernon Schryver    vjs at rhyolite.com