Hello R. On 12/07/2012 10:25 AM, Russ White wrote: > >> I think you are twisting the facts on your own convenience. > > So you're saying that the hosted RPKI system is not reliant on routing? > That it can be reached no matter whether or not routing is available? >
If by 'hosted RPKI' you are referring to the 'web page', well, the system does need the webpage to function. All repository generation and upkeep will still be running even if the webpage is DDoSed. True, you lose the ability to introduce changes while this supposed DDoS is operating, but routing will not get plastered. All hosted RPKI implementations implement a split system were this upkeep is run by servers not exposed directly to the Internet. If by 'hosted RPKI' you are referring to repository operators hosting all crypto material, yes, you are depending on routing. But, then, if you host your own CA RPs still depend on routing to fetch objects from your repo. If you put objects in the DNS, you depend on routing AND on the DNS to fetch them (that's two dependencies instead of one). RPKI repo fetch could be made fully independent from DNS by adopting something like multiple-pub-points. RPKI repositories could be massively cached by CDNs by adopting HTTP as an additional repository fetching protocol. Yet all of these depend on routing up to some point, it doesn't matter if the repos are hosted by third parties or hosted by the end users themselves. If you have a design for a distribution system which in no way depends on routing and doesn't involve the UPS guy, that'd be awesome ;) > There was, just recently, a large amount of discussion over the problems > with a DNS based system to provide origin authentication because "DNS > relies on routing, and now you're making routing rely on DNS!" Ignoring > the dependence of virtually _any_ distribution system on routing to one > degree or another, how can the same criticism not apply to a hosted RPKI > system, and the customer's ability to reach that system? > > And how does adding another system that relies on the system it's > supposed to be protecting reduce (or even "not add") complexity? > > Or am I "twisting facts to my convenience" again? > I think you're describing a dependency which is not critical and presenting it as if it were. > :-) > > Russ > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
