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: [email protected] [[email protected]] on behalf of Eric Osterweil 
[[email protected]]
Sent: Thursday, January 19, 2012 3:07 PM
To: Stephen Kent
Cc: [email protected] 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
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr

Reply via email to