Cooperative Control: Part 3 March 1, 2010
Posted by Devin Akin in : Uncategorized , trackbackCooperative Control
By utilizing cooperative control, HiveAPs cooperate with neighboring HiveAPs to support control functions such as radio resource management, Layer 2/3 roaming, client load balancing, and wireless mesh networking, eliminating the need for a centralized controller.
Cooperative control is made possible with the following self-organizing and automatically-operational cooperative control protocols:
- AMRP (Aerohive Mobility Routing Protocol) – Provides HiveAPs with the ability to perform automatic neighbor discovery, MAC-layer best-path forwarding through a wireless mesh, dynamic and stateful rerouting of traffic in the event of a failure, and predictive identity information and key distribution to neighboring HiveAPs. This provides clients with fast/secure roaming capabilities between HiveAPs while maintaining their authentication state, encryption keys, firewall sessions, and QoS enforcement settings.
- ACSP (Aerohive Channel Selection Protocol) – Used by HiveAPs to analyze the RF environment on each channel within a regulatory domain and to work in conjunction with each other to determine the best channel and power settings for wireless access and mesh. ACSP minimizes co-channel and adjacent channel interference in order to provide optimized application performance.
- DNXP (Dynamic Network Extension Protocol) – Dynamically creates tunnels on an as-needed basis between HiveAPs in different subnets, giving clients the ability to seamlessly roam between subnets while preserving their IP address settings, authentication state, encryption keys, firewall sessions, and QoS enforcement settings. Note that tunnels are not required for clients roaming among APs in the same subnet.
Cooperative control protocols allow HiveAPs to operate as a cohesive system in order to provide the mobility, security, RF control, scalability, and resiliency that are essential for supporting today’s and tomorrow’s demanding applications over a Wi-Fi infrastructure.
HiveAP Auto Discovery & Self Organization
Cooperative control simplifies the deployment of HiveAPs by enabling them to automatically discover one another and by proactively synchronizing network state. HiveAPs have the ability to discover each other, whether they see each other over a wired network or a wireless network. When HiveAPs are powered on, they start to search for both wired and wireless HiveAP neighbors, and if neighbors are found with the same hive name and shared secret, they can build AES-secured connections to each other.
Once the neighbor relationships have been established between HiveAPs in a Hive, they will run cooperative control protocols across wired and wireless links to provide fast/secure roaming, radio resource management, and resiliency. If HiveAPs discover neighboring HiveAPs that are in a different subnet, as long as the HiveAPs are configured with same hive name and hive shared secret settings, they will exchange IP information with each other and establish communications over the routed network infrastructure to provide cooperative control functionality across layer 3 boundaries. The beauty of cooperative control protocols is that they do not need to be configured, greatly decreasing the operational cost and complexity of deploying a modern wireless solution.
Roaming Issues with Autonomous APs
Fast/secure roaming is most often defined as roaming that occurs in just a few tens of milliseconds. Fast/secure roaming becomes very important when using real-time applications like voice and video, where an interruption in a connection can cause dead air, pops, or even dropped sessions.
With traditional autonomous APs that exist without knowledge of each other, fast/secure roaming using IEEE 802.1X/EAP for authentication is not possible. This is because during authentication, the RADIUS server, wireless client, and AP exchange user authentication information and derive encryption keys between themselves. If the wireless client moves to another AP, the new AP does not have any of the keys that were created on the previous AP, and so the wireless client will have to repeat the entire authentication and key derivation process again. During this process, existing sessions on the client that are time sensitive will be terminated, such as voice, video, or file transfers.
Diagram 3. Autonomous APs – No Fast/Secure Roaming with 802.1X/EAP
Aerohive Networks has solved the problem that exists with autonomous AP solutions using AMRP. Whether connected via the wired LAN or wireless mesh, HiveAPs cooperate with each other using AMRP to predicatively exchange client authentication state, identity information, and encryption key information with neighboring HiveAPs, allowing clients to perform fast/secure roaming. The following diagram lists the steps taken by the HiveAPs for fast/secure roaming.
Diagram 4. HiveAPs – Authentication, Key Derivation, and Key Distribution
Step 1 – After a wireless client successfully authenticates with a RADIUS server using 802.1X/EAP authentication, the information exchanged between the RADIUS server and the client is used to derive a key called the pairwise master key (PMK). This PMK is the same on the wireless client and RADIUS server.
Step 2 – The RADIUS server transfers the PMK to the HiveAP so that the client and HiveAP can build an encrypted connection between each other.
Step 3 – Using AMRP, the HiveAP proactively distributes encryption keys, identity information, SIP voice session state information, firewall, and QoS policy information to all neighboring HiveAPs. This, along with the de facto standard Opportunistic Key Caching (OKC), permits clients to roam between HiveAPs without having to repeat the 802.1X/EAP authentication process, enabling fast/secure roaming.
Note: For security reasons, the key and identity information sent between HiveAPs is encrypted with AES and is stored only in memory on the HiveAP. This way, the keys are removed from the system with all user identity information when a HiveAP is powered off. Furthermore, administrators do not have access to view the keys. These security measures prevent the keys from being obtained if the wired network is analyzed or if a HiveAP is stolen.
Along with the key information that is distributed among neighboring HiveAPs, AMRP also distributes the user’s identity information so that HiveAPs can enforce the identity-based firewall access policies and QoS settings as the user roams between HiveAPs.
Comments»
Does this not mean that every hive ap has to be added as a radius client in the radius server. And that would mean the hive aps have to be statically IP addressed.
Ms MSFT
Excellent question. You simply add one or more subnet ranges (as small or as large as you like) into your RADIUS server that includes the HiveAPs. It’s the same as adding single IPs for controllers or adding a subnet range for a group of controllers. Piece of cake.