I agree totally with prefix-list filtering customers and we have done so from the very beginning. (Who wants to blemish the reputation of their ASN as result of a customer being a bonehead and announcing default, etc?) Provider<->Provider prefix-list filtering becomes much more involved however. When a provider has 400+ bilateral peering relationships, the time it takes to bring a new customer online who has their own address space grows substantially. It is no different when a provider obtains additional address space. If their peers are prefix-list filtering, they have to contact every peer to have them blast a hole in the filters for the new address block.
If a provider performed prefix filtering on their peers, the policies would need to be auto-generated from some database, a la IRR or the like. This used to be a problem not long ago, when things such as sequenced prefix lists (with incremental update support), and BGP route refresh didn't exist. Today, however, they do. The problem is that the data in the IRRs is stale -- at best, the associated infrastructure isn't necessarily production quality, the routers can't store the policies, much less perform matches in a reasonable manner, and they certainly can't perform any type of forwarding plane functions such as SA verification. Of course, a bit of latency introduced would perhaps encourage correct aggregation and use of provider-allocated space, which, of course, is yet another rathole in and of itself.
In a perfect world, we would not need to filter, period. Filtering customers has become necessary to survival. I see Provider<->Provider filtering as a major hurdle to jump anytime your (or anyone elses) network expands in relation to prefixes being legitimately announced.
Though I'm certain you'll agree that hurdle isn't nearly as high as the one that providers must jump when another provider begins advertsing more-specifics of their customers address space. For example, I recall a provider announcing a /24 which contained www.cisco.com a few months back, and every peer gladly accepted the announcment .. including Cisco's service provider! As you can imagine, this caused a bit of a problem for a number of folks. Fortunately, Cisco doesn't rely wholly on web-generated revenue, as some folks do. The lobbying for this isn't simply because we think it's cool or that it would be trivial to accomplish .. it's because the lack of inter-provider filtering and SA verification mechanisms are by far one of the most vulnerable components of today's Internet. Support for these two components alone would clearly improve the Internet as a whole, significantly increasing reliability, while decreasing vulnerability to things such a DoS attacks. -danny
On Thu, Jun 22, 2000 at 02:39:27PM -0600, Danny McPherson wrote:
If a provider performed prefix filtering on their peers, the policies would need to be auto-generated from some database, a la IRR or the like. This used to be a problem not long ago, when things such as sequenced prefix lists (with incremental update support), and BGP route refresh didn't exist. Today, however, they do. The problem is that the data in the IRRs is stale -- at best,
Perhaps this should serve as a small head's up. One side effect of the RADB maintainer object fee is that stale objects from unowned maintainers will be purged from the RADB. This will probably happen Real Soon Now. One planned use of the planned Route Server extensions (RSng++) is to allow real-time correlation of routing data against the totality of the IRR. This will likely result in a publicly accessible database of what the Route Servers have seen in the global routing mesh. For completeness, such a database may also include views from other routers. One possible use for such a database is an report similar to the CIDR report showing non-registered routes. A development schedule for the new features has not been set yet.
the associated infrastructure isn't necessarily production quality, the routers can't store the policies, much less perform matches in a reasonable manner,
If the routers aren't able to handle this then people should start putting pressures on their router vendors. I would be curious if the various router vendors have benchmarked their route filtering mechanisms and published it anywhere. As a data point, most of the existing route servers at the RSng maintained exchange points are Sun Ultra-1 hosts (some are Alphas) with up to 512M of memory (the MAE's) and as little as 256M in other locations. The amount of memory required is (roughly) proportional to the number of routes received and the number of views the route servers has. A "normal" router wouldn't require nearly this amount of memory since normal routers do not maintain the idea of a "view" - just a pool of routes and policy filters for incoming and outgoing policy. Additionally, current RS prefix filters waste space since RSd requires duplicate ACLs in a given policy filter, even if they are identical in several places within the file. (Scheduled to be fixed.) The mae-east route server has 60 views, and receives an average of 70K routes from about the same number of peers. Mae-West has 56 views and about 57K routes. At these loads the RS's still has memory to spare. With the current inefficiencies in RSd it is still able to converge over 60 views in less than 2 minutes. Much of the time it takes for things to converge is due to the fact that when a peer is dropped it takes a while for it decide to come back. (The route server reconfig process is another thing that needs work - both in re-processing the prefix filters, and also BGP soft reconfigs.) My point is that although the route servers can be considered to be underloaded by the number of routes available from the number of peers we have (i.e. we're not receiving a full Internet view from each peer), convergence time is still good on an Ultra 1. And I'm pretty sure that I'm running more prefix filters than almost anyone else on this list. (45M for Mae-East.) Most people's prefix filters are targeted towards "Here is the routes I expect you to send me and here are the routes I want to send you." This protects one's network and one's downstream customers. However, such filters can be HUGE and contain many duplicate prefixes. In a perfect world where the IRR was sufficiently populated, one should need one prefix filter to protect against blackholing: "Are these people allowed to originate this block? Are these people allowed to originate this aggregate?" The IRR (as viewed from the RADB host) currently contains 153K route objects - including all stale data. Simply filtering on origin AS and prefix (or aggregator AS and aggregate prefix) provides a large chunk of the safety-net filtering that people are looking for. It doesn't prevent sub-optimal routing, but it helps prevent people from injecting stupid things into the mesh. Unfortunately, most policy filtering mechanisms aren't optimized to this simplified case. Perhaps it needs to be worked on.
-danny
-- Jeffrey Haas - Merit RSng project - jeffhaas@merit.edu
On 23 Jun 00, at 10:37, Jeff Haas wrote: <entire paragraphs deleted for brevity>
One planned use of the planned Route Server extensions (RSng++) is to allow real-time correlation of routing data against the totality of the IRR. This will likely result in a publicly accessible database of what the Route Servers have seen in the global routing mesh. For completeness, such a database may also include views from other routers. One possible use for such a database is an report similar to the CIDR report showing non-registered routes.
Are there any plans to correlate route registry objects against address registry databases? I believe that one of the roots of this thread is the need to validate the legitimacy of not only routes, but registered route objects. Although it is too much to expect that route objects will match up cleanly with address block assignments at the outset, performing such a correlation would at least identify the scope of the problem. -- Mark Borchers Splitrock Services Network Engineering 9012 New Trails Dr. (281) 465-1200 The Woodlands, TX 77381 mborchers@splitrock.net http://www.splitrock.net/
On Fri, Jun 23, 2000 at 12:56:32PM -0500, Mark Borchers wrote:
Are there any plans to correlate route registry objects against address registry databases?
Yes. RFC 2725 - Routing Policy System Security. This will provide an authorization mechanism for delegation of objects. This includes provisions for "unauhorized" (private) data in the IRR - its simply tagged differently.
I believe that one of the roots of this thread is the need to validate the legitimacy of not only routes, but registered route objects.
Oh believe me, we know. :-)
Although it is too much to expect that route objects will match up cleanly with address block assignments at the outset, performing such a correlation would at least identify the scope of the problem.
I've had some initial conversations with ARIN on getting SWIP information published in RPSL format (as inet-num objects) minus the contact information. Now if someone has an idea for how to represent allocation lengths for the IP registries in an inet-num object, I think we can make a lot of people happy. We will also be talking to RIPE and APNIC about this as work progresses.
Mark Borchers Splitrock Services
-- Jeffrey Haas - Merit RSng project - jeffhaas@merit.edu
Are there any plans to correlate route registry objects against address registry databases? I believe that one of the roots of this thread is the need to validate the legitimacy of not only routes, but registered route objects. Although it is too much to expect that route objects will match up cleanly with address block assignments at the outset, performing such a correlation would at least identify the scope of the problem. It's not all that simple to do, although certainly some of the trash could be deleted, since it's not always the organisation "owning" the address space that announces it. Some process that compares the IR registry view to the current routing table view might be "better" but who would take on that task and under what mandate as its one thing to find the problems but it's an entirely different problem to actually fix it? Mark.
I plan to write a WHOIS client for the RA in Perl as part of Net::Whois. I also plan to have a program that will walk the RA for a given AS (which is why I need the whois client). Eventually I also plan to add ARIN support to Net::Whois I'd like to see a DNS walk to compare the registry to what's out there. Not to mention finding all the bogus records that do things like list ENGLAND as a country code (instead of UK). ----- Original Message ----- From: "Mark Prior" <mrp@connect.com.au> To: "Mark Borchers" <markb@infi.net> Cc: <nanog@merit.edu> Sent: Sunday, June 25, 2000 3:05 AM Subject: Re: using IRR tools for BGP route filtering
Are there any plans to correlate route registry objects against address registry databases?
I believe that one of the roots of this thread is the need to validate the legitimacy of not only routes, but registered route objects. Although it is too much to expect that route objects will match up cleanly with address block assignments at the outset, performing such a correlation would at least identify the scope of the problem.
It's not all that simple to do, although certainly some of the trash could be deleted, since it's not always the organisation "owning" the address space that announces it. Some process that compares the IR registry view to the current routing table view might be "better" but who would take on that task and under what mandate as its one thing to find the problems but it's an entirely different problem to actually fix it?
Mark.
On Sun, Jun 25, 2000 at 04:35:15PM +0930, Mark Prior wrote: [snip]
It's not all that simple to do, although certainly some of the trash could be deleted, since it's not always the organisation "owning" the address space that announces it. Some process that compares the IR registry view to the current routing table view might be "better" but who would take on that task and under what mandate as its one thing to find the problems but it's an entirely different problem to actually fix it?
Monitoring BGP table-vs-IRR is no big deal; IPMA has been giving a view into that for a long time. Giving anyone a good reason to fix their errors is another issue entirely. Most of the players who care about routing registries do so because they, their peers or upstreams use them. The incentive for those who don't care/use them to start caring/using them is what is lacking. Both the push to self-maintained registries [eliminating the 'not maintained here' paranoia] and the address-registry tie-in are good moves to make RRs more of a standard-and-accepted thing with which even curmudgeonly-types would have trouble arguing. Cheers, Joe -- Joe Provo Voice 508.486.7471 Director, Internet Planning & Design Fax 508.229.2375 Network Deployment & Management, RCN <joe.provo@rcn.com>
participants (6)
-
Dana Hudes -
Danny McPherson -
Jeff Haas -
Joe Provo - Network Architect -
Mark Borchers -
Mark Prior