Chapter 8

Designing for Client Mobility

This chapter covers the following topics:

Roaming Review: This section reviews the process a wireless client uses to roam from one AP to another, as well as the different types of roaming supported by a Cisco wireless network.

Organizing Roaming Behavior with Mobility Groups: This section discusses how Cisco WLCs can be assigned to logical groups that support client roaming within an enterprise.

Optimizing AP Selection for Client Roaming: This section provides an overview of ways that wireless clients scan for available APs and select one for association. Several methods to make the AP selection more efficient are also covered.

Optimizing Security Processes for Roaming: This section explains the robust secure network (RSN) and its impact on wireless client roaming. It also covers five common methods to streamline the roaming process in the midst of robust security.

This chapter covers the following ENWLSD exam topics:

3.1 Design mobility groups based on mobility roles
3.2 Optimize client roaming
3.3 Validate mobility tunneling for data and control path

Wireless client devices are inherently mobile, so you should expect them to move around. This chapter discusses client mobility from the AP and controller perspectives. You should have a good understanding of client roaming so that you can design and configure your wireless network properly as it grows over time.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess if you should read this entire chapter. If you miss no more than one of these self-assessment questions, you might want to move ahead to the “Exam Preparation Tasks” section. Table 8-1 lists the major headings in this chapter and the “Do I Know This Already?” quiz questions covering the material in those headings so you can assess your knowledge of these specific areas. You can find the answers to the “Do I Know This Already?” quiz in Appendix D.

Table 8-1 “Do I Know This Already?” Section-to-Question Mapping

Foundation Topics Section	Questions
Roaming Review	1–3
Organizing Roaming Behavior with Mobility Groups	4–6
Optimizing AP Selection for Client Roaming	7–8
Optimizing Security Processes for Roaming	9–10

1. Which one of the following 802.11 management frames is used to initiate a roam from one AP to another?
1. Authentication request
2. Association request
3. Roam request
4. Reassociation request
2. Suppose AP-1 is joined to WLC-1 and AP-2 is joined to WLC-2. Both APs offer the SSID “Wi-Fi” and the same IP subnet. A client undergoes a roam from AP-1 to AP-2, then back to AP-1. Which one of the following roam types did the client undergo from AP-2 to AP-1?
1. Intra-controller
2. Inter-controller Layer 2
3. Inter-controller Layer 3
4. Autonomous
3. Suppose AP-1 is joined to WLC-1 and AP-2 is joined to WLC-2. Both APs offer the SSID “Wi-Fi,” but each offers a different IP subnet. A client undergoes a roam from AP-1 to AP-2 and is able to keep using its original IP address. For this client roam, which of the following correctly identifies the roles played by WLC-2?
1. Anchor controller, POA
2. Anchor controller, POP
3. Foreign controller, POA
4. Foreign controller, POP
4. A single mobility group can have a maximum of how many controllers? (Choose one.)
1. 10
2. 24
3. 50
4. 72
5. When you configure mobility groups on Cisco WLCs, what is the maximum number of controllers that can belong to the same mobility domain?
1. 10
2. 24
3. 50
4. 72
6. To verify that mobility tunneling is working correctly over a CAPWAP tunnel between two WLCs, which one of the following CLI commands should you use?
1. ping
2. eping
3. cping
4. mping
7. Which one of the following statements is correct about active scanning?
1. A client actively tunes its radio through a sequence of channels and waits to receive 802.11 beacon frames from APs.
2. A client actively tunes its radio through a sequence of channels and transmits 802.11 probe request frames, then waits for replies from APs.
3. A client tunes its radio through a sequence of channels and transmits 802.11 Action frames to discover APs that answer.
4. An AP actively tunes its radio through a sequence of channels to discover any clients sending 802.11 beacon frames.
8. Which two of the following 802.11 amendments can be used to assist clients in finding candidate APs to roam toward?
1. 802.11k
2. 802.11r
3. 802.11s
4. 802.11v
5. 802.11w
9. The 802.11r amendment is also known as which one of the following?
1. Fast secure roaming
2. Opportunistic Key Caching (OKC)
3. Fast BSS Transition (FT)
4. Fast Key Caching (FKC)
10. Suppose an 802.11r client initiates a roam with a target AP. Which one of the following correctly describes the step when the PTK and GTK are generated?
1. When the client undergoes 802.1X/EAP authentication with a RADIUS server
2. When the client and AP exchange 802.11 authentication and reassociation messages
3. Right after the 802.1X/EAP authentication is completed
4. During the normal 4-way handshake

Foundation Topics

Roaming Review

Perhaps the best way to begin a chapter about wireless mobility is to review client roaming in various scenarios. Before a client device can use a wireless network, it must join or associate itself with an AP by completing the following steps:

Discover an AP’s presence by scanning channels to receive 802.11 beacon frames or by sending 802.11 probe request frames.
Authenticate itself to a specific AP at its BSSID address, using either open system or shared key authentication.
Associate with the AP by sending an 802.11 association request frame to the AP; if the AP is agreeable, it responds with an association response frame.
If the WLAN uses WPA2 or WPA3 and is a secured with a pre-shared key (PSK) or 802.1X, the client must authenticate itself with the PSK or through EAP and RADIUS.

Once fully associated, the client can communicate over the wireless network through that AP, as long as the client stays within the AP’s cell. Wireless clients are free to move around, so a client device must remain aware of the quality of its current association so it can be ready to move its association to a different AP when necessary. Ideally, a client will move its association well ahead of time so that communication with the original AP does not become unusable before the roam occurs.

Figure 8-1 illustrates the basic roaming process. The client begins with an association to AP-1 while inside that cell. As the client moves away from AP-1, it notices that the RF conditions become less and less favorable for maintaining a good connection with AP-1. The client discovers AP-2’s presence and a better signal, so it decides to try to roam there by sending an 802.11 reassociation frame to AP-2. If the reassociation is successful, the client’s previous association with AP-1 is torn down. If AP-1 has any unsent data destined for the client, it relays that data to AP-2 over the wired network.

Images — **Figure 8-1** *A Basic Roam from One AP to Another*

The basic idea is to request an association when a fresh connection to an AP is needed and to request a reassociation when a roam from one AP to another is needed. The reassociation is designed to preserve network connectivity as much as possible, minimizing any disruption while the client transitions between two APs.

From the client’s perspective, the roaming process is always the same between any two APs. However, the roaming mechanism can take many forms on the back end, depending on the wireless network architecture. The following sections provide a quick review.

Autonomous APs

When a network is built from autonomous APs, there are no back-end mechanisms to support roaming, as each AP acts independently. Therefore, the roaming operation is quite simple and straightforward and is the scenario shown in Figure 8-1. If the client moves from one IP subnet into another subnet as it roams between APs, it must take time to request a new IP address from a DHCP server through the new AP association.

Intra-Controller (Layer 2) Roam

Suppose the wireless network is made up of lightweight APs joined to a single WLC, as shown in Figure 8-2. Each AP maintains CAPWAP tunnels to the WLC to transport control and data traffic. When a client roams between AP-1 and AP-2, its associations are handled within the same controller. The controller simply has to update its table of client associations to reflect the change from AP-1 to AP-2. The SSID, security parameters, and IP subnet can all stay consistent, so the roam transition can be as efficient as possible. Because the client’s IP address can remain the same, the roaming event occurs at Layer 2.

Inter-Controller (Layer 2) Roam

Larger networks may use multiple controllers with APs that are distributed across them. As a mobile client moves about, it might roam from an AP joined to one controller onto an AP joined to a different controller. This is known as inter-controller roaming and is illustrated in Figure 8-3. As the client moves from AP-1 to AP-2, its association is passed from WLC-1 to WLC-2. Such a seamless handoff does require some cooperation between controllers behind the scenes, which is discussed further in the section “Organizing Roaming Behavior with Mobility Groups” in this chapter.

Another important aspect to notice is what happens to the client’s IP address. Both AP-1 and AP-2 offer the same SSID and the same IP subnet (192.168.100.0/24). As the client roams, it moves between AP cells but remains in the same subnet, so it can keep using the same IP address without stopping to request a new one from a DHCP server. This is also known as a Layer 2 inter-controller roam.

Inter-Controller (Layer 3) Roam

When multiple controllers are used in a network design, they might not always offer the same IP subnet on the same WLAN. That does not mean that clients cannot roam between APs hosted by different controllers. Inter-controller roaming can also support roams that cross Layer 3 boundaries. In Figure 8-4, a wireless client has roamed from AP-1 to AP-2, and from WLC-1 to WLC-2, where the APs are joined. Notice that the two APs support two different IP subnets and that the client was using 192.168.100.88 while it was associated with AP-1.

Now notice that the client is still using 192.168.100.88 after it reassociated with AP-2. Even though AP-2 (and WLC-2) does not directly offer the 192.168.100.0/24 subnet, the controllers have worked together to maintain connectivity with that subnet. A Layer 3 inter-controller roam is a cooperation between controllers that allows a subnet from one to be supported on another.

Behind the scenes, the controllers take on specific roles to support the roaming client. When the client first joins the wireless network, such as AP-1 in Figure 8-4, the controller hosting the client takes on the anchor controller role and provides the initial IP address for the client. When the client roams to a different AP that is joined to a different controller, the new controller takes on the foreign controller role. Because the foreign controller is not able to support the client’s IP address directly, it builds an additional CAPWAP tunnel to the anchor controller just to transport traffic to and from the roamed client and its original IP address.

Layer 3 roaming also involves two other roles. The point of attachment (POA) refers to the AP and controller where a wireless client is currently associated. Therefore, the POA moves to follow a client as it roams. The point of presence (POP) refers to the controller where the client is seen to be. In other words, the POP is located at the point where the client’s IP address can connect with the corresponding IP subnet and VLAN. When the client initially associates with the network, it obtains the IP address it will use and continue to use while undergoing Layer 3 roams, so its POP remains stationary. You can think of the POP as the client’s anchor point (conveniently located at the anchor controller). The POA travels with the client but is always tethered to the POP. That also means the controller-to-controller CAPWAP tunnel will move to follow the client and its POA.

Cisco WLCs also support the following two special cases of Layer 3 inter-controller roaming:

Static IP tunneling: This feature provides Layer 3 roaming for wireless clients that have statically configured IP addresses. As long as a controller directly connects to the corresponding IP subnet, it can become an anchor controller. Then foreign controllers will build CAPWAP tunnels to the anchor to transport traffic to and from the client’s static IP address.
Guest anchor: When a WLAN is defined on a controller, it can be flagged as a guest WLAN that will always be tunneled to a controller that serves as a static anchor point. In effect, clients associated to a guest WLAN will be connected to a guest VLAN connected to the anchor controller. In this way, all guest users can be contained at the guest anchor, regardless of their physical location.

Organizing Roaming Behavior with Mobility Groups

The previous section explained that wireless clients can roam between APs, even when the APs are joined to different wireless controllers. To make the roaming process consistent and transparent to the client, Cisco WLCs must work behind the scenes to keep track of roaming events and to hand off clients from one controller to another.

Defining the Mobility Hierarchy

If multiple controllers exist in a network, they must be configured into mobility groups or logical collections. As long as controllers are placed in the same mobility group, client roaming can be handled seamlessly between any of the controllers. You can place up to 24 controllers into a single mobility group. In Figure 8-5, four controllers belong to the mobility group called “Group1.” Each controller maintains a list of mobility group members, each identified by MAC address and management IP address, along with the mobility group name. The figure also lists the group members from WLC-1’s perspective. The first line of the mobility group list always refers to the local controller, which already knows its own group name assignment. Therefore, the group name is not shown in the first line of the list.

As clients roam, controllers must inform each other of the event. Even in the case of an intra-controller roam, where the client stays within the same controller, the controller must inform all other group members. Inter-controller roams involve two different controllers, so they must coordinate the roam and hand off clients from one to the other. Layer 3 roams require a further step, where anchor and foreign controllers must form a relationship and the extra CAPWAP tunnel required to transport the client’s traffic between them.

Notice in Figure 8-5 that each of the four controllers has a “connection” to every other controller in the mobility group. The controllers in the group must form a full mesh of unicast connections so that they can communicate events and handshake with each other. Imagine what the full mesh diagram would look like if the maximum of 24 controllers were members of the same group! Fortunately, you can leverage IP multicast instead so that any of the controllers can send events to one multicast address and reach all controllers in the group simultaneously.

Tip

You can learn more about configuring and using multicast on wireless controllers by reading Chapter 12, “Implementing Multicast.”

In a design with many controllers, you can group them into multiple mobility groups, each containing up to 24 controllers. However, seamless roaming is supported between a maximum of three mobility groups that are organized as a mobility domain, up to a maximum of 72 controllers in total. You can have additional mobility groups that lie outside the mobility domain, but those are considered to be in their own mobility domain. If a client roams from one mobility domain to another, the roam will be disruptive to the user experience because it requires the client to start a new association, a new DHCP exchange, and a new authentication process.

Figure 8-6 illustrates the mobility group and domain relationships. Three mobility groups, “GroupA,” “GroupB,” and “GroupC,” form one mobility domain, while “Group D” belongs to a different mobility domain. Only two controllers are shown in each mobility group for simplicity. Clients can roam between any controllers in any of the three groups, A through C, and preserve their connectivity. Roaming between controllers that lie in different mobility domains is still possible but will be disruptive to the user experience.

One interesting thing about mobility groups is the manner in which they are defined and configured. Each controller must have a complete list of itself and every other controller in the mobility domain, but the mobility domain itself is not explicitly defined. Consider the list of group members defined on WLC-A1 in Figure 8-6. WLC-A1 appears on the first line without a group name, followed by WLC-A2 with “GroupA.” GroupB is defined as controllers WLC-B1 and WLC-B2, and GroupC as WLC-C1 and WLC-C2. Each of the other controllers must have its own list, too, so that each controller has the same concept of the mobility group memberships. Mobility group “GroupD” is never mentioned in the list because it lies outside the three-group maximum for the first mobility domain. Instead, it forms the only group that is part of the second mobility domain.

Exploring Mobility Operations

