Hi Chris, On Nov 20, 2011, at 10:35 PM, Christopher Morrow wrote: > On Wed, Nov 16, 2011 at 11:23 PM, Danny McPherson <[email protected]> wrote: >> >> Team, >> I've updated this draft based on some feedback received already. Given >> the discussion at the WG session, and the list discussion as of late, I'd >> like >> to ask that it become a WG item and used to inform the BGP Threat Model >> document -- particularly with regards to what's an acceptable residual risk >> and >> what is not. Once that's comprehensive it can be used to inform secure >> routing >> requirements documents in the working group, and then we can begin assessing >> the feasibility of reducing various risks. > > "The authors believe the capability to prevent leaks should be a > first-order engineering objective in any secure routing architecture." > > So, in the simple scenario laid out, the customer is filtered by the > isp's, no? and the filter data is built with something like: take irr > data, meld with rpki data, create filter-lists. > > The rpki data gives the isps an ability to filter the customer > announcements, which would stop the leaks. Is the thing you really > want to outline in a draft the process to link the > resource-certification data with the existing IRR data and create > better prefix/as-path filters?
As the -01 draft states: ---snip--- Discussion of out of band methods to mitigate this attack are beyond the scope of this document, as it's objective is to inform routing protocol design choices currently being considered within the IETF's SIDR Working Group. ---snip--- > I think one item that was asked for on the list (or perhaps in the > meeting) was: How can you know a route you see is a leak? > > Taken another way, in the case of your example: > > victim - isp2 - attacker - isp1 > > how is the victim to know that this path isn't proper? > what in the update says that? That's the point. :-) At present, nothing being "secured" in the UPDATE, (specifically AS_PATH wrt BGPSec), will tell you that the UPDATE was sent through a legitimate control-plane path vs. an illegitimate control-plane path. In today's networks, the means to control the propagation of a particular BGP route are through configuration of 'policy' locally on routers, (ASBR's/PE's), that look for a combination of /one or more/ _BGP_attributes_ in the BGP route itself to limit its propagation. As one specific example, an operator of an AS typically configures their ingress ASBR's to assign a specific standard BGP community that says something like: - this is a customer route; - this is a peer route (I would note that these BGP standard communities are 'local' to and only have meaning within the operator of their particular AS. An operator should NOT or would NOT "trust" third-parties, e.g.: their customers or peers, to set and send these communities to them for lots of obvious reasons). When a BGP route travels to that operator's egress ASBR's, the egress ASBR then has a locally configured policy that looks for the locally significant BGP community string that says: "this is a customer route", in which case the route is sent out of both peer & customer eBGP sessions. OTOH, if the eBGP policy at the egress ASBR determines, based on the locally significant BGP community string assigned to a BGP route, "this is a peer route", the action in that locally configured policy at peer eBGP sessions is to drop (not announce outbound) that particular UPDATE; whereas, the action at customer eBGP sessions is to announce that UPDATE outbound. Locally significant BGP communities + locally configured policy are just one method that could be used, but likely the most widely used. Depending on the size of one's network other BGP Attributes + locally configured policy may be used. > is there other data that could be used (outside of bgp) to tell the > victim that the path is improper? IMHO, and as I think Russ has pointed out, BGP was only (?) designed to express reachability, not to carry or forward _policy_. At present, nothing in the BGP protocol disseminates _policy_[1]. Instead, policy to control propagation of BGP routing information is only known to routers via out-of-band configuration (through CLI or NETCONF), either manually or through automated methods. -shane [1] The only minor exception I can think of to this is the well-known NO_EXPORT or NO_ADVERTISE BGP communities. However, those have an extremely limited scope -- specifically, both communities are only exchanged between _directly_ connected adjacent ASN's. I would add that since BGPSec does not make any attempt to sign the BGP community Attribute, it follows that even in this most limited case BGPSec is not able to certify (authenticate?) that a given BGP route *should* or *should not* be propagated to AS'es 2+ hops away. What if one stripped the NO_EXPORT or NO_ADVERTISE community off and re-announced that BGP route -- is that not considered a MiTM attack, just as bad (or, worse?) as fraudulently inserting one's self into the AS_PATH? _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
