Disabling Management via Wireless - is there any point?

Question

Hey guys.
Firstly, yes, I do know that allowing management of controllers over an unsecured WLAN is a bad idea (although even that would be SSL-secured by default, but open to brute-forcing I'd guess).
Secondly, let's assume that Management via Dynamic Interfaces is disabled too (why anyone would want to enable that is a bit beyond me too?).
This 1 little tickbox manages to justify an entire page in the GUI, so it definitely looks pretty darn important!
The problem is that in a multi-controller environment the only controller that knows you're connecting over wireless is the one that you're connecting through. Any other controller will be happy to accept the management connection on it's management interface address because it sees it as coming from the wired network. To prevent this from happening I think you could do either of two things...
1) Apply a CPU ACL that blocks the client IP ranges, which will work equally well for wireless and wired-side connections, i.e. it's the equivalent of the "management via wireless" setting but works for all controllers simultaneously. You'd have to remember to keep this updated though if ever your WLANs and client ranges change.
2) Put the management interfaces of all controllers in an isolated management VLAN (which will potentially complicate all your supporting services access, e.g. DHCP/RADIUS/etc.). That'll stop the undesirable "wired" access on the n-1 controllers and then the mgmt-via-wireless will take care of the wireless access to the other 1 controller.
So the setting seems rather pointless on it's own in anything other than in a single-controller environment. I'm sure I've read somewhere that the controllers do tell each other about their current clients (for things like CCKM and rogue management), so wouldn't it be cool if this centralised awareness logic was applied to management connections?
What are the experiences out there with this feature? Is it generally seen as worthwhile, or does it really need some extra planning and possible augmentation via other features to be of any value?
In general, other than popular paranoia about wireless being "less secure" than wired access, what are the compelling reasons for denying management via wireless? As I mentioned above, even over a completely non-secured WLAN you'd still have SSL/SSH security if you configure your allowed management protocols right.
Thanks,
Justin

Answer 1

Yes "It makes the auditors happy" is definitely a good and valid reason.
I've just co-incidentally come across this in the 5.0.148 release notes:
http://www.cisco.com/en/US/docs/wireless/controller/release/notes/crn501480.html#wp234100
"Preventing Clients from Accessing the Management Network on a Controller
To prevent or block a wired or wireless client from accessing the management network on a controller (from the wireless client dynamic interface or VLAN), the network administrator should ensure that there is no route through which to reach the controller from the dynamic interface or use a firewall between the client dynamic interface and the management network."
That makes sense, but do many folks out there do it that way? Generally there's not much control between the management VLAN and the users' VLAN because the latter is usually where the wireless-supporting services reside.