Each type of client roam involves a different communication exchange between controllers. Even before roaming the first time, a client must associate with an AP somewhere in the network. In Figure 8-7, the client has associated with AP-1 on WLC-1. Therefore, WLC-1 must announce the client’s action so that all other controllers in the mobility domain will be aware of the event. This is done by sending a Mobility Announce message to every other controller—either by unicast to the full mesh of controllers or by a single multicast.

Now consider an intra-controller roam, as depicted in Figure 8-8. The client roams from AP-1 to AP-2, both joined to WLC-1. The controller is able to update the client’s association change (technically a reassociation) internally, but it must also send a Mobility Announce message to update all other controllers.

Layer 3 inter-controller roams are a bit more complex because they involve an interaction between two different controllers and their roles. In Figure 8-9, the client has roamed from AP-2 to AP-3, moving from WLC-1 to WLC-2. The event begins with a Mobility Announce message from WLC-2 to inform all other controllers where the client is now reassociated or attached. WLC-1 must also communicate a Mobile Handoff event about the move from WLC-1 to WLC-2. Finally, the two controllers must take on the anchor and foreign controller roles to support the client’s original IP address on an AP with a different subnet. This is done through an exchange of Mobile Anchor handshake messages.

Validating the Mobility Hierarchy and Tunneling

Cisco WLCs exchange mobility traffic with each other using various tunneling methods, depending on the controller platform. The most recent platforms, such as the Catalyst 9800, transport mobility control messages over encrypted CAPWAP tunnels. Client data traffic is also transported over CAPWAP tunnels, but encryption is optional. Legacy controller platforms that are based on AireOS software prior to release 8.5 transport mobility messages over Ethernet-over-IP (EoIP) tunnels (IP protocol 97) and UDP port 16666. AireOS platforms running release 8.5 or later support encrypted CAPWAP.

If a network consists of a mix of controller platforms, you should validate that mobility messaging actually works between them. Mobility messages cannot be exchanged at all between Catalyst 9800 and AireOS platforms unless the AireOS controllers are running release 8.8.111 or later, which introduced the Inter-Release Controller Mobility (IRCM) feature.

Also, the network may have a firewall or some problem that prevents the mobility messages from being delivered successfully. You can use the commands listed in Table 8-2 from the controller CLI to verify successful messaging connectivity. Test packets are sourced from the controller’s management IP address and target the far end controller’s management IP address. Example output from the cping command is shown in Example 8-1.

Table 8-2 CLI Commands for Testing Mobility Messaging Between Controllers

Description	Command Syntax
Test mobility messaging over CAPWAP	cping ip-address
Test mobility data over EoIP	eping ip-address
Test mobility control messaging over UDP port 16666	mping ip-address

Example 8-1 Sample Output from Testing CAPWAP Mobility Messaging to WLC 192.168.250.10

Click here to view code image

(Cisco Controller) >cping 192.168.250.10
Send count=3, Receive count=3 from 192.168.250.10
(Cisco Controller)>

Optimizing AP Selection for Client Roaming

As a wireless client device moves around, it must roam from one AP to another to maintain good connectivity. Because the clients, and not the APs, can be in motion, they must play the active role in finding and maintaining a usable signal. Therefore, the decision to roam is normally reserved for the client device. This section explores the decision process and various methods that can make it more efficient.

Optimizing the AP Scanning Process

Wireless clients usually use a proprietary algorithm to decide when it is time to roam. Imagine a client device that begins its association very near to an AP. RF conditions there should be good, with a high RSSI (both AP at the client and client at the AP) and a high SNR. The data rate will likely be higher and 802.11 frames will be received intact and uncorrupted.

Now imagine the client as it moves away from the AP, as shown in Figure 8-10. The RSSI will get lower and lower as the client gets near the AP-1’s cell boundary. SNR will also reduce because of the lower signal strength. The data rate will fall, and more frames will be lost between the client and the AP. At some point along this path, the client should realize what is happening and try to find a new, better AP to join. Hopefully the client will do this well ahead of time—before the RF conditions get too low to stay connected to the AP, with enough time to allow for the roaming process itself to take place.

Generally a client device will monitor parameters such as the AP’s RSSI, the SNR, data frame retries, and how the data rate is shifting before attempting to roam. The values and combination of these thresholds are usually proprietary and not configurable, and they can vary from one device to another. Some clients offer a “roaming aggressiveness” setting, which can modify the thresholds so that roaming occurs more or less frequently, but the setting values are usually generic terms such as low, medium, high, and so on.

With no outside assistance, a client device must attempt to discover any neighboring APs that might offer RF conditions that support a better connection. During times when the client radio is idle and has no data to transmit, it can scan through all of the available channels (and bands) and use one of the following methods to find candidate APs:

