Sandy, Thank you for responding! Please see below.
On Feb 23, 2011, at 13:26 MST, Sandra Murphy wrote: >> Can you clarify what you mean by "the sidr work to date has not formally >> bound the route origin ... and [is] easily spoofed"? > > This is something that has been mentioned in the wg many times, so I'll > answer. > > It is quite easy for an AS to construct an AS_PATH with the legitimate > authorized origin on the origin end, without every having received such an > announcement from the origin. Without the legitimate origin ever having > actually made the announcement to anyone, even. > > That's why path validation is important. You really would like some > assurance that the origin actually announced the prefix *and* announced it to > the party that appears tp have propagated it onward. Let's deconstruct this a little further to see if we can be more clear on the reqmt's, (which feeds into the re-charter, etc. discussions). Fundamentally I think it comes down to this: What is the routing scope for which SIDR intends to provide AS_PATH 'authorization'? The reason I'm asking is, operationally, the more certain I can be of that 'authority' the more inclined/obligated I will be to impose, say, AS_PATH filtering based on that 'authority' to accept or drop those prefixes in my routers. Alternatively, if we're just signing AS_PATH's, but don't know how to operationally use (or, it's too difficult/burdensome to use) those AS_PATH signatures at, for example, a certain routing scope/distance ... then, why bother imposing those signatures beyond a certain routing scope in the first place (increasing cost/complexity of the routers and Ops in the process)? Specifically, what you've described above (I believe) only refers to just the _origin_ of a particular announcement -- not a 'signature' over the complete AS_PATH or a signature for each ASN in an entire AS_PATH. I described my understanding of "origin" in my previous e-mail in this thread, namely: a given [customer] ASN (AS_A) expresses its intent to announce prefixes from that ASN to a set of _immediately_ adjacent (directly-connected) transit providers and/or peers. Again, just for the purposes of drawing an analogy to something I'm already familiar with, this would be similar to what ASN's do today with IRR 'aut-num' objects by expressing their import & export policies to immediately adjacent ASN's. Given this has already been done in the IRR, for dozens of years, with aut-num objects means it should be straightforward to have a similar concept in the RPKI. I'd also add that the benefit of this approach is that the origin ASN, AS_A, knows first-hand (based on contract ual policy) to which [upstream] transit-providers or peers it *potentially*[1] should or should not be announcing sets of routes to. More importantly, capturing/recording this "adjacency" information is already part of the 'work-flow' that we do today, in the IRR world, when turning up (or, turning down) a particular [customer] neighbor ASN. (Adding the RPKI bits to the workflow will add more time and steps to that process, but the "process" is already there). If this is _all_ the current charter text and reqmt's draft is intended to capture, I can start to look at refining those from this PoV. (And, you can ignore the rest of this e-mail :-). That said, I'm still very worried about _whether_ or how we are going to handle the case of, for example, spoofing and/or hiding ASN'es in the case of 'local-as' and 'private-as' that are used extensively on these directly adjacent connections (to facilitate faster integrations of networks during M&A). OTOH, once we go beyond AS_A's immediately adjacent ASN's (routing scope with AS_PATH of length > 2 -- IOW, the upstream peer/transit-provider's neighbors), this is where I really question if any 'value' can be derived from a complete, end-to-end AS_PATH signature (or, seeing a signature on each ASN in the AS_PATH). More specifically, I mean that I (and, other operators) not only could, but _will_ construct off-line AS_PATH filters and push them to my routers (or, my future routers with 'majik' crypto-assist can directly do the same thing themselves) where I would be able to _reliably_ make a decision on whether to accept or deny prefixes coming from peers with a _completely_ signed AS_PATH. As one extreme example, is it *really* operationally feasible to impose a filter of all possible AS_PATH's that UUnet *could* send to me, for all their customers (plus, customers of customers, etc., etc. -- including all of the prepending variations that may exist) on all of the eBGP se ssions that I have with AS701 and not have it be out-of-date half-way through uploading it on my routers? >> I thought the entire goal of the RPKI and, more importantly, the objects >> that it holds attest to the 'authorization' to originate a route? In >> particular, I refer to the following in Section 3.1 of >> http://tools.ietf.org/html/draft-ietf-sidr-arch-12: > > Authorization yes but not authentication. > > You know the origin AS is authorized to announce the prefix but you don't > know that the announcement is authentic. Any other AS could produce a route > that looks like the legitimate origin made the announcement when they did not. > > When this is pointed out, I always remind people: > > Even though origin authorization is not the end game, it is a vital necesary > crucial important first step without which nothing else could succeed. Right. I get that based on past discussions surrounding the "liability", (and/or amount of work), to verify the authenticity of an organization and their associated objects. That said, I applaud Randy putting forward the "ghostbusters" draft to reveal the identify of the "authorized" party associated with the RPKI objects they hold in order to make it possible for operators to find out who the heck is behind a set of RPKI objects. > I.e., we are not wasteing our time here. I'm just trying to make sure I'm on the same page wrt getting the reqmt's straight in order that when solutions start appearing I can clearly explain to my internal developers and end-users/customers what they are, and are not, intended to solve for. Thanks again, -shane [1] I say "potentially", because there are, for example, both standard and proprietary BGP TE communities, (such as NO_EXPORT), that allow customers to selectively suppress, prepend or de-preference routes that limit a prefixes routing scope ... but, those have nothing to do with the AS_PATH attribute. > --Sandy > > >> ---snip--- >> A ROA is an attestation that the holder of a set of prefixes has >> authorized an autonomous system to originate routes for those >> prefixes. A ROA is structured according to the format described in >> [ROA-FORM]. The validity of this authorization depends on the signer >> of the ROA being the holder of the prefix(es) in the ROA; this fact >> is asserted by an end-entity certificate from the PKI, whose >> corresponding private key is used to sign the ROA. >> ---snip--- >> >> Perhaps there's a subtle _security_ nuance that I'm missing in your >> statement? >> >> Thanks, >> >> -shane _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
