Hi, > Can someone explain to me how this: > > http://www.cisco.com/en/US/products/ps6366/products_qanda_item09186a008082c464.shtml#err2 > > ...is anything other than a terrible, terrible idea? > > Do people disable this in their networks?
but thats the way it works - MIC error causes all TKIP activity to be stopped... thus the AP stops being an AP - we see this quite a few times a day - the joys of a broadcast based system - just one single bad client can mess up everyones life. ISTR that lots of APs behave in this way....at least if they follow standards, clients are required to disassociate from the AP and rekey (their own key and group key) when a MIC failure first occurs. IEEE 802.11i requires any station detecting two MIC failures within 60 seconds to stop all communication for 60 seconds. The Mac is nice about this too, eg kernel[0]: AirPort: Message Integrity Failure detected (G) kernel[0]: AirPort: MIC Failure -- activate countermeasures kernel[0]: AirPort: Message Integrity Failure detected (G) kernel[0]: AirPort: MIC Failure -- activate countermeasures kernel[0]: AirPort: Link DOWN (out-of-range 0) kernel[0]: AirPort: Link Active: "eduroam" - 00xxxxxxxxxx - chan 144 - and you get a nice scary message as a user...mmm.. couple this with the issue that if you have mixed mode - ie TKIP and AES for an SSID, then the AES client has to have a TKIP group key...and therefore falls into 'get ready to be hacked' territory...oh, and will fall foul of this issue. one more really really good reason to drop TKIP and move to WPA2/AES only alan _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
