Re: [sidr] Key learning procedures in BGPsec?

About your "all BGPSEC routers in the global routing system" - keep in mind that the ebgp routers are the ones that need a private key, not all the routers in an AS.

While we have a lot of info on churn in routing updates, I am not certain how to predict how much church there will be in the keys assigned to routers.

To those who operate networks:
can you mention an order of magnitude of the number of e-bgp routers you have?
can you mention how often you re-key your routers, for whatever secure communication you ordinarily  use with the routers?  (I presume without proof that operators typically secure the communications to their routers and must already be doing key management.) 

--Sandy

________________________________________
From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Eric Osterweil [eosterweil@verisign.com]
Sent: Thursday, January 19, 2012 3:07 PM
To: Stephen Kent
Cc: sidr@ietf.org list
Subject: Re: [sidr] Key learning procedures in BGPsec?

On Jan 18, 2012, at 2:41 PM, Stephen Kent wrote:

> At 6:36 PM -0500 1/17/12, Eric Osterweil wrote:
>> ...
>> 2 - How do we envision the process of an AS getting its own private key information installed on all of its routers?*  Without _these_, updates cannot be signed...
>
> BGPSEC allows for a per-AS key pair or a per-router key pair.or anything
> in between. Thus, if an AS has routers in locations that the AS operator considers physically insecure, it can choose to have those routers be individually keyed, while having a shared key pair for other routers.
>
> Yes, this design may require routers to have access to a fairly large number of PUBLIC keys for routers/ASes.

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?

Eric
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr