Chris, On Mar 21, 2012, at 8:15 AM, Christopher Morrow wrote: > On Wed, Mar 21, 2012 at 10:08 AM, Russ White <[email protected]> wrote: >> >>>>>> The point is you've gone beyond the existence of the path here to the >>>>>> rightful use of the path --and that is policy. >>>> >>>>> don't think so. >>>> >>>> Yes, you have. >>>> >>>> Because you've insisted on making the solution work per prefix, you've >>>> moved the problem out of the realm of path validation and into the realm >>>> of per prefix policy. Paths don't exist per prefix. Paths either exist >>>> or don't. Only policies can tell you whether or not a particular path is >>>> available for a particular prefix. >>> >>> clearly there's something I'm missing... if we remove the ideas of >>> SIDR form the table, how does your picture change? how does the >>> outcome change? it SEEMS (to me) that the situation is exactly the >>> same... there's no idea of policy in protocol, there is only bgp, and >>> the local decision by B to NOT send a route to E. >> >> But D has no way of knowing this in band without SIDR. With SIDR, it's a >> matter of looking at the signatures --by the design specs of SIDR > > no, you never sent anything of this route to E so E never had anything > to pass along to C and then to D ... knowledge of this path is not > there, in both the SIDR and non-SIDR cases. All D knows in both SIDR > and non-SIDR cases is: "Look at that, a path through C to B to A, > joy!" > > In the SIDR case, assuming full secure path along from A -> B -> C -> D, D > sees: > "Hey lookie! a 'signed' path from C to B to A!" > > The conversation about E never happens, because .... D has no > information about E.
But, this is the fundamental problem. Or, more succinctly, the problem that's not being recognizing here is one of "scoping" (and, not scoping) of routing announcements. To take a step back, with respect to Route Origin Authentication, the principle there is that only the Origin ASN(s) bound to a specific IP prefix is allowed to _inject_ that IP prefix into BGP. In effect, a ROA is a (out-of-band) policy that defines the scope of a particular IP prefix as having a root of one, or more, specific Origin ASN's. The Origin ASN(s) for that IP prefix are effectively the root of a tree that _COULD_ extend outward through several dozen downstream ASN's. Today, it's the _policy_ implemented within the individual downstream ASN's that further _refine_ the scope of that announcement, by expanding or trimming the branches of the tree of downstream ASN's. Furthermore, as pointed out in the route-leaks draft, the default (out-of-the-box) behavior of vanilla BGP is for it to propagate all learned routing routing information to all parties, i.e.: BGP's default scope = global. Thus, if we're talking about changing BGP to /automatically/ restrict the 'ann ouncement scope' of a particular prefix, (or set of paths), then we seem to be talking about a fundamental change to BGP. -shane _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
