<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 06/13/2013 05:33 AM, Phil Mayers
      wrote:<br>
    </div>
    <blockquote cite="mid:51B991F7.9070706@imperial.ac.uk" type="cite">On
      06/13/2013 06:31 AM, Ronald F. Guilmette wrote:
      <br>
      <br>
      <blockquote type="cite">1)  If everyone on the planet were to
        somehow magically and immediately be
        <br>
        converted over to DNSSEC tomorrow, then would DNS amplification
        attacks
        <br>
        become a thing of the past, starting tomorrow?  Does DNSSEC
        "solve" the
        <br>
        DNS amplification attack problem?  Or does it have no direct
        bearing on
        <br>
      </blockquote>
      <br>
      No, quite the opposite in fact. By increasing the size of
      responses, DNSSEC arguably makes the amplification problem
      (slightly) worse.
      <br>
    </blockquote>
    <br>
    "slightly" is generous.  I would say "dramatically".<br>
    <br>
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    $ dig mx isc.org @ord.sns-pb.isc.org +noall +stats +nodnssec<br>
    <br>
    ; <<>> DiG 9.9.2-P1 <<>> mx isc.org
    @ord.sns-pb.isc.org +noall +stats +nodnssec<br>
    ;; global options: +cmd<br>
    ;; Query time: 223 msec<br>
    ;; SERVER: 199.6.0.30#53(199.6.0.30)<br>
    ;; WHEN: Thu Jun 13 11:28:49 2013<br>
    ;; MSG SIZE  rcvd: 403<br>
    <br>
    <br>
    $ dig mx isc.org @ord.sns-pb.isc.org +noall +stats +dnssec<br>
    <br>
    ; <<>> DiG 9.9.2-P1 <<>> mx isc.org
    @ord.sns-pb.isc.org +noall +stats +dnssec<br>
    ;; global options: +cmd<br>
    ;; Query time: 242 msec<br>
    ;; SERVER: 199.6.0.30#53(199.6.0.30)<br>
    ;; WHEN: Thu Jun 13 11:28:54 2013<br>
    ;; MSG SIZE  rcvd: 2427<br>
    <br>
    <br>
    DNS reflection attacks are all about amplification (a small request
    resulting in a response larger than the request).  A 6 times greater
    response size is a large jump in amplification.<br>
    <br>
    <blockquote cite="mid:51B991F7.9070706@imperial.ac.uk" type="cite">
      <br>
      DNSSEC is a good thing and necessary for other reasons, but it
      does not help amplification attacks.
      <br>
    </blockquote>
    <br>
    +1<br>
    <br>
    <blockquote cite="mid:51B991F7.9070706@imperial.ac.uk" type="cite">
      <br>
      <blockquote type="cite">2)  Has anyone ever proposed adding to the
        DNS protocol something vaguely
        <br>
        reminicent of the old ICMP Source Quench?  If so, what became of
        that
        <br>
        proposal?
        <br>
      </blockquote>
      <br>
      <snip>
      <br>
      <br>
      <blockquote type="cite">Basically, the whole idea is just simply
        to allow a victim to switch to
        <br>
        "safe TCP only mode" with all of the intermediaries that are
        participating
        <br>
      </blockquote>
      <br>
      The problem with that idea is that it needs software updates on
      both the reflecting DNS server and the victim. It also seems to
      require keeping a lot of soft state in the endpoints.
      <br>
    </blockquote>
    <br>
    This would require both software updates and an update to the DNS
    protocol.<br>
    <br>
    This idea does require state at the endpoints.  We seem to have
    already lost that battle - example RRL.  Would this require more
    state at the endpoints than RRL?  I think that this probably would
    require more state.<br>
    <br>
    One concern I have is that it turns the problem on its head and now
    the network that is the target of the attack is required to get
    packets out through their loaded equipment to stop the attack.<br>
    <br>
    This could lead to wrong headed statements like, "Yes, we sent X GB
    of traffic at your network.  You didn't implement DNS source
    quench?  You should have."<br>
    <br>
    The chain of responsibility for these attacks is:<br>
    1. The person(s) originating the spoofed traffic.<br>
    2. The network(s) allowing the origination of spoofed traffic.<br>
    3. The network(s) transmitting the spoofed traffic.<br>
    4. The operators of nodes amplifying the traffic towards the victim.<br>
    5. The victim.<br>
    <br>
    A system that requires the victim to take action to stop attacks
    might be misconstrued by some to be abdicating the responsibility of
    the upper four levels.<br>
    <br>
    <blockquote cite="mid:51B991F7.9070706@imperial.ac.uk" type="cite">
      <br>
      Altogether, it seems easier for everyone to just apply RRL
      patches, do BCP38 and de-peer with people who don't do BCP38.
      <br>
    </blockquote>
    <br>
    Agreed.  Close all open resolvers as well.<br>
    <br>
    Using this strategy, however, you will have to do an awful lot of
    de-peering.<br>
    <br>
    <pre class="moz-signature" cols="72">-DMM

</pre>
  </body>
</html>