> I think that draft-foo-sidr-simple-leak-attack-bgpsec-no-help-02 shows > very well why rpki-origin-validation and bgpsec are vulerable to route > leaks. Also it has a good and simple example of a route leak. One > drawback that I see is that it does not explain the problem in general, > the document is focused on route leaks as result of > Man-in-the-middle-attack. Recent events relating leaks showed us that an > attack it is not necessary, just some fat fingers in the right place and > you are done.
In reality, what we are calling a "man in the middle attack," has always just been one instance of the more general "route leak" problem. The only way to know if a route has been "leaked," is to know what the table _should_ look like. BGPSEC (and the original drafts, S-BGP, on which the BGPSEC "requirements" are based) is focused on "this is what really happened," rather than, "this is what should be happening." The interesting point of security (if we want to prevent problems rather than just provide forensics) is, "this is what should be happening." So, to answers Chris' questions: >>> 1) "Yes, route leaks are a problem, please fix them." Yes, route leaks are a problem, and there needs to be some way to guard against them, which means, we're going to have to talk about intent. >>> If #1 above is the answer, and IDR decides that changes to the BGP >>> protocol are warranted (or are a possible solution to the problem) >>> then SIDR has agreed to do what they can to 'secure' the bits >>> added/changed/used in that endeavor. This, OTOH, I disagree with. The most direct way to solve this problem isn't to "add bits to BGP." It's to provide a general framework in which intent can be exposed where necessary. Let's not pretend that this "route leak" problem is the last and only problem to be solved, nor that the solution to all possible future problem is to continue to "add bits." >>> 1) SIDR SIDR is the correct place to address this problem, though I know it means reconsidering the entire suite of requirements and currently proposed solutions. OTOH, that's a good thing, because it might make us go back and look at real requirements, rather than trying to narrow the requirements to the set that can be solved with an already proposed solution. :-) Russ -- <>< [email protected] [email protected] _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
