Skip to main content
Cisco SD-WAN
Product Documentation
Viptela Documentation

Control Plane Security Overview

The control plane of any network is concerned with determining the network topology and defining how to direct packets. In a traditional network, the control plane operations of building and maintaining routing and forwarding tables and directing packets towards their destination are handled by routing and switching protocols, which typically offer few or no mechanisms for authenticating devices or for encrypting routing updates and other control information. In addition, the traditional methods for providing security are highly manual and do not scale. As examples, certificates are typically installed manually rather than in an automated fashion, and using preshared keys is not a very secure approach for providing device security.

The Viptela control plane has been designed with network and device security in mind. The foundation of the control plane is one of two security protocols derived from SSL (Secure Sockets Layer)—​the Datagram Transport Layer Security (DTLS) protocol and the Transport Layer Security (TLS) protocol. The vSmart controller, which is the centralized brain of the Viptela solution, establishes and maintains DTLS or TLS connections to all Viptela devices in the overlay network: to the vEdge routers, the vBond orchestrators, to vManage NMSs, and to other vSmart controllers. These connections carry control plane traffic. DTLS or TLS provides communication privacy between Viptela devices in the network, using the Advanced Encryption Standard (AES-256) encryption algorithm to encrypt all control traffic sent over the connections.

The privacy and encryption in the control plane offered by DTLS and TLS provide a safe and secure foundation for the other two security components, authentication and integrity. To perform authentication, the Viptela devices exchange digital certificates. These certificates, which are either installed by the software or hard-coded into the hardware, depending on the device, identify the device and allow the devices themselves to automatically determine which ones belong in the network and which are imposters. For integrity, the DTLS or TLS connections run SHA-1 or SHA-2, a cryptographic secure hash algorithm which ensures that all control and data traffic sent over the connections has not been tampered with.

s00142.pngThe following are the control plane security components, which function in the privacy provided by DTLS or TLS connections:

  • AES-256 encryption algorithm provides encryption services.
  • Digital certificates are used for authentication.
  • SHA-1 or SHA-2 is responsible for ensuring integrity.

DTLS and TLS Infrastructure

Security protocols derived from SSL provide the foundation for the Viptela control plane infrastructure.

The first is the DTLS protocol, which is a transport privacy protocol for connectionless datagram protocols such as UDP, provides the foundation for the Viptela control plane infrastructure. It is based on the stream-oriented Transport Layer Security (TLS) protocol, which provides security for TCP-based traffic. (TLS itself evolved from SSL.) The Viptela infrastructure design uses DTLS running over UDP to avoid some of the issues with TCP, including the delays associated with stream protocols and some security issues. However, because UDP performs no handshaking and sends no acknowledgments, DTLS has to handle possible packet re-ordering, loss of datagrams, and data larger than the datagram packet size.

The control plane infrastructure can also be configured to run over TLS. This might be desirable in situations where the protections of TCP outweigh its issues. For example, firewalls generally offer better protection for TCP servers than for UDP servers.

The Viptela software implements the standard version of DTLS with UDP, which is defined in RFC 6347. DTLS for use with other protocols is defined in a number of other RFCs. For TLS, the Viptela software implements the standard version defined in RFC 5246.

s00035.pngIn the Viptela architecture, the Viptela devices use DTLS or TLS as a tunneling protocol, which is an application-level (Layer 4) tunneling protocol. When the vSmart controllers, vBond orchestrators, vManage NMSs, and vEdge routers join the network, they create provisional DTLS or TLS tunnels between them as part of the device authentication process. After the authentication process completes successfully, the provisional tunnels between the vEdge routers and vSmart controllers, and those between the vBond orchestrators and vSmart controllers, become permanent and remain up as long as the devices are active in the network. It is these authenticated, secure DTLS or TLS tunnels that are used by all the protocol applications running on the Viptela devices to transport their traffic. For example, an OMP session on a vEdge router communicates with an OMP session on a vSmart controller by sending plain IP traffic through the secure DTLS or TLS tunnel between the two devices. (The Overlay Management Protocol is the Viptela control protocol used to exchange routing, policy, and management information among Viptela devices, as described in Overlay Routing Overview.)

s000074.pngA Viptela daemon running on each vSmart controller and vEdge router creates and maintains the secure DTLS or TLS connections between the devices. This daemon is called vdaemon and is discussed later in this article. After the control plane DTLS or TLS connections are established between these devices, multiple protocols can create sessions to run and route their traffic over these connections—including OMP, Simple Network Management Protocol (SNMP), and Network Configuration Protocol (Netconf)—without needing to be concerned with any security-related issues. The session-related traffic is simply directed over the secure connection between the vEdge routers and vSmart controllers.

Control Plane Authentication

The Viptela control plane uses digital certificates with 2048-bit RSA keys to authenticate the Viptela devices in the network. The digital certificates are created, managed, and exchanged by standard components of the public key infrastructure, or PKI:

  • Public keys—These keys are generally known.
  • Private keys—These keys are private. They reside on each Viptela device and cannot be retrieved from the device.
  • Certificates signed by a root certification authority (CA)—The trust chain associated with the root CA needs to be present on all Viptela devices.

