soBGP deployment

Tue May 24 01:57:18 UTC 2005

>> 1) Keep the security ancillary data nearby.  You might need it when the 
>> source of the data is unreachable (perhaps because of an incident like a 
>> flood).
>
> That is why in my view soBGP is something that can only be deployed as an 
> after-filter (i.e. ones full BGP mesh is in for decisions about if the 
> routing data is to be passed along to other peers or to IGP).

I don't understand this assertion. I get the feeling there's not a lot of 
understanding about how soBGP actually works....

An AS _does not_ connect to a centralized location of any type with soBGP. 
You receive certificates through one of several possible sources, including 
a new message type within BGP itself--so you can receive certificates 
through "set aside" BGP sessions, or through "normal" peering, whichever 
way makes more sense for your architecture.

Once you have these certificates, you build a database of validated 
certificates that attest to specific information, including origination 
authentication and paths, and you _can_ (though no-one is forcing anyone 
to) also hang policy off this database. This operates in exactly the same 
way as BGP does today. It's distributed, peer to peer. As long as your 
interface to all your external peers is consistent, it will work, no matter 
how you implement it internally--just like you can use confeds, route 
reflectors, full mesh iBGP, route servers, or anything you like within your 
AS with BGP today.

>> 2) Appending signatures is dicey.  It has to be all public key and 
>> there's never a guarantee that the latest signer hasn't stripped out 
>> previous entries.  (That could make a longer path seem shorter in order 
>> to redirect traffic.)

AFAIK, you can't strip sig's out of S-BGP because of the way the sigs are 
built. You can't strip sig's out of soBGP because they simply aren't there. 
soBGP does not touch, in any way, shape, or form, the current BGP packets. 
There are additional message types proposed, but these in no way impact any 
current NLRI information, at all.

>> IMHO - the inherent problem is that a router is trying to work inside the 
>> plane of activity (meaning it can only talk to it's nearest neighbors), but 
>> it takes the view point of something with ubiquitous knowledge to know if 
>> every thing is cool.  How can you do this without a trusted third party 
>> involved somewhere, in a way that is not obtrusive (whether at registration 
>> time or at run time)?

This is exactly how link state protocols work, no? They talk to their 
nearest set of neighbors, but then they build a complete SPF from the 
information they gain through this discussion. This is, precisely, how 
soBGP validates paths.

:-)

Russ

__________________________________
riw at cisco.com CCIE <>< Grace Alone