I’m delighted to say that we’re now ready to kick-off with the first post of our all new content series focusing on best practice around internal enterprise WiFi.
Over the past few months I’ve had quite a few email enquiries from readers wondering if I had any perspective on the issue of internal enterprise WiFi. I had to point out that although I’ve got strong views on the subject (i.e. it should be secure, but it should be easily accessible — and available to every employee), I wasn’t sure about the technology or procedures to follow. Hence the introduction of this series. I hope you find it useful.
I put a call for submissions up a few weeks ago and we’ve had quite a lot of companies operating in the WiFi technology space get in touch. I then wrote back to each company with a set of standard questions around the topic. In my outline I also asked respondents to actively include examples and references to their own products and services — and where possible, give a few sample case studies to help get readers started on the right techniques and practices. I thought this would be rather useful given the fact that anyone reading this series in-depth will obviously be interested.
Devin Akin of Aerohive Networks
I have to say that I was thoroughly impressed at the answers submitted for this post by Devin Akin. Devin is Chief WiFi Architect at Aerohive Networks. His list of commonly performed duties is rather comprehensive — I have to reproduce it here:
Company evangelist, channel builder, strategic employee stealer – Aerohive is building the A-team, technical marketing (competitive analysis), corporate strategy, internal cheerleader, deal closer, innovator, business development, and fixer
Next, let’s have a picture of the man himself:
Ok, so that’s Devin. Now let’s take a look at Aerohive.
They’re a specialist enterprise WiFi infrastructure company with a different take on the technology architecture underpinning wireless networks (as Devin will explain below). They use Cooperative Control (controller-less) architecture combined with both public and private cloud management systems. They’re based in Sunnyvale, California but their footprint extends across the globe. In terms of finance, they’ve just completed a series-D round of funding ($25m).
Right then, let’s get started. My questions are in bold.
– – – – –
A landline has been standard issue for employees for decades now. In a similar manner, should enterprises be deploying internal WiFi services for their employees to use?
Yes. Wi-Fi enables greater employee work efficiency, productivity, and computing on-the-move. Recent studies have shown that the average Wi-Fi enabled worker yields up to an hour extra of productive work per day.
Additionally, some enterprise Wi-Fi systems now have the intelligence to identify the device type and user and tie that to a variety of other parameters (location, time of day, day of week, etc) to enforce user-based policies. This ensures specific security measures are applied to workers while remaining productive.
Wired systems simply cannot offer this. It’s for these reasons that all Ethernet switching vendors are now seeking Wi-Fi solutions to be paired with their Ethernet solutions, whether through OEM, acquisition, or by in-house development.
First, the enterprise Wi-Fi system has to have the intelligence to recognize a personal Mobile Internet Device (MID). Once that intelligence is integrated, then appropriate authentication mechanisms must be in place for the specific MIDs in use. For example, if 802.1X/EAP is not supported (or not fully supported) by the MID, then a Captive Web Portal (CWP) could be used to securely authenticate the user against an internal LDAP user database (such as Active Directory) and then securely (HTTPS) distribute to the user a unique PSK (called a Private Pre-shared Key or PPSK) for use while connected to the network. Policies should include:
- Secure access for guests, corporate MID users, and contractors.
- Identification of device types, operating systems, and policy application (QoS, firewall, etc) based on a combination of user credentials and device. For example, a personally-owned iPhone might only be allowed Internet access while a corporate-issued iPad might have VDI and Internet access.
I think ‘slow’ is relative. In the US, strong adoption started in 2001 and has accelerated without delay ever since. In other parts of the world, it varies greatly based on economy, scepticism of security, education around Wi-Fi technology, technology availability, and more. We see heavy adoption in many European countries, ANZA, and across APAC. I wouldn’t say that adoption is slow, but in areas where it’s not ‘fast’, I would call the roll-outs more ‘measured’ or ‘calculated’.
I believe that, as an industry, we’ll continue to see a steady growth of Wi-Fi sales for many years to come in support of the MID explosion. Many computing devices, for example, are not offered with an Ethernet option, such as smart phones, tablet computers, and MacBook Airs.
How secure is WiFi compared to a wired-line alternative? Is it possible to deploy a WiFi network that you’d consider as secure as wired infrastructure?
Wi-Fi networks are far more secure than wired-line networks, if the administrator wishes to implement the available security features. It is now expected that every user on an enterprise-class Wi-Fi network has their own stateful firewall session (something that isn’t done on Ethernet) that controls and filters all of their traffic.
Enterprise Wi-Fi networks usually have integrated WIPS for intrusion prevention, and Aerohive even has L2-L4 DoS attack recognition/defence (moving beyond just the L2 that other vendors offer). Each user in enterprise Wi-Fi networks is securely authenticated against a central user database using 802.1X/PEAP (or similar), which is usually supported by enterprise-class Ethernet switches, but rarely implemented.
It’s noteworthy that Aerohive supports fully-distributed data forwarding (as there are no controllers in our solution).
Our competitors are trying to emulate this with semi-distributed forwarding, whereby some protocols (stateless, such as Windows file copies) are forwarded at the AP and some protocols (FTP, TFTP, SIP, etc) are forwarded at the controller. Since all or most (depending on vendor) is forwarded at the edge, the data is often decrypted at the AP and put onto the Ethernet unencrypted. This makes it equal in security with Ethernet at that point.
This trend is impossible to not notice, and is driving adoption of Wi-Fi infrastructure in a huge way in Aerohive’s #1 vertical market: education. The strain that tablet computers, such as the iPad, put on the network is shocking but, for Aerohive, it’s a God-send.
Our architecture was designed from the ground-up for extreme scalability and speed, un-killable resilience, tremendous edge-based intelligence, is low cost with pervasive coverage, and extremely high-density handling. All of these are required to handle the ‘iEverything Explosion’, as we call it, and Aerohive is the only vendor positioned to deal with this opportunity (that other vendors see as a problem).
In addition to the need for resilience and speed in supporting this tidal wave of MIDs on the network is the intelligence within the platform to deal with incompatibilities between clients and infrastructure due to problems like bad client drivers. Aerohive’s intelligence engine is far ahead of any of our competitors in auto-diagnosing and auto-correcting client problems in order that clients continue to maintain their SLAs, which we support and were first-to-market with.
When it comes to delivering WiFi for thousands of employees across a multi-storey building, explain to us why you can’t deliver this with a few £49 routers from PC World plugged into a standard BT Broadband line?
Such SOHO-class Wi-Fi routers have the follow deficiencies:
- No shared control plane or enterprise features, which means no RRM, WIPS, RTLS, Fast/Secure L2/L3 roaming, tunnelling, centralized authentication, guest management, directory integration, survivability features, airtime scheduling/fairness, centralized management, user-based security profiling with QoS/firewalling, device recognition and policy application, client/AP health scoring, PCI/HIPAA/SOX reporting and monitoring, spectrum analysis, protocol capturing, etc. The SOHO-class AP market has not progressed in 10 years, but enterprise-class Wi-Fi has made great strides, supporting mobile applications, giving users more productive hours in the day, and allowing a seamless corporate user experience regardless of where the user roams within the coverage areas.
- Typically handle a light traffic load for up to 15 clients maximum – often more like 10 clients.
Comparing such Wi-Fi routers to enterprise-class Wi-Fi, like Aerohive sells, is like comparing a group of bicycles to a 747 Jumbo jet and asking why you can’t just have everyone ride their bicycle from London to Sydney for £49 instead of £1499.
With today’s 802.11n networks, each Access Point (AP) needs a Gigabit Ethernet backhaul link in order to experience a non-blocking experience. PoE or PoE+ is often provided via the Ethernet cable for cost-saving purposes, but I realize that’s really outside of the scope of the question, so I’ll stay on-point.
The question is an important one for the following reasons:
- Controller-based vendors have the controller as their system’s backplane. If they have, for example, 100 dual-radio 802.11n APs, each having approximately 350 Mbps of throughput capacity, then that’s 35 Gbps of traffic that the controller may ultimately have to deal with. Most controllers have up to four 1Gbps interfaces, but there are some very large/expensive controllers that have dual 10Gbps interfaces. In either scenario, the controller is a bottleneck, and even worse, those controllers that have 10Gbps interfaces are still only capable of approximately 4Gbps of encrypted throughput. That’s just for 100 APs with 300Mbps data rates. What about 5,000 APs with 450Mbps data rates for large enterprises with new, state-of-the-art APs? The controller-based architecture is dead.
- Because everything Aerohive does is within and between APs – using a resilient set of cooperative protocols (called Cooperative Control) – Aerohive’s backbone is the Ethernet infrastructure. With fast Ethernet as the backbone, it’s still FAR faster than any controller can provide and, with Gigabit Ethernet at the edge, has no bottleneck at all. Aerohive uses a highly-intelligent, fully-distributed architecture that is designed exactly like the Internet, where a group of separate-but-cooperative intelligent nodes (in our case APs) work as a team (called a Hive) to form one large distributed computer that cannot be taken offline unless every single AP dies. When is the last time the entire Internet failed? It works the same with Aerohive’s architecture. The backhaul has no single points of failure or bottlenecks.
- With Aerohive, the backhaul can be Ethernet or Wi-Fi, as our system natively and dynamically meshes over any link available to it for added resilience. Each link has a path-cost, and the least-cost path is used at any given time for forwarding of frames for the backhaul. Each AP will auto-discover its neighbours over the Ethernet and Wi-Fi networks and form mesh links unless configured not to do so. This is especially useful in scenarios where you need to reboot upstream routers and switches for code updates/maintenance and don’t want the Wi-Fi to go offline downstream. This is something native to Aerohive’s architecture that is found with no other Wi-Fi vendor.
Do you think overly restrictive enterprise WiFi security policies are heavily outdated or still relevant for today’s environment? What WiFi policies have you seen adopted by enterprises?
I think ‘overly restrictive’ is open to interpretation. You’ve likely heard people say that ‘access’ and ‘security’ are polar opposites and, in the past, that has been reality, but no longer. I believe it’s important for a network administrator to have the tools at his/her disposal to create/apply the access policies that he/she deems appropriate. What’s more, it’s important that the configuration of these policies should be simple, and with most enterprise Wi-Fi vendors it is not.
Aerohive’s system is the most feature-rich enterprise-class Wi-Fi infrastructure product in the market today, and yet it’s still as simple to use as an SMB-class product. To directly answer your question, it is Aerohive’s stance that there are several areas that need improvement in today’s enterprise, including (but certainly not limited to):
- Securing guest/hotspot access. This has been a problem for over 10 years. The de facto standards for authentication/encryption today are WPA2-Enterprise using 802.1X/PEAP and WPA2-PSK. Aerohive introduced a third option, a ‘best of both worlds’ option, called Private Pre-shared Key (PPSK) over two years ago, which has seen wide adoption among our customer base. We’ve recently used this feature, in combination with our captive web portal (CWP) feature, to introduce secure hotspot/guest access. A guest can register via HTTPS (secured via SSL) for a PPSK that is as secure as 802.1X/EAP. This is an important enhancement that we hope to see everyone do in the future for the benefit of the industry.
- With user-based, policy-driven security combined with device and application recognition and other security parameters such as location and time-of-day/day-of-week, mobile devices can be given the specific access they need, and nothing more. In the past, the tools to make this possible were: 1) not usually available and/or 2) very clunky. Now that vendors have had time to mature their products and to address today’s MID explosion from a security perspective, access and security are on the same side of the fence – at least for some vendors (like Aerohive), though not for all as they’d have you believe.
What’s the best way to implement a guest WiFi network that doesn’t involve visitors and their hosts having to jump through helpdesk hoops to get wireless connectivity?
It really depends on the policy of the organization.
Most organizations will have an SSID dedicated to guest users, leave it with open security (no security), offer a CWP where the user can either register or agree to acceptable use (or both), and then proceed to the Internet at some rate-limited uplink/downlink value. These types of networks are often either connected into a DMZ in the Internet firewall or firewalled within the Wi-Fi infrastructure (if the Wi-Fi infrastructure system has an integrated firewall) so that guest user traffic cannot reach internal network resources. In scenarios like this, security can only be achieved through: 1) client use of VPN software, or 2) client use of secure protocols like HTTPS or POP3/SSL.
Some organizations use a ticketing system that dynamically adds a username/password to the system through the use of a special interface or application that can be used by a non-technical user like a lobby ambassador (receptionist). These logins can be set to expire after a given amount of time.
Some organizations, in an attempt to offer guests ‘secure’ access, have started using PSK-secured guest networks, with the same firewalling scenario. The problem with doing this is that the PSK is shared, making it easily hackable.
Aerohive can do all the above, but also tie our PPSK functionality into each scenario so that every user can have their own revocable PSK to secure their traffic. Aerohive’s per-user stateful firewall assures that guest users may only go to the Internet, and they can be uplink and downlink rate-limited so that they don’t hog all of the Internet bandwidth. Protocols can be filtered and traffic can even be redistributed (tunnelled) to a firewall DMZ from AP-to-AP if you like (though it’s not required). Most customers like the fact that guest and corporate traffic can exist on the same VLAN and, due to per-user firewall policies at the AP, guest users can only get Internet access while other users have may have local access as well.
The best way is to use a self-registration CWP with PPSK and a per-user firewall that allows Internet-access only and rate-limiting. This configuration takes seconds in Aerohive’s system.
Regarding deploying an internal WiFi network, can you give any examples of ‘gotchas’, problems or challenges that readers may not have considered?
There are many gotchas, but I have some that irritate me personally, so here’s a quick list:
First, I’ll say that unless all intelligence is within the AP, then ‘distributed forwarding’ is a mess. Controller vendors push part of the intelligence out to their APs, and then perform some of their functions there, but still require that the controller perform other functions as well.
Where this gets sticky is with distributed forwarding of data. Protocols that are considered ‘stateful’ like SIP, FTP, and TFTP, open dynamic ports on each end of the connection. This means that if the Wi-Fi infrastructure vendor has a stateful firewall in their product, they must maintain this state.
For controller vendors, if the data flows to/through the controller, then there’s only one firewall to deal with, so this isn’t a problem, but when data flows are distributed, firewalls must be distributed into the APs and then be synchronized.
Controller vendors do not synchronize firewalls across APs, so traffic that requires stateful handling must traverse the controller, which forms a bottleneck – defeating the very reason for distributed forwarding. That means that distributed forwarding with a controller-based architecture is just a ‘hack’.
Additionally, they have to decide which protocols will be distributed and which will be centralized. That’s a mess. Aerohive uses distributed forwarding with firewall synchronization across all APs.
In small deployments (up to 24 APs let’s say), some vendors are touting that they are ‘controller-less’ like Aerohive. This is just silly. They have reverted to the Colubris model of 2007 (long dead) whereby an AP becomes a controller for a small group of APs. It’s still a single point of failure, still a bottleneck, and is feature-poor (in comparison with using a real controller) due to a lack of processing power, it’s minimally manageable, and it’s only a SMB solution at best. This is not ‘controller-less’, and it is not an enterprise-class solution.
Every vendor calls themselves ‘enterprise-class’ it seems, but many are just not. They don’t offer the system resilience or feature set expected in enterprise-class systems. There are only a small handful of true enterprise-grade Wi-Fi infrastructure systems on the market, and Aerohive’s is the best among them.
A challenge that users should consider is that voice/video/RTLS and high client density handling require a reasonable number of APs. Often vendors will try to be more competitive on ‘up-front’ pricing by short-changing the customer on APs, saying things like, “our system requires 30% less APs” – that’s just misleading.
In any scenario where there is a large number of client devices (like a school perhaps), ‘coverage’ is rarely a top priority in the design, but rather ‘capacity’ is more important. If accurate location services are needed, then more APs are often required for the installation. Don’t let the marketing fool you.
The typical rule of thumb is one AP per 3,000 square feet for RTLS and 4,500 square feet for high-density/high-capacity with voice/multimedia. It can certainly vary, but these are good places to start your planning.
Aerohive has a free planning tool at www.Aerohive.com/planner that customers/prospects can use to plan their networks and to get an accurate idea of how many APs they will need for a given capacity, coverage, data-rate, etc.
Should companies deploy WiFi networks themselves with their own resource, or should they hire a dedicated specialist to prepare, advise and install it?
I think there are two ways of looking at this question.
First, I believe that all customers should be educated, to some degree, on the technologies they implement within their business. If the customer can afford to train their people to properly design, install, configure, and troubleshoot enterprise Wi-Fi systems, then they should. If they cannot, then they should at least educate their people to the degree necessary to properly oversee those contractors/providers who do the work so that the organization is not taken advantage of.
Second, I believe that it is a good idea for all organizations to have one or more trusted advisors (consultants), systems integrators (SIs), or Managed Service Providers (MSPs) who they work with for IT services. SIs and MSPs usually dedicate tremendous resources to training their engineers to be experts both on specific technologies and on specific hardware/software that they sell for manufacturers.
In order to answer your question as accurately as possible, I believe that it’s important to hire a specialist to participate in the most complex portions of the process, such as design. A network architect (designer) will understand, end-to-end, the Wi-Fi infrastructure platform, how it hooks into back-end authentication systems, client load capabilities, how to use the feature sets, etc, and can design the network around the system’s capabilities and/or choose a system that has the right capabilities for the customer (depending on the situation). Initial configuration might also be an area where an expert consultant may be very helpful. For day-to-day operations, either an MSP or a systems administrator seems most cost effective and appropriate.
Could you give us some examples of best practice installations that you’ve recommended, implemented or observed from around the marketplace?
I’m not exactly sure how to answer this question or what you’re looking for, so I’ll offer some related information.
Aerohive is extremely strong in the education market. Requirements for Wi-Fi in this market are stringent: high-density of clients, high traffic load, variety of client types, traffic spikes at the beginning of classes, the need for classroom control mechanisms, mission-critical resilience (100% uptime) during class hours is required, indoor and outdoor APs must be coordinated, temporary buildings need instant meshing with additional Ethernet ports on APs for printers and local switches, many simultaneous user profiles (guests, staff, students, contractors, etc), and strong security (802.1X/EAP, PPSK, WIPS, stateful firewall, etc).
This is just a few requirements, but the actual list is much longer. In order to meet these needs, most schools deploy one AP per two classrooms, but when the school’s physical structure is concrete block walls, it’s often one AP per room because RF simply doesn’t penetrate concrete block walls. Aerohive has a variety of AP types (indoor, outdoor, high-end, 2 gig ports with long range), entry-level (1 gig port with medium range), etc, to fit every need and cost requirement. We have hundreds of schools deployed in this manner.
For remote workers, VPN connectivity is a big deal. Aerohive APs can be VPN clients and VPN servers. Our AP300 series can terminate 128 tunnels and be configured in redundant mode, so for remote workers and branch offices it solves the problem of buying additional hardware with additional management systems. It’s a great solution for mid-market VPN needs.
For large-scale branch office and home Wi-Fi with VPN termination, Aerohive will be launching a platform in Q3/11 (based on the Pareto Networks acquisition from January 2011) that will scale to tens of thousands of locations with low-cost CPE that supports zero-touch auto-provisioning and cloud-management with complete end-to-end visibility.
There’s something for everyone here. We’ve deployed our existing VPN solution into dozens of customers, who claim that it’s important to them because: 1) it’s managed by the same system as the Wi-Fi, 2) it keeps both sides of the link on the same L2 LAN segment (IPSec over GRE), and 3) there’s no feature license – it’s included free with the cost of the AP.
Well then! Wow! Thank you for such comprehensive answers Devin.
If you’d like more information about Aerohive Networks, please visit them at aerohive.com.
We’ll have more contributions to the Internet Enterprise WiFi Best Practice series shortly — in the meantime, thank you once again Devin.