Passive scanning: The client tunes its radio to a channel and waits a short time to receive 802.11 beacon frames from any AP and SSID.
Active scanning: The client tunes its radio to a channel, transmits an 802.11 probe request frame, and then waits a period of time to receive any probe response frames from APs.

Passive scanning can be useful when a client needs to conserve battery power because it involves only receiving frames, rather than transmitting too. However, it requires the client to dwell longer on each scanned channel to wait for beacons, which are transmitted every 102 milliseconds. The client might have to wait even longer to receive a beacon that advertises the specific SSID that is needed.

In contrast, active scanning is a more efficient use of time because the client can request a specific SSID from listening APs. Probe responses are usually returned within about 10 milliseconds.

By default, client devices usually scan every possible channel in both the 2.4 and 5GHz bands. The time spent dwelling on each of many channels can cause the roaming process to become disruptive. For example, voice calls require a latency that is less than 150 milliseconds; if it takes longer than that to roam between APs, the audio quality can suffer. One solution is to reduce the total number of channels and bands to scan. Some environments may choose to disable all DFS channels on the controllers and APs. If that is done, then the same channels should be disabled on the clients as well, so that they do not waste time scanning channels that are not in use.

Optimizing with CCX Assistance

Client devices that support the Cisco Compatibility Extensions (CCX) can interact with a Cisco wireless network beyond the basic 802.11 operations. CCX can offer the following features to assist clients to roam more efficiently:

Roaming thresholds: You can configure thresholds on the controller that get pushed out to clients supporting CCX version 4 or better. You can set the minimum AP RSSI (−85 dBm by default), roam hysteresis or how much greater a different AP’s RSSI must be before a roam (default 3 dB), the threshold to trigger active scanning (default −72 dBm), and the maximum time for the client to complete a scan and roam (default 5 seconds).
Enhanced neighbor list: As clients that support CCX version 2 or better associate with an AP, they share data about the APs they roamed from. The AP can then maintain a neighbor list to share with other clients as they associate. Compatible clients can use the list to make more efficient choices as they roam away from the AP.
Directed roam request: A controller can send a request informing a client that it might benefit from roaming to a different AP from the one currently in use. The client must support CCX version 4 or better, and it may choose to follow the controller’s guidance or ignore it.

Tip

The CCX roaming threshold parameters can be configured per band, under Wireless > 802.11a/n/ac > Client Roaming and Wireless > 802.11b/g/n > Client Roaming.

Optimizing with 802.11k Assistance

A Cisco wireless network can support 802.11k, which is a standards-based method of assisted roaming. As long as the client also supports 802.11k, the APs and controllers can interact with it to suggest the need to roam, as well as a list of known-good candidate APs it can roam to. This interaction is performed with 802.11 action management frames. The following steps are taken in the assisted roaming process:

The AP where the client is currently associated determines that the client is moving away, as the client’s RSSI is seen to be decreasing.
The AP informs the client that it should roam soon.
The client requests a list of neighboring APs from the associated AP.
The AP sends the client a list of neighboring APs that offer the same SSID, along with their channel numbers.
The client reassociates to the best AP in the neighbor list.

Notice that 802.11k places the decision to roam on the AP rather than the client. Granted, the client is still free to initiate the roam by requesting the list of candidate APs and requesting the actual reassociation, but the AP (and its controller) help with the decision process.

In fact, you might have noticed that the whole process never mentions the client using passive or active scanning to find APs. With 802.11k, the client does not need to scan on its own because the AP provides the list of candidate APs. This means the client does not have to tune its radio off-channel to scan other channels, nor does it have to expend battery power to transmit probe request frames to find APs.

In step 4, the AP sends a list of neighboring APs that is generated dynamically, rather than one that is maintained on the controller like the CCX enhanced neighbor list. The dynamic information comes from the RRM neighbor list that is collected from the NDP advertisements sent between APs. Indeed, the 802.11k standard is part of the RRM process definition.

The neighbor list sent by the AP contains up to six candidate APs the client can try. The APs are prioritized in the list according to the expected RSSI at the client location, the floor location, and the roaming history collected by the controller. The controller is able to leverage Cisco Prime Infrastructure to limit the list of neighbors to APs that are located on the same floor level as the client’s current AP. The controller can also adjust the neighbor priorities to favor one AP over another, effectively load-balancing clients across APs by influencing which AP appears best for each client.

Tip

You can configure 802.11k on a per-WLAN basis in the WLANs > WLAN > Advanced tab. By default, it is disabled. Once enabled, it can send neighbor lists only on the client’s current band or on both bands.

Optimizing with 802.11v Assistance

The 802.11v amendment defines several wireless network management methods. BSS Transition can be used to influence client roaming behavior. For example, a client can send a “solicited request” to its associated AP to ask for a list of neighboring APs it might roam toward.

