There are a number of IDS capabilities that are highlighted regarding the WLC. Unfortunately, you will find that the product continues to suffer from ongoing false positives and a severe lack of documentation (and support) for the IDS.
For example, if you utilize containment against a rogue AP (which is used to prevent users from attaching to the rogue), the system detects its own containment messages as a denial of service attack. The system is not intelligent enough to know that it is the source of these messages and ignore them.
Initially, Cisco flagged these false positive as "cosmetic" and claimed that to fix them required a "feature request that must be run through the Cisco sales team" which we did in the spring of 07. Cisco has be VERY slow in coming around on getting these fixed (it has been well over a year since these have been documented and they are still not resolved in the current version of 4.2).
The Wireless IDS system is also famous for other false alarms which Cisco TAC has linked to alarming on normal behavior when a client goes out of range and a string of deauthentication messages is sent to make sure that the conversation has ended. The WLC 4.2 continues to flag these as false-positive denial-of-service attacks even though the IDS parameters could be adjusted (from the factory) to account for the known 64 repeated deauths that are sent.
The IDS file is capable of "tuning" but the parameters are very lightly documented. In fact, the IDS parameter file itself had the least sparse version of documentation and it is a text file only 200-lines long.
In terms of determining if a rogue AP is on-wire. This functionality does not work reliably (not just if there is no path on the wired network to the controller which is understandable) but even if the rogue AP is on the same subnet as the controller. It just plain does not work.
If you are attempting to determine if there are clients on the rogue AP, this mechanism works with limited success since the AP has to catch the client attaching during its brief scan interval. This results in misleading information.
There are other false alarms that appear to be related to a specific chipset (using the OUI / first octet of the MAC address). However, there has been very little movement on Cisco's part in getting resolution to getting these anomalies addressed. The basic attitude has been "if we didn't see it in our lab in San Jose when we wrote the code, there's nothing we can do". Since the IDS lacks any ability to "phone home" (sending the alarms it is seeing to the development team) they end up having to develop in a relatively limited environment.
For more information, please reference the following:
Wireless LAN Controller IDS Signature Parameters
http://www.cisco.com/en/US/tech/tk722/tk809/technologies_tech_note09186a008063e5d0.shtml
I would send you the link to some of the bugs, such as CSCsj06015, CSCsh35010, CSCsk60655, etc. but the Cisco bug tool ( http://tools.cisco.com/Support/BugToolKit/ )is currently not working (no doubt the system is getting overworked). Maybe the site will be up when you read this.
In the interest of fairness, there have been efforts over the past year by Cisco to address these false alarms and a number of them appear to finally be resolved.
Bottom line: In my opinion, the wireless IDS is still not ready for prime time. To quote my customer, "I just can't trust it". Unless you set your customer's expectations fairly low, you will both end up disappointed.
That said, the product itself still has many compelling reasons to implement it including ease of installation and management. If you are willing to wade through the various bugs in the IDS and WCS it still is the best game in town.
- John
