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
