Re: [sidr] BGPSEC Threat Model ID

[Christopher Morrow <[e-mail]>]

On Fri, Nov 4, 2011 at 4:52 PM, Brian Dickson
<[e-mail]> wrote:
> 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.

channeling russ: "where is this arrangement publicly documented?" (So
I can know it and put it into my algorithm)

> 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.)
>

Where is this documented? (this permissions giving)
How is this enforced? (the permission)
what about cases of partial transit? (I sent a route to B, and
requested he NOT send it to the world at large)
  how is that sort of thing documented? (again, channeling russ)

> 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.

depends on your perspective I suppose, no? Doesn't RPSL today have the
ability to signal: "Send partial routes to Foo and Full routes to Bar"
?

> (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...

it didn't really... re-explaining valley-free routing with mistakes
due to agreements not-available 2 as-hops away isn't helpful. Routes
leak, people should filter... not new knowledge.

-chris