On Jan 19, 2012, at 5:18 PM, Stephen Kent wrote: > At 3:07 PM -0500 1/19/12, Eric Osterweil wrote: >> ... >> >> Where "fairly large" could approximate a number that is on the order of the >> number of all BGPsec routers in the global routing system, right >> (~millions)? I would imaging that keeping a coherent cache of these keys at >> every ISP would be a major concern, no? That's potentially a huge challenge >> when you include churn, revocation, etc, right? > > It's not clear how many different router certs we will see, but I agree that > it may be substantial. it will likely be a mix of per-As and per-router > certs, spread over all of the participating ASes. > > Even if there are many fewer certs, inconsistent caches would pose a problem. > Unless we're discussing an emergency rekey for a cert, the smart procedure is > to post a new cert well before the old one expires, allowing RPs to retrieve > the new one in plenty of time.
Yeah, I agree with your comment about getting keys out ahead of time. However, with a corpus of keys that could well order in the millions, I would worry that the inherent churn and resource requirements are going to be well more than we are (or at least I was) expecting. > There is not yet an operational guidance doc for router cert management, but > I anticipate this sort of guidance will appear there. Will it include some discussion about scaling? I think this key-per-router idea could turn out to be Pandora's box. While having a key or two per AS or per prefix may allow us to use elements of today's routing system to give us some idea about how churn and dynamics _may_ look, I'm kind of worried now that we haven't properly evaluated how enormous the resource dependencies will be with per-router-keys. Are there any specific plans to write this up anywhere? Eric _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
