Subject: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))

From: "Murphy, Sandra" <[email-masked]>
Date: Fri, 4 May 2012 22:24:05 +0000

still speaking as regular ol' member

Looking back, I do not see a reply from Danny to my question below.

But the subsequent conversation reads to me like "onboard .. signing certificates" means getting the private keys routers would use for signing into the routers.

Because the below implies that the "signing certificates", i.e., private keys, would be "from the RPKI", I figure I'd better speak up.  Just in case someone actually thought that was being suggested.

Communicating the router's private keys in the RPKI would be a bad idea.

First, of course, is the confidentiality concern.  Private keys are supposed to be protected from exposure.  Creating RPKI objects where they would be protected from exposure would be hard.

Furthermore, the private keys used in the routers are strictly a local concern.  There is no need to communicate them globally.  So publishing them in the RPKI at all, even if protected, would be a poor choice.

I do not know that anyone plans to use the rpki-rtr protocol to get private keys to the router.

--Sandy, speaking as regular ol' member

________________________________________
From: [email-masked] [[email-masked]] on behalf of Murphy, Sandra [[email-masked]]
Sent: Wednesday, April 11, 2012 1:28 PM
To: Danny McPherson; Christopher Morrow
Cc: [email-masked]; [email-masked]; sidr wg
Subject: Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)

speaking as regular ol' member

On Tuesday, April 10, 2012 9:15 PM, Danny McPherson [[email-masked]] said:

>From there, we can discuss the issue of, for example, HOW TO onboard
>and purge signing and validating certificates to routers from the RPKI --
>[I suspect the intention was to use rpki-rtr protocol for this, but it doesn't
>currently support it, nor are the security implications clear].

I can not  understand your comment.  What do you mean by "signing certificates"?

I can guess that "validating certificates" means the certs carrying public keys used to validate signatures, but the "signing certificates" part has me stumped.

--Sandy

________________________________________
From: [email-masked] [[email-masked]] on behalf of Danny McPherson [[email-masked]]
Sent: Tuesday, April 10, 2012 9:15 PM
To: Christopher Morrow
Cc: sidr wg; [email-masked]; [email-masked]
Subject: Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)

On Apr 10, 2012, at 8:56 PM, Christopher Morrow wrote:

> yes, my goal was to have updated the wiki today at the office, work
> intruded... tomorrow I'll do that with some more content for each
> item, and hopefully better coordinates as well for the location.

Thanks.

>> Also, are we collecting requirements for these (e.g., object scale, RPs, etc..)?  Basing these discussions on requirements that exist somewhere already?  Or simply discussing solutions that have already been developed and deployment experience?  If the latter, then we can we ensure we reference and prepare to discuss what requirements drive to the development of those solutions?
>>
>
> I think the only bit in the 3 that has a current 'requirements'
> discussion is the 'freshness' (item 2). The first item 'deployment
> discussion' is really a discussion of:
>  "Should there be some document that describes the top N (3?)
> deployment scenarios && where should that document/presentation/etc
> live?" (I suppose implicit in that is 'requirements for format,
> content, intended audience')

I was thinking more simply along the lines of "a fully deployed RPKI today would have o objects and r RPs a c churn and we ought to ensure our designs accommodate that" -- only then can we have a reasonable discussion on, e.g., data freshness?  What have we based these design goals on thus far - do we have a stable reference for this?

