Global Blackhole Service
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.
More information about the NANOG