> 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...
The problem is, of course, that a "route leak," is explicitly a part of BGP's semantics --on the filtering side of things. Communities, for instance, are very much a part of the semantics of BGP. They are used to filter routes and control the places where routes are advertised; therefore filtering is a part of BGP's semantics. Proving a route should not be advertised is as much a part of this problem as proving a route should be advertised --in fact, you can't really separate the two problems, though we've been trying to for years. "Securing the semantics of BGP," is just a convenient way to restrict the scope to BGP-SEC (SBGP), while being flexible enough to leave out the things BGP-SEC (SBGP) can't fix as well. We need to begin from the beginning, starting with a real requirements document with real requirements framed in a way actually designed to protect the operation of BGP from the perspective of intent, rather than operation. I'll say it again (to be ignored again): all security is about intent. Russ -- <>< riwh...@verisign.com ru...@riw.us _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
