soBGP deployment

Tue May 24 02:12:56 UTC 2005

> The essential difference as far as I can see today between soBGP and sBGP 
> in this space is that, as a 2 liner:
>
>  - sBGP allows the receiver to validate that the update indeed traversed 
> the path described in the AS Path Update as part of the local acceptance 
> of the update.
>
>  - soBGP allows the receiver to determine that the AS Path describes a 
> plausible traversal across the network, but cannot validate that the 
> update itself traversed this path.

I would restate soBGP's in this way:

- soBGP allows the receiver to determine that the AS PAth describes a path 
that actually exists, anchored at the beginning with the originating AS, 
and anchored at the end with the advertising AS, but cannot validate that 
the update itself traversed this path.

This is a very good summation of the points between the two concepts--using 
something that signs actual routing information passing through the system 
(including, but not limited to S-BGP), or describing the routing system 
dynamically and in real time, and deciding if the routing information 
you're receiving actually matches the description you've built (soBGP, IRV, 
and even reverse DNS lookup solutions are all within this camp).

There are more tradeoffs than apparent here, so look carefully. :-) For 
one, it's harder to make a strong case that it matters where the update has 
been than it appears at first glance--the first and obvious answer is to 
say that you can gather policy based on the path the update has taken. This 
isn't true in a routing system, however, because of aggregation and 
filtering, first, and because packets don't _necessarily_ follow the path 
of the update, second....

> In looking at this what I personally saw was a design tradeoff, where 
> soBGP attempted to lighten the update load and the certification load by 
> making one part of the BGP update message unprotected by a certificate 
> set, while sBGP attempts to provide the receiver with sufficient 
> information so as to allow the receiver to validate the entire update.

Somewhat, yes.... soBGP's original design goal set was:

-- Do not touch BGP as it exists today. Make it run without modifying 
packet formats, etc.

-- Do not require a centralized registry of information.

-- You must not rely on routing to secure routing.

-- Do not require the crypto to be done on box or off box, just let the 
crypto be done in the most logical place possible, which varies from AS to 
AS.

-- Do not require each AS to have the same security policy. Internetworks 
and AS' within internetworks vary, the same size does _not_ fit all.

This seemed like a pretty good set of goals, when we started.

:-)

Russ

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