I have quite a few questions/statements about this document. If you feel that this list is not the appropriate place to answer them please respond to me at [email protected]. Thanks.
*) Aren't the EE certs contained in the Certificate, Manifest and ROA artifacts? Should they be counted as separate items to retrieve? *) I'm not sure about the status of ghostbuster records today. Has any RIR implemented or deployed them yet? To my knowledge an RPKI repository contains CA certs with RFC 3779 extensions, manifests, CRLs and ROAs. Admittedly I am not familiar with the implementations of all of the RIRs. *) Is there any reason that ARIN's pilot is listed? The service is deprecated and the production system is live at this point. Granted it probably does not have a large volume of data yet. *) You note that "In addition, in regards to multihoming, we need one ROA and one EE certificate for each feasible origin for a prefix, yet we will only see on entry in a RIB." but on the other hand because of the maximum length in a ROA I believe that it is very difficult to surmise a relationship between the number of ROAs and the number of entries in the RIB. *) Just as a side note, combining tables 1 and 2 might make the data easier to read. In separate tables I am forced to keep find the correlated rows. *) Just for my own education, what are the router EE certs? *) Another question: should the set of interconnected repositories be considered a directed graph or a tree hierarchy? Since the certs are hierarchical shouldn't the URIs pointing to external repositories be hierarchical as well? *) Does cache synching have to be done serially? If these estimates are accurate then the I think the current expiry periods of manifests in some of the RIRs would be considered woefully inadequate. Regards, Bryan On Nov 14, 2012, at 10:47 PM, Eric Osterweil <[email protected]> wrote: > 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
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
