Re: using IRR tools for BGP route filtering

[Danny McPherson <danny () tcb net>]

> I agree totally with prefix-list filtering customers and we have done so
> from the very beginning.  (Who wants to blemish the reputation of their
> ASN as result of a customer being a bonehead and announcing default, etc?)
> Provider<->Provider prefix-list filtering becomes much more involved
> however.  When a provider has 400+ bilateral peering relationships, the
> time it takes to bring a new customer online who has their own address
> space grows substantially.  It is no different when a provider obtains
> additional address space.  If their peers are prefix-list filtering, they
> have to contact every peer to have them blast a hole in the filters for
> the new address block.

If a provider performed prefix filtering on their peers, the policies would
need to be auto-generated from some database, a la IRR or the like.  This 
used to be a problem not long ago, when things such as sequenced prefix lists
(with incremental update support), and BGP route refresh didn't exist.  Today,
however, they do.  The problem is that the data in the IRRs is stale -- at 
best,
the associated infrastructure isn't necessarily production quality, the routers
can't store the policies, much less perform matches in a reasonable manner, and
they certainly can't perform any type of forwarding plane functions such as SA
verification.

Of course, a bit of latency introduced would perhaps encourage correct 
aggregation
and use of provider-allocated space, which, of course, is yet another rathole 
in
and of itself.

> In a perfect world, we would not need to filter, period.  Filtering
> customers has become necessary to survival.  I see Provider<->Provider
> filtering as a major hurdle to jump anytime your (or anyone elses) network
> expands in relation to prefixes being legitimately announced.

Though I'm certain you'll agree that hurdle isn't nearly as high as the one that 
providers must jump when another provider begins advertsing more-specifics of 
their customers address space.  

For example, I recall a provider announcing a /24 which contained www.cisco.com 
a few months back, and every peer gladly accepted the announcment .. including 
Cisco's service provider!  As you can imagine, this caused a bit of a problem 
for a number of folks.  Fortunately, Cisco doesn't rely wholly on web-generated 
revenue, as some folks do.

The lobbying for this isn't simply because we think it's cool or that it would
be trivial to accomplish .. it's because the lack of inter-provider filtering 
and SA verification mechanisms are by far one of the most vulnerable components
of today's Internet.  

Support for these two components alone would clearly improve the Internet as a
whole, significantly increasing reliability, while decreasing vulnerability to
things such a DoS attacks.

-danny