Networking

Cisco Wireless Controllers, not the iPhone, created the ARP Storm

I wrote a blog last week about how the Apple iPhone was suspected of creating conditions similar to a Denial-of-Service Attack (DoS) attack on the wireless network of Duke University. Initially Duke University opened help tickets with both Apple and Cisco. As it turns out, it was not the iPhone that was at fault. After a week of researching the issue, Cisco has determined that several other mitigating factors were present which led to the DoS attacks.To understand what caused the initial misdiagnosis, it's important to understand the basic elements of the WLAN used by Duke University. Their WLAN consists of Cisco wireless LAN controllers (WLC) and Cisco lightweight access points (LAP). The function of a WLC is to manage LAPs and provide communication paths for every device that resides on the WLAN. The LAP is the perimeter device to which computers having wireless capabilities associate with to gain access to the university network.

It's also important to understand how an iPhone is programmed to initiate associations with wireless networks. The iPhone first tries to re-associate with the last network it was connected to. It does this by sending out a unicast ARP request to try and find the last device it was associated with. This actually is a logical approach as it potentially reduces the amount of time required to attach to a network.

The internal DoS attacks to the Duke University WLAN were successful due to two elements. The WLAN apparently uses a flat topology or has more than one WLC on the same Layer2 VLAN and the ARP unicast feature was enabled on the WLC.

Now to the WLC and what leads to the DoS condition. Simply put, the vulnerable WLC doesn't know what to do when a unicast ARP request for a MAC address is received and the MAC address is not listed in the ARP table. As programmed, the WLC will send the request out to all other controllers on the same Layer2 VLAN or domain. It then very quickly becomes an ARP storm creating the DoS condition, because all of the other vulnerable controllers are going to do the exact same thing with the request.

Cisco has released a Security Advisory that explains the entire DoS process, affected products and an interim workaround. Finally according to the advisory, corrected firmware upgrades will be available this Friday, July 27, 2007.

About Michael Kassner

Information is my field...Writing is my passion...Coupling the two is my mission.

Editor's Picks

Free Newsletters, In your Inbox