<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>