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