Aerohive whitepaper-cooperative control WLAN

Cooperative Control Wireless LAN Architecture

Version 3.5

solution brief

Reseller contact:[email protected]://www.altaware.comPhone: 949-484-4125

2 Copyright © 2011, Aerohive Networks, Inc.

Table of Contents Introduction ........................................................................................................................................... 4

Cooperative Control® Architecture ............................................................................................... 4

Centralized Management, Distributed Control, and Distributed Forwarding ........................... 5

Key Concepts and Naming Conventions ..................................................................................... 7

Cooperative Control ............................................................................................................................. 8

HiveAP Auto Discovery & Self Organization .................................................................................. 9

Roaming Issues with Autonomous APs ........................................................................................... 9

Fast/Secure Layer 3 Roaming ....................................................................................................... 11

Tunnel Load Balancing in Large Scale Layer 3 Roaming Environments .................................. 13

Radio Resource Management (RRM) .......................................................................................... 13

Station Load Balancing .................................................................................................................. 13

Policy Enforcement at the Edge ........................................................................................................ 14

User Profiles and Identity-Based Policy ......................................................................................... 14

QoS at the Edge ............................................................................................................................. 15

QoS with Dynamic Airtime Scheduling ........................................................................................ 17

Service Level Agreements (SLAs) and Airtime Boost .................................................................. 20

HiveAP Security and Theft Protection ........................................................................................... 21

Wireless Intrusion Protection System (WIPS) - Rogue AP and Client Prevention ...................... 22

Voice- and Video-aware WIPS Scanning .................................................................................... 23

Integrated Protocol Analyzer Integration and Client Monitoring ............................................. 24

3rd Party WIPS and Protocol Analyzer Integration ....................................................................... 25

Wireless Decryption at the HiveAP Allows Advanced Security at the Edge ........................... 26

RADIUS Server Built into HiveAPs .................................................................................................... 27

Built-in Captive Web Portal ............................................................................................................ 27

Identity-Based Tunnels .................................................................................................................... 28

Guest Access Policy Enforcement at the Edge .......................................................................... 29

Private Preshared Key (PPSK) Security .......................................................................................... 30

Virtual Private Networking (VPN) .................................................................................................. 32

Best Path Forwarding and Wireless Mesh ......................................................................................... 34

Wireless Mesh .................................................................................................................................. 34

Scalable, Layer-2 Routing and Optimal Path Selection ............................................................ 36

Scalability with Best Path Forwarding ........................................................................................... 37

Cooperative Control WLAN Architecture

Copyright © 2011, Aerohive Networks, Inc. 3

High Availability .................................................................................................................................. 37

No Single Point of Failure ............................................................................................................... 37

Smart Power-over-Ethernet (PoE) ................................................................................................. 37

Redundant and Aggregate Links ................................................................................................. 38

Self Healing by Dynamically Routing Around Failures ................................................................ 38

Dynamic Mesh Failover .................................................................................................................. 39

AAA Credential Caching .............................................................................................................. 40

Centralized WLAN Management ....................................................................................................... 40

Simple, Scalable Management with the HiveManager WNMS ................................................ 40

Versions of HiveManager ............................................................................................................... 41

HiveManager Components and Communication ........................................................................... 42

Simplified Configuration Management ....................................................................................... 43

Zero Configuration for Access Point Deployments ..................................................................... 44

Auto-Provisioning ............................................................................................................................ 44

Simplified Monitoring, Troubleshooting, and Reporting ............................................................. 44

HiveAP Classification for Adaptive WLAN Policy Configuration ............................................... 46

Guest Manager ................................................................................................................................... 48

Role-based Guest Administration ................................................................................................. 48

Guest Access with GuestManager ............................................................................................... 49

Guest Account Creation and Management .............................................................................. 49

Credentials ...................................................................................................................................... 50

Single Centralized Instance for Guest Authentication ............................................................... 50

Delivered as an Appliance ........................................................................................................... 50

Conclusion ........................................................................................................................................... 51


Introduction

The first generation of WLANs were autonomous (standalone) access points and were relatively simple to deploy, but they lacked the manageability, mobility, and security features that enterprises required, even for convenience networks. Then centralized, controller-based architectures emerged to address these issues and others such as fast/secure roaming for mobile devices, radio resource management (RRM), and per-user or per-device security policies. Unfortunately, they also introduced opaque overlay networks, performance bottlenecks, single points of failure, increased latency, and substantially higher costs to enterprise networks. As Wi-Fi is increasingly embraced as a critical part of the enterprise network and enterprises deploy demanding applications (e.g. voice and video) over an extremely high-speed Wi-Fi infrastructure, the consequences of this movement are magnified and are leading the industry to reexamine the validity of today’s centralized WLAN architecture. Aerohive Networks has responded by pioneering a new WLAN architecture called the Cooperative Control architecture. It is a controller-less architecture that eliminates the downsides of controllers while providing the management, mobility, scalability, resiliency, and security that enterprises require in their wireless infrastructure.

Cooperative Control® Architecture

Aerohive Networks has developed an innovative new class of wireless infrastructure equipment called a Cooperative Control Access Point (CC-AP). A CC-AP combines an enterprise-class access point with a suite of cooperative control protocols and functions to provide all of the benefits of a controller-based WLAN solution, but without requiring a controller or an overlay network. Aerohive Networks’ implementation of a CC-AP is called a HiveAP. This cooperative control functionality enables multiple HiveAPs to be organized into groups, called “Hives,” that share control information between HiveAPs and enable functions like fast/secure layer 2/3 roaming, coordinated radio channel and power management, security, quality-of-service (QoS), and native mesh networking. This information sharing capability enables a next generation WLAN architecture – the cooperative control architecture – that provides all of the benefits of a controller-based architecture, but is easier to deploy and expand, lower cost, more reliable, more scalable, more ubiquitously deployable, higher performing, and more suitable for demanding applications such as voice and video than controller-based architectures. The diagram that follows outlines the building blocks of the cooperative control architecture. It is implemented using two types of products:

• Cooperative Control Access Points (HiveAPs) that have dual radios that support simultaneous use of the 2.4 GHz and 5 GHz spectrums for wireless access and/or wireless mesh connectivity. HiveAPs implement robust security such as: WPA/WPA2-Enterprise, WPA/WPA2-Person, de facto standards such as Opportunistic Key Caching, Private PSK, integrated WIPS, stateful firewall policies, and L2-L4 denial-of-service (DoS) prevention. Each HiveAP’s SLA capabilities are based on advanced QoS policies, Dynamic Airtime Scheduling, and Airtime Boost capabilities using an easily-configured management application. A single radio HiveAP is also available.



• A central management platform (HiveManager) that provides centralized user policy management and simplified HiveAP configuration, firmware updates, monitoring, and troubleshooting. HiveManager is available in many flavors, including 1U and 2U appliances, a virtual appliance (virtual machine), and a SaaS delivery option called HiveManager Online.

The architecture is supported by three distinct, but tightly-interrelated technology building blocks:

• Cooperative control: a set of control-plane protocols that provides dynamic layer 2 (MAC-based) routing, automatic radio channel and power selection, and fast/secure roaming without requiring controllers.

• Policy enforcement at the edge: the ability to enforce granular, user-based QoS,

security, and access policies at the edge of the network where the user connects.

• Best-path forwarding: scalable wired/wireless mesh routing protocols allow traffic

to be securely forwarded via the highest performance and most available path in the network. This includes both the ability to fail back when failed links are reestablished and to dynamically transition access radios into mesh backhaul mode as policy dictates.

Centralized Management, Distributed Control, and Distributed Forwarding

Diagram 1. Building Blocks of Cooperative Control Architecture


In order to better appreciate the Aerohive Networks cooperative control architecture, it is important to understand the three major functional areas, or logical network planes, that can be used to describe how network architecture operates: the management plane, the control plane, and the data plane. By comparing the logical network planes of the most common networking devices – such as routers and switches – with that of HiveAPs, you can see striking similarities. For example: • They all have the ability to use a centralized management platform for configuration,

monitoring, and troubleshooting, and because the management platform itself is not in the data path, it can be taken offline without affecting the functionality of the network.

• Each class of network device implements a distributed control plane that uses control protocols (e.g. OSPF, spanning tree, etc.) to share information between devices that allows them to coordinate with each other to ensure the network functions properly and continuously adapts to changes. With this knowledge of network state provided by the distributed control plane, each individual device is then able to implement a distributed data plane allowing each one to quickly make decisions on how traffic should be processed and forwarded using the optimal path.

This architecture has proven to be the winning architecture for switched and routed networks for many years because it is scalable, high performance, and resilient while still allowing for central management. As an example, the Internet uses this architecture. Many enterprise WLANs today are implemented with a centralized controller-based architecture that breaks from this proven network architecture by centralizing the control plane and data plane in a controller hardware platform, which compromises scalability and resilience. Aerohive’s cooperative control architecture is the first architecture to bring these proven network benefits to WLANs. The following chart shows the architectural parallels between cooperative control and the proven architecture used in switched and routed networks. Logical Network Planes Routers Switches HiveAPs

Management Plane Responsible for configuration, monitoring, and troubleshooting

Centralized – Using an NMS platform

Centralized – Using an NMS platform

Centralized – Using HiveManager, a centralized WNMS platform

Control Plane Responsible for making forwarding decisions and programming the data plane

Distributed – Using Protocols (OSPF, RIP, BGP, etc.) to determine how traffic should be forwarded

Distributed – Using Protocols such as spanning tree protocol (STP) to avoid loops and MAC address learning to determine where traffic should go

Distributed – Using Aerohive Cooperative Control Protocols (AMRP, ACSP, DNXP, INXP) for dynamic RRM, fast/secure L2/L3 roaming, identity-based tunnels, and for determining how traffic should be forwarded

Data Plane Responsible for processing and forwarding data

Distributed – Processed and forwarded by each router

Distributed – Processed and forwarded by each switch

Distributed – Processed and forwarded by each HiveAP

Extending the proven architecture used in switched and routed infrastructures to WLANs through the use of distributed control and data planes is especially important as



enterprises require greater levels of availability, increased performance with 802.11n, and seek to improve productivity in their regional and branch offices. Distributing the control and data planes (e.g., removing controllers) eliminates single points of failure and performance bottlenecks from the entire wireless network, allowing the remote site deployment to be as simple and as functional as the campus deployment.

Key Concepts and Naming Conventions

The diagram below shows that HiveAPs have different roles which are automatically designated based on how they are connected to the network. The following is a list of key terms used to describe the Aerohive Networks cooperative control architecture: • HiveAP®: The product brand name for Aerohive’s CC-AP (Cooperative Control

Access Point). HiveAPs coordinate with each other using cooperative control protocols to provide critical functions including seamless mobility, automatic radio resource management (RRM), policy-based security, and best-path forwarding.

• HiveOS®: The firmware developed by Aerohive Networks that runs on HiveAPs. • HiveManager®: A centralized wireless network management system (WNMS) that

enables sophisticated identity-based policy management, simplistic device configuration, HiveOS updates, and monitoring and troubleshooting of HiveAPs within a cooperative control WLAN infrastructure. HiveManager is available as an appliance, a virtual appliance, or a SaaS offering called HiveManager Online™.

• Hive: A Hive is a group of HiveAPs that share a common name and secret key that permit them to securely communicate with each other using cooperative control protocols. Within a Hive, clients can seamlessly roam among HiveAPs across layer 2 and layer 3 boundaries, while preserving their security state, QoS settings, IP settings, and data connections.

• GuestManager™: A guest management platform that provides a simple web interface for allowing administrators, such as receptionists or lobby ambassadors, to create temporary user accounts that provide guests with access to the wireless network.

• Wired Backhaul Link: An Ethernet connection from a HiveAP to the primary wired network, typically called the distribution system (DS) in wireless standards, which is used to bridge traffic between the wireless and wired LANs.

• Wireless Backhaul Link: Wireless connections between HiveAPs that are used to create a wireless mesh and to provide wireless connections that transport primarily control and data traffic.

• Bridge Link: An Ethernet connection from a HiveAP that allows a wired device or network segment to be bridged over the WLAN onto the primary wired LAN.

• Wireless Access Link: The wireless connection between a wireless client and a HiveAP.

• Portal: A HiveAP that is directly connected to the wired LAN via Ethernet that provides default MAC routes to mesh points within the Hive. This role is dynamically chosen. If the wired link is unplugged, then the HiveAP can dynamically become a mesh point.

• Mesh Point: A HiveAP that is connected to the Hive via wireless backhaul links and does not use a wired link for backhaul. This role is also dynamically chosen. If a wired link is plugged in, the HiveAP dynamically becomes a portal, if permitted by the configuration.

• Cooperative Control Signaling: The control-plane communication between HiveAPs using Cooperative Control Protocols


Cooperative 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,

Diagram 2. Aerohive Networks Naming Conventions



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.

Fast/Secure Layer 3 Roaming

Mobility in typical IP networks is challenging because, as a user moves from subnet to subnet, their IP settings change, which usually makes IP-based sessions or applications fail. To allow users to maintain their IP settings and network connections while roaming across subnets throughout a WLAN, Aerohive has developed the Dynamic Network Extension Protocol (DNXP). At the time a user roams to an AP that is located in a different subnet, DNXP will dynamically establish a tunnel from the new AP back to an AP in the subnet the user roamed from. The user’s traffic is tunneled back to its original subnet, which allows clients to preserve their IP address settings, authentication state, encryption keys, firewall sessions, and QoS enforcement settings as they roam across HiveAPs in different subnets. This is especially important for clients using voice and video applications. When layer 3 roaming is enabled, HiveAPs can automatically discover their layer 3 neighbors (neighboring HiveAPs on different subnets) by scanning radio channels. If HiveAPs are within radio range of each other, are in the same hive, have layer 3 roaming enabled, and are in different IP networks, the HiveAPs will build layer 3 neighbor relationships with each other over the routed Ethernet network. HiveAPs will then distribute tunnel and client information to their layer 3 neighbors. This way, when the user roams across layer 3 boundaries, the tunnels can be built without delay. In situations where HiveAPs cannot discover each other automatically over the air, possibly due to being on opposite sides of an RF obstacle, you can manually configure layer 3 neighbors for HiveAPs using HiveManager.


When layer 3 neighbors are discovered, either automatically or manually, HiveAPs in different subnets will exchange lists of available HiveAP portals and client and roaming cache information. This way, if a client does roam to a new subnet, the HiveAP in the new subnet will be aware of the client and can dynamically build a tunnel back to any one of the portal HiveAPs in the previous subnet. This allows for fast/secure layer 3 roaming. The following diagram shows the basic steps performed by HiveAPs as clients roam within their subnet and across subnet boundaries.

Step 1 – The client performs seamless, fast/secure layer 2 roaming within subnet A. Step 2 – After the client successfully roams to HiveAP 2, HiveAP 2 will send an encrypted control packet over the Ethernet infrastructure to HiveAP neighbors in the neighboring subnet. The control packet contains, as a minimum, the client’s identity, security and QoS information, SIP call state, and the client’s originating subnet. Step 3 – Because the client’s identity and key information, including SIP call state, is proactively synchronized between neighboring HiveAPs, when the client roams to HiveAP3, HiveAP3 has all the information it needs to enforce policies and to tunnel permitted traffic, over the GRE tunnel, to a portal HiveAP in the client’s original subnet. This behavior allows the client to maintain its IP address and active sessions as it roams. Predictively, HiveAP3 forwards the wireless client’s roaming information to HiveAP4 in anticipation of any further roaming.

The ability for a client to maintain its IP, QoS, firewall, and security settings while roaming across subnet boundaries ensures that client application sessions do not get dropped while roaming. Based on a configurable idle time or number of packets per minute, HiveAPs can be set to disassociate these wireless clients so that they can reconnect and receive an IP address in their new subnet allowing traffic to be locally forwarded. If a client roams across subnet boundaries when it does not have any active sessions in

Diagram 5. The Process for Fast/Secure Layer 3 Roaming



process, it can be immediately transitioned to the new subnet, eliminating the need to tunnel traffic. In summary, with HiveAPs and cooperative control, wireless clients have the ability to perform fast/secure roaming between HiveAPs within the same or between different subnets without impacting client data or voice connections.

Tunnel Load Balancing in Large Scale Layer 3 Roaming Environments

Aerohive’s layer 3 roaming feature provides unprecedented scalability by using tunnel load balancing to distribute tunnels across all portal HiveAPs within a subnet. This leverages the distributed processing power of the wireless network to support thousands of layer 3 roaming tunnels and multiple gigabits of cross subnet throughput. When a HiveAP in a remote subnet attempts to establish a tunnel to a HiveAP in the original subnet, in the very rare case that the HiveAP in the original subnet has high tunnel load, it can inform the HiveAP in the remote subnet to tunnel to another portal HiveAP in the subnet. This prevents any single HiveAP from being over-utilized.

Radio Resource Management (RRM)

To respond to changes in the RF environment, HiveAPs use Aerohive Channel Selection Protocol (ACSP). ACSP allows HiveAPs to cooperate in order to to automatically select the best channels and power settings on which to operate for optimal network performance across an entire system. HiveAPs use ACSP to scan channels and to build tables of discovered wireless devices. These tables, along with additional RF information such as channel utilization and retry counters, are used to identify and classify interference types and sources. HiveAPs communicate ACSP state information with each other and use this information to select the appropriate channels and power levels for the network topology and configuration. For each radio in access mode, ACSP will select a channel and power level to maximize coverage while minimizing interference with its neighbors. This is accomplished by ensuring that HiveAPs use different channels than their immediate neighbors, and that they adjust their power to minimize co-channel interference with other, more distant, HiveAPs. For radios in backhaul (mesh) mode, ACSP ensures that that they use the same channel throughout the mesh, while still minimizing interference with the access links. To maintain optimal performance, ACSP constantly checks the radio power settings and can automatically decrease radio power based on communication from neighboring APs to give the maximum coverage possible while minimizing interference. This behavior is highly beneficial in a failure state or when an AP is taken off line, where neighboring APs can automatically adjust their power to the optimum state, essentially taking into account the missing AP. ACSP can also be scheduled to recalibrate the radio channels during a configurable daily time window and when a specified number of clients are associated. This helps ensure that radio channels do not switch while the WLAN is being utilized, preventing a disruption of service for wireless clients.

Station Load Balancing

Many times in a wireless network, many users will unknowingly be connected to the same AP, or even the same radio on the same AP, while neighboring APs may be under-utilized. This can have a significant impact on client performance and may cause the


users to have an unsatisfactory experience. It is logical, therefore, that clients be encouraged to move from the more heavily-loaded APs to the lightly-loaded ones. To aid in the distribution of clients among HiveAPs in a cooperative control infrastructure, Aerohive has implemented station load balancing. HiveAP load is determined, as a minimum, by:

1) the overall load of the system 2) the load in a specific area on a specific channel 3) the voice traffic load of attached stations 4) the total number of attached stations 5) the signal quality of attached stations

HiveAPs can make decisions to offload stations from one radio to another within the same HiveAP (Bandsteering) based on client capabilities and/or to offload stations to a HiveAP that is better suited to handle the load in the immediate area. Transitioning clients between radios and between APs is done without breaking the application session. Use of admission control can prevent over-utilization by ensuring there is enough headroom for stations that roam to the HiveAP. It also prevents overloading a single HiveAP, especially when there are other HiveAPs nearby that can better handle the load. This is useful with VoWiFi, because it helps ensure that a HiveAP has availability to support new or roaming voice stations, and that there is enough airtime available for excellent voice quality.

Policy Enforcement at the Edge

Utilizing Policy Enforcement at the Edge, a key technology in Aerohive Networks’ cooperative control architecture, HiveAPs can enforce powerful and flexible identity-based security, access control, and QoS policies at the edge of the network. Applying those policies to traffic at the local HiveAP allows the denial-of-service (DoS) and firewall engines to validate traffic at the point of entry before it is forwarded through the HiveAP. Likewise, it allows QoS engines in the HiveAP to instantaneously respond to the real-time variations (measured in microseconds) in wireless throughput inherent to a dynamic RF environment. Enforcing policy at the edge provides substantially better control than solutions that enforce policy multiple hops, and several milliseconds away on a centralized controller.

User Profiles and Identity-Based Policy

The Aerohive solution defines different sets of access policies for different classes of users through the creation of user profiles (a set of connectivity parameters). Each user profile defines a VLAN, QoS policy, MAC firewall policy, IP firewall policy, tunnel policy, and layer 3 roaming policy, which is assigned to users when they connect to the WLAN.

On a HiveAP, user profile attributes (numbers associated with a set of connectivity parameters) are used to identify a user profile. If a user authenticates with the HiveAP using 802.1X/EAP authentication or MAC address authentication, the RADIUS server can return a user profile attribute to the HiveAP, which binds the user to a user profile. The user profile attribute returned by RADIUS can be defined based on the user’s group



settings in Active Directory, eDirectory, OpenDirectory, LDAP, or a RADIUS user group, user, or realm. If the user does not use 802.1X/EAP or MAC address authentication, the user profile can be assigned to the user based on the SSID’s default user profile attribute setting. The user profile attribute assigned to a user stays with the user as he/she roams throughout the WLAN. Administrators can configure HiveAPs to use the same set of policies for a user profile throughout a WLAN or they can make adjustments based on specific HiveAPs. For example, clients associating to the same SSID in different locations can be assigned to different VLANs and subnets. As a user roams between the two locations, the attribute is used by the HiveAPs to identify the set of policies for the client at the new location including: VLAN, firewall policy, QoS policy, and layer 3 roaming policy. Depending on the policies in place for each location, the client’s traffic can be tunneled back to a HiveAP in the client’s original location (if it’s on a different subnet), which is useful for seamlessly maintaining active IP sessions, or the client can forced to obtain new IP settings for the VLAN in the new location.

QoS at the Edge

Any time you transmit data from a higher speed network, such as an Ethernet network, to a lower speed network, such as a WLAN, there is a high potential for packet loss and performance degradation. Think of traffic from a five lane highway that narrows down to a two lane road, and imagine how an emergency vehicle, such as an ambulance, would get through that traffic on a busy day. Advanced QoS techniques are required in order to ensure optimal performance for high-priority applications, such as voice and video, without adversely affecting the performance of lower-priority traffic such as web-based applications and email, when traffic is sent from the wired network to the WLAN. Each HiveAP has a sophisticated and granular QoS engine, which provides linear and unlimited scalability of QoS services across the WLAN system. Most modern WLAN systems support the Wi-Fi Alliance WMM certification for QoS, which was based on the IEEE 802.11e amendment. With WMM, traffic can be classified into one of four access categories (ACs), which are bound to queues, for transmission onto the wireless network. Higher-priority ACs have different (better) arbitration values than lower-priority ACs, so higher-priority traffic experiences less delay in transitioning from queue to wireless medium.

Though WMM does a reasonable job of ensuring that each traffic type gets an appropriate amount of access to the wireless medium, if voice and video (high-priority) traffic are being used on the WLAN, it is likely that there will be momentary periods of congestion for lower priority queues. When queues get full, even momentarily, packets get dropped. Dropped packets may not sound like a big deal, especially if they use TCP (since they will be retransmitted); however, because TCP uses a built-in congestion avoidance algorithm that cuts TCP window sizes in half when a packet is dropped, TCP performance can be severely affected by L2 frames that are dropped. Though applications classified in the higher-priority queues may not be affected, applications in lower-priority queues including email, database, accounting, inventory, workforce automation, or SaaS applications may suffer significantly. By using advanced QoS techniques to augment


WMM, it is possible to mitigate L2 frame loss and to ensure higher performance for lower-priority applications as well.

In order to provide highly-efficient voice and video transmission and to alleviate the problems that occur when packets are dropped because of momentary congestion of WMM queues, Aerohive has augmented WMM by implementing advanced classification, policing (rate limiting), queuing, and packet scheduling mechanisms within each HiveAP. The following diagram shows a simple example and workflow of the QoS engines within a HiveAP.

Diagram 6 shows an example of how traffic arriving from the wired LAN is processed by a HiveAP to ensure highly-effective QoS to the WLAN. Step 1 –Traffic is sent from the wired LAN to a HiveAP Step 2 –When packets arrive from an Ethernet uplink, a wireless uplink, or an access connection, the traffic is assigned to its appropriate user profile, which defines the QoS policy.

Diagram 6. QoS Policy Enforcement at the Edge – Downlink Example



Step 3 –The QoS packet classifier categorizes traffic into eight queues per user based on QoS classification policies. Classification policies can be configured to map traffic to queues based on MAC OUI (Organization Unique Identifier), network service, SSID and interface, or priority markings on incoming packets using IEEE 802.1p or DSCP (DiffServ Code Point).

Step 4 –The QoS traffic policer can then enforce QoS policy by performing rate-limiting and marking. Traffic can be rate-limited per user profile, per user, and per user queue.

Step 5 –The marker is responsible for marking packets with DSCP and/or 802.11e for traffic destined to the WLAN and with DSCP and/or 802.1p for traffic destined for the wired LAN. Step 6 –Traffic to the WLAN is queued in eight queues per user and waits to be scheduled for transmission by the scheduler.

Step 7 –The QoS packet scheduling engine uses two scheduling types for determining how packets are sent from the user queues to the WMM hardware queues for transmission onto the wireless medium.

• Strict priority – Packets in queues that are scheduled with strict priority are sent ahead of packets in all other queues. Strict priority is typically configured for user queues that are assigned to low latency traffic such as voice.

• Weighted round robin – The scheduler can allocate the amount of airtime or bandwidth that can be transmitted by the user of a wireless client device based on weights specified for a user profile, individual users within a user profile, and the eight queues per user. Based on weighted preferences, the scheduler moves packets from the individual user queues to the appropriate WMM access categories for transmission onto the wireless network.

Because a QoS packet scheduling engine is built into every HiveAP, HiveAPs have the ability to closely monitor the availability of the WMM access categories and to instantly react to changing network conditions. The QoS packet scheduling engine only transmits to WMM access categories when they are available, queuing packets in eight queues per user in the meantime. This behavior prevents dropped packets and jitter, which adversely affect time-sensitive applications such as voice. It also prevents TCP performance degradation caused by contention window back-off algorithms that are invoked when TCP packets are dropped.

Step 8 –Finally, WMM functionality transmits L2 frames from its four access categories based on the availability of the wireless medium. Packets from higher-priority access categories are transmitted with a smaller random back-off window to allow transmission onto the wireless medium with less delay.

QoS with Dynamic Airtime Scheduling

In WLANs, wireless performance can vary significantly based on the RF environment. WLANs are a shared medium, which means that all clients and neighboring APs using the same or overlapping channel(s) compete for the same bandwidth. In addition, each client’s data rate set varies depending on the Physical Layer Specification (PHY) it is using (802.11 a/b/g/n), signal strength, and interference and noise it is experiencing. Use of low-speed PHYs, RF interference, inconsistent RF coverage, connecting at the fringe of


the network, and moving behind obstructions all contribute to low data rate connections. Slow clients consume more airtime to transfer a given amount of data, leaving less airtime for other clients, which decreases network capacity and significantly degrades the performance of all clients on the network. By enabling Aerohive’s new patent-pending wireless Quality of Service (QoS) technology –Dynamic Airtime Scheduling - these problems are solved. The benefits of Dynamic Airtime Scheduling are compelling both to the IT organization and to the users of the WLAN, as it enables clients connected at higher data rates, in a mixed data rate environment, to achieve up to 10 times more throughput than they would get with traditional WLAN infrastructures - without penalizing low-speed clients. This means that users see faster download times and improved application performance, and it means that low-speed clients don’t destroy the performance of the WLAN for the rest of the users. This allows IT to implement a phased upgrade to 802.11n and immediately reap the benefits of the new 802.11n infrastructure, even if it takes years to upgrade all of the clients. And, because a user connecting at the fringe of the WLAN can no longer consume all of the airtime, the network impact of a bad client or a weak coverage area is diminished. This allows IT to reduce their infrastructure investment, saving IT time and increasing user satisfaction. With bandwidth-based QoS scheduling, the AP calculates the bandwidth used by clients based on the size and number of frames transmitted to or from a client. Bandwidth-based scheduling does not take into account the time it takes for a frame to be transmitted over the air. Clients connected at different data rates take different amounts of airtime to transmit the same amount of data. By enabling Dynamic Airtime Scheduling, the scheduler allocates airtime, instead of bandwidth, to each type of user, user profile, and user queue, which can be given weighted preferences based on QoS policy settings. When traffic is transmitted to or from a client, the HiveAP calculates the airtime utilization based on intricate knowledge of the clients, user queues, per-packet client data rates, and frame transmission times, ensuring that the appropriate amount of airtime is provided to clients based on their QoS policy settings. Dynamic Airtime Scheduling is made possible because it is performed directly on the HiveAPs responsible for processing the wireless frames. This gives the scheduling engine access to all the information needed, in real time (at the microsecond level), allowing the HiveAP to react to instantaneous changes in client airtime utilization that occur when the client is moving. Managing airtime usage is critical and needs to be dynamically scheduled because it affects all clients within the cell and varies drastically by client, based on distance from the AP, PHY being used, signal strength, interference, and error rates. With Dynamic Airtime Scheduling, airtime can be dynamically scheduled to increase aggregate network and client performance and to allocate network capacity based on IT-specified policies. To demonstrate the advantages of Dynamic Airtime Scheduling, a series of tests have been run and documented in the Aerohive whitepaper: Optimizing Network and Client Performance Through Dynamic Airtime Scheduling. The following test, which is an excerpt from the whitepaper, simulates a typical WLAN’s transition to 802.11n – where 802.11n APs are servicing a mixture of 802.11n clients and legacy (a/b/g) clients. These tests show how Dynamic Airtime Scheduling prevents a



high performance 802.11n WLAN from being hampered by clients connected at lower data rates – even if some of those slow clients are slow 802.11n clients. Depending on distance from the AP, position of the antenna, or even RF interference, the data rate of a connected 802.11n client can range from 6.5 to 300 Mbps (depending on supported features), so some 802.11n clients will be slower than other 802.11n clients. It is even possible that some 802.11n clients could actually be slower than 802.11a/g clients. To simulate a mixed 11n/a environment, we connect three 802.11n clients at 3 different rates on the 5 GHz radio band of an AP. The rates used for the 802.11n clients are 270 Mbps, 108 Mbps, and 54 Mbps (with frame aggregation enabled for 802.11n-only data rates). Simultaneously we connect three 802.11a clients at 54 Mbps, 12 Mbps, and 6 Mbps. This simulates a mixed-PHY environment where six clients, 3 of each type, are connected to the same AP but at varying distances or interference levels, which cause the data rate to vary. These tests transfer 10,000 good 1500-byte HTTP packets for each client. The graph to the left shows the results without airtime scheduling. In this test, each of the clients, though connected at different data rates, has the same throughput as the client at the lowest rate, which in this case is 6 Mbps. The time it takes all 6 clients to finish transferring 10,000 HTTP packets is between 90 and 110 seconds.

The graph to the right shows the same test with a HiveAP using Aerohive’s Dynamic Airtime Scheduling. The transfer time at the 270 Mbps data rate is approximately 10 seconds – about 10 times faster than the 110 seconds seen in the previous test. Likewise, the rest of the transfer times improved significantly. The 802.11n client at 108 Mbps was over 6 times faster, the 802.11n client at 54 Mbps was over 3 times faster, the 802.11a client at 54 Mbps was 2.5 times faster, the 802.11a client at 12 Mbps was 30% faster, and the 802.11n client at 6 Mbps decreased slightly (10%). With Dynamic Airtime Scheduling, network performance is dramatically improved for individual clients and for the network as a whole. All of the high data rate clients saw substantial improvements in performance, while the slower clients saw almost no negative impact. In an open air network, the effects of the performance gain will even be higher. Once the high-speed clients finish, fewer clients are on the air, so contention and retries decrease leading to performance increases.

Diagram 7. Side-by-side comparison with and without Dynamic Airtime Scheduling


Service Level Agreements (SLAs) and Airtime Boost

Dynamic Airtime Scheduling gives HiveAPs a platform on which to build additional capabilities. Such capabilities currently include Performance Sentinel, SLA, and Airtime Boost. Performance Sentinel is a feature that compares client throughput and demand with pre-defined SLA throughput levels. It uses client data statistics to determine client throughput and uses buffer statistics in the HiveAP’s QoS engine to determine if a client is trying to send more data. SLAs are easily configured within a user profile, as shown below.

If, for any reason, SLAs are not being met, actions can be taken, such as logging or use of the Airtime Boost feature. Airtime Boost is a feature that works in concert with Dynamic Airtime Scheduling that provides additional airtime to a client that is not meeting its SLA.

Diagram 9. SLA with Airtime Boost

Diagram 8. SLA Parameter Configuration



The ability to assign and guarantee specific levels of throughput to individual users or groups of users within a Wi-Fi network is another significant step, pioneered by Aerohive Networks, toward making a Wi-Fi network as deterministic as Ethernet.

HiveAP Security and Theft Protection

Unlike firewalls, routers, and switches, which are typically locked away in a wiring closet, APs are usually mounted on ceilings, above ceiling tiles, on walls, and in other publicly-accessible locations. Because of this, Aerohive has developed mechanisms to prevent secure information from being obtained from HiveAPs and to prevent HiveAPs from functioning in the event of a HiveAP theft. • Encrypted Configuration File

If a malicious user were to steal a HiveAP and then open it up and remove the flash drive, the configuration of the HiveAP is encrypted and unreadable.

• Encrypted and/or Hashed Passwords and Shared Keys in Command Line Interface If the bootstrap configuration is not set or if someone knows the admin name and password and is able to gain access to the HiveOS command line interface, all passwords and shared keys are hashed and/or encrypted so they cannot be obtained.

• Secure Trusted Platform Module (TPM) device in HiveAP 300 series The HiveAP 300 series HiveAPs are equipped with an integrated TPM chip, which is a standards-based hardware device that provides capabilities for secure storage of sensitive data. HiveAPs use the TPM chip to securely store cryptographic keys for encrypting and decrypting the configuration file, shared secrets, and user databases stored in flash, ensuring they cannot be viewed or altered.

• 802.1X/EAP Dynamically-Generated Keys Are Removed When A HiveAP Is Powered

Off All dynamically-generated keys, such as keys used by 802.1X/EAP authenticated clients, which includes PMKs (Pairwise Master Key) and PTKs (Pairwise Transient Keys), are securely stored in memory and are not accessible via the command line interface. Once the HiveAP is powered off, the keys are wiped from memory.

• HiveAP RADIUS Users Stored in DRAM Are Removed When HiveAP is Powered Off If the HiveAP is configured as a RADIUS server and uses a local user database, this database can optionally be stored in DRAM, which is cleared when a HiveAP is powered off or rebooted.

• Bootstrap Configuration If the hardware reset button functionality is enabled, you can set a bootstrap configuration on a HiveAP so that when the HiveAP boots, after a hardware reset, it will be configured with:

– A strong admin name and password for serial console or SSH access; – disabled wireless interfaces; – disabled console access; – and optionally disabled Ethernet interfaces.


Note that if you do configure the bootstrap to disable console access, wireless interfaces, and Ethernet interfaces, the HiveAP will essentially become a paperweight in the event it is stolen. In the unlikely and unfortunate event that a HiveAP is ever stolen, Aerohive has provided these security mechanisms to prevent loss of secure data and to prevent the misuse of the HiveAP.

Wireless Intrusion Protection System (WIPS) - Rogue AP and Client Prevention

Using WIPS functionality, each HiveAP has the ability to perform off-channel scanning to identify and locate unauthorized (rogue) APs and clients, as well as misbehaving clients, and report them to HiveManager. Administrators can configure rogue AP detection/prevention policies that look for APs that have invalid BSSIDs, SSIDs, authentication and encryption settings, and other incorrect configuration parameters. Along with searching for rogue APs over the airwaves, HiveAPs can be configured to use on-network rogue AP detection functionality to probe VLANs using cooperative control messages to detect if rogue APs are physically attached to the corporate switched network. Once rogue APs are found, the administrator can use rogue mitigation functionality (e.g. deauthentication) to prevent clients from associating with the rogue APs. The administrator can then use HiveManager to locate the position of rogue APs on a topology map so they can be removed.

The following diagram shows a list of rogue APs in HiveManager, Aerohive’s WLAN management system. In the picture, you can see the detailed information displayed about the rogue APs along with a link to a topology map displaying the location of the rogue AP on the map if it was discovered by at least three HiveAPs.

The following diagram shows an example of a discovered rogue AP on the topology map and the channel mappings of HiveAPs. The rogue AP is highlighted in the circle.

Diagram 10. Rogue AP List



Voice- and Video-aware WIPS Scanning

In order for HiveAPs to detect rogue APs or clients that are on different channels than what the HiveAP is using, the HiveAP must take a few milliseconds at a time to scan other radio channels. This off-channel scanning can slightly affect voice and video quality. To prevent degradation of voice and video quality, the off-channel scanning can be configured to operate only when there is no traffic in voice queues.

Diagram 11. Rogue AP Location on Topology Map


Integrated Protocol Analyzer Integration and Client Monitoring

Integrated into HiveManager is a Packet Capture tool. This tool allows the administrator to capture filtered or unfiltered traffic from an AP’s radios and to store the capture file for post-capture analysis.

Monitoring one or more clients in real-time within HiveManager is a snap with the Client Monitor tool. You simply select the client you want to monitor, select one or APs to monitor in regard to this client, and start the process. Many clients can be monitored at once, and everything that happens with monitored clients is logged to the display and can be exported.

Diagram 12. Integrate Protocol Analysis

Diagram 13. Client Monitoring



3rd Party WIPS and Protocol Analyzer Integration

Aerohive has worked with leading WIPS vendors to integrate their systems with HiveManager. This integration greatly simplifies configuration and deployment of the WIPS system by white-listing all HiveAPs in one simple step.

Aerohive has integrated HiveOS with Wireshark, one of the industry’s leading protocol analyzers, for the purposes of remote troubleshooting and performance and security analysis. Integration with other protocol analyzers is on the way, and with this kind of integration, administrators can now see what the AP sees without disconnecting clients. Each radio can capture data and send it to the analyzer (over the air or over the Ethernet) while clients continue to operate normally. This revolutionary step enables quick and easy monitoring across a distributed enterprise, or even large campus installations, without an on-site visit.

Diagram 14. 3rd Party WIPS Integration


Wireless Decryption at the HiveAP Allows Advanced Security at the Edge

Each HiveAP is responsible for encrypting and decrypting wireless frames and therefore has the ability to view frame payloads, perform security checks, and encrypt again if necessary before sending traffic out. This allows HiveAPs to enforce advanced security policies locally, at the point of network entry, before traffic is sent to the wired network, wirelessly through a mesh, or to another wireless client.

HiveAPs apply security policies to traffic based on the identity of a user or by the SSID being used. Security policies can enforce MAC address filters, MAC (layer 2) firewall policies, IP (layer-3/layer-4) stateful inspection firewall polices, and can prevent a number of wireless MAC-layer and IP-layer denial of service (DoS) attacks. Because each HiveAP is responsible for processing the security policies for its own traffic, the distributed processing power of all HiveAPs in the WLAN system is harnessed. Given the high-end processing power of each HiveAP, collective processing power far exceeds a centralized, controller-based model, allowing virtually unlimited scalability.

HiveAPs decrypt wireless frames at the network edge (before they are transmitted on to the wired network), making it possible to use the security systems currently in place in the wired network to enforce security policies on wireless traffic as well. This way, wireless and wired traffic alike can be forced to flow through the corporate security systems, including firewalls, antivirus gateways, intrusion detection and prevention systems, and network access control (NAC) devices.

Diagram 15. 3rd Party Protocol Analyzer Integration



RADIUS Server Built into HiveAPs

For locations that do not have local RADIUS servers or do not want to backhaul RADIUS traffic over a WAN to a central office, HiveAPs can be configured to provide a full RADIUS server implementation. This gives administrators the ability to implement a centrally-managed, secure WLAN authentication solution using 802.1X/EAP without having to purchase, configure/modify, or maintain corporate RADIUS servers. HiveAPs with the RADIUS server enabled can terminate 802.1X/EAP authentication methods such as PEAP, EAP-TTLS, EAP-TLS, and LEAP locally on the HiveAP. HiveAPs can authenticate wireless users using a local user database on the HiveAP or with external domain authentication to Directory Services (Active Directory, eDirectory, OpenDirectory, LDAP, or LDAP/S). Because the 802.1X/EAP key processing and distribution is performed in HiveAPs for wireless clients, these processes are offloaded from the corporate RADIUS servers, preserving their performance. With the ability to use any HiveAP as a RADIUS server, network administrators have the flexibility to design fail-safe RADIUS server implementations anywhere within a WLAN. This is especially useful in the branch office, where the 802.1X/EAP authentication process can occur locally on a HiveAP without the need to traverse a WAN link.

The HiveManager management appliance makes configuring HiveAP RADIUS servers a straightforward process. The RADIUS server settings, server certificates, and local users can be managed from a simple, easy-to-use graphical interface.

Built-in Captive Web Portal

Another way to provide policy enforcement at the edge is by using captive web portal functionality built in to each HiveAP. Captive web portals are what you expect to see when accessing a wireless network at a hotel or airport. When a user associates with an SSID which has the captive web portal enabled, and then opens a web browser, the user is redirected to a web-based registration screen hosted by the HiveAP itself.


The web page can be customized by the administrator to display a page to authenticate guests created with GuestManager (Aerohive’s web-based guest management solution), a HiveAP RADIUS server, or a third party RADIUS server. Additionally the captive web portal can be configured to display a web-based self-registration form where users can fill in their details and agree to the company’s acceptable use policy. Administrators can customize the captive web portal by designing their own web pages. After a user passes the registration process, their traffic is enforced by the HiveAP based on the user profile assigned to the SSID or based on a user profile assigned by an attribute returned from GuestManager or a RADIUS server.

Identity-Based Tunnels

Along with firewall policies, QoS policies, and VLAN assignment, when a client associates with an SSID and gets assigned to a user profile, the client’s traffic can be directed to be tunneled to a HiveAP in a pre-defined location or subnet. The following diagram provides a common use-case for identity-based tunnels. An SSID called Guest-WiFi is configured on HiveAPs in the internal network. When a guest client associates with the SSID, they are assigned to the Guest-DMZ user profile that has a policy to tunnel all the guest client’s frames (layer 2 traffic) via L2-GRE to one of the HiveAPs in the DMZ. The client obtains its IP address from a DHCP server accessible from the DMZ, which can optionally be running on a DMZ HiveAP. When a guest attempts to access the network, the guest traffic is restricted by the captive web portal on the local HiveAP until the guest has authenticated with a user account created using GuestManager or a RADIUS server, or the guest has completed a web-based self registration form. After being granted access, the local HiveAP enforces the guest-specific firewall policy, QoS policy, and tunnel policy configured in the Guest-DMZ user profile, and the permitted traffic is directed over a L2-GRE tunnel to a HiveAP in the DMZ, which permits access to the Internet. The guest traffic will never appear on the internal network outside of the L2-GRE tunnel. The client is essentially an extended member of the remote network.

Diagram 16. HiveAP Captive Web Portal



While this diagram shows an example of using identity-based tunnels for guest access, identity-based tunnels can be used for a variety of other scenarios as well. Using identity-based tunnels, network resources can be accessed from any location in the wireless network as if they were physically there. For extra scalability, HiveAPs can use round robin to build tunnels to a set of HiveAPs at the destination, and tunnels only exist while they are in use by clients.

Guest Access Policy Enforcement at the Edge

Along with the captive web portal capabilities that are available within HiveAPs, there are a number of complimentary features within Aerohive products that can be used to provide a robust guest access solution. These features include: 1. GuestManager – a robust, appliance-based guest management solution with an

easy-to-use web interface that allows a lobby ambassador to easily create time-limited user accounts with access to the WLAN. By supporting RADIUS Dynamic Change of Authorization (CoA), guest users can be removed from the network when their temporary account expires. Accounts can have varying user profiles, which will assign different QoS settings, firewall policies, and VLAN assignments. It is possible to provide access via username/password authentication, or just require a simple registration form before granting access to the WLAN.

2. Guest segmentation/isolation – after a guest has been authenticated or registered with a HiveAP, they can be placed on their own VLAN to prevent them from accessing corporate resources, but to allow them to still access the Internet. If VLAN segmentation is not possible due to the network architecture at the access layer, guests can be tunneled, using the identity-based tunnel functionality, directly to one or more HiveAPs within a firewalled DMZ area, such as a lobby.

3. User Profile-based Firewall Policies – these policies can be used to allow a different set of MAC and IP firewall policies to be applied to guest users to limit their access to specific resources. This can be used as an alternative to VLANs or tunneling or as an

Diagram 17. A Common Use for Identity-Based Tunnels - Placing Guests in a Firewalled DMZ for Internet-only Access


additional layer of control beyond VLANs and tunneling to control guest use of the network.

4. Per-SSID RADIUS server settings – allows a guest SSID to use a separate RADIUS server for authenticating guest users. This is important because GuestManager and most third-party guest management solutions utilize their own RADIUS servers. These RADIUS servers are equipped with a graphical interface to allow lobby administrators to create temporary guest user accounts, as guests are registered at the front desk. With RADIUS server settings per SSID, your corporate users authenticate with corporate RADIUS servers, while guest users authenticate with RADIUS servers tied to guest management solutions.

5. Per-SSID DoS settings – allows stricter management frame DoS settings and airtime flood prevention settings to be applied to guests.

The Aerohive guest access solution provides the flexibility of using features integrated into each HiveAP while allowing seamless interoperability with third-party guest access solutions.

Private Preshared Key (PPSK) Security

Though using 802.1X/EAP is the most secure approach to Wi-Fi authentication, this method is typically only implemented for devices managed by IT administrators, where they have control over the domain infrastructure, user accounts, and wireless clients being used. For temporary users such as contractors, students, or guests, the IT administrator may not have the access rights required, the time, or the knowledge of how to configure 802.1X/EAP clients for all the different wireless devices involved. Even more difficult is the fact that many legacy and SOHO-class wireless devices are still used in the enterprise that do not support 802.1X/EAP or the latest WPA2 standard with support for Opportunistic Key Caching (OKC) that required for fast/secure roaming between APs. The next best option has traditionally been to use a preshared key (PSK) for these devices; however, classic PSK trades off many of the advantages of 802.1X/EAP, such as the ability to revoke keys for wireless devices if they are lost, stolen, or compromised, and the extra security of having unique keys per user or client device. To draw on the strengths of both preshared key and 802.1X/EAP mechanisms without incurring the significant shortcomings of either, Aerohive has introduced a new approach to WLAN authentication: Private PSKs (PPSKs). PPSKs are unique preshared keys created for individual users on the same SSID. They offer the key uniqueness and policy flexibility that 802.1X/EAP provides with the deployment simplicity of preshared keys. The following diagram is a simple example showing a WLAN with traditional PSKs versus that of a WLAN using Aerohive’s PPSK functionality. With the traditional approach, all of the client devices use the same PSK and all receive the same access rights because the clients cannot be distinguished from each other.



On the other hand, with PPSK, as shown on the right, every user is assigned his/her own unique or “private” PSK, which can be manually created or automatically generated by HiveManager and sent to the user via email, printout, or SMS. Every PPSK can also be used to identify the user’s access policy, including their VLAN, firewall policy, QoS policy, tunnel policy, access schedule, and key validity period. Because the keys are unique, keys from one user cannot be used to derive keys for other users. Furthermore, if a device is lost, stolen, or compromised, the individual user’s key can be revoked from the network, preventing unauthorized access from any wireless device using that key. As for the client users, the configuration is the same as using a standard PSK.

Diagram 18. Private Preshared Key (PPSK)


Virtual Private Networking (VPN)

The Aerohive wireless VPN solution uses HiveAP 300s with their powerful network processor and CPU, as VPN servers, and any model HiveAP for VPN clients. Because the wireless VPN solution is made up entirely of Aerohive components, you can use HiveManager’s web-based interface to create a VPN policy, server certificates, and user-based policy, and push them out to all participating HiveAPs at the push of a button to establish a global VPN. Aerohive’s wireless VPN solution has been designed from the ground up to take advantage of layer 2 (L2) and layer 3 (L3) tunneling making it easier to deploy a global VPN. Typical L3 IPSec VPN solutions require planning and implementation of unique IP subnets for the remote offices, DHCP relays/IP helpers on remote routers, and IP routing, access control lists (ACLs), or firewall policies are needed to send traffic though the VPN. Aerohive’s wireless VPN does not have these complexities because it uses GRE to encapsulate layer 2 traffic, and IPSec to authenticate and encrypt the traffic so that it can be securely passed though the Internet. To the client, it will appear as though they are physically connected to the L2-switched network at the corporate office. For the IT administrator, planning and implementation complexities of typical L3 VPN solutions are alleviated because the same subnet can be shared among many remote sites. To deploy an Aerohive wireless VPN solution, HiveAPs configured as VPN servers are installed in the corporate network, typically in a DMZ. HiveAPs configured as VPN clients are installed at remote sites can obtain IP address settings via DHCP and can automatically establish a L2 VPN tunnel to the HiveAP acting as a VPN server at corporate headquarters. From that point on, traffic from corporate devices at the



remote site, including DHCP, is encapsulated in GRE and sent encrypted though a VPN tunnel to the HiveAP VPN servers at headquarters. Traffic is then unencrypted, decapsulated, and transmitted on to the corporate LAN with its full L2 MAC header and VLAN tag intact, just as if the traffic was originated from the corporate office. This gives IT administrators the ability to allocate and share corporate IP subnets among many remote sites without having to create unique IP subnets for each office. This alleviates the need to configure IP routing at the corporate site or branch offices to route traffic though the VPN. HiveAPs use MAC layer routing to determine whether traffic should be forwarded locally or sent though the VPN. An example of Aerohive’s wireless VPN solution is displayed below, which shows the network components of a branch and a teleworker’s home office. Each remote site establishes L2 VPN connections to corporate headquarters, which securely extends the corporate network to corporate workers in remote sites. Corporate devices obtain IP addressing though the VPN as if they are physically on the corporate network. In branch offices, wireless devices access the corporate network via a secure SSID profile available on branch HiveAPs. Likewise, corporate wired and wireless devices have direct access to the branch network though a bridged Ethernet connection on a branch HiveAP.

In the teleworker home office, a secure SSID is broadcasted from a HiveAP for secure corporate access, but a home SSID provides access to home resources and the Internet without access to the corporate VPN. Whether in a branch or teleworker home office, with best path forwarding and split tunneling, remote users have direct access to local resources such as printers, desktop PCs, or servers, even if these resources are not on corporate subnets.

Diagram 19. Aerohive’s Wireless VPN Topology


Best Path Forwarding and Wireless Mesh

One of the major concerns in WLANs is where security and QoS is applied. In many cases, administrators look to controllers for this, not because they like the architecture, but because they look to the controller to enforce policy. When all policy is enforced within the AP, as with the Aerohive Networks HiveAP, optimal data forwarding is enabled, including the “Best Path.” The best path is the shortest and lowest latency path to a network resource. With Aerohive best path forwarding, each HiveAP communicates with neighboring HiveAPs to find optimal paths between themselves, clients, and the wired network and then makes forwarding decisions dynamically. Aerohive’s Cooperative Control protocol suite works in a similar manner to Layer-3, link-state routing protocols whereby path costs are applied to links. This allows both fail-over and fail-back functionality. Unlike controller-based implementations with distributed data forwarding, which allow some traffic to be processed locally on an AP (which requires forgoing some level of functionality, such as firewalling and QoS) and other traffic to be processed by the controller, no tradeoffs have to be made on security, monitoring, or performance in an Aerohive wireless network. Aerohive does not have to compromise on functionality because traffic is always locally forwarded and fully processed at the HiveAP, whether you have HiveAPs at a corporate headquarters or in a branch office.

Wireless Mesh

Using cooperative control protocols that operate over the wired and wireless network segments, HiveAPs can establish wireless mesh connections with neighboring hive members. Because HiveAPs have two radios – one that supports 2.4 GHz channels and the other that supports 5 GHz channels – the administrator has the option to specify the use of one radio for wireless access and the other for wireless mesh. Wireless mesh can be used where wired connectivity is not feasible or is difficult to deploy, such as in historic buildings or stairwells where wireless access is required for VoWiFi solutions or location-based services. Wireless mesh can also be used where a network needs to be rapidly deployed, such as for a conference or a disaster recovery situation. Even if wired connectivity exists, wireless mesh can be used to augment the wired network. This gives the HiveAPs extra resiliency capabilities by being able to route around a failure like an Ethernet link that has been accidentally disconnected or an access switch that has failed or has been powered down. All a HiveAP needs is power, and the cooperative control protocol suite does the rest. The HiveAPs automatically build wireless mesh connections with each other to provide wireless coverage that is not limited to Ethernet’s 100-meter maximum twisted pair length.



Over the wireless mesh, Aerohive’s cooperative control protocols are used to provide best path forwarding, fast/secure roaming, optimal radio channel and power selection for wireless connections, and high availability with dynamic and stateful re-routing of traffic in the event of a failure. Because cooperative control protocols have been designed to scale to support very large wireless mesh networks, they prevent flooding by limiting the scope of broadcasts for the distribution of routes and roaming cache information. This, in combination with QoS, DoS prevention, and firewall policy enforcement at the HiveAP, keeps unnecessary traffic off the mesh, ensuring optimized WLAN performance though the mesh. Another powerful capability delivered by Aerohive’s mesh technology is the ability to use the mesh to bridge between two LANs. By configuring an Ethernet interface on a HiveAP to function as a wireless bridge, the HiveAP will learn the MAC address of devices on a local LAN segment and distribute that information throughout the Hive to allow traffic to be forwarded to and from those devices over the wireless network and to the primary wired LAN. This is especially useful for connecting devices such as video surveillance cameras that are in a building, parking lot, or outdoor area where running Ethernet cabling is too costly, or not possible, but power is available.

Diagram 20. HiveAP Deployment Flexibility


Scalable, Layer-2 Routing and Optimal Path Selection

For best path forwarding capabilities, HiveAPs utilize the Aerohive Mobility Routing Protocol (AMRP). Using AMRP, HiveAPs communicate with each other to determine the best path through a wireless network and have the ability to forward traffic locally using the best (least cost) path. This is a significant improvement over centralized, controller-based solutions, which require traffic to be backhauled to a centralized controller for policy to be enforced and forwarding decisions to be made. In order to determine the best paths through a network, HiveAPs run AMRP over both wired and wireless mesh connections. This allows the routing algorithms to determine the least path cost based on a number of metrics, including: data rates, hops, and interference. If a wired or wireless uplink fails, or interference affects the wireless performance, a better route can be selected and propagated through the WLAN. This allows HiveAPs to dynamically select a new best path for seamless re-routing and forwarding of traffic. To support large-scale WLAN installations, such as large corporate campuses, AMRP has been designed to limit the messages and routing information within self-contained areas. This limits the number of route table entries that a single HiveAP needs to maintain. The following diagram highlights the differences between the data forwarding paths that are observed with the best path forwarding of Aerohive’s cooperative control architecture versus that found in a typical controller-based architecture.

With the centralized control and centralized data plane architecture, all wireless traffic is directed to a dedicated WLAN controller, which may be many hops away or even at a

Diagram 21. Centralized vs. Distributed Data Forwarding



different location. Because of the indirect paths and round-trip times between the APs and the controllers, extra latency and jitter are introduced, which can have adverse affects on WLAN performance and voice quality. This is especially problematic if the path to the controller or the controller itself is heavily utilized. In contrast, the Aerohive cooperative control architecture using AMRP allows for best path forwarding between devices over the LAN and over wireless mesh, preventing extra latency and jitter as traffic passes between devices. This is essential for achieving high performance and exceptional voice quality.

Scalability with Best Path Forwarding

Performance scales linearly as the number of HiveAPs increases. Each HiveAP makes its own forwarding decisions and uses best path forwarding to transmit data. With no central traffic forwarding device that can become a bottleneck, the HiveAPs can take full advantage of the performance and capacity of the wired network infrastructure, giving full non-blocking performance. This is essential for 802.11n, which increases the performance of WLANs up to eight times.

High Availability

The Aerohive Networks cooperative control architecture is a perfect fit for organizations that require mission-critical reliability with no complex planning and minimal budget. Aerohive’s high availability features come standard within the HiveAPs and provide many levels of resiliency and redundancy.

No Single Point of Failure

Because HiveAPs do not utilize a controller, the Aerohive Networks WLAN architecture does not have a single point of failure. If a single HiveAP fails, stations automatically move to neighboring HiveAPs just as they would if they were roaming, without loss of authentication, security, QoS parameters, or session state, and without interruption of data or voice sessions. In addition, with cooperative control routing protocols and a distributed data plane, if HiveAPs within the mesh fail, Ethernet uplinks are disconnected, or if Ethernet switches fail, HiveAPs route around the failure to maintain connectivity.

Smart Power-over-Ethernet (PoE)

All HiveAPs can be fully powered by switches that support the 802.3at PoE amendment (also called PoE+), and the 100 series HiveAPs can be fully powered by 802.3af. Aerohive’s HiveAP 300 series 802.11n APs facilitate the transition to maximum-performance 802.11n by providing flexible support for legacy network switches and mid-span injectors. Aerohive's Smart PoE technology automatically detects the level of power being delivered by PoE-enabled switches or injectors and makes appropriate adjustments to the AP’s functionality. If required, HiveAP services can be automatically reduced to fit within the delivered power envelope. Using Smart PoE, if the HiveAP needs more power than is currently available, it will first disable its redundant Eth1 interface to free up some power. If it needs more power, it switches its radios from 3x3 to 2x3, which requires less power still. In rare cases when further power conservation is necessary, the HiveAP will reduce the speed on its Eth0 interface from 10/100/1000 Mbps to 10/100 Mbps. As a safeguard, in the event that


there is a problem with the PoE switch or Ethernet cable, the HiveAP disables its wireless interfaces and returns its Eth0 and Eth1 interfaces to 10/100/1000 Mbps speeds so that the HiveAP can be managed at full speed. This safeguard includes unique functionality such as support of LLDP and CDP that allows an administrator to find the switch manufacturer, port number, and operating system and then fully provision the AP so that when appropriate power is restored, the AP is ready to function at full capacity. For extra power and resiliency, both gigabit Ethernet ports on the HiveAP 340 have been equipped with Smart PoE technology, which allows both ports to draw power at the same time. Even if both of the links are connected to legacy PoE (802.3af) switches, the HiveAPs can operate at full capacity.

Redundant and Aggregate Links

For added resiliency, the gigabit Ethernet ports on the HiveAP 320 and 340 can be dual-homed for link redundancy, providing sub-second failover in the event of a switch or link failure. If HiveAPs are connected to two ports on a switch that is capable of Ethernet link aggregation, the HiveAPs can simultaneously utilize both links to get either 200 Mbps (with 100 Mbps connections) or 2 Gbps (with 1 Gbps connections) of throughput in both uplink and downlink directions. If you have 100BaseTx access layer Ethernet switches, Ethernet link aggregation mitigates the need to upgrade to gigabit Ethernet to support the high speeds of 802.11n. The following diagram shows a HiveAP connected to two different switches, having its eth0 and eth1 interfaces configured as redundant. In the first case, the traffic is flowing through eth0, and power is obtained from both eth0 and eth1 using Smart PoE. In the second case, the switch fails or the eth0 link is pulled. The HiveAP draws its full power from eth1, and the data traffic also continues out eth1. Failover between redundant interfaces occurs in less than one second without any interruption of service.

Self Healing by Dynamically Routing Around Failures

Diagram 22. Smart PoE and Redundant Interfaces



The resiliency built inherent in HiveAPs because of the cooperative control protocol suite allows the network to continue to operate even in the event of multiple inline failures. Because there is no central control point, there is no worry of a single device failure that is capable of bringing down an entire wireless network. The diagram below shows HiveAPs and the traffic from wireless clients when all HiveAPs are up and operational, and then when network failures occur and HiveAPs are taken offline.

Dynamic Mesh Failover

Aerohive also has a solution for environments that require wireless mesh capabilities for high availability, but desire the performance advantages of using both 5 GHz and 2.4 GHz radios for wireless access. An administrator can predefine either the 5 GHz or the 2.4 GHz radio as a dynamic mesh failover candidate on HiveAPs within a hive. This way, if a wired link is unplugged, or a switch fails, the HiveAP will de-authenticate any wireless clients on the chosen failover radio (typically the 5 GHz radio). The deauthenticated clients would then reassociate on the 2.4 GHz radio, and then the failover radio would be used to build a secure dynamic mesh connection to a nearby HiveAP. The HiveAPs will then dynamically route the client’s traffic around the wired failure over the new secure mesh link. When the failure is fixed, the mesh link is brought down and the radio is put back into access mode for client connectivity.

Diagram 23. Hive Availability with Seamless Roaming and Automatic Re-routing


AAA Credential Caching

Aerohive provides the ability to survive a WAN link failure by not requiring access to a central controller; however, if the WAN link does fail, wireless client authentication often fails as well – primarily when an off-site Authentication, Authorization, and Accounting (AAA) server, such as RADIUS, is used. Aerohive provides the ability to cache username and password hashes in DRAM such that if there is a WAN failure, authentication will continue to work for the branch office. This caching feature works only for users who have previously logged on within a configurable time. For example, users that have logged on in the last 48 hours will be able to authenticate across all APs at the branch, but new users will not have a cached entry. In the event of a WAN link failure, the RADIUS/AAA service in a HiveAP, if in use, can failover from using the external database to a local user database residing on the HiveAP.

Centralized WLAN Management

Centralized configuration, monitoring, and reporting on an Aerohive WLAN is provided by a web-based network management system called HiveManager. This management appliance can be located anywhere, and is not part of the network infrastructure or data path.

Simple, Scalable Management with the HiveManager WNMS

The HiveManager wireless network management system (WNMS) enables simple configuration and operating system updates, monitoring of HiveAPs within a cooperative control WLAN infrastructure, and compliance reporting, all while letting HiveAPs perform control and data forwarding functions among themselves. HiveManager has the responsibility of managing, monitoring, and reporting. Even if HiveManager is powered down and removed from the network, HiveAPs continue to

Diagram 24. Dynamic Mesh Failover



function with their entire feature set. Without the overhead of control and data forwarding that exists in controller-based management solutions, the HiveManager platform scales to support the management and monitoring of thousands of HiveAPs from a single console. Though each HiveAP can be configured using a robust command line interface (CLI), for any more than handful of HiveAPs it is recommended that the HiveManager platform be used. HiveManager simplifies management and monitoring of HiveAPs using a combination of topology views and floor plans, list views with filter and sort capabilities, and WLAN policies which provide a unified configuration for all non-device-specific configuration options. The following picture shows an example of the monitor list view for HiveAPs. At a glance, you can see the operational status, AP types, software versions, number of clients associated, IP addresses, and power/channel selections to name just a few.

Versions of HiveManager

HiveManager is available in many versions, included 1U standard and 2U high-capacity appliances, a virtual appliance (VMware virtual machine), and as a software-as-a-service (SaaS) offering called HiveManager Online. Each mode of delivery has its own unique benefits, and there’s even two operational modes: Express and Enterprise. HiveManager Express has a streamlined graphical user interface (GUI) for those organizations who prioritize ease-of-use above most other features and who have a uniform company-wide access policy. HiveManager Enterprise is a maximized implementation of HiveManager, offering a tremendous level of configuration, monitoring, and configuration flexibility and sophistication.

Diagram 25. HiveManager – Managed HiveAPs Monitor List View


HiveManager Components and Communication

HiveManager communicates with HiveAPs using an IP-based protocol called CAPWAP, which is an IETF draft for the Control and Provisioning of Wireless Access Points. HiveManager also communicates with HiveAPs using SCP (Secure Copy), SSH2, SNMP v3, DTLS (Datagram Transport Layer Security), and TLS (Transport Layer Security) to name a few. HiveAPs build a secure (authenticated and strongly encrypted) CAPWAP tunnel to HiveManager, through which configuration files and firmware can be downloaded and configuration and statistical data can be uploaded. HiveAPs can be located anywhere in the network as long as they have the ability to reach the HiveManager via an IP address. HiveAPs can even communicate to the HiveManager through NAT (Network Address Translation) or NAPT (Network Address Port Translation). Administrators can access the HiveManager GUI from a web browser, and the GUI is based on HTML, AJAX, and Flash, allowing administrators to experience a real-time management platform securely and efficiently from any PC.

Diagram 26. Versions of HiveManager



On HiveManager 1U and 2U appliances, there are both MGT and LAN interfaces, allowing the separation of HiveManager administration from the management of HiveAPs. By default, the MGT interface is used for both the HiveManager administration and HiveAP management. However, the administrator can dedicate the LAN interface for HiveAP management and use the MGT interface solely for HiveManager administration.

Simplified Configuration Management

The management GUI for the HiveManager has been designed so that thousands of HiveAPs can be easily managed and monitored. To simplify the configuration of like items across one or more HiveAPs, a WLAN policy is applied. A WLAN policy contains all the configuration settings for HiveAPs that are not HiveAP specific. Configuration settings such as SSID, Hive, RADIUS, QoS policy, firewall policy, SNMP, NTP, Syslog, and user profile, to name a few, are all included within a WLAN policy. Once WLAN policies are defined, they are assigned to one or more HiveAPs based on a location or a logical deployment type. If a set of HiveAPs requires different configuration settings, the administrator can simply clone an existing WLAN policy, make the necessary changes to the new policy, and apply the new policy to a set of HiveAPs. Device-specific configuration settings, such as interface modes, login credentials, routes, radio profile assignments, and radio channel and power settings can be assigned to one or more devices in the device-specific configuration settings by selecting and modifying a single HiveAP or multi-selecting a set of HiveAPs.

Diagram 27. HiveManager Components and Communication


Zero Configuration for Access Point Deployments

As HiveAPs are deployed, they can be installed without any initial configuration settings. When HiveAPs are connected to the network and powered on, by default they obtain their IP settings via DHCP. HiveAPs then automatically locate a HiveManager using the following methods: • DNS – to lookup the name: hivemanager.yourdomain • DHCP – to provide option 226: the IP address of the HiveManager • DHCP – to provide option 225: a custom DNS name for the HiveManager • CAPWAP – broadcast discovery that works if the HiveAPs and HiveManager are on

the same subnet. • CLI – capwap client server name <string>

HiveAPs then use CAPWAP to contact the HiveManager, authenticate, and then build an encrypted tunnel. HiveManager then displays a list of the discovered HiveAPs. The administrator simply assigns WLAN Policies to HiveAPs and accepts them as devices to manage. After that, the administrator can use one-button configuration updates to send the configuration to one or more HiveAPs, or to schedule the configuration updates for a later time. Likewise, if the operating system needs updating, the administrator can select one or more HiveAPs to immediately send or schedule operating system updates.

Auto-Provisioning

By default, when HiveAPs locate the HiveManager, they will be displayed in HiveManager in the New HiveAPs Automatically Discovered list. This gives the administrator control of when and how a HiveAP should be managed. However, the management process can be automated by using the auto-provisioning feature in HiveManager. Using auto-provisioning, the administrator can import or manually enter a list of serial numbers for HiveAPs that will be deployed, and then pre-define a WLAN policy, operating system version, radio profiles, topology map, and VLAN for the HiveAPs. When a HiveAP with one of the entered serial numbers is discovered, HiveManager will automatically push configuration and/or operating system updates to each newly-discovered HiveAP with no administrator interaction required.

Simplified Monitoring, Troubleshooting, and Reporting

