On Wed, Mar 21, 2012 at 11:32 AM, Shane Amante <[email protected]> wrote: > 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 'announcement scope' of a particular prefix, (or set of paths), > then we seem to be talking about a fundamental change to BGP.
but we're not... you can still decide to ignore the origin information and signature information. you COULD decide to check origins and simply remark internally (with a community say) about the status of that origin authentication. You could decide, internally, to simply mark with a community the routes which fail (in several forms) path validation. -chris > -shane _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
