Wi-Fi Alliance Voice-Enterprise Certification: Standardized Fast Secure Roaming

Two of the most important aspects of building a successful modern enterprise wireless LAN are enabling transparent user mobility across the network and strong security to protect sensitive corporate data. 

However, these two objectives have historically been difficult to achieve in tandem. A balancing act between mobility and security has caused an unpleasant trade-off for organizations due to the time-consuming processes that strong security methods require. On one hand, high performance mobility can be provided when relatively weak security is implemented with an Open or WPA2-Personal WLAN, but this leaves sensitive corporate data at higher risk of exposure. On the other hand, much stronger security can be implemented with WPA2-Enterprise, lowering the exposure risk of sensitive corporate data, but resulting in poor mobility performance due to the time-consuming 802.1X authentication process. Thus, the introduction of more secure Wi-Fi networks solved one problem (security) but created another (roaming performance).

The industry needed a high performance, yet secure, solution to this mobility problem. The answer lies with fast secure roaming. Pre-standard solutions, such as CCKM and OKC have been around for some time but have failed to realize widespread adoption, especially by client manufacturers. The Wi-Fi Alliance^™ Voice-Enterprise certification program, introduced May 2012 and already appearing in major WLAN products, brings a standards-based fast roaming method to market, which serves to align infrastructure and client manufacturers on a common implementation method and provides the benefits of low-latency roaming performance while maintaining strong security with WPA2-Enterprise.

I dive deeper into the Voice-Enterprise certification program and implementation details of fast secure roaming in the new whitepaper, "Wi-Fi Alliance Voice-Enterprise Certification: Standardized Fast Secure Roaming" [PDF].

Whitepaper: Wi-Fi Alliance Voice-Enterprise Certification
(Click to Download)

Download this whitepaper to learn:

• Challenges in providing both transparent user mobility and strong security
• Requirements that products must pass to achieve Voice-Enterprise certification
• Performance criteria that Voice-Enterprise products must achieve
• Technical details of the Fast BSS Transition specification, based on IEEE 802.11r, for both controller-based and controllerless WLANs
• Performance optimizations available with Radio Resource Measurement (802.11k) and Wireless Network Management (802.11v), both part of the Voice-Enterprise program

Cheers,

Andrew



Additional Wi-Fi Roaming Blog Posts You Might Be Interested In:

1. Part 1 - Connection Control and Importance of Roaming Analysis
2. Part 2 - The Many Variations of Wi-Fi Roaming
3. Part 3 - Methods of Measuring Roam Times
4. Part 4 - Analysis with Wireshark and AirPcap
5. Apple iOS Fast Roaming with Aerohive Wi-Fi APs

Apple iOS Fast Roaming with Aerohive Wi-Fi APs

Well folks, after what seems like an eternity, true standards-based Wi-Fi fast roaming is really here! I blogged back in December that Apple iOS version 6.01 added support for fast roaming with 802.11r and 802.11k. And WLAN infrastructure vendors have added support as well, with Aerohive 6.0 and Cisco 7.2 code releases.

Recently, I had the opportunity to test this functionality out on an iPhone 5 and an iPad mini with an Aerohive WLAN. I'd like to share my results with you... and I can tell you that you won't be disappointed! How do 8.5ms roams sound?!

Apple iPad Fast Roaming (1) and Aerohive AP Neighbor Report (2)

As you can see, the iPad completes the roam in 8.5ms, the time it takes to complete the 802.11 authentication and reassociation; no full 802.1X authentication, RADIUS TLS session resumption, or even 4-way handshake are required! This is the result of support for the Wi-Fi Alliance Voice-Enterprise certification on both the WLAN and client. In the tests that were captured, the WLAN was configured for WPA2-Enterprise with 802.1X authentication and dynamic keying. The initial client association resulted in a full 802.1X authentication with the RADIUS server, followed by fast roams as shown above.

Roaming with 802.11r (Fast BSS Transition) is noticeably faster than other proprietary fast-roaming methods (OKC/PKC) and it's also faster than roaming on a Pre-Shared Key (PSK) WLAN. This is because the 4-Way Handshake exchange can be eliminated by embedding the key derivation material (ANonce, SNonce, MIC, and GTK) within the Fast Transition Information Element inside the 802.11 Authentication and Reassociation frames. There is also a Mobility Domain IE that comes into play to distinguish boundaries between different WLANs (since key material must be exchanged between APs on the backend, two separate WLANs cannot facilitate fast roaming).

Here's a look at the Fast Transition IE inside the Reassociation Response (frame 18) from the AP to the iPad:

802.11r Fast Transition Information Element

You may want to review my previous post on The Many Variations of Wi-Fi Roaming to compare the frame exchanges required with each roaming method, CWNP's whitepaper on Fast BSS Transition [PDF] and blogs (here and here) to understand the key hierarchy and exchange between the initial AP authenticator (PMK-R0) and subsequent APs (PMK-R1).

Immediately after the fast roam completes, the Apple iPad submits a Neighbor Report Request within a Management Action frame. In essence, the client is requesting a list of all the neighbors from the AP in order to build a list for future roaming events. This report can be requested on-demand by the client and can help improve roam times by reducing or eliminating the need for the client station to actively scan off-channel. This way, the client has a list of nearby APs that is always up-to-date and can quickly move to another channel where it knows another AP is waiting.

Here is a look inside the Neighbor Report sent back to the iPad from the Aerohive AP (frame 21):

802.11k Neighbor Report

Unfortunately, Wireshark does not yet have a protocol dissector for 802.11k neighbor reports, so manual decoding must be performed. You can see that the Category Code is 5 (Radio Measurement) is used. Inside the tagged parameters lies the neighbor report details, which contains an element for each neighboring AP in the same WLAN and details about the AP such as it's BSSID and channel number which I have highlighted above. In this case, there is one neighboring AP with BSSID "08:ea:44:78:14:28" and it is operating on channel 161 (0xA1 in hexadecimal). Other information in the report includes AP's reachability, security policy (similar or different), and capabilities for spectrum management, quality of service, power save, block acknowledgements, and PHY type (802.11a/b/g/n).

There are three IEEE 802.11 amendments that come into play which are all bundled up in the Wi-Fi Alliance Voice-Enterprise certification.

Standards and Certification Recap
The core of fast roaming was drafted in the IEEE 802.11r amendment, defining "Fast BSS Transition"  or just Fast Transition (FT) for short. The name is derived because every individual AP radio cell is defined as a "Basic Service Set (BSS)" in the standard, and the amendment defines a method for client stations to transition (also called roaming) very fast between AP radios. It accomplishes this by defining a Mobility Domain comprised of a set of BSSs (APs) within the same Extended Service Set (ESS, otherwise known as an SSID) which have been validated. Validated APs must coordinate with each other to exchange client station details, including pairwise master key (PMK) encryption material, and perform pre-authentication of the client prior to the roam. This speeds the client roam by eliminating the need to re-authenticate the client through 802.1X/RADIUS or having to perform the 4-Way Handshake to derive pairwise transient key (PTK) encryption key material even in the case of a simple PSK network. The 802.11r amendement was ratified in 2008.

The IEEE 802.11k amendment on "Radio Resource Measurement" defines methods for information exchange about the RF environment between APs and client stations. The goal is to enable the client stations to understand the radio environment in which they exist so that they have more information to make correct decisions about roaming and performance. Stations can take radio measurements locally, request measurement by other stations, or have measurement requested of them and return the results. One interesting aspect for fast roaming is the Neighbor Report, where a client can request an AP to measure and report the neighboring APs which are available within the same Mobility Domain, including several pieces of operational information about each neighbor such as: BSSID, channel, security policy, and capabilities for QoS, APSD (power-save), BlockAck, spectrum management, and PHY type (802.11a/b/g/n). Some other reports available with 802.11k include: channel load, noise histogram, location configuration information, link measurement, and traffic stream measurements. The 802.11k amendment was ratified in 2008 as well.

