Wi-Fi Direct Formally Certifies Soft-AP Functionality

To follow-up on my previous post regarding the security threats associated with virtualized AP functionality (soft-APs), it is important for network administrators to understand that the forthcoming Wi-Fi Alliance certification for Wi-Fi Direct functionality does allow devices in a group to cross-connect other group members into the larger infrastructure network.

Practically, this means that a device, such as a laptop, can simultaneously be connected to the infrastructure as a client as well as establish a Wi-Fi Direct group session with one or many other group members, then allow those group members to access resources in the infrastructure.

The Wi-Fi Direct cross-connect functionality is explained on the Wi-Fi Alliance's webpage.

Can a device simultaneously connect to a regular Wi-Fi  network and a group of Wi-Fi Direct-certified devices at the same time?

All devices certified under the Wi-Fi Direct program will allow the user to connect to an infrastructure or a Wi-Fi Direct-certified network. Some devices certified under the Wi-Fi Direct program will support connections to both an infrastructure network and Wi-Fi Direct-certified group at the same time (e.g. a laptop may support an infrastructure connection while also belonging to a Wi-Fi Direct-certified group). Simultaneous connection to a Wi-Fi Direct-certified group and an infrastructure network is an optional feature.

Can a network based on devices certified under the Wi-Fi Direct program cross connect to an infrastructure network for internet connectivity?

Yes. A single device in a Wi-Fi Direct-certified group network may share internet connectivity with other devices in the network by creating simultaneous infrastructure and Wi-Fi Direct connections. A network of devices certified under the Wi-Fi Direct program operates in a security domain separate from the infrastructure network, even when cross-connected.

The mention of separate "security domains" is interesting, and infers that the security posture of the Wi-Fi Direct group may differ from that of the infrastructure. For example, if the infrastructure requires 802.1x/EAP authentication and WPA2-AES encryption, the Wi-Fi Direct group does not need to abide by that policy and may use WPA2-PSK instead. And sure enough, this inference is validated:

How will security work for Wi-Fi Direct-certified products?

Group networks based on the specification underlying the Wi-Fi Direct program operate in a security domain that is independent from any infrastructure network. This means that they have protection of the security features certified under the WPA2 program, but are managed separately from the security system in the AP-based network (home, enterprise, hotspot). This means both the group networks based on the specification underlying the Wi-Fi Direct program and the infrastructure networks can be protected, but users don’t need credentials for the infrastructure network to connect to the network based on the specification underlying the Wi-Fi Direct program.

Additionally, since Wi-Fi Direct will be backwards compatible with clients that are not certified under the Wi-Fi Direct program, and only one group members needs to be Wi-Fi Direct capable, this will have implications for rogue AP network detection as well. One group member will provide the connection to the rest of the group in lieu of an infrastructure AP. Due to this and the backwards compatibility, the central Wi-Fi Direct group member may be acting as a soft-AP to provide the group communication framework.

How does the specification underlying the Wi-Fi Direct certification program work?

The underlying specification connects devices using an approach similar to the traditional AP-to-client connection used in Wi-Fi CERTIFIED infrastructure networks. One Wi-Fi Direct-certified device will provide the connection to other participants in a group of Wi-Fi Direct-certified devices in lieu of an AP. A device certified under the Wi-Fi Direct program does not require special hardware compared to traditional Wi-Fi AP devices.

Will Wi-Fi Direct work with legacy devices?

Yes. A legacy Wi-Fi CERTIFIED station device can connect with a Wi-Fi Direct device.