APs can also use 802.11v to send unsolicited requests to a client, in order to suggest that it is time for the client to roam or make a BSS transition. The client’s signal strength at the AP might be getting low enough that it would actually fare better by reassociating to a different AP. Or the AP might suggest roaming as a means to lighten the client load on the current AP.

The unsolicited BSS transition requests are exactly that—the AP suggests, but does not mandate, a roam. The client is free to decide whether or not to roam; if not, the AP can continue monitoring the client and dissociate it if it does not eventually roam.

Through 802.11v, an AP can also control admission by refusing to let clients with weak RSSI to associate at all.

Tip

802.11v can be enabled and configured on a per-WLAN basis in the WLANs > WLAN > Advanced tab.

Optimizing Security Processes for Roaming

This chapter began with a review of the four basic steps of the roaming process. The fourth step involves the interaction between the client, the AP, and perhaps a RADIUS server, to implement a secure wireless connection. Because of the complexity involved, that step can be the most time consuming. The following sections explain the problem and some solutions to make secure roaming more efficient. The solutions are commonly called “fast secure roaming” methods.

RSN in a Nutshell

The 802.11i amendment defined a robust security network (RSN) as a wireless network that leverages cryptography to secure the integrity and content of data passing between APs and their associated clients. The security measures require a hierarchy of cryptographic keys to be generated, derived, and then used during a wireless session. An RSN also requires WPA2 or WPA3 to implement the necessary key generation and mechanisms for robust security.

Recall that WPA2 and WPA3 have personal and enterprise modes that can authenticate wireless clients with a pre-shared key (PSK) and 802.1X, respectively. With a PSK, all wireless clients and APs allowed to participate in a WLAN are configured with the same key string. With 802.11X, EAP is leveraged so that an external RADIUS server can authenticate and authorize clients to connect.

Figure 8-11 shows an overview of the entire process when a client associates with a WLAN that is offered by an AP. Working from the top down, the client and AP must progress through the familiar 802.11 probe, open authentication, and association exchanges. This part of the process is normally quick and can be made more efficient through the features described in the previous sections.

Once a client is associated with the AP, it must be authenticated and cryptographic keys generated for its session. An entire hierarchy of keys must be generated, beginning with the Master Session Key (MSK). If WPA2-Personal or WPA3-Personal is in use, then the MSK is derived from the pre-shared key. Otherwise, the MSK is derived during the EAP exchange as the client is authenticated by the RADIUS server. In turn, a Pairwise Master Key (PMK) is derived from the MSK and will be used to derive further keys involved with unicast communication and the client. Refer to Figure 8-12 for an overview of the key hierarchy, acronyms, and the order in which they are derived from each other.

The controller also generates a Group Master Key (GMK) that will be used to derive further keys to protect multicast and broadcast traffic. Because the GMK is used for broadcast and multicast traffic, it is meant for multiple clients at a time. Therefore, the GMK is generated independently of any client association, but keys derived from it will be shared with each client associated to the WLAN.

Once the master keys are ready, the client and the AP (actually its controller) must undergo an exchange of four EAP over LAN (EAPoL) frames. This is known as the 4-way handshake, which is used to derive the pairwise (PTK) and group (GTK) temporal keys. These keys will become the basis for any further keys that are needed to protect the data integrity (MIC) and encrypt the data contents (AES) of wireless frames to and from the one specific client.

The description here is meant to give an overview of the many keys involved in securing wireless traffic. Indeed, there are many keys and acronyms involved. Just remember that master keys produce temporal keys, that pairwise keys are specific to a client, and that group keys are used for multiple clients.

Then remember that the whole process of authenticating with 802.1X and generating keys is complex and lengthy. Why is that important? By default, 802.1X will block any data traffic going to or from the client until the client can be authenticated through EAP and its wireless session secured. In the meantime, the client must simply wait until communication can begin. That might not matter too much during an initial association with an AP, as data has not yet begun to flow anyway.

Any time a client roams to a different AP, it must go through the entire process shown in Figure 8-11 again because it must be authenticated at the new AP. New cryptographic keys must be generated again because they are not shared among APs. This process can take a second or more to complete. During that time, the client must wait and any data flow already in progress will be disrupted—something that becomes very noticeable to voice and real-time applications. In other words, such a roam is not seamless at all.

One other sometimes unexpected outcome is the impact that secure roaming has on the authentication resources. Consider a large university where many large classrooms are full of people. While classes are in session, large populations of users are sitting still and are mostly not roaming. Most classes begin and end at the same time, so all students go into motion at roughly the same time. This results in large bursts of authentications, which can tax the RADIUS resources.

The solution to making secure roaming more seamless is to somehow shorten the authentication and key generation processes. The sections that follow explain several approaches that you can leverage in a wireless design, along with the benefits and drawbacks of each.

PMKID Caching or SKC Caching