>From there, we can discuss the issue of, for example, HOW TO onboard and purge signing and validating certificates to routers from the RPKI -- [I suspect the intention was to use rpki-rtr protocol for this, but it doesn't currently support it, nor are the security implications clear].

Only when we get to that point will we really begin to understand the dynamics of RPKI and it's employment for secure routing (well beyond "authorized" origin policy configuration), and the impact of rate+state in both the RPKI and it's effectuating in the routing system, and perhaps most importantly, the inter-dependencies between the two (even basic stuff like the rate of updates from an RPKI cache to a router in a fully loaded system given today's RPKI object counts).

>> Also, it looks to me like we're in dire need of a charter update...
>
> for which? (I didn't think that any of the 3 items was actually
> outside of the current charter)

I meant the goals and milestones, apologies for not being clear.

-danny
_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: Randy Bush <[email-masked]>
Date: Fri, 04 May 2012 14:10:31 -1000

> But the subsequent conversation reads to me like "onboard .. signing
> certificates"

i can not find 'onboard' used as a verb in any rfc.  so anything is a
guess.

> means getting the private keys routers would use for signing into the
> routers.

try draft-ymbk-bgpsec-rtr-rekeying-00.txt, which i thought was asked to
be adopted by the wg.  probably my screw-up.

> Communicating the router's private keys in the RPKI would be a bad

only if you don't think a public bath is private :)

> private keys to the router.

this is the ietf.  i am fairly sure someone does.  i just think they
would be extremely ill-advised to do so.

randy

---

From: "Osterweil, Eric" <[email-masked]>
Date: Sat, 5 May 2012 00:59:41 +0000

He Sandy,

Speaking just as a regular ole wg member:

The issue Danny alluded to is NOT private keys in rpki. It is the fact that the specs imply that routers that need to sign updates ON BEHALF OF ASES need to do so with private keys that have been vouched for. But getting these private keys "onboard" routers that lie across (for example) foreign borders can be an operational nonstarter. For ex, if my router's key needs to be voched for but its private portion (that signs updates) is sent over a medium in which it can be intercepted, then how can I trust the signatures from it. Conversely, if I cannot securely get my private keys onto my routers across potentially hostile borders, how can I expect them to sign my AS' updates?  

His point is NOT addressed by any draft in the wg (since you asked).

Hth,

Eric

----- Original Message -----
From: Murphy, Sandra [mailto:[email-masked]]
Sent: Friday, May 04, 2012 06:24 PM
To: Danny McPherson <[email-masked]>; Christopher Morrow <[email-masked]>
Cc: sidr wg <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))

--Sandy

Thanks.

-danny

---

From: Chris Morrow <[email-masked]>
Date: Fri, 04 May 2012 21:28:32 -0400

> His point is NOT addressed by any draft in the wg (since you asked).

read randy's mentioned draft?

---

From: "Osterweil, Eric" <[email-masked]>
Date: Sat, 5 May 2012 01:37:53 +0000

Hey Chris,

Yeah, I read that. I know there's a tendency for some people to want to talk about bath houses on this list, but I was going to pass on that.

As for draft-ymbk-bgpsec-rtr-rekeying-00.txt, that draft just points out the inadequacies of either approach and that there is no good solution. My take is that this is indicative of a misalignment between a given architecture and implicit requirements. Sometimes you can't patch the holes in a leaky ship, you need to reassess the requirements. I think the evidence illustrates that this is the case here.

Eric

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 4 May 2012 21:54:05 -0400

> As for draft-ymbk-bgpsec-rtr-rekeying-00.txt, that draft just points out the inadequacies of either approach and that there is no good solution. My take is that this is indicative of a misalignment…

it seems to me that putting key-material on a distant router is done
today... isn't it? or are you saying that how you do it today leaves
you feeling icky, and you'd rather another method be devised?

Could you outline a possible method? (provide a solution, for instance)

---

From: "Osterweil, Eric" <[email-masked]>
Date: Sat, 5 May 2012 02:06:42 +0000

Hey Chris,

The implications of putting signatures on updates that are both globally visible/verifiable and implicitly give object-level security to updates is WAY different than the semantics of the keying done today.  The implications of the scope of these keys puts them in a much different role.  I was assuming that was clear, but maybe not?

Eric

---

From: Chris Morrow <[email-masked]>
Date: Fri, 04 May 2012 22:18:39 -0400

On 05/04/2012 10:06 PM, Osterweil, Eric wrote:
> Hey Chris,
>
> The implications of putting signatures on updates that are both
> globally visible/verifiable and implicitly give object-level security
> to updates is WAY different than the semantics of the keying done
> today.  The implications of the scope of these keys puts them in a
> much different role.  I was assuming that was clear, but maybe not?

I think we're talking about 2 different (at least) things...

> Eric
>
>
> ----- Original Message ----- From: Christopher Morrow
> [mailto:[email-masked]] Sent: Friday, May 04, 2012 09:54 PM
> To: Osterweil, Eric Cc:
> [email-masked]<[email-masked]>;
> [email-masked]<[email-masked]>;
> [email-masked]<[email-masked]>; [email-masked]<[email-masked]>;
> [email-masked]<[email-masked]>;
> [email-masked]<[email-masked]> Subject: Re: [sidr]
> RPKI and private keys (was RE: Interim Meeting Draft Agenda:
> 04-30-2012 (April 30, 2012)))
>
> On Fri, May 4, 2012 at 9:37 PM, Osterweil,
> Eric<[email-masked]>  wrote:
>> Hey Chris,
>>
>> Yeah, I read that. I know there's a tendency for some people to
>> want to talk about bath houses on this list, but I was going to
>> pass on that.
>>
>> As for draft-ymbk-bgpsec-rtr-rekeying-00.txt, that draft just
>> points out the inadequacies of either approach and that there is no
>> good solution. My take is that this is indicative of a misalignment
>> between a given architecture and implicit requirements. Sometimes
>> you can't patch the holes in a leaky ship, you need to reassess the
>> requirements. I think the evidence illustrates that this is the
>> case here.
>>
>
>> ----- Original Message ----- From: Chris Morrow
>> [mailto:[email-masked]] Sent: Friday, May 04, 2012 09:28
>> PM To: Osterweil, Eric Cc:
>> [email-masked]'<[email-masked]>;
>> [email-masked]'<[email-masked]>;
>> [email-masked]'<[email-masked]>;
>> [email-masked]'<[email-masked]>;
>> [email-masked]'<[email-masked]>;
>> [email-masked]'<[email-masked]> Subject: Re:
>> [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda:
>> 04-30-2012 (April 30, 2012)))
>>
>>
>>

