IoT Fly By

Just as we thought everything was stabilizing after the big BYOD rush…here comes its big brother…IoT.  As soon as you dig into the nuts and bolts of IoT, you realize that Wi-Fi infrastructure suddenly went from being “caught up” or in some cases “ahead of the curve”, to being way behind the curve again. ARGH!

I see bits and pieces of what I would call IoT Readiness scattered across a variety of Wi-Fi vendor solutions. There are a variety of IoT Readiness options, some more important than others, and urgency depends on the market(s) served by the equipment vendor.

iPSK

I wouldn’t expect to get many arguments if I put security as the highest priority. Most existing and forthcoming IoT devices will have PSK security only. It’s sad, but it’s reality. No 802.1X, no stateful firewall, no MDM. Just PSK. If an intruder hacks into one, he’s hacked them all…and you, Mr. Network Administrator, just lost your job.  Why? Because your boss’s boss’s head is now on the chopping block for trusting you with something that can wreck the company’s income and brand. #GoodJob

Somebody has to be the scapegoat after all…and how many VPs and CXOs do you know that, given a choice, would rather lose their job than have you lose yours? This IoT stuff is serious business and will make handling BYOD look like child’s play.

What’s an Administrator to do?  There are essentially two options: 1) resist the IoT invasion until it overwhelms you and then change career fields, or 2) push your equipment manufacturer to discuss with you their IoT roadmap and to listen to your concerns. No enterprise or mid-market Wi-Fi solution currently on the market is fully (or even modestly) IoT ready. Depending on vertical market and geography, we have 2-5 years before being utterly overrun with IoT devices, and it’s already ramping up as I write this.

Enter iPSK. This is my own generic terminology for “Individual Preshared Key”.  To my knowledge, there are only two semblances of such technology on the market today: Aerohive’s PPSK & Ruckus’s DPSK.  Both have their place and their benefits, but if asked to say which is more IoT ready, I would choose PPSK due to its scalable, cloud-enabled, more flexibly distributed implementation. That’s certainly not meant as a knock against Ruckus’s implementation because it has some cool advantages of its own.  There are numerous papers on how each of these proprietary implementations work, and security mechanism mechanics are not the point of this paper. More important than comparing PPSK and DPSK is to notice that they are the only two Wi-Fi companies with such a security feature. Why-o-why, after so many years of Wi-Fi technology maturity, is it only these two companies who have such a feature?

Even though I would consider PPSK the best iPSK mechanism available today, I would also offer that it isn’t yet IoT ready. I took the time to look into Aerohive’s roadmap, and some of the goodness that surfaced was ID Manager’s API.  While I would consider it a work in progress, it still seems to be the only one of its kind.  When assessing PPSK’s IoT readiness, an immediately-found stumbling block was that PPSK is currently designed for user-centric environments (e.g. BYOD) and needs the simultaneous ability to address device-centric environments (IoT). With IoT, there are likely to be many device groups on the network, each with their own security filtering and traffic shaping.  Many of these groups will be for user-less devices, meaning, for example, that the Wi-Fi device could be a sensor of some kind.

WIPS

Wireless Intrusion Prevention Systems (WIPS) is a polarizing topic in the Wi-Fi market. Some believe in it, some don’t. Some want the minimum, and some the maximum. Most opt for infrastructure-integrated WIPS features, but some swear by overlays. All of that opinion-spewing is fine when protecting your infrastructure is the primary goal, but the game changes with IoT.

• Very High Density (VHD) deployments will be the norm due to BYOD and IoT combined
• APs can’t feasibly go off-channel for scanning in VHD scenarios, so any monitoring must be done by overlay WIPS scanners
• Lack of appropriate client security (e.g. scalable, flexible iPSK implementation) means that PSK-secured clients will need full-time monitoring against intruders
• IoT devices are unlikely to have integrated stateful firewalls or the ability to be monitored/controlled by MDM, so WIPS becomes even more important.

The ratio of WIPS scanners to APs will have to be reduced.  In the past, WIPS was just WIDS (detection), and being able to hear threats was good enough.  Now, sensors must respond to threats, and so must be close enough to clients and APs to be effective.  Additionally, in order to spend enough time on-channel to effectively monitor so many clients, the Sensor:AP ratio will likely be around 4:1, but that’s an early-on guess based on experience.  It could certainly be different based on unique scenarios.

I think it’s fairly obvious that adding 1 sensor for every 4 APs could get costly, because for every deployed sensor, there’s also cabling, management, licensing, PoE switch port, and other associated costs.  In order to minimize these costs, it’s my hunch that many end users will use their recently-replaced access APs as dedicated sensors.  Since network administrators will already be familiar with the configuration and monitoring interfaces of their infrastructure system, then using, for example, 3×3:3 802.11n APs as dedicated sensors when they are replaced by 3×3:3 11ac APs makes good financial and technical sense.  Essentially, it’s a hybrid WIPS deployment model that you could call “Self Overlay.” No matter how you feel about WIPS, as a feature set or an overlay solution, it’s lucked out in that IoT will breathe new life into it.

