Articles Worth Reading: 12/30/2010

Here are a collection of articles from the past week that I have found useful, interesting, or enlightening. As always, for a complete list of articles check out my shared article feed from Google Reader.


Unplugged – Show 4 – Too Many iPads – My Etherealmind: 

"#Content

* 802.11n adoption in the enterprise may be driven by iPads and iPhones today, and Android in the future. This may drive the greater of adoption of wireless networking generally.

* Will the prevalence of personal hotspot devices end up ruining enterprise guest networks? Guest networks are becoming important systems for external consultants and contractors and the wireless networks need to be more reliable. Discussions of some of the challenges around this.

* Fast roaming and why it’s important in an enterprise environment, especially with 802.1x/EAP authentication; forthcoming Wi-Fi Alliance Voice Enterprise certification.

* Keith R Parsons moving to Ruckus."

2010: The Enterprise Wi-Fi Year in Review - www.enterprisenetworkingplanet.com: 

"Thanks to 802.11n, there's a good chance 2010 was the year a wireless LAN became your default network access method. This retrospective from Wi-Fi Planet looks at the major deals, improvements in technology and changes in the market that pushed Wi-Fi ahead in the enterprise."

* I had the honor of contributing to this great article by Lisa Phifer.


Breaking GSM Security With a $15 Phone: 

"Whatever assurances have been given about the security of GSM cellphone calls, forget about them now."

802.11: Safety equipment for outdoor WLAN deployments: 

"Deploying outdoor network is hard. It is hard technology wise. One is bound by the limitations of the technology (the 802.11 standard), regulatory restrictions (FCC and the likes) and the environment itself (buildings, trees, hills, weather changes, etc). And once you have designed the network, you have to deploy the network."

dailywireless.org » AT&T Expands Public WiFi: 

"AT&T will expand Wi-Fi hot spots in New York’s Times Square just ahead of New Year’s celebrations and is also deploying its first hot spots in a public, outdoor area of San Francisco, the Embarcadero waterfront district."

How to Get Your Idea Approved - Amy Gallo - Best Practices - Harvard Business Review: 

"When you have an idea, proposal, or recommendation that you believe in, it's easy to presume that getting it approved will be a breeze. If you see how great the idea is, won't everyone else? However, whether an audience accepts an idea is often less about the idea itself than about how you present it. When you need approval, don't assume that just because it's brilliant, others will see it that way — convince them."

Layer 2 vs Layer 3 in Wireless Mesh: Do You Have to Choose? « Mesh Without Wires: 

"Layer 2 vs Layer 3 benefits and trade-offs have been a topic of discussion for a couple of decades as both approaches have their benefits and drawbacks."

Cheers (and happy reading),
Andrew

Packet Pushers Unplugged #4 - Too Many iPads

Enterprise support for consumer devices is definitely one of the hot topics these days for Wi-Fi engineers and IT departments. Check out the latest Wireless Unplugged episode of Packet Pushers Podcast, hosted by Greg Ferro (@etherealmind), and featuring the expert opinions of Jennifer Huber (@jenniferlucille), Chris Lyttle (@wifikiwi), and myself (@revolutionwifi).

In this episode we discuss the iPad as well as other relevant wireless topics, including:

- 802.11n adoption in the enterprise may be driven by iPads and iPhones today, and Android in the future. This may drive the greater of adoption of wireless networking generally.

- Will the prevalence of personal hotspot devices end up ruining enterprise guest networks? Guest networks are becoming important systems for external consultants and contractors and the wireless networks need to be more reliable. Discussions of some of the challenges around this.

- Fast roaming and why it’s important in an enterprise environment, especially with 802.1x/EAP authentication; forthcoming Wi-Fi Alliance Voice Enterprise certification.

- Keith R Parsons moving to Ruckus.

Packet Pushers Podcast: Wireless Unplugged Show #4 - Too Many iPads

Thanks to all participants for the great discussion! It's always an honor.

Cheers,
Andrew

A Few Wi-Fi Wish-List Items for 2011

Finally, as a wrap-up to my 2010 recap and 2011 projections for the Wi-Fi industry, here a few wish-list items that are desperately needed.

1. Voice-Enterprise Certification – the convergence of voice over IP with user mobility and smartphone adoption is leading the requirement for organizations to support large-scale VoFi deployments. However, performance of voice over Wi-Fi must be balanced with strong security based on WPA2 (802.11i) and 802.1x/EAP authentication. Predicting this need, the IEEE passed the 802.11r amendment in June 2008 to provide a method for fast, secure roaming by clients among a coordinated group of access points. This allows clients to re-use existing master key material obtained during the initial authentication during subsequent roams to other APs within the system, bypassing lengthy authentication exchanges. However, industry adoption for this feature has been almost completely absent, and the Wi-Fi Alliance has been slow to finalize the Voice-Enterprise interoperability program. This feature is such an important milestone for network performance and SLA compliance it is hard to fathom why both infrastructure and client vendors have been reluctant to implement fast roaming capability. Perhaps 2011 will be the year customers get this needed tool to increase network performance.
   
   
2. 802.11u Amendment Ratification – it’s painfully obvious that open unsecured Wi-Fi hotspots are inadequate for broad consumer use, resulting in poor data security. The problem with providing an alternative has been the complicated nature of secure Wi-Fi hotspots. In addition, there is no current mechanism for service advertisement at public locations other than creative network SSID naming. The IEEE 802.11u amendment aims to change this and remove the barriers to secure public Wi-Fi. It will do this by allowing additional information to be sent between network operators and customers for service advertisement, coordination of service delivery between Wi-Fi and external network operations (such as cellular), and provide on-demand account enrollment and customer authorization for network access. It aims to simplify the entire process for users, easing proper network identification and selection as well as gaining access through both paid and free hotspot networks. It is also unclear at this point if 802.11u will include provisions for anonymous EAP authentication and automated provider authentication (certificate validation) for free hotspots, but this function is also a clear necessity. Watch for ratification of this amendment in 2011, but manufacturer adoption and inter-network roaming agreements are likely longer-term developments.

