Link Search Menu Expand Document
calendar_month 07-Mar-24

Segmentation Design

The Aruba ESP Campus Segmentation Design section describes the technologies and design principals used in the implementation of an Aruba ESP traffic segmentation design.

Table of contents

Network Segmentation

Traditional VLAN and access control list (ACL) security features remain important components of the security framework. Aruba ESP greatly fortifies standard security practices by:

  • Enabling automated application and enforcement of security policy throughout the overlay network,
  • Incorporating roles, or personas that clearly identify and group access attempts for each user or device for consistent policy application.
  • Successfully segmenting campus traffic originating from both wired and wireless endpoints.

Two policy frameworks are provided within the ESP architecture to allow organizations to choose the approach that best meets current requirements.

Aruba Dynamic Segmentation provides mechanisms to assign user traffic to secure network segments dynamically using policies defined by business requirements. This solution uses Generic Route Encapsulation (GRE) to tunnel traffic from APs and switches to a gateway cluster, for consistent, high-throughput policy enforcement on north/south traffic.

Aruba Central NetConductor also provides mechanisms for securely and dynamically segmenting user traffic. This solution uses a distributed overlay architecture built on VXLAN-GBP to segment user traffic in the network using an efficient and fault-tolerant fabric topology and GBP enforcement at any point in the network.

Policy intro

Logical network segmentation is a fundamental tool of secure IP network design. Virtual LANs (VLANs) are used to separate IP broadcast domains. Virtual routing and forwarding (VRF) instances enable a single network device to provide routing services within multiple, distinct routing domains. VLANs and VRFs both use access control lists (ACLs) and route-maps to filter communication between subnets.

Virtual LAN

A VLAN segments traffic at layer 2 and restricts MAC reachability. From a policy standpoint, VLANs are used for macro-segmentation. Devices are grouped into a VLAN by IP subnet, and an IP ACL is applied to the VLAN interface. This serves as the main policy enforcement mechanism to determine if endpoints in a VLAN or subnets are permitted to communicate with endpoints in other VLANs or subnets.

In NetConductor, VLANs also are configured to create layer 2 segments.

Virtual Routing and Forwarding

A VRF instance enables a single network device to manage multiple routing domains and maintain entirely separate route tables. Member interfaces forward traffic based on the VRF-specific route table. A VRF can contain overlapping IP addresses with another VRF, because the individual route tables are discrete.

Because VRF separates IP routing domains, the network can be segmented to enforce policy effectively. For example, a retail organization can place all PCI traffic in a VRF separate from other enterprise networks to guarantee that regulated traffic cannot intermingle with enterprise traffic. VRF segmentation should be kept to a minimum when designing campus networks in order to preserve resources on the network infrastructure.

In NetConductor, VRFs can be used to create layer 3 overlay networks.

Access Control Lists

An access control list (ACL) is a filter applied to network traffic to identify hosts or networks and to restrict communication with other hosts or network segments. Filtering rules can be applied to MAC addresses, IPv4 addresses and ports, or IPv6 addresses and ports.

When traffic matches an ACL rule, policy is applied to permit, deny or drop the traffic. The ACL also can be used to apply Quality of Service (QoS) policies and route map filters.

ACLs are commonly used to create an IPv4 filter at a layer 3 network boundary. This enables configuration of filters based on IP address, type, and port number to regulate communication between IP subnets. For example, an ACL can deny user VLANs (BYOD, employee, and visitor) from accessing a network infrastructure management VLAN.

On AOS-CX devices, ACLs are applied to an interface in a specific direction depending on the platform. It is important to note this direction. The following table lists the AOS-CX capability to apply ACL inbound or outbound by interface type and by ACL type.

ACL Interface Type8400X83608325832064xx630062006100
Ingress IPv4 ACL on portsYesYesYesYesYesYesYesYes
Ingress IPv4 ACL on VLANsYesYesYesYesYesYesYesYes
Ingress routed IPv4 ACL on VLANsYesYesYesYesYesYes--
Ingress IPv6 ACL on portsYesYesYesYesYesYesYesYes
Ingress IPv6 ACL on VLANsYesYesYesYesYesYesYesYes
Ingress routed IPv6 ACL on VLANsYesYesYesYesYesYes--
Ingress MAC ACL on portsYesYesYesYesYesYesYesYes
Ingress MAC ACL on VLANsYesYesYesYesYesYesYesYes
Egress IPv4 ACL (on route-only ports)YesYesYesYesYesYes--
Egress IPv4 ACL (on bridged ports)-Yes--YesYesYes-
Egress routed IPv4 ACL on VLANs-YesYesYesYesYes--
Egress IPv6 ACL on ports-Yes--YesYesYes-
Egress IPv4 ACL on VLANs-YesYesYesYesYesYes-
Egress routed IPv6 ACL on VLANs-YesYesYesYesYes--
Egress IPv6 ACL on VLANs-YesYesYesYesYesYes-
Egress MAC ACL on ports-Yes--YesYesYes-
Egress MAC ACL on VLANs-Yes--YesYesYes-
Control plane ACLsYesYesYesYesYesYesYesYes
Ingress ADC on portsYesYesYesYesYesYesYesYes

Role-Based Policy

User Role

The Aruba WLAN solution has long featured the concept of a user role, or persona. The user role is a container for a variety of attributes that define how a user or device is permitted to use the network and resources connected to it. In most cases, the role is derived and assigned to a user or device based on the credentials provided during 802.1X-based authentication. Roles also can be based on device properties, usage patterns, geography, time of day, and a number of additional attributes.

A major advancement in security policy enforcement, Aruba ESP provides the ability to assign a role to any authenticated or profiled traffic in the network and enforce the associated policy at any point in the network: switch, AP, or gateway. This ability enables a true zero-trust network environment by ensuring that every packet is associated to a role and compliant with the policy of that role. Policy can be applied using ACLs, VLAN assignment, QoS markings, time restrictions, and other security requirements in a variety of combinations.

Policy

Plan security policy carefully to make the best use of roles for a comprehensive solution that does not interfere with legitimate use of the network.

Common types or categories of roles with similar policies are:

  • Trusted
  • Untrusted
  • IoT

Trusted

Trusted roles should require 802.1X-based, enterprise authentication. Trusted roles provide varying levels of access to internal, limited-access resources. Examples of roles that typically fall into the trusted category are:

  • Employee
    • Typical permissions include:
      • Full access to general network resources, including File, Print, Email, Internet, and access to internal systems.
    • Typical exceptions/prohibitions include:
      • Secure or sensitive systems such as related to PCI, PHI, or PII data.
      • Operational controls - HVAC, lighting, building automation systems.
      • Network Management System - management interfaces, configuration management applications.
  • IT
    • Typical permissions include:
      • Standard employee access.
      • Network Management System - management interfaces, configuration management applications.
    • Typical exceptions/prohibitions include:
      • Exceptions may be PCI, PHI, PII data
  • Critical
    • Typical permissions include:
      • This role is typically assigned to a single account used only when access to authentication services is disrupted.
      • This role has specific system control rights needed to perform repair, recovery and restoration when required.

Untrusted

Untrusted roles should require authentication, but may rely on non-802.1X mechanisms such as a pre-shared key or guest registration. Examples of roles that typically fall into the untrusted category are:

  • Visitor

    • Typical permissions include:
      • Internet-only access limited to HTTPS, HTTP, DNS, DHCP protocols.
    • Typical exceptions/prohibitions include:
      • Bandwidth limits.
      • Application categories (gambling, gaming, adult content, etc.).
      • Time of day.
  • Contractor

    • Typical permissions include:

      • Internet access with limitations.
      • Sensitive or operational systems as needed for the contracted function.
    • Typical exceptions/prohibitions include:

      • Device profiling for minimum patch level.
      • Application categories (gambling, gaming, adult content, etc.).
      • Time of day.
      • Network Management System - management interfaces, configuration management applications.

Note: A contractor in this context is a project oriented, short-term resource, working from their own client devices.

IoT

IoT roles must be tailored to the limitations and requirements of the devices to be deployed. Policy must permit the IoT solution to function properly with correct peer-to-peer communication. Policy also must permit the management plane of the IoT solution to reach all devices. Examples of roles that typically fall into the IoT category are:

  • Office devices
    • Typical permissions include:
      • Access to consumables management system.
      • Access to print servers, DHCP, and DNS.
    • Typical exceptions/prohibitions include:
      • No access to Internet or other systems.
  • Building management devices
    • Typical permissions include:
      • Access to building management system (BMS) hosts.
      • Access to DHCP and DNS.
    • Typical exceptions/prohibitions include:
      • No access to Internet or other systems.

When device-to-device communication is not required, configure the user roles to deny traffic between endpoints.

When designing network roles, the goal is to create roles that make policy enforcement consistent and precise while limiting available attack surface.

Developing an accurate network profile and specific access requirements for each unique type of user or device is essential.

Policy Enforcement

Centralized Overlay

When building networks using a centralized policy architecture, APs and switches form GRE tunnels to a gateway cluster and all user traffic is tunneled. This results in an efficient design for primarily client initiated, north/south-bound traffic such as that destined for a data center or the Internet.

As the authentication server in 802.1X authentication sessions, the gateway applies a role to every client session upon successful authentication. Aruba gateway products also serve as the primary policy enforcement point using a high-throughput policy enforcement firewall and deep-packet inspection engine.

Distributed Overlay

