nanog mailing list archives
Re: MACsec SFP
From: Pieter Hulshoff <phulshof () aimvalley nl>
Date: Tue, 24 Jun 2014 21:27:00 +0200
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
Current thread:
- Re: MACsec SFP, (continued)
- Re: MACsec SFP Saku Ytti (Jun 24)
- Re: MACsec SFP Christopher Morrow (Jun 24)
- Re: MACsec SFP Eric Flanery (eric) (Jun 24)
- Re: MACsec SFP Pieter Hulshoff (Jun 25)
- Re: MACsec SFP Eric Flanery (eric) (Jun 25)
- Re: MACsec SFP Saku Ytti (Jun 25)
- Re: MACsec SFP Tim Durack (Jun 25)
- Re: MACsec SFP Randy Bush (Jun 24)
- Re: MACsec SFP Christopher Morrow (Jun 24)
- Re: MACsec SFP Randy Bush (Jun 24)
- Re: MACsec SFP Pieter Hulshoff (Jun 24)
- Re: MACsec SFP Aris Lambrianidis (Jun 24)
- Re: MACsec SFP Pieter Hulshoff (Jun 24)
- Re: MACsec SFP John Schiel (Jun 25)
- Re: MACsec SFP Christopher Morrow (Jun 25)
- Re: MACsec SFP Pieter Hulshoff (Jun 25)
- Re: MACsec SFP Christopher Morrow (Jun 25)
- Re: MACsec SFP Tim Durack (Jun 25)
- RE: MACsec SFP Michael O Holstein (Jun 25)
- Re: MACsec SFP Pieter Hulshoff (Jun 25)
- Re: MACsec SFP Saku Ytti (Jun 25)