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 18:05:48 -0600

This is not our experience, and yes, we filter customers *and* peers.
(We have a few peers we don't filter other than sanity-wise, but this
is a limitation of config file size, not performance. Plus, a couple
of Tier-1 networks don't register or don't publish as-sets.)

Configuration size is certainly one of the issues, yes.  I guess 
some providers are more concerned with BGP convergence than others.
I for one think 4-5 minutes to pickup a full BGP table from a 
single peer when doing nothing else -- and withOut any filter 
lookups, is a bit much.

We have been requiring customers to register, for BGP customers, since
we started offering IP transit, and have built filters for customer from
RADB and other public registries from day one.

Good practice.  Unfortunately, it still doesn't provide safety when one of 
your peers advertises a network that they're not supposed to.

Obviously, when it comes to the data plane, filtering should be done
at the edge, for scaling reasons. 

Though this requires providers to rely on other providers to ensure 
their availability, something many providers would rather not do.

Filtering based on registries is a hack - the real issue of trust, of
originators of routing information, is better managed through an end-to-end,
top-to-bottom, but scalable, delegation and signature method, using such
mechanisms as are under discussion in various IETF wg's on secure BGP.

SBGP.  Ha.  Did you perhaps consider the performance implications
of this?  And the requirement for de-aggregation or hierarchal 
signatures?  And the fact that today it'd take pretty much an 
entire 24-hour period for one router to verify a full Internet 
routing table from a single peer?  And that'll scale?  I'd suggest
we stick to some registry/pre-population of policies mechanisms.

It's interesting that for quite a while nearly 30K PSTN 800 numbers
were allocated nearly every week, with number portability and all.
Perhaps we're simply missing something :-)

There is still the issue of the boot-strap route required for root name
servers... :-)

Among those the requirement for routers to actually have cycles to 
populate forwarding tables and forward packets, something they 
probably wouldn't be doing if they were running SBGP.

In fact, the end result is non-propogation of bogus routing information.
If only a few more big networks would do this, the risk to the net in general
would be substantially reduced.

I'll again site the www.cisco.com incident from a few months back.  
The announcement was originated from a large provider that performs 
prefix-based filtering on all customers.  I can speculate that your 
customers as well were affected by this.


  By Date           By Thread  

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