Re: [sidr] BGPSEC Threat Model ID

[Russ White <[e-mail]>]

> To say that BGP routes "leaked" via an AS for purposes of MITM, DoS, or
> benign, that is not an authorized transit for a given prefix is out of
> scope 
> because it is not a "semantics violation" does not mitigate what I perceive 
> as  a very significant risk to my operations.  

This is something of an aside --but I find the entire discussion about
"semantics violations" a bit of a red herring. If we are to secure every
possible "semantic violation," then we should also be securing
communities, next hops, and verifying the AS of the peering router is
actually the AS contained in the AS Path --in a way that operators
multiple hops away can check. These are all also "BGP semantics," not
just the AS Path.

> Absent a companion set of mechanisms and controls under cover of "BGPSEC" 
> to mitigate that risk, I'm opposed to the publication of this document
> under the 
> auspices  of  "Threat Model for BGP Path Security".  I.e., it is not an
> acceptable 
> residual risk.

The bottom line issue --as I see it-- is that we've never properly
defined the problem space.

To secure something requires that everyone understand the intent,
whether by implying it from inband signaling, or knowing it through out
of band signaling. SIDR --and hence this threats document-- has been
going down the path of "we want security without knowing intent." A
logical impossibility.

So, I agree with Danny --this document doesn't cover the threat space,
and shouldn't be published. Instead, we need a real analysis of the
entire threat space, without regard to the difficulty of actually
securing that space.

> I'm saying policy is a big part of the problem, at least as considerable
> as  
> "integrity" of the AS_PATH, IMO, and if we don't take a systemic approach 
> and consider the gaps that exist, then it's hard for me to justify the 
> investment.

To put this in different terms:

1. You can't know if something is "secure" without knowing the intent of
the "authorizer."
2. You can't know someone's intent unless they tell you --inferring
intent is dangerous and bad.
3. Hence, securing a system without advertising intent is impossible.
4. Intent == policy.
5. If you're going to include policy, then you need to consider all
policy, and not just a narrow range of policy "because this is what I
care about, and it's what also happens to be easy to secure."

Whether intent should be transmitted in band or out of band is a matter
of open discussion (though I think we must either resolve to change the
nature of BGP, or resolve to signal intent out of band).

:-)

Russ