North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Blackholing traffic by ASN

  • From: Danny McPherson
  • Date: Wed Jan 30 19:24:06 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