Written by guest author, R. Leigh Hennig from Markley Group
Overview
A common way to encrypt the traffic between destinations is by setting up IPSec tunnels, a suite of protocols (collectively outlined in IETF RFC 6071) used to ensure end-to-end security across an insecure network. IPsec has other benefits as well, such as the ability to connect to private resources across disparate networks—for instance, reachability to private subnets over the Internet. SSL VPNs, such as Cisco AnyConnect, offer similar features, but are typically reserved for client-to-server encryption, instead of site-to-site.
IPsec has some limitations, however, primarily in the protocol’s overhead and complexity in creating and maintaining tunnels. The algorithms (such as AES) and underlying protocols (such as IKE) that IPsec relies upon are not only computationally expensive, but also require additional headers on every single packet that traverses the tunnel, resulting in reduced network performance—higher latency, and diminished throughput.
For some scenarios, MACsec may be worth deploying—either in addition to, or instead of, IPsec.
MACsec
MACsec (IEEE 802.11ae and subsequent amendments) is an encryption standard that operates at the data-link layer of the OSI model, below the layers used by IPsec protocols. It is not a like-for-like replacement of IPsec; instead, MACsec facilitates encryption on the individual links that comprise a network. Unlike IPsec, which offers end-to-end encryption, MACsec secures point-to-point traffic between routers, switches, and firewalls. If any connection along the path is not secured with MACsec, then the traffic at that connection is insecure, and end-to-end encryption is broken. Let’s take a look:
Scenario 1: MACsec with one link not encrypted
This is a classic example of a chain only being as strong as its weakest link. MACsec needs to be configured at each interface along the entire path in order for the traffic to be encrypted. If any single link isn’t configured to use MACsec, then the entire encryption scheme is broken at that point. Someone at the point where the link is not encrypted could listen on the wire and capture your traffic.
Scenario 2: All links use MACsec
Here, the traffic from source to destination is protected, because at each hop, MACsec is encrypting. Without a gap in the chain, no one can listen to the communication.
Scenario 3: IPsec, but no MACsec
This is the more classic way of encrypting traffic. MACsec may or may not be used on some or all of the links, but that doesn’t matter, because the only two entities involved in the encryption scheme are the terminating endpoints.
| MACsec | IPsec | |
| Configuration Scope |
High (Required on every link along the entire path) |
Low (Only required on the remote endpoints) |
| Complexity |
Low (But more devices to configure) |
High (But only remote endpoints need to be configured) |
| Computational Overhead |
Low (Throughput not typically impacted) |
High (Throughput may be significantly constrained) |
| Network Throughput |
High (Little overhead—often operates at line rate, so a 10G link may not be constrained) |
Low-to-moderate (Overhead usually reduces throughput significantly—a 10G link may only support 500Mbps of encrypted traffic, or less) |
| Stability |
High (There’s no tunnel to be maintained) |
Low-to-moderate (IPsec tunnels are notoriously difficult to maintain) |
| Protocol Support |
High (MACsec operates at Layer 2, and therefore transparent to upper layer protocols such as IPv4 multicast) |
Low (Limited/no support for protocols other than IP, and multicast is not traditionally supported, necessitating additional tunnel protocols such as GRE to carry OSPF, for example) |
As shown, both encryption mechanisms have benefits, and neither replaces the other. Depending on your network environment, you may be required to use IPsec. Other scenarios may allow you to use MACsec instead. Some network providers, such as AWS, have it enabled globally. So while you don’t have control over any device in the AWS network, as long as your device supports it, then connecting to AWS DirectConnect via the Markley Network Fabric will offer you encryption along the entire network path (as the Fabric supports MACsec).
As with any decision on how to build your network and secure traffic, nuance is required when evaluating your options. In general, however, you can:
Use IPsec if…
- You don’t have the ability to configure MACsec on all links along the entire path.
- Remote connectivity to a private subnet across disparate networks is required (i.e., your remote office has a network of 10.0.0.0/8 or 192.168.1.0/24 and you need to access that across the Internet or from another untrusted network).
Use MACsec if…
- You have assurance that all links along the path also implement MACsec.
- Throughput requirements exceed the performance limitations of IPsec.
Security on the Markley Network Fabric
Some of the world’s most demanding of enterprise, research, government, and academic organizations rely on Markley for reliability, security, and performance across their network. In addition to layer 1 optical encryption between our sites, we offer MACsec encryption to our customers for their 1-, 10-, and 100G ports, allowing you to securely connect your offices with connections terminating in our facilities, as well as into AWS DirectConnect and any other supporting cloud provider.
If MACsec isn’t an option for your organization but you still need help with encryption, let us know—connecting, securing, and designing well-architected networks is what we do.
For more information about the Markley Network Fabric, visit our webpage, or contact us.
Technium Team Member Spotlight: Taylor Routt
Technium: Feb 28, 2024 10:51:22 AM
