Wireless Access

Hello Airheads,

I'm working on suggesting some wireless optimizations and need some community support surrounding the use of PMKID caching, Opportunistic Key Caching, 802.11r, and 802.11k.

My question is 3 part:

• What is the impact of enabling, disabling, or combining these features together? More specifically, what is the impact when one or more of these features are turned on but not supported by the client?
• How does one make the judgement of whether to use or not use one or more of these features?
• Do I need the "Validate PMKID" feature in order for clients to perform roaming using PMKID caching?

As an example, this particular environment is roughly 60% Windows 7, 25% IOS, <1% OSX, and the remaining ~14% other. Which features should be used for this environment and why or why not?

From discussions I've had with some Aruba engineers, it sounds like Apple's implementation of OKC is spotty at best across the board on all platforms. However, documents such as this one suggest that PMKID caching, 802.11r, and 802.11k are all supported.

From the 6.3 CLI guide

Validate PMKID: This parameter instructs the controller to check the pairwise master key (PMK) ID sent by the client. When this option is enabled, the client must send a PMKID in the associate or reassociate frame to indicate that it supports OKC or PMK caching; otherwise, full 802.1x authentication takes place. NOTE: This feature is optional, since most clients that support OKC and PMK caching do not send the PMKID in their association request.

Any help is appreciated!

I found this technical brief from 2007: http://community.arubanetworks.com/aruba/attachments/aruba/115/1097/1/Aruba+OKC+Implementation.pdf

Assuming the information is still relavent, here's what I learned:

• PMK caching is always on for WPA2 ESSIDs and cannot be disabled
• PMK caching requies the client to send the PMKID
• OKC w/o Validate PMKID does not check to see if a PMKID has been sent and tries to always perform OKC
• OKC w/ Validate PMKID means that the client must send the PMKID for OKC to occur, but some (most?) clients do not do this
• If a client does not support OKC, it may reject an OKC attempt by sending an EAPOL Start frame
• If a client does not support OKC and does not reject the OKC attempt by sending an EAPOL start frame, the client may hang and need to be restarted. To make sure this does not happen, you can turn on Validate PMKID, but this may result in fewer successful OKC and more full 802.1X transactions

Combining this knowledge with what I know from the Apple article I originally posted, my best guess for options to turn on would be to enable OKC with the Validate PMKID option. To me this sounds like there will be some improvement without causing problems for unsupported devices. <--Looking for feedback on this conclusion

Other things I learned:

• OKC and PMK caching are WPA2 specific. You should not turn on OKC for WPA ESSIDs. https://arubanetworkskb.secure.force.com/pkb/articles/HowTo/R-1564
• OKC and PMK caching do not apply to PSK ESSIDs. https://arubanetworkskb.secure.force.com/pkb/articles/HowTo/R-377
• OKC is not an industry standard, unlike 802.11r. https://arubanetworkskb.secure.force.com/pkb/articles/FAQ/What-is-Fast-BSS-Transition-IEEE-802-11r-standard-and-what-is-the-supported-key-hierarchy

One more roaming document I found: https://arubanetworkskb.secure.force.com/pkb/articles/HowTo/How-to-improve-client-handover-and-roaming-between-AP-s

Despite all of this information, I still don't have a clear-cut answer for some of my original questions.

What is the impact of enabling, disabling, or combining these features together? More specifically, what is the impact when one or more of these features are turned on but not supported by the client? Answered for OKC/PMK Caching, not answered for 802.11r/802.11k
How does one make the judgement of whether to use or not use one or more of these features? Answered for OKC/PMK Caching, not answered for 802.11r/802.11k
Do I need the "Validate PMKID" feature in order for clients to perform roaming using PMKID caching? Answered

More info from the 6.4 User Guide:

• "Fast BSS Transition is operational only if the wireless client has support for 802.11r standard. If the client does not have support for 802.11r standard, it falls back to normal WPA2 authentication method."
• "If dot11r is enabled, iOS clients such as iPad/iPhone gen1 (limitation on iOS) and all MAC-OS clients (limitation on MAC) fail to connect to the network."
• "Fast BSS transition is operational only with WPA2-Enterprise or WPA2-Personal" [PSK networks]

I also found this forum post about 802.11k: http://community.arubanetworks.com/t5/ArubaOS-and-Controllers/Implications-of-enabling-802-11k/td-p/11364

In that post, cjoseph mentions that many clients do not respond well to 802.11k.

In other words my conclusions are...

• A lot of devices don't support OKC, so don't use it without the Validate PMKID option
• A lot of devices don't support 802.11r
• A lot of devices don't support 802.11k

What a bummer.

EDIT: The 802.11k forum post mentions that the problematic clients were IOS devices running lower than version 4.3, so maybe these days it would be OK to turn that feature on.

Hey Tim!

Great thread, I'm currently working with a customer that has a good mix on their client environment. Windows, OS X, IOS and Android happily coexisting.

A while ago we changed radius servers to a Clearpass and went with a publicly trusted server certificate, since then MAC OS X have been suffering from worse roaming. This is partly related to the CRL URL in the certificate and we tried this with good results:

http://support.apple.com/kb/TS5258

Regarding roaming protocols used we are currently using OKC with validate PMKID. I see full reauthentication at every roam from Android, OS X and IOS but not windows machines.

From my understanding, 802.11k will never help to prevent full reauthentications but merely helping in a faster selection of access point to roam to. I want to try this but have not as of yet since reading about potential problems that may occur. Did you try .k in your described environment?

The other thing I would like to try is to disable the  "Validate PMKID" option to see if it changes anything with the full reauths. Any thoughts on this?

Best regards,

Chris

My impression is that Validate PMKID is necessary for clients that do not support OKC or that have broken OKC implementations, and that this includes a lot of Apple kit.

I have not been able to google anyone maintaining a comprehensive list of client behaviors, or even a list of any quality, really.

(EDIT: another step to take is ensure your RADIUS infrastructure is supporting fast reauthentication; that will reduce the length of most "full" reauthentications)

I 2nd bjulin's comment about the Validate PMKID parameter - every piece of Aruba literature I've encountered suggests using OKC w/ Validate PMKID for the best combination of both compatibiltiy with improved roaming performance on some devices (if supported). Validate PMKID should only be turned off if all of the clients connecting to the SSID support OKC, which, again Apple products do not support at this time.

In regards to .11k (and .11r), I've created a new SSID in my own environment for testing with many advanced features turned on (still validating PMKID for OKC though). Although few devices actually support .11r/.11k, most modern devices across the board are still able to connect and use the new SSID with no problems, which is good news.

Also, your comment about 11k is correct - it won't improve the roaming speed, just help the client make a better decision about which AP to join. Using this in combination with Client Match is a winning combo.

