Apple iOS Fast Roaming with Aerohive Wi-Fi APs

Well folks, after what seems like an eternity, true standards-based Wi-Fi fast roaming is really here! I blogged back in December that Apple iOS version 6.01 added support for fast roaming with 802.11r and 802.11k. And WLAN infrastructure vendors have added support as well, with Aerohive 6.0 and Cisco 7.2 code releases.

Recently, I had the opportunity to test this functionality out on an iPhone 5 and an iPad mini with an Aerohive WLAN. I'd like to share my results with you... and I can tell you that you won't be disappointed! How do 8.5ms roams sound?!

Apple iPad Fast Roaming (1) and Aerohive AP Neighbor Report (2)

As you can see, the iPad completes the roam in 8.5ms, the time it takes to complete the 802.11 authentication and reassociation; no full 802.1X authentication, RADIUS TLS session resumption, or even 4-way handshake are required! This is the result of support for the Wi-Fi Alliance Voice-Enterprise certification on both the WLAN and client. In the tests that were captured, the WLAN was configured for WPA2-Enterprise with 802.1X authentication and dynamic keying. The initial client association resulted in a full 802.1X authentication with the RADIUS server, followed by fast roams as shown above.

Roaming with 802.11r (Fast BSS Transition) is noticeably faster than other proprietary fast-roaming methods (OKC/PKC) and it's also faster than roaming on a Pre-Shared Key (PSK) WLAN. This is because the 4-Way Handshake exchange can be eliminated by embedding the key derivation material (ANonce, SNonce, MIC, and GTK) within the Fast Transition Information Element inside the 802.11 Authentication and Reassociation frames. There is also a Mobility Domain IE that comes into play to distinguish boundaries between different WLANs (since key material must be exchanged between APs on the backend, two separate WLANs cannot facilitate fast roaming).

Here's a look at the Fast Transition IE inside the Reassociation Response (frame 18) from the AP to the iPad:

802.11r Fast Transition Information Element

You may want to review my previous post on The Many Variations of Wi-Fi Roaming to compare the frame exchanges required with each roaming method, CWNP's whitepaper on Fast BSS Transition [PDF] and blogs (here and here) to understand the key hierarchy and exchange between the initial AP authenticator (PMK-R0) and subsequent APs (PMK-R1).

Immediately after the fast roam completes, the Apple iPad submits a Neighbor Report Request within a Management Action frame. In essence, the client is requesting a list of all the neighbors from the AP in order to build a list for future roaming events. This report can be requested on-demand by the client and can help improve roam times by reducing or eliminating the need for the client station to actively scan off-channel. This way, the client has a list of nearby APs that is always up-to-date and can quickly move to another channel where it knows another AP is waiting.

Here is a look inside the Neighbor Report sent back to the iPad from the Aerohive AP (frame 21):

802.11k Neighbor Report

Unfortunately, Wireshark does not yet have a protocol dissector for 802.11k neighbor reports, so manual decoding must be performed. You can see that the Category Code is 5 (Radio Measurement) is used. Inside the tagged parameters lies the neighbor report details, which contains an element for each neighboring AP in the same WLAN and details about the AP such as it's BSSID and channel number which I have highlighted above. In this case, there is one neighboring AP with BSSID "08:ea:44:78:14:28" and it is operating on channel 161 (0xA1 in hexadecimal). Other information in the report includes AP's reachability, security policy (similar or different), and capabilities for spectrum management, quality of service, power save, block acknowledgements, and PHY type (802.11a/b/g/n).

There are three IEEE 802.11 amendments that come into play which are all bundled up in the Wi-Fi Alliance Voice-Enterprise certification.

Standards and Certification Recap
The core of fast roaming was drafted in the IEEE 802.11r amendment, defining "Fast BSS Transition"  or just Fast Transition (FT) for short. The name is derived because every individual AP radio cell is defined as a "Basic Service Set (BSS)" in the standard, and the amendment defines a method for client stations to transition (also called roaming) very fast between AP radios. It accomplishes this by defining a Mobility Domain comprised of a set of BSSs (APs) within the same Extended Service Set (ESS, otherwise known as an SSID) which have been validated. Validated APs must coordinate with each other to exchange client station details, including pairwise master key (PMK) encryption material, and perform pre-authentication of the client prior to the roam. This speeds the client roam by eliminating the need to re-authenticate the client through 802.1X/RADIUS or having to perform the 4-Way Handshake to derive pairwise transient key (PTK) encryption key material even in the case of a simple PSK network. The 802.11r amendement was ratified in 2008.

The IEEE 802.11k amendment on "Radio Resource Measurement" defines methods for information exchange about the RF environment between APs and client stations. The goal is to enable the client stations to understand the radio environment in which they exist so that they have more information to make correct decisions about roaming and performance. Stations can take radio measurements locally, request measurement by other stations, or have measurement requested of them and return the results. One interesting aspect for fast roaming is the Neighbor Report, where a client can request an AP to measure and report the neighboring APs which are available within the same Mobility Domain, including several pieces of operational information about each neighbor such as: BSSID, channel, security policy, and capabilities for QoS, APSD (power-save), BlockAck, spectrum management, and PHY type (802.11a/b/g/n). Some other reports available with 802.11k include: channel load, noise histogram, location configuration information, link measurement, and traffic stream measurements. The 802.11k amendment was ratified in 2008 as well.

The IEEE 802.11v amendment on "Wireless Network Management (WNM)" defines methods for stations to exchange information for the purpose of improving overall performance of the wireless network. Where 802.11k is concerned only with the radio environment, 802.11v expands it to include broader operational data surrounding existing network conditions allowing stations to be more cognizant of the topology and state of the network. There are a multitude of WNM services, the most interesting (for me, at least) is the BSS Transition Management capability, whereby an AP can request a client to roam to another AP for better performance or capacity. Some other services include: co-located interference, diagnostic reporting, directed multicast services, location services, multiple BSSID capability, proxy ARP, QoS traffic capability, and traffic filtering service, to name only a few. The 802.11v amendment was ratified in 2011.