So, what can network administrators do to protect their networks? One of the FAQ answers addresses this specifically by stating that the infrastructure APs can identify clients connecting to the infrastructure as supporting Wi-Fi Direct and may disallow their association. However, as with all things, there is a catch (and it's a fairly obvious one). In order for APs to prevent clients implementing Wi-Fi Direct (presumably either in an active Wi-Fi Direct group or not) from connecting to the infrastructure, the AP firmware must be upgraded to recognize Wi-Fi Direct capable clients. Additionally, the clients must be honest in reporting their capability to the infrastructure, which is a HUGE leap of faith to start trusting clients to report the truth, especially in matters of security where attackers will be all-too-happy to falsify capability reports to gain entry. (Just see NAC / NAP endpoint scanning and reporting falsification for a history lesson on how well that goes over!)

What has been done to ensure that Wi-Fi Direct is suitable for enterprise environments?

Wi-Fi Direct-certified devices will be identifiable as Wi-Fi Direct-certified devices to infrastructure access points. APs can prevent devices currently using Wi-Fi Direct from connecting to the AP, or disconnect them if already connected, while Wi-Fi Direct is in use and/or configure their parameters including channel. The technology behind the Wi-Fi Direct certification program will be important for enterprise environments, enabling applications such as file transfer, printing, and display in the absence of a suitable WLAN. We also expect that the specification will be used in enterprises to temporarily connect mobile data terminals and other portable devices for short-term tasks such as data transfer.

Wi-Fi Direct certification seems to me to be a formalized soft-AP functionality for Wi-Fi devices. Interesting indeed!

Let's at-least hope Wi-Fi Direct clients will "play by the rules" and implement ALL infrastructure AP functionality to ensure network performance. I don't want to be seeing some silly beacon intervals at 10ms.

Also, the mention of the "pre-association discovery method" may have ramifications on performance of the RF channel if clients attempt discovery too often. Client probing behavior in an infrastructure BSS can be bad enough by some manufacturer's proprietary algorithms. And that only happens when clients have triggered their internal roam threshold parameters. Now add on top of that Wi-Fi Direct pre-association discovery frames by multiple clients in your environment and we could see channel utilization increase dramatically if implemented poorly.

There's never a dull moment in this industry, I guess.

-Andrew

Auto-Anchor Mobility Fundamentals

Having a fully redundant guest network architecture can be beneficial for service availability. Depending on business and operational requirements, many organizations use the guest architecture for purposes where traffic needs to be tunneled to a single point in the network, not necessarily just "guest" traffic in the traditional sense.

In a Cisco Unified wireless network deployment, this is accomplished with Auto-Anchor Mobility Tunneling by establishing Mobility peer relationships between internal production controllers and isolated controllers (typically in a bastion host or DMZ segment firewalled from the internal network). When using the auto-anchor mobility feature, these controllers do not need to have the same mobility group name because no layer 2 fast roaming or session state synchronization needs to occur between the controllers (layer 3 roaming is still performed to allow the IP address to be maintained by the client).

Typically, the DMZ anchor controllers are simply termination points within the isolated network segment and do not directly control any lightweight access points. This allows the DMZ anchor controllers to be smaller scale controllers, sized for bandwidth and throughput rather than AP licensing. Typically 4402-25 or 5508-25 controllers are used. Also, layer 2 roaming between APs on the controllers does not come into play.

Also, note that each production internal controller should have a mobility peer relationship with every other DMZ anchor controller to which it will send traffic. However, each DMZ anchor controller only needs mobility peers with each production internal controller, not with other DMZ anchors controllers.

Mobility communication between controllers occurs using their management interfaces, and uses the following protocols:

• UDP 16,666 is used for Mobility control traffic between peers (Control Path)
• IP Protocol 97 is used for Ethernet-in-IP traffic tunneling of client traffic (Data Path)

To setup the mobility peer relationship, navigate to the Controller > Mobility Management > Mobility Groups section. Add a new mobility group member by specifying the peer's management interface MAC address, IP address, and it's mobility group name (not the local one).

The status will initially show both the Control and Data paths down. Once communication is established, the status will show as "Up". Mobility peer connection establishment and keep-alive is performed at a periodic interval which defaults to every 10 seconds.

Note - The control and data paths may individually be shown as down if communication can be established using one protocol but not another. Check network ACLs or firewalls for traffic restrictions if this is the case.

To verify connectivity and peer kee-palive timers at any time, the following CLI commands may be useful:

• mping peer-ip-address - used to test the Control Path between mobility peers
• eping peer-ip-address - used to test the Data Path between mobility peers
• show mobility summary - used to view mobility configuration and timers

Next, anchor the guest WLAN to multiple anchor controllers in the DMZ for round-robin client load balancing and redundancy. All mobility anchor controllers are used (active/active operation). This is accomplished from WLANs > WLAN Name Blue Arrow Drop-Down Button > Mobility Anchors.

On the production internal controller - specify one or more DMZ anchor controllers as the mobility anchors for the WLAN.

On the DMZ anchor controllers - specify its own IP address (local) as the mobility anchor for the WLAN since it will be the termination point for the client traffic.

It is also important to mention that the WLAN configuration on the production internal and DMZ anchor controllers all be identical with only one exception:

• Interface - the production internal controllers should have the "management" interface assigned to the WLAN to allow the client traffic to be tunneled to the DMZ anchor controllers. The DMZ anchor controllers should have a dynamic interface assigned to the WLAN to forward client traffic out to the network (this is where clients will obtain IP addresses).

In a failover scenario, once the production internal controller recognizes that the anchor controller is no longer reachable (during the next keep-alive interval), it marks the anchor as Down, de-authenticates clients, forces client re-authentication, and anchors them to one of the remaining Up anchor controllers. Failover could occur because of a controller failure, or even failure of a single port link if not using link aggregation (LAG). In the event of a single port failure, the anchor controller migrates the affected logical interface to the backup port assigned to the interface. Production controller failover to other active DMZ anchor controllers does occur, but re-establishment of the mobility relationship occurs within 10 seconds once the backup port becomes active and new clients are allowed to terminate on the anchor again.

Note - this may result in clients obtaining a new IP address if the anchor controllers are not attached to the same client subnets (perhaps they are in different data centers for instance).

In my testing, failover occurs within 6-10 seconds of taking the anchor controller offline.

There are a ton of related features, requirements, and design considerations for auto-anchor mobility, but this should provide a basic overview.

Cheers,
-Andrew

Packet Pushers Podcast - Wireless Unplugged Episode #2

PPP Wireless Unplugged episode #2 was just posted. Greg, Jennifer, Sam and company were gracious enough to invite me to participate in this episode. We cover some good topics, check it out!

Here was the agenda we covered:

This is the second podcast from the Packet Pushers devoted to Wireless Networking. After Jennifer Huber joined the Packet Pushers, we agreed that an occasional wireless podcast about would be worth doing. Herewith, is the second episode of Packet Pushers Unplugged on wireless networking.

The Content

• Item 1 – Importance of a site survey and the types of site surveys (Active, Passive, Predictive)
• Item 2 – Wireless Tech Field Day coming up next year – Have you put in your .02 about who you’d like to see there? Please go to the survey athttp://www.surveymonkey.com/s/GKM2W6Q and tell us what you think.
• Item 3 – Emerging Wi-Fi Uses in Retail Enterprises (business analytics, real-time location services, multi channel guest interaction, guest connections, employee use of personal devices such as the iPad) and Andrews blog post on the topic here
• Item 4 – A quick discussion on Virtual AP Threat and how to handle them – also more detail on a blog here.

Cheers
-Andrew

Windows 7 Supplicant Round-Up

The wireless network supplicant was completely re-written in Windows Vista, and significantly updated in Windows 7. It now offers a broader set of enterprise class features than previous generations of native supplicants built into the operating system. It is now called "WLAN AutoConfig" replacing the previous generation "Wireless Zero Config (WZC)" service on Windows XP.

New / Updated Features
New and updated features added in the Windows 7 WLAN AutoConfig software include:
- Better integration and control from the Windows notification area
- Better wireless network profile and preference management
- Global versus current-user profile creation and management
- Better Group Policy integration for administrative control
- Better authentication mode control (machine or user account; Vista required manual XML profile editing and re-import)
- Single sign-on support
- Broader EAP protocol support, including:

• PEAPv2 support (inner/outer crypto-binding, anonymous outer identity)
• Cisco LEAP support (... but you shouldn't be using this protocol)
• Cisco PEAPv1 support (EAP-GTC inner method)
• Cisco EAP-FAST support
• EAP-AKA, EAP-SIM, and EAP-TTLS support

- Better PMK caching control (Vista required group policy or local registry hacks to change defaults)
- FIPS compliance support
- WLAN Hosted Networks (virtualization)
- Better network recognition upon re-connect, including DHCP Network Hint
- Intel / Cisco E2E feature integration (when using a supported Intel adapter)

Supplicant Deployment Considerations
However, choice is (almost) never a bad thing, and some organizations may prefer to stick with a 3rd party supplicant for various reasons. Those reasons may include bad experience with legacy WZC service (gun-shy), consistency of the user experience, preventing re-training of users on how to connect/disconnect and configure wireless profiles, specific features requirements only found in certain software supplicants, performance characteristics, corporate policy control features, or ease of deployment and management with existing administrative tool sets.

Here are some considerations and options when evaluating supplicants for use in your environment:
- Windows Compatibility
- Authentication Protocol Support (EAP flavors)
- Security Controls for Administrative Lock-Down
- VPN Software Integration (auto-launch, etc.)
- Roaming Performance (support for CCKM, OKC, and eventually Fast BSS Transistion)
- Cost / Licensing (especially for a large user base)
- IPv6 support

Windows Compatibility
You can check compatibility of various software packages in the Windows 7 Compatibility Center. This website lists products that have passed Microsoft testing requirements to verify compatibility. Other software packages may run on Windows 7 which are not listed on this website but have not been submitted or passed Microsoft testing (use at your own risk).

Windows 7 Supplicant Round-up
Here is a quick list of the most common enterprise and open-source wireless supplicants, noting which ones currently support Windows 7.

- Windows 7 Native Supplicant
- Intel PROSet - Full support for Win7
- Juniper Odyssey Access Client - No support for Win7
- Open1X Supplicant - Support in the development release only
- Cisco Aironet Desktop Utility - No support for Win7
- Cisco Secure Services Client - No support for Win7
- Cisco AnyConnect Client - Full support for Win7
- Secure W2 Client - Full support for Win7
- Lenovo ThinkVantage Access Connections - Full Support for Win7 (see here)
- Broadcom WLAN Utility - Compatible versions exist, check your OEM for support
- Atheros WLAN Utility - Compatible versions exist, check your OEM for support

I'll leave it up to you to evaluate the features most important for your environment and to draw your own conclusions as to which one makes the most sense for your organization.

But I will say, based on my own experience, the Windows 7 native supplicant is a much improved product over the legacy WZC. Because it is bundled with the OS and offers tight integration with Group Policy controls, give it a shot and see if it meets your needs before spending money on another solution.

Cheers,
-Andrew

* Updated 2011/04/05 to add the Cisco AnyConnect client to the list based on reader feedback.

Limit SSIDs & Data Rates to Maintain Network Performance

To maintain proper Wi-Fi network performance, limit the number of active SSIDs to reduce channel overhead used by network management frames, especially beacons. Most enterprise Wi-Fi solutions on the market allow administrators to configure multiple virtual SSIDs on a single access point, each creating a distinct Basic Service Set (BSS). Therefore, each BSS sends out beacon frames at the Target Beacon Transmission Time (TBTT), which typically defaults to every 100ms.

Enabling too many concurrent SSIDs results in more network overhead from beacons. This can cause performance degradation by utilizing a large amount of available airtime on the channel.

Tips for maintaining high network performance:

1. Limit active SSIDs to 6 at maximum
   This is a general rule-of-thumb, and should be adjusted based on your environment and network design and performance requirements. Lower this value even further if you plan on deploying voice over Wi-Fi, perhaps down to 3 or 4 SSIDs max.
   
   
2. Disable Low Data Rates
   Since beacons are sent at the lowest "basic rate" of the BSS, disabling lower data rates forces beacons to use higher data rates and reduces network overhead. Be sure to test changing data rates prior to implementation to ensure adequate coverage still exists and that no impact to clients in your environment results from this change. A good starting point is to disable the 1-2 Mbps 802.11b data rates!

Here is an example. Assuming 6 SSIDs per-AP, 100ms TBTT, and 3 co-channel APs in the same area (within signal range to induce CCA medium busy backoff amongst each other):

Note 2013-08-16: This assumes a 180 byte beacon frame, which is probably too low for modern WLANs which have added many features that result in more Information Elements. For example, I typically measure beacons at around 370-400 bytes today. 802.11u and Hotspot 2.0 capabilities will increase this further. So, these calculations on bandwidth utilization are probably about half of what they are today. Double these numbers :) I'll try to post another blog updating these numbers accordingly.

   Beacon Data Rate     Resulting Channel Bandwidth Utilization

   1 Mbps               25.92%

   2 Mbps               12.96%

   5.5 Mbps             4.71%

   11 Mbps              2.36%

   6 Mbps (802.11a/g)   4.32%

   12 Mbps (802.11a/g)  2.16%

Same network example, now with only 3 SSIDs per-AP:

   Beacon Data Rate     Resulting Channel Bandwidth Utilization

   1 Mbps               12.96%

   2 Mbps               6.48%

   5.5 Mbps             2.36%

   11 Mbps              1.18%

   6 Mbps (802.11a/g)   2.16%

   12 Mbps (802.11a/g)  1.08%

Limiting active SSIDs and disabling lower data rates can make a HUGE difference!

Additional Reading Materials / Tools:

Cisco's Beacon Bandwidth Estimator (Only available from Cisco Advanced Services)

Wireless LAN Professionals - Episode 10 (@KeithRParsons)

Computerworld Article by Douglas Haider (@wifijedi)

Aruba Airheads Articles (3 in total)

Cheers,

-Andrew

Cisco CleanAir Review

Cisco's CleanAir system integrates spectrum analysis into wireless access points to provide real-time, always-on visibility into external non-Wi-Fi sources of interference present in the environment.

My organization was involved in the beta evaluation of the CleanAir product, and the product has been released for several months now to all customers. However, I have refrained from posting on this product until now in order to be able to provide conclusions on the product from live "real-world" deployments.

Having recently deployed the CleanAir product in two production facilities, I would like to now share some of our results and findings.

Brief Overview of CleanAir

Released last spring, this system is available to customers as of the 7.0 version of code and requires the newer 3500 series wireless access points. The 3500 AP series hardware has been augmented with a dedicated spectrum analysis chipset  to detect and report sources of interference. The AP reports findings up to the wireless controller, where the information can be integrated into the Radio Resource Management (RRM) feature set to automatically optimize the network channel and power settings to avoid severe and/or persistent sources of interference.

A funny anecdote about the "CleanAir" product name - many non-technical individuals being briefed on the technology originally thought it referred to either a.) a "green IT" initiative or b.) removing foul smells from the air.

