Blackhole Routes
Stephen J. Wilcox
steve at telecomplete.co.uk
Thu Sep 30 19:03:05 UTC 2004
we can handle most DoS's ourselves, this is the case with a lot/most? upstreams,
we dont automatically forward blackholes upstream
the only time anyone would need to do that is if a particular upstream's
connection was saturated with the DoS.
i'd agree automatically propogating these isnt good practice.. (imho)
Steve
On Thu, 30 Sep 2004, Deepak Jain wrote:
>
> > It goes a little further than that these days. Folks are openly
> > allowing customers to advertize routes with something lika a 666
> > community which will then be blackholed within their network. So if
> > you're a service provider with your own blackhole system, you can
> > easily tie it into your upstream's system and dump the traffic many
> > hops away from you meaning that the traffic is getting dumped closer
> > to the source than the destination in a fair number of cases.
> >
>
> This is very dangerous however.....
>
> If providers start tying their customer's blackhole announcements to the
> provider's upstreams' blackhole announcements in an AUTOMATIC process,
> bad things <tm> are likely to happen. What happens when a customer of a
> provider mistakenly advertises more routes than he should [lets say
> specifics in case #1] you can flood your upstreams' routers with
> specifics and potentially cause flapping or memory overflows...
>
> In case #2, presumably the blackhole community takes precedence, so if a
> customer is mistakenly readvertising their multihome provider's table
> with a 666 tag, all of the upstream providers might be blackholing the
> majority of their non-customer routes.
>
> Non-automatic tying of customer blackholes to upstream or peer
> blackholes is a powerful tool to improve the stability of the net as a
> whole.
>
> Deepak Jain
> AiNET
>
More information about the NANOG
mailing list