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
On (2014-06-23 11:13 +0200), Pieter Hulshoff wrote:
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. 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. -- ++ytti
On 24-6-2014 8:37, Saku Ytti wrote:
On (2014-06-23 11:13 +0200), Pieter Hulshoff wrote:
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
On Tue, Jun 24, 2014 at 12:59 AM, Pieter Hulshoff <phulshof@aimvalley.nl> wrote:
On 24-6-2014 8:37, Saku Ytti wrote:
On (2014-06-23 11:13 +0200), Pieter Hulshoff wrote:
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?
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.
On (2014-06-24 09:59 +0200), Pieter Hulshoff wrote: 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. -- ++ytti
On 24-6-2014 10:21, Saku Ytti wrote:
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
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-sync...). 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
On (2014-06-24 10:55 +0200), Pieter Hulshoff wrote:
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. -- ++ytti
On 24-6-2014 11:09, Saku Ytti wrote:
On (2014-06-24 10:55 +0200), Pieter Hulshoff wrote:
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
DIP switches? Frank -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Saku Ytti Sent: Tuesday, June 24, 2014 3:21 AM To: nanog@nanog.org Subject: Re: MACsec SFP On (2014-06-24 09:59 +0200), Pieter Hulshoff wrote: 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. -- ++ytti
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. -chris
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 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
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
On (2014-06-24 11:50 -0400), Christopher Morrow wrote:
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. Maybe some customer would then enter need for this in CLI in their multimillion dollar RFQ, and then we'd get the feature. -- ++ytti
On Tue, Jun 24, 2014 at 12:07 PM, Saku Ytti <saku@ytti.fi> wrote:
On (2014-06-24 11:50 -0400), Christopher Morrow wrote:
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.
On (2014-06-24 12:30 -0400), 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.
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. -- ++ytti
On Tue, Jun 24, 2014 at 1:19 PM, Saku Ytti <saku@ytti.fi> wrote:
On (2014-06-24 12:30 -0400), 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.
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 :) 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.
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 On Tue, Jun 24, 2014 at 10:19 AM, Saku Ytti <saku@ytti.fi> wrote:
On (2014-06-24 12:30 -0400), 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.
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.
-- ++ytti
That's a large number of proposals. :) I'll have a chat with some colleagues about the types outside my areas of expertise to see what they think about it. You're not the first to mention separately tunable transmitters and receivers. Do you think there would be a great demand for this device? Anyone else care to wager in on these proposals; do any of them strike you as something you would be interested in as well? Kind regards, Pieter Hulshoff
Those 'proposals' are really just things that would have been useful in module form at one point or another, not necessarily anything that I've given any serious thought to what sort of market they would have. Some are probably impractical, some would probably be far too expensive to actually be useful, and some would probably only have very narrow appeal. That said, I do think the separately tunable tunable transmitters and receivers could be huge, especially if they came at only a reasonably small premium over fixed wavelengths. Just for CWDM as we are implementing it, we need to deal with 16 different wavelengths, and three different transmit powers, giving us 48 different modules to deal with (DWDM would/will only make that worse). If we could cut that to one, or even three, it would make things much simpler, from planning to stocking and sparing. --Eric On Wed, Jun 25, 2014 at 1:55 AM, Pieter Hulshoff <phulshof@aimvalley.nl> wrote:
That's a large number of proposals. :) I'll have a chat with some colleagues about the types outside my areas of expertise to see what they think about it.
You're not the first to mention separately tunable transmitters and receivers. Do you think there would be a great demand for this device?
Anyone else care to wager in on these proposals; do any of them strike you as something you would be interested in as well?
Kind regards,
Pieter Hulshoff
On (2014-06-25 05:09 -0700), Eric Flanery (eric) wrote:
That said, I do think the separately tunable tunable transmitters and receivers could be huge, especially if they came at only a reasonably small
I don't think this technology exists. The receivers are always wideband and there is some filter in optical mux or in BX optic to avoid receiving reflections of your own TX. Not sure if tunable filter exists. But you can today buy BX optics which work on same wavelength, so you can use same part in both ends of the connection. -- ++ytti
On Wed, Jun 25, 2014 at 8:40 AM, Saku Ytti <saku@ytti.fi> wrote:
On (2014-06-25 05:09 -0700), Eric Flanery (eric) wrote:
That said, I do think the separately tunable tunable transmitters and receivers could be huge, especially if they came at only a reasonably small
I don't think this technology exists. The receivers are always wideband and there is some filter in optical mux or in BX optic to avoid receiving reflections of your own TX. Not sure if tunable filter exists.
Tunable rx exists in pluggable format, but it is called 100G coherent :-) I would find tunable rx useful for 1/10G (eliminate DCM, power-splitter based WDM etc), but not sure there is enough market for the product to exist. Closest I got was inline FBG fiber patch. There are manufacturers for these. Tim:>
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
On Tue, Jun 24, 2014 at 6:30 PM, Randy Bush <randy@psg.com> wrote:
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.
sure... but to do this you have to be able to program the keys from the platform the SFP is plugged into.. .not via the sfp itself (outside the chassis)
i have always been fond of rfc 4808 and not the unnecessarily complex alternatives such as tcp-ao. sure... but to do this you have to be able to program the keys from the platform the SFP is plugged into.. .not via the sfp itself (outside the chassis)
i was advocating the general method, prepping key roll, not the particular use in md5 tcp randy
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
How much ahead of my time would I be if I was to ask for CFP/CFP2 transceivers supporting MACsec? (at a reasonably competitive price) --Aris
On 25-06-14 04:57, Aris Lambrianidis wrote:
How much ahead of my time would I be if I was to ask for CFP/CFP2 transceivers supporting MACsec? (at a reasonably competitive price)
So far, most requests I got were for 1 Gbps, and some for 10 Gbps. You're the first to mention 100 Gbps, so my guess is that you're ahead of the curve. Frankly, we're still in the process of designing 10 Gbps in this format, and don't have a CFP platform for smart S/CFPs ready yet, but I'll certainly keep it in mind, especially if more people show interest. Some of our larger customers may be interested in it, so I'll check with them. Kind regards, Pieter Hulshoff
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@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
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
On 25-06-14 22:45, Christopher Morrow wrote:
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 not familiar with the MACsec key distribution available in current routers/switches. Are you saying Cisco doesn't support EAP and/or MKA for this purpose or just that the command protocol for configuring EAP/MKA is run via SSH/SNMP/telnet? Kind regards, Pieter Hulshoff
On Wed, Jun 25, 2014 at 4:51 PM, Pieter Hulshoff <phulshof@aimvalley.nl> wrote:
On 25-06-14 22:45, Christopher Morrow wrote:
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 not familiar with the MACsec key distribution available in current routers/switches. Are you saying Cisco doesn't support EAP and/or MKA for this purpose or just that the command protocol for configuring EAP/MKA is run via SSH/SNMP/telnet?
I had looked a bit ago (like a year or so perhaps longer) for this and it seemed like command-line on the switch functions only. This: <http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/software/release/15-0_1_se/configuration/guide/3750xcg/swmacsec.pdf> (for 15.0 IOS on a 3750... ymmv on others of course) it lookslike they have MKA (and eap) for user-facing ports, and some nutty cisco thing (trustsec) for switch-to-switch. I never looked at this for machine-facing ports... Oh, the manual setup for switch-to-switch is possibly what i recall from my last look at this. -chris
On Cisco equipment supporting MACsec, EAP and MKA is of course configured through the normal cli. On Wednesday, June 25, 2014, Pieter Hulshoff <phulshof@aimvalley.nl> wrote:
On 25-06-14 22:45, Christopher Morrow wrote:
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 not familiar with the MACsec key distribution available in current routers/switches. Are you saying Cisco doesn't support EAP and/or MKA for this purpose or just that the command protocol for configuring EAP/MKA is run via SSH/SNMP/telnet?
Kind regards,
Pieter Hulshoff
-- Tim:>
protocol was that communicated this information down to the SFP
For EEPROM access in a SFP+ it's I2C with is well documented and used in tons of embedded stuff .. commercial logic analysis tools can handle this protocol, as can your average $10 Arudrino. Of course writing certain parts of the SFP+ EEPROM are "protected" for obvious reasons but that certainly hasn't stopped people. Cheers, Michael Holstein Cleveland State University
On 25-06-14 22:17, John Schiel 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?
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.
It hasn't been decided yet. For our current portfolio of managed device we use a proprietary layer-2 protocol, and offer a network management module that can be integrated into a network management system, a smart device gateway with SNMP support, and an integrated network management in Creanord's EchoVault system. Layer-3 management support is under investigation. Obviously, any key communication over the line would be encrypted, but what security system will be used will depend greatly on the chosen communication protocol. This will in part depend on the customer feedback I get, which currently range from our current layer-2 solution to a web interface to a CLI. If we go layer-3, we'll probably use a standard like SSL/TLS for web pages, and SSH for CLI. Kind regards, Pieter Hulshoff
On (2014-06-25 22:45 +0200), Pieter Hulshoff wrote:
chosen communication protocol. This will in part depend on the customer feedback I get, which currently range from our current layer-2 solution to a web interface to a CLI. If we go layer-3, we'll probably use a standard like SSL/TLS for web pages, and SSH for CLI.
Problem I have with SFP getting control-plane is that then I need provisioning and potentially config backup system. I think router CLI and I2C is right place for this, obviously it creates lag, as first routers won't support it, and you need to do it offline. Perhaps such lag could be avoided in future if we'd specify some 'host to SFP' high level protocol, perhaps in much the same way as DHCP 'option' handling? In this case, router could code arbitrary value to arbitrary option without understanding what it means, and down the line introduce syntactic sugar for commonly used features. -- ++ytti
Perhaps such lag could be avoided in future if we'd specify some 'host to SFP' high level protocol, perhaps in much the same way as DHCP 'option' handling?
The SFF Committee specifies GBIC registers. They’d be the appropriate group to add registers for features such as MACsec, Ethernet OAM and the like. I’d also encourage a common SFF Committee feature to query and update GBIC firmware and encourage SFP vendors to make firmware freely redistributable so that SFPs can be updated by the operating system as needed to avoid security exposures (and such a feature is problematic, as it would have to be written in such a way as to prevent it being used as another mechanism resellers can use to ‘lock’ SFP sales to their equipment sales). The Committee have already specified registers for tuneable SFPs. After the SFF Committee specifies the registers the operating system vendors or vendors of devices would then add commands to support to toggle the I2C needed to program those registers with MACsec keys, etc. You should not be able to set the MACsec key from the optical side. That feature is not only cryptographically dubious but it also requires that the 'forwarding plane' (which might otherwise be entirely hardware) be connected to the SFP’s management plane. That’s not desirable from a design or security point of view. Note carefully that I’m not discouraging a self-keying mode where GBICs don’t verify their partners but are proof against receive-only optical taps (and in that case I’d encourage the SFF Committee to specify that implementations print their fingerprint and the fingerprint of the partner GBIC, so that people can verify after the fact that the partner expected is the one encountered). -- Glen Turner <http://www.gdt.id.au/~gdt/>
On (2014-06-30 13:28 +0930), Glen Turner wrote:
After the SFF Committee specifies the registers the operating system vendors or vendors of devices would then add commands to support to toggle the I2C needed to program those registers with MACsec keys, etc.
This is what I tried to tackle, this creates chicken/egg scenario, no one is buying optic, because you can't program it from your router, and you can't program it in your router, as no one is using the optic and vendor won't put development hours on it. If instead there would be standardized (DHCP option like) system to code arbitrary value to arbitrary location, you could code the feature, without router understanding what it is, after a while, syntactic sugar might be added for convenience. -- ++ytti
On 30 Jun 2014, at 3:47 pm, Saku Ytti <saku@ytti.fi> wrote:
On (2014-06-30 13:28 +0930), Glen Turner wrote:
After the SFF Committee specifies the registers the operating system vendors or vendors of devices would then add commands to support to toggle the I2C needed to program those registers with MACsec keys, etc.
This is what I tried to tackle, this creates chicken/egg scenario, no one is buying optic, because you can't program it from your router, and you can't program it in your router, as no one is using the optic and vendor won't put development hours on it. If instead there would be standardized (DHCP option like) system to code arbitrary value to arbitrary location, you could code the feature, without router understanding what it is, after a while, syntactic sugar might be added for convenience.
What you really want isn’t DHCP-like, but simple AND-mask OR-set register handling. You’d provide your customers with the magic numbers. interface … gbic-register [if REGISTER AND-MASK VALUE]… [set REGISTER AND-MASK OR-VALUE]… gbic-register … Assuming that the GBIC programming doesn’t change PHY requirements you are done. -- Glen Turner <http://www.gdt.id.au/~gdt/>
On (2014-06-30 17:21 +0930), Glen Turner wrote:
What you really want isn’t DHCP-like, but simple AND-mask OR-set register handling. You’d provide your customers with the magic numbers.
interface … gbic-register [if REGISTER AND-MASK VALUE]… [set REGISTER AND-MASK OR-VALUE]… gbic-register …
Assuming that the GBIC programming doesn’t change PHY requirements you are done.
It could be lot more user-friendly with syntactic sugar for strings, ip addresses etc. So you'd know you'll push crypto key string to register N1 and crypto integer (implying which algo to use) in regisrter N2, so you'd get something like. gbic-register N1 string "supahsecret" dgib-register N2 int 4 Far more user-friendly. -- ++ytti
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 24 jun 2014 kl. 08:37 skrev Saku Ytti <saku@ytti.fi>:
On (2014-06-23 11:13 +0200), Pieter Hulshoff wrote:
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.
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.
-- ++ytti
I was wondering: Would there be an interest in a similar IPsec SFP or is that part already well taken care of by the router market? Kind regards, Pieter Hulshoff
participants (13)
-
Andreas Larsen -
Aris Lambrianidis -
Christopher Morrow -
Eric Flanery (eric) -
Frank Bulk (iname.com) -
Glen Turner -
John Schiel -
Jonathan Lassoff -
Michael O Holstein -
Pieter Hulshoff -
Randy Bush -
Saku Ytti -
Tim Durack