Showing posts with label aerohive. Show all posts
Showing posts with label aerohive. Show all posts

Friday, May 31, 2013

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

Sunday, June 24, 2012

My IPv6 Mission

I've decided that I've procrastinated long enough. Therefore, over the next few months I'm on a mission, an IPv6 mission. I'll be reading as much material as I can get my hands on, deploying native IPv6 on my home network (including WLAN), and connecting to Hurricane Electric's tunnel broker service for native IPv6 Internet access.

To help me get started, I've acquired the following resources:

Cisco 871W Router
This router is a bit older, but it was easy to acquire, can run dual-stack IPv4 and IPv6 which gives me support for both protocols in my home (because not all of my clients support IPv6, like my Roku and Wii), and it is still receiving software upgrades from Cisco. I won't be using the integrated radio in this unit since it's ancient by fast-moving Wi-Fi standards (802.11g only; when this unit first came out it didn't even support AES-CCMP... so yeah, the radio hardware is a bit old).
Aerohive AP 330 (x2, and one AP 170)
Let's not overlook IPv6 for our Wi-Fi clients! I already have an Aerohive WLAN at home, and it supports IPv6 client access. The AP 330s have two 3x3:3 MIMO radios, full enterprise-class features, and mesh networking which I've extended out to my garage (hey, the man garage cave needs streaming Internet radio while I'm working on my motorcycle)!
IPv6 Essentials, 2nd Edition
Deploying IPv6 Networks
IPv6 for Enterprise Networks

I'll be posting what I learn as I go on this blog. I'll also be tweeting what I learn and my progress using the #IPv6Mission hashtag on Twitter. 

Follow along if you're new to IPv6, and I hope you enjoy! Even if you are familiar with IPv6, I'll be covering specific implementation details for Wi-Fi networks, which can be a bit different animal than wired IPv6 (there are a few gotchas that you'll need to be aware of - but let's save those for another post). And for those IPv6 experts out there, I may just need some help from time to time :)

Cheers,
Andrew

Thursday, April 5, 2012

Wi-Fi and Aerohive, The Right Fit!


This blog was originally posted on the Aerohive HiveMind Blog, but I wanted to make sure that my regular readers on this site were informed. I will splitting my blogging between Aerohive and Revolution Wi-Fi from here on out, so you may notice some drop in the frequency of posts on this site. Please visit the Aerohive blog to read my posts over there as well!

About a month ago I made the leap... I changed employers and hopped over the fence from the customer side to the vendor side. I knew the time was right, and the opportunity was right and I’ve been looking to put it into words ever since. I’ve thought long and hard, searching for a deep insight into why I made the decision to join Aerohive Networks, let alone a vendor in general. Finally, I realized I was over-thinking it. The reasons are simple...

Wi-Fi Is My Passion (and a burgeoning industry)
The first reason comes down to doing what I love to do. I started my career as a general technologist, working equally on building networks, servers, data center facilities, and core services like DNS and Active Directory. I quickly fell in love with networking because it was the glue that held everything together.  

Then I found Wi-Fi. I’m the first one to admit it, I’m a dreamer (and an idealist). I love seeing how technology changes how we interact with the world, how it influences our society, culture and behaviors. I’m a people-gazer.  Wi-Fi ignites my passion because it is on the front lines, directly affecting people’s lives. In the same fashion that Steve Jobs and Apple have changed how people interact with each other and the world through the effective design and use of technology, I think Wi-Fi has much the same effect. And I love being a part of that!


Wi-Fi gives one time to think and reflect. No wonder I’m a dreamer!
This is me performing a site survey for an outdoor mesh deployment.

I’m also very lucky to be involved in this industry at a time when Wi-Fi is experiencing a second wave of growth. It really took off in the home around 2003 with 802.11g. The release of 802.11n revitalized and broadened the possibilities in the enterprise. And with the wave of mobile devices, expansion of hotspots, and carrier offload, Wi-Fi is poised to play a prominent role in how people stay connected in their personal and professional lives like never before. Technology advancements like 802.11ac and 802.11ad will be exciting enablers to make solutions for video more pervasisve.

I’m fortuitous to be working with a technology I love, in an industry that is full of potential!

Innovating not Following
The second reason, and specifically why I joined Aerohive, is I believe in our technology. It’s important for me to work at a company that has an innovative spirit and a forward-thinking vision. I believe Aerohive offers that in spades!

The Aerohive Cooperative Control architecture is modern, is not constricted by legacy controller mindset, and allows our team to focus on solving business problems using innovative technology for our customers. Examples include the Bonjour Gateway, BYOD and mobile device solutions, Branch on Demand routing, Client Health Score for simplified troubleshooting, PPSK for enterprise class security that’s easier for smaller organizations to deploy and support, directory integration capabilities for high availability, Cloud SaaS operating model options, TeacherView and StudentManager.

I’ve worked with almost every Wi-Fi vendor solution on the market, and while most are capable solutions, they’re also complex to deploy, manage, and support for customers. In addition they’re spinning significant development cycles on re-designing a controller architecture back into a distributed architecture rather than on focusing on customer needs. We see this with Cisco’s move towards FlexConnect, Aruba towards RAP and Instant, and with Motorola toward Wing5. They’re busy making the Wi-Fi basics work in a distributed fashion, incrementally migrating existing features back into the access point. But they’re suffering from feature and scalability limitations while doing so, and limiting their ability to innovate at the same time. They are also validating the Aerohive position that was pioneered years ago with Cooperative Control (albeit in a twisted fashion) – Thank You!

Aerohive offers a focus on innovation. I want to be a part of that.

Relationships Matter
I’ll be the first to admit this... my success is a direct result of the relationships that I form with other [very smart] individuals. I learn best and succeed most when I surround myself with people smarter than I am. This was true when I first started my career, getting mentorship from an incredibly experienced radio and network engineer (thanks Tony, if you ever read this). It’s still true, no matter how far I’ve come in my career.


Making friends, at -15° F (I’m far left)

Aerohive is a pool of incredible Wi-Fi talent. I know other vendors are as well, but I think our team is especially so. It’s like a laundry list of who’s who in the industry, not only from name recognition but from respect. And respect matters a lot to me. Individuals like David Coleman, Matthew Gast, Bob O’Hara, Joel Vincent, Abby Strong, and my new boss Devin Akin are well-known thought leaders in this industry and well respected by everyone. I can learn from these people, and will in buckets!

The leadership team also exudes confidence and experience in running a small tech company and know how to succeed. We’ve got David Flynn, ChangmingLiu, Adam Conway, and others who have “been here, done it before” with Netscreen and Juniper. These individuals give me great confidence on our ability to execute and be successful.

The Right Fit
Putting all these things together, Aerohive was the right fit.

I’m excited to be on the Aerohive team, and can’t wait to evangelize Wi-Fi technology in general and our solutions in particular. We have a lot to offer today and a ton more coming in the pipeline!

Exciting times!

Cheers,
Andrew vonNagy

Thursday, June 2, 2011

Wi-Fi Article Round-Up: 2011/06/02

A recap of Wi-Fi related articles from around the interwebs. As always, for a complete list of articles check out my shared article feed from Google Reader.

My Stuff:
Industry Wi-Fi Articles:
Techie Wi-Fi Articles:
  • Sam Clements busted out some Linux kung-fu on Cisco networking equipment to resurrect an NM-AIR-WLC6 from death. He reminds us just how useful some basic Linux skills can be as a swiss-army knife for many occasions as an IT professional. And that "dd" is our friend :)
  • The guys at MetaGeek give practical advice on building a spectrum analysis report with their Chanalyzer Pro Report Builder. Remember, include only the appropriate amount of data and graphs to get your point across. Too much data can be self-destructive!
  • Aerohive released HiveOS 4.0, which includes enhanced support for Mobile Internet Devices (MIDs), spectrum analysis based on the Atheros chipsets, and Partner Admin which enables managed service provider cloud NMS control for customer deployments. See reviews by Chris Lyttle and Marcus Burton.
  • PC Pro (a UK based magazine) researched What's Killing Your Wi-Fi? This article is full of so many mistakes, mis-conceptions, and flat-out wrong advice, that I would caution anyone reading it to dismiss most of what it says. From getting the unlicensed frequency ranges wrong, describing co-channel interference of other Wi-Fi networks minimal compared to non-Wi-Fi interference, to coming dangerously close to advising users to leave their networks unsecured for performance gains, PC Pro shows very poor journalism. I also would like to know what "wireless industry experts" they "canvassed", because they don't site any sources (other than generically) and their facts are incomplete or wrong in many cases.
Other IT Related Articles:
  • Riverbed unleashes the fury on competitors paying for so-called "independent lab testing", which is arguably skewed to shed favorable light on the sponsoring vendor's products. I think we've all read these types of reports, and most of us are smart enough to see through them. However, it's unfortunate that some customers will never know better, and take these reports at face value. Matthew Norwood also recently called out the need to study vendor solutions and be careful who you trust prior to making decisions. Bravo Riverbed and Matthew!
  • My good friend, Nate Lee, covered ARP Spoofing / Man-in-the-Middle attacks, DHCP Snooping, and Dynamic ARP Inspection security controls on wired switches. This is a great intro to these network security features that all organizations should consider implementing on edge access switches. This must be his way of showing me how secure his network can be after I've heckled him for years about how my Wi-Fi network was much more secure than his wired network :)
  • Stephen Foskett gave the low-down on what Tech Field Day is all about, and I am super jealous about the Fenway Park visit during Tech Field Day 6 in Boston next week. I know it's virtualization focused, but I soooo want to be there!
  • FCC Commissioner Mignon Clyburn visited my hometown of Omaha, NE and spoke about broadband availability being so much more than just access to the Internet. The Internet is already a necessity for almost everyone to function in today's society. She spoke of the issues of physical broadband availability, adoption, and important access provided by local libraries, schools, employers, friends and families. Also of critical importance, especially in rural America, is access to distance learning programs for children and students (something which I am proud to have worked on at my time early in my career with a local NE school district).
Comic for the Week:
Take a break, with a Geek Meditation Session (courtesy of AllThingsD, via @travis_schlafke)


Cheers (and happy reading!),
Andrew

Tuesday, May 24, 2011

Aerohive Credential Caching Improves Branch Office Availability

The Necessity for Highly Available WLANs
Wireless LANs are mission-critical, and have been for a while. More so than ever, the availability of the wireless network is important to operate business, educate students, and interact with consumers. Organizations across many industries have realized the benefits of that mobility, users increasingly expect ubiquitous network access, and machine-to-machine (M2M) communications are poised to grow the demand exponentially. In such an atmosphere, the wireless network must be high performing, resilient, adaptable, and highly available.

Many organizations provide highly available WLANs by using pre-shared key (PSK) security since there is no reliance on external systems for network access. EAP authentication provides higher security than PSK deployments, but suffers from higher complexity and reliance on AAA services external to the WLAN for network access. Modern wireless networks typically rely on RADIUS as this service. However, deploying local authentication services at each remote site can be cost prohibitive due to software licensing and server resources. This, coupled with higher latency involved with EAP authentication across a WAN circuit, typically leads many organizations to adopt central AAA services for non-mission critical applications, and forgo stronger EAP security and implement PSK for mission-critical applications such as VoWiFi or transaction processing. This results in a trade-off of security for availability, which is sub-optimal and introduces a much higher amount of risk to the organization.

Can't we have both high security using EAP with dynamic per-user authentication and keying coupled with the high availability of PSK networks? We can, using Aerohive credential caching!

Credential Caching Overview
Aerohive authentication cache provides remote branch offices the ability to cache successful client authentications from central directory services for use when the central site or services are unavailable, such as a WAN outage. This provides high availability of the WLAN for remote sites, enabling continuity of service for locally deployed applications, collaboration among users, and local Internet access (if deployed locally at branches and not tunneled back to the corporate head-end).

It does this by providing local RADIUS service within select HiveAPs and integrating with corporate directory services, including Active Directory, Open Directory, and native LDAP systems. In this scenario, the HiveAP provides EAP authentication for clients and functions as both the authenticator and authentication server simultaneously. EAP types supported include PEAP, EAP-TLS, EAP-TTLS, and LEAP. On the back-end the HiveAP is configured with directory access credentials to authenticate users and cache their login information locally from the directory server for offline use (similar to a Windows computer object joined to the domain). This may include Kerberos v5 if using Active Directory as the back-end directory service.

Aerohive Credential Caching Logical Diagram with Central Directory Services


Note - I know some of you will be wondering why I'm not discussing Private PSK (PPSK) or Dynamic PSK (DPSK) offered by Aerohive and Ruckus. While these are novel approaches for small scale solutions involving user interactive device platforms, these solutions cannot address many deployment scenarios involving embedded devices or non-user devices, as is typical with voice handsets and vendor transaction processing systems. A more robust and scalable solutions is required for such scenarios.

Deployment Requirements
To deploy credential caching, administrators must configure a the following settings on HiveAPs at the branch sites:
  1. Determine the remote HiveAPs that will provide local AAA server (RADIUS) services
  2. Assign static IP addresses to the HiveAPs providing AAA services
  3. Create certificate(s) for HiveAP AAA servers to use during EAP authentication
  4. Integrate the HiveAP AAA servers with user directory services
  5. Create the HiveAP AAA server (RADIUS) configuration
  6. Create AAA client settings for all other NAS client APs, which point to the HiveAP AAA server(s) for RADIUS authentication
  7. Deploy configurations to all HiveAPs
First, determine which HiveAPs at each remote site will be AAA servers providing RADIUS and EAP termination. One or multiple HiveAPs may provide AAA services for other HiveAPs. Multiple APs are recommended to provide fault tolerance at each branch location.

Second, the selected HiveAPs must be configured with static IP addresses since they will be providing services that other NAS client APs will rely on for user authentication. Assign static IP addresses from within individual AP configuration settings in the "Interface and Network Settings" section (be sure to also configure DNS servers in the WLAN profile when using static IP addresses to ensure name resolution for HiveManager discovery).

Next, create one or multiple RADIUS server-side certificates for use by the HiveAP AAA servers. The server-side certificates are required during TLS tunnel setup between the RADIUS server and client during EAP authentication. This can be accomplished by creating a Certificate Signing Request (CSR) either from HiveManager or using an external utility such as OpenSSL. Using HiveManager is a simple process; navigate to Advanced Configuration > Keys and Certificates > Server CSR. Fill out the form and click "Create". 

Then send off the CSR file to the Certificate Authority for verification and certificate creation. Once the CA has issued the certificate, navigate to Advanced Configuration > Keys and Certificates > Certificate Mgmt to import the certificate into HiveManager. The private key file will automatically be generated with the CSR and listed in this section. No manual merging of the private key and issued certificate are required, but may be performed if desired. Also import the CA certificate to send the complete certificate chain to clients during outer TLS tunnel establishment. It will also be used to verify trust of client certificates if using EAP-TLS authentication. The certificate, private key, and CA certificate files will be pushed to HiveAP AAA servers later during the configuration.

Aerohive Certificate Management, Showing the Private Key,
CA Certificate, and Issued Certificate Files

Integration with AAA user directory services is accomplished in the Advanced Settings > Authentication > AAA User Directory Settings section. In this section, you will define a profile that HiveAP AAA servers will use to query a back-end directory to authenticate users. This may include Active Directory, Open Directory, or native LDAP. In this example we will use Active Directory since this is very common. Create a new profile to get started.

Aerohive HiveManager AAA User Directory Settings
Select the directory type from the option buttons and select or define a new IP address / host name network object for the Directory Server. Multiple directory servers may be configured for redundancy.

For Active Directory integration, specify the default domain in which the HiveAP computer object, AD server, and user objects to be authenticated reside (select the root domain of the forest). If users in multiple domains need to be supported, configure the "Multiple Domain Info" section at the bottom. Configure the BindDN account (user object) that HiveAP AAA server(s) will use when authenticating itself to the directory server to lookup user accounts. This allows the HiveAP RADIUS service to authenticate wireless users. Additionally, in order to perform credential caching, configure the Admin User account which is used by the HiveAP to login to Active Directory and add itself as a computer object in the domain or computer OU specified. This allows the HiveAP to cache user NTLM credentials locally in access point RAM for use when the directory server(s) are not available. The admin user specified must have rights to add computer objects into the domain or OU specified.

Note - Using this method, the admin user account information is stored in HiveManager and in the flash configuration file of HiveAPs. If this is not desirable, HiveAPs may be joined individually to the domain from the CLI which does not get stored in any configuration files. Issue the following command: "exec aaa net-join { primary | backup1 | backup2 | backup3 } username USER password PASSWORD".

Next, create a HiveAP AAA Server profile for the access points providing RADIUS service from the Advanced > Authentication > HiveAP AAA Server Settings section. Here you will define what EAP methods are supported, the certificate files to be used during EAP, database access settings, and NAS clients. For the database access settings, select the configured directory service type and previously configured AAA user directory profile. Enable RADIUS Server Credential Caching and set a cache lifetime which determines how long cached credentials will be used when the directory server(s) are not available. The remaining three interval timers determine how long an individual directory server is marked down before being retried (default 600 sec.), how long to use the local database if all directory servers are down before retrying (default 300 sec.), and how long to keep retrying an unresponsive remote directory server in the list before moving on to the next server in the list (default 30 sec.).

Enable Credential Caching in the HiveAP AAA Server Settings

In the NAS settings section be sure to configure the IP address of every NAS client AP  that needs to use the HiveAP RADIUS server to authenticate clients, or configure a IP network object for broader access by multiple APs in the same subnet range.

Finally, create a AAA Client Settings profile which will be deployed to all of the other NAS client APs instructing them to contact the HiveAP AAA Server(s) for RADIUS authentication services. This is configured from the Advanced > Authentication > AAA Client Settings section.

Once all configuration is complete, assign the HiveAP AAA Server Settings profile to APs designated to be RADIUS servers from within individual AP configuration settings in the "Service Settings" section. Also embed the AAA Client Settings profile within SSID profile(s) as the assigned RADIUS server(s), and deploy configurations to all APs.

Verification
Once the configuration for HiveAP RADIUS servers and HiveAP NAS clients have been deployed to access points, verify directory integration by reviewing access point and directory server logs. Logs in both locations will show successful bind to the LDAP server and computer object creation.

Active Directory Logs Showing Successful Bind, and HiveAP Computer Object Creation

Finally, verify correct credential caching operation by performing client authentication while directory services are available and then re-testing once directory services are unavailable using the local AP cache. Issue the "show auth" command to view currently authenticated clients as well as cache entries created. Below we can see one current user session followed by an entry for the same client in the local cache table.

HiveAP02#show auth
Authentication Entities:
if=interface; UID=User profile group ID; AA=Authenticator Address;
idx=index; PMK=Pairwise Master Key; PTK=Pairwise Transient Key;
GMK=Group Master Key; GTK=Group Transient Key;

if=wifi1.1; idx=11; AA=0019:7729:57a0; SSID=HiveMind; default-UID=0;
PTK-rekey=0; GTK-rekey=0; GMK-rekey=0; strict=no; preauth=no; replay-window=0;
proactive-pmkid-response=disabled;
Reauth-period=n/a; PTK-timeout=4000; PTK-retry=4; GTK-timeout=4000; GTK-retry=4;
Local-cache-timeout=86400
Protocol-suite=WPA2-AES-802.1X;

No. Supplicant UID PMK PTK Life State Reauth-itv Cipher User-Name
--- -------------- --- ----- ----- ----- ------- ---------- --------- --------------------
0 0019:7e9d:871d 0 4f76* ec43* -1 done 0 WPA2/CCMP HiveUser

Local Cache Table:
No. Supplicant UID PMK PMKID Life TLC User-Name
--- -------------- --- ----- ----- ----- ----- --------------------
0 0019:7e9d:871d 0 4f76* 0850* -1 86232 HiveUser


Issue the same command after disconnecting the client and the current session entry will be removed, but the local cache table entry will remain (up to the configured cache lifetime).

HiveAP02#show auth
Authentication Entities:
if=interface; UID=User profile group ID; AA=Authenticator Address;
idx=index; PMK=Pairwise Master Key; PTK=Pairwise Transient Key;
GMK=Group Master Key; GTK=Group Transient Key;

if=wifi1.1; idx=11; AA=0019:7729:57a0; SSID=HiveMind; default-UID=0;
PTK-rekey=0; GTK-rekey=0; GMK-rekey=0; strict=no; preauth=no; replay-window=0;
proactive-pmkid-response=disabled;
Reauth-period=n/a; PTK-timeout=4000; PTK-retry=4; GTK-timeout=4000; GTK-retry=4;
Local-cache-timeout=86400
Protocol-suite=WPA2-AES-802.1X;

Local Cache Table:
No. Supplicant UID PMK PMKID Life TLC User-Name
--- -------------- --- ----- ----- ----- ----- --------------------
0 0019:7e9d:871d 0 f7ad* b08f* -1 86386 HiveUser


Finally, disable the back-end directory services and re-test client authentication using the credential cache on the access point. The following log output is in reverse chronological order, and shows the HiveAP AAA server unable to bind to the directory server at 10.22.33.44, then successfully authenticating the client "HiveUser" via RADIUS using the local credential cache from the NAS client at 10.108.30.18, which is its own IP address.

2011-05-10 10:11:20 notice ah_rt_sta_modify: 0019:7e9d:871d(ip=10.108.30.96)
2011-05-10 10:11:20 notice Station 0019:7e9d:871d is authenticated to 0019:7729:57a0 thru SSID HiveMind
2011-05-10 10:11:18 info [mesh]: set proxy : 0019:7e9d:871d 0019:7729:5780 wifi1.1 flag 0x1c03
2011-05-10 10:11:18 info set proxy route: 0019:7e9d:871d -> 0019:7729:5780 ifp wifi1.1 upid 0 flag 0x1c03 monitor(0/0) pkt/sec ok
2011-05-10 10:11:18 info receive event STA JOIN: 0019:7e9d:871d associate wifi1.1 upid 0 vlan 1 flag 0x00000000
2011-05-10 10:11:18 notice ah_rt_sta_add: 0019:7e9d:871d(ip=10.108.30.96)
2011-05-10 10:11:18 info [Auth]STA(0019:7e9d:871d) login to SSID(wifi1.1) by user_name=HiveUser
2011-05-10 10:11:18 notice ah_auth_radius_check_nas_ip: updated nas_ip(10.108.30.18)
2011-05-10 10:11:18 info radius_msg_get_vendor_attr: select vhdr(type=17, len=52)
2011-05-10 10:11:18 info radius_msg_get_vendor_attr: select vhdr(type=16, len=52)
2011-05-10 10:11:18 info RADIUS: The RADIUS server accepted user 'HiveUser' through the NAS at 10.108.30.18.
2011-05-10 10:11:18 info RADIUS: eap auth for STA=0019:7e9d:871d user=HiveUser successfully with type peap
2011-05-10 10:11:18 warn RADIUS: User 'LDAPLAB\HiveUser' do LDAP_search under baseDN 'dc=ldaplab,dc=abccompany,dc=com' from server '10.22.33.44' failed
2011-05-10 10:11:18 warn rlm_ldap: (re)connection attempt failed
2011-05-10 10:11:18 err rlm_ldap: cn=HiveAPBind,ou=people,dc=ldaplab,dc=abccompany,dc=com bind to 10.22.33.44:636 failed: Can't contact LDAP server
2011-05-10 10:11:16 notice ah_auth_radius_check_nas_ip: updated nas_ip(10.108.30.18)
2011-05-10 10:11:16 info RADIUS: eap auth for STA=0000:0000:0000 user=HiveUser successfully with type mschapv2
2011-05-10 10:11:16 warn RADIUS: User 'LDAPLAB\HiveUser' do LDAP_search under baseDN 'dc=ldaplab,dc=abccompany,dc=com' from server '10.22.33.44' failed
2011-05-10 10:11:16 warn rlm_ldap: (re)connection attempt failed
2011-05-10 10:11:16 err rlm_ldap: cn=HiveAPBind,ou=people,dc=ldaplab,dc=abccompany,dc=com bind to 10.22.33.44:636 failed: Can't contact LDAP server

Therefore, using the Aerohive credential caching feature, EAP authentication services can be maintained during a WAN outage or central site service disruption. This feature bridges the gap for branch sites, allowing continued WLAN network access by clients during temporary service disruption. The cache lifetime setting dictates the tolerable duration of a service outage.

Revolution or Evolution? - Andrew's Take
Industries from retail, education, hospitality, healthcare, and transportation are relying on mission-critical wireless networks to operate business. They expect a highly secure and highly available network at reasonable cost and with minimal complexity. And they won't tolerate trade-offs between these features. The status quo from most WLAN vendors is to provide basic RADIUS integration for client authentication. Aerohive has gone further, integrating native LDAP and Kerberos functionality which provides user credential caching enabling a highly available WLAN network without compromising security to get there.

Aerohive isn't rewriting the book on RADIUS, LDAP or Kerberos. These are existing, mature protocols. However, Aerohive has applied these features in a new and unique way that can dramatically improve WLAN availability and provides tremendous benefits for distributed organizations with branch offices.

Cheers,
Andrew


Other Posts You Might Like:

Wednesday, April 20, 2011

Aerohive HiveAP Initial (Guided) Configuration

Once armed with HiveAPs that are provisioned and have successfully connected to the HiveManager system, and a working knowledge of the HiveManager configuration workflow, we are ready to create and deploy an initial configuration to our HiveAPs.

Administrators can opt to configure the HiveAPs through the Guided Configuration or the Advanced Configuration. I recommend that administrators use the guided configuration until they are comfortable and fully understand all of the settings contained in the advanced configuration section.

Guided Configuration
As the HiveManger online help system states:
"When you first start using HiveManager, the number of configuration objects can be somewhat overwhelming. Common questions that arise at this stage are "What do I need to configure?" and "Where do I begin?"
HiveManager Guided Configuration Section
Luckily, the HiveManager Guided Configuration takes the administrator through the basic configuration steps required to setup HiveAPs to get a WLAN up and running. Navigate to the "Configuration" section of HiveManager. The Guided Configuration section will be visible along the left side of the screen (shown right).

To create a basic configuration to get up-and-running, we'll tackle the basic settings for each of the four objects described in the HiveManager workflow, as well as provide an overview of the optional settings in each section. Note - we will configure individual "HiveAPs" at the end, as it makes a bit more sense to do this last.

Additionally, the HiveManager Help system is context-sensitive, so if you get stuck or need to lookup an item you are unfamiliar with you can simply select Help > HiveManager Help from the upper right corner.

Note - Configuration of these profiles does not affect the current operation of the wireless network until they are applied to HiveAPs and the updated configuration is pushed out, which is covered at the end of this article.

User Profiles
Create a new user profile which controls the default settings applied to users mapped to this profile. User profiles can be applied to users statically through SSID assignment or dynamically through RADIUS assignment based on returned attributes by the server.

Basic settings include the default VLAN access and the Attribute Number used for RADIUS policy assignment of users into the correct user profile. RADIUS attributes 64, 65, and 81 are used for both VLAN and User Profile assignment, with different values of-course (shown below).

Mapping LDAP User Groups to Local User Profiles with RADIUS Attributes
Optional settings in this section include GRE or VPN tunneling for station isolation (guest WLANs) or other security requirements, L2/L3 firewall policies, QoS settings for rate limiting, queuing, and call admission control (CAC), user profile availability schedule (day & time restrictions), and SLA settings for throughput and airtime fairness.

It should also be noted that many of the settings nested within these main objects are linked to corresponding Advanced Configuration objects. These links can be followed by clicking on the "Plus" (Add) or "Notepad" (Modify) icons next to the configuration item. Once the advanced item has been configured, the user is returned to the main object to continue configuration where they left off. 

Link to Add or Modify an Advanced Configuration Item
SSID Profiles
Within the SSIDs configuration section, administrators define logical wireless networks that control the methods by which client and access points communicate with each other, which often includes authentication and encryption settings (as shown below).

SSID definition and security settings configuration in HiveManager
Advanced Access Security Settings can be displayed where indicated by the red line by clicking the link in the figure above. This allows the administrator to fine-tune Group and Pairwise (User) encryption key lifetimes and timers, including an option to enable Proactive / Opportunistic Key Caching (PKC/OKC).

It should also be noted that Aerohive has developed a unique feature called Private Pre-Shared Key (PPSK), that enables the provisioning of unique PSKs to individuals, rather than sharing a single WPA/WPA2 PSK with everyone on the same network. This prevents users from eavesdropping on each other, makes network access revocation tied to individual users, and eases access revocation by eliminating the need to update PSKs on all workstations any time an individual user access is revoked. This is a great feature for small businesses with growing user bases to maintain network security and manageability without having to invest in enterprise class authentication with 802.1x/EAP. Often times small businesses struggle with the expertise, expense, and support involved with deploying an 802.1x solution, and this helps them transition and scale until they are ready. PPSKs are also useful in guest networking scenarios as an alternative to an open network, typically with a clerk, concierge, or attendant providing guests with unique PSKs upon arrival at the establishment.

User profiles are also assigned to users connected to this SSID. In the User Profiles for Traffic Management section, define the default user profile for all users accessing this SSID. Optionally, if using WPA/WPA2 802.1x (Enterprise) also select the user profiles that are allowed to be dynamically assigned to users by a RADIUS server. If the RADIUS server does not return a user profile attribute, or returns a non-selected user profile from the list, then the default user profile is applied. For advanced security, strict enforcement of selected user profiles available for dynamic assignment can be applied, and can be configured to instruct the access point to either disconnect the user, ban the user for period of time (e.g. 60 sec.), or ban the user forever. This is a great security feature which allows a single RADIUS server (or server cluster) to handle authentication for multiple user groups while still enforcing strict network access policies. This prevents SSID hopping whereby a valid user who authenticates successfully connects to a different SSID to gain higher privileged network access rights.

Optional settings in the SSID profile include radio data rates for both 2.4 GHz and 5 GHz network bands, denial of service prevention settings, traffic filtering for management access and client-to-client traffic handling, SSID availability schedules (day & time restrictions), and several advanced configuration settings such as maximum client limit, DTIM period, fragmentation threshold, Wi-Fi Multimedia (WMM), SSID broadcast / hiding, and U-APSD power save.

WLAN Policies
The WLAN policy is the top-level object underneath which all other configuration objects are stored (except for individual HiveAP settings), and are pushed to HiveAPs to apply the operational network settings. As such, the WLAN policy ties together many objects which have previously been configured with a few new ones.

After giving the WLAN policy a name and description, define the Hive that will be used for all access points which are assigned this WLAN policy. A Hive essentially allows multiple HiveAPs to coordinate distributed wireless network control plane and data plane operations, forming a virtual software controller using Aerohive's Cooperative Control architecture. This includes forwarding and routing paths, consistency of QoS and firewall policy enforcement, layer 2 and layer 3 client roaming, and radio frequency and power management. Hive members may be on the same subnet or different subnets. It is recommended that all HiveAPs which clients can seamlessly roam between (without disconnecting) be included in the same Hive.

Configuring a WLAN Policy in HiveManager
Next, add one or multiple SSID profiles to the WLAN policy, which defines the SSIDs that will be pushed to the HiveAPs for network access. Also define the default management interface VLAN and native (untagged) VLAN for the HiveAPs. These VLAN settings help administrators segment management traffic from user traffic to meet performance and security requirements common in most organizations.

Optional settings in the WLAN policy include HiveAP physical interface traffic filters, service settings for application layer gateway (ALG) and WIPS, management servers for SNMP, syslog, DNS, NTP, and location services, QoS classification and marking, dynamic airtime scheduling, VPN service settings for identity-based tunneling (guest DMZ termination for example), and statistics collection settings.

Note - QoS classification and marking is performed globally within the HiveAP, but QoS queuing structures are defined per user-profile.