The SAgE (spectrum analysis engine) chipset is architected in-parallel with the Wi-Fi chipset and does not impede wireless performance. If the incoming energy is recognized as a Wi-Fi signal (specifically the Wi-Fi preamble), it is sent to the Wi-Fi chipset in the AP. If not, then it is passed to the SAgE chipset for spectrum analysis. 

Many administrators (and even some engineers) confuse the meaning of "interference" to include medium contention from other nearby Wi-Fi networks. This is not correct. Strictly speaking, "interference" is non-Wi-Fi energy. The CleanAir system only attempts to measure, identify, and classify sources of non-Wi-Fi interference. This is evident in the basic CleanAir chipset architecture, essentially splitting incoming signals to either the Wi-Fi or SAgE chipset, but never both.

Air quality index (AQI) is an inverse measure of how much interference is in the environment. Air quality is at 100% when no interference is present, and is reduced based on energy strength and duty cycle (airtime occupied) by interference sources. SAgE samples are taken every 1 second by the AP, AQI is calculated every 15 seconds and summarized into 30 second intervals, which are then reported up to the controller every 15 minutes (by default). The exception is when an administrator is actively monitoring an AP radio interface from the WCS or WLC, then the AP is automatically instructed to switch into a rapid update mode which changes the default reporting period down to 30 seconds to provide more real-time information. 

