Wireless Network Segmentation Options

Wireless Network Segmentation Requirements
Wireless networks often have as one of their many goals the secure segmentation of different user roles. This is typically due to various reasons including distinct device capabilities (or lack thereof), varying network/application/data access rights among user classes, support for guest or partner Wi-Fi networks, or separation of user classes from one another.

Traditionally, wireless network segmentation has been accomplished by creating separate Extended Service Set Identifiers (ESSID / SSID), and mapping each to a different network VLAN with access restrictions performed by some upstream device such as a firewall or router.

However, that approach is increasingly ill-suited for today's complex wireless networks, which are tasked with supporting multiple user roles, device classes, and information security distinctions over the same network infrastructure equipment. Creating separate SSIDs for each security scenario can quickly tailspin a Wi-Fi network into sluggish performance due to the overhead created to support each virtual BSS.  For an overview of this issue, see "Limit SSIDs and Data Rates to Maintain Network Performance." And the need for segmentation is only growing with the expanding Consumerization of Enterprise Wi-Fi and IT in general. If your organization hasn't seen an influx of smartphones, tablets, and personal computing devices, it will soon.

Couldn't we just use a single SSID to support all these various user roles, you may ask? The good news is that you can. A single SSID can be used for all similarly capable device classes, such as all devices that support 802.1x / EAP authentication with WPA2, but user role distinctions do not necessarily need different SSIDs (a few SSIDs may still be required to advertise and support varying authentication and encryption security methods, but in general many similarly capable devices can be collapsed into the same SSID). Centralized RADIUS can be used to distinguish user-roles based on group mappings and return security attributes to the wireless network for enforcement. This is called Identity Based Networking, and it has traditionally involved RADIUS servers returning a dynamic VLAN assignment for the authenticated user to the network.

The downside to this method is that multiple back-end VLANs, IP subnets, and security enforcement points are still required on the wired network. This causes increased administrative management and support, wasted IP addressing space, difficulty in appropriately sizing various network segments (especially considering the tremendous growth and fluctuation of wireless endpoint requirements), and leaving a disconnect between policy assignment (at the wireless AP) and policy enforcement (at an upstream firewall / router).

Private VLAN Concepts

Private VLANs are one method to provide network segmentation between hosts without wasting IP addressing space. This is accomplished by creating one large Layer 3 subnet and using special (Cisco proprietary) Layer 2 VLAN segmentation at the port-level to create security boundaries between hosts, rather than rely on a static one-to-one mapping of VLAN to IP subnet as is traditionally done.

Essentially, one 'Parent' VLAN is mapped to the IP subnet for all hosts, then secondary 'Child' VLANs are used to segment traffic between different security domains. These child VLANs can be either 'Isolated' or 'Community'. Isolated child VLANs allow the host(s) on assigned ports to only communicate with the default gateway. Community child VLANs allow the host(s) on assigned ports to communicate with the default gateway as well as other hosts in the same community child VLAN. For a good primer on Private VLANs see Jeremy Stretch's article on Basic Private VLAN Configuration over at PacketLife.net.

Private VLANs and Wi-Fi Networks
Using Identity Based Network integrated with Private VLANs would seem to be a logical extension of identity based networks for wireless networks. First, since wireless networks involve user mobility, using a single large client VLAN is appealing to reduce Layer 3 roaming requirements between subnets. As clients move throughout the wireless environment they need to retain the same IP address to maintain application sessions and provide a good user experience. Second, the large growth of wireless endpoints on corporate networks makes reducing IP address and VLAN ID waste attractive. Third, the requirement to support various external user roles on the same network is growing as more organizations need to support various business partners and vendors on the corporate wireless infrastructure. In essence, private organizations are leveraging their wireless infrastructure like a managed service provider, facilitating business processes that involve external entities. All of these external entities may need similar network access such as Internet, VPN, and on-site collaboration capability within their group, yet should be segmented from other external entities also at the customer / partner site.

However, using Private VLANs for wireless users is not possible due to capability limitations of Cisco wireless equipment. As Jeremy Stretch pointed out in Private VLANs on Trunks and SVIs, when PVLAN information is tagged across 802.1q trunk links the Parent VLAN ID is used for traffic sourced from promiscuous ports, and the Child VLAN ID is used for traffic sourced from child ports. This incongruity in VLAN tagging breaks down on trunk ports to wireless access points.

Let's use the following illustration to demonstrate:

Here we can see that the Private VLANs are setup with VLAN 100 as the Parent, and VLANs 101 and 102 as Child Community VLANs. The goal is to have clients be able to communicate with other hosts in their child VLAN, but not hosts in other child VLANs. However, we see that wireless integration with PVLANs breaks down because wireless equipment does not understand the PVLAN concept of parent and child VLAN associations, as wired switches do. In order for communication to function correctly across trunk links, both ends must understand the child to parent relationship, since only the source VLAN is tagged across the trunk link.

In this example, the client in VLAN 102 associates to the AP and issues a DHCP Request. This frame transits the trunk link using a tag of 102. The wired switch understands the parent and child VLAN association and is able to forward the frame out of the promiscuous port to the router (default gateway) without any tag since this is an access port in VLAN 100. The router responds with a DHCP Offer frame, which transits the trunk link using a tag of 100 (the parent VLAN). The AP receives this frame and drops it because no SSID is associated with VLAN 100. Creating another SSID tied to VLAN 100 also won't help because the client will still be associated to the VLAN 102 SSID. And moving the client into an SSID tied to VLAN 100 causes the client to be considered "promiscuous" and defeats the entire purpose of private VLAN segmentation.

Therefore, we end up with one-way communication. Ultimately, the lack of wireless equipment's ability to understand private VLAN concepts prevents the association of parent and child VLANs. This prevents the use of private VLANs with Cisco Autonomous, Lightweight (local mode), and Lightweight (H-REAP) wireless networks.

Note - Routers do not understand private VLAN concepts either, which requires them to be connected to the switch using an access port rather than a trunk port.

Wireless Network Segmentation Options
The options left for wireless network segmentation include:

1. Multiple SSIDs mapped to separate VLANs and IP subnets (the traditional solution)
   Benefits - secure segmentation between user roles; straight-forward network administration and support.
   Drawbacks - increased wireless network overhead and reduced performance; wasted VLAN IDs and IP address space; static policy definitions are not flexible to address changing needs.
   
   
2. Single SSID integrated with identity based networking concepts, RADIUS dynamic VLAN assignment, spearate VLANs and IP subnets, and upstream firewall or router policy enforcement.
   Benefits - secure segmentation between user roles; reduced wireless network overhead and improved performance.
   Drawbacks - wasted VLAN IDs and IP address space; complex network administration and support; disconnect between policy assignment and policy enforcement implemented in different equipment.
   
   
3. Single SSID integrated with identity based networking concepts, RADIUS policy definition, and edge firewall policy enforcement capabilities in the access points, and a single wired VLAN and IP subnet for wireless clients.
   Benefits - secure segmentation between user roles; reduced wireless network overhead and improved performance; preservation of VLAN IDs and IP address space; straight-forward network administration and support; integrated policy assignment and enforcement in the same equipment.
   Drawbacks - limited wireless vendor support for integrated firewall capability in access points; may require more powerful access point hardware to maintain performance.

Option 1 is clearly the traditional and most well-understood of the three options. However, it suffers from lack of scalability and fairly rigid user classifications and policy enforcement that is not easily changed without major effort. This option has broad market support in almost every enterprise-class Wi-Fi product.

Option 2 improves the situation by reducing wireless network overhead, but adds complexity by requiring correct centralized policy assignment through RADIUS attributes in order for security access to be controlled correctly. It also fails to address the back-end wired network complexity and similarly suffers from lack of scalability and rigid policy enforcement. However, this option also has broad market support.

Option 3 is clearly the best of all options, as it combines improved wireless network performance, easily scalable growth, simplifies back-end wired network complexity by reducing VLAN IDs and preserving IP addressing space, centralizes policy management, and integrates policy assignment and enforcement in the same equipment. However, this option may require more powerful access points to process user traffic, inspect and apply appropriate security controls, and maintain throughput and low-latency performance. This option also has limited market support, with only a handful of vendors supporting integrated firewall capability in access points.

Any of these three options will provide adequate network security when designed properly.

Cheers,
Andrew