Joe wrote:

...

Haesu wrote: 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