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@cisco.com CCIE <>< Grace Alone