Re: [sidr] Route Leaks and BGP Security

[Russ White <[e-mail]>]

> 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