On Jan 23, 2012, at 3:31 PM, Stephen Kent wrote: > At 10:39 PM -0500 1/19/12, Eric Osterweil wrote: >> ... >> > >>> 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. > > speak for yourself :-).
Good one... > >> > 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? > > I anticipate that an operational considerations doc will be written. Great, I'd like to request that some form of complexity analysis be included (even just back of the envelope kinds of explanations). Thanks, Eric _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
