A while ago I described the need for BPDU guard in hypervisor switches, and not surprisingly got a number of “it’s there” tweets seconds after vSphere 5.1 (which includes BPDU guard) was launched. Rickard Nobel also did a magnificent job of replicating the problem my blog post is describing and verifying vSphere 5.1 stops a BPDU denial-of-service attack.
Imagine a happily-running simple network with two switches, two hypervisors and two VMs belonging to the same VLAN:
Now, for whatever weird reason the VM administrator decides to configure a VPN (or GRE) tunnel between the VMs and enables bridging between the Ethernet interface and the tunnel on both VMs.
Actions like this are usually caused by Monte Carlo approach to device configuration: trying every combination of GUI-accessible features till one of them appears to be working. The Heisenbergian properties of this approach can be greatly enhanced by throwing random results of Google search at the problem.
Unless the VM administrator manages to mangle all the intelligence built into the VM protocol stack (and there are always ways of doing that – see DisableSTA in Windows registry), the VMs configured as bridges start sending BPDUs through their physical interface, and any properly configured switch shuts down the offending port, preventing a forwarding loop ... and hosing the hypervisor host and all its VMs as a collateral damage.
A malicious tenant could misuse BPDU guard for a BPDU-based denial-of-service attack (details in Rickard Nobel’s blog post), and VMware decided to prevent that by implementing BPDU filter (Net.BlockGuestBPDU variable) in its vSwitch. BPDU filter definitely prevents DoS attacks ... but it also destroys any chance of ever detecting a forwarding loop.
While you can prevent bridging-induced forwarding loops with the combination of BPDU filter and reject forged transmits (described in more details in my original blog post), you’re still avoiding the symptoms, not fixing the problem. Any VM doing unauthorized bridging should be immediately disconnected from the vSwitch – which just might prompt its administrator to correct the faulty settings.
Instead of that, VMware unfortunately decided to go down the familiar never ever disturb the VM, let’s just pretend everything is OK route (and it’s definitely easier to implement drop packets with SNAP value 0x010B code than shut down the offending interface and log the event one).
Summary: vSwitch BPDU filter is a great step in the right direction, but we still need the solution (BPDU Guard) not a band-aid combo. Oh, and did I mention that neither BPDU filter nor reject forged transmits are enabled by default?