Archive

Posts Tagged ‘aruba’

Hunting down the cost factors in the cloud Wi-Fi management plane

October 3rd, 2013

 

Mature cloud Wi-Fi offerings have gone through few phases already. They started with bare-bones device configuration from the cloud console and over the years matured into meaty management plane for complete Wi-Fi access, security and complementary services in the cloud.

CostAlongside these phases of evolution, optimizing the cost of operation of the cloud backend has always been important consideration. It is critical for cloud operators and Managed Service Providers (MSPs). This cost dictates what end users pay for cloud Wi-Fi services and whether attractive pricing models (like AirTight’s Opex-only model) can be viable in the long run. It is also important to the bottom line of the cloud operator/MSP.

Posed with the cost question, one would impulsively say that cost is driven by the capacity in terms of number of APs that can be managed from a staple of compute resource in the cloud. That is an important cost contributor, but not the only one!

 

What do the cost models from cloud operation reveal?

 

We have monitored cloud backend operation costs for past several years. Based on that data, we have built some cost models. These models have led to the discovery of factors that are significant cost contributors. Identifying the cost component is a major step towards reducing it. The cost reduction is often implemented by the combination of technology and process innovations.

 

Draining the cost out of cloud

 

Scalability

This one is no brainer for anyone with head in the cloud. Scalability generally refers to number of APs that can be managed with a unit of compute resource. Higher scalability helps reduce the cost. Enough said.

Provisioning

As the customers of diverse scales (10 APs to 10,000 APs) are deployed in the cloud and at diverse paces, it often results into unused capacity holes in the provisioned compute resources. The capacity holes are undesirable, because the cloud operator or MSP has to pay for them, but they don’t get utilized towards managing end user devices.

The unused capacity problem needs to be solved at two points in time: Initial provisioning and re-provisioning. Clearly, when new customers are deployed, you try to fit them in the right sized capacity buckets. Assuming they love your product, they will then deploy more and start to outgrow their capacity buckets (but you also cannot over-provision, else there will be capacity hole from the beginning). This is the re-provisioning time. At that time, the cloud architecture and processes need to be able to seamlessly migrate customers to bigger capacity buckets.

Personnel

The very reason customers have chosen to go with cloud is because they want plug-n-play experience. As such, the patience level of the cloud customer is often lower than the one choosing the onsite deployment option. This necessitates higher level of plug-n-play experience to avoid support calls.

There are various points in the life cycle that have high tendency to generate support calls.  One point in time is when devices connect to the cloud, or let’s say, not able to connect to cloud. Another critical time is during software upgrades. The issues also often arise during re-provisioning as discussed above when customers are migrated between compute resources. The cost of attending to support calls can be a significant factor if these experiences are not super smooth. Additional complexities arise when APs are sold through channel, but cloud is operated by vendor or another MSP.

The pricing logic behind reducing personnel cost at MSP is as follows. The end user is eliminating the onsite personnel cost by migrating to cloud, and hence paying less on TCO basis. When the experience is not smooth, this cost is transferred to the personnel at the cloud operator or MSP. The cloud operator and MSP cannot make money if they pick up significant part of this cost on their head.

Latent Resources

Certain features such as high availability and disaster recovery have potential to give rise to latent resources. Latent resources are different from capacity holes discussed before. Latent resources are like insurance in that they don’t get utilized most of the time, but they need to be maintained in great shape. Brute force implementation of these redundancy features has been found to be significant cost contributor to cloud operation.

For any cloud services platform, the above pain points are exposed after years of operational experience and teething pain with diverse customer deployments. That is why, it would be appropriate to say that there are two parts to the viable cloud operation – one is the computing technology that enables complete management features and the other is operational maturity. You overlook any one of them and the cloud can become unviable for operator/MSP and customers in the long term.

 

Additional references:

Wireless Field Day 5, AirTight Cloud Architecture video

Aruba Debuts Bare-Bones Cloud WLAN at Network Computing by Lee Badman

Next generation cloud-based Wi-Fi management plane

Controller Wi-Fi, controller-less Wi-Fi, cloud Wi-Fi: What does it mean to the end user?

AirTight is Making Enterprise Wi-Fi Fun Again

Different Shades of Cloud Wi-Fi: Rebranded, Activated, Managed

 

802.11ac, 802.11n, Cloud computing, WLAN networks , , , , , ,

A tale of the two WLAN controllers, do we need to be chasing our tail for the WLAN security?

January 31st, 2012

Right when the Wi-Fi access and security management are moving towards the controller-less architecture, another interesting architecture seems to have evolved at the other extreme. This architecture seems to be advocating not one, but two WLAN controllers in tandem – and that too from two different vendors. And, some optional (additional?) security management servers on top of the tandem. You think I am kidding? Then check this announcement from Aruba Networks, which is a leading controller-based WLAN vendor: http://www.arubanetworks.com/solutions/by-application/byod-services-on-your-existing-wi-fi/. The stated business case seems to be to put a band-aid on the Cisco WLAN’s (another leading controller-based WLAN vendor) insufficient security features.

In this case, the tandem is only for BYOD security, but as a matter of fact there are many more security gaps that will still remain to be addressed even after the twin tandem controllers are deployed. Would we need a third WLAN controller in the tandem to fill the remaining security gap, and who might provide that? Or, is it just easier to deploy a controller-less comprehensive WIPS solution (and that too with the onsite or cloud option) and secure the Cisco WLAN once and for all. Just a practical thought.

Cloud computing, Wireless security , , , , ,

Skyjacking attack – then Cisco, now Aruba?

July 18th, 2011

Skyjacking Cisco WLC Aruba Mobility Controller AirWave Wi-Fi WIPSRecall “Skyjacking” vulnerability discovered with Cisco LAPs couple of years ago? It allowed hacker to transfer control of enterprise Cisco LAPs from enterprise WLC to hacker controlled WLC in the Internet with over-the-air attack. Once control is transferred, the hacker could change configuration on those LAPs in any way by adding, deleting and modifying SSIDs. The hacker could also tamper with Cisco monitor mode APs and take away the security layer. Cisco Skyjacking exploited vulnerability in Cisco’s over-the-air controller discovery protocol. Know more about it here 

Now a similar vulnerability seems to have been discovered in Aruba OS and AirWave console. The advisory states: “[a]n attacker could plant an AP with maliciously crafted SSID in the general vicinity of the wireless LAN and might trigger a XSS vulnerability in reporting section of the ArubaOS and AirWave WebUIs. This vulnerability could potentially be used to execute commands on the controller with admin credentials.” Though modus operandi is different from Cisco, the end result is similar – transferring the control of Wi-Fi controller to hacker by launching over-the-air attack.

No system is free from vulnerabilities and such things will continue to be discovered. But, you don’t have to give away “hack one, get one free”. You don’t have to give hackers control of Wi-Fi coverage and Wi-Fi security in a single shot. This can be achieved by ensuring that the Wi-Fi security layer operates independent of Wi-Fi infrastrucutre.  Read more…

Best practices, Wireless security , , ,