The IEEE 802.11v amendment on "Wireless Network Management (WNM)" defines methods for stations to exchange information for the purpose of improving overall performance of the wireless network. Where 802.11k is concerned only with the radio environment, 802.11v expands it to include broader operational data surrounding existing network conditions allowing stations to be more cognizant of the topology and state of the network. There are a multitude of WNM services, the most interesting (for me, at least) is the BSS Transition Management capability, whereby an AP can request a client to roam to another AP for better performance or capacity. Some other services include: co-located interference, diagnostic reporting, directed multicast services, location services, multiple BSSID capability, proxy ARP, QoS traffic capability, and traffic filtering service, to name only a few. The 802.11v amendment was ratified in 2011.

Each of these amendments define numerous capabilities, of which I will only scratch the surface in this post to highlight a few. If you are interested in learning more about the services defined in each of the amendments, visit the IEEE Get Program website to download the 802.11-2012 standard, or search the web for PDF versions of each amendment.

Aerohive WLAN Configuration
Prior to being able to test and execute a fast transition (FT) roam, you need to configure the WLAN infrastructure to support the 11r/k/v features. In Aerohive HiveManager, navigate into the Configuration section and edit the SSID on which FT roaming should be supported. In the Advanced section of the SSID configuration you will see two sections, one for WMM and one for Voice Enterprise.

Aerohive Voice-Enterprise Configuration (IEEE 802.11r, k, v)

Upon checking the first check box for Voice Enterprise, you will be presented with the following notice, informing you that Voice-Enterprise requires 802.11rkv and WMM AC-Voice which will all be enabled automatically.

You may have also noticed the note which states 802.11r requires WPA2 key management. This is because 802.11r advertises FT support in-part through the Authentication and Key Management (AKM) suites in the Robust Security Network (RSN) Information Element, which was included in the 802.11i amendment and WPA2 certification program. Pre-standard WPA did not include the RSN IE and therefore cannot support fast transition. So make sure you're using WPA2 (with either 802.1X or PSK) on the SSID as well.

Save and upload this configuration to at-least two APs, which will then begin including the Mobility Domain IE, Fast Transition IE, and Radio Management capabilities in beacons and probe responses to advertise these capabilities to clients.

Note - no explicit configuration is required to enable Voice-Enterprise on Apple iOS devices. Simply run iOS 6.01 or later and join a Voice-Enterprise enabled WLAN.

Client Limitations
In addition, the RSN IE which advertises encryption ciphers and authentication and key management (AKM) methods in-use on the WLAN to clients now includes a new AKM type to advertise Fast Transition key management. Some existing client drivers have issues parsing the RSN IE with additional AKM and will fail to association to the WLAN - in fact, they won't even try. Until client drivers are updated by manufacturers to support this addition AKM type, they will be unable to join any SSID that has Voice-Enterprise (specifically 802.11r) enabled.

Therefore, it is recommended to create a separate SSID specifically for Fast Transition capable clients and migrate them over to the new SSID.

Final Thoughts
Wi-Fi roaming performance has been a painful sore spot on the industry for many years. Problems were initially obscured through the use of open or WEP encrypted networks where roaming was relatively fast due to the simple security models implemented. However, as security improved with 802.11i and WPA2-Enterprise, roaming performance became a glaring issue, often taking >500ms or worse! This impacted the usability of real-time applications on an enterprise WLAN, forcing many network administrators to rely on less-secure PSK security methods.

Some vendors responded with proprietary fast roaming methods such as CCKM, OKC, and PKC. However, this served to fragment the industry and support for these methods were spotty at best. The IEEE thankfully stepped in and ratified the 802.11r amendment in 2008, yet it has taken nearly 5 years since then for enough momentum to build to finally implement standards-based testing and certification of fast roaming through the Wi-Fi Alliance Voice-Enterprise certification program.

However, now that standards-based fast roaming is here, IT IS GLORIOUS! I applaud Apple for being an advocate for fast roaming and implementing it into their iOS platform, likely because their devices get blamed for poor performance all the time. I encourage other mobile device manufacturers to follow suit, especially if their devices are used with real-time voice or video applications.

Cheers,
Andrew

Wi-Fi Roaming Analysis with Wireshark and AirPcap

This article is part 4 in the Wi-Fi roaming analysis series. In this post, we'll take the concepts we've learned in the first three articles and apply them in a live environment by performing a wireless packet capture and analyzing the roaming performance of an actual client device.

Remember from part 1 that roaming analysis provides insight into how decisions made on wireless architecture, network design, client selection, and configuration impact overall network performance. Performing Wi-Fi roaming analysis will enable network architects and engineers to:

1. Baseline current client roaming performance
2. Analyze gaps between current network performance and application requirements
3. Identify opportunities to improve and optimize performance
4. Implement changes to infrastructure and client devices to optimize performance
5. Take more active control to ensure network performance matches desired service levels

Throughout this blog post and the next, I will be using actual roaming events that I captured with my iPhone as an example. You can download and open this packet capture if you want to follow along.

Wi-Fi Roaming Analysis Series:

1. Part 1 - Connection Control and Importance of Roaming Analysis
2. Part 2 - The Many Variations of Wi-Fi Roaming
3. Part 3 - Methods of Measuring Roam Times
4. Part 4 - Analysis with Wireshark and AirPcap
5. Part 5 - Analysis with Wildpackets Omnipeek (coming)
6. Part 6 - Tips for Roaming Performance Improvement (coming)

Hardware Requirements
In order to perform wireless roaming analysis, you will need multiple wireless adapters to capture frames simultaneously on different channels. The hardware required  typically includes 3 wireless adapters and a USB hub. I have had good success with the Rosewill RHB-330 USB hub. Be sure to check the supported adapters list for the protocol analyzer software that you intend on using to capture and analyze the traffic.

Scanning between channels with a single adapter is not sufficient because the adapter will miss frames transmitted on alternate channels. If the scanning duration (also called dwell time) is set to a small value then the adapter will likely miss frames related to the roaming and authentication exchange because it hops away to a different channel before the roam completes. And if the scanning duration is set to a large a value then there is a good chance the adapter will be on the wrong channel when the roam occurs, as well as the inability to calculate roam times between data packets on the "old" and "new" AP as discussed in part 3 of this series. Remember, scanning ALWAYS results in missing frames. If you are scanning 3 channels, then you can only capture 1/3rd of the frames (actually less due to hop time between channels). So remember, never use channel scanning for protocol analysis!

Devin Akin originally covered multi-adapter Wi-Fi captures in his CWNP whitepaper titled The Triple Blendy. It is worth your time to read (even almost 4 years later... it has stood the test of time)!

The selection of a supported wireless adapter model for use with Wireshark can be tricky. This is because differences exist between operating system platforms which may prevent the ability to capture all wireless frames over the air. You will want to make sure that the adapter you use supports capturing in "Monitor Mode" not "Promiscuous" mode. This usually requires the Wi-Fi adapter to be disconnected from the network. Unfortunately, Microsoft Windows is very limited with regard to monitor mode support. For this reason, engineers typically take one of two approaches to capture Wi-Fi traffic with Wireshark:

