soBGP deployment

Sun May 22 01:45:59 UTC 2005

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

There is no "registry." Each AS distributes set of certificates carrying a 
list of who they're connected to. You can, as an option, list who you allow 
to transit, and who you don't allow to transit, and other policies (nothing 
longer than prefix length x within this address block, etc). But, there's 
nothing saying you _must_ send any sort of _policy_ out. It's even possible 
to build the certificates so you can "hide" peering relationships you don't 
want to be known about by anyone other than the specific peers involved (by 
building multiple certificates of specific types, and filtering who you 
send them to).

As for updating the information--each AS originates it's own piece, just 
like they do routes today. If they keep their routes up to date, there's no 
reason not to update your peering information in a certificate you're 
originating. It's not as if you have to make a phone call to the local RR, 
and have them update their database, etc....

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

Huh? :-) Since soBGP doesn't put anything in the existing BGP packets at 
all, there's nothing to "cut and paste" from one packet to another (?). You 
can "make up" paths, I suppose, but you'd have to make one up that:

-- already exists
-- has one end anchored at the receiving AS
-- has the other end anchored at the originating AS

That's a pretty narrow range of "made up paths." When you start factoring 
in aggregation of routing information, you quickly realize there are much 
larger holes in aggregation than the "hole" of replacing one path that 
exists with another path that exists.

As for deploying this on a 2500--well, that's never been envisioned. The 
entire architecture has always been envisioned as running either on _or_ 
off box, where you could do the crypto part once on an "soBGP server," and 
then let the routers on the edges ask this "server" about the routes they 
receive. This is explicitely called out as the most likely deployment 
possibility in the current architecture draft, and also in evvery 
presentation we've ever given on it.

Of course, you can always do it on box, as well, given the box in question 
has the resources available. It's also possible, with the current 
architecture, to spread the certificate processing (the crypto part) across 
all the edges of an autonomous system. I don't know how well thought that 
part is, at this point, but we've always intended to allow that sort of 
thing to be done, as long as we can figure out how to do it and not break 
anything. :-)

:-)

Russ

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