MACsec SFP

Tue Jun 24 15:50:42 UTC 2014

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