On Dec 6, 2012, at 5:11 PM, Eric Osterweil <[email protected]> wrote:
>> As Chris mentioned down-thread: Could you explain how these considerations >> differ from considerations around hosted services for critical services, >> e.g., DNSSEC? > > This system (and therefore, its considerations) is/are VASTLY different than > those of DNSSEC... In a lot of ways: > 1 - This repository system requires RPs to have a FULLY synchronized copy of > all objects at all times. DNSSEC does not. > a - This means all systems have to be high performing/reachable/etc. or > there begin to be problems > b - This means that global crawling must be done before computation can > be reliable > c - … DNSSEC requires you to have up-to-date information on all the things you care about. It's just that in BGPSEC, everyone cares about everything :) W.r.t. (a) -- Doesn't this argue in favor of hosting? Isn't the "all" less burdensome if there are fewer things to keep alive? I know I would rather have my web site on Dreamhost than on my on host in a colo. W.r.t. (b) -- Again, this seems to argue in favor of the hosted model, since you have to crawl fewer repos. And it's not really true that you have to crawl the whole tree before you can do anything. If you have a partial tree, then you can validate part of the ROAs. Especially if you crawl intelligently, e.g., trying to avoid missing links in a cert chain. I believe that RPSTIR does something like this. > 2 - This system's hosting model is proposing to put all of the object > generation information in a very few places (the hosted model), DNSSEC does > not (the hosting colocation coefficient in DNSSEC is vastly > different that 5, for rpki) > a - I am not even encouraged to have all my DNS zones hosted by RIRs... > I can get a registrar or hoster to do it, but I can choose from many many > options... > b - … Not sure where you're going with this. I thought you were arguing that the hosting model in general was a bad technology, which would not depend on the coefficient or which entities were doing the hosting. > 3 - The downside of borking routing is all your [connectivity] bases are > belong to us... Lots of problems exist when destinations are unreachable that > do not exist (or are semantically different) when names are unresolvable. In > short, these are very different systems, with _very_ different architectures, > with very _very_ different goals, etc. I could go on, but is this sufficient? Different services have different values for different networks. There are certainly lots of stakeholders for whom loss of DNS reachability would be as bad as loss of IP reachability, as would seem to be attested by the predominant focus in the cyber crime community on DNS hijacking rather than BGP hijacking. To be clear, I have no particular dog in this fight. I'm not even really clear on why this discussion is happening on the SIDR list, given that it's a deployment decision between an CA and its customers. --Richard _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
