On Tue, Jun 24, 2014 at 9:59 AM, Pieter Hulshoff <phuls...@aimvalley.nl> wrote: > On 24-6-2014 15:50, Christopher Morrow wrote: >> >> On Tue, Jun 24, 2014 at 3:59 AM, Pieter Hulshoff <phuls...@aimvalley.nl> >> wrote: >> >>> features they should have. I'll then try to build a business case to get >>> the >>> product developed. MACsec is currently on the top of my own list, but >>> I'll >>> gladly pass other ideas to my colleagues. >> >> what would be your key management strategy for the macsec version? >> given press / etc over the last 18 or so months it seems like folk >> with long-haul ether framing might be very interested in macsec for >> those links and NOT doing it by sticking some switch platform between >> the 2 routed endpoints. >> >> management of key material (and rolling and...) is probably >> interesting for them as well. > > > Actually, that's part of the feature list I'm trying to put together. Not
Hurray! :) > everyone is willing to put a complete key infrastructure together, and some > even expressed interest in a simple unmanaged point-to-point solution. Let > me share my current view (subject to change): > > The first release will support 802.1X MKA using a pre-shared key. I'm still > trying to decide if this key should be programmable, e.g. via I2C, or if we > will simply sell paired devices with a unique pair-wise key programmed in > the factory. MKA will automatically take care of the distribution of new > MACsec keys. 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... remote-hands work is going to get a bunch more difficult than: "grab one from the jar, hurry!!!" 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?) > Later releases may support 802.1X EAPOL device authentication, though > exactly which EAP sub-protocols we will support is yet to be determined. As > said: a lot depends on the answers I will get from potential customers, > including people on this list. > > Kind regards, > > Pieter Hulshoff >