---

From: "Osterweil, Eric" <[email-masked]>
Date: Sat, 5 May 2012 02:30:26 +0000

Well, when u compared the key mgmt that is done today w/ the key mgmt that will need to be done with bgpsec keys on routers, I think there was an strained analogy. I'm talking about the latter, but I was trying to indulge the discussion. ;) 

Eric

---

From: Chris Morrow <[email-masked]>
Date: Fri, 04 May 2012 22:57:56 -0400

On 05/04/2012 10:30 PM, Osterweil, Eric wrote:
>
>
> Well, when u compared the key mgmt that is done today w/ the key mgmt
> that will need to be done with bgpsec keys on routers, I think there
> was an strained analogy. I'm talking about the latter, but I was
> trying to indulge the discussion. ;)

tis late on a friday... and this has a tiny screen... but:

I was under the impression that Danny was originally asking about how to 
get the AS or ROUTER key material (used to sign updates as the pass by) 
onto the device in question.

Take for example a router of in the disputed territory of crapinderburg:
  1) you either shipped a device with a person to install it (or a 
person with secure comms and a router arrived separately)
  2) that person would install the requisite cert material/key at 
installation time.

Alternately that person does basic config (or the device is drop-shipped 
with basic config) and a remote/NOC/automation-job does the rest over a 
secure (I hope) channel, ie: ssh/scp. This would include installing the 
cert/key on the device (in some form of protected storage)

There was mention in danny's note of 'the rpki distribution system...' 
and both sandy and I (and randy?) noted that the rpki-to-rtr (or like) 
protocol was never meant to handle this sort of thing, that other normal 
router configuration/management systems were meant to do it.

Are we crossed up on the rpki-rtr vs 'other means' discussion currently?

For reference, here's danny's quote that got the crossed up conversation 
started:

"From there, we can discuss the issue of, for example, HOW TO onboard
  and purge signing and validating certificates to routers from the RPKI
  [I suspect the intention was to use rpki-rtr protocol for this, but it
doesn't currently support it, nor are the security implications clear]."

-chris

---

From: Jakob Heitz <[email-masked]>
Date: Fri, 4 May 2012 23:01:59 -0400

Might it be possible to create the key pair on the router?
Then you don't have to move the private key to the router,
You move the public key off the router. Much easier.

-- 
Jakob Heitz.

On Friday, May 04, 2012 6:54 PM, Christopher Morrow <> wrote:

>> Yeah, I read that. I know there's a tendency for some people to want
>> to talk about bath houses on this list, but I was going to pass on
>> that.  
>> 
>> As for draft-ymbk-bgpsec-rtr-rekeying-00.txt, that draft just points
>> out the inadequacies of either approach and that there is no good
>> solution. My take is that this is indicative of a misalignment
>> requirements. I think the evidence illustrates that this is the case
>> here.      
>> 
> 
>> Cc: [email-masked]' <[email-masked]>;
>> [email-masked]' <[email-masked]>; [email-masked]'
>> <[email-masked]>; [email-masked]' <[email-masked]>;
>> [email-masked]' <[email-masked]>;
>> [email-masked]' <[email-masked]>    
>> Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting
>> Draft Agenda: 04-30-2012 (April 30, 2012))) 
>> 
>> 
>>

---

From: Chris Morrow <[email-masked]>
Date: Fri, 04 May 2012 23:04:49 -0400

> You move the public key off the router. Much easier.

you could, but I presume the thing being created is really a cert 
(ee-cert) and is signed by the 'as-cert' that is published in the RPKI 
so folk can say:
This route I see, is signed by bloof123 which is signed by bloof-asn - 
that looks like AS123's cert, and the sig is in the place where AS123 is 
supposed to be"