When building networks using a distributed policy architecture, switches form an EVPN-VXLAN overlay fabric. Data traffic is encapsulated in a VXLAN packet that includes a group policy ID (GPID) on every datagram. This enables policy enforcement on any VXLAN-GBP-aware device configured with a corresponding role and policy.

The distributed policy architecture implemented in the Aruba Central NetConductor solution provides consistent and efficient policy enforcement on all directions of traffic flow and opens the potential for Internet-wide, Zero Trust networking.

The policy enforced on a switch is configured within Aruba Central and downloaded to the switch when it is added to the overlay fabric.

802.1X and Policy Based Segmentation

Remote Authentication Dial-In User Service (RADIUS)

RADIUS is a networking protocol used to communicate user credentials to an authentication database, then relay the corresponding user profile from the database to the network infrastructure.

The primary authentication method used in ESP design is 802.1X. Although Aruba products are standards-compliant and integrate with many commonly available RADIUS server products, a comprehensive ESP policy layer must use Aruba ClearPass Policy Manager as the RADIUS and policy server.

Aruba ESP offers critical capabilities required to operate a secure and reliable RADIUS infrastructure. Use “authentication priority” to enable fallback from 802.1X to MAC-based authentication to ensure that critical devices always receive required network access. “Client limits” should be configured to limit the number of authenticated clients from any single device port to prevent unintended MAC flooding.

Another important method to increase fault-tolerance is creating a “critical authentication” role. This role can be assigned to critical devices if an authentication request fails. It should be associated with a policy that permits only basic connectivity for continued authentication attempts. A critical authentication role on the switching infrastructure allows devices to access the network if the RADIUS server is temporarily unreachable.

Role Assignment

Roles are typically assigned when a user or device is authenticated with 802.1X. The RADIUS server queries a back-end LDAP containing a profile associated with the credentials provided. In Aruba ESP, a vendor specific attribute (VSA) is used to communicate the assigned role.

After authentication, the RADIUS server can relay standard defined attributes and VSAs related to the profile back to the network infrastructure.

When endpoints do not have appropriate credentials to connect to the network, a “rejection role” should be used to prevent continued authentication failures. The rejection role should place the device in a restricted VLAN with access to DHCP and DNS only. This ensures that the supplicant sees itself as authenticated and failing to get a route to the Internet. The supplicant should discontinue further authentication attempts.

A change-of-authorization message is a special RADIUS message that enables modification of the policy applied to an already authenticated user or device. A role can be changed for an existing authenticated user or device based on time, location, or behavioral variables.

Basic principles of user role assignment include:

  • The user role dictates if traffic is switched locally or tunneled to another device.
  • Any RADIUS server can be used to return a local user role (LUR).
  • Roles are assigned from the RADIUS server using the “HPE-User-Role” VSA.
  • A role can assign a policy or QoS ACL, reauthentication timers, and captive portal redirect.

  • The role must exist on a network device before the associated policy can be enforced by that device.

Colorless Ports

The ESP colorless ports feature enables dynamic assignment of a role and policy to an access port following device connection and authentication. A device can connect to any port in the network and be assigned to the correct VLAN based on the associated policy. As a result of this VLAN assignment, the traffic then can be put directly onto a traditional VLAN, encapsulated in a GRE tunnel and sent to a gateway using UBT, or encapsulated in a VXLAN tunnel and sent across a NetConductor fabric.

Dynamic Segmentation

In Aruba ESP, dynamic segmentation is the solution for assigning user traffic to secure network segments dynamically based on policies defined by business requirements. Colorless ports facilitate onboarding wired devices to dynamically assigned roles and policies. For wireless devices, 802.1X is preferred for authentication and role assignment.

Dynamic segmentation uses GRE to tunnel APs and switches to a centralized gateway cluster and provide firewall-based segmentation and policy enforcement on the data plane. Policy can be applied to traffic bridged at the AP; however, using a gateway cluster provides better throughput and enforcement capabilities.

Micro-segmentation of traffic is achieved by enforcing role-based policy on the gateway cluster of the tunneled data plane. In addition to applying IP-based policy between subnets, MAC layer traffic can be filtered within a subnet to limit peer-to-peer communication.

Wireless Data Plane Modes

Dynamic segmentation supports three wireless data plane modes:

  • Tunnel Mode
  • Bridge Mode
  • Mixed Mode

Tunnel mode SSIDs use a GRE tunnel from the APs to a centralized gateway cluster. Policy is configured in Aruba Central, and the gateway is the enforcement point providing policy enforcement firewall and DPI engine capabilities.

Gateways are required for campuses expecting to deploy more than 500 APs and 5000 clients at a single site. Gateways are recommended for maximum policy enforcement capabilities with high throughput.

Tunnel Mode in Three-Tier Wired

Tunnel-mode_Three-Tier

