Thursday, September 23, 2010

H-REAP Feature Matrix

Following up on my previous two posts on Cisco's H-REAP distributed forwarding mode of operation for lightweight access points, Cisco has recently published a feature matrix for the H-REAP access point mode of operation. The matrix applies to the latest version of wireless LAN controller code.

Some notable items include:

  • No PMK/OKC/PKC fast roaming support.
    This is a big disappointment, especially considering H-REAP does support Cisco's proprietary CCKM fast roaming. Hopefully they're working on this as well as 802.11r Fast BSS Transition support.

  • No Spectrum Intelligence on 3500 series APs.
    Considering this is built into the AP and is not a controller function, lack of support is surprising. I can see why reporting and trending through the WLC and WCS would be interrupted in standalone mode, but I would think spectrum intelligence base functionality should be available for admins to connect remotely to the AP and analyse the airspace.

    Update: Just to clarify, CleanAir spectrum intelligence does work in H-REAP connected mode, but does not work in H-REAP standalone mode since the WLC aggregates and reports on the interference data.

  • No Workgroup Bridge support
    I was not aware of limitation previously! If you support autonomous WGBs, then H-REAP is NOT the solution for you at this point.

  • Supports DFS/TPC (802.11h) even in standalone mode
    This is critical to maintain compliance with FCC regulations to avoid radar in the 5GHz band. Kudos to Cisco for being one of the few vendors with support for DFS channels, allowing administrators greater spectrum to work with to increase client and network capacity.

Overall, a few interesting new findings in this document. It is definitely not comprehensive though, so don't use this as your only source for H-REAP feature support. Check our my previous blog post for a more thorough listing compiled from multiple Cisco document sources as well as real-world testing.


Monday, September 20, 2010

Update: WLC Upgrade Issue Affects 11n Data Rates

Update Sep. 20, 2010: Cisco has created new bug ID CSCti89945 for this issue. See my original post on this issue here.

CSCti89945 Bug Details

wlc upgrade to, N breaks requires wlan deletion-readdition.


when a wlc is upgrade from say or later to the wlans do not work with the N rates. a/b/g regular rates work on N capable clients


Issue is seen specifc to N rates when upgrade from lower versions to


Delete the WLAN and recreate or add the WLANs back for N rates to start working on wlc.


Wednesday, September 15, 2010

PEAPv0 Packet Flow Reference

I have created a handy reference for understanding the packet flow of a PEAPv0 / EAP-MSCHAPv2 authentication exchange.

Included are packet flows for three different authentication scenarios:

  1. Full initial authentication exchange
  2. Full initial authentication exchange including Active Directory services
  3. TLS session resumption (also called fast reconnect)

Here is a preview:

You can download the full version here. I hope you enjoy it and find it useful!


Sunday, September 12, 2010

802.11u Where Are You?

A few weeks ago I blogged about the "Consumerization of Enterprise Wi-Fi". A large component driving that trend in retail stores is the ability to interact with the consumer at the point of purchase with highly relevant and localized content. Challenges to deployment of these solutions include providing a capable last-mile connection, addressing security concerns, and probably one of the biggest (if not the biggest) challenge is usability of the solution for the consumer.

The first challenge in designing an in-store communication channel with the consumer is the last-mile (ahem, last link shall we say) connectivity. A recent cellular coverage survey of one major retailer with presence in many typical suburban shopping centers, strip malls, and even urban locations, revealed that telco coverage maps indicating good coverage of the store location did not equate to good in-store cellular coverage. In fact, at most locations the cellular coverage dropped significantly when entering the front door due to signal attenuation from materials used in building construction. Furthermore, improvement of in-store coverage is usually cost prohibitive, due to the expense associated with cellular repeaters. Other solutions such as femto-cells are largely consumer-based products at this time which restrict connections to a few concurrent handsets which must be pre-registered to be used. Enterprise products are being developed, but are not on the market yet. Other solutions are equally cost prohibitive such as Distributed Antenna Systems (DAS). Other unique solutions are immature, such a in-line Ethernet cellular repeaters that can remove the need for separate cabling and use the existing network cable plant.

This leads many retailers to investigate Wi-Fi as a solution for consumer interaction. However, there are numerous hurdles when taking this approach as well. Security of Wi-Fi networks is always a topic for discussion, especially once the PCI auditors come knocking. If the retailer plans on offering in-store purchases by consumers from their online inventory, then strong connection-level security through authentication and encryption is preferred over the open architecture commonly attributed to hotspots.