What’s on your Wi-Fi feature wish-list?

Cheers,

Andrew

A Look Ahead to Possible Wi-Fi Industry Trends in 2011

Many of the trends from the past year will carry over into 2011 and continue to impact the industry, while a few new developments are poised to radically alter the landscape. Here are my projections for some of the developments we should expect to see in the coming year.

1. Wireless as the Primary Enterprise Access Medium – spurred by large-scale adoption of 802.11n equipment, more organizations and employees will increasingly rely on Wi-Fi networks for the bulk of their work. Although a complete shift to Wi-Fi is unlikely except for a minority of organizations aggressively seeking expense reduction, most organizations will realize that the benefit of a scaled-down switching infrastructure, eliminating unused switch port capacity, and deploying greater capacity Wi-Fi networks to handle mobile workers.
   
   
2. Smart-AP Architectures Begin to Emerge from Market Leaders – just as 2010 saw established competitors challenge the common wireless controller architecture, market leaders will look to begin migrating to a more distributed architecture with smart APs. As industry experts continue to recognize that controller features can now cost-effectively be implemented in smart APs, market leaders will be forced to react and keep pace, or face continuing erosion of market share to innovative up-and-comers. However, the transition for large established equipment manufacturers will not be easy, having to support current customers with a deployed base of controllers as well as customers still running legacy autonomous access point architectures. Watch for product feature sets to begin migrating back into the smart APs in 2011, but don’t hold your breath for a viable large-scale controller-less solution, as ditching the controller will be tough given their wealth of feature that need to be migrated. Also, implementing coordination among smart APs will be limited to small groups of APs upon first release to ensure product stability. Watch for the large vendors to position these smart APs in parallel to existing controllers to prevent erosion and cannibalization of existing revenue streams, targeting smaller SMB/SOHO deployments for initial product releases while continuing to recommend controllers for larger installations.
   
   
3. Consumer Device Adoption in the Enterprise Becomes the Norm – enterprise Wi-Fi networks are a bit of an anomaly, having gained broad adoption in the consumer space long before enterprise. As such, Wi-Fi is viewed more as a utility by employees, who more commonly expect to connect any device to any network to get connected. Underscoring a major societal and cultural trend of the connected lifestyle, enterprises will be forced to support consumer-grade devices on corporate networks. This will present challenges for IT departments to provide secure and controlled access to corporate data. Mobile device management (MDM) solutions will increasingly be sought after to manage the great diversity in client platforms. Wireless network engineers will need to take care to architect solutions to alleviate poor consumer device performance and ensure mission-critical devices and applications achieve the required QoS and SLA required. Watch for organizations to take baby steps in support of these devices while they develop broader strategies for device funding, liability, and security compliance. Support may initially be limited to Internet and/or thin-client access to corporate applications and data, with broader access following strategy definition and procurement of management solution.
   
   
4. Mobile Commerce Leads to More Retail Hotspots – if 2010 was the year of mobile advertising, 2011 will be the year of mobile commerce and greater consumer interaction. Retailers are looking to keep pace in highly competitive markets and adjust to shifts in consumer behaviors, specifically targeting mobile commerce applications. Wi-Fi hotspots have long been a staple of cafés and bookshops, but will see increasingly broad adoptance among other retailers looking to provide a mechanism for customer engagement while in-store where they have the most influence at the product location. Wi-Fi will serve as a foundation for mobile commerce and marketing applications due to its pervasive presence in consumer smartphones and the lack of adequate 3G/4G cellular data network coverage within many brick-and-mortar facilities. Retailers will need to be careful to ensure the content is engaging, relevant, and provides a great customer experience. Watch for more hotspots to spring up throughout 2011.
   
   
5.  Emergence of Smart Meter, M2M, and Sensor Networks – wireless sensor networks have long been confined to the realm of university research and limited deployment mainly in the structural engineering field. However, this technology is maturing to the point where mass-market adoption is within the realm of possibility. Use-cases in the enterprise for smart buildings, energy efficiency, and better facilities monitoring and management coupled with commercial products for the consumer market with products to enable a connected home (thermostats, televisions, blu-ray players, home entertainment and set-top boxes, etc.) will bring smart meter, machine-to-machine (M2M), and sensor networks into the mainstream. Manufacturing costs are reaching low enough levels to allow product pricing to reach inflection points which could drive mass consumption by consumers. Enterprises, on the other hand, will be slower to adopt this technology due to investment in current systems, and deployment will likely be reliant on the rebound of the economy to spur new facility construction. Also watch for government funded economic stimulus projects to make increasing use of this technology. Sensor networks hold the potential to radically shift how Wi-Fi networks operate, shifting from human interaction networks to largely automated systems that require higher levels of stability and consistent network operation. Wi-Fi engineers should be able to proactively identify these shifts and manage network changes to provide greater availability and capacity.

