Make OFDM Great Again

So 802.11ax promises to “reinvent” our dear OFDM technology and bring us to a new promised land of OFDMA. Fly your wireless networking expert flag with pride with this t-shirt!

https://www.zazzle.com/make_ofdm_great_again_t_shirt-235065886507498299

Capture

No, that ain’t me wearing the shirt sadly.

Building your own Battery Pack

Snapshot

So, you’ve built your predictive design and now it’s time for the rubber to meet the road – the infamous AP-on-a-Stick survey. To perform this piece of your wireless design you’ll need a lot of “unique” gear… tripods, laptop shelves, tons of wireless adapters, APs, and enough battery power to get you through the day.

When I was building out my survey kit, I noticed one flaw with the “professional” battery packs built for wireless surveys. Beyond being very bulky and expensive, the majority of them only support 802.3af. The newer and larger APs often prefer 802.3at (also called PoE+) these days. In some cases, they can use 802.3af, but they turn off several spatial streams in the 2.4GHz radio to adjust for the lack of power.

That’s less than ideal, isn’t it?

Thanks for the Internet, I was able to cobble together a pretty affordable battery pack that supports both 802.3af and 802.3at and lasts an incredibly long time. Here’s the pieces and parts that have worked for me:

Intocircuit 26000mAh High Capacity Battery Pack

Tycon Systems TP-DCDC-2448GD-HP DC Converter

Power Jack Adapter Plug

The total will run you about ~$140.00 and it lasts for an extremely long time. Just power up the Intocircuit, hook it up to the Tycon converter using the adapter, and connect your AP. I’ve used it for several gigs now and despite looking a little “homemade,” it does the trick.

Aruba UAP Boot Process

aruba_question

There’s been many exciting announcements at the Atmosphere 2017 conference and it’s been really great to meet a bunch of the fellow wireless twittersphere. All in all, definitely worth the time to attend.

Many other wireless minds have been covering a lot of the “cool” stuff – new ArubaOS8, new machine learning analytics with RASA and Niara, new monitoring tech with Airwave Glass and Clarity Synthetic, crazy new ways of wireless with 802.11ax, and more.

But one thing that really stood out to me personally is the new Univeral AP code that’s being rolled out to their new APs. Those of you familiar with Aruba know that there used to be two primary “versions” of hardware – Instant and Campus. Campus APs were meant to be used with a controller and they were sold without region locks, assuming that the controller would handle the regulatory compliance. The advantage was that they locked in real quick to a controller with auto discovery. The disadvantage was that there wasn’t a supported way to flash them into an Instant system, so hope you like those controllers you got there. The Instant APs had more intelligence at the edge and had region locks baked in at order, and they could move back and forth between Instant and Controller architectures – but to have them discover a controller required manual intervention, meaning that converting a large scale Instant roll-out into Campus methodology was a pain in the ass. Both were sold at the exact same price point.

The new “Universal” code means that an AP can become either a Campus or Instant AP from birth without any funky conversions. The self discovery process has become much longer though, so to spare you from any hand wringing as the APs slowly toddle towards configuration, here’s the new boot process that was shared at Atmosphere 2017:

  • Static master assignment preconfigured
  • DHCP based discovery using DHCP options assigned by DHCP server
    • NOTE – This uses option 43 to give the controller IP address to the AP
    • NOTE – make sure you don’t have another service utilizing DHCP option 43, I have seen that cause random problems with redirecting the AP to something completely unrelated
    • NOTE – The AP has to have basic DHCP and DNS discovery for any automated discovery to tick. If it doesn’t, it will reboot constantly. Yes, you will need to edit the CLI config to allow APoaS site surveys
  • Aruba Discovery Protocol based discovery
    • NOTE – this only works if either the controller is in the same broadcast domain as the AP or if multicast forwarding is configured (multicast address used is 239.0.82.11)
  • DNS based discovery (this is what Aruba recommends as best practice)
    • NOTE – the AP will look for aruba-master
  • Instant Virtual Controller Discovery
    • NOTE – this means that the AP will reach out in its own broadcast domain with the PAPI protocol to find a local Instant AP that is elected as VC
  • Airwave Discovery
  • Activate Match Airwave
    • NOTE – Activate is Aruba’s cloud based provisioning service. The AP must be able to communicate on the Internet for this step or the following two to work.
  • Activate Match Central
  • Activate Match CAP/RAP
  • Broadcast Instant Provisioning SSID
    • NOTE – And here’s where you are off to the races with the Instant platform!

Quite a journey, isn’t it? Nice that we’ll be able to purchase as single SKU now though.

 

 

 

Atmosphere 2017

atmosphere2017

No podcast/blogpost this week, as I’m out living it up in Nashville with some of the best and brightest minds in the wireless networking industry! They’ve revealed a lot of exciting new features in just the first day, ranging from the ambitious machine learning based security on the internal network to the practical new wired tunneling techniques and multi-zoned APs. And yes, the presentations are more than just marketing fluff. I’ve already attended several great sessions, including a technical deep dive on 802.11ax, with many more scheduled for the next several days. More to come.

Also, the ongoing Amazon S3 outage just proves that the cloud really is just someone else’s computer.

 

 

PacketWrangling Podcast – Spectrum Analysis

cropped-blocklogo

Welcome to the first Packet Wrangling podcast! In this episode, we take a quick look at spectrum analysis technology and discuss why it’s important both for new deployments and to troubleshoot existing installations.

It’s 2017 – Stop Guesstimating!

I’ve been involved in a number of planning meetings for IT infrastructure refreshes – servers, storage, WAN, networking, wireless, you name it. Most of the time the requirements are more or less well-defined and well thought out… number of hosts, exact processors, memory requirements, connectivity to the storage arrays, VLAN assignments, and so on. All the I’s have been dotted and the T’s have been thoroughly crossed. But there’s always one noticeable outlier – the wireless network.

