Re: Lazy Engineers and Viable Excuses

[Ian Mason]

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