Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))
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 ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))
>> i don't even want to watch while you try to sell this to the vendor >> hardware folk. > > Really? Seems like it could provide opportunity for much entertainment > and talking past each other... ietf meetings are insufficient? ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))
On May 14, 2012, at 4:07 PM, Randy Bush 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. 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. Really? Seems like it could provide opportunity for much entertainment and talking past each other... W > > randy > ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))
> 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 ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))
Brewing where? (Astonishing, would like to hear more.) --Sandy From: sidr-boun...@ietf.org [sidr-boun...@ietf.org] on behalf of Montgomery, Douglas [do...@nist.gov] 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))) 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" wrote: > >On May 11, 2012, at 2:51 PM, Christopher Morrow wrote: > >> On Fri, May 11, 2012 at 2:43 PM, Randy Bush wrote: >> >>>> 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. >> >> 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' > >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 > > >> >> 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 >> ___ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> > >___ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))
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" wrote: > >On May 11, 2012, at 2:51 PM, Christopher Morrow wrote: > >> On Fri, May 11, 2012 at 2:43 PM, Randy Bush wrote: >> 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. >> >> 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' > >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 > > >> >> 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 >> ___ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> > >___ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))
On May 11, 2012, at 2:51 PM, Christopher Morrow wrote: > On Fri, May 11, 2012 at 2:43 PM, Randy Bush wrote: > >>> 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. > > 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' 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 > > 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 > ___ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))
> -Original Message- > From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of > Christopher Morrow > Sent: Friday, May 11, 2012 2:51 PM > 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). > [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. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))
On Fri, May 11, 2012 at 2:43 PM, Randy Bush wrote: >> 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. 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 ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))
>> 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 ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))
On Fri, May 11, 2012 at 12:35 AM, Randy Bush wrote: > 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'. 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. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))
> 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...). 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 ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))
At Fri, 04 May 2012 17:33:43 -1000, Randy Bush wrote: > > > 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. > > 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...). ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))
> "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]." 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 ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))
> 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. draft-ymbk-bgpsec-rtr-rekeying-00.txt, section 3. Router-Generated Keys ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))
On 05/04/2012 11:01 PM, Jakob Heitz wrote: 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. 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 ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))
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: > On Fri, May 4, 2012 at 9:37 PM, Osterweil, Eric > 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. >> > > 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) > >> Eric >> >> >> - Original Message - >> From: Chris Morrow [mailto:morr...@ops-netman.net] >> Sent: Friday, May 04, 2012 09:28 PM >> To: Osterweil, Eric >> Cc: 'sandra.mur...@sparta.com' ; >> 'da...@tcb.net' ; 'morrowc.li...@gmail.com' >> ; 'sidr@ietf.org' ; >> 'sidr-cha...@tools.ietf.org' ; >> 'sidr-...@tools.ietf.org' >> Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting >> Draft Agenda: 04-30-2012 (April 30, 2012))) >> >> >> >> On 05/04/2012 08:59 PM, Osterweil, Eric wrote: >> >>> His point is NOT addressed by any draft in the wg (since you asked). >> >> read randy's mentioned draft? ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))
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 ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))
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 - Original Message - From: Chris Morrow [mailto:morr...@ops-netman.net] Sent: Friday, May 04, 2012 10:18 PM To: Osterweil, Eric Cc: 'morrowc.li...@gmail.com' ; 'sandra.mur...@sparta.com' ; 'da...@tcb.net' ; 'sidr@ietf.org' ; 'sidr-cha...@tools.ietf.org' ; 'sidr-...@tools.ietf.org' Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) 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:morrowc.li...@gmail.com] Sent: Friday, May 04, 2012 09:54 PM > To: Osterweil, Eric Cc: > morr...@ops-netman.net; > sandra.mur...@sparta.com; > da...@tcb.net; sidr@ietf.org; > sidr-cha...@tools.ietf.org; > sidr-...@tools.ietf.org 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 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. >> > > 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) > >> Eric >> >> >> - Original Message - From: Chris Morrow >> [mailto:morr...@ops-netman.net] Sent: Friday, May 04, 2012 09:28 >> PM To: Osterweil, Eric Cc: >> 'sandra.mur...@sparta.com'; >> 'da...@tcb.net'; >> 'morrowc.li...@gmail.com'; >> 'sidr@ietf.org'; >> 'sidr-cha...@tools.ietf.org'; >> 'sidr-...@tools.ietf.org' Subject: Re: >> [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: >> 04-30-2012 (April 30, 2012))) >> >> >> >> On 05/04/2012 08:59 PM, Osterweil, Eric wrote: >> >>> His point is NOT addressed by any draft in the wg (since you >>> asked). >> >> read randy's mentioned draft? ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))
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:morrowc.li...@gmail.com] Sent: Friday, May 04, 2012 09:54 PM To: Osterweil, Eric Cc: morr...@ops-netman.net; sandra.mur...@sparta.com; da...@tcb.net; sidr@ietf.org; sidr-cha...@tools.ietf.org; sidr-...@tools.ietf.org 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 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. 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) Eric - Original Message - From: Chris Morrow [mailto:morr...@ops-netman.net] Sent: Friday, May 04, 2012 09:28 PM To: Osterweil, Eric Cc: 'sandra.mur...@sparta.com'; 'da...@tcb.net'; 'morrowc.li...@gmail.com'; 'sidr@ietf.org'; 'sidr-cha...@tools.ietf.org'; 'sidr-...@tools.ietf.org' Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) On 05/04/2012 08:59 PM, Osterweil, Eric wrote: His point is NOT addressed by any draft in the wg (since you asked). read randy's mentioned draft? ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))
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 - Original Message - From: Christopher Morrow [mailto:morrowc.li...@gmail.com] Sent: Friday, May 04, 2012 09:54 PM To: Osterweil, Eric Cc: morr...@ops-netman.net ; sandra.mur...@sparta.com ; da...@tcb.net ; sidr@ietf.org ; sidr-cha...@tools.ietf.org ; sidr-...@tools.ietf.org 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 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. > 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) > Eric > > > - Original Message - > From: Chris Morrow [mailto:morr...@ops-netman.net] > Sent: Friday, May 04, 2012 09:28 PM > To: Osterweil, Eric > Cc: 'sandra.mur...@sparta.com' ; 'da...@tcb.net' > ; 'morrowc.li...@gmail.com' ; > 'sidr@ietf.org' ; 'sidr-cha...@tools.ietf.org' > ; 'sidr-...@tools.ietf.org' > > Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft > Agenda: 04-30-2012 (April 30, 2012))) > > > > On 05/04/2012 08:59 PM, Osterweil, Eric wrote: > >> His point is NOT addressed by any draft in the wg (since you asked). > > read randy's mentioned draft? ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
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 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. > 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) > Eric > > > - Original Message - > From: Chris Morrow [mailto:morr...@ops-netman.net] > Sent: Friday, May 04, 2012 09:28 PM > To: Osterweil, Eric > Cc: 'sandra.mur...@sparta.com' ; 'da...@tcb.net' > ; 'morrowc.li...@gmail.com' ; > 'sidr@ietf.org' ; 'sidr-cha...@tools.ietf.org' > ; 'sidr-...@tools.ietf.org' > > Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft > Agenda: 04-30-2012 (April 30, 2012))) > > > > On 05/04/2012 08:59 PM, Osterweil, Eric wrote: > >> His point is NOT addressed by any draft in the wg (since you asked). > > read randy's mentioned draft? ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))
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 - Original Message - From: Chris Morrow [mailto:morr...@ops-netman.net] Sent: Friday, May 04, 2012 09:28 PM To: Osterweil, Eric Cc: 'sandra.mur...@sparta.com' ; 'da...@tcb.net' ; 'morrowc.li...@gmail.com' ; 'sidr@ietf.org' ; 'sidr-cha...@tools.ietf.org' ; 'sidr-...@tools.ietf.org' Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) On 05/04/2012 08:59 PM, Osterweil, Eric wrote: > His point is NOT addressed by any draft in the wg (since you asked). read randy's mentioned draft? ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))
On 05/04/2012 08:59 PM, Osterweil, Eric wrote: His point is NOT addressed by any draft in the wg (since you asked). read randy's mentioned draft? ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))
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:sandra.mur...@sparta.com] Sent: Friday, May 04, 2012 06:24 PM To: Danny McPherson ; Christopher Morrow Cc: sidr wg ; sidr-cha...@tools.ietf.org ; sidr-...@tools.ietf.org Subject: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) 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: sidr-boun...@ietf.org [sidr-boun...@ietf.org] on behalf of Murphy, Sandra [sandra.mur...@sparta.com] Sent: Wednesday, April 11, 2012 1:28 PM To: Danny McPherson; Christopher Morrow Cc: sidr-...@tools.ietf.org; sidr-cha...@tools.ietf.org; 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 [da...@tcb.net] 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: sidr-boun...@ietf.org [sidr-boun...@ietf.org] on behalf of Danny McPherson [da...@tcb.net] Sent: Tuesday, April 10, 2012 9:15 PM To: Christopher Morrow Cc: sidr wg; sidr-cha...@tools.ietf.org; sidr-...@tools.ietf.org 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
Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))
> 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 > idea. only if you don't think a public bath is private :) > I do not know that anyone plans to use the rpki-rtr protocol to get > 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 ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