Each of these amendments define numerous capabilities, of which I will only scratch the surface in this post to highlight a few. If you are interested in learning more about the services defined in each of the amendments, visit the IEEE Get Program website to download the 802.11-2012 standard, or search the web for PDF versions of each amendment.

Aerohive WLAN Configuration
Prior to being able to test and execute a fast transition (FT) roam, you need to configure the WLAN infrastructure to support the 11r/k/v features. In Aerohive HiveManager, navigate into the Configuration section and edit the SSID on which FT roaming should be supported. In the Advanced section of the SSID configuration you will see two sections, one for WMM and one for Voice Enterprise.

Aerohive Voice-Enterprise Configuration (IEEE 802.11r, k, v)

Upon checking the first check box for Voice Enterprise, you will be presented with the following notice, informing you that Voice-Enterprise requires 802.11rkv and WMM AC-Voice which will all be enabled automatically.

You may have also noticed the note which states 802.11r requires WPA2 key management. This is because 802.11r advertises FT support in-part through the Authentication and Key Management (AKM) suites in the Robust Security Network (RSN) Information Element, which was included in the 802.11i amendment and WPA2 certification program. Pre-standard WPA did not include the RSN IE and therefore cannot support fast transition. So make sure you're using WPA2 (with either 802.1X or PSK) on the SSID as well.

Save and upload this configuration to at-least two APs, which will then begin including the Mobility Domain IE, Fast Transition IE, and Radio Management capabilities in beacons and probe responses to advertise these capabilities to clients.

Note - no explicit configuration is required to enable Voice-Enterprise on Apple iOS devices. Simply run iOS 6.01 or later and join a Voice-Enterprise enabled WLAN.

Client Limitations
In addition, the RSN IE which advertises encryption ciphers and authentication and key management (AKM) methods in-use on the WLAN to clients now includes a new AKM type to advertise Fast Transition key management. Some existing client drivers have issues parsing the RSN IE with additional AKM and will fail to association to the WLAN - in fact, they won't even try. Until client drivers are updated by manufacturers to support this addition AKM type, they will be unable to join any SSID that has Voice-Enterprise (specifically 802.11r) enabled.

Therefore, it is recommended to create a separate SSID specifically for Fast Transition capable clients and migrate them over to the new SSID.

Final Thoughts
Wi-Fi roaming performance has been a painful sore spot on the industry for many years. Problems were initially obscured through the use of open or WEP encrypted networks where roaming was relatively fast due to the simple security models implemented. However, as security improved with 802.11i and WPA2-Enterprise, roaming performance became a glaring issue, often taking >500ms or worse! This impacted the usability of real-time applications on an enterprise WLAN, forcing many network administrators to rely on less-secure PSK security methods.

Some vendors responded with proprietary fast roaming methods such as CCKM, OKC, and PKC. However, this served to fragment the industry and support for these methods were spotty at best. The IEEE thankfully stepped in and ratified the 802.11r amendment in 2008, yet it has taken nearly 5 years since then for enough momentum to build to finally implement standards-based testing and certification of fast roaming through the Wi-Fi Alliance Voice-Enterprise certification program.

However, now that standards-based fast roaming is here, IT IS GLORIOUS! I applaud Apple for being an advocate for fast roaming and implementing it into their iOS platform, likely because their devices get blamed for poor performance all the time. I encourage other mobile device manufacturers to follow suit, especially if their devices are used with real-time voice or video applications.

Cheers,
Andrew

Unboxing Apps

When folders first came out on iOS I loved 'em. I thought it would help me organize all my apps and bring order to my digital chaos. And to a small extent it did, at first.

But I've found the more apps that I shove into folders, the less I use them. And i really only USE a handful of apps on a daily basis anyways.

So today I'm blowin' up them folders and unboxing apps!

Maybe just by seeing the app icons more readily I'll be spurred into using them more often. It feels so fresh and new already!

Here's what made the first-page cut on my phone:

Education Institutions want Apple Bonjour Improvements

Members of the Educause community are drafting a petition to Apple for improvements in Bonjour network services for enterprise environments with larger and more complex networking needs than consumer home networks. Specifically, they want the applications to work across routed layer 3 networks natively instead of being limited to the local subnet.

A well-respected blogger, Lee H. Badman, who works for Syracuse University writes about the petition over on Network Computing:

BYOD hype tends to center on the likes of smartphones and tablets. These self-owned devices usually do just fine on the network from the technical perspective, while causing a policy ruckus that has spawned new product markets. But Apple has a family of popular devices and protocols that are decidedly sub-par enterprise network clients, and higher education network administrators want Apple to provide some relief. 

... 

Apple has built this market niche on the extremely limited Bonjour protocol, which is non-routable and extremely difficult to scale and administer on large wireless networks. Users want to make use of these very slick living-room-oriented devices at work, as they have a lot of potential cool uses. Network admins want to help, but not at the expense of wholesale network redesign. 

So what's Apple's answer thus far to individual pleas for a change in paradigm? Find a workaround.

Solutions exist out in the market, but only from 3rd party Wi-Fi vendors. Aerohive Networks is leading the charge with the only currently available solution in Bonjour Gateway. Aruba networks has announced a solution with AirGroup, but it will not be available for quite a while yet (rumored Q1 2013 September 2012).

Apple has turned into a computing behemoth with the rapid adoption of their iOS and OS X platforms in enterprise environments. Whether it's BYOD or corporate issued mobile devices, enabling services like Bonjour across the enterprise network in a simple and scalable fashion will only become of greater importance. 


It will be interesting to see how Apple's growth in the enterprise coupled with the greater demands on devices in such environments will be reflected in Apple's product development moving forward. Will they listen to the Educasue community and the larger enterprise demands? Or will they rely on 3rd party vendor partners to continue to pick up the slack?


Andrew




P.S. - Updated the AirGroup release timing information based on feedback from Aruba.

