MACsec SFP

Mailman List Mirror (Read Only)
1

All,

Last year some people on this list expressed interest in smart SFP options, like e.g. MACsec. As a network consultant and systems architect with AimValley in the Netherlands, I'm currently in the process of gathering feature and market information for such a device, and I would welcome some feedback from interested people. Discussion about other types of smart SFPs would also be welcome. Feel free to contact me directly using the contact information below.

Kind regards,

Pieter Hulshoff
Network Consultant & Systems Architect
Aimvalley B.V.
Utrechtseweg 38
1213 TV Hilversum
+31 35 689 1936
phulshof@aimvalley.nl
http://www.aimvalley.com

2

I'd do questionable things for subrate SFP, SFP which I can put to 1GE port
and have 10M and 100M rates available. Or to 10GE port and get 1GE, 100M and
10M

Use case is network generation upgrade where you still have one or two 100M
ports for MGMT ports etc.

There are quite few service SFP already available, RAD does E1 over IP/ETH
tunnels in SFP, Huawei has router-in-SFP, JDSU has ethernet probe in SFP,
probably quite few others.

3

feature and market information for such a device, and I would welcome some
feedback from interested people. Discussion about other types of smart SFPs
would also be welcome. Feel free to contact me directly using the contact
information below.

I'd do questionable things for subrate SFP, SFP which I can put to 1GE port
and have 10M and 100M rates available. Or to 10GE port and get 1GE, 100M and
10M

Use case is network generation upgrade where you still have one or two 100M
ports for MGMT ports etc.

I've seen this request from others as well. Do you have any proposal/preference to limit the data rate from the switch?

There are quite few service SFP already available, RAD does E1 over IP/ETH
tunnels in SFP, Huawei has router-in-SFP, JDSU has ethernet probe in SFP,
probably quite few others.

I'm aware of these products; we (AimValley) build and sell several similar products as well. Since I'm a systems architect, and not a sales person, my email was mostly meant to get an idea of what type of smart SFP products people in the field would like to see come to light, and what type of 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.

Kind regards,

Pieter Hulshoff

4

Totally agree with Ytti subrated sfp Yummyyyyy
Andreas Larsen
IP-Only AB | Postadress: 753 81 UPPSALA | Besöksadress Uppsala: S:t Persg 6
Besöksadress Stockholm: N Stationsg 69 | Vxl: +46 18 843 10 00 | Mobil +46 70 843 10 56
www.ip-only.se

5

Seems like it would be just like emulating a media convertor. Drop any
frames in excess of 100 Mbit? Perhaps buffer a little bit?

If using the interface for any protocols, configuration might need to
be made to adjust link costs.

6

Hi Pieter,

I've seen this request from others as well. Do you have any
proposal/preference to limit the data rate from the switch?

For this solution to be marketable, it needs to be extremely cheap, as you're
essentially competing against cheapest consumer grade switches to subrate a
port.
These ports would not be revenue generating, but almost invariably MGMT ports
to legacy equipment, issues like QoS are not relevant, price point is. From
switch POV, packets would be lost on-link when rate exceeds, and TCP would
then decrease rate.

So SFP would need to implement rudimentary buffering and packet dropping.

And as always, it's best if there is some way for these to work without any
configuration, as the moment you need to configure 1 thing, you need to
develop provisioning system and potentially also configuration backups, which
may in some organizations make solution prohibitively expensive compared to
using small switch from existing vendor, which is already supported by
systems.

7

