Cisco WLC 7.0.116.0 New Features

Cisco just released wireless LAN controller code version 7.0.116.0, which includes a laundry list of new features. Many of these new features have been in development for quite some time, and both partners and customers have been anxiously awaiting several.

Visit Cisco's website to see the full release notes for this code version.

Here are some of the notable new features and what they will mean for customers:

• WIPS Enhanced Local Mode
  This feature places a subset of Adaptive WIPS capabilities into access points operating in Local or H-REAP modes. Traditionally, Cisco aWIPS required Monitor mode APs. Now customers can get most of the benefits of an in-depth aWIPS deployment with the same access points that service client connections, without having to spend additional money on dedicated monitor APs. The solution still requires the WCS and MSE platforms, but can reduce CapEx and OpEx costs for customers. It is designed primarily for retail customers with distributed branch offices needing to maintain PCI compliance in the face of expanding mobile retail initiatives.
  
  By my count, ELM supports detection of 35 of 48 attacks available in the full aWIPS solution (~73%). The majority of missing attack detections are comprised of some RF DoS and Zero-Day attack detection capabilities, which are arguably not the most severe attacks (DoS) and are notoriously hard to baseline against false-positives / negatives (Zero-Day).
  
  Additionally, the focus of ELM attack detection is on the current operating channel of the AP, and has limited visibility into off-channel attacks through RRM off-channel scanning. This makes sense since the network infrastructure is performing double-duty serving clients and detecting attacks. This should not be an issue for larger network deployments with multiple APs covering most or all of the available channels. For smaller installations, this could present a serious problem however, and reduce effectiveness of the solution. However, this solution is arguably aimed at the larger retail deployments where the expense of deploying dedicated Monitor mode APs has been a problem.
  
  All in all, larger customers should take a look, while smaller customers will probably opt for a dedicated WIPS solution.
  
  
• H-REAP Fault Tolerance
  Cisco has been improving Hybrid REAP mode functionality in leaps and bounds in order to compete in distributed WLAN architecture scenarios, with the likes of Aerohive's Cooperative Control, Aruba's Instant virtual controller, Motorola's Adaptive APs, etc.
  
  H-REAP fault tolerance improves operation by removing the requirement for H-REAP mode APs to reboot when moving from standalone back to a connected state. Previously, H-REAP APs move into standalone mode without affecting locally-switched clients, but when re-joining a controller they were required to reboot and download a complete configuration which caused a service disruption during the fail-back process. Now the AP is able re-join the controller without impacting client service or rebooting, assuming it can verify the configuration matches.
  
  In addition, H-REAP WAN latency may now exceed 100ms (upwards of 2 seconds) provided customers use H-REAP Local Authentication of clients using the internal user list pushed to the access points.
  
  
• H-REAP Opportunistic Key Caching (OKC)
  Previously, H-REAP access points only supported CCKM key caching for fast roaming. Now it supports both CCKM and OKC, which should provide much broader support for fast roaming with many more clients in typical customer environments. Note that both CCKM and OKC still require the 802.1x/EAP key derivation to be completed through the controller. Any keys derived while the H-REAP AP is in standalone mode (disconnected) will not support fast roaming between multiple APs.
  
  I will also be awaiting 802.11r Fast BSS Transition support in H-REAP APs once broader market support and adoption are achieved through the Wi-Fi Alliance Voice Enterprise Certification (due out in 2011).
  
  
• Cisco Identity Services Engine (ISE) Support
  Cisco's next-generation ISE product provides context based access controls and integrates several services into a cohesive platform, including the Cisco Secure ACS authentication and Network Admission Control (NAC / Clean Access) products. This platform enables organizations to enforce network access policies based on a combination of user and device identity, and will be integrated into wireless, switch, and router platforms with software updates.
  
  ISE addresses customer needs for granular access control beyond VLANs and IP subnet policies, acknowledging the need for deeper insight into the context of the client session to drive policy enforcement. A common scenario for this today might be differential network and application access based on user and device, differentiating access by an employee on a laptop versus an iPad. ISE is part of the Cisco TrustSec solution.
  
  