In addition to standard PKI components, the Viptela device serial numbers and the vEdge router chassis numbers are used in the authentication processes.

Let's first look at the PKI components that are involved in device authentication. On vEdge routers, the public and private keys and the certificates are managed automatically, by a Trusted Board ID chip that is built into the router. When the routers are manufactured, this chip is programmed with a signed certificate, which includes the device's public key and its serial number, and the device's private key. When the vEdge routers boot up and join the network, they exchange their certificates (including the device's public key and serial number) with other Viptela devices as part of the device authentication process. For networks with thousands or tens of thousands of vEdge routers, providing an automated process for managing keys and certificates greatly simplifies the task of maintaining security across the edge devices in the network. (Note that the vEdge router's private key always remains embedded in the router's Trusted Board ID chip, and it is never distributed, nor can it ever be retrieved from the device. In fact, any brute-force attempt to read the private key causes the Trusted Board ID chip to fail, thereby disabling all access to the router.)

For vSmart controllers, vBond orchestrators, and vManage NMS systems, the public and private keys and the certificates are managed manually. When you boot these devices for the first time, the Viptela software generates a unique private key–public key pair for each software image. The public key needs to be signed by the CA root. The network administrator then requests a signed certificate and manually installs it and the certificate chains on the vSmart controllers, vBond orchestrators, and vManage NMS systems. A typical network might have only a small handful of vSmart controllers, vBond orchestrators, and vManage NMSs, so the burden of manually managing the keys and certificates on these devices is small.

To augment these standard PKI components, the Viptela software uses the device serial numbers in performing automatic device authentication. Specifically, it uses the vEdge and vSmart serial numbers and the vEdge chassis numbers. When a batch of vEdge routers is shipped, the manufacturer sends a text file that lists the serial numbers of the vEdge routers and the corresponding chassis numbers. For the vSmart controllers, when the network administrator receives the signed certificate, they should extract the serial numbers from the certificates and place them into a single text file, one serial number per line. Then the network administrator manually installs these two files. The file received from the manufacturer that lists all valid vEdge serial and chassis numbers is uploaded and installed on vSmart controllers. Both the vEdge authorized serial number file and the file listing the vSmart serial numbers are uploaded and installed on vBond orchestrators. Then, during the automatic authentication process, as pairs of devices are establishing DTLS control connections between them, each device compares the serial numbers (and for vEdge routers, the chassis numbers) to those in the files installed on the device. A devices allows a connection to be established only if the serial number or serial–chassis number combination (for a vEdge router) matches.

You can display the installed vSmart authorized serial numbers using the show control valid-vsmarts command on a vSmart controller or a vEdge router and the show orchestrator valid-vsmarts command on a vBond orchestrator. You can display the installed vEdge authorized serial and chassis number associations using the show control valid-vedges command on a vSmart controller and the show orchestrator valid-devices command on a vBond orchestrator

Now, let's look at how the PKI authentication components and the device serial and chassis numbers are used to authenticate devices on the Viptela overlay network. When vSmart controllers, vBond orchestrators, and vEdge routers first boot up, they establish secure DTLS or TLS connections between them. Over these connections, the devices authenticate each other, using the public and private keys, the signed certificates, and the device serial numbers and performing a series of handshake operations to ensure that all the devices on the network are valid and not imposters. The following figure illustrates the key and certificate exchange that occurs when the Viptela devices boot. For details about the authentication that occurs during the bringup process, see Bringup Sequence of Events.


Control Plane Encryption

Control plane encryption is done by either DTLS, which is based on the TLS protocol, or TLS. These protocol encrypt the control plane traffic that is sent across the connections between Viptela devices to validate the integrity of the data. TLS uses asymmetric cryptography for authenticating key exchange, symmetric encryption for confidentiality, and message authentication codes for message integrity.

A single Viptela device can have DTLS or TLS connections to multiple Viptela devices, so vdaemon creates a kernel route for each destination. For example, a vEdge router would typically have one kernel route, and hence one DTLS or TLS connection, for each vSmart controller. Similarly, a vSmart controller would have one kernel route and one DTLS or TLS connection for each vEdge router in its domain.


Control Plane Integrity

The Viptela design implements control plane integrity by combining two security elements: SHA-1 or SHA-2 message digests, and public and private keys.

SHA-1 and SHA-2 are cryptographic hash functions that generate message digests (sometimes called simply digests) for each packet sent over a control plane connection. SHA-1 generates a 160-bit message digest. SHA-2 is a family that consists of six hash functions with digests that are 224, 256, 384, or 512 bits. The receiver then generates a digest for the packet, and if the two match, the packet is accepted as valid. Both SHA-1 and SHA-2 allow verification that the packet's contents have not been tampered with.

The second component of control plane integrity is the use of public and private keys. When a control plane connection is being established, a local Viptela device sends a challenge to a remote device. The remote device encrypts the challenge by signing it with its private key, and returns the signed challenge to the local device. The local device then uses the remote device's public key to verify that the received challenge matches the sent challenge.

Then, once a control plane connection is up, keys are used to ensure that packets have been sent by a trusted host and were not inserted midstream by an untrusted source. The authenticity of each packet is verified through encryption and decryption with symmetric keys that were exchanged during the process of establishing the control connection.

  • Was this article helpful?