[ratelimits] can't make qps-scale change effective slip
paul at redbarn.org
Mon Jan 7 17:12:26 UTC 2013
there's an information warfare/economics issue at hand here.
Irwin Tillman wrote:
> From: Vernon Schryver <vjs at rhyolite.com>
>> Perhaps it would make more sense and you wanted the slip rate to
>> increase by the ratio, perhaps changing to (1/(60/7200))*2=240.964.
>> That would result in 240 dropped responses, 1 truncated response, 240
>> dropped, 1 truncated response, and so on.
>> Simultaneously increasing slip and decreasing responses-second by
>> the ratio would result in the about the same number of output
>> packets/second during the attack. Perhaps slip should be increased
>> by the square of the ratio. I don't know.
>> What do you think qps-scale should do?
> I must admit, I don't know.
> I'm unsure of what result I should be aiming for.
> Looking at my 7200 queries/second "foo ANY?" attack,
> I was happy with the result from 'responses-per-second 10',
> but felt umcomfortable sending 3600 truncated responses per second
> (using default 'slip 2') to the victim.
> Of course, it was a lot better than sending 7200 full-size responses/second
> to the victim, but I suspect I was still saturating some victims.
importantly, you acted as an attenuator not an amplifier. the attacker
would gain more by spoofing your address on large responses to the
victim, then by spoofing the victim's source address on queries sent to you.
therefore while it's still painful for the victim it's an unalloyed
improvement over not running DNS RRL at all.
for this reason i treat it as out of scope, and like diffuse attacks and
distributed algoithms, something we should study in the future.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ratelimits