As you can see from this article (http://support.apple.com/kb/HT5535), modern IOS devices support both 11r and 11k, which makes me hopeful that in the future, OS X will support these as well and other vendors will follow suit.

In light of that experiment, I'm toying with the idea of permanently deploying 2 SSIDs for corporate devices - one with the most compatibility, and one with all of the advanced features enabled. Any devices that can't connect to the advanced SSID can still fall back to the "legacy" SSID. I'm hesitant about this since adding SSIDs wastes airtime, so maybe I'll only do it on 5GHz... I haven't decided yet.

Here is my working sample config with OKC/11r/11k (and a few other tweaks). You can't see from the config, but I've also turned on Airgroup and Client Match. Since OKC w/ Validate PMKID is default, it also doesn't show up. What you do see is I've explicitly denied legacy devices and turned on broadcast filter (Airgroup will take care of the mDNS for Apple TVs). Again, this has been working solidly for all modern devices (with up-to-date drivers for OS X/Windows, mind you). Roaming has not been an issue.

aaa authentication dot1x "Corp-Advanced-auth_dot1x_prof"
voice-aware
!
aaa profile "Corp-Advanced-aaa_prof"
authentication-dot1x "Corp-Advanced-auth_dot1x_prof"
dot1x-default-role "Corp-Advanced-role"
dot1x-server-group "Corp_srvgrp"
!
wlan dot11r-profile "Corp-Advanced-dot11r_prof"
dot11r
!
wlan ht-ssid-profile "Corp-Advanced-htssid_prof"
no legacy-stations
max-tx-a-msdu-count-be 3
max-tx-a-msdu-count-bk 3
max-tx-a-msdu-count-vi 3
!
wlan ssid-profile "Corp-Advanced-ssid_prof"
essid "Corp-Advanced"
opmode wpa2-aes
a-basic-rates 24
a-tx-rates 24 36 48 54
g-basic-rates 24
g-tx-rates 24 36 48 54
wmm
wmm-vo-dscp "46"
wmm-vi-dscp "32"
wmm-be-dscp "0"
wmm-bk-dscp "8"
hide-ssid
deny-bcast
ht-ssid-profile "Corp-Advanced-htssid_prof"
qbss-load-enable
dot11r-profile "Corp-Advanced-dot11r_prof"
!
wlan handover-trigger-profile "Corp-Advanced-handover_trigger_prof"
handover-trigger
handover-threshold 65
!
wlan dot11k-profile "Corp-Advanced-dot11k_prof"
dot11k-enable
force-disassoc
handover-trigger-profile "Corp-Advanced-handover_trigger_prof"
!
wlan virtual-ap "Corp-Advanced-vap_prof"
aaa-profile "Corp-Advanced-aaa_prof"
dot11k-profile "Corp-Advanced-dot11k_prof"
ssid-profile "Corp-Advanced-ssid_prof"
allowed-band a
broadcast-filter all

Thanx for your detailed post!

With 802.11k configured, does OS X and IOS devices manage to connect?

I tested one IOS device and it seemed to work OK (it connected at least), and I was able to verify that it was using 11k properly from the show commands on the controller. But the device didn't belong to me so I couldn't follow up to see if everything was working OK long term. 

I also haven't had an OS X to test with, so I can't speak to that at all yet. Once I have more thorough testing on those platforms I'll update.

I'm running a similar test SSID with 11r and 11k turned on.  Despite all the comments online saying it won't work, a Mac OS 10.9 client was able to successfully connect.  As expected, iOS hasn't been a problem.  Can anyone else confirm that newer OS X clients don't have problems with 11r and 11k, even if they don't actually use the standards?

Hi Mike!

Thanks for your input, so you're still seeing full reauthentications while roaming?

We didn't have.1x enabled for authentications (just using WPA2) which means .11r isn't really doing anything, if my understanding is correct.  That might be why the Mac isn't having any problems.  That said, with .11k enabled, I was not having roaming problems.

Hi Tim,

Thank you for all of the time on this thread! The information is extremely useful. Given the fact that it is now 2017 and we have a ton of BOYD devices in our WLAN, how has your configuration treated you? I am currently experiencing issues with Android based Samsung devices. I have PMK(Validate) and OKC enabled, but left 11.r and 11.k disabled. However, the samsung devices seem to forcefully disconnect, and reconnect at random intervals through out the day. I was wondering if you have experienced that in your environment, and if so (or not) what could I do differenly to improve the wireless performance for the android base user?

All I can offer is that I reached the same conclusion about OKC/validate options and am

running that way and though we have some issues none have surfaced that are related to

this.  This is in a college environment for which "BYOD" is an understatement.

Also on 11k the answers I've had offered seem to paraphrase to "depends on how old/cretinous your clients can be" and "you may be able to get away with it if not now within a year or two."  So it's a decision like disabling slow rates -- at some point you have to figure out if it's worth punishing the rest of the network just to keep some Wii's or the like from getting the boot, or just draw the line and kick them off.

11r forget it unless you are in an environment where you pick the client mix.  Maybe a few years from now.