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
On Thu, 22 Jun 2000, Danny McPherson wrote:
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
OK, feasble or not to enforce, would it NOT be a good idea to incorporate a "if you announce a network you shouldn't announce we ignore your ASN" policy? At the customer<->provider level, this is more likely since any provider worth their salt should be prefix-list filtering customers. At the Provider<->Provider level, it becomes more political. Noone wants to blackhole a network (or themselfs from a network) because some network engineer mistyped a network statement. On the otherhand, if punative damages, or blackholes to other networks were a definate effect of announcing the wrong prefixes, perhaps some providers (you know who you are!) would recruit NOC/Network Engineer staff at places other than the local Mediaplay and McDonalds. If providers were egress filtering properly, a simple typo in a network statement wouldn't be able to take out someone elses network. It would require the same typo be made on a prefix-list as well. If your network is so %^#&( large that one router can't deal with the prefix-list for all the customers you have, perhaps instead of pushing your stock price or showing $2B in profits, you should consider upgrading the edges. It appears to me, from recent events, that it has been that large providers %^#ing up and allowing announcements through. People, announcements from ASN's behind yours are as much your responsibility as those that bear only your ASN. If your BGP speaking customers keep %^&*ing up, filter their announcements and LOG the exceptions. Contact them and find out WHY they tried to announce 0/0 or whatever bonehead prefix bounced off their filters. If they can't figure it out, you have four options: 1) Static route into them. 2) Demand exclusive enable access to their router(s) 3) Hope they subscribe to the clue-of-the-month club 4) Prepare to be embarrassed/sued when your customer announces the most specific for a site that stands to lose $10,000's per hour. While I'm ranting, customers, if you give up exclusive enable access, keep tabs on what your provider is doing. I know of one instance where a provider charges a customer for bridging two sides of said providers network. Provider-East-Coast-Border<-->Provider-Core<-->Provider-West-Coast-Border ^ ^ |-Customer DS3--| |-Customer DS3--| |- Cust rtr -| It seems that in the case described, provider core lost connectivity to one of the coasts. Since provider had exclusive enable access to the customers router, they had set up on their OSPF backbone as an "oh shit" route. When the provider core lost connectivity to one coast from the other, they routed east coast to west coast, THROUGH the customer, charging them for both inbound down one DS3 and outbound down the other. The moral of this story is: Allow your provider to prefix-list/AS-PATH filter you. Don't give them exclusive enable access on your router. ESPECIALLY when you have more connectivity into them than they have to the rest of the world. The other moral of this story is: If you catch your provider doing this, GET ANOTHER PROVIDER!!! The provider in question knows who they are and knows they were caught. (At least now they do) I'm not sure what was more embarrassing for them; Being caught or having to do it in the first place. --- John Fraizer EnterZone, Inc
participants (2)
-
Danny McPherson -
John Fraizer