Ok, let me show why this isn't a valid reason. Me: Will you peer with me on both coasts with this bandwidth using this protocol? BigISP: No, because we don't trust ..... Me: Will you sell me the same, identical connections in multiple locations using the same, identical protocols? BigISP: Of course, yes. Me: If you have systems in place to protect your network against my network as a customer, why don't those exact same systems work when you connect the same network, router and protocol as a peer? BigISP: Its too complicated, and you wouldn't understand. Question: historically have more routing snafus originated in "customer" BGP sessions or in "peer" BGP sessions? On Tue, 14 November 2000, David Diaz wrote:
Sorry, Yes. My original answer mentioned in the past. I think we all understand that the "business" side has entered.
However someone connecting to your peering router can create a create deal of havoc. Some of the older routers could have a major problem with floods of tens of thousands or hundreds of thousands of routes being added or withdrawn quickly. At the same time if the peer is flapping and rerouting hunderds of megs to different exchange points, first east coast then west, it could cause a serious problem. I know you know that Sean.
On Tue, Nov 14, 2000, Sean Donelan wrote:
Question: historically have more routing snafus originated in "customer" BGP sessions or in "peer" BGP sessions?
Question: Historically have more routing snafus originated in filtered BGP sessions or in unfiltered BGP sessions? When I've been involved in network admin, filtering BGP sessions resulted in less headaches than unfiltered BGP sessions (one problem I did have was when I was being lazy with filtering and didn't require exact matches, and a few downstreams decided they wanted to deaggregate aggressively..) "Its too hard" doesn't cut it with me. I guess thats because I'm used to having to write RFC compliant code, and there's no "real" RFC compliance for configuration here.. 2c, Adrian -- Adrian Chadd "God: Damn! I left pot everywhere! <adrian@creative.net.au> Now I'll have to create Republicans!" - Bill Hicks
i think all agree that filtering large/teir 1 peers (let's assume teir 1 is defined as a peer who sends a large number of routes, ie: ignore the business BS) the way customers are/should be filtered (by exact match prefix) is impossible with the hardware (and/or implementations) available today. then, assuming that these teir 1's are filtering their customers by prefix collected from the/a IRR, then most routes are registered and the work necessary by these teir 1s to register and maintain route objects for their aggregates (as-path origin ^$) and an as-set is minimal. i know that not all teir 1s are filtering this way or register their aggregates, but is there really an excuse not to? esp today, when we have merit's IRRd (or BIRD from ISI? and others) at our disposal, such that we can maintain our own IRR and mirror the [RPSL] databases of others _and_ there are at least 2 publically available databases (RADB and ALTDB). ok - sticking my foot in the business BS just for a moment - registration could easily be a peering contract requirement. [here's the beef] it should be possible to have an [daily] automated process (such as we have for building customer prefix filters) which for a set of teir 1 peers, queries the IRR for a peer's as-set reducing it to a number of routes * .NN (where NN is say 10%, or graduated or whatever - allowing for some flux between runs of the collector) and applies this number as the maximum-prefix for that peer. the only drawback i can think of is that if the advertised prefixes from a peer ligitimately exceeds the estimation (eg: add a customer advertising a large number routes) the peering would have to be reset, the peer would have to soft-clear outbound, or see draft-ramachandra-bgp-restart-04. this doesnt protect one from prefix hijacking, but it does reduce the affects of redistribution accidents and the like and is doable. ignoring kinky transit arrangements, it is possible to further restrain by as-path of teir 1 peer X, by not accepting as-path ^(Y|Z)_
First, it is not clear to me whether Juniper can prefix filter on a tier 1. Cisco can prefix filter on SOME NSPs that might be classed as tier 1. ESnet prefix filters on all peers that have fewer than about 10,000 prefixes. As we are moving to Juniper at one peering point, we might try filtering come bigger peers. The Juniper folks say that they are still testing how extremely large policies effect performance. We will see. Note: I am only talking about filtering BGP announcements, not packets! Since Sprint and UUnet don't seem to be willing to provide information in the IRR to allow us to generate access-lists/policies, and not peering with these folks would be a Bad Idea(tm), so we can't quite filter everyone. (If I could figure out a way to get them to register, I'd have fun trying, though.) The only downside to such filtering I have seen is that some folks (including some which use the router servers which mandate registration) are very lax about registration. It also makes for some rather long configuration files. Even with many large peers not being filtered, configurations at major meet points exceed a megabyte. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634
On Wed, Nov 15, 2000 at 12:02:59PM -0800, Kevin Oberman darkened my spool with the following:
First, it is not clear to me whether Juniper can prefix filter on a tier 1. Cisco can prefix filter on SOME NSPs that might be classed as tier 1. ESnet prefix filters on all peers that have fewer than about 10,000 prefixes.
i believe both juniper and cisco could, but i think you;re going to have unpleasantness wrt boot-time config loading, config commit time, size of the canonical config, slow boot-time/unstable-wire policy evaluation. ??? even with prefix filtering; if soft-reconfig is enabled, a peer could still DOS its peering router by consuming all its memory (eg: every /32 of /<some large prefix>).
As we are moving to Juniper at one peering point, we might try filtering come bigger peers. The Juniper folks say that they are still testing how extremely large policies effect performance. We will see.
Note: I am only talking about filtering BGP announcements, not packets!
Since Sprint and UUnet don't seem to be willing to provide information in the IRR to allow us to generate access-lists/policies, and not peering with these folks would be a Bad Idea(tm), so we can't quite filter everyone. (If I could figure out a way to get them to register, I'd have fun trying, though.)
so, the question is how to make registering irresistable? peering contract requirement? peer pressure? :)
The only downside to such filtering I have seen is that some folks (including some which use the router servers which mandate registration) are very lax about registration. It also makes for some rather long configuration files. Even with many large peers not being filtered, configurations at major meet points exceed a megabyte.
i believe this amounts to a fairly easy and doable solution. a 1 line configuration stmt and it can be automated....even some of the object registration could be automated. but, all the teir 1s have to play.
Since Sprint and UUnet don't seem to be willing to provide information in the IRR to allow us to generate access-lists/policies, and not peering with these folks would be a Bad Idea(tm), so we can't quite filter everyone. (If I could figure out a way to get them to register, I'd have fun trying, though.)
so, the question is how to make registering irresistable? peering contract requirement? peer pressure? :)
I would be very interested to hear from anyone who has problems/suggestions/ criticisms/etc... with the current routing registry. In particular, it would be nice to hear from UUnet, Sprint and those people who choose not to register in the IRR. A few years ago the chief complaints were poor data integrity (ie, bogus/old /stale data), authentication/security and under-participation (ie, very few ISP's used the registry). Yes, these are very serious problems. The data integrity problem I am guessing would still be the main drawback people would cite. We/Merit have worked hard over the last several years to address the problems associated with the IRR and continue to do so. We are finally in a position to do something about the data integrity problem and expect to implement RFC2725 (ie, RPS auth) by mid-2001 which should have a significant impact. But things change over time and I would like to hear what people think. Criticisms, suggestions, ...? --jerry winters (Merit)
On Wed, Nov 15, 2000 at 04:25:59PM -0500, gerald@merit.edu darkened my spool with the following:
Since Sprint and UUnet don't seem to be willing to provide information in the IRR to allow us to generate access-lists/policies, and not peering with these folks would be a Bad Idea(tm), so we can't quite filter everyone. (If I could figure out a way to get them to register, I'd have fun trying, though.)
so, the question is how to make registering irresistable? peering contract requirement? peer pressure? :)
I would be very interested to hear from anyone who has problems/suggestions/ criticisms/etc... with the current routing registry. In particular, it would be nice to hear from UUnet, Sprint and those people who choose not to register in the IRR.
A few years ago the chief complaints were poor data integrity (ie, bogus/old /stale data), authentication/security and under-participation (ie, very few ISP's used the registry). Yes, these are very serious problems.
The data integrity problem I am guessing would still be the main drawback people would cite.
We/Merit have worked hard over the last several years to address the problems associated with the IRR and continue to do so. We are finally in a position to do something about the data integrity problem and expect to implement RFC2725 (ie, RPS auth) by mid-2001 which should have a significant impact.
But things change over time and I would like to hear what people think. Criticisms, suggestions, ...?
--jerry winters (Merit)
i would venture to say that laziness would be one reason folks don't register. possibly the primary. havent you heard; diligence is passe. how many have md5 auth on all their [ie]bgp sessions? <my hand is not raised, unfortunately>
At 15:02 15/11/00, Kevin Oberman wrote:
Since Sprint and UUnet don't seem to be willing to provide information in the IRR to allow us to generate access-lists/policies, and not peering with these folks would be a Bad Idea(tm), so we can't quite filter everyone. (If I could figure out a way to get them to register, I'd have fun trying, though.)
Excellent point. The main deployment limitation of any of the schemes proposed for enhanced authentication of prefix advertisements appears to be the unwillingness of certain major ISPs to provide authenticated information about which prefixes that service provider claims to be providing service for. The Routing Registries would be one way to make that data available, however the folks who don't want to participate in the RRs also seem uncomfortable providing the same data via some other method that can be authenticated. Offhand, I don't know which service providers have this reluctance. Its clear that at least some major service providers do have such a reluctance. Until resolved, this will be a significant deployment hindrance for better methods (e.g. S-BGP or the other proposed approaches) of protecting against inaccurate/false/accidental prefix advertisements. Sigh. Ran rja@extremenetworks.com DISCLAIMER: Speaking for myself here, not my employer. Flames to /dev/null please.
At 11:24 AM -0800 11/15/2000, john heasley wrote:
i think all agree that filtering large/teir 1 peers (let's assume teir 1 is defined as a peer who sends a large number of routes, ie: ignore the business BS) the way customers are/should be filtered (by exact match prefix) is impossible with the hardware (and/or implementations) available today.
Are we truly talking about full route filtering alone as adequate at this level, or is there a requirement for reverse path verification on the traffic between large peers? Or can it be assumed that RPF and other traffic filtering is adequately handled at the customer to provider edge?
[here's the beef] it should be possible to have an [daily] automated process (such as we have for building customer prefix filters) which for a set of teir 1 peers, queries the IRR for a peer's as-set reducing it to a number of routes * .NN (where NN is say 10%, or graduated or whatever - allowing for some flux between runs of the collector) and applies this number as the maximum-prefix for that peer.
the only drawback i can think of is that if the advertised prefixes from a peer ligitimately exceeds the estimation (eg: add a customer advertising a large number routes) the peering would have to be reset, the peer would have to soft-clear outbound, or see draft-ramachandra-bgp-restart-04.
Sounds as if there might be a need for an authenticated "RPSL alert" between large providers, signaling that there is a significant increase in the number of expected prefixes. For that matter, unless I've missed it, there's no RPSL construct for maximum prefixes.
this doesnt protect one from prefix hijacking, but it does reduce the affects of redistribution accidents and the like and is doable.
On Mon, Nov 20, 2000 at 01:55:41PM -0500, Howard C. Berkowitz darkened my spool with the following:
At 11:24 AM -0800 11/15/2000, john heasley wrote:
i think all agree that filtering large/teir 1 peers (let's assume teir 1 is defined as a peer who sends a large number of routes, ie: ignore the business BS) the way customers are/should be filtered (by exact match prefix) is impossible with the hardware (and/or implementations) available today.
Are we truly talking about full route filtering alone as adequate at
route filtering (or limiting the number of prefixes) is one possible solution (even if only a temporary stepping-stone) to limit the effects of - oops, isp X just redistributed bgp into rip into bgp - leaking transit AS A's routes to transit AS B (an the like) definitely not a complete solution.
this level, or is there a requirement for reverse path verification on the traffic between large peers? Or can it be assumed that RPF and other traffic filtering is adequately handled at the customer to provider edge?
rpf verification does not solve the above. it is an excellent solution for limiting spoof. yes, folks should be using this when possible.
[here's the beef] it should be possible to have an [daily] automated process (such as we have for building customer prefix filters) which for a set of teir 1 peers, queries the IRR for a peer's as-set reducing it to a number of routes * .NN (where NN is say 10%, or graduated or whatever - allowing for some flux between runs of the collector) and applies this number as the maximum-prefix for that peer.
the only drawback i can think of is that if the advertised prefixes from a peer ligitimately exceeds the estimation (eg: add a customer advertising a large number routes) the peering would have to be reset, the peer would have to soft-clear outbound, or see draft-ramachandra-bgp-restart-04.
Sounds as if there might be a need for an authenticated "RPSL alert" between large providers, signaling that there is a significant increase in the number of expected prefixes. For that matter, unless
or folks can plan ahead to meet the time frame of daily collections. but, if .NN is chosen wisely, the daily average gain can be accounted for. no? can tony's data help derive .NN? http://www.employees.org:80/~tbates/cidr-report.html but, for the most part, unless ISP X sees registration as an advantage to _them_, they're just going to sit on their hands. who is registering? abovenet/mfn? exodus? i know verio does. if i recall correctly, its a requirement for LINX membership, or was that just for autnums.
I've missed it, there's no RPSL construct for maximum prefixes.
i dont believe there is, but the number of registered prefixes can be easily counted. expand their as-set recursively (!ias-foo,1 - i think that's right) and expand each AS to routes (!gasNNNN); count the result.
this doesnt protect one from prefix hijacking, but it does reduce the affects of redistribution accidents and the like and is doable.
participants (7)
-
Adrian Chadd -
gerald＠merit.edu -
Howard C. Berkowitz -
john heasley -
Kevin Oberman -
Ran Atkinson -
Sean Donelan