Re: [sidr] BGPSEC Threat Model ID

[Brian Dickson <[e-mail]>]

On Fri, Nov 4, 2011 at 9:34 PM, Randy Bush <[e-mail]> wrote:
>> I think the distinction between a leak and something more intentional
>> s a matter of policy.  Knowing the policy associated with the
>> adjacencies that an AS is leaking over would allow leaked
>> announcements to be identified
>
> o We can not know intent, should Mary have announced the prefix to Bob

This is a semantic issue, and I think can best be viewed within the
realm of knowing/proving.

You can't prove a positive, but you can prove a negative.

If the semantics regarding intent are limited to negatives, I believe
it is possible to correctly infer one aspect of intent.

See below for an analogy...

> o Policy on the global Internet changes every 36ms, new customers, new
>  peers, circuit moves, ...

So long as the policy expression point is eBGP peering sessions, and
that marking is mandatory and inherited by routes crossing those
sessions, the 36ms issue itself becomes moot.

BGP is stateful, and all of these things that involve the above
new/changed eBGP things (peering sessions, customers, peers) involve
stateful changes. Tying policy (and policy changes) to only eBGP
sessions, regardless of other things that influence route
announce/withdraw/attribute-change means routes marked when crossing
eBGP boundaries will always be statefully-correct. (The presumption is
that _policy changes_ on eBGP will automatically require
re-announcement of all prefixes across that session, either by forced
soft reconfig outbound enforced by the protocol, or an actual session
reset.)

Here is what I hope is a useful analogy to illustrate "negative intent".

Consider the realm of business communications of written material,
e.g. either paper or via signed (S/MIME) email.
Consider this realm where the only additional policy component is the
Non-Disclosure Agreement.
Presume NDA material is presumed here to always be marked, including
with who the NDA parties are. Also presume chain-of-custody style
marking history, if material is re-sent to other parties.
Presume NDAs permit material to be communicated to parent companies,
to subsidiaries, and even to joint-venture subsidiaries.
Presume NDAs permit material to be exchanged between the signatories,
and their subsidiaries, and vice versa.
Presume NDAs do not permit sharing with any other party.
Presume NDAs do not permit joint-venture subsidiaries who receive
material from one parent, to be sent to the other parent, even the
other parent is one of the two NDA signatories. (Think of this as
parents -> subsidiaries having additional/separate NDAs that also get
stamped on material shared to the subsidiary.)
Presume NDA material exchanged by their respective subsidiaries can
only be sent directly via the signatories themselves.

Now consider the scenario when someone who isn't a signatory with any
of the above NDAs between A and B, i.e. someone who is neither A, nor
B, nor a subsidiary or joint-venture subsidiary (direct or indirect)
of A or B.

The recipient has a chain-of-custody cover sheet showing who sent it to whom.
A responsible actor would do what with this document? (I propose the
answer, presuming every document is a duplicate, not an original, is
to destroy it.)

A bad actor might use it, and might forward it to someone else.
The party receiving from a bad actor is able to correctly infer from
the attached NDAs and chain of custody documents, that the immediate
sender is in fact a bad actor.

I would argue that regardless of why or how one receives such a
document, the _definition_ of bad actor can be derived from whether or
not he/she destroys the improperly communicated document. A bad actor
is _de_facto_ someone who accepts the document without destroying it.

Note also, in this arbitrary analogy, the following also apply:
- not every document has an NDA.
- not every extra-org arrangement will be NDA'd
- chain-of-custody is presumed to be based on crypto, and includes
chaining of signatures (a la BGPsec's current I-D doc)
- chain-of-custody is present whether there is an NDA or not
- multiple NDAs can be present, esp. when documents are sent to
subsidiary^n'th org)
- NDA was chosen because it generally is included in employment
agreements governing behavior of individual actors within an
organization
- Employment agreements may even have restrictions on
improperly-received non-public (NDA) material to which employer is not
an NDA signatory

And finally, here's how this analogously applies to a possible
addition to BGP/BGPSEC:
- adding a flag or flags to eBGP peering sessions, indicating:
  - whether or not the sender wants to _limit_ distribution of routes
that are sent (to just recipient's "customers" - should be default on,
turned off only when sender is transit customer of recipient);
  - whether or not the sender wants to _send_ (otherwise)
distribution-limited routes (e.g. those learned from peers - default
off, turned on only when sender is transit provider to recipient)
  - whether or not the recipient will _accept_ (otherwise)
distribution-limited routes (e.g. from a transit provider - default
off, turned on only when recipient is trasnti customer of sender)
- default values equate to "true peer" - I send my customers' routes
(and customer^n'th routes), and distribute your routes only to my
customers.
- Controls automatic blocking only; local policy cannot override this
blocking, but can do anything else it wants/need. If local policy is
being blocked, there are ways to change the peering flag-bits to
enable that policy (caveat emptor)
- Permits implementation of any neighbor-neighbor policies, including
mutual transit
- Blocks route leaks in all cases except (idiotic) multi-party mutual
transit (more than one consecutive hop with mutual transit), and even
then, route leakage is constrained to at most one AS-hop away from
such a contiguous mutual-transit "mess"
- Requires only signaling negative-intent - ''Don't send this in an
unconstrained fashion". It's the only (new) bit set on routes; the
rest of the bits on peering session control whether/when this bit gets
set, or when/how to block based on this bit. The intent is clear, even
when the route is seen many AS-hops away.

Some things just work better when done on a white board interactively
- sorry if this is not as clear as it was intended.

Brian