A new RRM component, called Event-Driven RRM (EDRRM), allows the controller to take immediate action to mitigate severe interference issues rather than waiting for the RRM configured interval to take action. The sensitivity threshold determines the AQI value for an individual AP radio that is required in order for EDRRM to kick into effect and make an adjustment in order to avoid the source of interference. Three threshold settings are available to control what AQI value triggers RRM events: High Sensitivity requires AQI to fall below 60, Medium Sensitivity requires AQI below 50, and Low Sensitivity requires AQI below 35. Additionally, air quality SNMP trap alarms are sent when the AQI drops below a value of 35 (by default).

Psuedo-MACs (PMAC) are used to correlate interference sources being detected by multiple APs and merge report information on the device, which is likely to be the case in most enterprise deployments. CleanAir has to detect the interferer for a long-enough period of time (classification requires 5-60 sec. of activity) in order to correlate an interferer as the same device being detected by multiple APs. Since interference sources do not have MAC addresses, a psuedo-MAC is created to uniquely identify interference sources. "Clustering" is used to represent a merged record for an interference source from multiple APs. Currently, cluster information is discarded once the detected energy source stops, and is not persistent for any length of time after the interference stops or is removed from the environment.

Persistent device avoidance allows the CleanAir system to recognize devices that are fixed in position and unlikely to move and avoid recurring interference issue in the areas affected by such devices. The interference sources may be continuous or periodic in nature, but either way are likely to repeatedly impact the same physical area over and over again. Examples include microwave ovens and mounted video cameras. CleanAir recognizes these persistent devices and instructs nearby APs to operate on alternate channels even if the persistent device is no longer observed. Only after a persistent device is absent for greater than 7 days, does the CleanAir system allow APs in the affected areas to re-use those channels.

