Securing Overlay Transport Virtualization (OTV) with Cisco TrustSec (CTS)
Read NX-OS and Cisco Nexus Switching: Next-Generation Data Center Architectures, 2nd Edition or more than 24,000 other books and videos on Safari Books Online. Start a free trial today.
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Data Center Interconnection (DCI) has become quite common in the past few years for a multitude of reasons, including workload mobility, data center migration, and enhanced disaster recovery posture, to name a few. Of the many DCI technologies that are available, Cisco's Overlay Transport Virtualization (OTV) has been widely deployed by customers in every vertical across the world.
OTV has many unique benefits in the DCI arena, including a scalable control plane protocol, ease of site additional and removal, optimized traffic localization capabilities, and the ability to use existing network infrastructure to provide connectivity. OTV is currently available on the flagship data center switching platform, the Cisco Nexus 7000, as well as the Cisco ASR 1000 series of routers that together provide an OTV solution to meet almost any customer's requirements.
For many customers, regulatory requirements or internal policies dictate that network traffic must be encrypted when passing between data centers.
Traditionally, there have been a few ways to facilitate this, ranging from dedicated and expensive hardware-based encryption devices that sit inline or the use of various VPN technologies such as IPSec to provide encryption services. See Figure 1.
)
One alternative to these technologies is using 802.1AE MACSEC on the Nexus 7000 to provide hardware-based, line rate encryption on the Data Center Interconnect links. 802.1AE MACSEC is an IEEE standard for link level encryption. The implementation of MACSEC on the Nexus 7000 is 128-bit Advanced Encryption Standard (AES) that is hardware-driven, which means no additional Supervisor CPU is used to encrypt data at any speeds.
As of the writing of this article, the M-Series modules on the Nexus 7000 support 802.1AE MACSEC on all ports, including the new M2-series modules. The F2e modules will have this feature enabled in the future.
It is important to note that because 802.1AE MACSEC is a link-level encryption, the two MACSEC-enabled endpoints, Nexus 7000 devices in our case, must be directly L2 adjacent. This means we direct fiber connection or one facilitated with optical gear is required. MACSEC has integrity checks for the frames and intermediate devices, like another switch, even at L2, will cause the integrity checks to fail. In most cases, this means metro-Ethernet services or carrier-provided label switched services will not work for a MACSEC connection. We will focus on a direct connection scenario in this article.
Figure 2 shows two data centers with OTV configured to provide data center interconnect services. The DCI link in this example is interface Ethernet4/1 on both of the Nexus switches. Prior to enabling CTS, the interface configuration looked like this:
version 6.1(2) interface Ethernet4/1 no ip redirects ip address 10.1.0.21/30 ip ospf network point-to-point ip router ospf 100 area 0.0.0.0 ip pim sparse-mode no shutdown N7K-1-Core#
)
To enable CTS, we simply need to add the following commands that will do the following:
- Enable cts and dot1x as a feature.
- Configure cts manual mode.
- Define a preshared key.
- Increase the interface MTU to accommodate the extra header 802.1AE MACSEC adds.
The last step is important because CTS won't take effect until the interface is flapped with a shut/no shut sequence.
N7K-1-Core# config Enter configuration commands, one per line. End with CNTL/Z. N7K-1-Core(config)# feature dot1x N7K-1-Core(config)# feature cts N7K-1-Core(config)# interface ethernet4/1 N7K-1-Core(config-if)# cts manual N7K-1-Core(config-if-cts-manual)# sap pmk d00df001 N7K-1-Core(config-if-cts-manual)# exit N7K-1-Core(config-if)# mtu 9216 N7K-1-Core(config-if)# shut N7K-1-Core(config-if)# no shut N7K-1-Core(config-if)# end N7K-1-Core#
Once configured, you can verify that CTS is in use by looking at the interface:
N7K-1-Core# show cts interface e4/1
CTS Information for Interface Ethernet4/1:
CTS is enabled, mode: CTS_MODE_MANUAL
IFC state: CTS_IFC_ST_CTS_OPEN_STATE
Authentication Status: CTS_AUTHC_SKIPPED_CONFIG
Peer Identity:
Peer is: Unknown in manual mode
802.1X role: CTS_ROLE_UNKNOWN
Last Re-Authentication:
Authorization Status: CTS_AUTHZ_SKIPPED_CONFIG
PEER SGT: 0
Peer SGT assignment: Not Trusted
SAP Status: CTS_SAP_SUCCESS
Configured pairwise ciphers: GCM_ENCRYPT
Replay protection: Enabled
Replay protection mode: Strict
Selected cipher: GCM_ENCRYPT
Current receive SPI: sci:f866f2ac5aa80000 an:3
Current transmit SPI: sci:30e4db1c019c0000 an:3
Propagate SGT: Enabled
N7K-1-Core#
The bold text shows that the encryption is active and negotiated.
Be sure to enable CTS on both ends of the link because if only one end is configured and the interface is flapped, the link will not come up as shown below:
N7K-1-Core# show int e4/1 Ethernet4/1 is down (Authorization pending) admin state is up, Dedicated Interface
That's it! How easy is that?! A few more thoughts on using CTS MACSEC for Data Center Interconnect:
- No need to change routing protocols or other L2 protocols to understand MACSEC; because it is link-level encryption, it is transparent to the upper-layer technologies.
- Optical taps don't work because the data is encrypted! SPAN/ERSPAN will still allow visibility into the frame as the CTS header is removed before the traffic is replicated.
- Remember that 40 bytes are added for CTS—16 for the 802.1AE header, 8 bytes for the Cisco MetaData, and 16 for the Integrity Check Value (ICV). Plan your MTU accordingly, and if you are using OTV, remember that it adds 42 more bytes.
- CTS was moved into the NX-OS base license as of NX-OS 6.1 on the Nexus 7000.
Cisco TrustSec and 802.1AE MACSEC provide a very attractive alternative to expensive external devices that take rack space, power, and cooling resources in my data center. Being transparent to the upper-layer protocols enables more ways to deploy line-rate encryption.