1. Use a Linux Distribution with custom Wi-Fi drivers. Many Wi-Fi and Security engineers use the Backtrack distribution coupled with a compatible wireless card. However, when multiple simultaneous captures are required, separate instances of Wireshark (or Tshark, the command-line version) must be run. The capture files must then be merged together, typically using the Mergecap tool included with Wireshark. This can be tedious and more time-consuming for everyday use.
   
   
2. Use Windows with AirPcap adapter(s). The benefit of this approach is easier capturing because many engineers are unfamiliar with Linux. Engineers also do not have to run separate Tshark instances to capture each Wi-Fi channel and subsequently merge the files together since AirPcap software includes a virtual channel aggregator that can be selected for capture within a single Wireshark instance. The drawback is that the AirPcap adapters do cost money, significantly more than standard Wi-Fi client adapters that could be used with Linux.

For this article, I will be using Windows with three AirPcap Nx adapters. I won't cover the installation of Wireshark or AirPcap software since they are both straight-forward. It is also helpful to label the wireless adapters with the slot on the USB hub that they have been installed on. This will help prevent you from subsequently plugging them into a different USB slot causing device discovery and driver installation again by Windows.

Setting Up the Packet Capture
To begin capturing Wi-Fi frames, we first need to configure the channels that our AirPcap adapters will be listening on. Open the AirPcap Control Panel and select the AirPcap Multi-Channel Aggregator as the interface. In the 'Basic Configuration' section below you should see a greyed-out list of channels that the adapters are currently set to use. If these channels need to be changed, select each individual interface from the list and configure the channel. If you need to configure 40MHz wide channels, select an extension channel either above (+1) or below (-1) the primary channel. Leave all other settings at defaults (as pictured below).

AirPcap Multi-Channel Aggregator Setup

Next, launch Wireshark and navigate to the Interfaces dialog from Capture menu. You should see multiple network interfaces listed, including the AirPcap Multi-Channel Aggregator.

Wireshark Capture Interfaces

You can review the capture options by clicking the 'Options' button next to the adapter you plan on using. On wireless networks, you will typically want to disable promiscuous mode (since we want to capture in monitor mode instead). I also never use a capture filter because I like to make sure that I'm capturing all of the frames over the air. Instead, I rely exclusively on display filters applied after the capture to narrow down the packet list to only those I care to analyze. But I always like to capture everything!

Wireshark Capture Options

Start the capture from either the Interfaces or Capture Options dialogue windows and proceed to physically follow the wireless client station as it roams between access points.

A quick note should be made covering proper placement of the protocol analyzer workstation. Since the objective when performing roaming analysis is to capture all frames to and from the wireless client(s) under test, the protocol analyzer should be positioned near the client(s) rather than near an AP. Since wireless frames are encoded at a variable data rate, it is common for wireless protocol analyzers to receive frames that they cannot decode since the signal strength or SNR may be too low. Therefore, by positioning the analyzer nearest the client(s) you increase the likelihood of successfully receiving all frames both from and to those clients.

On a related note, to analyze the efficiency of wireless communications with a protocol analyzer, focus on the Wi-Fi retransmission rate rather than looking at FCS error rates since the FCS rate can be inflated simply because the analyzer workstation is not able to successfully decode all the wireless frames that it can hear in the environment. This is a common mistake many network engineers unfamiliar with Wi-Fi make.

Filtering for Frames of Interest
Display filters in Wireshark can be used to identify frames of interest for Wi-Fi roaming events. A display filter can be applied either during the wireless capture or after stopping the capture. Applying a display filter during the capture can help you ensure that roaming events are occurring and being captured by the protocol analyzer workstation. In this case you would want to filter only on frames that signal a roaming event to minimize scrolling in the live view. This is useful to avoid capturing a large amount of data only to find out that the client did not roam between APs or the workstation did not correctly capture the frames.

There are a couple of different methods to approach filtering to identify and analyze wireless roaming events that I recommend. I actually use both methods in succession, but feel free to find a workflow that works for you.

The first method that I use is to filter the packet capture on wireless association and reassociation frames, since those frames signal a new connection between a client and AP. To quickly find the roaming events within a capture file, filter the packet list for 802.11 Association Request frames or 802.11 Reassociation Request frames using the following display filter (the OR logic is denoted by the use of two pipe '||' symbols):

(wlan.fc.type_subtype == 0x00) || (wlan.fc.type_subtype == 0x02)

Take note of the packet numbers to reference where the roaming events occur in the capture list, then clear the display filter before continuing. In the example packet capture, these include frame numbers 48, 49, and 808.

Wireshark Display Filter for Wi-Fi Associations

The second method that I use is to filter the packet capture on a single wireless client station in order to analyze the roaming performance of a single device (or focusing your analysis on one client at a time). This is helpful after the roaming events have been identified using the first filtering method and corresponding packet numbers relating to roaming events have been recorded. This second filter then allows me to focus on a single wireless client and declutter the list by removing frames related to all other APs and clients. To narrow the frame list to a single wireless client, filter for the MAC address of the device in question using the following display filter (replace with the actual MAC address of the client):

wlan.addr == 0c:77:1a:c1:24:a2

This can be automated very easily by opening the Statistics > Endpoints table in Wireshark, navigating to the WLAN tab, right-clicking on the desired device and selecting "Apply a Filter > Selected".

Apply a Device Filter in Wireshark from the Statistics > Endpoints Menu

You can also combine the two filters in order to only view roaming events related to a specific client, which is very useful when capturing in a live environment with multiple clients in the area. The display filter would combine the two component filters with AND logic, denoted with two ampersands '&&' as follows:

(wlan.addr == 0c:77:1a:c1:24:a2) && ((wlan.fc.type_subtype == 0x00) || (wlan.fc.type_subtype == 0x02))

Wireshark coloring rules (found in the View menu) can be quite helpful when filtering on all of the frames from a single station. This allows the engineer to quickly scroll through the list to find frames that are related to roaming or other interesting events. Here is a list of sample coloring rules that I have written for Wireshark to highlight various wireless events.

Wireshark Coloring Rules for Wi-Fi

Note that the order of rules is important because the first matched rule is applied and processing stops. Therefore, given the ordered rules below, a retransmitted frame would always be colored yellow regardless of what type of frame it is. Likewise, unencrypted data is colored orange, but since EAP frames are highlighted with higher precedence they are colored green instead. Unencrypted wireless data frames are useful to pick out in a trace file to identify Null Data frames that are commonly used by clients to enter and exit a Wi-Fi adapter power-save state for battery life improvement.

Using these coloring rules, I can simply scan the list visually for frames that are highlighted in green to find information related to roaming events. Here is an example where I can clearly pick out encrypted QoS data frames (not colored), client probing (blue), and client roaming (green):

Wireshark Colored Frame List

Manually Analyzing Roam Times
Once you have a display filter applied that limits the displayed list of frames to a single wireless client, the next step is to calculate the amount of time elapsed during each roaming event for the client. After reading part 2 in this series you should be able to quickly identify which roaming variation is occurring for each roaming event just by looking at the list of frames, and from part 3 in this series you should have picked a preferred method for analyzing roam times because you'll want to stick with it.

In order to manually analyze a roaming event, we need to set a time reference. This allows Wireshark to automatically calculate the time differential of subsequent frames relative to a reference frame. What you want to do is set the time reference as the first frame of the roaming event, then identify the last frame of the roaming event and look at the 'Time' column for that frame, whose value will be equal to the time elapsed since the reference frame. That's your total roam time! If you want to go further, you can even break down the time elapsed for each portion of the roam, such as probing, 802.11 auth, 802.11 association, EAP authentication, and EAPoL-Key (4-way handshake).

