Lazy Engineers and Viable Excuses

Tue Aug 26 02:13:11 UTC 2003

At 02:32 26/08/2003, Jared Mauch wrote:

>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.

The trick is for IXPs and NAPs to have terms that *require* people to:-
         1) put their routes in an IRR
         2) keep them accurate

The LINX in London does (1) as a joining requirement and contractual 
obligation, and applies pressure where (2) cause a problem. How many others 
follow similar practices?

>  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 at puck.nether.net
>clue++;      | http://puck.nether.net/~jared/  My statements are only mine.