Close

Celebrating Aruba Control Plane Security

By Chris Grundemann, Blog Contributor
Share Post

Since it was announced this past January, then launched in June, WPA3 has been dominating the Wi-Fi network security headlines. This is well deserved, as it represents a major step forward in several key areas of Wi-Fi security. Today, however, I want to celebrate an often-overlooked security feature offered by Aruba: Control Plane Security (CPSec).

To Secure Users, First Secure the Network

While WPA3 provides many new security protections, including individualized data encryption, none can help users who mistakenly connect to a compromised or rogue AP. To ensure your users’ security, you must first secure your network. That’s where CPSec comes in.

CPSec does two things. First, it uses IPSec to provide a secure, encrypted communication channel between authorized APs and mobility controllers. Second, it allows you to define the allowlist of authorized APs.

IPSec

Probably the most obvious benefit of enabling CPSec is that it encrypts all of the control plane communication between authorized APs and their controllers. This encryption is handled with the industry-standard, public-key, certificate-based IPSec protocol suite. Two types of certificates can be used to certify an AP and encrypt its control plane messages:

  • Self-signed certificates – When using self-signed certificates, the Conductor controller generates the certificates and then sends them to local controllers, which use them to certify the APs terminating on that controller. If there are no local controllers, the Conductor sends its certificates directly to the APs that it terminates.
  • Factory-installed certificates – Newer AP models are equipped with a TPM (Trusted Platform Module) chip, which stores a unique certificate. These APs (models from AP-105 & AP-12** and above) do not need a certificate downloaded from the Conductor controller.

In both cases, the certificates enable IPSec encryption for all control/management plane communication. Since the Conductor controller is the trust anchor, APs can failover between local controllers without issue.

Campus AP Allowlist

While the benefits of encrypting traffic, especially the traffic that controls your Wi-Fi network, may be obvious, another benefit of enabling (and properly managing) CPSec is perhaps just as important: AP allowlisting.

You may have noticed that I used the term ‘authorized APs’ above. When using CPSec, only authorized APs are allowed to communicate with controllers. You authorize an AP by adding its MAC address (and an optional description) to the Campus AP allowlist. This gives you specific and direct control over which APs are allowed to join your Wi-Fi network. No more rogue APs!

CPSec Fun Facts

While configuring CPSec is super simple, I have seen quite a few colleagues tripped up with some of the details. To help combat that, here are a few fun facts, things to be aware of, potential pitfalls to avoid, and general notes:

  • CPSec is enabled by default for new deployments. This is ideal, as enabling it is a best practice, and turning it on later can cause several minutes of downtime as APs reboot to enable secure communication.
  • The Campus AP allowlist can be created manually (the default) or automatically. Automatic essentially authorizes any AP that contacts the controller, so this method should only be used when you are sure there are no rogue APs present. You can limit the automatic authorization with an IP range. I strongly recommend that even when you use automatic (auto-cert) provisioning, you disable it after initial setup to prevent unwanted APs.
  • Once an AP is authorized, you can revoke its certificate or simply delete it from the allowlist. This is great if you find a rogue AP or need to replace an AP.
  • The Campus AP allowlist is synchronized between all Conductor and Member controllers. This is great in day-to-day operations but can be troublesome if you move a mobility controller to a new campus. Be sure to always purge the allowlist before redeploying a controller.
  • When using CPSec, user traffic is unaffected. It is still sent via GRE tunnel.
  • CPSec cannot be used with Remote APs (RAP). Since RAPs already encrypt all traffic (user and control) with IPSec, adding CPSec to double-encrypt control plane traffic would add too much overhead and is not an option. Also, when using RAP and CPSec, there are two allowlists, one for Campus APs and one for Remote APs.
  • Currently, CPSec only supports IPv4. This is a major bummer, but for now, if your controller terminates any IPv6 APs, do not enable CPSec.

Tl;dr:

While WPA3 is all the rage these days, don’t forget basic security hygiene. Aruba’s CPSec is a valuable tool that is both simple and powerful. To learn more, check out the “Control Plane Security” chapter in your ArubaOS User Guide.

Follow Chris Grundemann on Twitter @ChrisGrundemann.