Comment 12 for bug 1274034

Thanks for the feedback Mathieu, and I absolutely agree. It's meant to be a mitigation approach as it only filters L3 and prevents the malicious VM from actually gathering any data. They can still DoS the L2 segment by hijacking traffic destined for the gateway (or any other IP for that matter), and L2 filtering (which the ebtables approach would accomplish) is the only way to stop that aspect of it.

There are also a few other things we're looking at to help beef up this area. One thing would be working to implement more robust port-security like features in the ovs-plugin-agent. As of OVS 1.10 they've implemented a drop_spoofed_arp flow action, which, while wouldn't necessarily address this specific issue, probably couldn't hurt to put on ports.

Regardless, we're doing some more testing in house to make sure it doesn't have any unintended effects, but assuming that all goes well I'll work on getting this patch into havana/icehouse. The processing overhead of one more chain should have a miniscule effect on throughput, and it can't hurt to have another validation that the packets are indeed coming and going to the correct place.