Hotspot 2.0 is a technology that leverages 802.11u and service provider authentication systems to connect clients to WLAN’s securely and automatically. For example, an owner of a Verizon Samsung Galaxy S5 with Passpoint enabled who comes within range of a Hotspot 2.0-enabled SSID which can serve Verizon customers will automatically connect to the WLAN, secured by WPA2, with no user interaction.
At least, that’s how I understand the most common use case for Hotspot 2.0 and 802.11u. Personally, I have other ambitions for the program and currently it isn’t at all clear what else Hotspot 2.0 is capable of.
I’m encouraged to see that Hotspot 2.0 Release 2 provides a public key infrastructure and pre-installed trusted root certificates on clients for use when forming secure connections to WLAN infrastructure components.
What I’d really like to see if that PKI infrastructure used in a manner similar to HTTPS, so that clients securely connect to an “open” SSID, use EAP-TLS to evaluate the server certificate against its trusted roots, and establish a WPA2 protected connection without any client-side credentials or cumbersome captive portal registration process. 802.11u data can be presented to the client for use in evaluating the certificate. To me, that is the holy grail for WLAN guest networks.
Authenticating users through carrier AAA isn’t important because very few WLAN operators want/need to know the identity of users on their guest networks (with the exception of retail, I suppose).
I must say that I cringed when I read that Release 2 includes “portal based signup.” Hopefully this is substantially different from the extremely mobile-unfriendly process of current captive portal technology. Either way it will be an obstacle to onboarding users. Guest Wi-Fi should be frictionless.
I’m not interested in authenticating guest users on the WLAN, but I do want them to have a secure connection. It would be awesome if WLAN operators could opt-out of all that AAA integration complexity required by Hotspot 2.0 and just use the PKI infrastructure to run an open, encrypted WLAN for guests. This would allow more clients to connect securely as well, rather than only smartphones with with carrier agreements and users that suffer through a portal-based signup process. Will this be possible? I certainly hope so.
The design of a WLAN to accommodate a school’s 1:1 program can make or break the entire enterprise. A poorly designed WLAN presents connectivity issues, bandwidth issues, co-channel contention, and RF utilization problems that distract end-users from classroom activities and results in a loss of trust in the technology. Similarly, clients with substandard Wi-Fi chipsets will also compromise WLAN performance.
These are some of the important considerations I’ve learned when designing and operating a WLAN to support a school’s 1:1 program.
Key points to consider when designing a high-density WLAN to support a 1:1 program:
- 802.11ac is highly desirable, 802.11n is workable and a minimum requirement
- Do a site survey to determine optimal AP placements, but design for capacity, not solely coverage
- Evaluate your switching capacity, including PoE budgets, for AP backhaul
- Establish client SLA’s before designing the WLAN
- 5 GHz radios are required
- DFS channels are required for wide channels or very-high density
- 2.4 GHz becomes a junk band in high density. Use it only for guest/BYOD clients.
- Use band-steering to move clients to the 5 GHz spectrum
- Use the entire 5 GHz spectrum everywhere, and choose channel bandwidths to prevent cell overlap.
- 80 MHz channels in coverage-areas
- 40 MHz channels in high-density areas like classrooms
- 20 MHz channels in really high-density areas such as multi-story classroom layouts
- Disable low data-rates, all the way up to 24 Mbps. Experiment with going higher.
- Reduce maximum AP radio power to limit cell sizes
- Reduce AP radio receive sensitivity to prevent clients at the edge of the cell from associating
- Use load balancing techniques to spread clients evenly among AP’s
- Limit SSID’s to as few as possible, generally no more than three. Try this:
- 1 SSID with WPA2-Enterprise security for school and BYOD devices
- Use AAA override/dynamic profile assignment (whatever your vendor calls it) to assign security policies, access control, VLAN’s, and QoS policies via RADIUS attributes
- 1 SSID with no security for guest access
- Only use WPA2-Enterprise 802.1X authentication. WPA-PSK is a nightmare if you ever need to change the password.
- Use an MDM solution to distribute Wi-Fi credentials
- Rate-limit guest and BYOD clients
- Use QoS to deprioritize traffic from guest and BYOD clients
- Use layer 7 QoS to deprioritize/rate-limit bandwidth hogs that are not time sensitive including
- Mac OS, iOS, Chrome OS, and Windows software updates
- Dropbox, iCloud, and Skydrive syncing
- Site-specific background data hogs such as an enterprise AV deployment, WSUS server, etc.
- Track the applications used on the WLAN and use layer 7 QoS to deprioritize/rate-limit bandwidth hogs that are time sensitive, but are only used for recreational purposes on the WLAN.
- Netflix, Pandora, Grooveshark, etc.
Should time allow, many of these points will become blog posts of their own.
For all of this to work, client devices must meet these requirements. Cheap and used devices rarely meet these specifications. Choose carefully. Don’t compromise.
- 802.11n minimum, 802.11ac desired
- The more spatial-streams, the better
- 802.1X support
- MDM support
- 5 GHz band support
- DFS channel support
Unfortunately many device manufacturers limit the Wi-Fi specs they publish to simply “802.11n” or “802.11ac.” Tracking all of this down is often only possible through testing a device in-person, especially DFS support.