Re: [sidr] BGPSEC Threat Model ID

[Brian Dickson <[e-mail]>]

On Fri, Nov 4, 2011 at 9:21 PM, Randy Bush <[e-mail]> wrote:
>> I suspect that it is a case of "accidental back-up transit via a
>> peer".  (I have seen this personally, where it was "malicious" instead
>> of "accidental".)
>
> and i have seen it intentional and pre-agreed.  life is not just simple
> customer, peer, upstream.
>
> randy

I think many of us have seen "special" arrangements, either first-hand,
or involving our customer(s) as one or more of the parties to such an
arrangement.

I think if we categorize neighbors as "customer, transit, peer,
special", that is still useful.

Here's why:
- as a general rule, "special" is negotiated between parties (two, or
more-than-two, doesn't matter)
- it is fine to have "customer" include "customer's customer et al",
and even "customer's special neighbor" iff the customer wants
- except when all the parties are part of a single "special"
arrangements, "special" is non-transitive.
- there can be many pools of "special", even with overlapping membership
- pretty much by definition, "special" pools are contiguous
- outside of that contiguous area, the boundary to that special area
can be treated as a normal AS (by non-participants)
- in fact, special pools could almost be treated like an AS Confederation

The last two points basically say, if we ignore the goings-on within
such a region, applying the simple rules (customer/transit/peer) are
sufficient to prevent leaks crossing any boundary other than between
region members.

Take as a whole, this is more than sufficient benefit to employ, so
long as it is possible for members of such regions to "remove the
safeties".

The exposure is strictly intra-region at that point, which is a lot
better than it is today.

Mechanisms for preventing route leaks don't have to necessarily be
perfect to be useful, IMHO.

Keeping the mechanics themselves simple, and the semantics clear, is
the second most important part. Sensible defaults is the most
important. Third is allowing network admins to disable them as needed.
Kind of analogous to the three laws of robotics, now that I think about it...

Brian