> 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 _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
