Aruba ESP Policy Design
The Aruba Edge Services Platform (ESP) Policy delivers flexible and highly reliable services using Zero Trust principles that govern access to network resources. It uses role-based policy to help networks evolve from traditional methods of VLAN segmentation to identity-based access for more accurate classification and more effective mitigation of increasing threats of unsecured IoT devices and the bad actors seeking to compromise them.
When designing Aruba ESP policies, consider the means of identifying different types of users and devices accessing the network and the levels of access they require. This identifying information is crucial for creating granular role-based access policies that define the resources each client session can access and the restrictions that apply.
Table of contents
Aruba ClearPass Policy Manager and Aruba Central’s Cloud Auth service are key components for applying effective role-based policy.
ClearPass can be deployed on-premises as a physical or virtual appliance to authenticate and assign client devices the appropriate level of network access. It interfaces with internal or external repositories such as LDAP, Device Insight, and partner firewall databases to quickly establish the identity of a device or user to make an informed decision about the level of access before establishing IP connectivity.
Cloud Auth is a cloud-native security service and an integral part of Aruba Centra’s NetConductor. It integrates with a company’s existing cloud identity store, such as Google Workspace or Azure Active Directory, to authenticate and assign the appropriate level of network access, similar to ClearPass.
Aruba ESP Policy design may contain one or more of the following elements:
- Aruba Central
- Aruba ClearPass Policy Manager
- Aruba CX Switches
- ArubaOS 10 Gateways and Access Points
- Aruba Central NetConductor.
The following diagrams are high-level examples of centralized and distributed policy enforcement models.
The first diagram, the centralized model, uses user-based tunneling (UBT) to encapsulate and forward wired client traffic to the ArubaOS 10 Gateway cluster via a GRE tunnel. The Gateways decapsulate and analyze the traffic, enforce user roles and other related attributes, then forward the traffic to their corresponding destinations.
In the second diagram, the distributed model, Aruba CX switches form an EVPN-VXLAN overlay fabric. Data traffic is encapsulated and forwarded in a VXLAN tunnel that enables policy enforcement on any VXLAN-GBP-aware device configured with a corresponding role and policy.
Client Roles
Aruba ESP provides the ability to assign a role to any connected client in the network and enforce the policy for that role at any point in the network: switch, AP, or gateway.
It defines a role for every type of user or device attempting to gain access. All recipients of a role will be affected by the same policies across the network and must be grouped accordingly.
Policy rules reference roles and thereby enact policy enforcement actions based on how that rule is applied to the particular network device through which transits.
Along with 802.1X authentication, organizations can incorporate a long list of built-in and/or customizable attributes that Aruba devices support. These attributes provide additional context to enable administrators to classify and allow or disallow client device access to the network.
Available attributes include:
- Hostname
- IP address
- Location of a gateway
- MDM membership status
- Firewall traffic classification
- Client OS version
- Time of day
- Profiled device type.
Precise assignment of a client role is an important foundation for enforcing Zero Trust policy in an organization.
Policies
A policy and its client role assignments must be defined carefully to serve as a comprehensive solution that provides appropriate, uninterrupted access to all trusted network devices, while securing the network from threats.
A policy is a set of rules governing client behavior on the network. Within the policy rules, each user is represented by a role. When used dynamically, the role is assigned during authentication, and all traffic from that user and/or device is marked with a role ID for that access instance.
After traffic is marked with a unique role ID, the policy can be enforced on any Aruba device to determine where, when, and how that traffic can flow within the network.
ClearPass
ClearPass is a flexible and powerful solution that can be implemented as a physical or virtual appliance in multiple virtual environments. While it can be deployed as a stand-alone AAA server, best practice is to deploy multiples in a cluster for both high availability (HA) and load balancing. Refer to the Installation Guide for details.
All implementation and operation of ClearPass are managed directly within the web UI of the Publisher node. This Deployment Guide provides detailed procedures for installing the solution properly. For more complete coverage of features and commands, refer to the User Guide.
When using ClearPass, take time to plan the expected client experience when joining the network. Create a flow chart to outline the authentication and authorization process for sharing with both technical and business teams in order to set proper expectations and illustrate the benefits of the new solution. Ensure that organization members under why the security steps are necessary.
After user experience and business requirements are defined, determine how ClearPass can meet the expectations. ClearPass is a feature-rich, powerful tool. This guide lists services and features used in the most common, simple, but very effective implementations.
Publisher and Subscriber - Consider the geographical location and HA requirements when building the ClearPass cluster to ensure that database synchronization, L2 redundancy, Guest Captive Portal, and other services are working properly.
Authentication Methods - Define the authentication methods used to allow or disallow clients on the network. The list of methods available includes, but is not limited to, PEAP, EAP-TLS, and EAP-TTLS.
Authentication Sources - Identify all authentication sources needed to support the authentication methods defined in the previous step. Sources such as Active Directory, MDM solutions, and internal user or guest device repositories can be included, along with others defined listed earlier in this section.
Identity - Identify available endpoint profiling methods to build context and, when applicable, build ClearPass Roles and Role Mapping Policies to further assist with policy enforcement.
Enforcement - Finally, configure the enforcement policy to build a top-down list of rules to determine the proper enforcement profile used to respond to the authenticator. This is the last step in processing the ClearPass service. It can contain VLAN names and IDs, QoS markings, Aruba user roles, and other standard or custom attributes.
Network Devices and Device Groups - Configure the list of Network Devices (e.g., RADIUS and TACACS clients) for which ClearPass must accept authentication requests. As an option, build device groups that the ClearPass service can use to classify, accept, and process requests, such as a group of switches from specific vendors, that may require different attributes in a response.
The components above collectively form a ClearPass service. Their overall interaction and combined capabilities as a complete service can be seen in the completed Service Templates & Wizards page in the ClearPass publisher. Combine the components above to secure every type of environment, from wired NAC to a wireless or wired guest captive portal.
For best results, standardize naming convention for VLANs across the campus so they can be referenced easily when needed in ClearPass. For example, if the enterprise user VLAN ID and name vary by IDF, building, or floor, you will require a complex Enforcement Policy to identify which VLAN ID to return based on the IDF name, subnet, etc. Repetitive profiles may require more time for configuration and subsequent maintenance and troubleshooting. Simplify the complexity of service configuration by standardizing VLAN names even if the IDs are different. ClearPass only needs to send one standard response, making supporting this platform much easier.
Centralized Policy
In a centralized policy, wireless and/or wired data traffic is tunneled back to a gateway cluster for security enforcement and traffic-shaping.
In the example below, a user from the finance department authenticates to the campus network. Another user is logged into a guest kiosk computer directly connected to a UBT-enabled switch. Both the AP and the switch forward the traffic via GRE tunnels to the Gateway. The Gateways decapsulate and analyze the traffic, enforce user roles and other related attributes based on a predefined IT security policy, then forward the traffic to their authorized destinations. In this case, all enforcement is performed at the Gateways.
Central
The Aruba Central cloud platform hosts applications for managing policy across the ESP architecture. Central provides a user interface that facilitates policy creation and consistent implementation on all devices in an Aruba ESP network.
Central manages on-premise gateways, APs, and switches to ensure consistent policy implementation.
Gateway
ArubaOS 10 is a cloud-ready, AI-integrated wireless network operating system. Gateways running AOS 10 are configured through Central. They excel at processing large ACLs, using DPI and IDP/IPS functions to perform deeper levels of inspection to further secure the network. Available gateway features and capabilities make it easier to adapt Aruba ESP Policy to different security requirements that vary from company to company.
When designing a gateway cluster for high-availability purposes, ensure that cluster capacity is below 50% to allow for hitless failover and uninterrupted connectivity in case of a cluster member failure.
Gateway clustering also can be used to increase scale without replacing existing gateways. A new gateway can be clustered with an existing one. An 80% capacity figure is the recommended maximum target to avoid performance issues. However, APs build a single GRE tunnel back to a single controller. When a cluster is at or below 50% utilization, APs establish redundant GRE tunnels to two cluster members.
The maximum cluster size for 7000 and 9000 series gateways is four devices. The maximum cluster size for 7200 series gateways is 12 devices. When possible, use larger capacity gateways, rather than more gateways, to meet requirements and increase flexibility for growth.
Homogeneous clusters are required. Mixing different gateway models within the same cluster is not supported.
Authentication servers, AAA profiles, roles, and policies are all configured through the Central configuration page for gateways.
On the Devices > Gateways tab > Security page, create user roles and associate them with AAA profiles using the subcategories in the same section. The AAA profile in the Role Assignment tab enables the gateway (in this example) to recognize the role returned by a RADIUS server during a client authentication event and map it to the appropriate endpoint.
The Security > Policies section enables creation of firewall rule sets based on application session properties. ArubaOS has six policy types, including standard and extended ACLs for compatibility with router software from popular vendors. However, firewall session policies provide equivalent and greater functions than standard and extended ACLs and should be used instead.
Policies are associated with a role in the Roles configuration tab on the page illustrated above. When a role is created and associated with a policy, a AAA profile can be configured to enable user authentication and role assignment. A secure per-user session can be managed from Central to secure the network access layer through the gateway cluster.
Switching
Aruba switches support a set of features called User-Based Tunneling (UBT). The switch tunnels client traffic back to a gateway cluster within a GRE tunnel, similar to how an AP tunnels client traffic. The gateway serves as a centralized policy enforcement point for wired, wireless, as well as WAN or Internet traffic.
UBT provides a centralized policy that supports Aruba Colorless Ports. A switch can dynamically tunnel traffic to a gateway cluster for policy enforcement so that any client device can connect to a properly configured switchport and dynamically receive the appropriate level of network access. This level of dynamic port assignment eliminates the need to manually configure and maintain multiple switch-port ranges for different devices.
To a network engineer, UBT eliminates the frustrating emergency Monday morning escalations to reconfigure ports for last-minute employee moves because someone forgot to submit a change request the week before. Also eliminated is the need to manage large port mapping plans that call for switch ports 1-8 configured as trunk ports for IAPs, 9-16 as access ports for security cameras, 17-20 as access ports for printers, and any other devices supported by the business.
Distributed Policy
Distributed policy enforcement uses VXLAN tunnels to create virtual networks between switches. Aruba CX switches are able to enforce policy locally with many of the same capabilities found on gateways. This is particularly powerful when securing East-West traffic within a campus. These capabilities are described as the Aruba ESP NetConductor solution.
NetConductor pairs VXLAN with the EVPN control plane to ensure endpoint reachability across geographically diverse subnets and broadcast domains.
In the example below, a wired user from the finance department authenticates to the campus network. A different user is logged into a guest kiosk computer. The switches analyze the traffic locally, enforce user roles and other related attributes based on a predefined IT security policy, then forward the traffic directly to their authorized destinations. Using the native firewall capabilities of the switches, policy enforcement can be performed at the edge, allowing the traffic to take a more direct path to its destination.
All switches configured by NetConductor must be in the same Central group. Wireless gateways may remain in an existing wireless group or be included in the switching group.
Central
The Aruba Central cloud platform hosts applications to manage policy across the ESP architecture. Central provides a workflow-based user interface called Aruba Central NetConductor that simplifies deployment of an EVPN-VXLAN overlay. NetConductor implements sophisticated, API-driven automation that interfaces with all ESP device types to ensure a consistent configuration across the organization.
The switches and gateways in a NetConductor fabric access a policy ID marked in the VXLAN header of every packet in the overlay to enable policy enforcement anywhere in the network. Policies are configured through the Client Roles interface in the gateway Security configuration section on Central.
Gateway
Gateways are configured using Aruba Central and the NetConductor workflow. Existing Aruba wireless LANs are easily integrated into a NetConductor fabric. The recommended approach is to connect the gateway cluster to two Aruba CX 8360 switches configured as a VSX pair. The pair takes on the Stub persona during fabric configuration.
The wireless LAN and the overlay fabric are connected over a static VXLAN tunnel configured between the controller cluster and the Stub switch to which it is connected. This tunnel ensures that the role ID is communicated between the WLAN and the EVPN fabric by preserving the VXLAN header.
NetConductor requires adding personas to switches within the fabric. The gateways should be connected to a VSX aggregation switch pair, and the switches should be assigned the Stub persona from NetConductor. This causes NetConductor to configure a static VXLAN tunnel between the gateways and switches and enables the communication of a VXLAN header containing GPID between the EVPN fabric and the WLAN overlay.
Switching
Switches are configured using Aruba Central NetConductor. Aruba Central NetConductor provides an intuitive user experience resulting in the deployment of an EVPN-VXLAN overlay fabric.
The Aruba CX switch operating system provides a sophisticated suite of L3 capabilities necessary for building highly resilient overlay networks based on EVPN-VXLAN, using the proposed Group Based Policy field to carry a Group Policy ID value that enables evaluation of any packet anywhere in the network against a policy. Each user or device session carried through the fabric is assigned a role ID enabling each switch in the network to enforce role-based policy.