What trends will you be watching for in 2011?

Cheers,

Andrew

Important Wi-Fi Industry Trends from 2010

With the end of the year upon us, let’s take a look back at some of the more important Wi-Fi industry developments that occurred in 2010. These trends set the tone for the year and kept many industry professionals busy and employed through the economic hardships.

Wi-Fi industry trends are direct byproducts of cultural shifts in how we as a society prefer to work, play, and live as a whole, and provide a view into the fabric of our daily lives. As an IT professional I am excited about the technology and services we enable, but on a macro level as member of a broader community I am intrigued about how different our daily lives are than our parents, grandparents, and ancestors. Change truly is a remarkable thing!

Important Wi-Fi trends from 2010:

1.  Large Scale Enterprise 802.11n Adoption - early adopters began deploying 802.11n in 2009, but 2010 will undoubtedly be the year of 11n. Large enterprises wrapped up interoperability and performance testing, formalized best practices and network design, and began deploying very large 802.11n access point roll-outs in 2010. In 2011, look for 3 spatial stream 802.11n to begin shipping in enterprise-class equipment, bring data rates of 450 Mbps (raw). Also, enterprises that have been evaluating Wi-Fi as wired Ethernet replacements will begin taking strides to implement this model for a large amount of their staff.
   
   
2. Challenges to the Controller Architecture - customers began challenging the viability of the Wi-Fi controller architecture due to behavioral shifts in network use. 802.11n brought higher bandwidth and discussion of Wi-Fi becoming the predominant access technology for end-users in the enterprise. Due to concerns over controller scalability, throughput, single points of failure, and the desire to optimize traffic flows, controller vendors have been challenged to re-think their Wi-Fi architectures to shift more control into distributed access points. Initial migration has begun with virtually all controller vendors now providing distributed data plane traffic forwarding. In 2011, look for advancements to distribute control of Quality of Service, security, radio management, and distributed key caching capabilities into access points. Additionally, watch for controllers to move into more of centralized management role and smart access points being operationally independent from controllers. Some vendors will begin removing controllers from their architectures completely, but will experience growing pains attempting to support both architectures simultaneously for a period of time.
   
   
3. Enterprise Consumerization & Wi-Fi Only Devices - everyone wants an iPad, including executives. Their ease-of-use, mobile form-factor, and consumer mind-share have executive level management in most organizations pushing IT departments to support iPad access on the corporate network. Since the iPad, and many new and emerging consumer devices, only have Wi-Fi connections, wireless engineering teams have been challenged to collaborate with internal IT security and deliver a secure access method for consumer devices in general, not just limited to the iPad. Careful consideration of security policy changes, network and application security design, and mobile device management platforms have kept IT departments busy scrambling to meet this need. In 2011, look for more enterprises to officially adopt support for consumer devices, owned both by the organization or by individuals, as well as implementation and market growth for mobile device management platforms to give administrators the ability to control access and storage of sensitive corporate data on these devices.
   
   
4. 3G Problems Drive Wi-Fi Hotspot Demand - as cellular carriers, and AT&T specifically, struggled to keep up with 3G data network demands, they increasingly changed their mindset on Wi-Fi hotspots from competitive technology to a complementary service. The rollout and use of Wi-Fi hotspots in 2010 grew at amazingly sharp rate, lead by AT&T and their quarterly reports on Wi-Fi hotspot usage. Wi-Fi hotspots are seeing unprecedented usage and availability for consumers, with renewed interest in making Wi-Fi a ubiquitous access technology across locales. In 2011, look for additional Wi-Fi hotspot rollout by cellular carriers as well as retail establishments that are attempting to attract and influence consumer purchasing habits.

What are your thoughts on the most important trends in Wi-Fi from the past year?

Cheers,

Andrew

Introduction to NFC on the Google Nexus S

Following up on my previous post about how NFC Smartphones Could Mean Greater Customer Influence, here is an introduction to the capabilities in the first iteration of NFC available in a U.S. smartphone, the Nexus S by Google and Samsung.

As mentioned in the video, NFC is currently limited to reading data from tags. The phone cannot send data to another NFC device at this time due to security concerns. This prevents contactless payment applications at this time, but I would expect to see enhanced NFC capabilities in the not-to-distant future once developers have worked out security considerations for this type of functionality.



It will be interesting to see which retail establishments are early adopters and lead the pack in innovative uses for this functionality to interact with their customers. I would expect to see a period of minimal NFC application availability initially as retailers evaluate technology use-cases and test interactive applications in limited markets. However, look for the market to pick up dramatically in time for the Q4 holiday shopping season next year as retailers push for competitive advantages in mobile commerce to drive increased store visits by consumers.

All signs point to mobile as the big strategic initiative for retailers in 2011!

Cheers,
Andrew

Why Work Doesn't Happen at Work