A recent article by Aruba Networks highlights the benefits as well as the security concerns with public Wi-Fi in retail:
"For every million iPhones Apple sells, retailers see a clearer opportunity to reach the ultimate marketing goal -- to influence the consumer at the time of purchase. Smartphones simplify the idea of real-time product marketing, making it something retailers can expand and personalize. 
Utilizing in-store WiFi networks, retailers can now deliver location and user-specific content to smartphone-carrying shoppers, while they are inside the store, updating it continuously.
Tempering the excitement of this new era in retail marketing is the fear (and reality) of opening up network access to the public. It wasn't too long ago when improperly secured in-store WiFi networks were exploited to gain access to the corporate network and over 100 million credit card records."
Implementation of 802.11i security is relatively well accepted as an effective security mechanism when properly deployed (strong EAP type, secure account provisioning, mutual authentication, crypto-binding inner and outer EAP methods, strong RADIUS shared secret, AES key wrap, etc.).

Once the security hurdle is crossed, usability of the solution must be considered. Apart from having an easily recognizable value proposition for the consumer (real-time discounts, complementary product promotions, expanded assortment across multiple channels including online, in-store, in-stock at nearby alternate locations, etc.), usability of the solution is critical for user adoption. A few of the questions that must be answered include:

  • How will the network be advertised? 
  • How will users connect to the network? Will an open or a secured network be used?
  • How can the retailer ensure an easy connection process for the consumer, while maintaining strong security (authentication, encryption)?
  • How can the retailer ensure a consistent user experience across multiple store locations; across multiple channels (online vs. in-store)?
Many barriers exist to making this process simple for the consumer. Take the popular Apple iPhone as an example. The Apple iOS SDK does not allow application developers to configure the device's Wi-Fi adapter for the consumer, even if an explicit prompt or opt-in process were required to be presented to the user. This seriously limits the capability of the retailer to remove technology as a barrier for the consumer. Instead, the best a retailer can do is to manually instruct the user to close the current application, open the device settings panel, find and connect to the Wi-Fi network, enter authentication credentials (if required by a secured network), and then re-open the retailer's application. Ughhh! What normal user would want to do that? No one, that's who. If it's too complicated, too lengthy, or too manual a process the consumer will not use it!

With a secure network solution, configuration of 802.11i security is the barrier. This is typically a one-time hurdle for the consumer because once it is setup most devices store or cache the network login credentials and server trust.

With an open network solution, the tediousness of opening a webpage and logging into a captive web portal for each and every connection to the network is the barrier.

This where the 802.11u amendment comes into play. The stated goal of this task group is to:
"develop an amendment to IEEE 802.11 to facilitate interworking with external networks. It is necessary for IEEE 802.11 to create a standard, which specifies the requirements and interfaces between IEEE 802.11 and external networks, such as those found in Cellular systems. The amendment will address specific interfaces to support external authentication, authorization and accounting, together with network selection, encryption, policy enforcement and resource management. Such interface provides interaction methods between IEEE 802.11 entities and the interworked external network. The standard also specifies how the interface works with existing IEEE 802.11 functions, e.g. IEEE 802.11i, to meet the interworking requirements."
Additionally, some of the specific issues to be addressed include:
  • Provide additional information to STAs about the characteristics of the network to support network selection decisions
  • Secure portal page and 802.11i security co-existence and operation in-parallel
  • Support for new user sign-up in 802.11i enabled networks (think in-store signup versus requiring signup at home prior to going to the store)
  • Requirement of the 802.11 network by external network operators (including traffic policies, QoS, voice call hand-overs, etc.) 
With the explosion of consumer smartphone adoption and mobile computing, retailers are investigating methods to utilize these market trends and seize the opportunity to create competitive advantage. However, current limitations with cellular and Wi-Fi networks make these imperfect solutions at-best; unusable solutions at worst. Additionally, place this in context with the cellular telco trend of offloading mobile data connections onto Wi-Fi, and the time is NOW for Wi-Fi to blossom as a public utility for data connectivity, information consumption, and retail interaction.

802.11u ratification can't come soon enough! With Draft 10 of the amendment being passed in July, final approval should be reached before the end of the year. Deployment should be as simple as software upgrades to existing infrastructure and client equipment. Let's hope manufacturers don't drag their feet on this one (see 802.11r for reference).

Don't leave us in the dark.

802.11u where are you?


Friday, September 10, 2010

Update: WLC Upgrade Issue Affects 11n Data Rates

Update Sep. 20, 2010: Cisco has created new bug ID CSCti89945 for this issue.
CSCti89945 Bug Details

