Re: using IRR tools for BGP route filtering

[Danny McPherson <danny () tcb net>]

> 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.

-danny