Recently I was asked by a customer to provide a presentation on wireless roaming, specifically 802.11r/802.11k. I wanted to share some of my presentation talking points at a high level with you. Before we dive into specific features and protocols, let’s go over the two categories to consider when implementing roaming methods.
The first category of roaming methods are the “802.11 standards”. 802.11 standards are suggested and/or described in a ratified IEEE 802.11 standard/amendment, verified by the wifi-alliance in certified wireless hardware, and may or may not be adopted by certain manufacturers. Since these roaming methods are defined in the protocol itself, careful consideration should be taken prior to enabling these roaming methods in your environment. For example, 802.11r, known officially as “Fast BSS Transition” was the first method officially ratified by the 802.11 standard. However despite it being defined as a standard, was not 100% adopted by hardware manufactures and can cause issues if implemented in an environment which has unsupported client hardware. For example, some apple devices use a proprietary 4 way handshake for 802.11r that is incompatible with traditional 802.11r and in this case, having FT enabled would prevent these Apple clients from associating to the WLAN. Figure 1 below shows an Apple client association to an AP that has FT enabled. Notice the AKM field?
The second of the two are the “proprietary” methods. Proprietary methods are those created by specific manufacturers of wireless hardware such as network adapters, access points, and controllers. These methods are not defined in 802.11 standards and are generally compatible without affecting other vendor hardware. Using the previous example of Apple, Cisco created a proprietary method known as “Adaptive FT” to workaround the issue of incompatible Apple devices not being able to associate to 802.11r enabled WLANs. Prior to this features existence, users might have had to create a second WLAN and/or disable 802.11r completely so that these specific apple devices could associate. Enabling the feature “Adaptive FT”, allows for proprietary apple devices to associate to the WLAN and use 802.11r, however this feature should not be used if you require non-apple devices to use 802.11r, as Adaptive FT mode only works for Apple and disables 802.11r functionality for all non-apple clients. Figure 2 shows the option for enabling Adaptive FT on a Cisco 9800 controller
TIP : Creating a new WLAN for the purpose of testing new features for your wireless network is a good way to test without affecting production.
During testing, make sure all AP models and client hardware are represented.
Be sure and remove the "test" WLAN when finished.
The main takeaway here folks is that you don’t want to just start enabling protocols and features on your wireless network without verifying compatibility first and performing serious testing! Verifying compatibility means gathering up all your hardware makes, models, driver versions, etc and verifying the features you want to enable are going to supported. For example, if I wanted to see if my Intel 8260 adapter in my laptop supports 802.11r I might could check intel.com.
So now that’s out of the way….lets get down to the specific roaming methods, proprietary and IEEE standard. (and apologies for only having Cisco gear to talk about, I’m a Cisco guy!)
Band Select (proprietary)
When enabled on a Cisco Controller, the Band Select feature suppresses the 2.4 AP probe responses so that clients will favor the 5ghz band. This feature is useful not only for clients that tend to connect to 2.4, but even for clients that tend to connect to 2.4 even though their settings are configured to favor 5ghz.
Load Balancing (proprietary)
When enabled, the Load Balancing feature prevents clients from associating/roaming to “busy AP's”
It accomplishes this by either looking at the Client count or the AP uplink usage. The downside is Load Balancing cannot disassociate a client that has already associated to an AP that is or has become busy since the client initially connected….bummer.
· Client Count
config load-balancing window <client_count>
· AP uplink usage
<config load-balancing uplink-threshold <traffic threshold>
Optimized Roaming (proprietary)
Cisco’s Optimized Roaming (OR) features use the Coverage Hole Detection (CHD) thresholds such as the RSSI threshold, to determine the best AP’s for a client to roam to. The main difference in OR when compared to Load Balancing is that OR can disassociate clients that fail to meet the configured thresholds. For example, if you set the CHD RSSI threshold to -72, then OR will disassociate the client if the AP’s “perceived” RSSI of said client falls below. The AP will flat out reject a new association if the perceived RSSI is 6dbm or more below the RSSI threshold.
· The RSSI threshold is determined from configured CHD threshold
config advanced 802.11<a/b> coverage data rssi-threshold <dbm>
· Exception for % of packets at or below RSSI threshold (this command delays client dissociation until x % of packets fail)
config advanced 802.11 a/b coverage data fail-percentage <percent>
· Number of packets received (minimum # of packets received from client to trigger dissociation) config advanced 802.11 a/b coverage packet-count <num-packets>
· Roaming data-rate threshold (disabled by default and optional. This will disassociate clients at a specified data rate or lower which may work well for sticky clients)
config advanced 802.11 a/b optimized-roaminig datarate <mbps>
· Optimized roaming interval (interval in seconds in which the AP reports client stats to the WLC for OR calculation)
config advanced 802.11 a/b> optimized roaming interval <seconds>
*NOTE* Some clients can’t interpret the Load Balancing “I’m busy go away!” message code 17 response that comes from the AP and therefore may be doomed, never to associate! But no worries in that situation you can always set the max denial count. Using this command on the WLC, after x amount of “go away I’m busy messages”, the AP will allow the client to connect.
Config load-balancing denial <denial count>
802.11K
The 802.11k standard, also known as “assisted roaming”, is designed to make roaming more efficient by eliminating the active/passive channel scanning and decisions the client would typically perform during traditional roaming. This is accomplished by the client first sending an action frame to its currently associated AP requesting a list of viable AP neighbors to roam to. The AP replies with another action frame providing the client with the neighbor list consisting of the AP’s and channel numbers of desirable candidates for the WLAN. At this point, the client does not need to scan for available channels nor does the client have to search for an AP to roam to as it has already been provided all the information it needs to make a good roaming decision. Implementing 802.11k improves bandwidth and channel utilization overall as well as improves the battery life of the client.
802.11v
Similar to Cisco’s proprietary feature “Optimized Roaming”, 802.11v, also known as BSS Transition Management Request, provides suggestions to aid client roaming decisions. It does not disassociate clients by default like OR does, but you can force a client to dissociate by turning on the disassociation-imminent function. The optional command will disassociate the client if it does not re-associate to another AP within a specified period of time. 802.11v is applied to clients using 3 methods: Client initiated solicited requests, AP initiated unsolicited request, and an unsolicited optimized roaming request sent from the AP which it triggered when the clients RSSI does not meet the configured threshold.
Client sends solicited request to its current AP asking for recommended AP's to roam to (Reason codes (has information as to why the client decided to roam)
Unsolicited requests come from the AP based in several different scenarios.
If BSS transition is enabled along with Load balancing the AP proactively transmits a BSS mgmt request to clients suggesting less loaded AP's when the client meets the configured LB criteria
If 802.11v + OR is enabled then clients are no longer disassociated, but rather better AP's are "suggested" in the BSS mgmt requests based on RSSI
Cisco AP’s that support “FRA” (flexible radio assignment) have dual 5ghz radios. In this situation, the AP will suggest better radio in the unsolicited request.
CCKM - Cisco Centralized Key Management
CCKM was a proprietary fast-secure roaming method created by Cisco. It was designed with the purpose of removing the overhead of 802.1x/EAP authentication when roaming. This is accomplished using its own key negotiation scheme and creating a global PMK cache for the client which is shared to all controllers in the mobility domain. Upon roaming, the client only needs to send a single reassociation request to the AP. Additional handshakes and additional EAP frames are avoided because the keys have already been derived and the already cached information on the WLC/client is used to complete the reassoication to the new AP. CCKM was never widely adopted and requires CCX to function. The final nail in the coffin was when Intel stopped supporting CCX for their wireless adapters in 2018 due to an OpenSSL vulnerability. It is for this reason that i don't recommend using CCKM anymore.
PMKID
Fast-Secure Roaming with PMKID caching, also known as "Sticky Key Caching" is a bit of an odd duck. This method is suggested in the 802.11i security amendment and since 802.11i is not about roaming, its kind of funny that its in there but i digress. To avoid future handshakes and EAP frames to an AP from a particular client, this method caches the PMK on the client and AP When a client first connects to an AP that it has never tried to associate to before, it goes through the full WPA/EAP authentication like normal except for the key caching taking place. The downside is literately every client in the organization has to roam and cache its PMK on every AP on the network in order to say 100% that fast-secure roaming is working in the environment.
As of this writing, PMKID Fast-Secure Roaming is the only supported method that works with WPA3. Support for 802.11r "Fast BSS Transitioning" was left out of the WPA3 standard.
802.11r – Fast BSS Transitioning
802.11r or Fast BSS Transitioning was the first method ratified for the IEEE 802.11 standard. This amendment introduced a new key hierarchy and is different from the other methods based on its ability to cache PMK’s on different devices in the mobility domain. Unlike PMKID caching methods, 802.11r is able to skip the 4 way handshake phase after the reassociation exchange. Instead, the 4 way handshake occurs before the client fully roams/associates to its new AP.
Traditional roaming without 802.11r requires full association and authentication. In the case of WPA, we must 4 way handshake every time we roam. The client cannot send data until the 4 way handshake is completed. As if the 4 way handshake process wasn’t time consuming enough, consider the scenario of a client authenticating via 802.1x over a WAN connection to a Radius server such as Cisco ISE. I have seen dot1x auth take over 1 full minute to complete without any kind of roaming assistance in place. That’s a long time to be wondering around looking for an AP…..especially when were dealing with network sensitive applications. A few times in my career I had to troubleshoot wireless in hospitals. Nurses have these mobile PC carts which move from patient room to patient room and having to authenticate across a WAN connection to a Radius server without of any kind of Fast Roaming, it isn’t pretty.
Unlike the proprietary methods previously mentioned, 802.11r requires support from the both the WLC as well as on the client side. Roaming is 100% a client decision so and roaming behavior will vary from manufacturer to manufacturer. There are several FT methods that may or may not be supported by specific client drivers so its very important to verify compatibility and perform thorough testing before rolling into production.