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? 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? is there other data that could be used (outside of bgp) to tell the victim that the path is improper? -chris _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