So, you'd need to effectively (I think) do a CSR, send that to the CA 
for signing, and off back with the actual Cert to the device.

-chris

---

From: Randy Bush <[email-masked]>
Date: Fri, 04 May 2012 17:33:43 -1000

> You move the public key off the router. Much easier.

draft-ymbk-bgpsec-rtr-rekeying-00.txt, section 3. Router-Generated Keys

---

From: Randy Bush <[email-masked]>
Date: Fri, 04 May 2012 17:46:54 -1000

>  doesn't currently support it, nor are the security implications clear]."

it is very hard to understand this, but this is my guess.

certificates do not sign, keys do, and not the public keys which are in
the certificates, but the corresponding private keys.

the public keys used to validate bgpsec signatures are in router ee
certs in the rpki.  indeed some of the router ee cert's data will need
to be in validating routers.  indeed there currently is no specification
for how this is done.  indeed, the rpki-rtr protocol could be extended
to do this, should be trivial.

but, until we have the bgpsec protocol nailed down a bit further, this
would be premature.

and i have said this at least once before, though possibly in private
email to danny.

randy

---

From: Rob Austein <[email-masked]>
Date: Thu, 10 May 2012 22:54:31 -0400

> draft-ymbk-bgpsec-rtr-rekeying-00.txt, section 3. Router-Generated Keys

Which notes that a (the?) main reason for even considering anything
other than router-generated keys is that router-generated keys are
somewhat problematic in hot swap scenarios.  After thinking about this
a bit, I'm not sure I really believe in the hot swap issue as
described.  Do we really care which router key is used to sign, so
long as the router key in question is certified properly so that
relying parties can verify the binding between key and signing AS?

So I suspect one could make the router-generated model work well.  One
just has to plan for it (certify router keys from both the live and
hot spare routers) or accept that there will be some cut-over time if
one fails to plan (or if one's plans fail...).

---

From: Randy Bush <[email-masked]>
Date: Thu, 10 May 2012 18:35:44 -1000

> one fails to plan (or if one's plans fail...).

at 2am, they always fail.  heck, they fail at 2pm.  and one often has to
fly one in from depot or vendor.  at up to $200k each, it's not like a
spare re is sitting next to each chassis.  and what spare stash facility
would have an on-net chassis to plug in send up a genned key?  and for
which AS-router-id?

would be interestd to hear from other ops if they believe they could get
the folk managing spares to pre-key in a useful way.

i was not comfortable, so we wrote up both.  glad to be wrong.

randy

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 11 May 2012 13:15:57 -0400

> the folk managing spares to pre-key in a useful way.

no way that'll happen 'reliably'. though I contend you have time
between 'card fail' and 'router back to normal' to ship a key in the
ether/ssh to the device too.

---

From: Randy Bush <[email-masked]>
Date: Fri, 11 May 2012 08:43:49 -1000

>> would be interestd to hear from other ops if they believe they could
>> get the folk managing spares to pre-key in a useful way.
> no way that'll happen 'reliably'.

agree

> though I contend you have time between 'card fail' and 'router back to
> normal' to ship a key in the ether/ssh to the device too.

by the time the replacement re is sufficiently on net to create and send
a public key to the noc for signing and publishing, the router is up and
has at least some routing data.  so the subsequent publication delay
would be a critical path delay (in the pert sense) to full, i.e. bgpsec,
use.

randy

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 11 May 2012 14:51:00 -0400

> would be a critical path delay (in the pert sense) to full, i.e. bgpsec,

hrm, so... normally something like this happens:
  1) router go boom
  2) troubleshooting ensues to see where the problem is (what to fix)
  3) RE/RSP is determined to be at fault
  4) spares call placed
  5) spare arrives and is placed into the chassis
  6) reboot/checkout happens
  7) customer links brought back online
  8) things return to 'normal'

I think that at 1 all routing stops (or enough stops that you stop it
all anyway).
I think that at 6 you are in a state where at a minimum the router has
core-facing connectivity and you are placing the config back on the
device + relevant other bits (the key in question).

So... I agree you can make a key locally, you can ALSO probably just
re-ship the current stored-in-a-safe key to the device, because you've
got an extra 10 seconds for a complete new SSH session to come up/down
while scp'ing the file-o-key-material to the remote device.

-chris

---

