Re: [sidr] BGPSEC Threat Model ID

[Brian Dickson <[e-mail]>]

On Fri, Nov 4, 2011 at 4:11 AM, Randy Bush <[e-mail]> wrote:
> could someone post a clear technical explanation of WHAT a route leak
> is,

I'll bite.

It requires carefully a constructed definition, first:
"Customer" - A is a customer of B iff A has an arrangement with B
which explicitly allows B to announce A's routes to any third party,
and for B to announce B's entire routing table to A.

Customer is a technical arrangement, regardless of how or why that
arrangement was arrived at, e.g. paying money.

If A is a customer of B, A is allowed to announce A's own routes (and
by extension A's customer's routes) to B.
A _may_ (or may not, at A's discretion) signal to B that A wishes B to
forward all (or a subset) of A's (and A's customers) routes to third
parties.
A is not _required_ to do so, and A may further signal that B should
only send those prefixes to a subset of third parties with whom B
peers.

(Observe: B may always announce A's routes to B's other customers.)

A route leak occurs, when B announces non-customer routes to non-customers.

(Those would be routes for which B has not been given explicit
_blanket_ permission to announce to third parties.)

If A (a customer of B) signals to B to not announce a subset of routes
to B's non-customers, but B does so anyways, that would _not_
constitute a true route-leak as such.
(It would, however, be a contractual and technical issue that would
normally be resolved between A and B.)

If it helps, I've tried to illustrate the leak/no-leak distinction below...

Brian

Examples - in the following, I'll use "->" or "<-" to indicate
customer relationships, and "-" to indicate non-customer (peer)
relationships.
The route traverses the AS's left-to-right. A is the originating ASN,
and the highest letter is the receiving ASN.

The following are non-route-leak paths from announcer to receiver:
A - B (A peers with B)
A -> B (A is a customer of B)
A <- B (B is a customer of A)
A -> B <- C
A <- B <- C
A -> B -> C
A -> B -> C - D
A -> B - C <- D
A - B <- C <- D
A -> B -> C - D <- E <- F (and so on)

(There can be only one "-", and all the arrows must point towards the
"-" in the ASCII stick diagram.)

Any of these would be route leaks:
A - B - C
A <- B -> C
A - B -> C
A <- B - C
A -> B - C -> D
A <- B <- C -> D -> E (This is one of the most common sources of
route-leaks. It is one of the easiest mistakes for a network engineer
to do.)
A -> B -> C - D <- E <- F -> G -> H (This is how the previous example
usually is seen in the wild)
A -> B -> C - D <- E - F <- G (Here E is accidentally providing transit to F)

The special case of mutual customers (mutual transit) would be represented as:
A <-> B

Mutual transit/customer arrangements can legitimately do the following:
A -> B <-> C -> D
A <- B <-> C <- D
A - B <-> C <- D
A -> B <-> C - D

Basically, on any given prefix announcement, "<->" can be treated as
either "<-" or "->" in order to fit the "allowed" rules.
If neither of those substitutions fits an existing "allowed" rule,
then the result would be a route leak. Examples of mutual-transit
leaks:
A - B <-> C - D
A <- B <-> C -> D
A - B <-> C -> D