soBGP deployment

Sun May 22 10:05:11 UTC 2005

On 21-mei-2005, at 20:25, Randy Bush wrote:

>> If you are an operator, would you deploy soBGP or something like  
>> it? If
>> not, why not.

[skip to the bottom for my reaction to Randy's post]

I think it would be a very good idea to start experimenting with this  
as soon as there are decent implementations.

The operational problem that soBGP will hopefully solve for me is  
peering with lots of relatively small peers, some of whom may be clue- 
challenged with regard to inter-domain routing. (AS number  
consumption seems to be higher than BGP book consumption...)

It's not the really small networks that are the biggest problem, BTW.  
It's the ones that have a few BGP customers but not enough to really  
know how to filter them properly that are the most dangerous.

The trouble is that today, I basically have three choices:

1. Generate filters from a routing registry. Here in RIPE country, we  
have a pretty good routing registry, because it's also the RIR  
database. Still, many people don't register their stuff, or don't  
register it correctly. And the tools necessary to generate  
configurations are _very_ hard to use. Also, if something goes wrong,  
my filters are zapped with unpredictable results. So basically I'd  
have to work very hard to get something that doesn't work properly  
and will kill my network if it fails.

2. Maintain filters manually. That won't scale, so the fact that  
peers usually don't inform you when they have new announcements etc  
doesn't even matter.

3. Use max-prefix and push a virgin into the volcano once in a while.

The nice thing about something like soBGP is that it makes it  
possible to work together to solve this problem rather than everyone  
having to do it on their own. For instance, if I know that networks X  
and Y have very high standards and when they say something is ok, it  
is, I could accept certificates signed by X or Y. This only requires  
the bare minimum of clue from the origin AS: they need to include the  
signed certificate, not much more. When something goes wrong, the  
worst thing that can happen when (for instance) Y screws up, is that  
I lose some peering routes, or I potentially allow some routes that  
shouldn't be allowed. The former case isn't all that bad: I still  
have all the routes for which I don't depend on Y. The latter case  
could be problematic, but it would be hard for an attacker to abuse  
this situation as she still has to corrupt the source or neighbor  
ASes in question.

I'm not saying this will solve all our problems, but I think there is  
a lot of potential here, and we need some operational experience to  
guide further development.

> something like it, for sure.  but i vastly prefer the s-bgp
> approach as it maps closely to bgp operational reality,

S-BGP signs every update. This is problematic in several ways. A  
receiver needs to check all AS hops in each AS path (that would be  
~500k for a full BGP table), which means you are pretty much forced  
to have a crypto accelerator on board. Also, no more peer group  
update optimization, so when you have a lot of peers you're going to  
burn much more CPU time for every update.

Last but not least: because S-BGP signs updates, a secret key must be  
present inside the router, making physical security much more important.

> and does not rely on a published policy database, which we have  
> seen fail
> for over a decade, etc.

soBGP and S-BGP aren't different in this regard, AFAIK. I don't think  
either needs a "published policy database" but obviously they need  
some trust anchors and access to policy information in some way.

> we should learn from the decade-long problems with the deployment
> issues in dnssec, and map routing security as closely as possible
> to operational protocol and reality.

If you give people an incentive to use a technology, you'll see the  
use of that technology increase over the situation prior to the  
incentive.  :-)  (See MD5 last year.)