Along with simplified configuration and operating system management, HiveManager makes it easy to monitor and troubleshoot HiveAPs within a wireless network infrastructure. Using hierarchical map views, an entire set of maps (from a world view down to floor levels) can be imported to organize HiveAPs based on their physical location. Icons can be added to represent locations, buildings, floors, and HiveAPs, and the color of the icons change based on the propagation of alarms from HiveAPs. From topology maps or filterable/sortable lists of managed HiveAPs, administrators can simply right-click on a HiveAP to view real-time information, such as a list of associated wireless clients, logs, roaming information, configurations, and statistics. From HiveManager, administrators can also use an extensive set of tools to ping, view LLDP or CDP information, perform packet captures, and even click a button to SSH directly into HiveAPs for more advanced troubleshooting tasks. The illustration below gives you an idea of the tool set available within HiveManager.



HiveManager allows an administrator to view all of the active clients in the WLAN, showing their IP addresses, MAC addresses, hostnames, user names (If RADIUS authentication is used), SSIDs, session start times, signal strength values, the HiveAPs clients that are associated with, and a variety of other parameters. This information is stored within the HiveManager and can be exported as a CSV file for advanced troubleshooting and network forensics. For ease of identifying clients, administrators have the ability to add comments and to modify user details for clients which remain persistent across logins. This is especially useful when testing and troubleshooting.

A wide variety of information can be exported for reporting purposes and pre-defined and custom reporting features are standard in HiveManager. To be proactive, administrators can configure email notifications so that they can be immediately informed of alarms on the WLAN.

More detailed information about each client is available by selecting the client from the list. This information includes the SSID and APs the clients have been associated with,

Diagram 29. HiveManager Real-time Active Clients Display

Diagram 28. HiveManager Tools


their signal levels, connection rates, RSSI values, duration, and traffic utilization statistics. The illustration below shows an example of some of the information that can be obtained about individual clients, which is often useful for learning about client behavior, troubleshooting problems, and looking for dead spots in wireless coverage.

HiveAP Classification for Adaptive WLAN Policy Configuration

To simplify the configuration of like items across one or more HiveAPs, a WLAN policy is created in HiveManager and then applied to HiveAPs. A WLAN policy contains all the configuration settings for HiveAPs that are not HiveAP-specific. Configuration settings such as SSIDs, Hives, RADIUS, QoS policies, firewall policies, SNMP, NTP, Syslog, and user profiles, to name a few, are all included within a WLAN Policy. Once WLAN policies are defined, they are assigned to one or more HiveAPs based on a location or a logical deployment type. If a set of HiveAPs require different configuration settings in areas of the network, you can use one of two different methods to accomplish the configuration. The first method is to

Diagram 30: HiveManager Detailed Active Client Information



simply clone an existing WLAN Policy, make the necessary changes, and apply the new WLAN policy to one or more HiveAPs. The second method is to use HiveAP classification. HiveAP classification allows an administrator to define network objects used in WLAN policies (including VLANs, IP addresses, MAC addresses, and RADIUS attribute groups) and to assign different values to these objects based on the topology map, where HiveAPs reside, three text strings (called tags) defined in HiveAP settings, or by specifying individual HiveAPs. The following diagram shows how a single WLAN policy can be applied to HiveAPs in Area 1 and Area 2, but with area-specific changes.

When HiveManager updates the configuration policy on HiveAPs, it can identify HiveAPs by location on a map, HiveAP classification tag, or specifically chosen HiveAPs. In this example, the HiveAPs in area 1 and area 2 are identified by the topology map they are located on within HiveManager. When you define VLAN or IP address objects, you can specify how they will be applied to HiveAPs based on HiveAP classification criteria. As an example, the following picture shows how you can define a VLAN object from within HiveManager that will be assigned to a user profile. You can see that the object Employee-VLAN will be configured as: VLAN 2 on HiveAPs located on the Area1 topology map and VLAN 7 for HiveAPs on the Area2 topology map.

Diagram 31. Identity and Location-Based Policy using a single WLAN policy


You can also use HiveAP classification settings for IP objects. In a similar fashion, you can define the RADIUS server IP address to use 10.1.1.55 in Area 1, and 10.6.1.55 in Area 2. This allows an administrator push one configuration policy to all HiveAPs while allowing the objects within the policy to be applied differently to individual HiveAPs based on classification information. In this example, when a user authenticates with SSID Corp_WiFi, the RADIUS server returns the user profile attribute number 100 for that specific user, and the HiveAP uses that value to bind the user to a user profile (ensuring the appropriate policies are enforced for that user). This mapping of user profile attribute numbers into specific user profiles can be different in different parts of the network, allowing for either global user policy enforcement or location-specific user policy enforcement. In this example, in some locations, a user is assigned different VLANs and QoS policies, but the same firewall policy and layer 3 roaming policies. Likewise, other users assigned to different user profile attributes may follow the same physical path, but can be assigned to different VLANs and policies. This allows administrators to create access policies based on identity and location.

Guest Manager

Aerohive's GuestManager is a guest account management and authentication server that completes Aerohive’s robust and secure guest access solution. In combination with HiveAPs, the GuestManager enables guest users to be simply and securely authorized for access to a guest network. Aerohive GuestManager makes it simple for authorized employees to create guest accounts while keeping the guest network secure by authenticating and reporting on all guest users.

Role-based Guest Administration

GuestManager, in conjunction with the overall Aerohive solution, enables granular management of different types of guest roles, while the HiveAPs can enforce different security, QoS, or segmentation requirements based upon roles communicated to them from GuestManager. This enables, for example, contractors to get extended access to a network and a visitor to get access for only a few hours. This functionality also enables contractors to get access to different network resources, while visitors may be allowed to access only the Internet. These two types of guests both authenticate using the same SSID and web portal interface but have different policies applied based upon their user

Diagram 32. Identity and Location-Based Policy



credentials.

Guest Access with GuestManager

In order to enable guest access to a corporate network securely with the least operational effort, an entire guest solution must be in place. The chart below shows the key requirements and how Aerohive provides a complete solution. Requirements The Aerohive Solution The ability to secure and segment guest traffic from corporate traffic

Aerohive enables segmentation through a rich identity-based policy engine. Based upon user identity, guests can be put on a separate VLAN or be tunneled to the DMZ to ensure that guest and employee traffic does not mix.

The ability to apply QoS and security policies to guest users as they join the network

Aerohive can apply complete access policy at the HiveAP including time-of-day and day-of-week access, firewall, DoS prevention, and QoS policies based on the identity or role of the guest.

The ability to easily create unique guest credentials

GuestManager makes it simple for authorized employees to create and distribute guest credentials and instructions for joining the network.

A user-friendly authentication and authorization process

As guest log into a guest SSID, they are presented with a Web Login page on a captive web portal hosted on the HiveAP. The users’ credentials are passed via RADIUS to GuestManager where they are authenticated and authorized for access to the guest network.

Guest Account Creation and Management

GuestManager also provides flexible guest account management, allowing guest access and accounts to be audited, canceled, or tracked. The creation of guest accounts enables an organization to configure a system that matches its security and operational goals. Here are a few examples of guest account registration available in GuestManager:

• Lobby ambassador registration enables receptionists or security personnel to provide access to the network as guests enter the building

• Employee registration enables any employee to create guest accounts. GuestManager integrates with Active Directory to enable employee access to GuestManager based on group policy.

• Self-registration enables guests to use a kiosk in the lobby or secure area to create their own accounts. This presumes physical access in order to get network access.

• Bulk account registration enables conference or training organizers to create large numbers of user credentials easily.


Credentials

The simple distribution of unique guest credentials is one of the key operational benefits of GuestManager. Credentials can be randomly generated or specified during registration to provide a unique login identity for the guest. Once the user credentials are created, the credentials can be emailed or printed on letter-sized paper or a label along with instructions on how to access the network.

Single Centralized Instance for Guest Authentication

GuestManager runs on RADIUS so it can be used to authenticate guests on wired and wireless portals. It enables an entire multi-site enterprise to use a single or regionalized instance of the platform to cover an entire company or just one part of it.

Delivered as an Appliance

GuestManager is delivered as a standalone appliance or an instance on HiveManager to ease deployment and maintenance of guest services. The GuestManager appliance has been “hardened” (secured) against malicious attack, and vulnerabilities are fixed as the system is upgraded.

Diagram 33. GuestManager Main Interface



Conclusion

Supporting near-100% uptime for mission-critical, real-time, and high-throughput applications demands an architecture that can provide unprecedented availability and security while still being simple to deploy, scale, and manage. Eliminating bottlenecks, single points of failure, and scalability limitations is the next step in Wi-Fi’s continuing evolution. The future of Wi-Fi is distributed intelligence and its name is Cooperative Control.

Diagram 34. Where GuestManager Fits in the Network

About Aerohive

Aerohive Networks reduces the cost and complexity of today’s networks with cloud-enabled, distributed Wi-Fi and routing solutions for enterprises and medium sized companies including branch offices and teleworkers. Aerohive’s award-winning cooperative control Wi-Fi architecture, public or private cloud-enabled network management, routing and VPN solutions eliminate costly controllers and single points of failure. This gives its customers mission critical reliability with granular security and policy enforcement and the ability to start small and expand without limitations. Aerohive was founded in 2006 and is headquartered in Sunnyvale, Calif. The company’s investors include Kleiner Perkins Caufield & Byers, Lightspeed Venture Partners, Northern Light Venture Capital and New Enterprise Associates, Inc. (NEA).

Corporate Headquarters EMEA Headquarters Aerohive Networks, Inc. Aerohive Networks Europe LTD 330 Gibraltar Drive Sequel House Sunnyvale, California 94089 USA The Hart Phone: 408.510.6100 Surrey, UK GU9 7HW Toll Free: 1.866.918.9918 +44 (0)1252 736590 Fax: 408.510.6199 Fax: +44 (0)1252711901 [email protected] www.aerohive.com WP1000110

Reseller contact:[email protected]://www.altaware.comPhone: 949-484-4125

Technology

Aerohive whitepaper-cooperative control WLAN