Are Apple iPhones Misbehaving on Wi-Fi

The latest generation of mobile devices, including the Apple iPhone 4S, may be causing performance degradation on your Wi-Fi network, which could be reported as a Denial of Service (DoS) attack by WIPS (wireless intrusion prevention systems).

One of my blog readers contacted me about a disturbing finding he had and asked for my opinion (thanks Thanh). The finding in question was that the Apple iPhone, iPad, and other mobile devices based on the latest Broadcom chipsets are setting really long Duration values in the range of 10-14ms within Wi-Fi control frames (e.g. RTS/CTS-to-self). This essentially reserves the medium for the device to transmit without a collision. The problem is that this is an excessively long period of time for an 802.11n capable device, and through my packet analysis I have found that no large frame transmission is subsequently occurring. This indicates that a performance problem may exist with the devices, and may be reported as an NAV DoS attack on the network by WIPS systems.

I've also heard anecdotal reports of this being observed on HTC Google Nexus One, Apple iPad 2, iPhone 4, some RIM Blackberrys, and even on a Broadcom evaluation board. So, there is a distinct possibility that this issue lies in the Broadcom chipset used in these devices and is not isolated to Apple devices. However, I have only tested this on my personal iPhone 4S and cannot directly verify those observations. So this post only details what I have actual been able to test and observe directly.

I had a hard time believing this could be true, so I investigated myself. Sure enough, I found the behavior when I tested.

Apple iPhone 4S Large Duration Value

What you see in the figure above is that the iPhone transmits CTS-to-Self frames at regular intervals, around once every second, with an excessively large Duration value. This causes all other Wi-Fi clients to set the NAV (virtual carrier sense) to the specified Duration value and defer transmission. Essentially, my iPhone was causing a blockage of all traffic on my wireless network for 11ms at regular intervals. Definitely not good for performance.

Possible valid explanations for this behavior could be:

1) Frame aggregation with 802.11n. I did see the iPhone using frame aggregation in other instances and using an appropriate Duration value around 4ms in those cases. But I did not see frame aggregation being used after the 11ms Duration control frames.

2) The use of a Transmit Opportunity (TXOP) on a QoS enabled WLAN in order to transmit a burst of packets within a specific QoS traffic class. I double-checked the TXOP values advertised by my access point and they are using the 802.11 default values of 0ms (single frame only) for best effort and background queues, 3.008ms for the video queue, and 1.504ms for the voice queue, which are much lower than the 11ms observed value.

3) A really large frame transmitted at a really low data rate. This is possible if the iPhone needed to transmit a 1,384 byte or larger frame at 1 Mbps to get such a Duration value. But I have all 802.11b rates disabled on my AP and verified in the packet trace that the iPhone was using 24 - 65 Mbps almost all the time, with only a few frames at my lowest available data rate of 6 Mbps.

After analyzing my packet trace I can find no evidence of my iPhone transmitting any data frames immediately after the control frame containing the high Duration value. This essentially rules out all three possible explanations.

Other possible explanations would be a poor client roaming algorithm that wants to halt traffic while it goes off-channel to scan for other APs to which it could roam, or a poorly designed battery saving technique for mobile devices. However, I captured on all three non-overlapping 2.4GHz channels and found no evidence of my iPhone probing on other channels during that 11ms time period. And using this as a battery saving technique doesn't even make a whole lot of sense because clients can already notify the AP of it's power save mode and the AP will buffer traffic until it wakes up, or at worst case send broadcast traffic at the configured DTIM interval, which is usually 102ms which allows for a much longer  sleep period anyways. Regardless, the iPhone indicated that it was staying awake (in active mode) in the control frames, so it appears to have not been putting the radio to sleep.

Frankly, I have no answer to explain this behavior. I don't exactly know what is going on.

The effect on a home network is likely to be small, since 11ms out of every 1 second is only about 1% of available airtime. However, in a corporate environment where mobile devices are being introduced into the environment at a staggering rate, the compound effect could be a serious reduction in Wi-Fi network performance and capacity! Think of having 30 students in a single classroom all connected with their mobile devices, 200 in a university lecture hall, or 500 at a trade show or conference. This is increasingly likely as smartphone and mobile device penetration is over 50% in the U.S. and other countries already, and consumers are typically carrying 2-3 Wi-Fi enabled devices with them at all time. The worst-case result in these environments would be so much reserved airtime that almost no network capacity would be left for actual user traffic. Just what we need trying to support tons of mobile devices on enterprise networks, huh.

If I uncover more details, I will update this post accordingly.

Thanks,
Andrew vonNagy

Use an iPad or iPhone as a Mobile TFTP Server

As network engineers, through the course of our work we often find ourselves out in the field working at either a remote location or on an un-familiar network diagnosing and troubleshooting issues, performing maintenance, or deploying new equipment. Quite often, this also involves upgrading code on network equipment, backing up configurations, or when called in to save the day (called a MacGyver - thanks Tom for that flashback) sometimes we even have to restore configurations or download a bug-free version of code to fix an issue.

If we are MacGyver, then our Swiss-Army knife is the trusty old TFTP protocol. Sure, it can be slow. Yes, it can have trouble traversing firewalls due to dynamically negotiated transfer ports. But it is about as widespread in networking equipment as file transfer protocols can get. SCP or SFTP would be better, but frankly have not been widely implemented.

We also love using our mobile devices just as much as non-geeks! Tom also did a nice write-up on a terminal console cable solution for iPads that is now widely popular among engineers. Today, I would like to highlight another useful application for network management from an iPad.

