MACsec SFP

Wed Jun 25 20:17:12 UTC 2014

Would be nice if we knew what the protocol was that communicated this
information down to the SFP and would also be nice if that was an open
protocol subject to review. UDP something? is my guess but ow do those
messages look?

I'm new to the MACsec idea but I would hope we could watch for such key
exchange traversing the wire and have some method to ignore spurious
messages and keys that may lock up a valid, working SFP.

--John

On Tue, Jun 24, 2014 at 1:27 PM, Pieter Hulshoff <phulshof at aimvalley.nl>
wrote:

> 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
>
>