To set a time reference in Wireshark, highlight a frame, right-click to bring up the menu and select 'Set Time Reference (toggle)'.

Setting a Time Reference in Wireshark

In our example frame capture, three association frames were identified using the first filter method. However, there are actually only two association / roaming events since frame #49 is a retransmission of frame #48. So... event #1 occurs around the association in frame #49 and event #2 occurs around frame #808.

Event #1 - A Full EAP Authentication
The first event is the client's initial connection to the WLAN, during which it performs a full EAP authentication since no data frames were captured prior. Using each of the three previously described methods for roam time measurement, this event could be measured as follows:

1. Data frame to Data frame: not applicable since no previous data frames exist.
2. 802.11 Probe Request through EAPoL-Key: 1.951 sec
   Set the time reference as frame #1; final time measured on frame #79.
3. 802.11 Auth Request through EAPoL-Key: 131 ms
   Set the time reference as frame #46; final time measured on frame #79.

Wireshark Roam Time Analysis - Full EAP Authentication

Event #2 - A Client Roam using EAP Session Resumption
The second event is the client roaming between two APs on the same WLAN, during which it performs EAP session resumption with the RADIUS server. You can identify that it is using EAP Session Resumption because fewer packets are exchanged during the EAP authentication, and if you dig into frame #817 (as shown below) you will see a TLS session ID that is included in the 'Client Hello' message to re-use a previously established TLS session (contrast this with frame #57 which did not include a session ID). Also observe that the session ID established by the server in frame #58 matches the same session ID re-used by the client in frame #817.

TLS Session ID Re-Used for EAP Session Resumption

Using each of the three previously described methods for roam time measurement, this event could be measured as follows:

1. Data frame to Data frame: 1.549 sec
   Set the time reference as frame #784; final time measured on frame #830.
2. 802.11 Probe Request through EAPoL-Key: 1.153 sec
   Set the time reference as frame #788; final time measured on frame #827.
3. 802.11 Auth Request through EAPoL-Key: 776 ms
   Set the time reference as frame #804; final time measured on frame #827. Notice that the client actually sends three authentication requests before getting a response. We also see a few additional frame re-transmissions during the roam as well (colored yellow). There could be many reasons why these occurred, such as interference, frame corruption, or null fading which can be an issue with mobile devices like the iPhone because they only have a single antenna chain for receive functions and do not have a digital signal processor (DSP) to perform MRC. Performing a packet capture simultaneously near the AP in question and comparing the two could provide additional insight.
   
   If this anomaly hadn't occurred, the client roam time would have been substantially less at 146ms (frame #806 to #827).

Wireshark Roam Time Analysis - EAP Session Resumption

Notice how much longer in time these roaming events can appear to be simply based on our method of measurement. This is why establishing a consistent methodology is important to compare roaming times between different client devices and over time. Roaming time data usually results in subjective assessments of a device's performance as either 'good' or 'bad'. But make sure that you understand how the measurement was calculated if you were not the one to perform the protocol analysis.

Breaking down the roam time of event #2 into subsequent parts, we can get an idea of where performance issues may be occurring:

