Hey everyone, A couple of us have done some quick back-of-the-envelope style calculations to help get an idea of what a global deployment of RPKI (supporting a global BGPSEC deployment) might look like, if we were to be able to deploy it. We've written up our methodology, evaluation, and findings in a short little tech-note here: http://techreports.verisignlabs.com/tr-lookup.cgi?trid=1120005
What we tried to do was calculate an extreme _lower_bound_ on what the overall gather/fetch times might be for a cache trying to gather a fully deployed RPKI repository. This seemed to be particularly opportune moment to raise this topic, re: some comments recently posted in the thread, ``Re: [sidr] additions and changes to agenda on Friday:'' > 1) size of a single repository (pick a large ISP as a for-instance, > some one like L3 who has ~30k customers, each with 5 routes average x2 > for keyroll situations? - or better yet, make up your own set of > numbers, document them and the reasoning why) > 2) number of repositories in existence (say, number of ASN in the > global table, or ...) > 3) re-fetch times of every repository (3 hrs for instance for any > object type?) > 4) average network latency from fetcher to fetchee (~150ms for instance) > > document that and then start looking at tradeoffs and consequences? What we found is that by creating a _systematic_ estimate of what a global RPKI would look like, we wind up with roughly 1.5 million objects (we explain why we feel this is a large _underestimate_ in the tech-note), and in order to ensure that all caches have received updated information (such as getting new certificates/CRLs/etc disseminated), repositories may have to wait about a month (roughly 32 days by our estimates), just for gatherers to reliably pick up a repo's changes. Or, a month before a key compromise might get remediated throughout the RPKI system. Our sincere hope is that this tech note will be a living document. To that end, comments, corrections, and feedback are very welcome. Eric _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr