Tunnel security and encryption

SD-WAN supports three security modes for customer data sent between bonders and aggregators.

Security modes

No security

This, as the name suggests, offers no security. It is appropriate for environments where neither data integrity nor secrecy are required. It is the least CPU-intensive option.

Hash-based message authentication codes (HMAC)

Data is signed and verified using an HMAC code. The algorithm uses MD5 hashing and a 30-byte secret key. HMAC-MD5 is defined in RFC 2104.

This security mode offers data integrity but not secrecy. That is, a receiving host can detect if an attacker has changed network data after it has been sent. However, the data is not hidden and can be seen by anyone with access to the networks between the bonder and aggregator.

Encryption

Data is encrypted between bonders and aggregators using the DTLS 1.2 protocol. DTLS is based on SSL/TLS, and is defined in RFC 4347 and RFC 6347.

Two ciphers are available:

  1. AES 128, the default due to being accelerated on some CPUs (requires 64-bit operating system)
  2. AES 256

SD-WAN offers perfect forward secrecy with all ciphers. Perfect forward secrecy is the property that encrypted traffic cannot be decrypted at a later time even if the private key is compromised.

Encryption is performed using private keys generated when the aggregator and bonder were provisioned, and hosts are authenticated with x.509 certificates signed by a certificate authority on the management server.

Each leg has its own encryption session. For example, a bond with three legs would use three independent sessions. Sessions renegotiate keys at the interval defined in the bond options—by default, every hour. This can be disabled by setting the value to 0.

Encryption increases the amount of overhead in each packet sent between the bonder and aggregator, resulting in a smaller MTU available to customers. The amount of overhead is different for each cipher. The following list shows the MTU available to the customer on a bond with 1500 byte leg MTUs.

  • No encryption: 1452 byte tunnel MTU (given that each leg has a 1500 byte MTU)
  • AES 128: 1403 byte MTU
  • AES 256: 1375 byte MTU

Encryption status

While a leg is setting up or renegotiating its encryption session, the leg icon will be displayed as a green circle with a lock: image0 This state should not persist for more than a few seconds.

When encryption is enabled, status details can be shown in the advanced pane of the Status section. This section shows the encryption protocol, cipher, MAC, and key exchange algorithm. For example:

image1

Hardware acceleration

Some CPUs offer hardware acceleration of the AES 128 cipher when installed with 64-bit operating systems. This significantly reduces the CPU load of encryption. To see if a bonder or aggregator CPU supports AES acceleration, browse to its node details page. If “AES” appears in the CPU description, AES acceleration is available.

image2

According to VMware, AES acceleration from the host CPU is passed through to ESXi guests since at least version 5.0.