Re: [sidr] Key learning procedures in BGPsec?

[Eric Osterweil <[e-mail]>]

Hey Sriram,

On Jan 18, 2012, at 8:42 AM, Sriram, Kotikalapudi wrote:

>> For that matter, what do people think about the issue that a private key 
>> could simply be covertly extracted from an AS' routers that are deployed 
>> in far off lands?  Wouldn't this kind of compromise be a terrifying security 
>> threat to most ISPs?  
> 
> Eric,
> 
> We (BGPSEC document authors) had considered this problem.
> It is mitigated by having 'Key per Router' as discussed in:
> http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-01#section-4.5
> 
> 4.5.   Key Per Router (Rouge Router Problem)
> 
> 4.5.1.  Decision
> 
>   Within each AS, each individual BGPSEC router can have a unique pair
>   of private and public keys.
> 
> 4.5.2.  Discussion
> 
>   If a router is compromised, its key pair can be revoked
>   independently, without disrupting the other routers in the AS.  Each
>   per-router key-pair will be represented in an end-entity certificate
>   issued under the CA cert of the AS.  The Subject Key Identifier (SKI)
>   in the signature points to the router certificate (and thus the
>   unique public key) of the router that affixed its signature, so that
>   a validating router can reliably identify the public key to use for
>   signature verification.

Indeed, I knew about this (and even remember a NANOG discussion about it in Denver, I think).  I mentioned one of my concerns surrounding this in an email, just moments ago: 
1 - I think this could lead to quite a lot of state that consuming routers need, in order to verify any possible updates received from an AS.  In the previous email, I gave a more detailed response.
- but also -
2 - If there is such a compromise, how is it addressed?  In order to get a new key in there, does someone need to send a whole new router to replace the old one?  Do we envision putting sensitive private key info on some kind of electronic media and sending it via FedEx, etc?
3 - If new key material is to be shipped in to the same location that the last one was compromised in (in a new router, on a CD, or whatever) aren't we just putting the new key signing materials in the same not-so-secure-environment, and should we give some thought to how easy it might be to extract this information from a router?

> 
> Sriram
> 
> P.S. In case you had not seen the cited document
> (draft-sriram-bgpsec-design-choices) before,
> it is a design rationale discussion document and is a companion to
> draft-lepinski-bgpsec-protocol-00.txt (our initial individual draft submission).

Yeah, I did see this.  I guess I was hoping that there was some kind of discussion text, intuition, or an explanation of the intricacies that are inherent to this proposition (re: the comments I made above and in the last few emails).  THanks for the pointer though.  I'll re-read this draft's diffs (as I see it's been updated since Taipei), thanks! :)

Eric