TFTP Server ($3.99) (Developer's Website)

Now with Dropbox integration and large file size transfers (>32 MB)!
 Key features:
* Full TFTP Server
* Supports file size transfers >32MB
* Dropbox integration - upload and download files from Dropbox
* One-touch Dropbox file upload
* Block size > 512 bytes
* WiFi IP address refresh
* Full logging
* Standard "swipe" to delete files

From the description, a few features really stand out. First, it supports file sizes larger than 32 MB. This is an absolute requirement for working on modern networks. Any wireless engineer who has managed code images on a controller-based WLAN system can attest that equipment images are growing larger by the month due to the rapid expansion of feature sets and supported thin-AP platforms (which typically have AP code embedded in the controller image). Second, and this is the hook for me, full Dropbox support! Yep, cloud syncing of image files, configuration backups, licenses, SSL/TLS certificates, etc. for easy retrieval and upload to networking equipment. If there was one complaint that I have about tablets in general, it’s the lack of a file system. Well, Dropbox and other cloud services go a long way to make that a non-issue. But it requires every application to integrate with the service independently. Luckily for us, TFTP Server does. Third, it supports running in the background. This frees up the user to switch between apps and multi-task. This allows complete network management using only your mobile device; you can console into the equipment and host a TFTP server all at the same time without requiring two separate devices.

Okay, enough description about the app. Let’s start using it.

Once you’ve downloaded it from the app store and launch it, you will see the main screen:

It consists of a slider button to turn the TFTP server on or off, and handily displays your current wireless IP address (Wi-Fi only, no hosting over 3G/4G).

  

Then, there are 3 tabs that control the operation of the app:

1.       Log – displays the server log to monitor server status and TFTP file transfer progress.

2.       My Files – displays a list of the files available on the mobile device, which have been synched from the Dropbox account.

3.       Dropbox – controls Dropbox integration and selection of files to sync with the mobile device.

The first step in configuring the application is to ensure you also have the Dropbox app downloaded and signed into your account. Designate a folder as the TFTP root directory for hosting files.

Second, open the TFTP Server app and go to the Dropbox tab. Click the Settings button to configure the TFTP root directory and link it to your Dropbox account. From here you can also Upload all Files that have been uploaded to the mobile device TFTP server and store them back on Dropbox.

Click Done and go back to the Dropbox tab. A new Show Files button is now displayed. Clicking on it will now pull up the TFTP root directory on Dropbox and allow you to select files to sync with the local system. Select any files that you need to host from the mobile TFTP server, then click Done. The files will be pulled down to the iPad / iPhone.

Once the files have been pulled down, you will see them in the My Files tab.

Okay, now it’s time for an actual file transfer. From the main screen, ensure that you are connected to a Wi-Fi network and have a valid IP address. Then turn on the TFTP server.

In a separate app (or device), console or SSH into the network device and initiate the TFTP file transfer. Here, I used SecureCRT for simplicity of writing this post.

The file transfer starts, and is visible in the Log tab on the TFTP Server app.

The transfer from the mobile device is noticeably slower than hosting it using laptop or an actual server. But the trade-off which sacrifices a bit of speed for complete mobility is likely worth it for most situations, especially when out in the field and a TFTP server is not available, or is located across a high-latency WAN circuit.

You can see the file transfer completes successfully in the terminal:

Overall, the TFTP Server app works well, is bug-free from what I have seen, and allows me to use only my mobile device in many instances, making my shoulder bag a little bit lighter. My shoulder thanks you!

Revolution or Evolution? – Andrew’s Take

As a network engineer, being thrown into “enemy” territory and unfamiliar networks can sometimes leave us scrambling to perform the simplest of tasks. At the same time engineers, like everyone else, are looking for ways to “do more with less”. In our varied travels, this means many of us are looking for ways to be more productive while carrying less equipment around. Being highly mobile improves our productivity and takes some of the strain out of travel.

Using an iPad or iPhone for complete network management is getting closer to reality with applications like TFTP Server now available. It’s not all that glamorous, but hey, when is an engineer’s work really ever glamorous. The little things in our day-to-day work can make all the difference in getting the job done while keeping our stress levels to a minimum.

Having this app handy is one of those little things that makes our job easier. Hurrah to that!

Cheers,

Andrew

Disclaimer – I was provided a free copy of the TFTP Server app by the developer, but all reviews and conclusions are wholly my own and were not paid for consideration.

HP Wi-Fi Direct Printing in the Enterprise

Have you been thinking that Wi-Fi Direct will mainly be limited to consumer applications? Think again. HP just announced support for Wireless Direct Printing, which allows any Wi-Fi capable device to print directly to the printer when in proximity without connecting through the corporate network.

This solution works by leveraging the Wi-Fi Direct standard that was developed last year by the Wi-Fi Alliance and the Apple AirPrint technology that eliminates software or driver installation on Apple mobile devices. The user simply needs to connect to the Wi-Fi network that the printer advertises, then print.

Pros: Easy printing from mobile devices in the enterprise

This should help simplify support for BYOD (bring your own device) initiatives. Since BYOD typically is also designed with security restrictions around corporate network access, and printers are usually distributed throughout the network, providing access to those printers would be a management headache to say the least.

Also, mobile device printing via Apple AirPrint on a corporate network is not usable at this point due to protocol limitations that prevent printer discovery and access across layer 3 network boundaries. The ability to connect directly to the printer and print documents will allow immediate adoption of AirPrint in the enterprise.

HP Wireless Direct Printing is Easy using AirPrint
(but appears to lack any security)

Cons: Unproven security


The security issues involved with a Wi-Fi network being advertised by a printer that is directly cabled into your network are significant. Printers have historically been easy targets for attackers to gain access to corporate networks due to their lack of focus on security. Just look here! By allowing direct wireless access to the printer, enterprises risk exploitation of numerous printer vulnerabilities which could result in broad internal network access for an attacker.

HP's implementation also appears to use an open Wi-Fi network, which makes the risk even greater! The Wi-Fi Direct faq states the use of a separate "security domain" from the corporate wireless network. What this means is that security of the Wi-Fi Direct connection can be different (and simpler) than security required to access the corporate network. But that doesn't require an open connection. Wi-Fi Direct supports strong WPA2 pre-shared key security and ease-of-setup using WPS. However, HP's documentation implies a wide-open wireless network.

HP Wireless Direct Printing Appears to Lack Any Security

Recommendation: Wait and see

I can't provide a solid recommendation on this technology or use in the enterprise until I learn more about HP's implementation. I have more questions than answers at this point. The prudent path for enterprises will be to wait and see what is discovered about this solution by the community over the coming weeks / months and engage your HP account team to learn more about the solution and security features.

Additionally, verify if the printers that your organization are purchasing support this technology, what the default settings are, and what controls can be put in place to prevent use of this feature until its use is appropriately secured and approved.

Cheers,
Andrew

Mac OS X Lion Creating Wi-Fi 802.1X Profiles

Mac OS X 10.7 (Lion) does not allow manual creation or configuration of 802.1X profiles for secure authentication on Wi-Fi and Ethernet networks for typical users. In order to access an 802.1X network in Lion, users are prompted to enter credentials when joining an active network that is in range, at which time it automatically detects the authentication settings that should be used.

The 802.1X tab in the System Preferences > Network > Advanced section no longer allows manual 802.1X profile creation.

Mac OS X 10.7 (Lion) 802.1X Profile Restriction

Lion forces the use of a configuration profile which must be created from Lion Server or using the iPhone Configuration Utility (iPCU). The config file is nothing more than an XML file containing the settings and usually has a .mobileconfig extension. Since Apple has decides to stop selling the Xserver line a year ago, most administrators will rely on the iPCU.

This restriction can be problematic for engineers wishing to test various client configuration scenarios without a live network. Many enterprise environments support multiple EAP types on their authentication servers in order to support various client deployment scenarios. Therefore, an engineer may wish to switch between profiles on the fly to test multiple authentication types. Additionally, user-created 802.1X profiles only work under their own user context, and do not work for pre-login or system level network connections which are of great benefit in enterprise environments for remote management and control when users are away from their desks (e.g. overnight). Finally, it should be noted that the "auto-detection" capability during network join may not work accurately for EAP-TTLS since it assumes use of MSCHAPv2 inner authentication.

To create an 802.1X profile for Lion, download and install the iPCU:

Install the iPhone Configuration Utility

Once installed, launch it from the Applications/Utilities folder in Finder. Start by selecting Configuration Profiles on the left side, then click New.

Create A New Configuration Profile in the iPhone Configuration Utility

Give the profile a name, unique identifier, organization name, and description. Then move on to the Wi-Fi section. Configure the basics like SSID and Security Type, then select one or multiple EAP types supported on the WLAN in the Protocols tab.

Switch to the Authentication tab to configure the credentials that will be used. Most enterprise admins will want to leave the username blank and select "Use Per-Connection Password" when deploying configuration profiles to their users to prompt each user to enter their own unique password instead of hardcoding a username and password. If using EAP-TLS an identity certificate may be selected. Finally, if you are concerned about username exposure with tunneled authentication protocols, provide an anonymous outer identity value so hackers cannot compile a list of valid usernames on your network.

iPhone Configuration Utility Wi-Fi Authentication Parameters

Last, configure the trusted certificates and server certificate names in the trust tab. This allows administrators to define which authentication servers or naming conventions are allowed to authenticate users. This also prevents users from being prompted to trust servers at the time of authentication.

When the Wi-Fi payload and configuration profile is completely finished, select either Share or Export. Share allows you to send the profile via email, whereas Export allows you to export the file to your local filesystem for distribution at a later time.

Note - See this Apple help document for further instructions on using the iPCU.

To install the configuration profile, locate the file (.mobileconfig extension) and double-click it.

Install the iPCU Configuration Profile

You will be prompted to fill-in any per-user authentication fields left blank by the administrator. The profiles can be viewed later in the System Preferences > Profiles section. This is also where you can delete previously installed profiles. The associated 802.1X profile is also visible in System Preferences > Network > Advanced > 802.1X.

802.1X Profile Successfully Installed

This method is not as easy for on-the-fly testing, but should allow administrators to accomplish all necessary tasks.

Cheers,
Andrew

Wireless Display Technologies Challenge Apple AirPlay

At CES this year two separate announcements are being made that could prove 2012 to be the year of wireless display technologies. Solutions are being promoted by Intel and Marvell, with the latter in partnership with the Wi-Fi Alliance, which are looking to disrupt the current in-home and peer-to-peer wireless display market currently dominated by Apple with their AirPlay streaming technology. Will either solution be able to challenge Apple's dominance? 2012 may prove to be a defining year for the wireless display market.

Intel is announcing expanded support for their WiDi technology. Intel Wireless Display (WiDi) compatible laptops and TV adapters have been around since early 2010. It requires specific laptop system specifications, including an Intel Wireless-N adapter. Earlier this year that Intel incorporated WiDi support for DRM protected DVD and Blu-Ray content, in an attempt to expand consumer interest.

Intel WiDi streams video from laptops to your HDTV
through a compatible adapter using 802.11n Wi-Fi

Until now, use of WiDi required an separate external receiver that connected to the television display. Such single-use type devices have not attracted much attention or interest from consumers. Intel's announcement at CES focuses on embedding WiDi technology into other set-top boxes and directly into televisions through a partnership with several System-on-a-Chip manufacturers that supply the components in such devices. This should help achieve broader reach for WiDi technology by being embedded into more consumers devices and eliminating the need to buy a separate single-purpose WiDi receiver.

In another announcement, Marvell and the Wi-Fi Alliance are announcing a standards-based Wi-Fi Display technology. Marvell is a silicon manufacturer of many of the wireless chipsets found in consumer electronic devices. By partnering with the Wi-Fi Alliance, Marvell hopes to drive greater adoption of their components into OEM devices through the use of a standards-based wireless display technology that will be interoperable with the large install base of Wi-Fi compatible devices.

To accomplish this, the two organizations have developed a complete Wi-Fi display software stack that is platform independent, allowing other manufacturers to eventually implement the solution. The stack includes link provisioning, management, video transcoding, HD video transport over Wi-Fi, and content security support with DRM. Link provisioning is likely built on-top of the Wi-Fi Direct peer-to-peer protocol developed by the Wi-Fi Alliance and announced this time last year at CES, but that has not been confirmed. The Wi-Fi Alliance will launch a certification program that will be available mid-2012.

This software stack is extensible to a variety of System-on-a-Chip (SoC) platforms and can take advantage of any hardware acceleration for video transcoding and security. By incorporating this technology into its wireless products, Marvell is enabling an entire ecosystem of Android and Windows based mobile devices, Wi-Fi Display HDMI dongles, DTVs, Blue-ray players and set-top boxes, such as Google TV.

However, both technologies face an uphill battle to garner enough consumer interest and market adoption to compete with Apple, whose AirPlay audio and video streaming technology currently reigns king in the wireless multimedia streaming market.

Apple's dominance in both the mobile device and digital content distribution markets have positioned AirPlay as the dominant solution. Leveraging multiple solutions in a coherent and integrated fashion has been Apple's strength and creates an ecosystem that is compelling to consumers. Apple is able to leverage existing devices that people have with their iPhone, iPad, iPod, Apple TV, Airport Express, and Mac (iTunes) solutions and build an integrated service at virtually no cost to consumers. Furthermore, leveraging their content management and distribution through iTunes, consumers have even more reason to buy set-top boxes like the Apple TV which can also stream cloud-based content in addition to in-home streaming from personal libraries.

Apple AirPlay enables audio and video streaming across Wi-Fi networks

Intel will face problems competing due to their use of proprietary technology, which is similar to Apple's approach but lacks the device install base and content management ecosystem that is core to Apple's strategy. Reliance on Intel wireless chipsets available only in laptops and not mobile devices further hinders adoption as consumers clearly prefer mobile devices these days. And without a content management or distribution solution, Intel will have trouble convincing users to buy WiDi compatible receivers or set-top boxes.

Marvell and the Wi-Fi Alliance are taking a better long-term approach with a standards-based solution that will be able to leverage compatibility with any Wi-Fi capable device on the market. However, it will take time for the WFA to develop interoperability certification and manufacturers to integrate Wi-Fi Display capability into equipment. Ultimately, this may eventually prove to be an integrated feature of most mobile and home theater consumer electronics, but only time will tell. This solution also faces a similar content management and distribution problem as Intel, leaving consumers with a potentially dis-jointed solution.

Revolution or Evolution? - Andrew's Take
Apple clearly has an advantage in the wireless display and multimedia streaming market with AirPlay due to their end-to-end ecosystem with mobile devices and content management that has proven to be their core strength. Intel is taking a proprietary, closed system approach, which will limit device support and availability to Intel equipped laptops and a small contingent of set-top boxes. Marvell and the Wi-Fi Alliance is taking a more open, standards-based approach, but it will take time for manufacturers to adopt and deploy the technology. And both solutions still lack the cohesive ecosystem that differentiates Apple from the rest of the market.

Ultimately, Apple is able to leverage that ecosystem of devices, software, and streaming in a integrated, seamless fashion that creates greater value for consumers. Unless these new solutions can offer broad availability and compatibility across the consumer electronics industry, I don't see how they can effectively compete with Apple. Marvell and the Wi-Fi Alliance are in the best position to execute on that vision, but it will take time. 2012 may prove to be a year where these vendors test market strategy and look to gain manufacturer support, but don't expect to see a large amount of devices available on the market. AirPlay will still reign king for some time to come.

Cheers,
Andrew

Cisco Live! 2011 Wireless & Security Recap, and an Apple Rumor

Last week at Cisco Live! 2011 I attended several sessions related to wireless LAN products and would like to provide a review of the major technical announcements that I took away from these presentations. Due to the overwhelming amount of technical content provided over the course of the 6 days, I won't be providing detailed recaps of each session. However, there were several major announcements that could impact customer roadmaps that I would like to discuss.

You can also read my article on value of live events on professional development and networking on the Cisco Mobility Blog.

CCIE Wireless Version 2 - On Sunday, several of my peers attended a CCIE-W techtorial which discussed the changes to expect in v2 of the written and lab exams. I did not attend this session, but you can find excellent recaps of the information presented by Jason Boyers (IPExpert), George Stefanick (my80211.com), and Blake Krone (Digital Lifestyle). You can also find my previous review of the v2 blueprint changes.

Some of the interesting facts that I caught from other included the relative scarcity of CCIE Wireless engineers - only 45 total worldwide, and only 27 outside of Cisco. Small numbers indeed!

ISE / TrustSec Overview - Several salient details of the new ISE platform include:

• ISE bundles multiple systems under one product, including ACS, NAC Manager, NAC Server, NAC Profiler, NAC Collector, and NAC Guest Server. These roles can all be installed on a single ISE instance or split between multiple ISE instances.
• ISE is out of band and provides central policy definition and enforcement.
• ISE focused on determing both device and user identity for complete contextual policy definition and enforcement. It supports a myriad of EAP types, similar to the Cisco ACS product.
• ISE also provides policy management for non-802.1X capable clients via MAC Auth Bypass (MAB) and/or web-authentication, which is important for wired network security. 802.1X timeouts will need to be tuned much shorter than the default of 90 seconds to allow MAC Auth Bypass and DHCP processes for non-802.1X clients to continue un-interupted, prior to device profiling and policy enforcement. Pre-auth ACLs can also be defined to limit access until device profiling and policy assignment can occur (PXE boot is one scenario to consider).
• Flex-Auth aims to allow a single port-configuration to accommodate client devices of all types (802.1X, MAB, web-auth) to ease switch port management. Failover behavior betweent authentication types can be defined to meet customer requirements.
• ISE supports device profiling using many different methods, including 802.1X authentication parameters, MAC address OUI lookups, DHCP options via SPAN port / IP helper / proxy, reverse DNS lookups, HTTP user-agent via SPAN port / captive web portal on ISE, NetFlow v5/v9, and SNMP queries & traps.
• Device profiling is hierarchical, can define generic categories then drill into more detailed profiles if desired to apply more specific policies. (Example: IP Phones > Cisco IP Phones > Cisco 7960 Series).
• Device profiles can be created using combinations of gathered information from the previous bullet point to provide a more educated interpretation of what the device is. This should help reduce false positives and false negatives as well as make it difficult for someone to spoof multiple device capabilities.
• ISE fully supports RADIUS Change of Authorization (COA) which allows dynamic policy changes in the middle of client sessions if the environment changes. Previously, only support for initial policy assignment upon the initial network access attempt was supported. COA can include client disconnection, re-authentication, port bouncing, or port shutdown. Note that the WLCs support COA as of version 7.0.116.0 code.
• It supports authorization & policy management via dynamic VLAN assignment, dynamic ACL assignment, downloadable ACLs, and Security Group ACLs.
• ISE provides a new security paradigm based on Security Group Access (SGA). SGA relies on Security Group Tagging (SGT) which is hardware ASIC dependent. SGTs are assigned based on successful RADIUS authentication and attribute assignment back to the network access device.
• Older equipment such as the 3750 switches do not support full Security Group Tagging. Such platforms will rely on a software upgrade to support the SGT eXchange Protocol (SXP) which will relay IP address to SGT mappings to neighboring equipment which do support SGT. This allows end-to-end network-wide support for the Security Group Access model and a migration path without forklifting existing equipment. Note that the wireless LAN controllers will support SXP with code version 7.0.116.0 and later. For a full list of hardware and software compatibility, see the Cisco TrustSec SGA Solution Config Guide.
• SGA simplifies network security policy enforcment with ingress SGA tagging, and egress SGA enforcement based on both the source and destination SGT combinations. This reduces the need to distribute policy definition throughout the entire network, simply enforce security for central servers and data stores once at egress. See the solution guide linked above for more information.
• It currently does Not Support TACACS+, only RADIUS (focused on client authentication, not admin).
• ISE logging is much more detailed than the current ACS product, providing more information to troubleshoot authentication and policy management for clients.
• ISE and NCS management platforms are tightly integrated. The GUI looks very similar to provide consistency, and client reporting in NCS provides ISE specific authentication and profiling information for easier monitoring and troubleshooting.

See my previous posts for a review of Wireless Network Segmentation Options and Dynamic VLAN Assignment.

WLC Code Support - The legacy WiSM-1 and 4400 series controllers will not be supported on code versions 7.2 and later. The latest supported code version will be 7.0. Customers should plan accordingly and prepare for hardware upgrades in the near future if they intent on deploying new features. Note that sotware maintenance for bug fixes and security patches will continue on the 4400 platform until 2014 according to the EoL notice.

ELM aWIPS Limited HW Support - Enhanced Local Mode (ELM) WIPS will only be supported on 802.11n access points. I am not sure if this is due to hardware limitations or not, but this is a huge issue for existing customers looking to support this feature. ELM was designed for highly distributed environments where the cost of an overlay solution was prohibitive. In lieu of that target market, I would have to say that Cisco seems unwise to limit support to new 11n access points. I would venture that most retail or other distributed environments already have deployed wireless network, many with older 11a/b/g hardware. The whole value proposition of ELM to reduce hardware deployment costs gets thrown out the window with this move and really invites customers to evaluate the entire WIPS market which includes other overlay solutions. This can only be a bad move for Cisco!

RRM Modifications - Significant changes to the RRM algorithm have been made between WLC versions 4.2 to 7.0. These include fixes to eliminate pinning (the worst APs cannot improve and prevent other APs in the same RF group from being changed) and cascading (propagation of a single channel change across all APs in the RF group). For example, an AP channel change event can only cause subsequent changes to first-hop APs which are direct RF neighbors of the original AP modified. RRM is preferred over static channel and power assignments becuase most RF environments are dynamic and change over time. Cisco recommends that customers who had issues on older code versions re-evaluate the use of RRM in their environments with these enhancements.

RRM First-Hop Neighbors (purple) Are Allowed
To Change Channels, But Not 2nd-Hop Neighbors (blue)

Also, most RF designs using RRM should be designed to allow APs to operate at medium power levels (values 3-5) so that RRM can adjust power levels up or down as necessary. If the network is designed with minimal overlap and APs operate at maximum power level 1 all the time, then RRM can adjust power higher to compensate for coverage holes or AP failures.

BandSelect Recommendations In-Flux - The historical official recommendation from Cisco documentation, TAC, TMEs and other support personnel has been to disable BandSelect on voice WLANs to prevent roaming delays. Since BandSelect delays probe responses on the 2.4GHz radio, it can cause roaming delays that may impact performance of an active voice call. However, we heard from a few sources during multiple presentations that voice engineers within Cisco may have validated minimal impact to voice calls and recommending customers to turn it on the voice WLANs. No official change has been made to formal recommendations at this point, but may be an interesting topic to watch for changes in the future.

Cisco Stadium Wi-Fi - The new 3500p access point and 25137NP (36⁰ spot-beam dual-polarization antenna) provide focused coverage for stadium seating sections. This solution also incorporates changes to the RRM algorithm and Wi-Fi Clear-Channel Assessment (CCA) specific to supporting a high-density environment. Read more about it here.

Cisco Narrow Beamwidth Antenna Focuses on
Individual Stadium Seating Sections

Layer 3 Roaming Enhancement - New in code version 7.0.116.0 is support for layer 3 client roaming when clients have static IP addresses configured.

Redundant Controller Licensing - Cisco WNBU (Wireless Networking Business Unit) has heard customer requests for backup controller licensing instead of having to purchase redundant units with full licensing for the intended AP capacity required. However, this change has not yet been committed to by WNBU. If you are a Cisco wireless customer and deploy N+1 or N+N redundancy, you should contact your Cisco account team to formally request s this change and throw added pressure on the pile!

Multiple LAG Groups on WLCs - Cisco WNBU is also considering adding support for multiple link aggregation (LAG) groups on the controllers. This would allow more flexible deployment in scenarios where controllers need to connect to separate physical networks, most common in DMZ anchor controller deployments I would imagine. For instance one LAG group connects to physical switches that lead into the core and another LAG group leads to a different set of physical switches that lead to the Internet. Currently, the only way to do this is to not use LAG at all and use a single physical interface for each side of the connection. This limits throughput to 1Gbps maximum. Multiple LAG support is not yet committed to by WNBU, so once again, call your account team to formally request support if it's important to you as a customer.

Rumor Apple will Support Fast Roaming in iOS 5 - There was also a very interesting rumor that was brought up in Wednesday's "Design and Deployment of Enterprise WLANs" that Apple may support 802.11r Fast BSS Transition (fast roaming) in it's upcoming release of iOS5. If this turns out to be true it will be a major improvement for support of Apple mobile devices including the iPhone, iPod Touch, and iPad in an enterprise environment. In a corporate setting these devices are much more likely to be leveraged as a converged devices supporting voice and video integration with corporate PBXs and video collaboration systems which require fast roaming for uninterrupted sessions.

Support for 802.11r should also officially come in Cisco WLC code version 7.2, although hooks have been in the WLC since the first 7.0 train release of 7.0.98.0.

Cheers,
Andrew

Bookmarklets for Mobile Devices

I read a lot of news and like to share a lot of it with friends, family, and professional networks using various services on the web. The easiest way for me to collect, consume, and distribute this content is through social media services such as Google Reader, Twitter, Facebook, and Email. 

I'm also always on the go, and it's increasingly rare that I can devote enough time during the week in front of a traditional computer or laptop to read all the news, information, and stay up to date as much as I want to. Therefore, it's an easy investment for me to own a smartphone to consume content whenever I have a minute or two of downtime. This makes information consumption much easier and fits better into my schedule. I also recently purchased a tablet to fill the intermediate gap when the screen size of a smartphone just isn't suitable for some content, but a tablet is still portable enough to carry with me most of the time. 

However, transitioning from a full web browser (Chrome is my preference) on a laptop, to a mobile browser (Safari on my iPhone/iPad), has caused some challenges. Normally, I find quite a bit of content that is shared by others through any one of the aforementioned services, which I want to subsequently re-share or post to my social networks. In Chrome, I use Bookmarklets to accomplish this task. Bookmarklets are simply small bookmarks comprised of javascript code that performs a specific function with the content in the current browser window. For instance, the Google Reader bookmarklet allows adding, sharing and note creation of items into your Google Reader feed.

Many of these bookmarklets are provided as links in webpages, allowing full browsers such as Chrome to easily drag and drop the link into the bookmark panel. However, mobile Safari does not allow direct bookmarking or copy/paste of these javascript links.

Therefore, I have copied out the javascript contents of these links in order to install these bookmarklets in mobile Safari. The process is fairly simple:

1. Copy the bookmarklet URL javascript contents from a desktop browser (or use my favorites listed below)
2. Email the contents to yourself
3. Open the email on your mobile device
4. Copy the javascript content from the email
5. Open mobile Safari
6. Create a new bookmark while on any page
7. Edit the bookmark, name it appropriate to the service, and paste in the javascript in the "Address" section

Now, when you're browsing any content that you want to share, click the appropriate bookmarklet from the bookmark menu and the service will prompt you to edit/send the item.

Here are some of my favorite bookmarklets:

Hootsuite Post

javascript:var d=document,w=window,f='http://hootsuite.com/twitter/bookmark-tool-v2?',l=d.location,e=encodeURIComponent,p='address='+e(l.href)+'&title='+e(d.title),u=f+p;a=function(){if(!w.open(u,'t','scrollbars=0,toolbar=0,location=0,resizable=0,status=0,width=550,height=330'))l.href=u;};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else a();void(0);

Hootsuite Post (launch iOS application)

javascript:location='owly://'+location;

Google Reader Note

javascript:var b=document.body;var GR________bookmarklet_domain='http://www.google.com';if(b&&!document.xmlVersion){void(z=document.createElement('script'));void(z.src='http://www.google.com/reader/ui/link-bookmarklet.js');void(b.appendChild(z));}else{}

Instapaper Note

javascript:function iprl5(){var d=document,z=d.createElement('scr'+'ipt'),b=d.body,l=d.location;try{if(!b)throw(0);d.title='(Saving...) '+d.title;z.setAttribute('src',l.protocol+'//www.instapaper.com/j/890WCIa1VUrN?u='+encodeURIComponent(l.href)+'&t='+(new Date().getTime()));b.appendChild(z);}catch(e){alert('Please wait until the page has loaded.');}}iprl5();void(0)

Facebook Post

javascript:var d=document,f='http://www.facebook.com/share',l=d.location,e=encodeURIComponent,p='.php?src=bm&v=4&i=1265501632&u='+e(l.href)+'&t='+e(d.title);1;try{if (!/^(.*\.)?facebook\.[^.]*$/.test(l.host))throw(0);share_internal_bookmarklet(p)}catch(z) {a=function() {if (!window.open(f+'r'+p,'sharer','toolbar=0,status=0,resizable=1,width=626,height=436'))l.href=f+p};if (/Firefox/.test(navigator.userAgent))setTimeout(a,0);else{a()}}void(0)

Gmail Message

javascript:popw='';Q='';x=document;y=window;if(x.selection) {Q=x.selection.createRange().text;} else if (y.getSelection) {Q=y.getSelection();} else if (x.getSelection) {Q=x.getSelection();}popw = y.open('https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=&su=' + escape(document.title) + '&body=' + escape(Q) + escape('\n') + escape(location.href) + '&zx=RANDOMCRAP&shva=1&disablechatbrowsercheck=1&ui=1','gmailForm','scrollbars=yes,width=680,height=510,top=175,left=75,status=no,resizable=yes');if (!document.all) T = setTimeout('popw.focus()',50);void(0);

Cheers,

Andrew