Reporting is tied into Cisco's WCS management platform and location tracking is performed through the Mobility Services Engine (MSE) context-aware service. WCS provides a central dashboard for administrative staff to monitor network performance, view historical interference trending data, and identify the location of the offending interferer when coupled with the MSE appliance for easy removal of the offending device.

For more information on the CleanAir feature set, see these excellent sources of information:

Cisco CleanAir Product Webpage

Cisco CleanAir Design Guide (The Definitive Resource from Cisco on CleanAir)

Cisco CleanAir Intelligence In Action

TechWise TV Episode on CleanAir

Cisco Aironet 3500 Series APs

CWNP Blog

Network World Review of CleanAir

Deployment and Setup

Deployment and configuration of CleanAir are intuitive and straight-forward. The following steps are involved when implementing the product:

1. Upgrade WLC code to version 7.0 or later

2. Install CleanAir capable access points (3500 series). Note - Cisco does not recommend a "salt-and-pepper" approach to CleanAir AP deployment with other APs. This is because EDRRM can only take action with CleanAir capable APs and does not currently effect the broader RRM eco-system. Therefore, other APs would not benefit from spectrum data reported by nearby CleanAir APs.

3. Configure CleanAir Settings for each Network Band

4. Configure EDRRM in the RRM > DCA Section for each Network Band

To view the configuration of CleanAir on the system, issue the show 802.11b cleanair config command (substitute '802.11a' to see the config for the 5GHz band).

5. Optionally, Configure the MSE to Track Location for Interference Sources

6. Monitor Interference Activity 

From the WLC (Monitor > Cisco CleanAir):

From the WCS Dashboard:

From WCS Maps (if using the MSE to locate interference sources) (Monitor > Maps):

8. Monitor EDRRM Activity from WCS (Monitor > RRM)

9. Create Interference Reports from WCS (Reports > Report Launch Pad)

Real-World Findings

- Interference Detection - CleanAir has been adept at accurately finding and reporting on multiple sources of interference in our deployments. One environment which consists of carpeted office space has discovered numerous DECT devices (likely desk phone wireless headsets) as well as microwave ovens. It was amazing to see just how many floors and areas of the building have leaky microwaves! A real eye-opener. Another environment which is warehouse space has exhibited microwave ovens in breakrooms and bluetooth devices likely owned by employees and active in their pockets while they work (cell phones are likely).

Overall, validation of CleanAir findings with laptop-based spectrum analysis has confirmed the devices and severity levels being reported in our production environments.

- Numerous Similar Interference Entries - Some interference sources are reported multiple times because the PMAC cluster and merge process seems to not work. We have only experienced this for a few types of interferers, most notable DECT phones. It is annoying to see a list of 5 DECT phones, when in reality only one exists but is being detected by 5 APs. More information on this in the "Opportunities for Improvement" section below.

- Good Coverage - Reception of Wi-Fi signals and interference energy exceeds the range for APs and clients to communicate reliably. So, network designs for data and voice should have no problem providing adequate coverage and visibility for CleanAir spectrum analysis.

As Cisco states in their CleanAir Design Guide, "The technology has been designed to compliment the current best practices in Wi-Fi deployment. This includes the deployment models of other widely used technologies such as Adaptive wIPS, Voice, and location deployments." 

- Well-Tuned EDRRM - We have found that EDRRM events are rare, and really only occur when interference is severe enough to warrant a channel change to improve client performance. Fears of change with wreckless abandon are unfounded, and network operation has been stable.

Benefits of CleanAir

The benefits of integrated spectrum analysis, and the CleanAir system in particular, include the following.

- Event-Driven RRM - allows the controller to take immediate action to avoid severe sources of interference, translating into reduced network downtime, improved performance for clients, and faster time to resolution for  client impacting incidents. The Air Quality Index (AQI) drives Event-Driven RRM to make on-demand changes. An example would be a Wi-Fi video camera with strong narrowband interference that effectively kills network operation on the channel.

- Persistent Interferer Avoidance - allows the controller to recognize sources of interference that may be lower-severity, yet occurring in a repeated fashion and degrading network performance. By tracking these repeating interference events, the network can pro-actively avoid such problems. An example would be a microwave oven that only gets turned on during lunch breaks but still needs to be avoided all the time so channel changes don't occur every day over the lunch hour.

