Pieter Hulshoff phulshof at
Tue Jun 24 19:27:00 UTC 2014

On 24-06-14 17:50, Christopher Morrow wrote:
> So.. now when my SFP in Elbonia dies I need to get a truck to Elbonia
> AND it's paired link in west caledonia? yikes. Also, is that a
> 'ybFxasasdasd' on the serial-number/key-pair-note or ybfXasdadasdsd'
> Gosh joe I'm not sure...

Obviously this solution wouldn't work for everyone, but I think for 
those people who prefer a simple unmanaged plug-and-play solution it 
would work just fine.

> Programmable seems like the way to go, provided there's a path to do
> that in the cli of the device you plugged the SFP into? (which I think
> is the hard part actually, right?)

Actually, there are many other ways to solve this. If you want unmanaged 
still, you could opt for using a key infrastructure combined with 802.1X 
EAPOL. For managed solutions, the device could be made programmable via 
I2C, in-band from the switch or even in-band from the line. We have 
several such managed smart SFPs in our portfolio, so adding such 
features to this device will not be a problem. A management channel 
however is an also added security risk, so not everybody would be in 
favour of that. No size fits all.

On 24-06-14 18:30, Christopher Morrow wrote:
> it's going to be hard to schedule a key roll then, right? I would
> expect that in most/many deployments where someone enters a 'key'
> there has to be some compliance process that includes: "And you change
> that key every X days" right? So you'll NOT want to be in a situation
> that involves coordinating a few thousand truck rolls every X months
> to have this deployed.

True, though an MKA PSK could safely be used for the life-time of a 
device. Should one want a regular key roll though, the CAK could be 
given a life-time, with a new one distributed automatically via MKA or 
EAPOL when it expires. It's also possible to set up a management command 
to do the same thing at the operator's request. Plenty of options; I'm 
trying to find out what demand there is for each to determine what 
should make our first release, and what will not. :)

Kind regards,

Pieter Hulshoff

More information about the NANOG mailing list