Note - If you plan on assigning HiveAPs static IP addresses, ensure that DNS servers are defined in the WLAN policy applied to the AP so that it can resolve and connect to HiveManager.

Individual HiveAP Settings
In addition to User, SSID, and WLAN Policy settings, unique settings can be configured for individual HiveAPs. Select the "HiveAPs" link from the Guided Configuration section, which will redirect to the Monitor > HiveAPs screen. Be sure to select the "Config" option button before drilling into an AP to modify the configuration instead of viewing statistics.

Once in an individual HiveAP, administrators can configure various settings that are typically unique to a single AP. These include host name, map location, assigned WLAN policy, radio modes (access, bridge, mesh), and static channel and power settings.

Configuring individual HiveAP settings


Note - To assign a WLAN Policy to multiple HiveAPs at once, select the check boxes next to each HiveAP in the Monitor > HiveAPs screen and click the Modify button. A subset of HiveAP settings are available for configuration across the selected APs.

Optional settings include configuring the built-in captive web portal and RADIUS functions, DHCP or static IP address assignment, static layer 3 roaming neighbors (beyond the dynamically discovered Hive members), administrative security credentials for console access and CAPWAP security to HiveManager, layer 2/3 routing, VLAN tag settings (override WLAN policy), and HiveAP classification (for use in variable substitution with network objects).

Updating the HiveAP Configuration
Now that all four of the Guided Configuration sections have been completed, it's time to deploy the configuration to HiveAPs.

As a precautionary step, review the configuration audit status of the access points prior to deployment to verify accuracy of the updated configuration that will be pushed to the AP. To do this, navigate to the Monitor > HiveAPs screen, ensure the "Monitor" radio button is selected, and click the red triangle next to a HiveAP to view the configuration audit.

Viewing HiveAP configuration audit details
If satisfied with the configuration items, check the box next to every HiveAP to be updated and select the Update > Upload and Activate Configuration button. Configure the desired settings which instructs how HiveManager peforms the upload, including either a complete or delta upload and activation schedule, then click the save icon. The settings section will roll upwards, allowing the administrator click the Upload button and push the settings to the HiveAPs.

Configuring the HiveManager Upload Settings

The user will be redirected to the HiveAP Update Results screen, which will show the progress of the upload and report any issues that may occur.

Viewing HiveAP Update Results

If successful, the settings configured in HiveManager are now active on the HiveAPs and the wireless network should be fully operational.

Tuesday, April 19, 2011

Aerohive HiveManager Configuration Workflow

Now that the Aerohive HiveAPs have been provisioned so they can discover and connect to a HiveManager management server, let's dive into how HiveManager handles configuration workflow, object definition, and nesting. This will serve as a foundation to prepare us to deploy an initial configuration to our HiveAPs.

The HMOL dashboard shows a new access point is connected
Initial Configuration State
Log into the HiveManager dashboard to get started. If you're using Aerohive's cloud management service, connect to HiveManager Online (HMOL) at https://myhive.aerohive.com and login using your supplied account credentials. From the "Navigate myHive" splash page, select "HiveManager Online" to access the management console. Once there, you should see the new access point listed in the Dashboard.

Navigating over to the Monitor - HiveAPs section, you can see that the access point connection details. You can also get to this page by clicking the "Number of New APs" hyperlink from the Dashboard.

The HiveAP monitor page shows the access point connection details
On this screen, notice that the AP is currently connected (green chain-link), the connection is secured (green padlock), and it is in Portal mode which integrates directly with the Ethernet network, as opposed to a Mesh Point that uses a wireless backhaul into the network through other mesh points or a portal.

Hovering over the red triangle in the audit column displays the pop-up message telling you that no configuration has been pushed to the AP yet. The red triangle alerts administrators that the current configuration on the AP does not match the desired configuration based on HiveManager templates assigned to the AP. Two green squares in the audit column would indicate that the configuration matches the defined template and no action is necessary.

HiveManager Configuration Workflow
Before jumping into the configuration, it's important to understand the workflow used within the system to define configuration items and how items relate to one another. Many enterprise wireless vendors implement a logical nesting, or roll-up, of foundational configuration items into larger groupings / profiles which then are applied to the equipment. This allows for creation of multiple profiles and easier testing, verification, and deployment.

The HiveManager configuration workflow consists of the following configuration items, nesting relationships, and profile objects which are then assigned to individual HiveAPs:


It is readily apparent from this workflow that configuration of four main objects is required:
  1. User Profiles
  2. SSIDs
  3. WLAN Policies
  4. Managed HiveAP Settings
Now that we have an understanding of the logical workflow and object nesting within HiveManager, we are prepared to define and deploy a working configuration to our HiveAPs.

Cheers,
Andrew