Re: Securing the BGP or controlling it?

[Jared Mauch <jared () puck nether net>]

On May 10, 2010, at 12:48 PM, Nick Hilliard wrote:

> On 10/05/2010 17:00, Aaron Glenn wrote:
> > my gut says things would do well to begin with simply making an effort
> > at maintaining usable irr data and automagically generating sane
> > filters. why don't people do that again? I hope I'm not naively
> > misunderstanding a primary use of irr data in front of 10,000 of my
> > closest friends...
>
> There are a lot of problems associated with using IRRDB filters for inbound
> prefix filtering.
>
> - some clients announce lots of prefixes.  This can make inbound prefix
> filtering difficult in some situations.
>
> pixiedust:/home/nick> grep '>' pakistani-telecom.bgpdump.txt | wc -l
>     967

There are certainly issues around what a customer may have as their primary path and what they are backup for.  These 
issues make for very long prefix-lists.

> - there are some endemic data reliability problems with the IRRDBs,
> exacerbated by the fact that on most of the widely-used IRRDBs, there is no
> link between the RIR and the IRRDB, which means that anyone can register
> any address space.  whois.ripe.net doesn't allow this, but lots of other
> IRRDBs do.

Certainly this is a function that you can petition your local RIR to do, have you made a proposal to them?

> - the ripe whois server software does not support server-side as-set
> expansion.  This is a really serious problem if you're expanding large ASNs.

Have you asked them to include this?

> - there is very little client software.  At least irrtoolset compiles these
> days, but its front-end is very primitive.  rpsltool provides some really
> nice templating functionality, but doesn't implement large sections of the
> rpsl standards.

I certainly agree the tools here are suboptimal, but is that the the reason to throw the baby out with the bathwater?

We're faced with a challenge here, where I surely agree with Peters argument that things won't get better here in the 
next ~7 years.

Who is going to be the provider that turns away business because their customer is unwilling to register their routes 
in a klunky-toolset?  What improvements to the toolset should go back to the community to improve filtering?  If there 
is no RIR <-> IRR link, will people be willing/able to get a certificate when RPKI becomes more readily available?

Will you accept a network outage because your certificate expires (vs a warning, ala SSL certs expired)?

There are many questions here that require engagement by community members to provide viable solutions.  Challenges 
certainly arise when you have nation-state telecom operators/incumbents involved as well that are unaccustomed to being 
told they MUST do something they may be unwilling to.

- Jared