Re: MACsec SFP

[Christopher Morrow <morrowc.lists () gmail com>]

On Tue, Jun 24, 2014 at 9:59 AM, Pieter Hulshoff <phulshof () aimvalley nl> wrote:
> On 24-6-2014 15:50, Christopher Morrow wrote:
> > On Tue, Jun 24, 2014 at 3:59 AM, Pieter Hulshoff <phulshof () 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