Note that when deploying WIPS, there are some risks that you need to be aware of.

Very High Density (VHD)

In 802.11 standard lingo, we have fun PHY naming such as High Throughput (HT) and Very High Throughput (VHT). If the IEEE can get away with such bland naming, I suppose that I can too.  With BYOD, he have High Density (HD).  With IoT and BYOD, we have Very High Density (VHD). Let’s then add some color to such naming.

There are a large variety of environments that we would call high density today, so the term High Density is not well defined. If I were to put a general number on HD, factoring in multiple vertical markets and daily scenarios and factoring out extreme corner cases like stadium bowls and arenas, I would say 60 clients per AP would be a good number to start with.  Most enterprise APs can support around 100 client devices per radio when traffic is encrypted. Due to client device limitations/shortcomings, RF interference, 802.11 protocol inefficiencies, and available channel space, it’s almost always considered a bad idea to go beyond 60 clients on a 2.4GHz radio, while a 5GHz radio can usually support the 100 client devices without it turning into a total train wreck.  There are more variables than I listed, but you probably get the picture as I’ve described it.

When moving to an IoT-burdened VHD scenario, It will be common, over the next 5 years, to come across APs that have upwards of 500 clients associated to them. There are some product changes (e.g. Access Point hardware and software features) that will have to be made to successfully support that number of client devices, such as:

• two band-unlocked radios per AP, each that can be used on 5GHz
• much higher client count capability per radio (e.g. 250+), with encryption support
• more sophisticated* airtime fairness, QoS, and rate-limiting functionality

*Wi-Fi needs long transmit bursts to be efficient and to maximize capacity, but rate limiting can needlessly reduce burst size.  In some cases rate limiting algorithms that try to smooth traffic will result in poor capacity.  In many cases, even a fairly high individual rate limit (e.g. 20Mbps) can result in severe capacity reductions. 

There has been much chatter about MU-MIMO helping with protocol efficiency over the last few months.  The best review of this technology that I’ve seen so far is found here. It’s my opinion so far that MU-MIMO will add minimal value toward solving VHD scenarios.  Perhaps testing will show otherwise when APs supporting it are released. We can always hope.

Device Management

Instead of “Internet of Things (IoT)” or “Internet of Everything (IoE)”, it should’ve been called “Internet of Diverse Unmanaged Networked Gunk.”  #JustSayin

Managing this tidal wave of endlessly diverse devices, each having its own limitations, will be complex to be sure. Perhaps we need a new baseline device management framework to which all wireless-enabled client vendors must adhere, or risk being eternally shunned.

In the early days (i.e. now) many IoT devices will be Bluetooth enabled instead of Wi-Fi enabled, but they will proxy through Wi-Fi enabled devices for their Internet access. Suppose you have 50 different kinds of wearable IoT devices (very reasonable for even a smallish company), 20 kinds of sensors and cameras, and a host of other random stuff like printers, personal cameras, picture frames, and pens….yes, pens.

Will your help desk support these devices if users complain about them not working? The short answer: yes. You may even have to hire a consumer wireless device “expert” to support these types of devices to keep your employees happy (including Execs).
If your company has 10,000 employees, I shutter to imagine the fun times you have ahead of you trying to manage this…uhhh… crisis. It’s a great time to be a Wi-Fi consultant. 🙂

Devinator’s Diagnosis

I’m hopeful that Aerohive will beef up their PPSK implementation, and if they truly want to impress, make PPSK an open platform.  That said, we know that Aerohive needs to make money, as they are a public, for-profit corporation.  It’s my humble opinion that since they have a big head-start, a mature, cloud-based implementation, APIs, and want to sell more software (e.g. ID Manager), if they make this security platform readily available, it would put them in the driver’s seat of a rising tide of IoT security implementations.  In other words, they could spearhead an innovation shift that they are already in front of. Isn’t that how Cisco often plays the game? 😉  Anyone remember ISL…or CCX?  IoT is big…game-changing big.

I’m also hopeful that Ruckus is working on similar upgrades to DPSK, as they too now have some cloud goodness.  For other Wi-Fi vendors who think that the iPSK security approach doesn’t have a bright future, I would mention that I’m currently amidst a PPSK-based network redesign that includes ~1200 APs and ~30k devices across a large school district, whereby IoT readiness is a major consideration. 802.1X/EAP is often:

• too complicated (e.g. lots of moving parts within the solution and lack of uniform EAP support across thousands of devices)
• too restrictive (e.g. no uniform fast/secure roaming support across a large variety of client devices)

I believe IoT will not only transform our networks, but society in general. It will change out we work and live our lives, both for better and worse, depending on how you look at it.