<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 5, 2016 at 11:21 AM, Doug Barton <span dir="ltr"><<a href="mailto:dougb@dougbarton.us" target="_blank">dougb@dougbarton.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
You're making the same mistake that a lot of people who are interested in fighting spam do. You're dismissing individual components of a larger solution because individually they don't solve the whole problem.<br></blockquote><div><br></div><div>I'm not making any mistakes. :-)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You're also making a more subtle error in reasoning. You're modeling a specific (relatively sophisticated) type of attacker, and creating a plan to defeat *that* attacker. The problem is that DDOS instigators come in all shapes and sizes, and many of them are not very smart. They are simply using a prefab script, perhaps with one or two edits of their own, and they will keep using it till it stops working.<br>
<br>
Of course there are sophisticated actors out there, but that doesn't mean we should not plug all the holes we can, especially when the solutions are simple and thorough.</blockquote><div><br></div><div>I was responding to Vixie's admonition to look at the problem from an economic standpoint and not waste our time doing things that strain the industry but have no impact in solving the problem.  I gave clear arguments that disabling ANY, deploying RRL, and cleaning up open recursives all fall into that category.  They all help, but fail Vixie's test of being worthwhile to focus efforts on.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On 9/5/2016 7:47 AM, Damian Menscher wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
1) Bypassing ANY is trivial for the attacker, as they can switch to TXT<br>
or any other record.<br>
</blockquote>
<br></span>
I think you're making the same point that Paul did in his OP. :)</blockquote><div><br></div><div>Yes, but he then went on to recommend (2), which I showed to be just as "silly" (his words) on the very next line:</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Enabling RRL doesn't fix this because...<br>
2) Amplifying off recursive servers rather than authoritative servers<br>
bypasses RRL.<br>
</blockquote>
<br></span>
True, but the fewer authorities that don't run RRL, the better. We want to plug as many holes as we can.<br></blockquote><div><br></div><div>Again, read Vixie's economic argument: don't waste time doing things that don't help.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, RRL has benefits to the server operator as well. In the event someone does try to use them, their own bandwidth costs don't shoot through the roof. So good net.citizenship + reduced bandwidth costs. That's a win/win.<br>
<br>
Also, you can enable RRL for a recursive server. :) (But see below)<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This is a trivial change for the attacker.  Shutting down<br>
open recursives isn't economically viable because...<br>
3) The Open Resolver Project sees well over 10M open recursives.  An<br>
attacker needs ~10k to launch a successful attack.  So we need to shut<br>
down 99.9% before they even need to change a line of code.<br>
</blockquote>
<br></span>
Yes, you have correctly identified a problem here. So good education for those operators will help, but not eliminate it. Also, the same operators who want to run open (or are doing so accidentally) are the same who are not likely to know how to enable RRL.<br>
<br>
But I'm not sure throwing our hands in the air is the right answer here. In any case ...<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But even<br>
then, we've achieved nothing because...<br>
4) DNS amplification is actually old-school --- the new hotness is<br>
amplifying off NTP or SSDP.  There are several other protocols as well<br>
(and it's likely new ones will continue to be created).<br>
</blockquote>
<br></span>
You're wrong on two counts here. First, why did they move off of DNS? It wouldn't have anything to do with the fact that we're closing off attack vectors, would it?<br></blockquote><div><br></div><div>No, I don't think it does.  I think they moved to NTP because the amplification factor is *significantly* higher than for DNS.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Second, you're wrong that DNS DDOS is not happening. Sure the other vectors are becoming more popular, but since DNS still works, it's still used. And NTP has reduced quite a bit because fixing the holes there were fairly simple to do.<br></blockquote><div><br></div><div>I don't think NTP is reduced because the holes were fixed, but rather because several ISPs started aggressively rate-limiting 123/udp.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The whole thing is an arms race. We can't say, "Well none of the really COOL attackers are using this vector, so I won't bother myself with it."</blockquote><div><br></div><div>But attacker coolness matters!  I'm not going to waste my time chasing attackers that get 10x amplification when there are attackers getting 100x amplification.  Yes, 10x (or even 1x) will succeed against home users and small businesses, but 100x becomes a threat to infrastructure.</div><div><br></div><div>But as you say, attackers will do the simple thing till it stops working.  RRL will, at best, cause them to switch to a different script, costing them minutes(!) of work.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My proposal passes the math/economics sniff test:<br>
<br>
There are ~500 ASNs that fail to filter spoofed traffic to the internet<br>
(due to lack of BCP38 compliance).  Most spoofed attacks originate from<br>
only a dozen of them.  If we get those cleaned, the attackers need to<br>
expend effort to find a new network to spoof from.  This is a bit harder<br>
than changing a script, and gets increasingly difficult for them as we<br>
clean up the abusive networks.  If we got transit providers on board<br>
with caring about the health of the internet rather than the number of<br>
octets they carried, they could probably end this discussion in a matter<br>
of weeks.<br>
</blockquote>
<br></span>
Your argument here is 100% accurate, except for the fact that it totally doesn't work. How do I know? Because it hasn't worked for the last 20+ years that it's been tried. There is no way these networks will change anything until they have an economic incentive to do so. I have been saying for a long time now that two things need to happen:<br>
<br>
1. Victims of DDOS attacks need to sue the networks that the packets came from.<br>
2. Large content providers (like Google *cough*) need to tell these network operators that they will not accept any packets from them until they implement BCP 38.<br>
<br>
The combination of those two actions really would solve the problem practically overnight. But we have to decide that the pain of implementing them is more attractive than the pain we're living with now, and humans hardly ever do that.</blockquote><div><br></div><div>I'm working to change that (starting by identifying the problematic ASNs and educating them).  But feel free to advocate for piecemeal solutions (everyone needs a hobby).</div><div><br></div><div>Damian</div></div></div></div>