nanog mailing list archives
Re: Lazy Engineers and Viable Excuses
From: Jared Mauch <jared () puck Nether net>
Date: Mon, 25 Aug 2003 21:32:12 -0400
On Mon, Aug 25, 2003 at 07:41:34PM -0400, Joe Abley wrote:
On Monday, 25 August 2003, at 19:08PM, 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. 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.
Joe, You of course are correct with the trusting of the data, but we are in a somewhat of a chicken and egg situation. If people don't trust the IRR, they don't filter on it, and then the data is allowed to get out of date. But people who maliciously add bogus (or excessive route objects for example) are easy to track down. This is what the maintainer objects are for and why the IRR software keeps logs of the messages (including headers) that are submitted. I think the key here is that filtering is a good thing(tm). People who are not using it as their baseline (with their own custom additions for their own AS based policy decisions of course) are asking for trouble. Hardly a month (or even a week) goes by where I don't see that one of our peers has attempted to leak the routing table to us. max-prefix and peer filtering help mitigate the risks to our network. If you don't trust other IRRs, run your own where you do have a stricter trust model via pgp/gpg. these are both tools that can be used in conjunction with each other and should be. Effort put into the automation of these will pay for itself. Customers will be able to update route objects via the web or via email. Reduced support costs in handling and authenticating requests manually, as well as the ability to audit these either realtime or in a delayed fashion. - Jared -- Jared Mauch | pgp key available via finger from jared () puck nether net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Current thread:
- Re: bgp route-map, (continued)
- Re: bgp route-map Matt Levine (Aug 25)
- Re: bgp route-map Haesu (Aug 25)
- Re: bgp route-map E.B. Dreger (Aug 25)
- Re: bgp route-map Cliff Albert (Aug 25)
- Route Programming (was Re: bgp route-map) Leo Bicknell (Aug 25)
- Re: Route Programming (was Re: bgp route-map) Haesu (Aug 25)
- Lazy Engineers and Viable Excuses Danny McPherson (Aug 25)
- Re: Lazy Engineers and Viable Excuses Rob Thomas (Aug 25)
- Re: Lazy Engineers and Viable Excuses Haesu (Aug 25)
- Re: Lazy Engineers and Viable Excuses Joe Abley (Aug 25)
- Re: Lazy Engineers and Viable Excuses Jared Mauch (Aug 25)
- Re: Lazy Engineers and Viable Excuses Danny McPherson (Aug 25)
- Re: Lazy Engineers and Viable Excuses Ian Mason (Aug 25)
- Re: Lazy Engineers and Viable Excuses Leo Bicknell (Aug 26)
- Re: Lazy Engineers and Viable Excuses Valdis . Kletnieks (Aug 26)
- Re: Lazy Engineers and Viable Excuses Jared Mauch (Aug 26)
- Re: Lazy Engineers and Viable Excuses Leo Bicknell (Aug 26)
- Re: Lazy Engineers and Viable Excuses Jared Mauch (Aug 26)
- Re: Lazy Engineers and Viable Excuses Leo Bicknell (Aug 26)
- Re: Lazy Engineers and Viable Excuses Stephen J. Wilcox (Aug 26)
- Re: Lazy Engineers and Viable Excuses Matt Levine (Aug 26)
- Re: Route Programming (was Re: bgp route-map) Haesu (Aug 25)