Home page logo
/

nanog logo nanog mailing list archives

Re: using IRR tools for BGP route filtering
From: Danny McPherson <danny () tcb net>
Date: Thu, 22 Jun 2000 14:39:27 -0600



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





  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]