On Dec 6, 2012, at 5:42 PM, Richard Barnes wrote: > 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 :)
Uh... big difference. DNSSEC doesn't require you to care about anything before you need it (on demand). RPKI is prefetching... I can't really outline the architectural difference better than that. > 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. Nope, it doesn't. It actually points out that hosting's myopic benefits are fools-gold, and they come with a much more dangerous price tag. Your choice of dreamhost is a _choice_, not a mandate from a set of 5 options. Fundamentally different. > W.r.t. (b) -- Again, this seems to argue in favor of the hosted model, since > you have to crawl fewer repos. Again, I fear you've missed the point. This points out that there is a _fundamental_flaw_ in the architecture. You inherit the instability and latency of all hosted environments all over the world, and you are captive until it is resolved. This is an architectural issue. > 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. So, if I need _you_ (an RP) to get my ROA because I've just come under attack, do you think it's OK to just schedule me for later? That's not going to help you reach the critical services that I might be offering. I'd call that, seriously suboptimal engineering. ;) Architecturally, it would be better to reach out for information when you need it... In fact, that's kinda how other name mapping systems that you might have mentioned earlier do it... ;) > 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. I am, and it doesn't. I was, and am, illustrating for you how inapt the comparison is. > 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. Sorry, a quick look at my dayjob might inform you of the fact that I put a high price on the importance of DNS... ;) That said, I have to say that the cybercime analogy is pretty weak. How about, the angle where cyber criminals DDoS a company and they come to someone (maybe us?) for DDoS remediation _through_BGP_? That work fer ya? ;) > 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. This is a deployment discussion about the rpki infrastructure, which has quite a bit to do w/ sidr. Eric _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
