Canopy needs BETTER FILTERS!!!

Hey all,

I thought I would pose a hypothetical situation where you might have a group of rogue subscribers. This scenario is highly unlikely, however it is completely possible. The only way to prevent this type of scenario is to have better filters at the Canopy radio, and/or to enable SM Isolation.

eSedona cannot use SM Isolation because we have subscribers that use our clusters as transport between their offices. SM Isolation also interferes with peer-to-peer technologies such as XBox Live! and VoIP. Any Canopy network that provides subscribers with SM-to-SM transport will be unhappy with SM Isolation.

What I would like to see is a better set of user-defined filters. It would be extremely helpful to be allowed a filter to block by IP Protocol type. That would allow me to block type 1 (ICMP), or any other type that became a nuisance.

If NAT mapping configuration were updated with this same match, you would be able to terminate GRE and IPSec tunnels through an SM that has NAT enabled.
(Think about a VPN server behind an SM w/ NAT).

Ok, here’s the story:

#1: Subscriber gets pissed off for some reason. He finds a few buddies that subscribe also, and coordinates an electronic attack.

#2: Subscribers begin purposely sending any type of L2 ethernet broadcast frame as fast as they can, all on the same cluster. This could be any ethernet frame type: appletalk, ipx/spx, IP, or even an unassigned frame type id.

For this example, I’m gonna say they are flooding “ICMP echo request” packets to the subnet broadcast IP, sourced also from the broadcast IP. That’s ethernet dst ff:ff:ff:ff:ff:ff and IP src & dst (for example). I chose “ICMP echo” because everything on the cluster would hear the packet, being its L2 broadcsated. Anything that can reply will do so, generating further load on the cluster.

#3: If you give every SM 500kbit of upload, then 10x 500kbit = 5mbit. This would equal more than all of your upstream bandwidth on a single AP, and very likely equal to or more than your downstream traffic cluster-wide. Here, our rogues are sending 500kbit of broadcasted ethernet traffic up each of their SMs. Each AP repeats that 500k per SM out its downlink to everyone else…

#4: If the flood never pauses or drops off after a few minutes, then you’ve got quite a problem on your hands. While the flood is occuring, APs are not accessible because they are too busy processing broadcast packets. You’d have to rely on your routers & packet sniffers to isolate source APs.

Even if you keep track of everyone’s MAC address - MACs can be spoofed.

Even if you track everyone’s assigned IP - IPs can also be spoofed.

I have not had the chance to see if SM Isolation really does block broadcast traffic. I assume it would. In addition, I’m not certain how version 8’s new kernel and UI would handle a broadcast flood: would the UI still be inaccessible during a flood like version 7.3.6?

I’m interested in any comments or feedback you may have. I will test version 8’s response to a flood in my lab, and post back next week.

This topic is also related to my other post about Broadcast Storm Control

Jeremy Baland
Network Engineer
eSedona Wireless Internet

I tested the response of during a broadcast flood (SM Isolation turned off). The new UI was inaccessible while I was flooding traffic, and quickly recovered as soon as I halted the traffic. This is the same experience as our live network that runs 7.3.6 (also in HW mode, with 2x).

Enabling SM Isolation worked to block retransmission of my broadcasts. However, the presence of so much broadcast traffic still tied up the AP. The web UI was very slow, but still reachable and usable if you’re patient. When altering my attack to target the AP itself, I was able to make the UI unreachable again. Using VLANs may help, however I believe it would not prevent the issue, as the AP would still have to process every flooded packet on each VLAN.

My test setup is a single P9 AP with a Cisco 3640 behind it. My test workstation is wired to another port on that router. 4x SM are registered, each with a linux-based traffic generator. All Canopy equipment is running release with 2x mode enabled on two SM. The other two SM are P7 and P8, and not capable of 2x.

Each traffic generator (4) was sending ICMP echo-request packets to a random IP. At the ethernet layer, both src and dst mac was broadcast (ff:ff:ff:ff:ff:ff). I have not yet measured pps or bandwidth metrics during a flood, however it is enough to render an AP completely unreachable directly from its ethernet port.

I was able to make the flood more effective by targetting the IP address of my AP. In this case, the AP attempted to respond to each ICMP echo-request with an echo-response, which was replied to the ethernet broadcast (ff:ff:ff:ff:ff:ff).

Remember: Every ethernet device that receives a broadcast frame must process that frame (ask any Cisco certified engineer). This takes a hardware interrupt to the cpu, as well as software interrupts at the driver layer, tying up vital resources for each and every system that receives the frame. This is how a single AP, or an entire cluster with CMM can be crippled by broadcasted ethernet floods.

– Jeremy


A kid with a linux box and if runs tools like “macof” can kill your whole canopy network in a minute.

Even if you keep track of everyone’s MAC address - MACs can be spoofed.

Even if you track everyone’s assigned IP - IPs can also be spoofed.

For this if you are not using NAT, In addition with the Better Filter :slight_smile: , there must me support to allow user-defined IP+MAC binding rules and deny all. Similar to the one we use in iptables.

/sbin/iptables I FORWARD -i eth2 -m mac --mac-source 00:B0:64:70:F3:E0 -s -j ACCEPT

Just wondering will the current CPU and Memory of SM is enough to handle all this stuffs ?