- 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
__________________________________
[EMAIL PROTECTED] CCIE <>< Grace Alone