mailing list archives
Re: Lazy Engineers and Viable Excuses
From: "Brian Dickson" <briand () cineclix com>
Date: Mon, 25 Aug 2003 19:22:44 -0700
You ARE correct. If everyone employs IRR and put explicit filters everywhere,
it'd be the perfect world..
... if everybody used the IRR to build explicit filters everywhere, if everybody kept their objects in the IRR
up-to-date, and if there was some appropriate authorisation scheme in place to allow you to trust the data in the IRR
implicitly, it'd be a perfect world.
There is this widely percieved notion that the IRR is a single, unadministered database.
This is incorrect. The "Source:" field tells the whole story - there are multiple databases, with varying degrees of
trust-worthiness, varying content, and varying uses.
The IRR is currently a reasonable tool to use to avoid listening to routes which are advertised by mistake from peers
who populate the IRR accurately. It's not a reasonable tool for avoiding maliciously bogus routes, since sticking
maliciously bogus information in the IRR is trivial.
The IRR is the correct tool; what is missing is a little application of the available capabilities of the tool.
Here's an example:
You have a lot of address space to manage. Some BGP customers, some not. Some worthy of trust, some not.
So, you operate your *own* routing registry, and tell the world about it. But, you, and only you, have update access.
You mirror the routing registries of only the customers you trust.
Your peers operate likewise. Your filter-building accesses the rr's of your peers, either directly, or via
a reasonably well-located and well-trusted mirror. Or better yet, you mirror (possibly privately) them, yourself.
Any problems with the content of any RR, you know who to contact (and blame). You also now have a mechanism to persuade
your peers with, which is the peering agreement you both signed. Update it to include this, if you need to.
No cruft, secure enough, no bogons, scalable. Technology that is already well understood, and for which tools have been
built. Clear chain of trust, and straightforward means to sever problem servers.
I don't see where (other than perhaps attitudes and erroneous assumptions) the problem is.
And running a route-registry is *really* no more difficult than querying one, in most cases less so.
Certainly less effort than even a small name server serving authoritative data...
Brian Dickson Email: briand () cineclix com
http://www.cineclix.com Tel : +1 604 688 2339
- Re: Lazy Engineers and Viable Excuses Brian Dickson (Aug 26)