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" <war...@kumari.net> wrote: > >On May 11, 2012, at 2:51 PM, Christopher Morrow wrote: > >> On Fri, May 11, 2012 at 2:43 PM, Randy Bush <ra...@psg.com> 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