So basically a 1G connection to the switch, buffering with frame drop, and a tri-rate RJ45 connector? Sounds like something that could easily be built into our Chronos platform (http://www.aimvalley.com/portfolio_item/chronos-smart-sfp-tstransparent-synce-sfp/). We'd just have to remove the SyncE, and add the 10/100 Mb support.

Probably the most complex part is to build a business case for it to pitch to our management. Would anyone be willing to email me a price indication, and perhaps an indication of how many of these products would be needed? No obligations of course; just to get an idea of whether a business case can be built?

Kind regards,

Pieter Hulshoff

8

So basically a 1G connection to the switch, buffering with frame drop, and a
tri-rate RJ45 connector? Sounds like something that could easily be built

Yes, also similar solution for 10GE SFP+.

Not sure what price should be 50EUR for 1GE and 100EUR for 10GE definitely
would be marketable, but they likely could cost more.
Like always, market increases as price decreases, so it might be possible to
push NRE costs to early adopters then price drop to reach wider market.

Probably the most complex part is to build a business case for it to pitch
to our management. Would anyone be willing to email me a price indication,
and perhaps an indication of how many of these products would be needed? No
obligations of course; just to get an idea of whether a business case can be
built?

I'm not ready to commit, because timing is critical here, as such part does
not exist, people have found some solution, solution usually means retaining
the previous-generation switch in pop, just to subrate the new-generation
ports.
But this uses lot of electricity usually and it wastes rack space, so it might
be easy to show how in just electricity costs you can recover costs in under a
year. If switch takes 150W, that's approximately 150 EUR per year for
electricity. If SFP takes 1W, yearly savings on electricity alone are 149EUR.
MTBF is probably better, due to no separate PSU and ability to capitalize on
redundant PSU of host.

9

So basically a 1G connection to the switch, buffering with frame drop, and a
tri-rate RJ45 connector? Sounds like something that could easily be built

Yes, also similar solution for 10GE SFP+.

What about XFP? Any need for that as well?

Not sure what price should be 50EUR for 1GE and 100EUR for 10GE definitely
would be marketable, but they likely could cost more.
Like always, market increases as price decreases, so it might be possible to
push NRE costs to early adopters then price drop to reach wider market.

Price would indeed depend quite a bit on the volume, since design and production cost will need to be recovered.

Probably the most complex part is to build a business case for it to pitch
to our management. Would anyone be willing to email me a price indication,
and perhaps an indication of how many of these products would be needed? No
obligations of course; just to get an idea of whether a business case can be
built?

I'm not ready to commit, because timing is critical here, as such part does
not exist, people have found some solution, solution usually means retaining
the previous-generation switch in pop, just to subrate the new-generation
ports.
But this uses lot of electricity usually and it wastes rack space, so it might
be easy to show how in just electricity costs you can recover costs in under a
year. If switch takes 150W, that's approximately 150 EUR per year for
electricity. If SFP takes 1W, yearly savings on electricity alone are 149EUR.
MTBF is probably better, due to no separate PSU and ability to capitalize on
redundant PSU of host.

I'm not looking for commitments in any way; just an indication of how often people need a solution like this to get an idea of the type of volumes we're looking at, and a reasonable selling price. As written above: design and production cost (including test, validation, factory, etc.), and reseller profit margins will need to be recovered, so if I'm to convince our management that we should develop this product I'll need to build some kind of business case for it. Of course we'll also contact our regular customer base about these matters, but I would welcome feedback from this list as well.

Kind regards,

Pieter Hulshoff

10

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.

-chris

11

Actually, that's part of the feature list I'm trying to put together. Not 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.

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

12

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! :slight_smile:

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

13

Solution could be same as for tunable optics, first you tune with eeprommer
until CLI gets support.
Remote legs could have their own eeprommer, which can be easy enough to use
not to require training and costs like 10EUR.

Maybe some customer would then enter need for this in CLI in their multimillion
dollar RFQ, and then we'd get the feature.

14

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

Solution could be same as for tunable optics, first you tune with eeprommer
until CLI gets support.
Remote legs could have their own eeprommer, which can be easy enough to use
not to require training and costs like 10EUR.

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.

also, as soon as you give the remote-hands person a copy of your key
material and ask them to do the deed on the eepromer, you'll be buying
replacement eepromer's/stick-note-bundles for the remote-hands people
(or god forbid asking ${equinix-alike} to cleanse your key material
from their ticketing system.

Maybe some customer would then enter need for this in CLI in their multimillion
dollar RFQ, and then we'd get the feature.

maybe so... multi-million of sfp is a lot of sfp though.

15

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.

Hopefully you could offer date when new keys take effect.

> Maybe some customer would then enter need for this in CLI in their multimillion
> dollar RFQ, and then we'd get the feature.

maybe so... multi-million of sfp is a lot of sfp though.

Of course this would be for the equipment where SFP sits, SFP vendor can't
solve this. But if you're making it mandatory in router RFQ, it seems pretty
much guaranteed vendors would comply and winning bid at least would implement
it.

16

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.

Hopefully you could offer date when new keys take effect.

sure, 'use new key in 37.243 minutes!' I still have to coordinate
people showing up at all sites over N period of time to do this
programming, and I'm SURE that some set of the programmed devices will
get an l instead of a 1 ... so 'quick chuck, get in the truck!' is
going to be an oft-heard refrain ;(

Hand managing this just isn't feasible, I think.

> Maybe some customer would then enter need for this in CLI in their multimillion
> dollar RFQ, and then we'd get the feature.

maybe so... multi-million of sfp is a lot of sfp though.

Of course this would be for the equipment where SFP sits, SFP vendor can't
solve this. But if you're making it mandatory in router RFQ, it seems pretty
much guaranteed vendors would comply and winning bid at least would implement
it.

yes, I realized as I clicked 'send'... in any case :slight_smile: the sfp
manufacturer likely has to decide on some way to program the sfp
(maybe there are already in-router/switch ways for other things like
this? like wavelength...) which all router/switch vendors have to also
agree to abide by.

17

Hmm, wandering pie-in-the-sky module wish list...

MACsec would be great, hopefully in an easy to manage/replace form.

Separately tunable transmitters and receivers; in both DWDM and CWDM
flavors. This would reduce the number of different parts to track/stock,
and enable the use of simple splitters/combiners in place of mux/demux
shelves for some short links.

Fully functional (as a manageable device) whatever-PON 'OLT in a module',
so that we can use any old host device that lacks specific support. (ONTs
too)

'Channelized SFP+', that talks on multiple wavelengths (CWDM/DWDM) at a 1G
rate simultaneously, to support a sort of WDM-PON. And/or SFP+ modules that
talk on multiple strands at a 1G rate simultaneously, with something like a
MPO/MTP connector, to increase density. I suppose there would need to be
some sort of switch or mux built into the module in either case.

A SFP(+) microwave modem, to connect to a radio head. Hopefully with wide
support of many licensed and unlicensed bands.

802.11-whatever APs in a SFP(+) form factor, preferably controller-based.
Perhaps doing some sort of RF-over-Ethernet to enable widely distributed
antenna systems.

Mini MPLS LER/PE routers in SFP form. All sorts of customer-facing
interface types could be interesting, but mostly (sub-rate) Ethernet with
QoS of some sort.

Self power-leveling and/or attenuating with wide ranges, again reducing
part tracking/stocking, and eliminating discrete attenuator pads.

SIP ATA in SFP form.

Small flash-based NAS in SFP form.

'Computational resources' in SFP(+) form (ARM chips maybe?).

OTDR functionality built into modules, hopefully able to operate without
disrupting the data flow, perhaps continuously.

Manageable (CLI and SNMP, please) modules of all sorts, to enable whatever
'special' features to be operated without requiring any particular support
from the host device beyond the MSA.

1G/100M SFPs that provide PoE ('passive' 18v or 24v would be most
appreciated.)

No vendor lock!

--Eric

18

DIP switches?

Frank

19

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.

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. :slight_smile:

Kind regards,

Pieter Hulshoff

20

Solution could be same as for tunable optics, first you tune with
eeprommer until CLI gets support.
Remote legs could have their own eeprommer, which can be easy enough
to use not to require training and costs like 10EUR.

it's going to be hard to schedule a key roll then, right?

i have always been fond of rfc 4808 and not the unnecessarily complex
alternatives such as tcp-ao.

randy