MACsec
MACsec
Section titled “MACsec”Summary
Section titled “Summary”MACsec (Media Access Control Security) is a standard security technology defined by IEEE 802.1AE that provides confidentiality, integrity, and authenticity for data transmitted over Ethernet networks. Unlike IPsec which operates at the network layer, MACsec secures traffic at the data link layer, encrypting all Ethernet frames including DHCP, ARP, LLDP, and higher-layer protocols.
MACsec utilizes GCM-AES-128 encryption to protect traffic between directly connected devices. Each MACsec-protected link forms a secure association using connectivity association keys (CAK) and connectivity association names (CKN) for authentication, with the MACsec Key Agreement (MKA) protocol managing key distribution and session maintenance.
On MikroTik RouterOS, MACsec interfaces function like standard Ethernet interfaces and can be assigned IP addresses, placed in bridges, or used with any interface-based feature. This makes MACsec suitable for securing point-to-point links between routers, switches, hosts, and other network devices where layer 2 security is required.
How MACsec Works
Section titled “How MACsec Works”Encryption and Security
Section titled “Encryption and Security”MACsec encrypts Ethernet frames using GCM-AES-128, providing cryptographic protection for all traffic on a secured link. When MACsec is enabled, the interface operates in one of two modes: authenticated (without encryption) or encrypted. The default mode encrypts all traffic, ensuring that even metadata like ARP requests and DHCP transactions cannot be intercepted.
The encryption covers the entire Ethernet payload but preserves the original source and destination MAC addresses. This allows switches to continue forwarding frames based on MAC tables while the payload remains protected. Frames include an integrity check value (ICV) that recipients verify to ensure frames have not been tampered with in transit.
MACsec Key Agreement (MKA)
Section titled “MACsec Key Agreement (MKA)”The MKA protocol manages the lifecycle of MACsec sessions. When two devices establish a MACsec link, they first authenticate using pre-shared CAK/CKN pairs. Once authenticated, MKA elects a key server (in point-to-point connections, one endpoint becomes the key server) which generates Secure Association Keys (SAK). These SAKs encrypt the actual data traffic and are periodically refreshed to maintain security.
MKA continuously monitors the link health and manages key rollover. If the link is interrupted or keys expire, MKA renegotiates the secure association. The protocol ensures that only authorized devices can participate in the MACsec domain and that encryption keys are never transmitted in cleartext.
MACsec Frame Format
Section titled “MACsec Frame Format”MACsec adds a Secure Content Identifier (SCI) and optional Secure Tag to each Ethernet frame. The SCI uniquely identifies the transmitting device and secure association, while the Secure Tag includes a packet number used with the SAK to generate unique encryption for each frame. This prevents replay attacks where an attacker might resend previously captured frames.
Basic Configuration
Section titled “Basic Configuration”Simple Two-Host Configuration
Section titled “Simple Two-Host Configuration”The most straightforward MACsec deployment connects two hosts directly. Each device creates a MACsec interface bound to its physical Ethernet port. RouterOS can automatically generate the CAK and CKN if not specified, which you can retrieve after creation.
# On Host1/interface macsecadd interface=ether1 name=macsec1
# Verify and note the auto-generated keys/interface macsec print show-sensitiveFlags: I - inactive, X - disabled, R - running 0 name="macsec1" mtu=1468 interface=ether1 status="negotiating" cak=71a7c363794da400dbde595d3926b0e9 ckn=f2c4660060169391d29d8db8a1f06e5d4b84a128bad06ad43ea2bd4f7d21968f profile=default
# On Host2/interface macsecadd interface=ether1 name=macsec1
# Verify and note the auto-generated keys/interface macsec print show-sensitiveFlags: I - inactive, X - disabled, R - running 0 name="macsec1" mtu=1468 interface=ether1 status="negotiating" cak=dc47d94291d19a6bb26a0c393a1af9a4 ckn=e9bd0811dad1e56f06876aa7715de1855f1aee0baf5982ac8b508d4fc0f162d9 profile=defaultAfter creating the interfaces, verify the connection status transitions from “negotiating” to “open-encrypted”:
/interface macsec printFlags: I - inactive, X - disabled, R - running 0 R name="macsec1" mtu=1468 interface=ether1 status="open-encrypted" cak=*o \ ckn=*o profile=defaultSwitch Configuration with Pre-Shared Keys
Section titled “Switch Configuration with Pre-Shared Keys”When deploying MACsec through a switch, you must manually configure matching CAK/CKN pairs on both ends. The switch needs the exact keys from each connected device. This example assumes Host1 connects to switch ether1 and Host2 connects to switch ether2.
# On the switch, configure MACsec for Host1/interface macsecadd comment=Host1 cak=71a7c363794da400dbde595d3926b0e9 \ ckn=f2c4660060169391d29d8db8a1f06e5d4b84a128bad06ad43ea2bd4f7d21968f \ interface=ether1 name=macsec-host1
# On the switch, configure MACsec for Host2/interface macsecadd comment=Host2 cak=dc47d94291d19a6bb26a0c393a1af9a4 \ ckn=e9bd0811dad1e56f06876aa7715de1855f1aee0baf5982ac8b508d4fc0f162d9 \ interface=ether2 name=macsec-host2Using MACsec with IP Addresses
Section titled “Using MACsec with IP Addresses”After establishing the MACsec link, configure IP addresses just like any other interface:
# Host1 configuration/ip addressadd address=192.168.10.10/24 interface=macsec1
# Host2 configuration/ip addressadd address=192.168.10.20/24 interface=macsec1
# Verify connectivityping 192.168.10.20Using MACsec with Bridge
Section titled “Using MACsec with Bridge”For layer 2 forwarding, add MACsec interfaces to a bridge:
# Switch configuration/interface bridgeadd name=bridge1
/interface bridge portadd bridge=bridge1 interface=macsec-host1add bridge=bridge1 interface=macsec-host2Use Cases
Section titled “Use Cases”Securing Sensitive Data Center Links
Section titled “Securing Sensitive Data Center Links”MACsec provides per-link encryption for connections between servers and switches in data center environments. This protects against physical tampering where someone might tap into Ethernet cables to intercept traffic. Since MACsec encrypts all layer 2 traffic, including storage protocols like iSCSI and management traffic like IPMI, sensitive data remains protected even on internal networks.
Deploy MACsec on uplinks between Top-of-Rack switches and aggregation switches, and on server connections where PCI-DSS or other compliance requirements mandate encryption. The encryption is transparent to applications and operating systems, requiring no changes to existing workloads.
Protecting Industrial Control Networks
Section titled “Protecting Industrial Control Networks”Industrial environments often have physical security concerns where network cables may be accessible in manufacturing floors or utility substations. MACsec secures SCADA traffic, PLC communications, and other operational technology without modifying industrial protocols or adding encapsulation overhead that could affect real-time requirements.
Site-to-Site Ethernet Links
Section titled “Site-to-Site Ethernet Links”For organizations using carrier Ethernet services to connect locations, MACsec adds an additional layer of security beyond what the service provider offers. This ensures that even if the provider’s network is compromised, traffic remains encrypted end-to-end. This is particularly valuable for financial institutions, healthcare organizations, and government agencies with strict data protection requirements.
Property Reference
Section titled “Property Reference”Interface Settings
Section titled “Interface Settings”Sub-menu: /interface/macsec
| Property | Type | Description | Default |
|---|---|---|---|
| cak | string | A 16-byte pre-shared connectivity association key (CAK) in hexadecimal format. Configure matching CAK and CKN on both ends to enable MACsec. Leave unset for automatic random generation. | auto-generated |
| ckn | string | A 32-byte connectivity association name (CKN) in hexadecimal format. Configure matching CAK and CKN on both ends to enable MACsec. Leave unset for automatic random generation. | auto-generated |
| comment | string | Short description of the interface for identification purposes. | |
| disabled | yes | no | Disables or enables the MACsec interface without removing configuration. | no |
| interface | name | The underlying Ethernet interface where MACsec is enabled. Each physical interface supports only one MACsec interface. | |
| mtu | integer | Maximum transmission unit for the MACsec interface. The Layer 2 MTU is derived from the parent interface minus 32 bytes for MACsec encapsulation and cannot be changed manually. | 1468 |
| name | string | Administrative name for the MACsec interface. | macsecN |
| profile | name | MACsec profile name that determines key server behavior. | default |
| status | read-only | Current operational status: disabled, initializing, invalid, negotiating, or open-encrypted. |
Profile Settings
Section titled “Profile Settings”Sub-menu: /interface/macsec/profile
| Property | Type | Description | Default |
|---|---|---|---|
| name | string | Name identifier for the MACsec profile. | |
| server-priority | integer: 0..255 | Priority for key server election in point-to-point connections. Lower values indicate higher priority. If priorities match, the interface with the lower MAC address becomes the key server. | 10 |
Status Values
Section titled “Status Values”The MACsec interface status indicates the current state of the secure association:
- disabled: Interface is administratively disabled
- initializing: Interface is starting up and performing initial negotiation
- invalid: CAK/CKN authentication failed or keys do not match peer
- negotiating: Keys matched but MKA session is still establishing
- open-encrypted: Secure association established and traffic is encrypted
Profile Configuration
Section titled “Profile Configuration”Understanding Key Server Election
Section titled “Understanding Key Server Election”In a point-to-point MACsec connection, one device must act as the key server to generate and distribute SAKs. The key server election uses the server-priority value, with lower values winning. If both devices have the same priority, the device with the lower MAC address becomes the key server.
# Create a profile with custom priority/interface macsec/profileadd name=high-priority server-priority=5
# Apply the profile to the interface/interface macsec set [find name=macsec1] profile=high-priorityMultiple Profile Scenarios
Section titled “Multiple Profile Scenarios”Multiple profiles are useful when connecting to different devices that may have different key server preferences or when managing complex multi-vendor environments. Each MACsec interface references one profile, and the profile settings affect only that interface’s key server behavior.
Performance Considerations
Section titled “Performance Considerations”CPU Impact
Section titled “CPU Impact”MACsec encryption in RouterOS is performed entirely in software by the CPU. This means throughput is limited by the device’s processor speed rather than interface speeds. For example, a CCR2004 might achieve significantly lower throughput on a MACsec link compared to its non-encrypted interfaces.
When planning MACsec deployments, benchmark realistic traffic patterns before production deployment. Sustained high-throughput workloads may not achieve expected performance levels. Consider the aggregate throughput requirements across all MACsec interfaces when sizing hardware.
MTU Considerations
Section titled “MTU Considerations”MACsec encapsulation adds 32 bytes to each frame (16 bytes for the Secure Tag and 16 bytes for the ICV). RouterOS automatically sets the L2MTU to the parent interface value minus 32 bytes. This means the effective MTU for payloads is reduced by 32 bytes.
If the parent interface supports jumbo frames (9000 byte MTU), the MACsec interface will have an L2MTU of 8968 bytes. Ensure that Path MTU Discovery accounts for this reduction, particularly for VPN tunnels or other encapsulated traffic that might already have overhead.
Latency Impact
Section titled “Latency Impact”The encryption process adds per-packet processing latency. While minimal for small frames, high-frequency trading or real-time control systems should test MACsec latency impact before deployment. The key rollover process (typically every few seconds) does not interrupt traffic but involves cryptographic operations that may cause micro-bursts in latency.
Troubleshooting
Section titled “Troubleshooting”Interface Stuck in Negotiating
Section titled “Interface Stuck in Negotiating”If the status remains “negotiating” for extended periods:
- Verify CAK and CKN match exactly on both ends (32 hex characters for CKN, 16 hex bytes for CAK)
- Confirm the physical link is operational with
/interface ethernet print - Check for firewall rules blocking EAPOL or MKA traffic (UDP ports 4789 and 6081)
- Ensure only one MACsec interface exists per physical port
- Review logs with
/log printfor MACsec-specific error messages
Status Shows Invalid
Section titled “Status Shows Invalid”An “invalid” status indicates authentication failure:
- Confirm both devices use the same CAK/CKN pair
- Verify hexadecimal format without spaces or prefixes (0x)
- Ensure no whitespace or case differences in the key strings
- Delete and recreate the interface with corrected keys if necessary
Traffic Not Passing
Section titled “Traffic Not Passing”When the interface shows “open-encrypted” but traffic fails:
- Verify IP addressing if using routed mode
- Confirm bridge membership if using layer 2 mode
- Check for firewall rules blocking traffic on the MACsec interface
- Test with
/tool pingto confirm basic connectivity - Review
/interface macsec monitorfor packet counters
Checking Packet Statistics
Section titled “Checking Packet Statistics”/interface macsec monitor [find name=macsec1]Monitor shows encrypted and decrypted packet counts, as well as dropped packet statistics. Unexpected drops may indicate MTU mismatches or resource constraints.
Limitations and Restrictions
Section titled “Limitations and Restrictions”Current RouterOS Limitations
Section titled “Current RouterOS Limitations”The RouterOS MACsec implementation has several important limitations to consider during deployment planning. Dynamic key management through 802.1X (Dot1X) is not supported, requiring manual CAK/CKN configuration on each endpoint. This increases operational complexity and the risk of key mismatches during configuration.
Hardware acceleration is not available, meaning all encryption operations use the main CPU. This significantly impacts throughput and may affect other device functions under high load. Review MikroTik’s documentation for your specific hardware model to understand expected performance characteristics.
Feature Restrictions
Section titled “Feature Restrictions”MACsec interfaces cannot be added to bonding interfaces directly. For redundant MACsec links, consider using failover bridge configurations or routing protocols with redundant paths. Additionally, MACsec on CRS3xx series switches requires specific switch chip configuration and may have hardware-specific limitations.
Compatibility Considerations
Section titled “Compatibility Considerations”MACsec requires compatible devices on both ends. While most modern switches and network adapters support IEEE 802.1AE, verify compatibility before deployment. Interoperability testing between MikroTik devices and other vendors is recommended, as implementation details may vary.