Secure DataPlane Bringup

Secure DataPlane Bringup

Once all the Viptela device are available and are part of Overlay network , DTLS tunnels are created between all the Viptela Devices and over which Control plane information is shared. For data traffic separate One to one IPsec tunnel is formed between each vEdge device and data are sent via proper encryption method.

The underlying foundation for security in the SD-WAN data plane is the security of the control plane. The control plane is secure—all devices are validated, and control traffic is encrypted and cannot be tampered with. Therefore, you can be confident in using routes and other information learned from the control plane to create and maintain secure data paths throughout a network of WAN Edge routers.

A overview of the DTLS and IPsec Tunnel are shown in below figure.

The SD-WAN data plane implements the important security components of authentication, encryption, and integrity in the following ways:

• Authentication
• Encryption 
• Integrity 

Data Plane Authentication and Encryption

The SD-WAN implementation of data plane authentication and encryption establishes SAs between each pair of devices that want to exchange data, but it eliminates IKE. Instead, to provide a scalable solution to data plane key exchange, the SD-WAN solution takes advantage of the fact that the DTLS control plane connections in the SD-WAN overlay network are known to be secure. Since the control plane establishes authenticated, encrypted, and tamper-proof connections, there is no need in the data plane to set up secure communications channels to perform data plane authentication.

For unicast traffic, data plane encryption is performed by AES-256-GCM. Each WAN Edge router periodically generates an AES key for its data path (specifically, one key per TLOC) and transmits this key to the vSmart controller in OMP route packets, which is like IP route updates. These packets contain information that the vSmart controller uses to determine the network topology, including the WAN Edge router's TLOC (a tuple of the system IP address and traffic color) and AES key. The vSmart controller then places these OMP route packets into reachability advertisements that it sends to the other WAN Edge routers in the network. This way, the AES keys for all the WAN Edge routers are distributed across the network. Even though the key exchange is symmetric, the WAN Edge routers use it asymmetrically. The result is a simple, scalable key exchange process that uses the vSmart controller.

In SD-WAN Release 19.2.x and IOS XE SD-WAN Release 16.12.x and later, SD-WAN supports IPsec pairwise keys that provide additional security. When IPsec pairwise keys are used, the WAN Edge router generates public and private Diffie-Hellman components and sends the public value to the vSmart for distribution to all other edge devices.

If control policies that are configured on a vSmart controller limit the communications channels between network devices, the reachability advertisements sent by the vSmart controller contain information only for the WAN Edge routers that they are allowed to exchange data with. So, a WAN Edge router learns the keys only for those WAN Edge routers that they are allowed to communicate with.

To further strengthen data plane authentication and encryption, WAN Edge routers regenerate their AES keys aggressively (by default, every 24 hours). Also, the key regeneration mechanism ensures that no data traffic is dropped when the keys change.

In the SD-WAN overlay network, the liveness of SAs between WAN Edge router peers is tracked by monitoring BFD packets, which are periodically exchanged over the IPsec connection between the peers. IPsec relays the connection status to the vSmart controllers. If data connectivity between two peers is lost, the exchange of BFD packets stops, and from this, the vSmart controller learns that the connection has been lost.

The IPsec has no explicit SA idle timeout, which specifies the time to wait before deleting SAs associated with inactive peers. Instead, an SA remains active as long as the IPsec connection between two WAN Edge routers is up, as determined by the periodic exchange of BFD packets between them. Also, the frequency with which SA keys are regenerated obviates the need to implement an implicit SA idle timeout.

Centralized Encryption Key Distribution

In order to make the secure data plane, following Key distribution is done between vEdge router and vSmart Controller.

• Each vEdge advertises its own AES256 IPSec encryption key in control plane updates
• IPSec encryption keys are distributed by the vSmart Controllers
• IPSec encryption keys are frequently rotated (default 2h)

Data Plane Integrity

The following components contribute to the integrity of data packets in the SD-WAN data plane:

ESP is a standard IPsec encryption protocol that protects (through encryption and authentication) the inner header, data packet payload, and ESP trailer in all data packets.

Modifications to ESP protect (through authentication) the outer IP and UDP headers. This mimics the functionality of the authentication header protocol.

Anti-replay is part of the standard IPsec software suite. It provides a mechanism to number all data packets and ensure that receiving WAN Edge routers accept only packets with unique numbers.

The first of these components, ESP, is the standard IPsec encryption protocol. ESP protects a data packet’s payload and its inner IP header fields both by encryption, which occurs automatically, and authentication. For authentication, ESP performs a hash calculation on the data packet's payload and inner header fields using AES-GCM and places the resultant hash (also called a digest) into a field at the end of the packet. The receiving device performs the same checksum and compares its calculated hash with that in the packet. If the two checksums match, the packet is accepted. Otherwise, it is dropped. In the figure, the left stack illustrates the ESP/UDP encapsulation.

In the SD-WAN solution, there are also modifications to ESP to enhance its behavior to cover more of the datagram. The modifications function the way the authentication header works. This modification performs a checksum that includes calculating the checksum over all the fields in the packet—the payload, the inner header, and all the nonmutable fields in the outer IP header. The authentication header places the resultant hash into the last field of the packet. The receiving device performs the same checksum and accepts packets whose checksums match. In the figure, the center stack illustrates the encapsulation performed by the modified version of ESP.

Tunnel Liveliness Detection

BFD packets are bi-directionally echoed between two vEdge’s