• Last Data Frame to Probing: this can indicate how long it takes the client to realize that it needs to roam and begin scanning for new APs. Poor performance here can indicate that the client's wireless stack does not identify a deteriorating connection quick enough to support the intended application. In this instance it took the client 157ms (frame #784 to #788).
  
  
• Probing Time: this can indicate how efficient the client is at scanning and discovering a new AP to join. If the client performs active scanning periodically, it may already have a list of potential APs, thus minimizing the time it takes to scan when it needs to actually roam. Poor performance here can indicate that the client is not able to quickly identify a new AP to join. This could be caused by not performing active scanning periodically while the connection to the current AP is strong. If the client does perform active scanning, then there may be a logic issue if it does not adequately use the previously gathered AP list and instead scans all channels again before roaming. Also, verify that APs are responding to probe requests adequately, since many band steering implementations rely on delayed or suppressed probe responses to influence client roaming behavior.
  
  In this instance it took the client 376ms (frame #788 to #804) and the client scanned all channels 1, 6, and 11 again before roaming, despite previously performing active scans at 10sec. intervals. It may have also scanned 5 GHz channels, but I did not have additional sniffers operating on 5 GHz. What you will also notice is that during previous active scanning, no probe requests were received from alternate APs other than the one it was currently connected to. This was a small network environment comprised of only 3 APs and the APs were configured to suppress probe responses if the client SNR was too weak (<15dB). This was a likely contributing factor to the probing time of the client. If I wanted to improve roaming performance, I might try disabling that feature on the APs. (That feature is actually disabled by default, I enabled it to highlight how AP configuration can impact client roaming).
  
  
• 802.11 Auth/Assoc: this can indicate if the client is able to successfully join a new AP. This process should be very short and efficient. If an AP is overloaded it may reject client associations, indicating a capacity issue on the WLAN. In this instance it took the client 633ms to join the new AP (frame #804 to #811). This is a LONG time, and provides cause for alarm and further investigation. As previously described, this appears to be an interference issue, but I cannot be certain. In a real-world environment, I would analyze this portion of multiple captured roaming events to determine if it was an anomaly or if it happens repeatedly.
  
  
• EAP Authentication: this can indicate how well the WLAN and backend infrastructure are designed to perform client authentication transactions quickly and efficiently. In this instance it took 137ms for the client to complete EAP authentication (frame #811 to #823), which is relatively fast since no fast roaming technique was used and the RADIUS server was on the local LAN.
  
  Many variables can come into play and affect latency in this portion of the roam, such as: 
• EAP method implemented, which determines the credentials used and number of round-trip packets to complete authentication.
• Number of EAP methods supported, since the RADIUS server proposed EAP methods in succession until the client accepts one.
• RADIUS server placement either on the local LAN or across a high-latency WAN link.
• Transaction processing load on the RADIUS server.
• Congestion on transit network devices, including switches or routers.
• Performance issues on the client device impacting the Wi-Fi supplicant.
• Ability to cache credentials on the client device for re-use. If credentials cannot be cached, then the user may be prompted to input or select a credential, which can take significantly longer than cached credentials.
  
  
• EAPoL-Key: this step should complete very fast in order to derive the final encryption key used between the AP and client to encrypt data traffic. If this step does not complete, it can indicate a bad pre-shared key (PSK) if the WLAN does not implement 802.1X. In this instance it took 5ms to complete key derivation between the client and AP (frame #824 to #827), which is normal.

Additional factors to look at:

• Power-Save: look for Null Data frames to indicate that the client is going in and out of power-save state. A client's power-save behavior can affect it's roaming performance. Clients will typically go into power-save state prior to performing active scanning because they need the AP to buffer data frames for them while they go off-channel. This is normal. However, if the client is going in and out of power-save state at other times during the roam (for example, during the EAP authentication) this may be a cause for alarm. In this instance, the client does go in and out of power-save state frequently since it is a mobile device, but it does not appear to impact roaming performance.

For this particular roam event, I would be most concerned with the probing time and 802.11 auth/assoc time. I would attempt to improve probing by verifying my AP configuration and disabling probe suppression of clients with weak SNR, and I would re-run multiple captures to ascertain whether or not the 802.11 auth/assoc process was an anomaly or occurs repeatedly.

Automated Roam Time Analysis
The Wireshark and AirPcap solution can be augmented with the purchase of Riverbed Cascade Pilot Personal Edition (formerly CACE Wi-Fi Pilot, which is the product that I have). This product complements Wireshark by providing data visualization, analysis, reporting, and drill-down capability on large packet captures. A good overview of the solution is provided here.

One useful function within the tool is automated roam time analysis. It will look through a packet capture file, identify client roaming events, and automatically measure the time elapsed for each roam. The measurement method used is between data frames on the old and new AP. Also, most automated tools like this one do not report a client's initial connection to the WLAN as a roam event and it will not show up in the analysis.

Adding the sample packet trace into Wi-Fi Pilot and opening the 'Roaming Time Analysis' view, we can confirm that the second event is identified as a roam and the time elapsed reported as 1.549 sec, the same as we manually calculated between data frames.

Wi-Fi Pilot - Roaming Time Analysis

The 'Avg/Min/Max Roaming Time Over Time' view is also interesting to plot client roaming latency over time:

Wi-Fi Pilot - Avg/Min/Max Roam Time

Wrap-Up
Wi-Fi roaming analysis used to be quite a tedious undertaking, requiring very specific hardware and software. However, in the last few years this has become much easier due to the availability of more common and affordable tools. Engineers can perform roaming analysis quite inexpensively using open-source software such as Backtrack Linux coupled with your choice of several common wireless network adapters. The trade-off of such a setup is the extra time and effort to merge capture files and perform the analysis manually. If you rarely need to perform roaming analysis, then this setup may suite your needs. If you are unfamiliar with Linux, or simply prefer a Windows setup, then you can purchase network adapters dedicated to wireless protocol analysis, such as AirPcap Nx, for a minor investment (currently $698 each, or $2,094 for a set of three). This can remove some of manual work merging capture files, but still requires manual roaming analysis.

If you have to perform roaming analysis quite often or could benefit from advanced data visualization and reporting features, it may be worth your time to invest in professional software that can automate the roaming analysis for you. Several Wi-Fi software packages provide automated roaming analysis. This can simplify and expedite the analysis, but depending on how the software calculates roam times, it may or may not match your preferred measurement method. In this article, I discussed Riverbed Cascade Pilot Personal Edition (currently $695) and will cover another software package, Wildpackets Omnipeek, that provides similar capabilities in my next post.

The examples shown in this article included a full EAP authentication and an EAP session resumption, neither of which are fast roaming techniques. Now that Apple has announced support for 802.11r (Fast BSS Transition) and enterprise WLAN gear will soon include support for it as well, I will be able to capture a fast secure roaming example and publish my findings.

Cheers,
Andrew


Other articles you might like:

• Using Wireshark Coloring Rules to Enhance Wi-Fi Protocol Analysis
• Wireshark WLAN Traffic Statistics and I/O Graphs

Wi-Fi Roaming Analysis Part 3 - Measuring Roam Times

This article picks up where we last left off in our discussion on Wi-Fi roaming. In part 1, I covered how connection control occurs in Wi-Fi, the importance of roaming, and what conditions are involved in triggering a client roam. Then in part 2, I dived into the many variations of Wi-Fi roaming and how they each work. Now that we know the background on how Wi-Fi roaming occurs in multiple different scenarios, it's almost time to dig in and get our hands dirty by actually capturing packets and measuring client roaming performance.

But before we an do so, we have one more topic to cover, namely - how to actually measure the roam. This may seem trivial, and really it isn't that difficult of a subject. However, it is important to establish the methodology we will use to provide consistent, repeatable, and comparable results. This will enable us to accurately compare roaming performance between different types of clients as well as across firmware, driver, and configuration updates on the same client or WLAN infrastructure.

Wi-Fi Roaming Analysis Series:

1. Part 1 - Connection Control and Importance of Roaming Analysis
2. Part 2 - The Many Variations of Wi-Fi Roaming
3. Part 3 - Methods of Measuring Roam Times
4. Part 4 - Analysis with Wireshark and AirPcap
5. Part 5 - Analysis with Wildpackets Omnipeek (coming)
6. Part 6 - Tips for Roaming Performance Improvement (coming)

Measuring Roam Times
There are several different methods by which we can actually measure the roaming event. Variations exist because organizations, wireless professionals, and software tools have different views on what constitutes a completed roam (from beginning to end). Different methods of measurement may be applicable in different scenarios, but what is important is to maintain consistency in approach in order to establish a baseline in performance and be able to accurately compare results to one another.

The following are common methods used to calculate the duration required for a client to roam from one AP to another AP:

1. Between 802.11 Encrypted Data Packets to/from the client on the old and new AP
   This method focuses on the analyzing the impact of roaming delay to the application(s) running on the client device. By analyzing the amount of time between the last data frame transmitted on the "old" AP and the first data frame transmitted on the "new" AP, we can get an idea as to the latency that is experienced by applications. This can be useful to understand how roaming latency might impact software development and internal application timers that may result in timeout errors or otherwise disrupt network applications.
   
   However, one drawback to this method is that it reflects not only the actual wireless roaming latency, but also any idle time between frame transmissions if the application does not have data buffered for transmission. This can inflate perceived roam times based on application behavior. For example, many applications are bursty in nature, and measuring roam times between data frames could result in a large amount of time being included that is simply client idle time since no frames have been sent by the application for transmission. Even in the "best-case" scenario of where application behavior is consistent, such as a VoIP G.711 call that sends frames every 20ms, this can still cause imprecise measurement. Historically, this has not been a problem when a large percentage of clients did not support fast roaming methods and roaming times were comparatively large. An inaccuracy of 20ms or less would not be a substantial factor in a 500ms - 1sec roam time. But as newer clients support 802.11r and Fast BSS Transition, roam times are likely to be 50-100ms. A measurement error of 20ms could represent 20-40% of the calculated roam time.
   
   
2. Between 802.11 Probe Request through EAPoL-Key (or Association Response)
   This method focuses solely on the wireless roaming latency, removing application behavior from the calculation. The calculation begins with client probing to discover candidate APs to which it can roam, and typically completes with the final EAPoL-Key frame (but may vary based on which type of roam was completed; for instance with 802.11r Fast BSS Transition the final frame required for a successful roam is the Association Response. See Part 2 of this series).
   
   However, the drawback with this method is that the calculation may be inflated by including the time required for client probing. Since client probing does not always reflect an actual roam event (many clients probe periodically to maintain a list of APs to minimize discovery time when they actually need to roam) and probing behavior varies between manufacturers and even driver versions, this can result in the inability to accurately compare roaming performance between clients or software upgrades.
   
   
3. Between 802.11 Authentication Request through EAPoL-Key (or Association Response)
   This method is nearly identical to the previous method, but it omits client probing from the actual roam time calculation. Many times, when this method is used, the client probing is still listed for informational purposes in order to better understand the client behavior. Therefore, the roam time calculation is limited to the time it took the client to move to the new AP once it decided that a roam was required. Measurement is typically performed from the client 802.11 Authentication Request through the final EAPoL-Key frame (or Association Response, depending on the type of roam. See Part 2 of this series).
   
   It should also be noted that 802.11 Authentication does not always indicate a roaming event; Wi-Fi clients are allowed to perform 802.11 authentication with multiple APs at once, but can only be "associated" to a single AP at a time. Therefore, look for 802.11 Association Request frames to positively identify a roaming event, then look backwards from that point to identify when the client both probed to discover the AP and performed 802.11 authentication to the AP (different than 802.1X/EAP authentication).

None of these methods are better than the others, simply different ways of measuring the time required for a roam to complete.

It may be helpful for you to reference a simple Wi-Fi connection ladder diagram. At what point do we start measuring roam, and and what point has the roam completed? Which method of measurement is most useful for my analysis?

Measuring Wi-Fi Roam Times

Also, consider which EAP type you have implemented in your network. Different EAP methods require different application flows to complete authentication and can impact the roaming performance for clients that do not support fast roaming. For reference, here is a PEAP authentication packet flow for a client performing a full 802.1X/EAP authentication on a Wi-Fi network.

Personally, I typically measure Wi-Fi roaming times between the 802.11 Authentication Request and the final EAPoL-Key frame (or Association Response). However, this is simply my preference because I often like to compare roaming times between different clients that may be running different applications. By eliminating the Data frames from my calculation, it is easier to directly compare the Wi-Fi driver stacks and radio performance of the clients.

In the next article on this topic, we'll dig into actual packet captures. Stay with me you packet analysis junkies!

Cheers,
Andrew

Wi-Fi Fast Roaming is Here! (Finally)

It's been a long time coming, but industry support for standards-based fast roaming is finally starting to emerge! See my previous posts:

http://revolutionwifi.blogspot.com/2010/06/its-time-for-80211r.html

http://revolutionwifi.blogspot.com/2012/02/wi-fi-roaming-analysis-part-2-roaming.html

Apple iOS now officially supports IEEE 802.11r and 802.11k, which form the underpinnings of the Wi-Fi Alliance Voice Enterprise certification for fast roaming. (Don't be confused by the word voice in the certification. This is applicable to any WiFi client that needs fast roaming capability at the driver level for any application.)

This will help Apple mobile devices perform better in enterprise environments, especially when multimedia and collaboration tools are used with BYOD.

From Apple's website:
http://support.apple.com/kb/HT5535

"iOS 6 introduces support for optimized client roaming on enterprise Wi-Fi networks. The 802.11 Working Group standards k and r were conceived to give wireless clients the ability to more seamlessly roam from access point (AP) to access point within the same network.

802.11k
802.11k allows an iOS 6 device to quickly identify nearby APs that are available for roaming. When the signal strength of the current AP weakens and the iOS device needs to roam to a new AP, it will already know the best candidate AP with which to connect.

802.11r
When an iOS 6 device roams from one AP to another on the same network, 802.11r streamlines the authentication process using a feature called Fast Basic Service Set Transition (FT). FT allows iOS 6 devices to associate with APs more quickly. Depending on your Wi-Fi hardware vendor, FT can work with both preshared key (PSK) and 802.1X authentication methods.

Coupled with 802.11k's ability to quickly identify the target AP, FT's faster association method may enhance application performance and aims to provide a better Wi-Fi experience in iOS.

Additional Information
Not every Wi-Fi network hardware vendor currently supports 802.11k and 802.11r. Check with the manufacturer of your Wi-Fi hardware (controllers and APs) to determine if support is available. Once support for both standards is verified, 802.11k and FT functionality must be enabled. Setup methods vary; please consult the current configuration documentation for your Wi-Fi hardware for details."

Cheers,
Andrew

Wi-Fi Roaming Analysis Part 2 - Roaming Variations

In Part 1 of this series, I provided a high-level overview of Wi-Fi connection control, the importance of roaming, and what conditions are involved in triggering a client roam.

Now that we have the basics out of the way, let's discuss the large number of roaming variations that exist and the implications of that on performance analysis. Once the client determines to move its network connection to a new AP, the actual roam occurs. This is where things get complicated, because various combinations of authentication and encryption suites require different frame exchanges to complete a roam.

Wi-Fi Roaming Analysis Series:

1. Part 1 - Connection Control and Importance of Roaming Analysis
2. Part 2 - The Many Variations of Wi-Fi Roaming
3. Part 3 - Methods of Measuring Roam Times
4. Part 4 - Analysis with Wireshark and AirPcap
5. Part 5 - Analysis with Wildpackets Omnipeek (coming)
6. Part 6 - Tips for Roaming Performance Improvement (coming)

Security Brings Complexity

When Wi-Fi was young, client traffic flowed fast and easy. Clients roamed from one AP to another with nary a care in the world, albeit some inefficient client roaming algorithms did exist. But over time WEP was found increasingly vulnerable to attack and eventually full defeat. The IEEE responded, defining a very "robust" security network, indeed! But with this increased security came new restrictions. Clients had to present their identity to access the network, and the APs had to call their boss for approval (authentication server). And this took time! At first, clients didn't mind. But over time clients grew increasingly impatient, wanting to get where they were going without having to stop. "Why doesn't the AP know who I am? I come through here every day!" they would say. And they were right.

I explain Wi-Fi roaming like interstate traffic. Originally there were simple on-ramps (Open/WEP networks). As the roads required maintenance and repair, toll-booths were erected to collect a fee before use (802.1X). These first-generation tolls were "cash-only" and required every car to stop and pay, which backed up traffic. Eventually, due to increasing demands and volume, these toll-booths were replaced with electronic toll collection, which allows cars to slow down and pay without stopping (fast roaming).

As the 802.11 protocol has grown more mature, it has also grown much more complex. Introduction of more secure networks solved one problem but created another. The need for and lack of standardized fast roaming has led to proprietary vendor enhancements to fill the gap. And lack of coordination among vendors has led to multiple competing methods with fragmented support throughout the industry.

The Many Variations of Wi-Fi Roaming

* Update 2012-02-03: Original table listed 802.1X/EAP as part of CCKM, which is incorrect. The table was updated to reflect this change. *

Note - The initial GTK installation is defined as part of the 4-Way Handshake with 802.11i / WPA2. It has also been observed in the 4-Way Handshake with WPA pre-standard networks, despite not being specified as such by the Wi-Fi Alliance. The GTK exchange is mainly used to update existing group keys and is listed mainly for reference purposes.

Simple Authentication & Roaming Methods
I call the following "simple" methods because they involve simple security protocols relative to the more robust methods involving 802.1X. These methods typically allow clients to complete a roam in <50ms and are very fast. However, the trade-off is lower security which becomes readily apparent when the network must scale beyond some small amount of users, at which point encryption key or pre-shared keys become unmanageable to provision, rotate, and maintain proper access control over.

• Open Network
  The client performs 802.11 open authentication (2-packet exchange) and 802.11 association (2-packet exchange), at which point data traffic is permitted. Simple, quick, and efficient! Open networks are typically found in hotspot and guest deployment scenarios and may have web authentication via a captive web portal  layered on top, in which case the wireless network or other in-line network appliance will only allow DHCP and DNS prior to web login. However, from a layer 2 Wi-Fi perspective, data traffic is unencrypted and presents significant security risks.
  
• Static WEP
  When static WEP keys are used for network access control and encryption, clients perform the same steps as an open network roam, going through 802.11 open auth and 802.11 association, then encrypt data frames using the WEP algorithm. No additional authentication exchange occurs with static WEP unless shared key authentication is configured (discussed next). The use of WEP encryption is inferred by the presence of the "Data Protection" bit set in 802.11 header as well as the abscence of a WPA or RSN information element. The use of a correct WEP key is inferred from the ability to decrypt frames at the receiver and verify the ICV (integrity check value). WEP is a legacy security protocol which can be cracked very easily and offers virtually no protection. Do NOT use WEP!
  
• Static WEP with Shared Key Authentication
  When an optional shared key authentication method is configured with static WEP, the access point and client exchange an additional challenge handshake and response to confirm that the client holds the correct WEP key prior to allowing it to associate to the AP. The desire to use shared key authentication is signalled within the 802.11 authentication request and response packets in the authentication algorithm fixed parameter field. The use of shared key authentication actually reduces the security of static WEP because versions of the same challenge text are transmitted over the air in both plaintext and hashed, allowing an attacker to recover the WEP key easier. Do NOT use WEP!
  
• WPA/WPA2 Pre-Shared Key
  When WPA or WPA2 is configured with pre-shared keys, the client and AP must be configured out-of-band with the proper passphrase, which is used as the master key. The client and AP exchange the 802.11 open auth and association frames before performing a 4-Way Handshake. The handshake facilitates the exchange of  random information (nonces). The passphrase, station addresses, nonces, and SSID are all used to transform the master key into a series of sub-keys, one of which is the PTK used for actual data encryption. A WPA2 PSK network is simpler in that the users only require knowledge of the passphrase, but suffers from issues of scalability and is difficult to revoke access when all users use the same passphrase. Traffic from each user is uniquely encrypted, but knowledge of the passphrase along with observation of the 4-Way Handshake can allow any user to decrypt another user's traffic. WPA2 PSK is best used in homes and SMBs where there is a small user base, which is why it is commonly referred to as WPA2-Personal. It is also commonly used with VoWiFi deployment to prevent voice call disruption due to the excessive roaming latency involved with full authentication methods listed below. 

Full Authentication & Roaming Methods
The following methods are what I classify as "full auth", meaning they perform a full 802.1X authentication process using a back-end AAA RADIUS server. When implemented without any optimization for fast roaming, these methods are used for both initial connection establishment as well as subsequent roaming between APs. These methods provide robust network security that is enterprise-ready, but the trade-off is much longer authentication time and roaming latency. It is typical for full authentication roams to take >600ms to complete, and can be longer depending on network architecture (e.g. authentication server is across a WAN circuit).

• Dynamic WEP
  The use of dynamic WEP is provided as a vendor proprietary feature by many manufacturers, and allows the use of 802.1X / EAP authentication with the WEP protocol. After successful 802.11 association, EAP authentiction proceeds using any supported EAP type (with Cisco LEAP being the most common). Unicast and broadcast WEP keys are assigned to the client by the AP using two EAPoL-Key frames after successful EAP authentication, which allows the network to remove reliance on statically configured WEP keys and the ability to dynamically assign unique unicast keys to each client. However, dynamic WEP still relies on the same flawed WEP protocol and does not remediate its inherent issues. There is no method to signal the use of dynamic WEP within the 802.11 frame, and relies on both the client and AP to be properly configured to support this process. (The use of LEAP authentication does use a proprietary Cisco information element, but is not required for dynamic WEP). Dynamic WEP was introduced into the market in Dec. 2000 with the release of LEAP authentication by Cisco. Dynamic WEP should NOT be used!
  
• WPA/WPA2 Full Authentication
  When WPA or WPA2 is configured with AAA authentication, user or device credentials are verified using a back-end authentication server. The client and AP exchange the 802.11 auth and association frames, then proceed with EAP authentication. Many different EAP authentication protocols exist and any one of them can be used depending on the customer requirements. EAP protocols require a lengthy communication exchange between the client and authentication server, typically 8 or or more round-trip frame exchanges, which creates significant delay in the roaming process. Since a client can only be associated to a single AP at a time, it must break its previously working data path prior to establishing a new data path. And EAP authentication sits as a large barrier in that path that must be overcome before application data can begin to flow again. Upon successful EAP authentication the AAA server and client derive a master key, similar to what was configured out-of-band in a PSK network, except that the master key is unique to this client session. The AAA server also sends a copy of the master key to the AP (or controller) acting as the authenticator. The AP and client then perform the familiar 4-Way Handshake to transform the master key into a temporal key used for actual data encryption. WPA2 full authentication is the basis for most enterprise Wi-Fi deployments because of the strong security offered. However, it creates significant latency that can disrupt real-time applications such as voice and video.  The WPA certification program was introduced in 2003 by the Wi-Fi Alliance prior to final IEEE 802.11i amendment ratification in 2004. The WPA2 certification program was subsequently released in 2004 and expanded in 2005.

Fast Roaming Techniques
The following fast roaming techniques improve upon the full authentication methods by optimizing various steps in the authentication process. A full authentication method is required to establish the initial client connection, after which a fast roaming technique can subsequently be used when roaming between APs to minimize delay. Fast roaming techniques vary in their ability to minimize delay, with the goal to complete a roam in <100ms. Voice traffic typically sends frames every 20ms and requires roaming latency under 100ms to prevent call disruption.

• Cisco Centralized Key Management (CCKM) (also called Fast Secure Roaming)
  CCKM is a vendor-proprietary fast roaming algorithm developed by Cisco Systems, and is only supported on their access points, both autonomous and lightweight models. CCKM works by caching the encryption key derived after an initial authentication (DWEP EAPoL key exchange or WPA/WPA2 4-Way Handshake) on both the WDS Master and the wireless client. A WDS master role is assigned to a central point of coordination for all the APs in a group, and can be an Autonomous AP, WLSE, or newer wireless LAN controller. When roaming to a new AP, the client increments a re-key number and derives a new PTK key using the BSSID of the new AP it wishes to roam to. The client indicates CCKM support by including a Cisco proprietary information element that includes the next re-key number within the association request frame. The new AP requests the new PTK key from the WDS master and then replies to the client with the association response frame. CCKM reduces the time to complete a roam by removing the EAP authentication and 4-Way Handshake. Roam times can be <50ms in most cases.
  
  CCKM was originally designed for use with LEAP authentication and WEP encryption, but can be used with other EAP authentication methods and encryption ciphers (TKIP or AES) as well. The use of CCKM is advertised by the presence of a vendor-specific AKMP (authentication and key management protocol) within the WPA and RSN information elements used in beacon and probe response frames. It is also indicated by a Cisco vendor-specific information element in 802.11 association request & response frames. Clients must support CCX version 2 at minimum to leverage CCKM with LEAP, version 3 for EAP-FAST, and version 4 for PEAP and EAP-TLS. CCKM was introduced into the market in 2004 with Cisco Autonomous software release 12.2(11)JA.
  
• WPA/WPA2 EAP Session Resumption (also called Fast Reconnect)
  Many EAP types used with 802.1X authentication rely on TLS security. TLS relies on a lengthy handshake negotiation to setup a secure communication path between the client and authentication server. This handshake requires a server-side certificate which usually results in authentication of the authentication server to the client. After the TLS handshake completes, the client must then authenticate itself to the server. EAP-TLS accomplishes this with a client-side certificate. Tunneled EAP types such as PEAP and EAP-TTLS use other less secure protocols such as MSCHAPv2 or EAP-GTC inside the tunnel to complete authentication without being directly exposed to an attack. Upon successful EAP authentication, the AP and client perform the familiar 4-Way Handshake to derive the PTK for data encryption.
  
  Once a client has initially authenticated, the TLS session and resulting security context can be cached on both client and server. Upon subsequent re-authentication, the use of the cached TLS session allows use of simpler and shorter handshake process. Additionally, the existence of a valid cached TLS session implies a previously successful authentication, and many EAP types allow the inner client authentication to be skipped. Overall, this typically results in a 50% reduction in frame exchange to the backend authentication server during EAP authentication. The use of session resumption is transparent to the WLAN infrastructure and appears as a normal full 802.1X authentication. However, roam times typically require <300ms to complete, but may be longer depending on network architecture (e.g. authentication server is across a WAN circuit). Although a significant improvement over full 802.1X authentication, EAP session resumption is still not fast enough to support real-time applications such as voice over IP. However, it is well supported in the industry and is common on wireless networks.
  
• WPA2 PMK Caching (also called Static PMK Caching or Fast/Secure Roam-Back)
  The client re-uses a previously cached PMK Security Association (PMKSA) from a prior full 802.1X authentication with an individual access point. The PMKSA cache can also be built by pre-authenticating through the existing AP association to the new AP. Once the client roams it will send the PMK Identifier (PMKID) of the cached PMKSA to the access point in the RSN Information Element within the Re-Association Request frame. If the AP has the same PMKID cached it will skip the 802.1X authentication and proceed directly to the 4-Way Handshake. The end-result of a PMK cache roam is functionally equivalent to an OKC and Fast BSS Transition roam, clients just cannot re-use a single cache entry across multiple APs. PMK cache roaming typically requires <100ms to complete.
  
  PMK caching is quite well supported by infrastructure and client devices alike. Unfortunately, its usefulness is limited by the fact that a client must have a cached PMKSA with each access point and this caching is not shared between APs within the same controller or AP group. Also, many clients and APs limit the amount of cached PMK entries due to memory utilization concerns. This means that it reduces how often it can be used, requiring full authentication to each AP the first time it associates. There is also a maximum lifetime for cached PMKSAs, after which time a full authentication is required again. PMK caching is therefore highly dependent on the traffic patterns of your clients. If they roam between the same set of APs most of the time, PMK caching could be a great benefit. If clients often roam to new APs throughout the network then PMK caching is less useful.  Reference section 8.4.1.2.1 of the IEEE 802.11-2007 standard. PMKSA caching was introduced in 2004 with the ratification of the IEEE 802.11i amendment.
  
• WPA2 Proactive Key Caching (PKC) (also called Opportunistic Key Caching)
  PKC builds on top of the standardized PMK caching, but extends the re-use of a single cached PMKSA across all wireless access points connected to the same WLC or AP group. PKC is not a defined standard by the IEEE, and vendor implementations may vary.
  
  PKC works by caching the PMKSA from an initial client full authentication at a central point of coordination for multiple access points, typically a WLC. When the client roams to a new AP within the same Extended Service Set (ESS), it "proactively" calculates a new PMKID for use with the new AP based on the BSSID of the new AP. The client then sends the newly calculated PMKID to the new AP in the RSN information element of the re-association request. Depending on vendor implementation, the AP will already have a cached PMKSA or PMKID pushed to it by the WLC, or it will query the WLC for the PMKID upon receiving the re-association request. If the AP derives the same PMKID as the client, it will skip EAP authentication and proceed directly to the 4-Way Handshake to derive a new PTK for data encryption.
  
  Essentially, the client can re-use the cached PMKSA, but calculates a new PMKID for use with every AP without needing to perform a full 802.1X authentication. PKC roaming performs similar to both static PMK caching and PSK roaming, requiring <100ms to complete. However, support for PKC is highly variable within the industry, and despite favorable initial adoption by client manufacturers, support has been declining. PKC was introduced by Airespace, Funk Software, and Atheros in 2004, shortly after the ratification of the IEEE 802.11i amendment for robust security networks.
  
• WPA2 Fast BSS Transition (FT)
  Given the limitations of static PMK caching, and limited support for proprietary OKC and CCKM fast roaming techniques, the IEEE standardized fast roaming across an ESS with the 802.11r amendment, which was ratified in 2008. An AP advertises support for FT in a new Mobility Domain Information Element (MDIE) in beacons, probe responses, and (re)association responses. The client must also indicate support in an MDIE included in authentication and (re)association requests.
  
  Fast Transition works by having the authenticator (typically a WLC) complete an initial successful 802.1X client authentication and derive a PMK-R0 for the client. The PMK-R0 is used to derive a unique PMK-R1 for each AP within the mobility domain. The authenticator then distributes the keys to other APs using a secure channel (which is not defined by the IEEE 11r amendment). During the initial authentication, the client performs full 802.1X authentication, completes the 4-Way Handshake to derive a PTKSA with the AP (using PMK-R1 key material), and then is allowed access to the network. However, upon roaming the 802.1X authentication and 4-Way Handshake steps may be skipped if a valid PMK-R1 for the new AP is presented by the client in the (re)authentication and (re)association request frames. Therefore, Fast Transition allows roaming faster than static PMK caching and OKC, and on-par with CCKM roaming, typically <50ms.
  
  This is an extremely over-simplified explanation, but will suffice to understand how Fast Transition works. It is also important to note that 11r also allows FT over the distribution system, through the current AP to the new AP, similar to 802.11i pre-authentication. However, I will not cover that topic in this article.

* Notice that many of these fast roaming techniques are restricted to WPA2 only.

Layer 2 versus Layer 3 Roaming
Layer 2 roaming occurs when a client roams from one AP to another AP which both attach to the same client subnet or VLAN.

Layer 3 roaming occurs when a client roams from one AP to another AP which does not attach to the same client subnet or VLAN. If a client is required to acquire a new IP address, existing application connections break which has an adverse affect on network usability. Existing client sessions will either hang or eventually timeout and disconnect.

Wireless controller architectures help eliminate the need for layer 3 roaming by tunneling client data traffic from APs back to the controller as the logical client network attachment point. This way, APs can be spread across a larger physical or logical network environment without impacting clients. However, this also can only scale so large until APs attach to different controllers with different client attachment points, or unique requirements may dictate traffic forwarding to an altogether different network segment (e.g. guest termination in a secured DMZ).

All enterprise Wi-Fi vendors implement layer 3 roaming transparency to clients in order to eliminate the need for a client to acquire a new IP address. This is typically accomplished through coordination between APs or controllers within a logical group to tunnel existing client traffic back to a point within the network that can serve the original client subnet or VLAN. Examples include Cisco's concept of a wireless controller "Mobility Group", Aerohive's concept of a "Hive", etc.

Revolution or Evolution? - Andrew's Take
Roaming is easily one of the most convoluted processes within the Wi-Fi industry. The complexity involved between security requirements, standard and proprietary roaming methods, combined with fragmented infrastructure and client manufacturer support is staggering. Network administrators cannot predict how roaming will perform without observing live clients and analyzing the results. As networks grow and administrators increasingly lose control of devices attaching to the network, it becomes an almost impossible task to ensure adequate performance for every client.

Support for standardized fast roaming is long overdue! As I have written before, it's time for both infrastructure and client vendors to adopt 802.11r Fast BSS Transition. Real-time traffic flows require better performance than can currently be achieved. Support for proprietary fast roaming techniques such as CCKM are available, but are tough to come by for customers and even harder to push adoption by vendors. It's time to stop the marketing spin around WLAN controllers and fast roaming, as Marcus can attest. We have a solution, now we need adoption!

I'm from Nebraska, and as Larry the Cable Guy would say: "Git-R-Done!"

Cheers,
Andrew



Further Reading
For further reading on fast roaming techniques related to CCKM, PMK caching, OKC/PKC, and 802.11r, see the Cisco Aironet Configuration Guide, Cisco Voice over Wireless 4.1 Design Guide, CWNP  RSN Fast BSS Transition (free registration required), and the IEEE 802.11r amendment.

For an example packet flow analysis, review my post on PEAP authentication which details the frame by frame exchange for two types of roams that are most common, a full EAP authentication and EAP session resumption.

Other Posts You Might Be Interested In:

• Wi-Fi Roaming Analysis (Part 1 - Connection Control)
• It's Time for 802.11r (standards-based fast roaming)
• Adopting Wireless Client Testing & Verification Procedures
• Using Wireshark Coloring Rules to Enhance Wi-Fi Protocol Analysis
• Wireshark WLAN Traffic Statistics & IO Graphs
• Windows 7 Supplicant Round-Up
• Limit SSIDs & Data Rates to Maintain Network Performance
• PEAPv0 Packet Flow Reference
• 802.11 Medium Contention and my Wireless QoS 5-Part Series
• Understanding Wi-Fi Carrier Sense