I recently ran across this TEDx talk from Jason Fried from 37signals, which is a collaboration company. In the talk he discusses how creative individuals, including engineers, need long periods of un-interrupted time in order to dive deep into ideas and perform meaningful work.

I think this talk is an excellent topic for wireless engineers from two different perspectives. First, we are engineers and part of our work is creative in nature. Designing a wireless network solution is part science, but also largely part artistic and creative. Second, the networks we build are increasingly being driven by consumer and corporate demand for mobile solutions. Part of this talk discusses how individuals seek out places where they can accomplish meaningful work, and increasingly this means away from the office. The solutions we build as wireless engineers directly enable "meaningful work" to be produced by the end-users we support.

Take 15 minutes and watch this video, it's well worth the time!



Cheers,
Andrew

NFC Smartphones Could Mean Greater Customer Influence

Yesterday, Google officially announced the Nexus S smartphone which was developed by Google and Samsung to ensure tight integration of the operating system and hardware. Apart from being the flagship device for Android 2.3 "Gingerbread", supporting a new SDK/NDK, and running on new hardware specs, what interests me the most about this announcement is the integration of Near-Field Communications technology.

Near Field Communication (NFC) technology is a combination of hardware and software that uses a very high frequency to transmit data between two devices when in close proximity, typically around 10 cm or less in distance. The technology is closely related to proximity cards, smartcards, and RFID equipment and serves as an extension which integrates both a smartcard interface and reader into a single device.

The first release of Android 2.3 only supports tag reading applications, not two-way communication. This allows initial applications to use NFC for tag reading and information display to the user, but prevents more direct information exchange between devices thus limiting applications such as contactless payment at point-of-sale. Also, since NFC is integrated into the Android operating system, no application launching is required to activate NFC when in proximity to a tag. This should provide a simple and satisfactory user experience.

Working in retail IT, and specifically on wireless communication technologies, the adoption of NFC has the potential to significantly disrupt the model of B2C (business to consumer) interaction. There is currently a race by retailers to adopt developing mobile technologies that allow greater interaction with guests where retailers have the most influence over purchasing habits, at the point-of-sale. Studies show that providing customers with more information about products, special offers, and targeted messages at the point-of-sale and through mobile platforms is still the most effective method for retailers to influence the customer, and outweighs fears about competitive shopping by consumers on mobile platforms.

Many retailers have been researching opportunities for customer interaction through mobile applications, cellular networks, and in-store Wi-Fi networks. Typically, cellular networks are not robust enough to provide a reliable interaction model with consumers, especially at the point-of-sale due to signal degradation inside modern facilities. Therefore, many have begun to offer free in-store Wi-Fi using a mix of existing and new network infrastructure, or managed services, to encourage consumers to connect and interact while within their stores. The draw for consumers is the ability to remain connected in their increasingly digital lifestyles. For the retailer, enhanced customer engagement through the use of mobile applications offers the possibility to influence the customer at the point of sale, drive higher sales, increase net profit by selling higher gross margin product, and increase brand loyalty.

Retail establishments have also been aggressively researching real-time location services (RTLS) to provide  highly targeted messages and promotions to consumers while in store. However, the lack of a mature business model for this level of interaction coupled with RTLS accuracy requirements are hindering progress at this point. Targeting consumer smartphone platforms for integration is typically the focus, which allows interaction with the broadest consumer segment, especially when in-store (how often do you take your phone while shopping versus a laptop or tablet?). Since most smartphone models only have Wi-Fi and cellular communications, a Wi-Fi RTLS solution is required. However, achieving the desired accuracy, usually within 5 feet, is problematic. Current Wi-Fi RTLS solutions use RSSI-based tri-lateration, which currently cannot provide the desirable level of location accuracy, ranging from 10-50 feet depending on network design and environmental constraints. Add in the complexity of initial and recurring calibration required to keep the system performing well, and the expense can quickly exceed the benefits.

The addition of Wi-Fi or RFID tags can increase location accuracy, but is not ideal for consumer use within retail establishments since the consumer would be required to pick up an additional tagged device upon entering the store, carry it with them throughout their visit, and return the tag upon exit. On the surface, that may not seem like an issue. However, a significant implication with this approach is the decoupling of user identity from the location data. Data correlation between the user and their shopping/purchase habits is of great value to retailers for business analytics including targeted messaging, providing a personalized shopping experience, understanding consumer demographics, and much more. Retailers are still developing these consumer interaction models and should be transparent in their collection and use of such information to ease consumer privacy concerns by providing detailed information to consumers, establishing strong data security policies, and adopting a consumer "opt-in" model for the service offering.

Near Field Communications (NFC) holds the potential to offer the highly localized and personalized consumer interaction model which retailers are currently seeking, while eliminating the need for deployment and maintenance of complex Wi-Fi RTLS systems. Although NFC is not a complete functional replacement for a dedicated RTLS system, it can provide most of the consumer influence benefits while sacrificing a subset of back-end business analytics such as consumer travel paths and dwell times through the store. The combination of NFC technology for localized consumer interaction, and Wi-Fi RTLS as a supplement for business analytics seems to offer a relatively good compromise.

The race by retail establishments to interact with consumers through mobile technologies should spur development of applications that utilize integrated NFC smartphone capabilities. Engadget aptly states "[NFC] has the potential to become a very interesting new method of interaction between our devices and our surroundings." Indeed!

