Re: MACsec SFP

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

On Wed, Jun 25, 2014 at 4:17 PM, John Schiel <jschiel () flowtools net> wrote:
> 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?

today you program the key (on switches that do macsec, not in an SFP
that does it for you, cause those don't exist, yet) in your router
config and as near as I have seen there isn't a key distribution
protocol aside from that which you write/manage yourself and which is
likely using ssh/snmp(ick)/telnet(ick).

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