This problem I'm about to describe, though, this is the sort of reason that I don't like L2 switches. They're just unclean.

The arp spoofing I've been discussing disrupts the association between MAC address and IP address. Although involved in the effect, L2 switches aren't interested in the arp spoofing itself---they only look at MAC addresses. Another imagineable attack would be to set one's own MAC address to be the same as the gateway or the same as one of the clients. On a broadcast network, aside from the arp behavior it might imply, this wouldn't do a god damned thing. But L2 switches presume any MAC address will be associated with at most one switchport, and will alter their CAM forwarding table based on MAC-spoofed traffic they see coming from the attacker, so the attacker can suck traffic for someone else's MAC address onto his or her port.

It's chaotic. If the gateway's MAC address is learnable on its own switchport and also on a spoofed switchport, some traffic won't reach the gateway as the gateway MAC association flaps between the two ports, and availability suffers.

Ettercap calls this attack port stealing. They claim they're able to steal a port, capture a batch of traffic, unsteal the port, and dump all the traffic to the real destination, resteal it---controlling the flapping semi-deliberately and using it to achieve MITM just like with arp spoofing. It sounds kind of ridiculous---I don't know if it works or not.

The ideal fix for this is to use a BSD gateway that understands 802.1q, and put every switchport in a different VLAN. Then, statically nail the BSD gateway's MAC address to this trunk port with all the VLANs on it. That way, the BSD gateway in effect makes all forwarding decisions by tagging packets with their destination port. Once the switch's CAM isn't involved in deciding which port a packet should go out, the problem goes away.

This scheme is not much better than plugging everyone into a hub attached to the BSD router, since all traffic will flow over that interface anyway, and since the hub is also immune to port-stealing. The switch's only useful function here is to tag packets with the port on which they came in, to make it easier to locate abusers. In addition, it has a mundane but pretty important benefit for conferences---it accomodates broken Ethernet interfaces that incorrectly ``autodetect'' full-duplex mode and mess up the whole network whenever they are plugged into a hub. In my experience there are too many of these.

Having all the traffic flow over one port is reasonable. At conferences, everyone is just using the Internet anyway, not sending big files to each other, so there is no capacity benefit to an ASIC forwarding mesh. Although most conventional sysadmins balk at these anti-switch ideas, I insist that this extreme arrangement is appropriate for the edge at most campuses, too, because everyone is using miscellaneous resources that are all ``upstream.''

One important thing to understand is the distinction between the two problems. The arp problems that arpless solves apply equally to subnets on both switches and hubs. But this second ``port stealing'' problem doesn't apply to broadcast networks built from hubs, only to switches.