|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: using IRR tools for BGP route filtering
> 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
|