Re: [sidr] Key learning procedures in BGPsec?

[Eric Osterweil <[e-mail]>]

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