soBGP deployment

Sat May 21 20:03:50 UTC 2005

In message <Pine.LNX.4.61.0505212143090.1930 at netcore.fi>, Pekka Savola writes:
>
>On Sat, 21 May 2005, Randy Bush wrote:
>> something like it, for sure.  but i vastly prefer the s-bgp
>> approach as it maps closely to bgp operational reality, and does
>> not rely on a published policy database, which we have seen fail
>> for over a decade, etc.
>
>So, can someone point out the important operational differences 
>between the two?
>
>>From 10K feet view, the only major difference seems to be that sBGP 
>also wants to protect the BGP sessions w/ IPsec all in one solution. 
>(Personally, I don't care about that all that much, and I have some 
>doubts whether this is a good approach for deployability in mind.)

The IPsec piece is actually the least important part of the difference.
>
>Maybe the important operational differences are only observable 
>from 1K feet view ?
>

Fundamentally, the answer to this question is this: how accurate do you 
think the routing registries are?

Both do a good job preventing fraud at the putative point of origination
of the route announcement.  This is obviously the most common form of 
attack.

With SBGP, each node signs the BGP statements it's about to send out.  
The accuracy of the security statement is thus linked to the 
transmission process.  With SO-BGP, the security against in-path 
attacks (or cut-and-paste attacks; see below) relies on a secure 
version of the routing registry.  If an AS forgets to update its 
routing registry to reflect new BGP adjacencies, paths containing them 
will be dropped by SO-BGP listeners.  If old adjacencies aren't 
deleted, routes that shouldn't be accepted will be.  In other words, 
there's a lot less coupling between the transmission process and its 
security properties.  Look at it this way: do you think that (a) most 
sites will publish their policies in the registry, and (b) they'll 
remember to update them?  As Randy has noted, we have a decade of 
experience suggesting that neither is true.  

Let me add a word about cut-and-paste attacks.  A signed origin 
statement asserts that some AS owns some prefix.  That statement will 
be readily available.  A nefarious site could cut that statement from 
some actual BGP session and prepend it to its own path announcement.  
That would add a hop, but many ASs will still prefer it and route 
towards the apparent owner through the nefarious site.  The nefarious 
site wouldn't forward such packets, of course; it would treat the 
packets as its own.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb