Re: [sidr] BGPSEC Threat Model ID

[Brian Dickson <[e-mail]>]

On Wed, Nov 2, 2011 at 1:41 PM, Russ White <[e-mail]> wrote:
> 1. Most providers apparently want to enforce policy without telling
> anyone what their policy actually is. That this is a logical
> contradiction doesn't seem to disturb anyone.
>
> 2. You can't "enforce" your policy --all you can do is signal to someone
> else what that policy is, and ask them nicely to enforce it for you.
>
> 2a. If you have a business relationship with this other party, then you
> already have an enforcement mechanism at hand --signatures and other
> sorts of things won't provide anything additional.

Actually, this is not strictly true.

Let's consider the smallest case where there are more than two parties,
where route leaks cause problems (whether malicious or accidental).

Parties: A, B, C.
Relationships, all formalized via contracts (whether for transit or peering).
C is a customer of A.
C is a customer of B.
B and A are peers.
For sake of argument, presume that A and B also have upstream transit providers.

The intended policies have A and B exchanging routes of only their
customers, and
their internal routes.

C receives the full Internet routing table from both A and B.

The agreements between A and C, and between B and C, prohibit C sending anything
other than C's own routes to A and B.

Then consider what happens in the case of C sending B's routes (and
B's upstream routes) to A.

A prefers routes learned from customers over peer or transit routes.

A now prefers the path via C to the entire Internet, including traffic
from A to B.

There is no _technological_  mechanism for B to stop this, short of
turning down C's BGP session.
And, this also presumes that B has some definitive way of discovering
this, which is not necessarily
the case.

When we add in D, a transit customer of C, we can see the challenging
nature of the problem.

How to we distinguish C sending B's routes to D (which is good and
expected and allowed),
from C sending B's routes to A (not good/unexpected/not "allowed" by contracts)?

If there isn't some easy way for A to see that their customer is
sending routes which are not
their own or their customers', by way of "marking" in the middle of
the AS path, then the scale
of the problem is huge (having prefix filters and AS-path filters
built on ... the IRR).
With marking, we gain easy filtering to honor the senders' intentions, and
the ability to authenticate things and still limit the information on
a need-to-know basis.

Observe the following - information about relationships encoded within
the path will be visible
only to those who receive the path. If the path signals "block me",
the relationship information
is also blocked.

This may be an acceptable degree of information leakage - which
happens to coincide with
path information, which necessarily must be leaked.

Brian