[dns-operations] Storm on the DNS

Paul Vixie paul at redbarn.org
Tue Dec 8 16:33:40 UTC 2015


On Sunday, December 06, 2015 05:06:02 PM Olafur Gudmundsson wrote:
> > On Dec 1, 2015, at 10:34 AM, Bill Woodcock <woody at pch.net> wrote:
> > Yes, what he said.  Also, remember also that the attacks don’t come out of
> > thin air…  They are, by and large, spoofed UDP, coming from
> > non-BCP-38-compliant networks.

yea, verily.

> > The finer the anycast granularity, the
> > more the pain is constrained to the networks from which the attack
> > traffic originates.

that's the reason f-root is in 50 or so locations, and mostly at internet exchanges. however, 
the size of the insecure edge seems to have outgrown any sensible anycast plan -- i'm 
guessing it would take 5,000 or 50,000 anycast nodes, not 50, to effectively localize the pain 
of spoofed-source attacks today.

by implication, and by experience, the spoofed-source attack problem has grown 
proportionally as the internet itself has grown. perhaps even disproportionally, but we still 
lack a generalized measurement regime for it. (MIT spoofer doesn't count as "generalized", 
since its measurements are by self-selected endpoints.)

> > Simply spending more money to make it
> > less painful for people to ignore BCP-38 isn’t really a scalable plan.
> 
> I agree 100% with Bill, there is no reason to try to improve the service
> level of root servers close to bad Network operators,

if only we could tell where the bad neighborhoods were, externally. but the implication here 
is wrong-- spending money to put traffic sinks close to bad neighborhoods is worthwhile 
since it causes that traffic to localize, sparing more distant parts of the internet from the 
impact of those attacks.

> We need a
> comprehensive map of network links that regularly allow spoofed traffic.

yes. also, we need a pony. neither can be produced without cooperation from the operators 
of networks who enable ddos by not doing SAV by default for all new customers, and only 
mitigating that constraint for customers who need it.

in other words, the only people who can measure SAV compliance are the operators and 
customers of networks who do not have SAV compliance. and in general, not caring about 
one means you don't care about the other, either.

> Right now the economics of defending DDoS attacks are all wrong, service
> providers need to spend lots of money and effort to increase capacity but
> attackers gain resources for free. We need to increase the pain for people
> using providers that ignore BCP-38 filtering, then customers can vote with
> their feet.

have you read <http://www.darkreading.com/perimeter/ddos-and-the-internets-liability-problem/a/d-id/1323197>, and would cloudflare sign a petition to support the stated goals 
of that article?

> In the spam days cutting peering with providers of spam hosting
> was quite effective, who will be first to cut peering arrangements to a
> non-BCP-38 provider?

in the spam days, open smtp relays and spammy smtp clients could be identified by their IP 
addresses, which made blocking them technically possible. however, having been on the 
phone to hundreds of operators who were being blocked, either at my ISP (AboveNet) or by 
my network reputation service (MAPS), i know that a lawsuit is as likely as cooperation. 
spamhaus does it better today, and is making a giant difference -- but the problem persists, 
and operators who hear that they must block outbound TCP/25 from their dsl/cable 
networks, still generally insist that they are not the network's police force, and threaten to 
sue, or do nothing.

in other words, the culture of "it's not my problem" remains pervasive, for all forms of abuse, 
regardless of protocol or role. thus, the proposal given above as a darkreading.com link.

-- 
P Vixie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20151208/fea30fa6/attachment-0001.html>


More information about the dns-operations mailing list