[picking on this message to base my comments] On Tue, May 13, 2014 at 09:48:32AM -0400, George, Wes wrote: > If I were to define a route leak succinctly, I???d say something like: > > A route leak occurs when a valid (in this document???s case, valid= > validated by RPKI Origin Validation and BGPSec) route announcement is > propagated beyond its intended AS boundary. The AS boundary can be one, or > an arbitrary number of ASNs away, and may be different for different BGP > Peer ASNs. These leaks can occur due to either misconfigurations or > malicious intent (I.e. An attempt to perform a MITM attack), (and any > solution should provide means to prevent both types of leak).
This to a large extent identifies the problem: BGP *as a protocol* has no idea what these boundaries are. Thus, "intent" is up to the perception of the involved parties. This thread has looped a few iterations with "this is a problem!" and SIDR basically saying "there's nothing in BGP here to secure". Both things are still true. I think documenting route-leaks and their potential negative (or malicious) consequences is worth GROW doing. I think this issue exists even without bgpsec being involved. While it's correct that bgpsec doesn't add anything here, until the underlying base protocol has some idea of what we can do, picking on bgpsec doesn't help. If anything, I'd probably take the route-leak document and say "here's the problem" with a one or two sentence note that bgpsec doesn't do much. In it's current form, I don't think the document is ready to progress. I'd even suggest it needs to be rescoped. The interesting work is resurrecting the thread on injecting routing policy intent into some system we can secure. :-) -- Jeff _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
