<html><head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000">there's an information
warfare/economics issue at hand here.<br>
<br>
Irwin Tillman wrote:
<blockquote
cite="mid:201301071701.r07H1OOp027872@scramble.Princeton.EDU"
type="cite">
<pre wrap="">From: Vernon Schryver <a class="moz-txt-link-rfc2396E" href="mailto:vjs@rhyolite.com"><vjs@rhyolite.com></a>
</pre>
<blockquote type="cite"><pre wrap="">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?
</pre></blockquote>
<pre wrap=""><!---->
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.</pre>
</blockquote>
<br>
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.<br>
<br>
therefore while it's still painful for the victim it's an unalloyed
improvement over not running DNS RRL at all.<br>
<br>
for this reason i treat it as out of scope, and like diffuse attacks and
distributed algoithms, something we should study in the future.<br>
<br>
paul<br>
</body></html>