On Wed, Nov 2, 2011 at 10:52 AM, Stephen Kent <[email protected]> wrote: > At 3:27 PM -0400 11/1/11, Danny McPherson wrote: > >> Route leaks represent a violation of an ISPs local policy, i.e., the ISP >> is propagating routes that it, locally, did not intend to propagate. > > Perhaps the network operator DID fully intend to propagate ("leak") those > routes in order to hijack and MITM traffic? Any multi-homed customer can > launch such an attack today of this sort, and as a matter of fact, it > happens all the time, for benign or malicious purposes. > > To say that this is not a "semantics violation" and therefore in scope > does not mitigate the risk. How that risk can be considered as a > "Residual Risk" in a "Threat Model for BGP Path Security" document totally > > escapes me? > > I interpret the task at hand as trying to secure BGP, not a new EGP. Since > BGP semantics (and syntax) do not provide a basis for deciding when an > advertisement constitutes a route leak, I think it reasonable that the > BGPSEC threat model view this as out of scope. If BGP were modified to > express semantics we're discussing, then it would be in scope, and I would > expect BGPSEC to address it.
BGPSEC is an _extension_ to BGP. (This is according to the WG Charter.) Adding ways of identifying updates as "bad", whether because of failure to authenticate, or because of authenticated data which indicates a semantic violation, is in-charter. Blocking updates does not fundamentally change the BGP path selection process. Thus, it isn't more than an enforced filtering methodology. It fits squarely within the model proposed by BGPSEC. If there is a need to address _malicious_ route leaks, and it is not possible to address without securing the necessary added semantic elements, then clearly those added elements can't and won't be done by the IDR WG, since securing those elements would be the responsibility of SIDR. Put another way - adding elements to BGP to address accidental route leaks will do nothing to address malicious route leaks. On the other hand, anything which addresses malicious route leaks, by definition, will also address accidental route leaks. Malicious route leaks and accidental route leaks are two of the biggest threats to BGP. Having two solutions, one done by IDR and another by SIDR, is clearly redundant, since the SIDR solution would make the IDR solution moot. Thus, it make the most sense to include the solution to malicious route leaks in SIDR's mandate. If need be, I request the WG chairs expressly poll the WG on this issue. I suggest that the issue remain in-charter for some period of time, until a solution to the problem is presented, at which time it be included in the main protocol document for BGPSEC, at which time it become mandatory. (BTW - I have already given a preliminary proposal, which is not an I-D yet, and which needs some work. But, this establishes the feasibility of achieving the semantics needed to mitigate the risk of route leaks.) > Sorry, I misunderstood your question. Now I know the data item to which you > were referring. I checked with a network operator here at the RIPE meetings, > to understand how/why it is used. I now believe that the ORIGIN attribute > is a poster boy for an attribute that is unsuitable for inter-AS protection. > This attribute can be set to one of 3 values by an AS sending an Update. > (One of these values cites EGP as the source of the data, so unless the > Update has been terribly delayed, this is not a credible value :-).) The > other two values are IGP and INCOMPLETE (i.e., mystery). How would an AS > that sees this value externally verify that the value is accurate? I am > unable to imagine how this would work. > >> Our context assumes use of the RPKI, and the RPKI attests to only >> prefix and ASN holdings of entities, hence the focus on these >> attributes. For example, MPLS attributes are not supported in the >> RPKI, so they are out of scope here. > > I think the "Threat Model" document should give consideration > to Path Attributes beyond just AS_PATH, particularly because most > are used in path selection. If we think we don't need to protect > these because they are not in RPKI, then we should consider what > that means rather than assume RPKI contains the information for > all that we need to protect. > > Let me try again. If we can't identify a suitable, authoritative source of > data that could be used to verify an assertion about an attribute in an > Update, that attribute is not a candidate for inter-AS security mechanisms. Here's the thing: (1) RPKI authenticates the Originator. (2) The Originator signs "stuff" (2a) "stuff" MUST include all the things from RPKI. (3) Every additional AS in the path adds itself and signs the result. (4) "Stuff" can include additional elements in addition to the things already identified in the -00 version of the protocol document. (4a) The signature allows the receiver to validate that it was sent by the Originator. The RPKI assures that the Originator is allowed to originate the Update. (4b) It follows that there is no reason not to trust all Transitive values set by Originator, and Signed by the Originator (4c) It also follows that Non-Transitive values could be set by one's Neighbor AS, signed by that AS, and have those values Secured. (5) If any BGP path attribute used in Path Selection is not signed, then BGPSEC has failed to meet its charter requirements. > If Enterprise_E is multi-homed to ISP_1 and ISP_2 and is a > transit customer of both, and then decides (or is compromised > and used to decide) that he wants to hijack traffic from ISP_1 > > towards ISP_2 for Prefix_P by announcing ISP_2's Enterprise_E2 > Prefix_P to ISP_1 through Enterprise_E's local interconnect, > and "policy" makes it a more preferred path, how is this not > > an attack? > > How does BGP indicate (i.e., where are the bits that say) that the Update > sent to E is not to be propagated to another ISP? I've been told that the > NO_EXPORT community does not have the right semantics, and that network > operators do not pay attention to this anyway. > > And it's most certainly a threat and one that some consider > out of scope at that? > > I presume that you mean in scope, right? I believe what Danny was saying is, "some consider this out of scope", where "some" means at a minimum the authors of the Threat document, and that since it is a threat, it really should be *in* scope. Consider this a +1 on this as being in scope of the Threat document, regardless of whether or not it should be in-scope for the protocol itself. Brian _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
