Blackholing traffic by ASN

Danny McPherson danny at tcb.net
Thu Jan 31 00:17:46 UTC 2008



On Jan 30, 2008, at 4:33 PM, Justin Shore wrote:

>
> I'm sure all of us have parts of the Internet that we block for one  
> reason or another.  I have existing methods for null routing  
> traffic from annoying hosts and subnets on our border routers today  
> (I'm still working on a network blackhole).  However I've never  
> tackled the problem by targeting a bad guy's ASN.  What's the best  
> option for null routing traffic by ASN?  I could always add another  
> deny statement in my inbound eBGP route-maps to match a new as-path  
> ACL for _BAD-ASN_ to keep from accepting their routes to begin  
> with.  Are there any other good tricks that I can employ?
>
> I have another question along those same lines.  Once I do have my  
> blackhole up and running I can easily funnel hosts or subnets into  
> the blackhole.  What about funneling all routes to a particular ASN  
> into the blackhole?  Are there any useful tricks here?

I'd recommend you exercise extreme caution with any such
policy.

Specifically, if the origin[?] AS that you're wanting to drop all
traffic from gets wind of such a policy, they could easily announce
other prefixes that result in your dropping that traffic, introducing
a more effective DoS vector.  Other ASes could easily spoof an
origin AS and trigger such a policy application as well.

You should probably do this explicitly based on prefix and null
route from some centralized route server w/uRPF and not as a
matter of automated policy based on a given AS Path set.

If you're simply worried about destination reachability to prefixes
provided by those ASes in question, then you could employ a
BGP filter on ingress dropping prefixes with those ASes in the path
-- although I think your query was more concerned with ingress
traffic from those ASes, not egressing destined to those networks.

Finally, as Ferg said, networks of that sort seem to find a need to
diversify their connectivity periodically -- all the more reason to
avoid such policies.

-danny



More information about the NANOG mailing list