Cisco's Adaptive 11r

There is an excellent post on the Cisco Support forums about options for implementing 802.11r Fast Transition. In summary, there are three ways to 802.11r for a WLAN on Cisco wireless:

• "Pure" mode, where the only Authentication Key Management (AKM) method listed in the Robust Security Network (RSN) Information Element is a FT method. Common FT methods are 802.1X FT or PSK FT. Clients that don't support 802.11r will not be able to connect to this type of WLAN. They may not even see it. 
• "Mixed" mode, where both FT and non-FT AKM methods are included in the AKM suite. This mode allows both clients that do and don't support FT to connect. There will still be clients that get confused by the presence of a FT AKM. Notably, if you change an existing WLAN to mixed mode FT, macOS clients may not be able to connect until you delete the WLAN profile and re-connect. 
• Adaptive 11r. In this mode, the beacon does not advertise the FT AKM at all, but will use FT when supported clients connect. 

Let's look at beacons for different types of FT networks. First, here are the relevant IEs for a non-FT network. 

RSN IE For non-FT WLAN

Beacons and probe responses for a non-FT network will contain non-FT AKM methods in the RSN IE, like PSK shown above. There will also not be a Mobility Domain IE. Now let's look at a mixed mode network.

RSN and Mobility Domain IEs

The RSN IE contains two AKM entries; regular PSK and FT using PSK. In addition to the FT AKM, beacons and probe responses will contain the Mobility Domain IE. Next, things get a little strange with Adaptive 11r.

Adaptive 11r RSN and MD IEs

With Adaptive 11r enabled on a WLAN, the RSN IE does not have any FT methods, but the Mobility Domain IE is present. Beacons will also contain the below IE, even if Aironet IE is disabled on the WLAN. 

Adaptive 11r Aironet IE

This looks similar to the Aironet IE that appears when Fast Lane is enabled. This IE is telling iOS clients that Adaptive 11r is available to use. Similarly, a compatible iOS device will tell the Cisco WLAN that it is, well, an iOS device, by adding a vendor IE into it's association request.

Apple Vendor IE

To summarize what we know so far, beacons and probe responses from an Adaptive 11r WLAN will contain a RSN IE with only non-FT elements, but will also include a Mobility Domain IE. This is paradoxically saying that the WLAN does not support FT and supports FT at the same time. So what happens when clients try to connect? First, let's see an association request from a client that doesn't support Adaptive 11r (a Motorola Android phone).

Association Request From Android Phone

This frame looks normal, and is what you would expect when a client is connecting to a non-FT WLAN. There is no Mobility Domain IE, which implies that the client saw that there was no FT AKM method in the RSN IE. The client determined that the network did not support FT, and did not include the Mobility Domain IE. The expanded RSN IE shows that the client will use PSK as the Authentication Key Management. What happens when a client that supports Adaptive 11r connects? 

Association Request from an iPad

The RSN IE shows that the AKM chosen was FT using PSK, which is not advertised in the beacons! This is the secret sauce of Adaptive 11r. You can also see the magic happen if you run "debug client" and "debug ft events enable" while an Adaptive 11r clients connects. Below is the output of debug commands while my iPad connected. Interesting lines are highlighted in red.

f4:5c:89:xx:xx:xx Recevied management frame ASSOCIATION REQUEST  on BSSID xx:xx:xx:df:a0:30 destination addr xx:xx:xx:df:a0:3f
f4:5c:89:xx:xx:xx Updating 11r vendor IE 

f4:5c:89:xx:xx:xx Marking this mobile as TGr capable.
RSNIE in Assoc. Req.: (20)

     [0000] 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f

     [0016] ac 04 0c 00

f4:5c:89:xx:xx:xx Processing RSN IE type 48, length 20 for mobile f4:5c:89:xx:xx:xx
f4:5c:89:xx:xx:xx Selected Unicast cipher CCMP128 for client device
f4:5c:89:xx:xx:xx RSN Capabilities:  12
f4:5c:89:xx:xx:xx Marking Mobile as non-11w Capable 
f4:5c:89:xx:xx:xx Validating FT AKM's on WLAN
f4:5c:89:xx:xx:xx Setting adaptive AKM 4 into RSN Data at 19

f4:5c:89:xx:xx:xx Sending assoc-resp with status 0 station:f4:5c:89:xx:xx:xx AP:xx:xx:xx:df:a0:30-01 on apVapId 1
f4:5c:89:xx:xx:xx VHT Operation IE: width 20/0 ch 165 freq0 0 freq1 0 msc0 0x3f msc1 0x3f
f4:5c:89:xx:xx:xx Including FT Mobility Domain IE (length 5) in Initial assoc Resp to mobile 
f4:5c:89:xx:xx:xx Sending R1KH-ID as 58:8d:09:cd:75:40
f4:5c:89:xx:xx:xx Sending R0KH-ID as:10.-114.-68.66
f4:5c:89:xx:xx:xx Including FT IE (length 98) in Initial Assoc Resp to mobile 

The most interesting part of the output is "Setting adaptive AKM 4 into RSN Data at 19". AKM 4 is short for FT using PSK, and "Data at 19" specifies position in the RSN IE that defines the AKM method. If you issue a "show client detail" command for an Adaptive 11r client, you will see that AKM method listed is an FT one.

(Cisco Controller) >show client detail f4:5c:89:xx:xx:xx
Client MAC Address............................... f4:5c:89:xx:xx:xx
Client Username ................................. N/A
AP MAC Address................................... xx:xx:xx:df:a0:30
AP Name.......................................... wap004-011-ap01   
AP radio slot Id................................. 1  
Client State..................................... Associated     
Client User Group................................ 
Client NAC OOB State............................. Access
Wireless LAN Id.................................. 14 
Wireless LAN Network Name (SSID)................. Fastlane
Wireless LAN Profile Name........................ Fastlane

Policy Type...................................... WPA2
Authentication Key Management.................... FT-PSK
Encryption Cipher................................ CCMP-128 (AES)

Roaming with an Adaptive 11r compatible client is the same as roaming with regular old FT. When the client sends authentication and reassociation requests to a new AP, it includes Mobility Domain and Fast BSS Transition IEs. Roam time with the iPad I tested with was less than 10 ms. (That's how long it took to go from Authentication to the first data packet sent by the iPad. Getting the iPad to roam in the first place was a challenge, given the environment I was testing with).

I like this feature from Cisco and Apple. There appears to be no risk in breaking connectivity for non-iOS devices if you enable it, and the upside for supported devices is really good. Hopefully this blog gave readers some insight into how this feature works.