[126261] in North American Network Operators' Group
Re: Securing the BGP or controlling it?
daemon@ATHENA.MIT.EDU (Jared Mauch)
Mon May 10 12:59:31 2010
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <4BE838EB.3000000@foobar.org>
Date: Mon, 10 May 2010 12:58:45 -0400
To: Nick Hilliard <nick@foobar.org>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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...
>=20
> There are a lot of problems associated with using IRRDB filters for =
inbound
> prefix filtering.
>=20
> - some clients announce lots of prefixes. This can make inbound =
prefix
> filtering difficult in some situations.
>=20
> 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=