Pairwise Master Key ID (PMKID) caching, also called Secure Key Caching (SKC), was introduced with the 802.11i amendment as an optional solution to improve roaming efficiency.

The client and an AP form a security association after a successful 4-way handshake and key exchange process. If the client roams elsewhere and then returns to an AP it has joined before, it can identify itself in a reassociation request frame with the cached security association name that references its PMK. The client and AP must still undergo a 4-way handshake, but the full EAP interaction with a RADIUS server can be bypassed and the PMK does not have to be generated again.

PMKID Caching has some limitations. The caching is only locally significant to specific APs, so it is not a global solution. A client can benefit only when it reassociates with an AP it has visited before. APs and controllers generally have a limit on the number of PMKs that can be cached, which can become a problem in a network with a large number of clients. PMKID caching is an optional feature that is not widely supported on client devices, and it’s not supported during inter-controller roams on Cisco WLCs.

Opportunistic Key Caching (OKC)

Opportunistic Key Caching (OKC), also called Proactive Key Caching (PKC), is very similar to PMKID Caching because one PMK is generated and cached per client. The PMK is cached for the lifetime of the client on the WLAN and is shared across all APs that are joined to the same controller.

OKC differs from PMKID because only one PMKID is needed per client. Clients can reassociate to any AP, with no prior association, as long as OKC has shared the client’s PMK information ahead of time. OKC is limited by its support across platforms because it is not defined in the 802.11 standard.

Preauthentication

Preauthentication was also introduced in the 802.11i amendment. Its goal is to allow a client to associate with an AP and then instruct the AP to send enough information on to a list of neighboring APs so that they can preauthenticate the client even while it has not yet associated with them. The AP-to-AP communication occurs over the distribution system (DS). Each of the neighbor APs can run through the EAP authentication and PMK generation for the client ahead of time. Then, when the client moves and reassociates to one of the neighboring APs, it can bypass the time-consuming EAP and PMK steps and move directly into the 4-way handshake.

Preauthentication has more limitations than benefits. For example, it was never widely adopted and is not supported on Cisco APs or WLCs at all. RADIUS resources can become taxed as clients attempt preauthentication with multiple APs in an area.

CCKM

Cisco Centralized Key Management (CCKM) is a proprietary fast secure roaming method. A wireless client goes through the entire EAP authentication and 4-way handshake and then the controller caches the client’s PMK for 1 hour. If the client roams back to the original AP or to a different AP on the same controller, the PMK is already cached, so only the PTK needs to be generated. That means the reassociated client can skip both the EAP and the 4-way handshake processes.

CCKM also works across multiple controllers and mobility groups because the controllers pass the client’s credential information as part of the mobility handoff. However, it is Cisco proprietary and requires a client to run a CCX version that supports the specific EAP method in use. For example, WPA2 with 802.1X, AES, and EAP-TLS require CCX version 4 or 5.

802.11r: Fast BSS Transition (FT)

The 802.11r amendment defines a standards-based technique for fast transition between APs. The technique is similar to the other fast secure roaming techniques presented in this chapter, as client key material is shared among APs to preauthenticate the client. However, 802.11r leverages a clever twist to the roaming process itself to make the transition even more efficient.

A client capable of using 802.11r begins with a full AP association, as shown in Figure 8-13. The figure looks very similar to the normal AP association process from Figure 8-11, with two small changes. During the 802.11 authentication and association request/response exchanges, the client signals that it would like to use 802.11r by including RSN and FT information elements within the frame contents of its requests. If the AP also supports 802.11r FT, it includes those elements in its responses. The frames also contain information about the keys that will be involved in the client’s secure session.

You might have noticed another change in the key derivations in the “PSK or 802.1X” portion of the figure. The 802.11r still depends on a hierarchy of cryptographic keys, but it expands on the scope and use. As a result, the key names are somewhat different from normal RSN keys. Every client still has an MSK, but the PMK is split in two. PMK-R0 is derived from the MSK, while PMK-R1 is derived from PMK-R0. The basic idea is to distribute a client’s PMK material across multiple “key holders” within the network. For example, a client’s PMK-R0 might be held by a controller while PMK-R1 is held by some APs. Each client still derives a PTK and a GTK with the PMK-R1 holder.

Like every other fast secure roaming scheme, the 802.11r initial association process is not very different from normal. The efficiency gains come from steps in the reassociation that can be bypassed. Figure 8-14 shows a typical 802.11r roam and reassociation. At the top of the figure, the client is associated with AP-1 for its data connection; at the bottom, the client has reassociated with AP-2. The step for 802.1X and EAP exchange has been bypassed, as well as the step for PMK generation. Did you notice that the 4-way EAPOL handshake for PTK and GTK keys is also missing?

