Is this the fault of the iPhone - With poll!

[Smilin]

IPhones flooding wireless LAN at Duke University

http://www.networkworld.com/ne...71607-duke-iphone.html



Ok, disclosure time. In case you didn't notice I posted this simultaneously in the "networking" and "all things apple" forum. I was mostly curious to see what sort of bias may exist. The results of "Who's fault" are in:

The networking forum almost unanimously agrees that it's Apple's fault:
Apple - 14
Cisco - 1
Duke IT -2

The Apple forum believes it is Duke IT by a one vote margin.
Apple - 6
Cisco - 1
Duke IT -7


Apple poll link:
http://forums.anandtech.com/me...=2073552&viewresults=y

I didn't vote myself.

 

[spidey07]

Clearly and totally apple's fault.

The phones are basically performing a denial of service attack.

this means every operator of a wireless net should ban the iPhone.

 

[JackMDS]

From my perspective the most important entry is missing from your poll.

The Fashion Industry.

I think it is amazing how Fashion took over Technology provided useless gadjets to people bellow 30.

 

[ognabor]

my only question is, where are the reports from other wireless networks? why is duke's the only one?

 

[GenHoth]

Don't know, but the sys manager here got the email for the Duke thing a while ago. Weird.

 

[nweaver]

Roaming is broken on the Iphone...those newer Cisco thin AP's with controller are damn near bombproof from almost every other point.

It's (imho) not even a question of faults. The iphone is DOSing the AP with invalid ARP requests, AKA a client is doing something wrong and overloading the equipment. Client is at fault.

Time to implement EAP-FAST, as I doubt the iPhone supports that.

 

[spyordie007]

As was stated Apple is clearly at fault. Wireless devices (including APs) are still subject to FCC rules:

This device complies with Part 15 rules. Operation is subject to the following two conditions:

1. This device may not cause harmful interference, and
2. This device must accept any interference received, including interference that may cause undesired operation.

(http://www.cisco.com/en/US/doc...ion/guide/c40reg.html)

Looks like Duke is using Autonomous APs in the areas they see it most. Makes me curious what the mix is. Mixed Autonomous/LWAPP environments can have all kinds of roaming issues, but nothing that would cause this kind of behavior.

If it were me I'd be running LWAPP and I'd connect up a IPS/IDS and exclude clients that act this way. You want to misbehave? Off the network with you!

Time to implement EAP-FAST, as I doubt the iPhone supports that.

If phones are getting on the network I doubt they are doing 802.1x; probably an open connection using a web-auth package...

 

[spidey07]

The article states they're using lightweight and the controllers processor is spiking, so I don't know if they have any IOS APs.

With that ungodly amount of arp traffic I can see the processor on the AP getting pegged and essentially cease to function anymore.

So in all honesty this is exactly like a DDoS attack.

 

[spyordie007]

...Some older autonomous Cisco Aironet access points tend to uncover the flooding first, since they try to resolve the ARP request themselves...

I almost missed that (hence the edit on my earlier post).

Seriously though, because this pretty much is a DoS they could totally work around this issue with an IPS/IDS and client exclusions, maybe I should email the folks at Duke

 

[spidey07]

There's gotta be a setting on the controller to stop broadcast storms like this though.

"hey you! Yeah you with 18K bcasts a second. You're done. No more talkie-talkie for you!"

 

[spyordie007]

Originally posted by: spidey07
There's gotta be a setting on the controller to stop broadcast storms like this though.

"hey you! Yeah you with 18K bcasts a second. You're done. No more talkie-talkie for you!"

The built-in signatures primarily focus on management frame related attacks (i.e. deauths, disassociations, etc.). For traffic inspection like this you'd need to span the traffic out to an IPS.

EDIT: Had a thought though, since ARP requests are so simple it may be possible to create a custom signature to shun clients without the need for an IPS. I'd have to do some research/testing to confirm how well it would work.

 

[nweaver]

I would just start with a ban of the iPhone MAC code.

 

[spyordie007]

Originally posted by: nweaver
I would just start with a ban of the iPhone MAC code.

I like that even better, you dont need on the network with your freaking phone!

 

[spidey07]

Any thoughts about aironet/ccx extensions triggering this bug? Fast roaming?

 

[ForumMaster]

kind of weird cause most modern ap's and networking hardware have features that automatically ignore a device if it initiates constant requests.

 

[Nothinman]

I would just start with a ban of the iPhone MAC code.

That's assuming Apple didn't use the same MAC prefix as the NICs in their notebooks.

 

[nweaver]

Originally posted by: spidey07
Any thoughts about aironet/ccx extensions triggering this bug? Fast roaming?

I don't think this is the case. Oh, and just in case anyone wondered, the iPhone is NOT CCX certified

 

[nweaver]

Originally posted by: Nothinman

I would just start with a ban of the iPhone MAC code.

That's assuming Apple didn't use the same MAC prefix as the NICs in their notebooks.

they might, anyone have any idea? I thought it was mostly Broadcom stuff in their laptops.

 

[Nothinman]

they might, anyone have any idea? I thought it was mostly Broadcom stuff in their laptops.

The chipset is usually broadcom but I thought they had their own MAC prefix that they used.

 

[nweaver]

Hmm...I thought that all the broadcom chips used a broadcom prefix. I know it's that way for the laptop wifi stuff...teh HP UltrawirelessOMG!!1! 720 has a broadcom prefix, not an HP.

 

[erikistired]

so where are all the retractions from the wannabe network superstars now that's it been confirmed it was a cisco problem and not an apple problem?

 

[RebateMonger]

Here's a link discusing the conclusion: Duke says the problem is with Cisco. Cisco has issued a "fix".

 

[jediphx]

LOL I love this quote in the article "MacDailyNews Take: Moral of the story: In any way, shape, or form, STFU until you know WTF you're talking about."

 

[nweaver]

I'd like to see details about the fix itself, rather then some "STFU" talk from an apple fanboi site. Cisco issuing a patch does NOT mean it was their fault, it just shows Cisco's commitment to customers. They will work to fix issues with 3rd party devices within their infrastructure for large customers. I'd also like to see the "contribution" of the apple team, since they couldn't even respond to Duke last week (where as I'm sure they had several L2 and L3 techs working on the problem within 12 hours from Cisco's side).


AKA, Need more information. Just saying "Cisco issued a patch, it's their fault n00bs" doesn't cut it.

 

[AmigaMan]

I just find it amusing the bias of the users in the Network forum compared to the identical poll in the Apple forum. At least we thought it could be a Duke IT problem and not just the iphone. Although I find it odd that both forums still didn't blame Cisco.

Cisco issuing a patch does NOT mean it was their fault, it just shows Cisco's commitment to customers.

WTF?!?! Do you work for their marketing department? Now if an apple user had said that, everyone would be all over them. Ironic ain't it? :/