• VLAN Select
  This feature enables pooling of multiple VLANs into a group for assignment to a single WLAN SSID or AP Group. Large wireless installations have traditionally required a single large subnet and broadcast domain to accommodate the number of wireless clients on a single SSID, dynamic VLAN assignment, or the use of multiple SSIDs which can introduce roaming latency and problems. VLAN Select allows client connections to a single SSID to be round-robin load-balanced into multiple network VLANs to reduce subnet size and broadcast / multicast forwarding concerns.
  
  Another use-case for VLAN Select is with guest termination in a DMZ environment. Large guest networks also traditionally required large subnets or multiple anchor controllers to segment the client population into smaller broadcast domains. This resulted in additional CapEx to buy more anchor controllers, since a single anchor controller could only use a single VLAN attached to a WLAN. Now, multiple VLANs can be tied to the same WLAN through VLAN Select, reducing the need for multiple anchor controllers.

I have update my post on H-REAP Deployment Guidelines and Feature Limitations to include these new enhancements, as well as a few others including security feature integration with Cisco switches. It's worth a read to review the current state of H-REAP functionality and limitations with the new 7.0.116.0 code release.

Cheers,
Andrew

Explaining DHCP Server 1.1.1.1

Often times, I am asked by other network engineering and security teams to investigate a potential problem or security issue with the corporate wireless network because clients are obtaining a DHCP lease from an apparently non-existent server with an IP address of 1.1.1.1.

I calmly explain to them that this is expected behavior and is nothing to worry about. However, the conversation usually does not stop there. This only seems to prompt more questions because my answer sounds, on its face, to go against every "preconception" network engineers hold to be true. In order to satisfy their curiosity, it's necessary to explain in a bit more depth how DHCP proxy and web authentication function in the Airespace wireless world (now Cisco Unified Wireless Network).

First, let's level-set the expectations:

• DHCP server 1.1.1.1 IS perfectly valid for wireless clients
• It is NOT a mis-configuration
• It is NOT a security issue or risk
• It will NOT cause an operational or performance issue for wireless clients
• The server address CAN be changed (and is now recommended, more on that below)
• DHCP proxy functionality on the controller MAY be changed, but most times should NOT be

Here is what is going on:

The wireless LAN controller perform DHCP proxy functions using an internal non-routable interface, called the virtual interface. Almost all public documentation by Airespace and Cisco show examples assigning the virtual interface an IP address of 1.1.1.1, which has become the de-facto standard for most deployments. The virtual interface is not attached to any physical ports, is not routable across the network, and is only used by the WLC internally.

DHCP proxy is useful for wireless client roaming in mobility anchoring scenarios to aid faster network connection re-establishment, particularly when performing Layer 3 A-Symmetric mobility tunneling to prevent the client from attempting to get an IP address in the new subnet. Instead, traffic tunneling between controllers allows the client to maintain their original IP address.

The WLC intercepts client DHCP discovery packets, inserts it's own IP address configured on the egress interface into the relay agent field, and unicasts the DHCP packet to the configured DHCP server. Here is an example packet capture from the wired port on a controller:

Here we see that packet #1 was the client DHCP broadcast discovery (carried inside the LWAPP tunnel from the AP to WLC), and packet #2 is the WLC relaying the packet to the configured DHCP server, which in this case is the subnet gateway address. Notice the relay agent information inserted by the controller.

Note - packet numbers 1, 4, 5, and 8 are all inside the LWAPP/CAPWAP tunnel between the AP and controller.

Once the server response is received by the WLC in packet #3, it modifies the DHCP offer and changes the DHCP server ID to the virtual interface address, as shown in packet #4 below.

Clients on the wireless network will perceive their address to be assigned by the server at 1.1.1.1 and will send all renewal requests to this address. This is perfectly normal and acceptable.

It is also important to note that web authentication uses the WLC virtual interface address, and will be seen during web login as the captive portal redirect page.

Changing the virtual interface IP address is now recommended because the 1-block (1.0.0.0/8) was assigned by the IANA to APNIC in January 2010, and is now a valid Internet address. Therefore, wireless clients attempting to reach a valid host at 1.1.1.1 on the Internet would not be able to successfully unless the WLC virtual interface has been configured to use a different address. It is now recommended to use an RFC1918 private address or an RFC3330 Test-Net address (such as 192.0.2.1/32).

To summarize, the DHCP server address of 1.1.1.1 is perfectly valid for wireless local area networks and does not cause operational, performance, or security concerns when used.

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