Hey Bryan, Thanks a lot for the comments! My thoughts are inline:
On Nov 14, 2012, at 11:29 PM, Bryan Weber wrote: > 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? afaik, EE certs are not contained in manifests. Manifests enumerate things like EE certs, but they are separate objects (with a different cardinality). I do believe that the cardinality of EE certs is 1:1 with ROAs. Though, they are still separately managed objects and have different management overheads (like managing crypto information when reissuing, etc). > > *) 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. Well, I think by the same token, not all ASes have deployed SIA repositories, or issued ROAs yet. The goal of the document is to represent a global RPKI as prescribed. In the future, if an AS is to run its own SIA (which I believe is envisioned to be far and away be the common case), I believe it _must_ have a ghostbuster record so that RPs can tell whose Cert they are dealing with. There's no other way to (say) find the administrative contact for a routing object. > > *) 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. We only listed the repositories in the the cited presentation, but we felt it was important to include them all for completeness and to avoid bias. We were trying to be unbiased and use the numbers and measurements that the BGPSEC design team has been publicizing. I don't know what their metric was for including those measurements, but I suspect others in the wg could explain better. > > *) 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. It is, admittedly, a rough estimate, and we are totally open to other systematic measures. However, to illustrate why it is tough to find a good estimate, while some aspects of using the RIB cause this number to seem large (as you have stated), consider also that the allocation/suballocation/subsuballocation hierarchy requires resource holders to issue a chain of certificates (from holder to holder to holder). From there, a single entry in the RIB could correspond to multiple allocation objects. This would inflate the number of objects, but we didn't see an obvious/clean way to estimate this either. As such, we definitely acknowledge that this is an imperfect estimator, but we felt it was likely a good ballpark. Make sense? > > *) 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. Gotcha, thanks. > > *) Just for my own education, what are the router EE certs? In BGPSEC, each router must be able to sign each update it transmits (originates and forwards). The design team seems to have recently acknowledged that pushing a single organizational signing cert's private key to all routers in (say) a multinational AS could be a security concern. As such, each CA can/should have separate EE certs issued for routers, such that these certs have their authority delegated from an organizational CA cert. > > *) 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? Well, can you be sure that there will be no cycles in this envisioned set? I, for example, cannot be sure that an object in one repo does not point to an external repo that in turn has an object that does not point back to the original. In fact, this issue is mentioned in the RPKI arch RFC (6480) as a possibility. Nothing ever goes to plan in the Internet, so I think it is a very realistic concern. > > *) Does cache synching have to be done serially? I believe the time estimates in the presentation that we cited are actual downloads, so I believe this is using whatever the current best practices are, though I admit the details were not 100% clear to me. > > 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. Agreed. :( Eric _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
