On Tue, 11 Mar 2008, Danny McPherson wrote:
> > On Mar 11, 2008, at 9:07 AM, Stephen Kent wrote: >> >> The proposal for dealing with stale data (as reflected in the >> manifest I-D) is to continue to use what you have. Thus the concerns >> you cite about what happens if anyone (IR or ISP) fails to publish >> data are not all valid ones. It is fair to note that new or changed >> data that is not published, or that is not fetched in a timely >> fashion, could cause ISPs to reject routes based on such changes. >> Unfortunately, without making change to BGP to carry such data, or >> providing some parallel distribution mechanism that is similarly >> timely, ... > > So to be clear, I didn't intend to propose a web of trust model, > although > after rereading my text from earlier, my point wasn't clear. I was > simply > pointing out that with a model such as what's currently proposed RIRs > would have a VERY operational role and some authority about what gets > routed and what does not. This is a fundamental change from how things > work today, where things more approximate a web of trust model - if > any. I understand that the effect of RIRs on routing will be more apparent, but I don't understand saying they have no impact today. For RIRs whose database is a comingled resource and routing database (e.g., RIPE), a billing dispute can effect the RIPE IRR which many people use in routing operations. And the whois is also frequently consulted in making routing decisions. And in any RIR, problems at the RIR level could lead to retraction of your prefix allocation and assignment to someone else. (Recall the social engineering prefix hijacking of a few years back.) That sounds to me like a pretty severe impact on what gets routed. So this might look new, but I don't see that the risk is larger. Of course, there's always the "the relying parties choose what importance to place on the RPKI" caveat. --Sandy > > -danny > > _______________________________________________ > Sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ Sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
