soBGP deployment

Pekka Savola pekkas at netcore.fi
Sat May 21 20:34:45 UTC 2005


On Sat, 21 May 2005, Steven M. Bellovin wrote:
> 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.

Yet, what is the (SBGP) alternative?

I don't think we have much success distributing this kind of 
certificates in similar scenario either.  At least we _do_ have some 
(limited) experience and even success in recording the prefixes in 
routing databases, and adding a signature there would be easy.

There's nothing to say the functional equivalent of certificate could 
also not be passed in an option or some other means as well when 
needed.  My assumption would be that being able to use public 
databases would be a protocol optimization.

Compare this to the situation when BGP filtering is done by 
automatically generating the prefix lists.  How would enhancing that 
to include a signature (and/or certificate) make matters worse or 
inefficient?  Is there any reason to believe using a different 
approach would fare any better?

Note that the original soBGP didn't require any updates when the 
peering relationships changed; based on a quick look, a later 
extension has probably changed this.

> 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.

Note that there's no technical reason AFAICS not to tie the signed 
origin statements to the origin's AS number, i.e., if someone would 
want to hijack a prefix, it would need to spoof the AS number as well. 
Not sure if that helps a lot, of course.

But this is a good point -- I think a fundamental question that needs 
to be asked is whether a sufficient security could be gained by just 
the originator and the verifier doing the cryptographic operations, 
and not requring everyone in the middle also do them (adding 
signatures etc.).  Personally I'd certainly hope so -- because the 
practical deployment issues with the on-the-path signing model seem 
prohibitive (too much 3rd party deployment required before the 
solution would be useful).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



More information about the NANOG mailing list