[172572] in North American Network Operators' Group
Re: MACsec SFP
daemon@ATHENA.MIT.EDU (Christopher Morrow)
Tue Jun 24 11:50:53 2014
X-Original-To: nanog@nanog.org
In-Reply-To: <53A98443.9060801@aimvalley.nl>
Date: Tue, 24 Jun 2014 11:50:42 -0400
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Pieter Hulshoff <phulshof@aimvalley.nl>
Cc: nanog list <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
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
>