I will be following the development, smartphone adoption, and application development surrounding NFC technologies and related wireless technologies very closely.

Cheers,
Andrew

CAPWAP Connection Maintenance

Continuing down our CAPWAP journey, once the access point has joined a controller, a mechanism is required to verify the correct code version is running on the AP, download the operational configuration, and maintain the connection especially during periods of idle WLAN activity. Collectively, I'll call this the CAPWAP connection maintenance process. Connection maintenance consists of 6 operational states for the access point, the first two of which have already been discussed regarding the controller discovery and join processes.

Connection Maintenance Operational States

1.      Discovery State is used when the AP is performing discovery to identify potential controllers on the network

2.      Join State is used when the AP is actively joining a WLC

3.      Image Data State is used if code version is out of sync with the WLC:

§  LWAPP Image Data Request(s) will be sent by the AP to request chunks of code

§  LWAPP Image Data Response(s) will be sent by the controller containing chunks of code

§  The AP will install new code, reboot, perform discovery, selection, and join a WLC

4.      Config State is used by WLC to provision the AP with the appropriate configuration

5.      RUN State is when the access point is ready to serve clients

6.      Reset State is used when the access point has been issued a command to reboot

Note - These operational states are performed behind the scenes and are not the same as the "Operational Status" field displayed in the WLC wireless access point list. That list defines the registered status of an AP with the controller (REG / DEREG).

Once the access point is in the RUN state, a heartbeat process between the AP and controller is initiated to identify the loss of connection so that the access point can attempt to failover to another controller.

LWAPP/CAPWAP Heartbeat Process:

1. LWAPP/CAPWAP Echo Request Sent
   When the access point's heartbeat timer expires, it sends an LWAPP Echo Request to the WLC. By default, the heartbeat timer is 30 seconds. It is administrator configurable in code version 5.0 and later.
   
   
2. Starts the 'NeighborDeadInterval' Timer
• The AP expects an LWAPP Echo Response from WLC before the timer expires.
• Once a response is received, the NeighborDeadInterval timer is reset and the Heartbeat Timer is restarted.
• If no response is received and the timer expires, the AP sends additional LWAPP Echo Requests up to 5 more times in 1 second intervals.
• If there is still no response received after 5 retries, the AP releases and renews its IP address, transitions back into the Discovery State, and attempts to discover a new controller.
  
  This behavior changed in code version 5.0; if the AP has a valid controller in its backup controller list, then it will immediately transition into the Join State and attempt to join the next controller in the list. The backup list is maintained by sending periodic LWAPP/CAPWAP discovery packets to each discovered controller (dictated by the AP Primary Discovery Timeout value).

The WLC also maintains a heartbeat timer, and expects an LWAPP/CAPWAP Echo Request packet from the AP before its timer expires. Once the WLC hearbeat timer expires, the AP connection is flushed from the controller's active AP list. If you have ever moved APs between primary, secondary, and tertiary controllers and noticed a small period of time that the previously connected controller still shows the AP as connected, it is due to this timer.


In versions 5.0 and later of WLC code, a fast heartbeat timer can be configured to detect failed controllers faster than 30 seconds. Separate timers can be specified for APs in local and H-REAP modes. The valid fast heartbeat interval is 1 – 10 seconds.

config advanced timers ap-fast-heartbeat { local | hreap | all } { enable | disable } interval
show advanced timers

From the AP, verification can be done using these commands:

show lwapp client ha
show lwapp client config

Tweaking the heartbeat timer allows quicker identification of failed controllers and faster failover necessary in a highly available environment. In my next post, I'll detail some additional measures that can be taken to implement a highly available wireless network.

Cheers,
Andrew

CAPWAP AP Join Process

Once the LWAPP/CAPWAP access point has discovered and selected a controller, the next step in the process is for the AP to join the selected controller. The join process verifies the identity of both the Cisco access point and controller, ensuring that only valid Cisco APs with either a Manufacturer Installed Certificate (MIC) or Self-Signed Certificate (SSC) from an autonomous AP conversion to lightweight mode can join the controller. This process also establishes a secure communication path for the LWAPP/CAPWAP control channel to ensure that only the current controller can configure and manage the access point.

The LWAPP and CAPWAP protocol join process is built on existing asymmetric and symmetric cryptography, hashing, and digital signatures. For an introduction to these concepts, see Public Key Cryptography, SSL and TLS protocols.

To join the controller, the access point and controller perform the following process:

1.      AP sends Join Request

a.       Random Session ID

b.      X.509 Certificate of LWAPP

2.      Controller Verification

a.       Verifies LWAPP X.509 Certificate was signed by a trusted CA

b.      Generates random AES encryption key for LWAPP Control traffic

c.       Encrypts AES key using LWAPP Public Key

d.      Concatenates key ciphertext with the Session ID from LWAPP Join Request

e.       Encrypts concatenated string with Controller’s Private Key

3.      Controller sends Join Response

a.       Ciphertext (Session ID, encrypted AES key)

b.      Controller’s X.509 Certificate

4.      LWAPP Verification

a.       Verifies Controller X.509 Certificate was signed by a trusted CA

b.      Decrypts concatenated string using Controller’s Public Key

c.       Validates the Session ID