“Oh and… maybe 10 APs? Maybe 12 just to be safe.”

It’s 2017 and we can simulate just about everything. Why are we still using primitive thumb based rules for the wireless network?

  1. If you guess too high, you’re out a sizeable chunk of money and you may  not even get additional bandwidth.
  2. If you guess too low, you’re going to have slow/dead zones. And good luck getting management to not only buy more APs in a separate purchase, but also to pay for the cabling.
  3. CCI is a real thing. Adding more APs does not necessarily add bandwidth. It’s the laws of physics!
  4. Just “cranking up the coverage” doesn’t always work either. Client radios are only so strong, and the conversation has to flow in both directions.
  5. It’s ill advised to go with the “low capacity” model and just throw extra APs up in high density areas as needed, again due to the laws of physics. Be sure to choose beefy APs for the auditoriums, gymnasiums, and so on.
  6. One AP per room is not a valid design principle.
  7. A design will help you determine how to balance building for 5GHz coverage while not creating a trainwreck in the 2.4GHz spectrum (hint: spectrum analysis isn’t a bad thing to have running in the background)
  8. Wireless is how we connect now. If your wireless performs poorly, it doesn’t matter how slick a datacenter you’ve built to serve up the applications, people will only remember that it didn’t load properly.

There are programs available that can fully simulate wireless propagation through all kinds of floor plans and allow you to effectively preview the performance of your wireless network, all from the comfort of your own home. While it’s still advised to take some onsite measurements in complicated deployments, a predictive survey will give you a much better starting point than the infamous “1 AP per room” design.

I’ve been using Ekahau Pro myself and it’s been a life saver.

You probably won’t be refreshing the wireless infrastructure for another five years – why not ensure that it’s going to work well?

Thanks for reading this slapdash semi early morning rant. And no, I am not being compensated by Ekahau for this blog.

Exploring EAP

As discussed in an earlier blog WPA2 Enterprise allows a network to authenticate each user with unique credentials, rather than a blanket passphrase. This is done through an EAP exchange over the 802.1X framework. We’ve touched on this briefly in a post about RBAC, but I wanted to take some time to review two of the different flavors of EAP so you can make an informed decision about which one is best for your organization.

There are two predominant versions of EAP being installed today – PEAP and EAP-TLS.

Protected Extensible Authentication Protocol (PEAP)

PEAP technically has multiple versions, but they all use the same basic “protected” transfer structure. The issue with legacy EAP was that the supplicant’s credentials were transmitted in cleartext… which is less than secure, because it opened up the potential for someone to intercept a username. PEAP corrects this by using two EAP exchanges – outer authentication and inner authentication. The outer authentication is a “dummy” EAP exchange (often using a ridiculous username) that sends information in cleartext to construct a temporary TLS tunnel. Once that encryption cover is in place, the inner authentication takes place securely inside the tunnel, out of sight of roaming sniffers. Can you see why it’s called “Protected”?

The most common version of PEAP is EAP-PEAPv0 (EAP-MSCHAPv2). The protocol used for the inner authentication is EAP-MSCHAPv2, which utilizes a user name and password as the credential. When using PEAP you will need to provide a server side certificate and set up a repository of usernames and passwords for individual client authentications. When your users connect to the network they will validate the server via the installed certificate and (if the trust is there) provide their unique credentials.

This option is popular because PEAP is widely supported by client devices and it allows you to easily utilize an existing database, like Active Directory. Your end users are already used to logging in to the domain using their AD credentials, so asking them to use those same credentials to log on to the network isn’t a stretch.

Extensible Authentication Protocol Transport Layer Security (EAP-TLS)

EAP-TLS is one of the most secure authentication methods available today. Rather than using the standard username / password combination for authentication, EAP-TLS requires both a server side and client side certificate. This means that you can avoid some of the risks inherent to passwords, like a user entering their credentials to connect to the network with an unapproved device or sharing their credentials with another employee. In order to connect to a network secured with EAP-TLS the client must have been provisioned a unique certificate by the network’s public key infrastructure (PKI).

The advantage of this level of security is also its inherent disadvantage. It can be a chore to implement a PKI if you don’t already have one in place. Provisioning this certificate based trust relationship to the client can be a straightforward process with Active Directory’s Group Policy when using Windows hosts, but it can introduce complications with some brands of smart devices unless you have a provisioning mechanism in place… manually installing certificates onto smartphones can be above the skill level of some users and it will bog down your IT department significantly.

Finally, if you do choose to go with EAP-TLS as your EAP structure, be sure to put some heavy security around the server that is housing your PKI.

I don’t mean to scare you away from EAP-TLS, as it is the definitive secure authentication solution. You should just be aware that this security comes at an administrative cost. If you want to go with EAP-TLS I would recommend looking into onboarding software to help provision certificates to your endpoints, like Aruba’s ClearPass or Cisco ISE.

EAP Options to Avoid:

There are many many many other EAP flavors available, too many to effectively cover in a single blog post. PEAP and EAP-TLS are the ones that I see the most often in the enterprise, with the occasional EAP-TTLS popping up here and there. However, there are some legacy EAP options with noticeable security flaws that are worth covering here, less to help plan the future and more to help you avoid these legacy options!

EAP-MD5 – This was one of the first EAP options available. It has severak major weaknesses – first, it does not use tunneled authentication, meaning that the username is transmitted in cleartext. Second, it uses MD5 encryption, which is not a very strong encryption suite. Third, it does not validate the server, opening you up to MiTM attacks.

EAP-LEAP – The username is transmitted in cleartext, which opens you up to social engineering attacks. There are better options out there.