- Enhanced Network Visibility - Monitoring air quality through the WLC and WCS are easy and intuitive. The WCS dashboard provides quick snapshot information for administrators checking in on network operation. Air quality reports allow scheduled review of all activity in the environment. Should severe interference sources be found, administrators now have the visibility within their toolbag to positively confirm or deny the presence of interference, rather than trying to diagnose issues from client-reported symptoms. This is tremendously beneficial for removing uncertainty and speculation around Wi-Fi performance issues, as well as to remove offending devices from the environment to prevent future issues.

- Accurate Device Classification - With a dedicated spectrum analysis chipset, the network gains precise and accurate information on non-Wi-Fi sources of interference. Other vendor solutions aiming to provide spectrum analysis capability rely on the Wi-Fi chipset itself to report on non-Wi-Fi energy. The problem with that approach is that Wi-Fi chipsets are designed primarily to modulate and de-modulate Wi-Fi signals, not to identify other sources of energy. Spectral resolution is also vastly superior with a chipset dedicated to spectrum analysis, which allows CleanAir to accurately identify spectral signatures to classify devices and report accurately on energy strength and duty cycle. Solutions based on Wi-Fi chipsets can take a guess, at best. This is especially true of narrowband interference sources or frequency-hopping wireless systems, where more granular spectrum resolution bandwidth can identify individual hopping patterns, as can be experienced with Bluetooth type devices for example.

Cisco's CleanAir spectral resolution is documented at 78KHz (on a 20MHz channel dwell) and 156KHz (on a 40MHz channel dwell), versus a standard Wi-Fi chipset at 312KHz. In addition, even other spectrum cards such as the MetaGeek Wi-Spy 2.4i at 373KHz resolution and AirMagnet Spectrum XT at 156.3KHz aren't as accurate as CleanAir. Also of note, is that the rated spectral resolution bandwidth of the Cisco Spectrum Expert laptop card is a minimum of 10KHz, so CleanAir is not quite as accurate as the laptop card and engineers may notice slight display differences between the two products.

Update: The newer Wi-Spy DBx product has much better resolution bandwidth rated at 24KHz. The Wi-Spy 2.4i resolution bandwidth is 373KHz, not 328KHz as originally posted. I also added a links to the AirMagnet Spectrum XT, Cisco CleanAir, and Cisco Spectrum Expert datasheets as requested by some readers.


Update 2: It appears that the resolution bandwidth listed in the CleanAir Design Guide - Glossary is inaccurate, swapping the values for 20MHz versus 40MHz dwell times. The information above has been updated to reflect the correct values.

- Remote Troubleshooting - Placing the AP into SE-Connect mode allows a Wi-Fi engineer to remotely connect to the AP and view real-time spectrum analysis information through their workstation with Cisco Spectrum Expert software installed. The reduces the need for expensive on-site travel by an engineer, decreases time to resolution of incidents, and improves troubleshooting capabilities of remote branch offices by central IT staff.

Opportunities for Improvement

For a first-generation product, Cisco seems to have nailed CleanAir. However, there are a few features that could improve the solution as it stands today.

- Unclassified Interferer Reporting - Currently, CleanAir only reports on interference sources that it can classify. This is also reflected in the AQI value for each AP radio. Any sources of interference which cannot be classified are not reported in the device list and do not affect AQI. They are visible however in the WLC via the Air Quality Graphs for individual radios. This behavior is on purpose because the CleanAir is specifically architected to classify specific non-Wi-Fi interference sources (currently 20+) and not to speculate on unknown energy.

I agree with this approach when it comes to EDRRM change activity, but disagree when it comes to reporting and alarms. CleanAir should be enhanced to give network administrators more visibility into the unknown energy sources through automated AQI reporting and alerting to signal the red flag for a human to investigate the source. Perhaps differentiating AQI between classified versus unclassifed device severity would still allow EDRRM to be based off only the sources which have been classifed, yet allow administrator visibility into air quality taking into account all energy being detected.

In addition, 802.11b DSSS/CCK modulation poses problems with detection because adjacent channel activity is hard to classify as either Wi-Fi or interference due to the spread spectrum modulation where most of the signal is around the center channel frequency, causing problems detecting side-lobe activity. This problem may be feeding energy to the SAgE chipset rather than the Wi-Fi chipset and resulting in some amount of detected energy remaining unclassified by CleanAir.

- Off-Channel Interference Scanning - The current RRM channel scanning process uses short dwell times and is already being used for neighbor discovery, rogue scanning and aWIPS. Spectrum information is collected during these times, but does not provide enough time time to reliably classify devices; therefore data collected during off-channel scanning is suppressed by the system. One option is to deploy monitor mode APs, which spend significantly longer dwell times on channels which allows CleanAir adequate time to detect and classify interference sources. Another option is to use on-demand directed off-channel scanning. This feature would allow an AP to detect interference sources on off-channels during RRM scanning, or receive reports of interference sources on other channels from nearby APs through the controller, and queue up other channels to scan when client traffic activity is low.

- Duplicate Interference Source Entries - PMAC does not always work as expected, and "bouncing" may occur when the interferer comes and goes faster than CleanAir can classify the source, which results in multiple PMACs being created for the same device or detecting APs being listed as "unknown" (location may still be fairly accurate, but reported information may be incomplete). An enhancement should be made to retain detected energy "clusters" for a period of time to better correlate a single interferer that is intermittent into a single PMAC.

