jump to navigation

Cooperative Control: Part 4 (final) March 8, 2010

Posted by Devin Akin in : Uncategorized , add a comment

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.

Diagram5

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

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 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.

————————

This is the last blog post on Cooperative Control.  If you want to read more on the topic, I will refer you to our website at Aerohive.com for the upcoming comprehensive whitepaper on Cooperative Control.  Future blogs will incorporate my personality.  See ya next week, and oh, btw, stay tuned for some really exciting action at the beginning of the quarter.  :)

Cooperative Control: Part 3 March 1, 2010

Posted by Devin Akin in : Uncategorized , 2comments

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:

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.

Diagram3

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.

Diagram4

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.

Cooperative Control: Part 2 February 22, 2010

Posted by Devin Akin in : Uncategorized , 1 comment so far

Centralized Management, Distributed Control, and Distributed Forwarding

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:

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.

Chart

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:

Diagram2

Diagram 2. Aerohive Networks Naming Conventions

Cooperative Control: Part 1 February 15, 2010

Posted by Devin Akin in : Uncategorized , 2comments

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.

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

Diagram1

Diagram 1. Building Blocks of
Cooperative Control Architecture

Test, Test, and Retest February 8, 2010

Posted by Devin Akin in : Uncategorized , 5comments

Test and Retest were in a boat.  Test jumped out.  Who was left?

If you want “Wi-Fi that works”, you gotta test, test, and retest.  Silicon Valley is full of some wicked smart software engineers, but nobody gets it right the first time every time.  Because developers are moving at a break-neck pace, with practically every project being one that breaks new technology ground, bugs are the status quo.  In fact, each new firmware revision has a set of release notes that lists all of the known bugs with that release.  Of course, that doesn’t include the ones that VARs and end-users will find later.

I think it should be each vendor’s goal to eliminate as many known-and-fixable bugs as possible prior to releasing code.  Sure, some people do beta testing, but, as my mom used to say, “they give it a lick and a promise” and move right into FCS.  Some vendors push “innovation” so hard that they completely lose sight of the importance of the code working at all.  Sure, customers care about innovation, but they care alot more about the system working as designed, specified, and promised.  In the new State-of-the-Market report for 2009 from Webtorials, 64% of respondents chose reliability as the most important Wi-Fi system characteristic that they value.  In InformationWeek’s 2010 Analytics Report “Nothing but Air”, author and Wi-Fi consultant Grant Moerschel notes that 90% of respondents value reliability over any other system characteristic.  In other words, everyone agrees that Wi-Fi should “just work.”  Wi-Fi is more-or-less synonymous with the Internet, which makes it a de facto utility.  Your lights and water “just work” – why can’t you count on your Wi-Fi for the same kind of reliability?

How do we achieve this Utopian state of Wi-Fi affairs?  I’ll tell you how.  Just like Toyota…oops, wait…scratch that…let’s change industries…Apple Computer (ref: http://bit.ly/6F49C4), you have to design, design, design, and test, test, test.  Ever heard that old saying, “measure twice, cut once?”  I say, “test thrice, support nonce.” Hey, I made that saying up on the spot, so what can you expect?  How shalt we do such testing anywho?  Well, Aerohive uses VeriWave.  Their systems are crazy cool.  If you haven’t checked out their platforms, they do more than you can imagine.  You need 500 stateful clients coming out of one antenna?  No problem.  What about a mega-mix of 802.11b, g, and n for uplink and downlink stress and compatibility testing?  Piece of cake.  Just about all of the Wi-Fi manufacturers use their gear, and for good reason.  We have 4 of their systems (of varying size and configuration), and they’re used a ton around here.  Cabled, chambered, and over-the-air (OTA) automated testing happening just about around the clock.  It’s a testing extravaganza.

I tried to get the big boss man to send me one of those WT20 units for my own testing purposes, but…as you can imagine, that was met with a swift, “Uh, no.”  Rats.  A brother needs…OK, it’s really more “want” than “need”, but you know what I mean…a VeriWave system.  It would allow me to bat “clean-up” on this QA thing.  After test, test, and retest comes Devinator-the-Bug-Hunter-from-Hell.  It would be just like old times at CWNP when we were the free QA dept for every Wi-Fi vendor and their brother.

Shout out to Marcus Burton, lab engineer extraordinaire.  Woot!

Wireless 2.0 February 1, 2010

Posted by Devin Akin in : Uncategorized , 1 comment so far

Maximized Minimalization.  Yep, that’s what it’s all about.

What kind of wordsmith would I be if I had called the blog “less is more”? We’ve been saying, “Simpli-Fi” for a couple of months now, and we are beginning to wonder if anyone “gets it.”  Our existing customers get it, but for the unreached masses, there’s an important story here.

The enterprise Wi-Fi market is undergoing tremendous growth, with predictions of enterprise Wi-Fi market doubling in the next 3 years.  The way that Wi-Fi is being used and the requirements on an enterprise Wi-Fi network are also going through a fundamental and generational change, so much so, that we are calling it Wireless 2.0.  It’s not a new term, but it is a relevant one.

W2a

Today, there is an explosion of Wi-Fi enabled devices, a potential 10X client performance increase with the 802.11n amendment and the migration of Wi-Fi from convenience to mission-critical Ethernet replacement networks.  This is driving the enterprise to demand a new type of Wi-Fi infrastructure.  Enterprise’s want a secure, multi-service infrastructure capable of supporting different application (voice, video, data), user, and client types as though they each had their own networks.  A ubiquitously accessible, low-cost, mobile network with wired-like resilience and determinism, that is easy to use and deploy, is expected.  In other words, enterprises want the mobility and productivity of Wi-Fi with the scale, performance, resilience, and ubiquity of the Internet.

We believe the way to maximize in each of these areas is to minimize.  Let’s talk about how to do that.

Step 1 – Minimize Components

The controller was a stop-gap from the git-go.  Ask Bob O’Hara.  He’ll tell you.  Well, in fact, he did…right here:  Bob Speaks.

Controllers fixed some problems, and because there was such an insane demand for things like fast/secure roaming and radio resource management, controllers got their day in the sun.  Near the beginning of that time period, AP component prices were extremely high, so building the MAC-daddy (pun intended) AP was pointless.  Who would’ve bought them?  Not me.  Today is a completely different story.

Between then and now, there have been some very fast changes in the market.  The market went from needing only a shared control plane to needing that plus much more – like massive scalability and throughput support, near 100% uptime, and low cost.  It just so happened that right as controllers hit their peak, the economy hit the floor.

Aerohive’s architecture allows us to do in software what everyone else is doing in hardware.  Using hardware to share the control plane has severe scalability, cost, and resilience problems.  Remove the controller, and all of those problems go away.  That leaves us with only a management system (called HiveManager) and APs (called HiveAPs), which enables linear and unlimited scalability at a major cost reduction.

How much hardware are we talking about removing anyway?  Well, there’s the rack of controllers (depending on your network size), your branch office controllers, and even your redundant controllers.  How many controllers can you possibly need anyway?  Just wait until the 800 pound gorilla starts forcing you replace your edge switches with wired/wireless controllers (so that they can scale).  Your pocketbook is going to take it in the shorts even more then that it does now.

Step 2 – Minimize Costs

Removing all forms of controller evil from your network will get you half way there, but there’s more to the story when it comes to costs.  If you’ve recently bought a controller-based solution, you know this already.  There’s AP licenses, feature licenses (remote AP, firewall, WIPS, VPN, and so on – for all controllers including the redundant ones), and of course each controller maxes out at a certain number of APs…so that means more controllers.  Oh, I’m not done yet…  There’s also hidden costs like rack space and cooling as well.

Did I mention that protocols are free?  Aerohive does in software what everyone else does in hardware.  The competition will throw FUD all day long about “their APs costs more than ours” or “their management system costs more than ours”, but when you compare the solution cost with apples-to-apples features, they (meaning all of them) aren’t on the same playing field.  It’s actually quite funny to listen to our SEs’ stories about how the competition has to take all profit out of their quotes to even be competitive. J  I wonder how that’s working out for the competitors…

Aerohive also thinks that it’s very important to offer cost flexibility to its customers, offering a variety of APs and a variety of management solutions.  On the management side alone, HiveManager is offered as a 1U, 2U, HA, Virtual Appliance (Virtual Machine), and a SaaS (online) solution.  Which you choose depends on your organization’s size, shape, and budget type (CAPEX/OPEX).  HiveManager also comes in two “flavors” called Express and Enterprise.

I chose HiveManager Online (HMOL) Express to run my home network…but hey, that’s just me.  You can choose whichever you like since they all do basically the same things, just in a variety of delivery modes.

Step 3 – Minimize Failures

The End Game: adaptive, self-healing, self-optimizing, application-aware Wi-Fi infrastructure.  That’s what it’s about.  I like to describe it as “you can’t kill it.”  In this resilient infrastructure, there are no single points of failure, uptime is maximized to near 100%, and due to the minimal number of components, typically hardware failure rates (which affects every enterprise vendor in the same way) affect the customer less.

Aerohive achieves this goal through use of stringently-tested software capable of link-state, best-path forwarding at Layer-2.  Yes, Layer-2.  An AP dies, no problem.  An Ethernet switch dies, no big deal.  A cable gets cut, so what?  Think of Aerohive as a hybrid of the “mesh-only” vendors, that have mesh down to a science, and the access vendors who give it their best shot to do mesh (but just suck at it).  Built from the ground-up as a mesh/access hybrid, it functions like the Internet.  Think about how the routers on the Internet are autonomous, yet talk to each other through routing protocols (a control plane function).  Aerohive’s control plane protocol suite, called Cooperative Control, works like a Layer-2 routing protocol – managing control functions like RRM and fast/secure roaming.

A significant part of minimizing failures is through stringent QA testing to minimize compatibility and functional problems.  Nothing ships until a large group of testers (inside and outside the QA department) approves it.  Recent reports from InformationWeek and Webtorials both show that reliability is far-and-away (90% in one survey, 64% in the other) the most important vendor evaluation criteria.

Step 4 – Minimize Complexity

Am I the only one sick and tired of complex GUIs that give wireless network administrators a feature fatigue headache?  How about figuring out how to divide up groups of APs into individual controllers of varying capacities, licenses, and physical locations?  Deployment and configuration complexity is simply unnecessary.  Put the APs where they should be, based on a site survey, and be done with it.

Aerohive is pioneering the Automatic Wi-Fi Transmission (not trademarked in case you want to copy it). “Simpl-Fi” is plastered across our homepage.  We have recently launched HiveManager Online (HMOL) with Express and Enterprise options.  HMOL couldn’t be any easier: automatic provisioning, no appliance to worry about, automatic backups, fully redundant, etc.  The benefits go on and on.  Aerohive is taking the pain out of Wi-Fi.

Step 5 – Minimize Security Holes

Wi-Fi security is like Medusa (the Greek gorgon).  Hopefully that’s a clear enough mental picture.  You have to consider role-based access control (often just referred to as a role-based firewall these days), WIPS, 802.1X/EAP, PSK, secure management, and more.  Every which way you turn, there’s another security concern.

Aerohive covers all of these bases and then some.  For example, why would you want to use PSK when you can use Private PSK (PPSK)?  Aerohive’s founders and senior staff originated with NetScreen, which sold to Juniper.  Need I say more about security?  Holy smokes, these guys KNOW a little somethin-somethin about security. (sorry for the GA slang…couldn’t resist).

Summary

Anyone with a networking architecture background can easily see that all roads will eventually lead to a distributed architecture.  It’s the only way to scale, provide resilience, and to minimize costs. Look at your routed or switched networks.  Look at the Internet.  All distributed…everything at the edge. All the controller vendors are tinkering with their Wireless 1.0 architectures, distributing functions in a vain attempt to re-optimize themselves for a Wireless 2.0 world. Even Motorola and Cisco we hear. Aerohive has had a distributed approach for 3 years already. Do you want to trust a sub-optimal, half-baked product from the big boys or a third-gen, fully-mature product from the leader in controller-less Wi-Fi?  Hey, I’m just sayin’…

Decoding Deauthentication January 25, 2010

Posted by Devin Akin in : Uncategorized , 2comments

Because the boys and girls at IEEE have done such an astounding job on the 802.11 standard, I’m certainly going to mention that this is their fine work.  Below is an excerpt from 802.11-2007 (copyright IEEE).

————————
5.4.3.2 Deauthentication
The deauthentication service is invoked when an existing Open System or Shared Key authentication is to be terminated.  Deauthentication is an SS.

In an ESS, because authentication is a prerequisite for association, the act of deauthentication shall cause the STA to be disassociated. The deauthentication service may be invoked by either authenticated party (non-AP STA or AP).  Deauthentication is not a request; it is a notification. Deauthentication shall not be refused by either party. When an AP sends a deauthentication notice to an associated STA, the association shall also be terminated.

In an RSN ESS, Open System authentication is required. In an RSN ESS, deauthentication results in termination of any association for the deauthenticated STA. It also results in the IEEE 802.1X Controlled Port for that STA being disabled and deletes the pairwise transient key security association (PTKSA). The deauthentication notification is provided to IEEE Std 802.1X-2004 via the MAC layer.

In an RSNA, deauthentication also destroys any related PTKSA, group temporal key security association (GTKSA), station-to-station link (STSL) master key security association (SMKSA), and STSL transient key security association (STKSA) that exist in the STA and closes the associated IEEE 802.1X Controlled Port.
If pairwise master key (PMK) caching is not enabled, deauthentication also destroys the pairwise master key security association (PMKSA) from which the deleted PTKSA was derived.

In an RSN IBSS, Open System authentication is optional, but a STA is required to recognize Deauthentication frames. Deauthentication results in the IEEE 802.1X Controlled Port for that STA being disabled and deletes the PTKSA.
————————

Just as a point of fact, next to the Bible, the 802.11 standard (with amendments) is my favorite book.  Who would’ve thought that the 802.11 standard had groupies like me. :)   Anyway, back to the topic at hand….  The reason I copied this small section into this blog is that there’s no point in trying to recreate something that’s already practically perfect…if not completely perfect.  In GA, we call that “reinventing the wheel.”  These guys said it better than I could have, so we’ll use their text to talk about this week’s topic: deauthentication (deauth).

What a deauth does (recap, in plain Geeky English)

1) breaks the 802.11 authentication and association
2) closes the “controlled port” for 802.1X/EAP authenticated clients
3) deletes the PTKSA and GTKSA (meaning the PTK which were formed during the 4-Way Handshake is now invalid)
4) deletes the PMKSA unless PMK caching isn’t enabled

It’s #4 that I’m most interested in talking about.  Regardless of architecture (controller-based or controller-less), most vendors have the ability for the PMKSA to be cached.  This means that when an 802.1X/EAP client roams, the PMK is still used for the next authentication.  Today’s de facto standard fast/secure roaming algorithm, called Opportunistic Key Caching (OKC), has the AP to which the client is associated forwarding the PMK to either a controller or other APs directly, where it’s used to create a new PMKID which the client can use for roaming to new APs.  It works well, and the Wi-Fi Alliance’s Voice-Enterprise certification will pull components from 802.11r, k, & v to enhance and standardize this process.

So to recap, deauth frames break PTKSAs (on the current AP and client) but allow PMKs to live on for reuse at other APs.  Obviously this isn’t a top-of-mind subject, but when you’re constantly designing stuff, you run into weirld little nuances like this that can catch you off-guard.  Obviously I’m not as advanced in 802.11 protocol and system design as our top hardware and software engineers, but in striving to reach their level of uber-geekiness, I stumble across little protocol nuggets like this that I can share.

As my good friend Criss likes to say: hope this helps.

/Devinator

It’s All About The People January 18, 2010

Posted by Devin Akin in : Uncategorized , 3comments

Before I start, here’s the disclaimer:  The opinions expressed in this blog post are mine and mine alone and do not necessarily represent anyone other than me.  I work for ‘the man’ now, and I write this blog knowing full-well that my mouth may get me in trouble because of some “between the lines” thing I implied (or didn’t), something I said (or didn’t), or someone I offended (unknowingly).  You can’t please everyone…so, if my LinkedIn status suddenly changes to “Will work for food” and this blog post suddenly disappears, you’ll know why. :)   Here goes…

I’ve worked in a many companies in my time, and I’ve heard all kinds of answers to the question, “What’s the most important thing the company has?”  I’ve heard:

1. Customer base
2. Intellectual property
3. Market share
4. Management team
5. Investors
6. Cash in the bank

…and others, depending on the most pressing issue of the day.

/Soap Box – Start

Being both passionate and opinionated, I say that the most important thing a company has is its people (employees, volunteers, people volunteering to work for $1/year, and all the others).  Why do I think that?  Perhaps a series of questions will help answer that question.

* Who found and landed the customers?
* Who puts in long hours to make sure that customers stay happy?
* Who creates the intellectual property owned by the company?
* Who works their butts off to make the company all of that cash?

If one employee leaves, it’s another employee who picks up the ball and runs with it, no?   This “people are the most important thing” fact applies to the CEO and the shipping clerk alike.  It’s people who make the world turn, and without people there is no company.  Sometimes, I think that everyone (regardless of their role within a company) forgets this.

/Soap Box – End

/Cool Stuff – Start

Lest you think that I’m “pointing my guns” at Aerohive, it’s quite the opposite.  Aerohive puts people first, knowing that everything else will fall into place if you do.  Dave regularly meets with everyone, regularly (and out of the blue) calls people, and department heads here genuinely care about their people.  I’ve even seen some department heads (VPs) show outright compassion and concern for folks who aren’t even in their department.

As a quick side note, I just have to tell you that people at Aerohive even call their managers to make sure THEY’RE OK.  When is the last time you saw someone check to make sure their manager was OK?  I’ve seen people get raises without asking for them.  I’ve seen people be incredibly encouraging to each other.  I’ve seen people in one department praise someone in another department to “just the right person” that causes the praiseworthy person to get promoted.  There’s some love going on around here.  Neat, eh?

/Cool Stuff – End

/Advice (and Rants) – Start

This section is a mash-up of topics (by paragraph) that I feel led to talk about.  These have nothing to do with Aerohive, but are rather my personal thoughts.  There’s no rhyme or reason to the order.  It’s just me spewing some solid advice (according to my own experience and sense of importance) that isn’t technical, isn’t company-related, and just have to do with me being me.

Because of the dynamic and multi-faceted nature of any ‘real’ company, there will be peaks and valleys.  Luckily I don’t have to argue that point because the recent economic melt-down just strongly proved my point.  During most of that time, most of us were very lucky to even have a job at all – any job.  If you were making anything akin to 6 figures during that time, you should be insanely grateful to someone.  Over the last 2 years, many people have been “stuck” in their jobs because of layoffs, flat growth, or any number of other reasons.  Yes, I know you get tired of doing the “same old thing for the same old money”, but you could be much, much worse off.  I konw at least a 1,000 people who would trade with you in 4.3 seconds (exactly).  Be thankful.

You know how you sometimes get “stuck” in a position you don’t necessarily care for?  I’ve been there more times than I care to admit.  Fun?  No.  However, if you find yourself thrashing about like a caged tiger looking for an exit, consider the long-term rather than the short term.  Have you ever heard those stories about the IBM mail room clerk becoming CEO after 30 years?  How do you figure that happened?  He starts in the mail room, then becomes the mail room manager because he knows how to do all of the jobs in the mail room better than anyone else.  It’s call experience.  Then, he may ask to be moved to tech support, asking for an opportunity to prove himself.  Again, he learns to do all of the jobs there, until someone wises up and promotes him to manager.  This cycle progresses through sales, marketing, operations, support, and more…until…he is the most experienced and knowledgeable person in the company.  Who better to lead the company to success than this guy?  Ever read the Bible story of Joseph?  I highly recommend it.  If you don’t like your current job, do it to the best of your ability, learn all you can, and move on to the next thing when the opportunity is there.  I’m sure that sounds like “just common sense”, but you’d be surprised how hard it is to follow that advice.  Follow this advice, and someday soon, it’ll be you in that VP’s chair.  Don’t believe me?  Ask a VP how he got his/her job.  Be diligent.

Something related to the previous rant is a since of ownership.  That is, treating the company like you own all of it – like it’s, “your baby.”  You know what I’m talking about.  Treat it as if you founded it, as if you knew every financial detail, as if you understood full-well why every employee was hired, as if every penny spent on anything was coming out of your checking account, and all of the rest.  We’re talking about, “this company lives or dies by your hand.”  Now that you know what I mean by “a sense of ownership”, I would like to say that every employee needs and should have this.  Working at a company is a handshake deal between you and your employer whereby you agree to display a sense of ownership in everything you do, and your employer agrees to pay you for it.  Compensation (often referred to as just “comp”) may be a mash-up of stock options, salary, benefits, and a variety of other things – each designed to give you a sense of ownership.  Employers should always strive to address comp issues before an employee feels that there’s a problem, looking to fairly compensate employees.  Employees, in turn, should (as part of that sense of ownership) consider that they are part of a team and that there is only so much money to go around.  They should only ask for what’s fair and not try to strain the company to the breaking point.  If it were (and since it is) YOUR company, how would you handle comp with employees given the opportunity?  Are you fairly paid or over-paid?  Only you can answer that, but you should answer that question – honestly.  Do you bring the company more money than your paid?  Are you sure?  Take ownership.

Companies should realize that one experienced employee is worth more than one inexperienced employee.  Sometimes that ratio may be 3:1, depending on the person and the job.  Obviously there’s a limit to what a company can pay a person, regardless of position, but generally speaking (because there are always exceptions), a company is shooting itself in the foot to let a senior level (experienced and adept at their job) person walk out the door.  A company is its people, and if you’re people are inexperienced and untrained, you’re going to suffer for it.  Value people.

/Advice (and Rants) – End

That’s enough for one blog.  I’ve never blogged on that topic before, but for some odd reason, I just felt strongly led to spew all of that this week.  People are the most important thing, and nobody will ever convince me otherwise.

Try not. Do. Or do not. There is no try. — Yoda January 11, 2010

Posted by Devin Akin in : Uncategorized , add a comment

How could anyone possibly say it better than Yoda?

What poked me to write this blog is the stark contrast between our Support Jedi Master Kobie and the hopelessly careless (or should I spell it out as ‘could care less’…) tech support at AT&T’s ADSL department.

Kobie stalks it, kills it, bags it, and brings it home in an organized binder.

By way of contrast… AT&T runs a line check, says everything is fine, has you run a speedtest against the SpeakEasy website, and then blames it on your internal house wiring when it doesn’t pass muster.

Nevermind that the connection has been perfect for 3 months, and nevermind that you’ve had an AT&T employee install Cat5e cable from your router’s RJ-11 port directly to the NID.   No call to engineering to check on routing problems (like a router failure that over-subscribes its counterparts).  No call to have someone check over-subscription of the DSLAM. Just blame the wiring and move on. Is it too much to ask for a support guy to want to figure out the problem rather than just following a support script?  Their processes pretty much ASSURE poor customer service a significant portion of the time.

I believe that a large part of the recipe for success in support is hiring people who care, who want to learn, who want to be great at their job, and who won’t stop until they fix your problem.  It’s about WANT TO.  Kobie is a great engineer because he WANTS to be a great engineer.

Kobie reading from a script would be a good April Fools day joke. :-)

So, like Yoda, adopting an attitude of, “Try not. Do. Or do not. There is no try.” will catapult you from ‘job doer’ to ‘industry professional.’ Why does this matter?

Have you ever heard…

“We don’t have any budget for that.”

Did this make you want to figure out how to do it anyway (without a budget) or did you just stop right there, whining that you could get your job done if you had resources?

Have you ever heard…

“That’s not your concern, so stop thinking about that and get back to work.”

Did this make you study to become something you’re not or did you go home and complain to your spouse and friends that life isn’t fair?

Failure is not an option, and whining is not an option. Doing is the ONLY option.

SO WHAT if you don’t hit the bullseye, and SO WHAT if you’re not perfect (or even the best).

If you have an ounce of WANT TO, then DO. Or do not.

Transmit Beamforming (TxBF) January 4, 2010

Posted by Devin Akin in : Uncategorized , add a comment

For those engineers working in product management at Wi-Fi manufacturers, TxBF is a well-understood technology.  For normal people (i.e. the rest of us), it can be a confusing thing.  There are multiple technologies that get lumped together under the TxBF moniker.  There are several types of TxBF, and I’d like to briefly (because this is a blog, not a whitepaper) describe each type for the purpose of clarification.

The purpose of TxBF is to raise the SNR at receiver for the purpose increased data rates and decreased retransmissions.  This can be done in a variety of ways.

There are two general types of TxBF: open loop and closed loop.  Open loop means that the transmitter has limited feedback to work with and is therefore essentially forced to estimate where the receiver is located.  Closed loop means that accuracy of transmissions is improved by opening a feedback channel between the transmitter and receiver so that the receiver can provide direct and specific feedback on how well it is receiving signals.

Standard-based (802.11n) Beamforming (Explicit Feedback) - The 802.11n amendment actually specifies 3 sub-types of Explicit beamforming: compressed, uncompressed, and CSI (channel state information).  CSI likely won’t be implemented.  In compressed and uncompressed explicit feedback, the receiver computes a steering matrix and sends it to the transmitter, which uses it to configure the phases of the transmit chains on per-frame basis.  This requires that both the transmitter and receiver understand and operate using the same TxBF protocol.

Standard-based (802.11n) Beamforming (Implicit Feedback) – The transmitter assumes that the channel is reciprocal (the same in both directions) and creates the steering matrix by tracking incoming training symbols.  Implicit TxBF’s primary advantages over explicit TxBF methods are that it places only a small load on the receiver and imposes minimal transmission overhead.  The primary disadvantage of implicit TxBF is that the transmitter needs to calibrate the differences between the transmit and receive chains, and the calibration process is completed using feedback from the receiver.

An advantage of 802.11n TxBF is that it’s standards-based, meaning that TxBF capable equipment will work with any other interoperability-certified (read: Wi-Fi Alliance) TxBF capable equipment.  Another advantage is that it allows the transmitters to continue using an omni-directional RF pattern, which prevents hidden node problems.  The disadvantage is that there won’t be an 802.11n TxBF-capable, Wi-Fi Alliance certified piece of equipment on the market for quite some time to come.  Several chipset vendors will soon release chipsets that support 802.11n TxBF, but even after these chipsets are released into the market, it will still be a significant amount of time before that translates into interoperability-certified devices available for sale.

Discrete Beamforming – Composed of an antenna array that is capable of a static number of pre-defined beam patterns and a CPU that intelligently selects from the table of possible beam patterns for each transmitted frame (e.g. Ruckus Wireless).

Discrete beamforming is markedly different than 802.11n beamforming, which is considered a type of “Linear” beamforming because it can form an almost infinite number of phase differentials between its transmit chains in order to aim the transmission at a client that is located in almost any point in space around the transmitter.

An advantage of Discrete Beamforming is that it focuses the AP’s transmit beam in a specific direction, which has the desirable effects of:

1) high gain in the intended direction

2) interference mitigation in the unintended directions

3) minimal client participation (nothing beyond the 802.11 standard) is required

4) fast-moving clients will generally stay within the beam pattern.

Ruckus’s array in particular, on indoor AP models, yields the approximate equivalent of a 6dBi antenna in 2.4 GHz, which is quite nice.  The disadvantage of this approach is that clients that are already predisposed to being sticky become very sticky and this approach to beamforming can produce significant hidden node issues, depending on how it is deployed and the client density of a cell or deployment as a whole.

An array of directional antennas - a cohesive set of directional antennas forming an array with a circular or spherical pattern when viewed as a whole (e.g. Xirrus).

With an array of directional antennas, each radio device is serving a smaller physical area, and there may be several radios, so capacity of a single physical array is significantly higher than a single- or dual-radio AP.  Disadvantages are that the array is big, expensive (in comparison to a single AP of course), and may be difficult to deploy in desirable locations (which may lead to sub-optimal coverage).  Additionally, having radios at such close range may cause inter-radio interference, and when array goes down, a large coverage area experiences an outage.

At this point, there’s no perfect solution, and even when the standards-based solution arrives, it’ll be immature, requiring some amount of vetting and adjustment before living up to its hype.  I’ve heard my good friend Joe Epstein say the approximate of, “Why would you need beamforming when you could just turn up the power to get the same effect?”  In today’s systems, that may cause some link balance issues with clients unless you have some fairly high-gain antennas (for the purpose of receive sensitivity) on your AP, but I get what he’s saying. :-)