wlc upgrade to, N breaks requires wlan deletion-readdition.


when a wlc is upgrade from say or later to the wlans do not work with the N rates. a/b/g regular rates work on N capable clients


Issue is seen specifc to N rates when upgrade from lower versions to


Delete the WLAN and recreate or add the WLANs back for N rates to start working on wlc.

Original Post:
It appears that I have found a bug affecting Cisco wireless LAN controllers when upgrading code from 4.2 to either 6.0 or 7.0. This effect has been found on both 4400 series controllers and WiSM blades in our environment.

After upgrading, everything appears to be correct, but mysteriously the 802.11n data rates do not take effect. Clients can still authenticate and connect to the network, but the highest achievable data rate is 54 Mbps.

Digging into the issue, it appears there may be corruption of the configuration file during the upgrade which prevents 11n APs from being allowed to use the 11n MCS data rates.

To verify the data rates in effect on the AP, open a terminal session and enter the "show controllers d0" command (or "d1" for the 5GHz radio):

AP# sh controllers do 0 

interface Dot11Radio0
Radio AIR-AP1140G, Base Address omitted, BBlock version 0.00,
Software version 3.00.75
Serial number: omitted
Number of supported simultaneous BSSID on Dot11Radio0: 16
Carrier Set: Americas (US) (-A)
Uniform Spreading Required: No
Configured Frequency: 2412 MHz  Channel 1
output trimmed
Receive Antennas : right-a left-b middle-c
Transmit Antennas : right-a left-b, cck single, ofdm all
Antenna: internal, Gain: Allowed 8, Reported 0, Configured 0, In Use 8

Active Rates:  basic-6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 m0. m1. m2. m3. m4. m5. m6. m7. m8. m9. m10. m11. m12. m13. m14. m15.

Current Rates:  basic-6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 m0. m1. m2. m3. m4. m5. m6. m7. m8. m9. m10. m11. m12. m13. m14. m15.

Allowed Rates:  1.0 2.0 5.5 6.0 9.0 11.0 12.0 18.0 24.0 36.0 48.0 54.0

All Rates:  1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 m0. m1. m2. m3. m4. m5. m6. m7. m8. m9. m10. m11. m12. m13. m14. m15.

Default Rates:  basic-1.0 basic-2.0 basic-5.5 basic-11.0 6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 m0. m1. m2. m3. m4. m5. m6. m7. m8. m9. m10. m11. m12. m13. m14. m15

Here you can clearly see that the allowed rates are limited to the legacy 802.11b/g rates and do not include the 11n MCS rates.

A workaround is to delete the existing SSID configuration and re-create it from scratch. This seems to allow the AP to transmit at the 11n rates and fixes the issue. However, this is not a very scalable workaround for large deployments such as ours. With hundreds of controllers it will not be feasible to manually delete and re-create SSIDs across all of them.

I have also tried exporting the existing configuration prior to upgrade and re-importing it after upgrade, but the same issue results. Specific code versions tested include to both and

I have an open Cisco TAC case on this issue and will post an update on any resolution they provide to prevent the issue from occurring.


Consumerization Follow-Up

Last week I wrote about the "consumerization" of enterprise Wi-Fi. It's important to realize that this is a trend in the broader IT eco-system, and is not limited to wireless technologies (although, to a large extent Wi-Fi and consumer electronics such as tablets and smartphones are leading this trend).

A good follow-up article if you're interested in security concerns regarding this trend was recently posted by Marcus Ranum and Bruce Schneier. If you're in IT and even peripherally involved in security controls, subscribing to Bruce's newsletter or RSS feed is a must. He typically approaches security problems from a practical perspective, debunking myths and common mis-conceptions, while digging into the psychological aspects of people to understand why most of us act irrationally when it comes to risk assessment. One of his most exclaimed phrases tells readers to "refuse to be terrorized!"

You can read their recent arguments for and against consumerization and corporate IT security in the latest edition of Information Security magazine (registration required). Bruce's half of the argument is also available without registration on his website.

I tend to agree with Bruce's point of view that corporate IT security will ultimately be on the losing end of this battle. To attract and retain the best young talent, corporations are going to have to allow employees to use their tools of choice. This doesn't mean giving up on security, but shifting the approach away from strict corporate control over IT systems. Saying "no" has always been the dirty word associated with security departments. It's time we start saying "yes" and developing flexible eco-systems to accommodate the variety of consumer electronics.

What is your company doing to support consumer devices? Are your employees finding ways around current security policies?