<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 6/28/2012 5:13 PM, Michael Graff
wrote:<br>
</div>
<blockquote cite="mid:4A62189F-9A60-4FFA-974C-521BBA4A92CF@isc.org"
type="cite"><br>
<div>
<div>On Jun 28, 2012, at 9:06 AM, Vernon Schryver wrote:</div>
<blockquote type="cite">
<div><font class="Apple-style-span" color="#000000"><br>
</font>That conclusion does not hold, because it does not
define the narrow<br>
window alternative. 11 times as wide as what?<br>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>This translates to a "normal" truncated response 50% of the
time, and a timeout the other 50%. 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. 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.</div>
</div>
</blockquote>
<br>
as we discussed 1x1 when you brought this up the first time, longer
request windows are the equivilent of no birthday protection in
terms of their kaminsky danger-factor. at this time the remaining
kaminsky-vulnerable recursives are dominated by "does not do source
port randomization at all" followed by "lives behind a
port-derandomizing NAT". so while i am in favour of birthday
protection, the risk posed by RRL whereby this protection can be
turned off on a query by query basis is among my half dozen top
concerns. (the risks of reflected amplified DDoS would also be
higher, so even if it were a direct tradeoff, the decision would be
obvious to me in favour of RRL.)<br>
<br>
<blockquote cite="mid:4A62189F-9A60-4FFA-974C-521BBA4A92CF@isc.org"
type="cite">
<div>
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
<br>
that's a fair point. the technical note currently has the following
text:<br>
<br>
<pre> 5 - Attacker Behaviour
5.1. A forged-source reflective amplifying attacker who wants to be
successful will either have to select authority servers who do not
practice rate limiting yet, or will have to select a large number of
authority servers and use round robin to distribute the attack flows.
Each authority server will have to be asked a question within one of
that server's zones chosen at random in order to get an amplification
effect. An attacker would do well to select DNSSEC-signed zones and to
use DNSSEC signalling in their forged queries to maximize response size.
This will be more effective than QTYPE ANY queries which are often
blocked altogether due to their diagnostic rather than operational
i will add text to the effect that a kaminsky attacker could use forged-source packet bursts
to quietize a DNS server that uses RRL in order to make their attack against a distant
recursive DNS server more effective.
the math isn't obvious to me, i'm not sure how much easier this makes a kaminsky attack, but
it's a tradeoff that every DNS operator should make explicitly and with complete knowledge.
</pre>
<br>
<blockquote cite="mid:4A62189F-9A60-4FFA-974C-521BBA4A92CF@isc.org"
type="cite">
<div>
<div> 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.<br>
</div>
</div>
</blockquote>
<br>
we are now in the post-apocalyptic road-warrior phase of
non-DNSSEC's history. it's difficult for me to imagine anyone
choosing to remain an attack amplifier when they could instead sign
their zones. but you're entirely right about the tradeoff
transparency; vernon and i do not intend to slip this decision into
an operator's life without their knowledge and consent.<br>
<br>
paul<br>
</body>
</html>