3

If one device (e.g. A wireless router) is attempting to communicate with another device (e.g. some gateway to another network) through a unmanaged switch and the router is ciphering frames it transmits using 802.1ae macsec (which the gateway also supports), but the switch that connects them doesn't know anything of 802.1ae and can't decipher the portions of the message that are ciphered, will the switch still be able to route the message between the two?

Or nominally, would most switches drop the message, in this case?

For managed switches, which need to read the VLAN ID from the encrypted part of the message, I assume it would drop it if it didn't support 802.1ae.

But for unmanaged switches, it would seem (nominally) that it would be able to route it correctly based solely on the mac address.

Tolsadus
  • 1,123
  • 11
  • 22
Bob
  • 130
  • 6

2 Answers2

2

Frames, like 802.1X or 802.1AE (protocols that apply to multiple LAN type use capital letters) use a special multicast OUI (01-80-C2) defined by the IEEE that prevents bridges (switches) from forwarding them to any other interface.

That means that MACsec (802.1AE, a superset of 802.1X) cannot cross a bridge that doesn't know how to use it. The same applies to all the 802.1x protocols. See the IEEE 802.1D™-2004 standard.

But for unmanaged switches, it would seem (nominally) that it would be able to route it correctly based solely on the mac address. But maybe that's not a correct assumption.

By the way, switches do not route. Routing is a layer-3 function, but bridges (switches) switch at layer-2.

Ron Maupin
  • 3,158
  • 1
  • 11
  • 16
  • Apologies, but I'm not sure I understand the point about the OUI value which you mentioned - In performing simple Google searches, there are plenty of examples of network captures, where the OUI in the MAC is the actual organizational value (e.g. http://costiser.ro/uploads/macsec-encrypt-on-vs-off.png). – Bob Feb 19 '17 at 13:28
  • @Rob: That's merely the capture software/package resolving the first three octets of the MAC address to the OUI of the organization to which that OUI has been assigned. That's not how the MAC address appears in the actual Ethernet frame. – joeqwerty Feb 19 '17 at 17:15
  • @Rob, the IEEE has reserved that OUI for Link-Local protocols, including 802.1X and 802.1AE. Frames with those protocols are sent to a destination MAC address with that OUI. Any frames sent to an address with that OUI are not allowed to be forwarded to a different bridge interface. That is why they are Link-Local protocols. – Ron Maupin Feb 19 '17 at 19:03
1

Switches which are not MACsec-capable can, in general, forward Ethernet frames which have been authenticated and/or encrypted with MACsec. RedHat has a blog post here with some pictures, and it describes this case as "the main use case for MACsec". This clearly makes sense, or the chances of MACsec adoption would be next to zero.

As you more-or-less say, the switch will forward frames based on an internal routing table which is loaded only with MAC addresses, which are in the clear in MACsec. The OUI stuff mentioned elsewhere is only relevant to MKA setup.

There is an issue with VLANs, as you point out. The 802.1Q tag is beyond the SecTAG and will be encrypted (if encryption is enabled). Vendors generally have work-arounds to prevent tag encryption, which you may be able to use - look up "802.1Q tag in the clear", for example.

EML
  • 393
  • 3
  • 12
  • This is a great answer and should be the accepted one. Page 10 of https://www.cisco.com/c/dam/en/us/td/docs/solutions/Enterprise/Security/MACsec/WP-High-Speed-WAN-Encrypt-MACsec.pdf describes exactly this. What would be the purpose of Q tag in the clear otherwise? – Pierre-Luc Bertrand Feb 20 '20 at 19:10
  • Wouldn't setting up several MACsec networks be an alternative to using VLANs? – 00prometheus Feb 15 '21 at 14:03