From: "George, Wes" <[email-masked]>
Date: Fri, 11 May 2012 15:14:37 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Christopher Morrow
> Sent: Friday, May 11, 2012 2:51 PM
> I think that at 1 all routing stops (or enough stops that you stop it all anyway).
>
[WEG] How prevalent is this scenario going to be in the hardware of sufficient burliness and shiny newness to manage BGPSec in the first place? Isn't it far more likely that the router going boom because of an RE/RP problem is a transient while it switches to the backup, and the sync of the config between primary and backup includes syncing the keys? (and replacing the spare is now only to restore full redundancy)
I do think that it's fair to know what the scenario looks like if you have a router that actually does go totally Tango Uniform and has to be resuscitated from spares including rebuilt configs and pushing keys, but I'm thinking that if it's a little more complex, that's not as big of a deal because of the fact that it's likely to be less common.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 14 May 2012 10:37:24 -0400

>  8) things return to 'normal'

So, what if[0] the keying material itself is stored in a small EEPROM on the chassis (well, backplane) itself?

The number of times the backplane fails pales in comparison to the number of RE / line-card failures, and many (most?) architectures already have an I2C EEPROM on the [back|mid]plane.
A 1Mb I2C EEPROM costs around ~$1.35 (or ~$0.60 more than a 8Kb).

Yes, you still have the "OMG, my chassis just caught on fire" problem, but this should (hopefully!) happen much much less often then "OMG, my RE just tossed it's RAM | HDD | CF, etc".
This would allow you to just pull the old RE and slap in a new one and have things "Just Work".

Yes, we are way down in the weeds of vendor / implementation stuff, but I guess my point is that, having an RE fail (not uncommon) doesn't *need* to mean having to roll keys.

W

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Mon, 14 May 2012 11:33:48 -0400

Work is brewing for BIOS authentication in network devices .... While not
exactly the same thing, it will require a trusted key store in ROM.
-- 
Doug Montgomery  Mgr. Internet & Scalable Systems Research / ITL / NIST

On 5/14/12 10:37 AM, "Warren Kumari" <[email-masked]> wrote:

>The number of times the backplane fails pales in comparison to the number
>of RE / line-card failures, and many (most?) architectures already have
>an I2C EEPROM on the [back|mid]plane.
>Yes, you still have the "OMG, my chassis just caught on fire" problem,
>but this should (hopefully!) happen much much less often then "OMG, my RE
>just tossed it's RAM | HDD | CF, etc".
>Yes, we are way down in the weeds of vendor / implementation stuff, but I
>guess my point is that, having an RE fail (not uncommon) doesn't *need*
>to mean having to roll keys.
>
>W
>
>
>>

---

From: "Murphy, Sandra" <[email-masked]>
Date: Mon, 14 May 2012 15:55:27 +0000

Brewing where?  (Astonishing, would like to hear more.)

--Sandy

________________________________________
From: [email-masked] [[email-masked]] on behalf of Montgomery, Douglas [[email-masked]]
Sent: Monday, May 14, 2012 11:33 AM
To: Warren Kumari; Christopher Morrow
Cc: Rob Austein; sidr wg list
Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))

---

From: Randy Bush <[email-masked]>
Date: Mon, 14 May 2012 10:07:55 -1000

> The number of times the backplane fails pales in comparison to the
> number of RE / line-card failures, and many (most?) architectures
> already have an I2C EEPROM on the [back|mid]plane.  A 1Mb I2C EEPROM
> costs around ~$1.35 (or ~$0.60 more than a 8Kb).

i don't even want to watch while you try to sell this to the vendor
hardware folk.

randy

---

From: Warren Kumari <[email-masked]>
Date: Mon, 14 May 2012 17:17:08 -0400

> i don't even want to watch while you try to sell this to the vendor

Really? Seems like it could provide opportunity for much entertainment and talking past each other...

W

---

From: Randy Bush <[email-masked]>
Date: Mon, 14 May 2012 11:18:06 -1000

> and talking past each other...

ietf meetings are insufficient?

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 15 May 2012 11:27:15 +0200

Not replying to anyone in particular here.. 

I just want to say though that this exporting of keys of routers makes me nervous. I think this will degrade the level of trust that people can place in bgpsec, and therefore I think it's not a good idea to include this in the standards.

I understand that this may mean that in certain failure scenarios people will find that they haven't provisioned replacement routers.

To this I would say:
- BCP should be to provision new hardware in advance, eg upon installation. A well documented and simple way to get CSRs out of the router would be useful here.
- The rpki repository and fetch mechanisms should be improved to support propagation of new router certs to RPs in hours max. (not days). It should also support a potentially large number of router certs (just like it should be able to support 500k ROAs).
- I think that bgpsec validation semantics should support 'graceful' degradation where an AS may sign some, but not all, updates if they come from different hardware. I think this is also needed for initial, incremental, deployment.

Tim