- Local Mode CleanAir - An enhancement to the CleanAir product should be made to allow remote troubleshooting to be performed without changing the mode of the AP, allowing it to continuously serve clients while remote spectrum analysis is performed. The SE-Connect mode should be discarded in favor of real-time spectrum analysis in Local mode.

A Note on Beamforming
One competitor has claimed that integrated spectrum analysis is great and all, but most performance issues come from the Wi-Fi network stomping on itself through medium contention among co-channel access points, and that dynamic beamforming can avoid non-Wi-Fi sources of interference.

Using beamforming to reduce Wi-Fi medium contention as well as to reduce received signal strength from interference sources is helpful to reduce negative network performance impact to some extent, but it cannot eliminate the impact completely. However, beamforming does not obviate the need for integrated spectrum analysis. In an ideal world, a product would have both.


Sure, changing channels disrupts the client session and should be avoided if possible, and beamforming may provide a bit more SNR and wiggle room to avoid a channel change. But there will inevitably be cases where the strength of the interfering device is so overwhelming (narrowband video cameras, for example) that it completely wipes out the channel, even with beamforming on the APs. In those instances would you rather have 1.) beamforming without integrated spectrum intelligence which just sits there confused and inoperable, or 2.) have visibility into the issue and be able to take corrective action to change channels and get the clients working again. Yeah, option number 2 is my choice too - get clients working again without manual intervention!


End result: integrated spectrum analysis is still a beneficial feature and cannot be discounted by vendors with dynamic beamforming capability.

Conclusions

The current CleanAir feature is still in its infancy, yet it already provides a great foundation for wireless network administrators to gain visibility into external sources of network problems. This feature is of great value to administrators today, and will only become even more important as Wi-Fi network become more pervasive and mission-critical to business operations.

Here are a few reasons why integrated spectrum analysis will be required to support mission-critical wireless networks now and into the future:

- Unlicensed spectrum use is growing. More devices, more uses, more potential for interference!

- Voice over Wi-Fi performance requires a well-tuned wireless network. Part of that is having some semblance of control over factors outside the realm of network control. Having visibility into these factors allows administrators better control over their environment to eliminate outside influences where required.

I have found Cisco's CleanAir to be a great initial product offering for integrated spectrum analysis. With the emergence of Wi-Fi networks as mission-critical to business operations, the maturation of voice over Wi-Fi requiring a highly stable and well-performing network, and growing use of unlicensed spectrum by devices of all types, integrated spectrum analysis will give organizations much-needed visibility into external sources of problems. This will allow organizations to solve performance problems rather than "speculate" as to the root-cause.

-Andrew

PS - Thank you Joel, Darrin, and Pete for support during the beta evaluation and production deployments of this product! This post is specifically dedicated to your teams for this (and other) reasons previously discussed ;)

Wi-Fi Tip: 802.11n Outdoor Bridge Links

In order to achieve 300 Mbps raw data link rates on outdoor 802.11n line-of-sight bridge links, polarize one antenna chain horizontally and one antenna chain vertically.

Due to the use of MIMO (multiple input, multiple output) in 802.11n, multiple spatial streams are required in the same time domain. Indoor networks rely on sufficient multipath in the environment in order for the receiver to distinguish separate data streams. Outdoor bridge links cannot provide sufficient multipath in order accommodate multiple independent spatial streams due to fundamental differences in design to prevent fresnal zone blockage and to ensure link stability and reliability. Thus, they require opposite antenna polarization to sufficiently distinguish the streams at the receiver.

Theoretically, two spatial streams "should" be the maximum supported for outdoor point-to-point bridge operation. But with the innovation in advanced antenna design being done by many companies today (Ruckus, MPAntenna, etc.), I think someone is bound to find a way to support 3 or possibly even 4 stream 802.11n on outdoor links.

Cheers,
Andrew

802.11n Rogue Network Detection

Executive Summary

Current wireless monitoring systems are able to detect and alert on 802.11n rogue wireless networks without modification or upgrade. No changes to current environment are required. However, traffic analysis and interception of 802.11n data traffic would require installation of an 802.11n capable WIPS/WIDS solution, as well as access to encryption key material if the network is secured.

Testing was performed on 6 different consumer and enterprise platforms was conducted to reach these results, as described below.

Overview

The 802.11n wireless standard specifies new frame encoding methods which are incompatible with legacy 802.11a/b/g equipment. One potential threat is for a rogue wireless network to be installed utilizing 802.11n in order to bypass detection by 802.11a/b/g based monitoring systems currently deployed.

Evaluation of enterprise and consumer 802.11n equipment was performed to determine the potential for such an attack. Testing revealed that the new frame encoding methods are not used for network advertisement or broadcast frames. The 802.11n standard mandates network advertisement using legacy encoding methods to ensure backwards compatibility. This allows current monitoring systems based on 802.11a/b/g equipment to detect the presence of 802.11n wireless networks.

The ability of current monitoring systems to adequately detect 802.11n rogue network threats provides sufficient insight into the wireless network for policy compliance and remediation efforts. The risk of 802.11n networks bypassing detection by current monitoring systems is very low. No changes to current environment are recommended in response to this threat.

802.11n Rogue Network Threats

