- 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.
further, the latter, because it relies on a separate data set for path validity, has serious and very kinky temporal sync problems.
*sigh* Once again: This data is updated at the same rate and in the same way as BGP routing data. Randy, if you're going to ignore me, and you _claim_ to have read teh soBGP drafts, you could at least tell the truth about the way soBGP works. I don't lie about S-BGP, I know how it works, and understand its good and bad points. This is an issue of _design tradeoffs_, plain and simple, as all security is. If I had infinite money, I might live in a burglarproof house. I don't, hence, I accept some level of break in risk. This is the way life is. If I had infinite processing power and infinite bandwidth across every link, my tradeoffs are different when considering the options available.
i receive a bgp announcement from a new peer, but the announcement was originated two weeks ago (shockers! a stable route); was the asserted path to my new peer valid when the announcement was originated two weeks ago? once your mind starts down such paranoid paths, the void opens before one's eyes.
I have this: A---B----C | | +---D----+ A is dual homed to B and D, and is advertising 10.1.1.0/24 through both. A removes its connection to B, but continues its connection through D. D is aggregating to 10.1.0.0/16, just to make things interesting. How long can B continue advertising the _fully signed_ and, to C, fully secure path to 10.1.1.0/24 through a path that no longer exists? No matter how long you make the timestamp, it's too long (and how long _is_ S-BGP's timestamp??). The possible attacks of this nature against signature based systems are limitless. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone