> danny's draft actually does a decent job of saying what a leak is (one > instance of a leak at least, which is fine), it just doesn't say how > you'd know that from 2 as-hops away... (today, with out bgp changes > and/or external knowledge about the ASes in the AS-Path)
I came to the conclusion long ago that BGP doesn't carry the information needed to "secure" the AS Path... Maybe this is why BGPsec can't provide the information needed to make intelligent decisions in so many places --because BGP itself doesn't provide that information, and BGPsec only attempts to "secure the semantics of BGP" (and that only in a rather incomplete way). The solution isn't to rule out such problems because they're "unsolvable." There are, in fact, at least two systems that can solve this problem. >> When S sends a packet to D, that packet should traverse >> only ASs that S trusts OR that D trusts. If the packet >> traverses an AS that NEITHER S NOR D trusts, then a route >> leak has occurred. I would generally avoid using packet flow models as a way to describe BGP security issues... BGP, like all routing protocols, is a distributed real time database combined with a set of rules about using the data within the database. By signing the updates, you're attempting to show that the each node participating in the database has followed the rules correctly. The problem is that many of the rules are implicit, rather than explicit, and implicit rules don't lend themselves to being signed. Danny's route leak problem, or needing "beacons," to take routes out of the system, etc., are instances of implicit rules. You have to start with a good model and good requirements, and then work from there. The model the WG has chosen --"we're going to secure BGP semantics," doesn't lead to a good result, simply because not all the semantics are on the table to be secured. :-) Russ _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
