[dns-operations] if you're banning ANY queries, don't forget to ban SOA as well

[Doug Barton]

Damian,

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.

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.

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.

On 9/5/2016 7:47 AM, Damian Menscher wrote:

> 1) Bypassing ANY is trivial for the attacker, as they can switch to TXT
> or any other record.

I think you're making the same point that Paul did in his OP. :)

> Enabling RRL doesn't fix this because...
> 2) Amplifying off recursive servers rather than authoritative servers
> bypasses RRL.

True, but the fewer authorities that don't run RRL, the better. We want 
to plug as many holes as we can.

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.

Also, you can enable RRL for a recursive server. :) (But see below)

> This is a trivial change for the attacker.  Shutting down
> open recursives isn't economically viable because...
> 3) The Open Resolver Project sees well over 10M open recursives.  An
> attacker needs ~10k to launch a successful attack.  So we need to shut
> down 99.9% before they even need to change a line of code.

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.

But I'm not sure throwing our hands in the air is the right answer here. 
In any case ...

> But even
> then, we've achieved nothing because...
> 4) DNS amplification is actually old-school --- the new hotness is
> amplifying off NTP or SSDP.  There are several other protocols as well
> (and it's likely new ones will continue to be created).

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?

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.

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

> My proposal passes the math/economics sniff test:
>
> There are ~500 ASNs that fail to filter spoofed traffic to the internet
> (due to lack of BCP38 compliance).  Most spoofed attacks originate from
> only a dozen of them.  If we get those cleaned, the attackers need to
> expend effort to find a new network to spoof from.  This is a bit harder
> than changing a script, and gets increasingly difficult for them as we
> clean up the abusive networks.  If we got transit providers on board
> with caring about the health of the internet rather than the number of
> octets they carried, they could probably end this discussion in a matter
> of weeks.

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:

1. Victims of DDOS attacks need to sue the networks that the packets 
came from.
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.

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.

Doug