The handshake is cleverly moved to coincide with the 802.11 open authentication and reassociation exchanges, which occur at the very beginning of every roam. Enough of the higher-level key information about the client’s prior 802.1X and security association is shared across controllers and APs within the mobility domain, even before the client needs to roam anywhere.

Along with the normal 802.11 content, the client adds RSN and FT information elements into its authentication and reassociation request frames. The AP works with the same elements in its response frames. The client begins by presenting information about its PMK-R0 key and key holder; then the AP references the PMK-R1 key and holder. If the key information checks out, the client and AP can go ahead and generate the PTK and GTK keys—even while the client is authenticating and reassociating! Once the AP sends a reassociation response frame, the client can begin using a fully secured connection.

The FT process bypasses EAP and the usual 4-way handshake during reassociations for both PSK and 802.1X clients. To accomplish an efficient roam, a client can participate in an FT 4-way handshake in an over-the-air or over-the-DS exchange. With over-the-air, the client is free to contact the next AP directly for the FT 4-way handshake. In contrast, over-the-DS requires the currently associated AP to relay the FT 4-way handshake to the new AP over the DS or wired network. In practice, over-the-DS is rarely implemented and used by clients.

Because of the unique handshake and key structure, 802.11r can work only if both the client and the AP/controller can support it. In fact, the client must signal to the AP that it wants to use FT. What if a network has clients that are not capable of FT? The 802.11r amendment defines a mixed or hybrid mode that is supposed to work with FT and non-FT clients, but some legacy clients still are not able to understand the necessary information elements. Cisco WLCs also offer an adaptive mode that supports even clients that are not able to recognize the RSN information elements in frames.

Fast Secure Roaming Review

This chapter has covered a variety of common methods to improve roaming efficiency in a robust secure network. As you review and compare the methods, be sure you understand the process that a wireless client goes through to join a secure WLAN. Specifically, remember where the 4-way handshake lies in the order of steps, and remember that most of the methods try to bypass the time-consuming 802.1X/EAP authentication and PMK generation steps. You can also refer to Table 8-3 to review the benefits and limitations of each method.

Table 8-3 A Summary of Common Fast Secure Roaming Methods

Fast Secure Roaming Method	Roaming Benefits	Limitations
PMKID Caching, SKC	Bypasses 802.1X/EAP and PMK generation steps	Optional Not widely supported Does not work for inter-controller roams
Opportunistic Key Caching (OKC), Proactive Key Caching (PKC)	Bypasses 802.1X/EAP and PMK generation steps One PMKID per client for lifetime on WLAN PMK shared across all APs	Not defined in 802.11 standard Not widely or consistently supported
Preauthentication	Bypasses 802.1X/EAP and PMK generation steps	Not widely adopted Not supported on Cisco WLCs Bursty EAP activity can tax RADIUS servers
CCKM	Bypasses 802.1X/EAP, PMK generation, and 4-way handshake	Cisco proprietary Requires client with CCX version that supports specific EAP method
802.11r, Fast BSS Transition (FT)	Standards based Bypasses 802.1X/EAP, PMK generation, and 4-way handshake Adaptive mode can work with FT-capable and non-FT clients	Requires support on client and AP/controller

Summary

This chapter described the main considerations needed to design a wireless network that maximizes client mobility and roaming. More precisely, you have learned the following:

How client roaming is handled by various controller topologies
How you can leverage logical mobility groups to organize controllers and their APs
How you can verify mobility communications between controllers
How wireless clients discover available APs and how the 802.11k and 802.11v features can make roaming more efficient
How various fast secure roaming features operate and can maximize roaming efficiency

Exam Preparation Tasks

As mentioned in the section “How to Use This Book” in the Introduction, you have a few choices for exam preparation: the exercises here, Chapter 18, “Final Preparation,” and the exam simulation questions in the Pearson Test Prep Software Online.

Review All Key Topics

Review the most important topics in this chapter, noted with the Key Topic icon in the outer margin of the page. Table 8-4 lists these key topics and the page numbers on which each is found.

Table 8-4 Key Topics for Chapter 8

Key Topic Element	Description	Page Number
List	Client association process	167
Figure 8-2	Intra-controller roaming	168
Figure 8-3	Inter-controller roaming	169
Figure 8-4	Layer 3 roaming	170
Figure 8-6	Mobility domain and groups	173
Table 8-2	Commands for testing mobility messaging between controllers	175
Figure 8-11	Client association in a secure WLAN	180
Figure 8-13	802.11r client association process	184
Figure 8-14	802.11r fast transition roaming process	184

Define Key Terms

Define the following key terms from this chapter and check your answers in the glossary:

fast BSS transition (FT)

foreign controller

inter-controller roaming

intra-controller roaming

Opportunistic Key Caching (OKC)

PMKID Caching

point of attachment (POA)

point of presence (POP)

preauthentication

proactive key caching (PKC)

reassociation

SKC Caching