Breaking the standards

In what's becoming something of a tradition in Network World tests, this project turned up design flaws in two standards: IEEE 802.1X authentication, which we tested in a NAC context, and IETF RFC 3918 covering multicast testing.

The 802.1X testing turned up a problem with "multi-auth" configurations, where multiple users attached to the same switch port should be authenticated before being granted access to network resources. Multi-auth can be useful anytime more than one computer may be attached to a switch port. Common use cases include a hub attached to the single Ethernet port in a conference room; an IP phone with a pass-through port for a PC; and a WLAN access point, which in turn fields connections from multiple users.

The problem is, though, the 802.1X standard doesn't address any of these use cases. The access control mechanism defined in 802.1X, called the port access entity (PAE), has a state machine that's either on or off for all traffic flowing through the switch port. There's no selective on/off switch that would permit authenticated traffic while blocking everything else. The danger here is similar to that of "badge tailgaiting" at an office building: The first user must use a badge, but then any number of unauthorized users can walk right in as long as the door is open.

Multi-auth is by definition a violation of the 802.1X protocol. Some vendors get around this by implementing multiple state machines, one for each MAC address seen. Others simply authenticate the first user seen, and then permit all traffic after that.

Testing also revealed a logic problem with RFC 3918, the industry standard methodology for IP multicast performance measurement. In the RFC's test for measuring group capacity, a test run is considered successful if at least one frame from each subscribed multicast group is received. However, when users subscribe to more groups than a switch can handle (this would likely only happen in a lab setting) the switch simply floods all multicast traffic to all ports regardless of whether subscribed users are attached. Thus, every iteration of this test will "pass," even iterations with flooding.

As a workaround, Network Test and Spirent Communications developed an alternative method that introduces one or more "spy" ports to detect flooding. The author proposed this change to the IETF's benchmarking working group, which may take it up for consideration.

-- David Newman