Notes - WAN MACsec White Paper
Last updated
Last updated
Previously, IPsec has been the method for encryption in the WAN, usually over the internet. IPsec operates at layer 3 and can operate over any IP transport. However, bandwidth demands are outpacing the encryption rates that IPsec can support.
MACsec offers encryption directly at layer 2 over Ethernet, and gives you simplification and line-rate forwarding. The encryption is per-port since it is operating at the Ethernet layer. The forwarding rate of MACsec can match the ethernet port rate (1/10/40/100Gbps, etc). MACsec is performed in hardware, while IPsec must be performed on an ASIC. So with MACsec there is no performance impact.
In MACsec, the frame is always in the clear between the time the frame is decrypted after ingress and encrypted upon egress. This allows you to do policy routing, QoS, etc. because the frame is in clear text within the router. MACsec also doesn’t require you to tune MSS (you can support jumbo frames) and you don’t need to define policy statements for interesting traffic to encrypt.
On the ASR9000, the frame is decrypted first upon ingress. Then all ingress functions can take place, such as MPLS label manipulation, queuing, scheduling, ACLs, etc. On egress, the encryption is done last, which allows all egress functions to still work as well.
One negative for MACsec is that the number of SAs per port is limited. For example, an ASR 1001 10GE port might only support a max of 64 SAs. To allow for hitless rollover, this number becomes 32. That means you cannot support more than 32 MACsec subinterfaces on a port. With IPsec, the number of SAs is typically not a concern (usually in the 1000s).
802.1AE was standardized in 2006 by the IEEE 802.1 working group. 802.1AE defines MACsec, which enables devices on a point-to-point or shared Ethernet network to provide confidentiality, integrity, and authenticity for user data.
An additional 16 byte MACsec security tag is added, as well as a ICV (Integrity Check Value) at the end of the frame.
0x88e5 is the Ethertype, which is used for a MACsec frame
TCI/AN is the tag control information/association number field
SL is short length, which is the length of the encrypted data
PN is the packet number, which is used for replay protection
SCI is the secure channel identifier
The current MACsec standard encrypts all fields after the SecTAG, which obfuscates the MPLS label, 802.1Q fields, etc. This might create an issue when using EoMPLS, as MACsec between two CEs hides the 802.1Q field from the PEs. The MACsec header offset can be used to leave some fields in clear text. This is not defined in the standard. However it is used in “WAN MACsec” to allow for EVPL services.
The MKA (MACsec Key Agreement) is how MACsec peers are discovered and how the security keys are negotiated. You can generate key material for use with MKA from:
PSK
EAP
Key distributed by MKA key server
When using a PSK, the PSK is used as the connectivity association key (CAK). The connectivity association key name (CKN) is manually entered and stored in the config. The CAK is then used to generate the rest of the MACsec encryption keys: ICK (integrity check key), KEK (key encrypting key), and SAK (secure association key).
When 802.1X/EAP is used, a master session key (MSK) is obtained through EAP. This generates the CAK and CKN. The CAK is again used to generated the ICK, KEK, and SAK.
MACsec can be applied on a per-interface or per-subinterface basis. You define a key chain and apply it to the interface as follows:
WAN MACsec adds:
802.1Q tag in the clear
MKA standard keying (which allows for multivendor interoperability)
Authentication Adaptability over carrier ethernet
The 802.1Q tag must be in the clear for certain carrier ethernet designs where the VLAN tag is used as a multiplexer. For example, if the customer has a hub site where 3 vlan tags are used, one per remote branch, the CE cannot encrypt the dot1q tag in MACsec, as the PE is using this field to determine which EPL to use. Therefore the CE needs to leave the 802.1Q tag in the clear.
Bullet three works around an issue where the MKA process uses a “for me” well known MAC which the provider equipment might consume and drop. Cisco introduced the ability for the operator to change the EAPoL destination address and/or EtherType so that the provider’s bridge does not consume the traffic, and instead it is properly tunneled.
A simple EPL does not require any special considerations. It seems you can just deploy regular MACsec. You might need to consider whether the carrier equipment will tunnel the MKA frames.
An EVPL, in which the VLAN tag is used for multiplexing EPLs at a location, requires the dot1q tag to be in the clear.
MACsec can be used as per-hop encryption within the service provider MPLS network. You don’t need to make any considerations for label encryption, as the label will be exposed upon decryption. MACsec doesn’t make any changes to MPLS traffic engineering, label operations, OAM, etc. The only consideration (not mentioned in this white paper) might be timing for 5G networks. MACsec presents some problems for accurate PTP timestamping - is the timestamp taken before or after encryption/decryption? Variable encryption/decryption rates could make PTP less accurate. This is mentioned in the book, Synchronizing 5G Mobile Networks.
MACsec can be used at the PE-CE link in order to achieve an end-to-end encryption without the complexity of IPsec. It just requires that the provider is running MACsec on their internal links as well.