The advancement of wireless local area network technologies with the recent 802.11n draft specification and subsequent availability of enterprise and consumer equipment represents unique opportunities and threats to corporate wireless networks. The 802.11n draft protocol specifies fundamental architectural changes in the encoding and transmission of radio frequency signals which allow wireless networks to achieve benefits such as higher throughput and longer range. The downside to such advancements is the inability for legacy 802.11a/b/g equipment to decode these signals, effectively leaving them blind to their transmission. This issue represents multiple risks to wireless networks, such as introducing a greater likelihood for interference, frame collisions, frame retransmissions, degraded throughput, as well as the potential for 802.11n rogue access points to remain undetected by legacy monitoring systems.

The IEEE 802.11n working group recognized these issues and built-in legacy co-existence mechanisms to facilitate the concurrent use of the new and old encoding mechanisms. The draft specifies three possible operating modes for 802.11n networks: Legacy, Mixed-Mode, and Greenfield Mode. Legacy mode operation conforms to the existing 802.11a/b/g encoding mechanisms and provides no additional benefits of the new standard. Mixed-Mode operation allows wireless networks to simultaneously serve both new and legacy equipment, and requires all signals encoded with the new standard to be pre-pended by a legacy frame header to allow legacy equipment to recognize the signal transmission. This behavior prevents legacy equipment from interfering with the transmissions of 802.11n signals at the cost of some throughput. Greenfield mode operation allows 802.11n equipment to transmit signals with the new encoding mechanism without pre-pending a legacy header. This provides for the maximum throughput for the wireless network, but prevents legacy equipment from recognizing or understanding these wireless signals.

The potential exists for rogue wireless networks implementing Greenfield mode operation to remain undetected by legacy monitoring systems based on 802.11a/b/g equipment.

Impact Analysis

The results from this evaluation reveal that legacy monitoring systems will be able to detect new 802.11n (IEEE 802.11 clause 20) wireless networks. The testing shows that each of the products evaluated support Legacy and Mixed-Mode operation, but few support Greenfield mode operation. More importantly, the testing also shows that network advertisement through Beacon frames are always sent with Legacy encoding (IEEE 802.11 clause 15,17, 18, or 19 data rates), ensuring that 802.11a/b/g equipment will always be able to detect the presence of such networks.

The IEEE 802.11n-2009 amendment, section 9.6.0d “Rate selection for data and management frames” states:

If the BSSBasicRateSet parameter is not empty, a non-STBC Beacon or a non-STBC PSMP frame shall be transmitted in a non-HT PPDU using one of the rates included in the BSSBasicRateSet parameter.

If the BSSBasicRateSet parameter is empty, the frame shall be transmitted in a non-HT PPDU using one of the mandatory PHY rates.

However, data frames sent between 802.11n clients and APs may be sent with either Mixed-Mode or Greenfield mode encoding, preventing legacy monitoring systems from deciphering their contents. However, due to modern wireless security protocols and encryption using dynamic keying material, data frames cannot be deciphered by monitoring systems for any secured network. Therefore, the inability to decipher high throughput encrypted data frames is not a significant change from current security operation.

Additionally, access points supporting an “N-Only” mode of operation implement this feature by evaluating the supported rates of client devices (as set in the HT Capabilities information element, specified in section 7.3.2.56 of the IEEE 802.11n-2009 amendment) attempting to associate to the BSS and refusing association if the client does not include support for 802.11n MCS data rates. Beacons for devices operating in this mode are still transmitted at Legacy data rates. Typically, the following association refusal status codes are used, per the IEEE 802.11-2007 standard section 7.3.1.9:

• Code 18 – STA Does Not Support All Data Rates in the BSS Basic Rate Set
• Code 10 – All Capability Fields Not Supported

The ability for legacy 802.11a/b/g equipment to detect 802.11n networks allows current monitoring systems to adequately detect 802.11n rogue network threats and provides sufficient insight into the wireless networks for policy compliance and remediation efforts.

Test Environment

Evaluation of 802.11n equipment was performed to determine the viability of such equipment to remain undetected by current wireless monitoring systems based on 802.11a/b/g equipment. In order to accurately assess this threat, equipment was selected from a cross-section of commercially available vendors, both enterprise and consumer oriented. Each device was tested to determine the ability of legacy equipment to detect their presence.

802.11n Device Test bed:

1. Cisco 1252 Autonomous Access Point
2. Linksys WRT350N
3. Linksys WRT600N
4. D-Link DIR-655
5. D-Link DGL-4500
6. Apple Airport Extreme

Each device was run through a series of tests to evaluate their operation characteristics:

1. Network advertisement when in 802.11a/b/g legacy mode operation
2. Network advertisement when in 802.11a/b/g/n mixed mode operation
3. Network advertisement when in 802.11n only mode operation
4. Analysis of advertised capabilities, including Greenfield mode and 40-MHz channels
5. Detection and reporting of networks by current monitoring systems based on legacy 802.11a/b/g access points

Test results were compiled independently for devices operating in the 2.4GHz and 5GHz frequency ranges due to operational differences commonly implemented by vendors.

Test Results

References

CWNP Blog

IEEE 802.11n-2009 Amendment to the IEEE 802.11-2007 standard:

• Section 9.6 Multirate Support
• Section 9.6.0d specifies rate selection for data and mangement frames
• Section 20.1.4 specifies PPDU formats (Non-HT Legacy, HT-Mixed, HT-Greenfield)

Cheers,

Andrew