d.      Decrypts the AES key using LWAPP’s Private Key

5.      Join Process is now completed

6.      AES Key Lifetime timer is 8 hours

a.       LWAPP sends LWAPP Key Update Request (contains new Session ID)

b.      Controller generates new AES key and encrypts as stated above.

c.       Controller sends LWAPP Key Update Response

All LWAPPs manufactured after July 18, 2005 have Manufacturer Installed Certificates (MIC) burned into protected flash memory. Upgraded access points manufactured prior to this date will have Self-Signed Certificates (SSC) installed during the upgrade process. The Cisco Upgrade Tool must be used during the upgrade of older APs in order to generate the self-signed certificate. SSCs are not trusted by default by the WLCs, so a mapping of AP MAC addresses to SSC Public Key hashes is created at the time of upgrade by the Cisco Upgrade Tool. This list can then be imported into WCS and pushed to the WLC.


Access points can also be restricted from joining a controller based on the AP Policies settings in the Security tab of the WLC. This allows more granular control of APs allowed to join a controller if the organization does not want to allow any valid Cisco AP to join for security reasons. 


Select the type(s) of certificates to accept (SSC, MIC, LSC) when authorizing APs against the AP authorization list. SSC certificates always require valid AP entries in the AP authorization list. MIC and LSC are accepted by default, and will only be checked against the AP authorization list if their respective authorization check boxes are enabled.

Debugging the LWAPP Discovery and Join processes can be accomplished with the following commands:

LWAPP Console Port Commands
debug ip udp
debug lwapp client events
show crypto ca certificates

WLC Commands:
debug lwapp events enable
debug lwapp packet enable
debug lwapp error enable
debug pm pki enable
show time

It is VERY important that the WLC have the correct time set, otherwise it may reject the LWAPP Certificate during the Join process because it is outside the validity interval. To set the correct time on the controller, issue the config time CLI command.

If LWAPs are using Self-Signed Certificates, ensure that the WLC is configured to accept the SSCs:

show auth-list

config auth-list ap-policy ssc { enable | disable }

config auth-list add { mic | ssc } ap-mac ap-keyhash

config auth-list delete ap-mac

Cheers,
Andrew

CAPWAP Controller Selection Process

Once a CAPWAP access point has discovered and built a list of all one or more available wireless LAN controllers, it is ready to select the optimal controller to join.

Controller selection is based on the following information embedded in the Discovery Response from each candidate controller:

1.      Controller sysName

2.      Controller Type

3.      AP Capacity

4.      Current AP Load

5.      Master Controller Status

6.      AP-Manager IP Address(es)

7.      Current AP Load on each AP-Manager IP Address

The AP will select a controller based on the following precedence rules:

1.      Primary configured controller preference

2.      Secondary configured controller preference

3.      Tertiary configured controller preference

4.      Primary Backup controller (WLC version 5.0 and later)

5.      Secondary Backup controller (WLC version 5.0 and later)

6.      Master Controller status of WLC

7.      Controller with greatest excess capacity

a.       Ratio of current AP load versus maximum capacity; expressed as a percentage

Note – Once an access point joins a controller, it learns the information of all controllers within the Mobility Group and stores their IP addresses in NVRAM. The AP may join another controller with greater excess capacity if no controller preferences are configured.

Cheers,

Andrew

CyberMonday Wish List

Inspired by Dan's post on his cyber Monday wish list over at Margin Scribbles, here is my own wish list for this holiday season.

1. CACE Wi-Fi Pilot and 3-Pack AirPcap Nx Adapter - sniffing packets is just so much fun, what better way to celebrate the holidays. I've always been hamstrung capturing wireless frames in monitor mode on my Windows PCs, having to resort to loading up a Linux distro (may I recommend Backtrack v4 just released). So this year I would like native Windows capturing capabilities to increase my wireless efficiencies. I could use Omnipeek as well, but I'm more familiar with Wireshark and Omnipeek workstation licensing is so unfriendly.
   
   
2. Arkon IPM127 bicycle mount for iPhone - riding my bicycle spring through fall in Minneapolis is great. Carrying my GPS integrated iPhone in the back of my jersey or in a seat-pouch is not. I need to be able to view my progress while I'm riding, pause tracking while waiting for those infrequent intersection cross-walks which I avoid as often as I can, and keep my butt motivated to perform better than the last time. Combining a bicycle mount, music player, and a GPS bicycle tracking app such as Cyclemeter.
   
   
3. Star Trek TNG Complete DVD Series - okay, strictly speaking this is not a techie item. But I love Star Trek The Next Generation and have been recording re-runs on my DVR for a year now. That's just not cutting it anymore, I must own the complete series. Someday, my future kids will watch Picard save Earth from the Borg, I know it.
   
   
4. Immunity SILICA-U - penetration testing can be so much fun. I've played with tons of pen-test tools, my favorites being BackTrack, Metasploit, aircrack-ng, and coWPAtty. But if I'm going to get serious about this stuff I need a professional wireless pen-testing tool. Immunity's SILICA-U takes wireless pen-testing to the next level, and I want some of that action.

I have plenty more geeky toys in my wish list, but those are my tops.

Cheers,
Andrew

CAPWAP Controller Discovery Process