Bridge mode SSIDs bridge wireless traffic to a VLAN locally and do not tunnel traffic to a gateway. As a result, a bridge mode AP must have all wireless user VLANs trunked to the connected switch port. Policy is configured in Aruba Central, and the AP is the enforcement point providing policy enforcement firewall and DPI capabilities for a moderate density of clients. Bridge mode SSIDs should be considered for locations expected to deploy fewer than 500 APs with fewer than 5000 clients per site. Consider the overall security, policy, and traffic engineering requirements of the planned deployment.

Bridge Mode in Two-Tier Wired

Bridge-mode_Two-Tier

Mixed mode SSIDs enable both bridge and tunnel forwarding modes on a single SSID. Reducing SSIDs on a campus increases WLAN performance by reducing the number of management and beacon frames transmitted. Mixed mode SSIDs only support 802.1X authentication. They should be considered if the design requires both bridged and tunneled traffic within the campus. Aruba ClearPass is preferred, but not mandatory, to deploy mixed mode SSIDs. Bridged and tunneled VLAN derivation uses a standard VSA (such as filter-id) or an Aruba VSA (such as user role), which is sent by the RADIUS server.

User-Based Tunneling for Wired

User-Base Tunneling (UBT) allows traffic from a switch to be tunneled to a gateway cluster using GRE in the same manner as traffic in a tunnel mode SSID. As with tunnel mode, policy is configured in Central, and the gateway serves as the policy enforcement point. This results in consistent policy enforcement on wired and wireless traffic and simplified engineering for northbound flows.

The following diagram shows UBT in the three-tier wired design. The employee, visitor, and Internet of Things (IoT) devices have different access policies based on the assigned user role even though they come from the same VLAN subnet in the access layer.

Policy Enforcement Using UBT in Three-Tier Wired

Wired_Policy_Three-Tier

Central NetConductor

In Aruba ESP, Central NetConductor is the solution for building a policy-based campus overlay network using VXLAN-EVPN to enable policy enforcement at the per-packet level at any point in the network. Colorless ports facilitate onboarding endpoints to the correct overlay network and policy domain using 802.1X for primary authentication.

NetConductor consistently distributes policy configuration across the ESP campus ensuring that gateways, APs, and switches all are able to identify the roles in use and enforce the associated policies.

VXLAN-GBP

NetConductor uses VXLAN-GBP to segment user traffic in a network by tagging VXLAN packets with a Group Policy ID (GPID) associated to a user role. The roles and policies are defined in Aruba Central and distributed to all devices in the overlay fabric.

The GPID is set at the ingress virtual tunnel endpoint (VTEP) based on the user role assigned when the device or user initially authenticates to the network. Endpoints can be authenticated by MAC or 802.1X.

Associating policy to each packet at ingress to the fabric and enforcing policy on each packet at egress from the fabric establishes a framework for a highly granular, scalable, and dynamic policy layer. An assigned policy tag is carried on data traffic within the fabric, from user segment to WAN block or physical security infrastructure to data center, with no loss of fidelity.

Segmentation using VXLAN-GBP provides the following advantages:

  • Role-to-role micro-segmentation of user traffic on the same VLAN by tagging with a user role stored as a GPID in the VXLAN header.
  • Consistent policy enforcement across a campus and between fabric domains.
  • At the egress, the switch determines if the traffic from the source role (carried in the Group Policy ID) is permitted or denied for the destination role (determined from the destination MAC). Traffic is forwarded or dropped accordingly.

  • In a gateway, traffic on a VXLAN tunnel can be terminated and enter another VXLAN tunnel. The Group Policy ID must be transported to the new tunnel for the final destination to enforce role-based policies.

distributed_overlay

EVPN to GRE Policy

Policy is communicated between GRE overlays and EVPN overlays using a static VXLAN tunnel between the EVPN fabric border on the gateway aggregation switches and the gateway cluster where the GRE sessions terminate. The GPID identifies an Aruba role and is carried in the VXLAN header across the static VXLAN tunnel between the two solutions.

Ensure that fabric border switches are sized appropriately for the number of MAC addresses expected.

Campus to Branch Policy

When a Central gateway group is configured for SD-Branch, a VXLAN header can be inserted into SD-Branch destined packets. The header contains the VXLAN GPID used within the EVPN fabric. This enables the remote site to receive the GPID and apply the same role to the packet that was applied at the originating site.


Back to top

© Copyright 2024 Hewlett Packard Enterprise Development LP. The information contained herein is subject to change without notice. The only warranties for Hewlett Packard Enterprise products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. Hewlett Packard Enterprise shall not be liable for technical or editorial errors or omissions contained herein. Aruba Networks and the Aruba logo are registered trademarks of Aruba Networks, Inc. Third-party trademarks mentioned are the property of their respective owners. To view the end-user software agreement, go to Aruba EULA.