[ratelimits] can't make qps-scale change effective slip
vjs at rhyolite.com
Mon Jan 7 17:48:07 UTC 2013
> From: Irwin Tillman <irwin at princeton.edu>
> >What do you think qps-scale should do?
> I must admit, I don't know.
What about the ideas of increasing scale by qps or qps*2?
(I fear that they are like most of my great ideas, silly nonsense on
> I've changed slip to 10, so now I'm sending 720 truncated responses per second
> to those victim. It still seems to me like a lot,
To emphasize what Paul Vixie said,
note that the slip responses are the same size as the forged requests.
The attacker is sending 7200 50 or 60 byte packets/second to
trick your DNS server into sending 720 50 or 60 byte packets/second.
That's rather inefficient, especially given the many open recursive
servers that do enthusiastically amplify.
> On the other
> hand, I imagine that with slip 10, I'm already defeating the purpose of slip.
The purpose of slip is to get answers to the DoS victim. I think
that to compute the probability that the victim gets at least one
a response for "isc.org ANY" (or whatever) during an attack, one
should compute the probability that the victim gets no responses.
Assume the victim sends a total 3 UDP requests.
With "slip 10", the probability that any single request from the victim
that is the same as the forged flood and that is not answered is 0.9.
The probability is 0.9*0.9*0.9 or 73% that none of the victim's
identical requests will be answered. That's poor but maybe not fatal.
With "slip 2", the probability of no answer for 3 UDP packets is only 13%.
If the traffic is from an SMTP client (mail sender) or HTTP client
(user with a browser) that has its own tries,
then the probabilities of a failed web page after the first "try again"
click goes down to 53% and 2%. Even 53% is very bad.
Vernon Schryver vjs at rhyolite.com
More information about the ratelimits