Global Blackhole Service

Jack Bates jbates at brightok.net
Fri Feb 13 10:41:12 CST 2009


Valdis.Kletnieks at vt.edu wrote:
> How do you vet proposed new entries to make sure that some miscreant doesn't
> DoS a legitimate site by claiming it is in need of black-holing?  Note that
> it's a different problem space than a bogon BGP feed or a spam-source BGP
> feed - if the Cymru guys take another 6 hours to do a proper paperwork and
> background check to verify a bogon, or if Paul and company take another day
> to verify something really *is* a cesspit of spam sources, it doesn't break the
> basic concept or usability of the feed.
> 
Presumably, the route server would have to have the same guidelines as 
issued by service providers. ie, /32 networks injected should come from 
authenticated feeds and fall within the netblock range owned by the 
injector. So one extra set of ACL's for each injector to upkeep. I 
believe what is being suggested is just one step beyond what many 
providers give to BGP customers to extend blackholes out.

> Oh, and cleaning up an entry in a timely fashion is also important, otherwise
> an attacker can launch a DDoS, get the target into the feed, and walk away...

This also would be decided by the injecting provider. More of a "Hey, 
one of my IPs is being DDOS'd, please drop traffic to it to protect the 
rest of my network." The downside to widespread use, is that it makes 
tracking the problem on the other side of the blocks near impossible. In 
all cases, once a blackhole is initiated anywhere, the DDOS has been 
successful. We use automatic community changes to accept /32 blackholes 
from customers, verify them, then send them on to peers that also 
support /32 blackholes with appropriate communities.


Jack


Jack




More information about the NANOG mailing list