SMS Authentication- A Nice, Easy Way To Do WLAN Guest Auth

For wireless guest access, there are all kinds of ways to skin the cat. In a perfect world, Hotspot 2.0 will take care of authentication and encryption, and all would be sunny to everyone's satisfaction. But, that ain't happening for a while (if ever). It's becoming more popular to tie guest access to social media "credentials" (a bit of a joke to call 'em that), as there's usually some marketing hook behind that, and some networks really don't care WHO you are, like really.

But when you need to have some level of accountability on your guest network for whatever reason, using SMS-based authentication is not a bad option. You can front it with a WPA2 PSK or leave it open (everyone has different use cases, business drivers, and policy), but for answering the challenge of "make it easy on 'em but still let us have some bit of real, verifiable information to tie to a person", SMS-based auth is hard to beat. 

Years ago, I set off on a quest to find a wireless guest solution that was easy to support, easy for users to self-provision through, and that met our organizational requirement that guest sessions not just be tied to some bogus email account (the joey@asscrack.com thing is funny only so many times in a row) but to use 10-digit cell number as the "User ID". Though we were a Cisco WLAN back then, Cisco couldn't come close to fulfilling our simple requirements. Rumor was that Coloubris had a gateway that might work, but this was around when HP bought them and we literally couldn't find a human being walking the earth that could tell us anything meaningful about that gateway. Then there was Bluesocket (now ADTRAN). When I first approached them with my needs, they- like Cisco- couldn't do the self-provision SMS based thing. And like Cisco, they tried telling me that if I was willing to change my requirements, they could provide a solution. But when I pushed back, Bluesocket was willing to do a little bit of development and was able to provide something that really was ahead of it's time (we're talking like 2006 here):

 

Sure, it's not so impressive today given that there are now lots of other guest portals that do SMS, but it still works very well, and is what we continue to use at my University because it does work well. Unfortunately, you have to invest in a full-blown Bluesocket appliance to get the functionality, but even that's not all bad.  The appliance works well as DHCP, firewalling, NAT, rate limiting, quarantine, MAC exception home for odd stuff that fits nowhere else and a handful of other guest-relevant functions, but also has (and is over-priced based on) lots of Bluesocket-specific WLAN stuff you'll never use if you don't have Bluesocket APs. And the appliance hardware is pretty dated. But... on balance, this has been dynamite- and is the only off-the-shelf 3rd party gateway kind of thing  that I'm aware of that you could bolt on to anyone's WLAN and make work if you didn't like what your native solution does for guest access (Sorry Cisco, you still don't get it as far as I can tell).

Then there's Meraki's version. The SMS auth groove is new to Meraki, and they still have some development to do on it before I'll sing it's praises too loudly, but it works well. I'm about to deploy it in a unique situation, and am pretty pleased with it's slick integration to Twilio as the SMS provider, and that I pay nothing extra to Meraki for exactly the SMS auth feature I want:

 