In a controller-based architecture, CAPWAP access points are dependent on a wireless controller to provide the software image, configuration, and centralized control and optionally data forwarding functions. Therefore, it is necessary for the access point to find a list of available controllers with which it can associate.

The following layer 3 CAPWAP discovery options are supported:

1.       Broadcast on the local subnet

2.       Local NVRAM list of the previously joined controller, previous mobility group members, and administrator primed controller through the console port

3.       Over the Air Provisioning (OTAP) (subsequently removed in version 6.0.170.0 code)

4.       DHCP Option 43 returned from the DHCP server

5.       DNS lookup for "CISCO-CAPWAP-CONTROLLER.localdomain"

Broadcast

The CAPWAP AP sends broadcast discovery requests on the local subnet. Controllers with management interfaces on the same subnet receive the discovery request and send a discovery reply back to the CAPWAP AP.

If no controllers are on the local subnet, broadcasts may be forwarded to the controller management interface by the local router using the Cisco “forward-protocol” and “ip helper-address” features. Use these commands to configure the router:

ip forward-protocol udp 12223

ip forward-protocol udp 5246

interface interface-name

     ip helper-address wlc-management-ip-address

When using the forward-protocol, the default gateway modifies the CAPWAP discovery packet that is broadcast on the local subnet by replacing the broadcast destination IP address 255.255.255.255 with the WLC management IP address configured as an IP helper-address, then routes the packet to the controller. The downside to this approach is that the WLC will also receive all other forwarded protocols such as DHCP discovery packets. Also, other configured IP helpers will receive the CAPWAP discovery packets. Since this behavior is likely undesired, be sure to use the forward-protocol method only temporarily.

Local NVRAM

The local NVRAM of the access point stores a list of controllers, gathered from the following sources:

·         Primary, Secondary, and Tertiary controller preferences previously configured for the AP

If the access point was previously associated to a controller, the IP addresses of the primary, secondary, and tertiary controllers are stored in the access point’s non-volatile memory. This process of storing controller IP addresses on access points for later deployment is called priming the access point.

To verify locally stored controller preferences:

show ap config general ap_name

Primary Cisco Switch Name........................ WLC001
Primary Cisco Switch IP Address.................. Not Configured
Secondary Cisco Switch Name...................... WLC002
Secondary Cisco Switch IP Address................ Not Configured
Tertiary Cisco Switch Name....................... BACKUP-WLC
Tertiary Cisco Switch IP Address................. Not Configured

·         Mobility Group Members from the previous controller connection

The AP also maintains previously learned WLC IP addresses locally in NVRAM. The AP sends a unicast CAPWAP Discovery Request to each of these WLC IP addresses. These WLC IP addresses are learned by the AP from previously joined controllers. The stored WLC IP addresses include all of the WLCs in previously joined controller mobility groups.

To verify locally stored controllers learned through mobility groups, console into the access point and enter the following command:

show capwap client config

mwarName                CCIETEST
mwarName                backupwlc
mwarName
numOfSlots              2
spamRebootOnAssert      1
spamStatTimer           180
randSeed                0x9640
transport               SPAM_TRANSPORT_L3(2)
transportCfg            SPAM_TRANSPORT_DEFAULT(0)
initialisation          SPAM_PRODUCTION_DISCOVERY(1)
ApMode                  Local
Discovery Timer         10 secs
Heart Beat Timer        30 secs
Led State Enabled       1
AP ILP Pre-Standard Switch Support Enabled
AP Power Injector Disabled
Infrastructure MFP validation Enabled
Configured Switch 1 Addr 10.127.78.5
Configured Switch 2 Addr 10.108.50.20

Note – mwarName entries are the controller preference settings (primary, secondary, tertiary). Configured Switch entries are the learned mobility group members.

·         Manually primed controller IP address through the console

Manual configuration can be used to “prime” the CAPWAP if network services for address assignment and WLC discovery do not exist. If the CAPWAP has previously joined a controller, or is currently joined to a controller, these commands will be disabled.

To stage an access point, use the commands:
capwap ap controller ip address wlc-mgmt-ip
show capwap ip config

OTAP

If this feature is enabled on the controller, all associated access points transmit wireless RRM neighbor messages, and un-joined access points can receive the controller IP address from these messages. This feature is disabled by default and should only be enabled when necessary for AP deployment.

Note – OTAP does not work with default APs out of the box or upgraded using the Upgrade Tool because the radios are disabled from the manufacturer. 

Configure OTAP:

config network otap-mode { enable | disable }
show network summary

Note - OTAP was removed from the wireless controller feature set in code version 6.0.170.0 due to a vulnerability.

DHCP Option 43

The IP address that should be configured as DHCP option 43 is the address of the controller Managament interface.

Cisco 1000 series access points use a string format for option 43.
Cisco Aironet access points use the type-length-value (TLV) format for option 43.

DHCP servers must be programmed to return the option based on the access point’s DHCP Vendor Class Identifier (VCI) string (DHCP option 60). The VCI strings for Cisco access points capable of operating in lightweight mode are listed in the following table:

The format of the Option 43 TLV block is:

     Type: 0xf1 (decimal 241)
     Length: Number of controller IP addresses * 4
     Value: List of WLC management interfaces

Configuration of option 43 will vary by DHCP server platform. Here is an example configuration using the built-in Cisco IOS DHCP server:

ip dhcp excluded-address start-ip end-ip
ip dhcp pool pool-name
     network ip-address netmask
     default-router ip-address
     dns-server ip-address … ip-address
     domain-name domain
     lease days hours

     option 60 ascii “VCI string”

     option 43 hex hex-value

An example of a finished IOS DHCP server configuration will look similar to this:

interface Vlan192

 ip address 192.168.1.1 255.255.255.0

ip dhcp excluded-address 192.168.1.1 192.168.1.10

ip dhcp pool lwapp

   network 192.168.1.0 255.255.255.0

   default-router 192.168.1.1

   dns-server 192.168.1.2

   domain-name test.lab

   lease 7

   option 60 ascii "Cisco AP c1240"

   option 43 hex f108.0a6c.3214.0a6c.3212

In this example, the hex value is obtained from these TLV values:

Type = 241 (0xf1)

Length = 2 IP addresses * 4 bytes each = 8 bytes (0x08)

Value = 10.108.50.20 (0x0a6c3214) and 10.108.50.18 (0x0a6c3212)

Note – Periods are added automatically to the hex value by Cisco IOS and should not be entered by the administrator when entering configuration commands.

DNS

The AP will attempt to resolve the DNS name “CISCO-CAPWAP-CONTROLLER.localdomain”. When the AP is able to resolve this name to one or more IP addresses, the AP sends a unicast CAPWAP Discovery Request to the resolved IP address(es). The DNS entries can be either an A (address) or CNAME (alias) records.

If the AP received a DHCP address, ensure the DHCP server is configured to return valid DNS servers and a valid domain name suffix to the AP.

If the AP is using a static IP address, configure the domain name and DNS name servers from the controller. WLC version 4.2 requires configuration from the CLI, whereas 6.0 and later allow configuration from the GUI. Once applied, the AP will disconnect and re-join the controller.

config ap static-IP { enable | disable } ap_name ip_address netmask gateway
config ap static-IP { add | delete } domain { all | ap_name } domain_suffix
config ap static-IP { add | delete } nameserver { all | ap_name } dns_server_ip_address

Verify the configuration of the AP:

(Cisco Controller) > show ap config general ccielwap

IP Address Configuration......................... Static IP assigned

IP Address....................................... 10.108.51.54

IP NetMask....................................... 255.255.254.0

Gateway IP Addr.................................. 10.108.50.1

Domain........................................... ccietest.com

Name Server...................................... 10.10.10.25

Verification of Method Used

To view the method used by an AP to discover the controller, view the console output of the AP as it searches, or issue the following command from a controller that receives the discovery request and search for IE 58 from the AP which indicates the discovery method used to resolve the controller IP address:

debug capwap packet enable

CAPWAP Discovery Packet IE 58 values:

0 = Broadcast

1 = Local NVRAM

2 = OTAP

3 = DHCP

4 = DNS

Example 1 – AP Console Log indicates DHCP discovery

*Mar  1 00:00:30.287: Logging LWAPP message to 255.255.255.255.

%DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0 assigned DHCP address 192.168.1.20, mask 255.255.255.0, hostname AP0018.7361.e702

Translating "CISCO-LWAPP-CONTROLLER.test.lab"...domain server (10.97.40.216)

%LWAPP-3-CLIENTEVENTLOG: Performing DNS resolution for CISCO-LWAPP-CONTROLLER

%LWAPP-3-CLIENTERRORLOG: DNS Name Lookup: could not resolve CISCO-LWAPP-CONTROLLER

%LWAPP-3-CLIENTEVENTLOG: Controller address 10.108.50.20 obtained through DHCP

%LWAPP-5-CHANGED: LWAPP changed state to JOIN

%LWAPP-5-CHANGED: LWAPP changed state to CFG

%LWAPP-5-CHANGED: LWAPP changed state to DOWN

%LWAPP-5-CHANGED: LWAPP changed state to UP

%LWAPP-3-CLIENTEVENTLOG: AP has joined controller CCIETEST

Example 2 – WLC LWAPP Packet Debug indicates DHCP discovery

(Cisco Controller) > debug lwapp packet enable

Mon Feb 22 09:55:32 2010: Start of Packet

Mon Feb 22 09:55:32 2010: Ethernet Source MAC (LRAD): 00:17:DF:96:9F:90

Mon Feb 22 09:55:32 2010: Msg Type       :

Mon Feb 22 09:55:32 2010:    DISCOVERY_REQUEST

Mon Feb 22 09:55:32 2010: Msg Length     :   31

Mon Feb 22 09:55:32 2010: Msg SeqNum     :   0

Mon Feb 22 09:55:32 2010:

IE            :   UNKNOWN IE 58

Mon Feb 22 09:55:32 2010: IE Length     :   1

Mon Feb 22 09:55:32 2010: Decode routine not available, Printing Hex Dump

Mon Feb 22 09:55:32 2010: 00000000: 03                                       Mon Feb 22 09:55:32 2010:

In my next post, I will describe the controller selection process used by the wireless access point to determine which controller to establish a connection to when multiple controllers have been discovered.

Prior to selecting a controller, the access point always performs discovery using the methods listed above. From the discovery responses the AP builds a list of candidate controllers and selects the optimal controller.

Cheers,

Andrew