Ethernet – Lost Ethertype in encrypted MACsec frames

ethernetprotocol-theorySecurity

MACsec uses an Ethertype of 88E5. This presents an obvious problem when encrypting frames which already have, or should have, another Ethertype. This RedHat blog, for example, states "[MACsec] can secure all traffic within a LAN, including DHCP and ARP, as well as traffic from higher layer protocols". How can ARP be secured when it has to have an Ethertype of 0806?

More generally, if you have an encypted backbone/switch/WLAN/whatever which talks to unencrypted endpoints, then the switch will encrypt plain Ethernet frames on ingress, and decrypt on egress. During this process, the original Ethertype is lost, since there's nowhere to store it in a MACsec frame, so what does the switch put in the outgoing Ethertype?

I guess one option is for the switch to only encrypt a specific Etherype – IPv4, say – and replace the incoming 0800 with 88E5, and reverse that at the output. This doesn't seem particularly useful though. Thanks.

Best Answer

MACsec actually adds to the ethernet frame header and trailer. You end up with a different value in the Ether Type field position, much like you do with 802.1Q, but the original Ether Type field is preserved.

Related Solutions

Ethernet – Extend MACSec encryption over provider bridge

MacSec (i.e. 802.1ae-2006) is a hop-by-hop encyption technology... Therefore provider-bridged MacSec isn't possible today; however, there is a talk of relaxing per-hop MacSec encryption

Ethernet – Detecting different Ethernet frames

Although ytti answered, there are some relevant details you may be interested in...

How can someone distinguish between different packets in the Ethernet protocol? It has no "length" field/area as higher-level protocols use to do so.

Actually ethernet has multiple encapsulations:

Ethernet II (Typically used for IP, as specified in [RFC 894], is the most common encapsulation): Does not have a length field, instead a type field is used...

       +----+----+------+------+-----+
       | DA | SA | Type | Data | FCS |
       +----+----+------+------+-----+
                 ^^^^^^^^

       DA      Destination MAC Address (6 bytes)
       SA      Source MAC Address      (6 bytes)
       Type    Protocol Type           (2 bytes: >= 0x0600 or 1536 decimal)  <---
       Data    Protocol Data           (46 - 1500 bytes)
       FCS     Frame Checksum          (4 bytes)

802.2 LLC Ethernet: has a length field

       +----+----+------+------+------+------+-----+
       | DA | SA | Len  | LLC  | SNAP | Data | FCS |
       +----+----+------+------+------+------+-----+
                 ^^^^^^^^

       DA      Destination MAC Address (6 bytes)
       SA      Source MAC Address      (6 bytes)
       Len     Length of Data field    (2 bytes: <= 0x05DC or 1500 decimal)  <---
       LLC     802.2 LLC Header        (3 bytes)
       SNAP                            (5 bytes)
       Data    Protocol Data           (46 - 1492 bytes)
       FCS     Frame Checksum          (4 bytes)

Regardless of the existence of 802.2's length field, you can always detect the end of an ethernet frame on the wire by looking for the 96-bit Interframe Gap.

Is the logical separation performed using the "EtherType" protocol field? (i.e. obtaining the packet length using the type of the higher-level protocol, that has a length field in it's headers).

By logical separation, I assume you mean separation between different protocols carried inside ethernet, such is distinguishing between IPv4, IPv6 or perhaps Spanning-Tree Frames.

Ethernet II normally uses the Type field
802.2 LLC Ethernet normally uses the five-byte 802.2 Ethernet SNAP extension. Protocols are only decoded with the SNAP extension when the 802.2 DSAP / SSAP bytes are 0xAAAA.

Is the physical distinction is simply non-transmission of electrical signals? (To my knowledge, high/low electrical signals are representing 0/1 bits)

Simplistically, yes there is a 96-bit gap between Ethernet frames; however, note that ethernet uses an 8b/10b encoding (FastEthernet) and 64b/66b encoding (GigabitEthernet), so it's not technically correct to say the "non-transmission of electrical signals", since 8b/10b doesn't have a "silent" state.

For the curious, I'm also linking to the original Ethernet Version 2 spec.

Best Answer

Related Solutions

Ethernet – Extend MACSec encryption over provider bridge

Ethernet – Detecting different Ethernet frames

Related Topic