No extra appliance needed, no additional fees, and it works so, so nicely with the rest of the magic in the Meraki cloud-managed wireless solution.  Where it is feature-thin, I can work around until they tighten it up (and I did make my wish last week, so I'm assuming the elves on Mount Meraki are almost done already). It only works with Twilio as the SMS service, but that's OK as Twilio is cheaper than cheap, and each texted password costs you a penny. (We use Message Media for the Bluesocket, is more expensive and less snappy in my experience).

Anyhow- If you've never gone the SMS path for guest access, I can vouch for it's effectiveness. Though I personally have no use for social media logins, I understand the appeal in certain markets (but would never use my own accounts for guest access- I'd rather go without). SMS is just another option to consider. Combine it with Personal PSK, and I think users and admins would both win, at least in my wireless world.

Pssst- If you have a Dashboard, Meraki is easy to try- and you get 25 free Twiio interactions so you can feel what the experience is like for texting the auto-generated password from your own easy-to-customize splash page before signing up for a Twilio account.

(I find Twilio almost as much fun to say as LaserFiche, by the way)

Bummers in WLAN Land

None of the following gripes are the industry's biggest problems. At the same time, they are nuisances and occasionally rise to the level of major headache. Some of these apply to WLANs of all sizes, others are far more applicable to bigger wireless environments. The remainder? They're just goofy. If any one of these were to be corrected or adjusted a bit, the wireless world we live in would be a little sunnier. In time, each and every one of these will "age out" and cease to irritate, but for now they are fair game to call out into the light  of day. I got me a license to bitch, and here it comes, in no specific order:

• Why are those cheap bastards at the laptop factory still putting out 2.4 GHz-only capable computers? It can't cost more than a couple bucks to provide a dual-band adapter in even the cheesiest laptop during manufacturing. Yet you have to look fairly hard, and often get into some serious upgrade dollars, to find a consumer-grade laptop (beyond Macbooks that come with dual-band 11n in all cases) that features both bands. It's almost unheard of in the "Sunday Specials" that feature prominently in the BYOD demographic. We all suffer for the side effects, and it's about time Acer, ASUS, Lenovo, and the other economy-class PC makers stepped up and became better citizens of the WLAN community.


• What's Up With Gartner's Quadrant When It Comes to Wireless Vendors? Gartner has always been a bit polarizing in their analysis of various technology sectors, but they flat out blew it with eliminating the WLAN-specific quadrant in favor of including only "unified" vendors.  It boils down to these:
  
  
  
  • Sure, some vendors make Ethernet switches and wireless APs. But in many environments, switches do little more than provide PoE for APs. Big flippin' deal.
  
  
  • When a company as radio and antenna savvy as Ruckus can't make it into The Quadrant because they don't have switches, there's something seriously wrong.
  
  
  • A Unified Quadrant isn't bad, but it's incomplete and therefor a disservice to the industry. It's time to bring back a WLAN only Quadrant, and a switching-only view IN ADDITION TO the unified Quadrant.
  
  
  
  


• Apple really missed the boat by not including 11ac in their very expensive new iPhones. The Big A should be a better steward of the client device space's future. If Samsung can do it, so can the Gods of Cupertino's Mountain of Cash. Instead of breathing life and craze into early 11ac adoption, Apple cheaped out and disappointed the fans (and wireless admins) that were hoping for more out of Apple's phone, especially for the money.


• Apple's Bonjour. Enough already. Fix it, and do your part to provide some pain relief to the wireless shepherds of the BYOD fields where your gadgets roam free.


• Cisco's Wireless Management System. It's WCS! It's NCS! It's NCS Prime! It's Prime Infrastructure! Whatever it's called this week, it's still buggy, slow, frustrating, and demanding of it's own FTE staff just to keep it breathing at times. To think about putting switches into this same management framework as wireless on very large networks as "unified" gets deeper into the management paradigm is the stuff of horror- unless we see a major overhaul soon. Too much of the WLAN market relies on this sometime-train wreck to not improve it.


• The Fallacy of Interoperability and Standards in the WLAN Space. Sure, we check our wireless devices for the famous Wi-Fi Alliance seal of approval that should mean all is well when devices need to talk with other devices, but there's a lot more to the equation. Consumer-grade stuff often doesn't play well in the Enterprise but nothing on the packaging explains the delineation. And... I can't mix and match enterprise WLAN hardware or features like I can Ethernet switches. This is arguably the way it has to be, but its also a royal pain in the butt at times. Vendor lock is real, for better or worse.

We've all got things that steam our clams when it comes to wireless networking. These are on my short list this week. The world certainly doesn't have to change on my say so, but at the same time time I can squawk about it, by golly.

Look A Bit Beyond WLAN RF

The RF part of wireless networking is often what keeps good IT folks from really getting proficient with WLAN, and many good WLAN types never look beyond the frequency ranges used in 802.11 technologies to see the bigger RF world that we live in. It's understandable, especially for those without some sort of professional or hobbyist background with signals. The world of WLAN spectrum can be hard enough to wrap your head around, but every now and then there is value in seeing the bigger "comms" picture. The more you understand about the way different frequencies behave in the most basic sense (and what services use those frequencies) the more comfortable you'll become with really understanding the more mysterious parts of both access-type WLAN and point-to-point bridging.

There are masters'-level classes on RF and radio technologies, tech training courses, and infinite online tutorials and calculators covering all the variety that falls under the broad heading of "learning about RF and RF systems". This is one of those areas that you never, ever stop learning about. And once the bug bites, it's not uncommon to become a radio-technology junkie who's interested in far more than just the goings on in the 2.4 and 5 GHz slices of the electromagnetic spectrum.

Let's look at just a bit of information on "commonly used" frequencies:

• How long are their wavelengths


• What are their natural "free space path loss" characteristics (how they "fade")


• At a common power and antenna config, how do they behave compared to each other?

Sounds like heady stuff, yes? It's really not that bad- so stay with me here.

The following frequencies have meaning to me, and certainly to many of you as well. I'll give you the wavelength of each, and tell you how much the signal fades after 1 km based on these values applied to each frequency:

• 100 mW (or 20 dBm) of power


• Simple 3 dB antenna at the transmitter and receiver

Whether the signal would be usable (any signal left after path loss)



(Table created by me, there is some minor rounding done)

Again, we see that with same power and antenna gain/sensitivity, the frequency in play makes a dramatic difference to what's available (or not) at the receiving end.

The frequency is a product of wavelength;  the lower the frequency gets, the longer the wavelength is. Lower frequencies also tend to require bigger antennas.

But this little exercise is of limited practical value, beyond helping to understand basic aspects of RF behavior at each of the frequencies I chose to show. High gain antennas, increased power levels (some technologies like Wi-Fi are limited to miniscule power levels while other technologies measure their outputs in Kilowatts), and environmental factors all influence the basic RF goings on at each frequency. Modulation types, quality of engineering, CPU and other silicon behind each given technology all also define performance of whatever technology is in play for a given spectrum. As I mentioned before, it does get complicated.

One of my favorite communications-oriented RF tutorial sites is at National Instruments. Although the American Radio Relay League (ARRL) is often thought of as a ham radio organization, they have a wealth of resources on all sorts of RF-related technologies and industry happenings.

If you've never built an antenna of some sort or another, you should. Whether it be a simple project for Over the Air TV or something weird for wireless penetration testing, its worth doing at least once. Research it, build it, improve upon it, and see how altering it changes the performance of whatever your application is (could be using a scanner to hear the local police comms or doing your own point to point wireless bridging), it's fascinating to design and build something RF-related, at least once. You'll find that seemingly unrelated wireless disciplines really do enhance the understanding of the actual wireless part of wireless networking.

Wireless Standards Just Aren't Enough

First the love:

Anyone in the wireless game, like really in it, knows that wireless networking is incredibly complicated under the hood. That the IEEE and the Wi-Fi Alliance could herd enough cats to get us to where we are today- enjoying our 11ac honeymoon- far from the days of early 802.11 is amazing.

Let's pause for a moment and think about how far we've really come, because it is impressive indeed. From a technology that was an expensive accessory at one point, with low data rates, high prices, and anemic security, to being the preferred method of access today for most of us, with rates and security features that are fitting for any environment (when installed right), wireless has grown up.  A huge thank you to everyone involved, as you've given me the best job in the world- that of a WLAN professional.

Now the lament:

As impressive as the modern WLAN is, somehow we ended up with some crazy market fragmentation and mindsets. Even though interoperability testing mostly keeps the wireless train on the rails, we still end up with enough in-place chaos to make life pretty miserable for wireless clients and support staff at times.

Maybe we try too hard for backwards compatibility. Perhaps device makers are lazy or out of touch, or could it be that the BYOD comet just hasn't caused enough pain to really get everyone's attention? For sure, the fuzzy, often-bludgeoned distinction between consumer and enterprise-grade components doesn't help matters.  Here's what I mean:

- In a world where we're talking about "Gigabit Wireless", we still have device and instrument manufacturers churning out chipsets that need 1 and 2 Mbps data rates to behave right. These devices are frequently intended for networks that aren't likely to have those rates enabled.

- Printer manufacturers have far deeper roots in the business environment than does wireless. Yet, we can't get printer makers to understand what their devices need to do for desired functionality on the "business WLAN".

- What we call BYOD is actually BYOD/T; that is bring your own device AND TOYS to the WLAN. If it works at home on the living room network, you know damn well people are going to want to use them at work. Like AppleTVs and Google Chromecasts. To the uninitiated, you look at the specs on the packaging and see "compatible with 802.11n/g" or whatever, and jump to the conclusion that it must work because that's the kind of network we're using. The  warning label that should say "check with your networking department before buying this for office use" never makes it to the packaging.

But... rather than having to explain to users why this gadget or that can't work on the WLAN, or killing ourselves to put in hyper-complex, house-of-cards-quality work-arounds, wouldn't it be nice if somehow the Community of Wireless Client Device Makers could get with the times and build compatibility for both consumer and enterprise networks in to begin with?

Just supporting enterprise security would help immensely, and likely add little to the device cost. (I'm astounded at how out of touch the business printer/projector makers seem to be). There are certainly other nuts to crack as well before everything is perfect between the WLAN and BYOD/T devices, and Apple could be an absolute leader here. Bonjour has long had it's day, as I've bitched to anyone who will listen.  "Apple TV is perfect for the boardroom" provided that you have one small flat network and one boardroom. But when you have hundreds of boardrooms/classrooms and complicated LAN topologies, devices like the Apple TV are a supreme pain in the assbone. If Apple could do right by the customers who continue to fatten the company's immense bottom line and give us something better than Bonjour for their devices in the workplace, maybe other device makers would follow suit. (Did you know that higher ed is begging Apple to provide relief from Bonjour headaches?)

Maybe we need tighter "categories" from the Wi-Fi Alliance- with devices that are labeled either "Enterprise Ready" or "Consumer Grade". This would give incentive for the lower-end stuff (including Apple's Bonjour-based devices) to step it up. It would also give a clean delineation for networkers to point to for device support. If done right, We could say "if it's got the Enterprise-ready label, we support it" and if not, don't bother bringing to us. Everyone would know where they stand, as the criteria that goes into an "Enterprise Ready" compatibility testing program would be based on far more than just whether radios can talk to each other. It's a nice thought anyways.

Ah well- end of rant. Now if you'll excuse me, I have to go explain why Chromecast doesn't work on our 802.1x-based WLAN.

How WLAN Vendors Can Solve The College Dorm Problem

Ladies and gentlemen of the WLAN industry, here are the problems with wireless networking in college dorms, and a head start on how you can develop a solution.

Problems:

1. College dorms are usually covered by the same enterprise 802.1x network used on the rest of campus, but are really more residential feeling at the operational level.
2. Wireless printing doesn't work where you have hundreds of anything-goes printers with no coordination on the same WLAN- and consumer-grade $40 printers don't support enterprise security.
3. Game consoles and Bonjoury toys also are fraught with problems and usually need yucky work-arounds on the business network usually found in dorms, or get relegated to the wired network.
4. Rogues get installed to get around what campus WLAN can't easily provide
5. Ditching the enterprise WLAN and letting students bring their own wireless routers is a recipe for chaos and angst from the RF and support perspectives.

Solution:

It's not cut and dry, and my enormous cranium hasn't yet formed the whole solution. But it starts like this:

1. Keep all the benefits of a centrally-managed solution. RF coordination, central monitoring and configs, etc- whether cloud-based or local not so important here.
2. Study PowerCloud's Skydog network paradigm. Everything about it doesn't fit the dorm challenge, but a lot of it does. If you can treat each dorm room as an apartment, with a dedicated SSID or some other compensating control (not all dorm rooms would need their own AP) we'd be off to a good start
3. Maybe use elements of Ruckus' Secure Hotspot in a way that lets a single student or roommates have all of her/their gadgets in a little "private WLAN" all somehow using the same private PSK.
4. Make sure any one student's most common gadgets can all interact in their own little WLAN space (even Bonjour toys and printers), that it's all easy to self-setup, and can be administered by WLAN admins if trouble hits. 
5. With all device types accomodated, the reasons for rogues are eliminated.
6. Make sure students can't get to each other's stuff, but allow for on-demand temporary access when sharing is desired.
7. Make sure that however it all gets put together, the RF environment is still well-coordinated.

There- that was easy. Now someone just needs to build the code and interfaces... 

 

 

Here's What I Want NOW From My Wireless Management System

When it comes to the management and security of wireless networks, I want a lot of things. I want new things, and I want legacy things that aren't going away to get better. I want slick, I want fast and I want effective. I want powerful, feature-rich, and a say in what features are worth devoting UI resources to. I want it all, baby- and here's my latest rant on the topic. You're going to love this.

Before I drop the bomb, lets set the stage.

I had the privilege of hanging out with the fellows from 7signal at the recent Wireless Field Day 5 event, and seeing how they do WLAN RF health characterization,  as well as getting a peek at what AirTight is up to. Being a long-time Cisco wireless customer, my mushy brain cant help but bring everything back to my vendor for comparison; but more on this in just a bit.

In my spare time, I've been having more fun than a person should be allowed to with the addicting Wi-Fi Pineapple (along with some tricks from the much-revered BackTrack Linux.) And at work, we're gearing up for thousands of students to flood back into the dorms, which means Rogue Hunting Season is neigh. Put all this together and feed it into the "It's Easy For Me To Demand Things From Other People That I Can't Do" engine, and out pops the following wireless support and security gem:


Wouldn't it be cool if...

• You could take one of your in-service APs and turn it into a virtual client that associates with other APs? (stay with me, I know you've heard this part before)


• Synthetic testing with said virtual client was possible: do my DHCP and RADIUS servers work? Can I reach the Internet? Can I reach other locations, from each of my SSIDs?


• The virtual client AP could report on nearby rogue networks, after I set a min threshold value, (getting closer to the money shot) and tell- Is the SSID open or protected?


• My virtual client could associate to the open SSIDs, and report back what the public IP is of the rogue?  (I could find it then through MAC or ARP tables if on my own network- doesn't need to be automated)


• Here's the LAGNIAPPE, baby- If the rogue SSID was encrypted, I'd like my virtual client to execute Aircrack-NG, Reaver, Fern, or whatever. Somehow, the power of my management system harnessed to this virtual client/pen testing-mode AP would give me a big-assed, infinite dictionary from hell and lots of power to crack. Then I could go back to the "find the public IP" step, which to me is the ultimate and definitive "game over" versus a lot of wireside detection systems that are so-so with their success rates.

I know there are lots of ways to do "wireless support", but I am enamored with the force-multiplying capabilities of a well-constructed virtual client mode for installed APs (as I imagine them working). I've been beating the drum for Cisco to consider basic virtual client functionality for years, to no avail.

But now I want even more- I want a "virtual client AP meets BackTrack Linux, and they have offspring" mode.

I'm not asking for too much, am I?

Features, Products, Services... The Differences According to Aerohive

I recently visited Aerohive's home turf as one of the delegates at Wireless Field Day 5. It was wonderful getting to meet, in person, many Bees I frequently interact with via email and social media.

My own history with Aerohive is built largely on covering their evolution from the early days, writing about them professionally in Network Computing Magazine. As with other vendors, sometimes Aerohive gets the spotlight and sometimes they get compared against when analyzing what competitors are up to. I have my own small Aerohive environment, and have first hand familiarity (not mastery, mind you) with Hive Manager and a couple of AP models.

Aerohive has been a major player in minor-but-growing cloud-managed wireless network space that includes Meraki (Cisco), AirTight Networks, and PowerCloud. 

Ah, cloud-managed networking. I've become a fan where I use it (and I do use it in a number of sites). I like that one of the running campaign themes of cloud-based networking in general is reduced hardware counts with no convoluted licensing schemes. 

Though Aerohive has done a good job with pushing the value of "here's a new feature, and you'll just get it with your next Hive Manager upgrade at no additional cost!" message to customers, I was taken a wee bit aback during the Field Day briefings on Aerohive's IDManager and Client Management services because they were called "new products" that require licensing.

Both offerings will no doubt be welcomed by existing Aerohive customers, and are easily marketed at prospective customers looking for a robust, all inclusive solution. My own little private shock at the licensing requirement doesn't detract from my overall opinion on Aerohive, and after thinking about it , I know where the surprise comes from: we've gotten so used to rich feature sets being "free" that we instinctively expect the gratis model to apply to any and all "features" Aerohive develops. Which really isn't fair to Aerohive, but is how we've been conditioned on the customer end.

I wont pretend to understand why Aerohive has "given" so many enterprise-grade services away to date that others license for, but draws the line at IDManager and Client Management. Nor do I care enough to get hung up on it, as other vendors seem to be licensing their Onboarding services as well after hearing their briefings. 

For those keeping score at home, here's a breakdown of some of what is included with Aerohive's Cloud Manager and licensed APs under the heading of "it's just in there":

• Spectrum analysis
• Application visibility and control
• Statefull firewall
• QoS
• VPN
• Partner MDM hooks
• Planner software(free to non-Aerohive customers too)
• Bonjour gateway software (also free to non-Aerohive customers)

And what you have to license seperately:

• Client Management (license blocks of 100)
• IDManager (tiered licensing, starting at 250 guests)
• StudentManager (blocks of 1000)