Re: [sidr] Key learning procedures in BGPsec?

About #1:

ROAs are used for origin validation.  (*) The bgpsec router needs only the prefix-AS binding in the ROA, not the crypto part, and only for the origin validation, not the signature attribute validation.  The rpki-rtr protocol is one way to communicate that binding.  

The bgpsec signature attribute validation does need the public keys that are used to validate the signatures.  (And the binding to an AS - see previous message.)  But it is the nature of the public part of a public/private key pair that security concerns are lower for communicating that part of the pair and exposure is no concern.

--Sandy

(*)(Years ago Geoff corrected me about calling ROAs "certs" and I've remembered the lesson. They're just signed objects, not certs.)

________________________________________
From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Eric Osterweil [eosterweil@verisign.com]
Sent: Tuesday, January 17, 2012 6:36 PM
To: sidr@ietf.org list
Subject: [sidr] Key learning procedures in BGPsec?

Hey everyone,

I was walking through the thought exercise of figuring out how BGPsec might be planning to do its crypto key learning (which I see as a two pronged problem that I outline below), and I couldn't seem to find any clear text on this matter in the current drafts.  I think I'm up to date on most of the drafts, but perhaps not?  Can someone point me to the the treatises that clarify:
1 - How are routers in BGPsec going to learn and onboard the crypto certs (ROAs/AOAs/xOAs?) needed to verify the routing updates that they receive from peers?  These certs are clearly going to need to be maintained and updated somewhere in each router's extended memory hierarchy, right?  Without these, updates from other ASes can not be verified...
- and -
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...

*Note: I think this is a subtle, but very critical issue.  If we consider (for example) that multinational ASes have routers all over the world, and that these routers need to be upgraded/replaced/etc sometimes, and that the ASes' private keys are essentially critical secrets (which also will change periodically), then how do we envision addressing the _ongoing_ issue of getting private keys onto routers in faraway places?  For instance, we wouldn't press a private key onto a CD, give it to a FedEx delivery person, and then let it work its way through customs in a foreign country that may (or may not) host entities with a vested interest in acquiring or intercepting such a critical enabling secret, right?  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?  afaict, this threat directly
 elevates the importance the vulnerability period that comes between compromise, detection, revocation/reissuing, and the lag that occurs until other routers throughout the routing system learn of the changes to certs.   fwiw, I don't think we can punt on this and claim it is anything other than a first order architectural issue, because of the online nature of BGPsec's signing process.

That said, I'm really hoping that I've just missed/misread some text that addresses these issues.  If that's the case, please forgive the rambling noise, and tia for the pointers... :-}

Eric

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