On Jan 22, 2013, at 11:08 AM, Christopher Morrow wrote: > On Tue, Jan 22, 2013 at 10:07 AM, Eric Osterweil > <[email protected]> wrote: > <snip> >> - I also don't understand how the text in this (a threats document) can >> claim that route >> leaks are beyond the scope of PATHSEC in a fait accompli manner... This is a >> threats document, right? This is a threat to BGP, right? The RPKI provides >> semantics that > > is the 'leak' a threat to 'BGP' or to the users of the network?
I think this might be a case of picket fences? I see your distinction, but I had thought the wg's broader goal was to protect those that rely on BGP? I didn't think we were designing a protocol that could fall in a forrest with no one to hear it. :) >> ``BGP, itself does not include semantics...'' for... I don't think applying >> this exclusion to >> route leaks survives a sniff test. > > the RPKI is simply a database, it's not part of the BGP protocol. The > RPKI system doesn't include bgp peering data, so while you could > detect and potentially mitigate a 'hijack', it's not clear to me that > you'd know 'leak' vs 'new peering arrangement' just based on the RPKI > data. Indeed. My point was not to draw RPKI into the solution space, or claim something about its goals. I was just trying to illustrate that the wg has already invested (heavily) in systems and designs that are not semantically part of BGP. It just seemed silly (imho) to start claiming that if something isn't part of BGP's semantics, we should treat it as taboo... >> Overall, I think the threats document is still missing a badly needed >> treatise on route >> leaks. > > is it fair to say that you would like the threats document to say, in > perhaps more words than this: > "BGP Path Security has no capability to influence or inform the bgp > system of 'route leaks'." > > this, I think, does run afoul of stephen's want for a definition of > 'route leak' though... but I think it's what you're aiming at? I am not sure. I would suggest that identifying a threat should _not_ be held up by the search for a closed form expression of that threat. Does that make more sense? Eric _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
