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
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
