I know this is a NANOG forum but curious how widespread usage of MACsec might be. (https://1.ieee802.org/security/802-1ae/).Currently reading the spec but wanted to pose some questions. I'm seeing some pitfalls: 1) May not work over wireless LAN devices? 2) Needs a centralized key server. 3) May not be supportable on all devices? Purported to be faster on the LAN than IPsec because MACsec is on layer 2. Thoughts?
On Mon, 21 Oct 2024 at 20:34, John Schiel <jschiel@flowtools.net> wrote:
1) May not work over wireless LAN devices?
I guess it depends on wireless technology, but 802.11xyzzy comes with an encryption solution already so isn't really a target of interest.
2) Needs a centralized key server.
Not really, implementation detail.
3) May not be supportable on all devices?
Definitely not supported on all devices, you tend to pay extra, but getting an increasingly small premium to pay. May become essentially free, depending on demand.
Purported to be faster on the LAN than IPsec because MACsec is on layer 2.
Speed doesn't have anything to do with layer2 or layer3, you may be assuming that ipsec is software and macsec is hardware which may be true, but is implementation detail. For example Juniper Trio can do some forms of IPSEC on the same hardware as MACSEC at the same performance profile. It is not exactly new technology, these devices have existed for +decade now? -- ++ytti
Thanks. I threw this out there not knowing how fast someone would respond. I only heard about this recently and am surprised it as as old as it is. Regarding speed, the first few pages I hit made a comment that it was slower because of packet overhead. I'm reading more and that is less of a concern. --jas On 10/21/24 12:28 PM, Saku Ytti wrote:
On Mon, 21 Oct 2024 at 20:34, John Schiel <jschiel@flowtools.net> wrote:
1) May not work over wireless LAN devices?
I guess it depends on wireless technology, but 802.11xyzzy comes with an encryption solution already so isn't really a target of interest.
2) Needs a centralized key server.
Not really, implementation detail.
3) May not be supportable on all devices?
Definitely not supported on all devices, you tend to pay extra, but getting an increasingly small premium to pay. May become essentially free, depending on demand.
Purported to be faster on the LAN than IPsec because MACsec is on layer 2. Speed doesn't have anything to do with layer2 or layer3, you may be assuming that ipsec is software and macsec is hardware which may be true, but is implementation detail. For example Juniper Trio can do some forms of IPSEC on the same hardware as MACSEC at the same performance profile.
It is not exactly new technology, these devices have existed for +decade now?
Regarding speed, the first few pages I hit made a comment that it was slower because of packet overhead. I'm reading more and that is less of a concern.
There's certainly a penalty paid for the extra time encrypting and decrypting , which of course can aggregate over a large number of protected links. But unless you're trying to manage latency budgets in the microseconds range it's not likely to be an issue. On Mon, Oct 21, 2024 at 3:01 PM John Schiel <jschiel@flowtools.net> wrote:
Thanks.
I threw this out there not knowing how fast someone would respond.
I only heard about this recently and am surprised it as as old as it is.
Regarding speed, the first few pages I hit made a comment that it was slower because of packet overhead. I'm reading more and that is less of a concern.
--jas
On Mon, 21 Oct 2024 at 20:34, John Schiel <jschiel@flowtools.net> wrote:
1) May not work over wireless LAN devices?
I guess it depends on wireless technology, but 802.11xyzzy comes with an encryption solution already so isn't really a target of interest.
2) Needs a centralized key server.
Not really, implementation detail.
3) May not be supportable on all devices?
Definitely not supported on all devices, you tend to pay extra, but getting an increasingly small premium to pay. May become essentially free, depending on demand.
Purported to be faster on the LAN than IPsec because MACsec is on layer
On 10/21/24 12:28 PM, Saku Ytti wrote: 2.
Speed doesn't have anything to do with layer2 or layer3, you may be assuming that ipsec is software and macsec is hardware which may be true, but is implementation detail. For example Juniper Trio can do some forms of IPSEC on the same hardware as MACSEC at the same performance profile.
It is not exactly new technology, these devices have existed for +decade now?
It is definitely deployed out there. I wouldn't worry too much about reading the specs. All of the implementations I've dealt with are only partial implementations. They almost all are limited to "point to point" functionality. As for comparing to IPsec, IPsec came out of a different time. It is more of framework with a zillion knobs, and lots of room for customization and future changes. The keying isn't even a part of IPsec. ISAKMP, later IKE, are separate protocols. IPsec has transport mode (seldom used) and tunnel mode. It has AH (which no one uses) and ESP. MACsec is much more narrowly defined. The cryptographic algorithms are standard. There is room for future updates of those algorithms, but for now, the implementers know what they need to do. For those reasons, I think it is more straightforward to implement MACsec in firmware. I would expect if you trimmed down IPsec, which most NOS implementations already do, you can implement it in the same way. Vendors have been charging big money for fast IPsec for a long time, they don't want to stop. But the MACsec price-point is so sweet compared to it, you now have people doing things like running MACsec over VXLAN in place of IPsec. On Mon, Oct 21, 2024 at 1:32 PM Tom Beecher <beecher@beecher.cc> wrote:
Regarding speed, the first few pages I hit made a comment that it was
slower because of packet overhead. I'm reading more and that is less of a concern.
There's certainly a penalty paid for the extra time encrypting and decrypting , which of course can aggregate over a large number of protected links.
But unless you're trying to manage latency budgets in the microseconds range it's not likely to be an issue.
On Mon, Oct 21, 2024 at 3:01 PM John Schiel <jschiel@flowtools.net> wrote:
Thanks.
I threw this out there not knowing how fast someone would respond.
I only heard about this recently and am surprised it as as old as it is.
Regarding speed, the first few pages I hit made a comment that it was slower because of packet overhead. I'm reading more and that is less of a concern.
--jas
On 10/21/24 12:28 PM, Saku Ytti wrote:
On Mon, 21 Oct 2024 at 20:34, John Schiel <jschiel@flowtools.net> wrote:
1) May not work over wireless LAN devices?
I guess it depends on wireless technology, but 802.11xyzzy comes with an encryption solution already so isn't really a target of interest.
2) Needs a centralized key server.
Not really, implementation detail.
3) May not be supportable on all devices?
Definitely not supported on all devices, you tend to pay extra, but getting an increasingly small premium to pay. May become essentially free, depending on demand.
Purported to be faster on the LAN than IPsec because MACsec is on layer 2. Speed doesn't have anything to do with layer2 or layer3, you may be assuming that ipsec is software and macsec is hardware which may be true, but is implementation detail. For example Juniper Trio can do some forms of IPSEC on the same hardware as MACSEC at the same performance profile.
It is not exactly new technology, these devices have existed for +decade now?
On 10/22/24 00:12, Crist Clark wrote:
It is definitely deployed out there. I wouldn't worry too much about reading the specs. All of the implementations I've dealt with are only partial implementations. They almost all are limited to "point to point" functionality.
As for comparing to IPsec, IPsec came out of a different time. It is more of framework with a zillion knobs, and lots of room for customization and future changes. The keying isn't even a part of IPsec. ISAKMP, later IKE, are separate protocols. IPsec has transport mode (seldom used) and tunnel mode. It has AH (which no one uses) and ESP.
MACsec is much more narrowly defined. The cryptographic algorithms are standard. There is room for future updates of those algorithms, but for now, the implementers know what they need to do.
For those reasons, I think it is more straightforward to implement MACsec in firmware. I would expect if you trimmed down IPsec, which most NOS implementations already do, you can implement it in the same way.
Vendors have been charging big money for fast IPsec for a long time, they don't want to stop. But the MACsec price-point is so sweet compared to it, you now have people doing things like running MACsec over VXLAN in place of IPsec.
MACsec is also really useful where you need point-to-point protection of traffic that isn't easily manipulated at L3 or may not even run over IP but that may transit publicly accessible infrastructure. Utility SCADA traffic is an example, and MACsec can be very useful on those networks as they often transition from wireless to fiber.
hey,
It is not exactly new technology, these devices have existed for +decade now?
What we are seeing now is MACsec getting integrated into latest NPUs directly. So far it has been mostly implemented by separate chips or in PHYs (or combination). This has, in some cases, limited you to what ports you can use MACsec on. It also had challenges with sync/PTP, per-vlan MACsec etc. So while it is proven technology and works well we are still seeing innovation/improvements. -- tarko
If you are going to deploy MACSEC, my advice is test, test, and test, especially (but not only) if you have different vendors' implementations of MACSEC on either end of the link. Test that MACSEC comes up. Test that it recovers from link flaps. Test key rotation. Test recovery from link flaps during key rotation. Test all permutations of recovery from admin down/up on both sides. Test everything you can think of, then think of more things to test. Stephen
On 10/22/24 16:56, Tarko Tikan wrote:
What we are seeing now is MACsec getting integrated into latest NPUs directly. So far it has been mostly implemented by separate chips or in PHYs (or combination). This has, in some cases, limited you to what ports you can use MACsec on. It also had challenges with sync/PTP, per-vlan MACsec etc.
So while it is proven technology and works well we are still seeing innovation/improvements.
It is also now shipping in coherent pluggables as a native feature. Mark.
I would caution anyone running MACsec on a link leveraging a provider circuit between them to quadruple check that the provider link supports customer use of MACsec. In theory MACsec will operate just fine over a Layer 2 link but carriers tend to not like unanticipated bits get appended or inserted into frame headers. In my carrier days, $dayjob's L2 products tended to be highly interoperable relative to the industry norm, and we still forced customers into a L1 service if they need MACsec. My understanding is that said carrier did start supporting it on its L2 services off of certain devices a couple of years ago, but I don't believe this is common for most providers. On Tue, Oct 22, 2024 at 2:27 PM Mark Tinka <mark@tinka.africa> wrote:
On 10/22/24 16:56, Tarko Tikan wrote:
What we are seeing now is MACsec getting integrated into latest NPUs directly. So far it has been mostly implemented by separate chips or in PHYs (or combination). This has, in some cases, limited you to what ports you can use MACsec on. It also had challenges with sync/PTP, per-vlan MACsec etc.
So while it is proven technology and works well we are still seeing innovation/improvements.
It is also now shipping in coherent pluggables as a native feature.
Mark.
-- - Dave Cohen craetdave@gmail.com @dCoSays www.venicesunlight.com
The biggest pitfall for telecom with MACSEC, is that PTP/SyncE and MACSEC on the same physical interface simultaneously is mostly not supported. Many claims that you can do both, but they don’t mention that it can’t be done at the same time. There are some newer models of Juniper ACX coming with that, one model of Cisco NCS (but not officially supported) and maybe others. But with the PHY and NPU separated it has been hard for them to implement. Probably the newest generation of NPU like Jericho3 will do this on the NPU and will handle it ok. But then again, the other end must also be of newer generation to interop properly. It is possible to configure MACSEC and PTP/SyncE on several models and interfaces and get them phase aligned. But in most cases, they will start to drift quite badly until they go out of spec. /Björn From: NANOG <nanog-bounces+bjorn.bertilsson=telia.no@nanog.org> On Behalf Of Dave Cohen Sent: Tuesday, October 22, 2024 8:39 PM To: Mark Tinka <mark@tinka.africa> Cc: nanog@nanog.org Subject: Re: IEEE MACsec I would caution anyone running MACsec on a link leveraging a provider circuit between them to quadruple check that the provider link supports customer use of MACsec. In theory MACsec will operate just fine over a Layer 2 link but carriers tend to not like unanticipated bits get appended or inserted into frame headers. In my carrier days, $dayjob's L2 products tended to be highly interoperable relative to the industry norm, and we still forced customers into a L1 service if they need MACsec. My understanding is that said carrier did start supporting it on its L2 services off of certain devices a couple of years ago, but I don't believe this is common for most providers. On Tue, Oct 22, 2024 at 2:27 PM Mark Tinka <mark@tinka.africa <mailto:mark@tinka.africa> > wrote: On 10/22/24 16:56, Tarko Tikan wrote:
What we are seeing now is MACsec getting integrated into latest NPUs directly. So far it has been mostly implemented by separate chips or in PHYs (or combination). This has, in some cases, limited you to what ports you can use MACsec on. It also had challenges with sync/PTP, per-vlan MACsec etc.
So while it is proven technology and works well we are still seeing innovation/improvements.
It is also now shipping in coherent pluggables as a native feature. Mark. -- - Dave Cohen craetdave@gmail.com <mailto:craetdave@gmail.com> @dCoSays www.venicesunlight.com <http://www.venicesunlight.com>
What a community!!! Thanks for all the responses. --jas On 10/23/24 9:27 AM, Bertilsson, Björn via NANOG wrote:
The biggest pitfall for telecom with MACSEC, is that PTP/SyncE and MACSEC on the same physical interface simultaneously is mostly not supported. Many claims that you can do both, but they don’t mention that it can’t be done at the same time. There are some newer models of Juniper ACX coming with that, one model of Cisco NCS (but not officially supported) and maybe others. But with the PHY and NPU separated it has been hard for them to implement. Probably the newest generation of NPU like Jericho3 will do this on the NPU and will handle it ok. But then again, the other end must also be of newer generation to interop properly.
It is possible to configure MACSEC and PTP/SyncE on several models and interfaces and get them phase aligned. But in most cases, they will start to drift quite badly until they go out of spec.
/Björn
*From:*NANOG <nanog-bounces+bjorn.bertilsson=telia.no@nanog.org> *On Behalf Of *Dave Cohen *Sent:* Tuesday, October 22, 2024 8:39 PM *To:* Mark Tinka <mark@tinka.africa> *Cc:* nanog@nanog.org *Subject:* Re: IEEE MACsec
I would caution anyone running MACsec on a link leveraging a provider circuit between them to quadruple check that the provider link supports customer use of MACsec. In theory MACsec will operate just fine over a Layer 2 link but carriers tend to not like unanticipated bits get appended or inserted into frame headers. In my carrier days, $dayjob's L2 products tended to be highly interoperable relative to the industry norm, and we still forced customers into a L1 service if they need MACsec. My understanding is that said carrier did start supporting it on its L2 services off of certain devices a couple of years ago, but I don't believe this is common for most providers.
On Tue, Oct 22, 2024 at 2:27 PM Mark Tinka <mark@tinka.africa> wrote:
On 10/22/24 16:56, Tarko Tikan wrote:
> What we are seeing now is MACsec getting integrated into latest NPUs > directly. So far it has been mostly implemented by separate chips or > in PHYs (or combination). This has, in some cases, limited you to what > ports you can use MACsec on. It also had challenges with sync/PTP, > per-vlan MACsec etc. > > So while it is proven technology and works well we are still seeing > innovation/improvements.
It is also now shipping in coherent pluggables as a native feature.
Mark.
--
- Dave Cohen craetdave@gmail.com @dCoSays
www.venicesunlight.com <http://www.venicesunlight.com>
In case you'll find it interesting - all three major cloud providers (AWS, Azure, GCP) support MACSec on their circuits dedicated to customers (restictions may apply). https://aws.amazon.com/directconnect/locations/ https://cloud.google.com/network-connectivity/docs/interconnect/concepts/cho... Can't find the similar table for Azure unfortunately but MACSec is there https://learn.microsoft.com/en-us/azure/expressroute/expressroute-about-encr... On Mon, Oct 21, 2024 at 9:11 PM John Schiel <jschiel@flowtools.net> wrote:
I know this is a NANOG forum but curious how widespread usage of MACsec might be. (https://1.ieee802.org/security/802-1ae/).Currently reading the spec but wanted to pose some questions.
I'm seeing some pitfalls: 1) May not work over wireless LAN devices? 2) Needs a centralized key server. 3) May not be supportable on all devices?
Purported to be faster on the LAN than IPsec because MACsec is on layer 2.
Thoughts?
Does anyone have a contact at Amazon AWS? I own fiber between the USA and Mexico and we would like to discuss a relationship with them to bring AWS X-connects into the Tijuana Baja California region. We connect from One Wilshire all the way to Mexico. Norman Jester Global Exchange Telecom 619-319-7055 (I prefer WhatsApp or Text if you do too.)
participants (12)
-
Andriy Bilous -
Bertilsson, Björn -
Brandon Martin -
Crist Clark -
Dave Cohen -
John Schiel -
Mark Tinka -
Norman Jester -
Saku Ytti -
Stephen Stuart -
Tarko Tikan -
Tom Beecher