neutron

Bug #1274034
Comment #48

Comment 48 for bug 1274034

Revision history for this message

Kris Lindgren (klindgren) wrote on 2015-05-18:

#48

Re: just that it was not a problem Neutron's anti-spoofing rules were originally designed to solve (much in the same way that a you wouldn't consider a helmet flawed just because it fails to protect your knees).

Considering this commit when allowed address pairs were added/refactored and the name previous name of this function: https://github.com/openstack/neutron/commit/b67b20832a5bfccd1bbf8d1e63ebcd7061856881

Or if thats not good enough - the original commit that added security group rules to begin with:
https://github.com/openstack/neutron/commit/f14af5dc755706c7297a96fa504acdfe15ac1957#diff-65b266f9e013df37c4934f0b1007897cR168

The original function of that code piece was specifically called out to do ARP SPOOFING filtering/prevention. It's just that the person who originally did it probably didn't realize that you cant correctly filter arp via iptables. So lets call a spade a spade here. Its not an "imperfect design", its not an "incomplete design", it not that "neutron or quantum didn't try to filter or have features to prevent arp spoofing/cache poisoning. Its a bug going back since security groups were implemented in neutron(actually quantum). This got masked by a few code refactors when allowed address pairs was added, but the intent to do arp filter since the "dawn of time" is clearly there.

So I would say based upon the code and the intent with the applied rules, this is more of the case of complaining because the helmet that you were wearing (that you were told is specifically suppose to protect you in the event of something bad) failed to protect your head and the kneepads that you were also wearing also failed to protect you knees.

Lets do the right thing here. Backport the fix to the stable versions. Admit that the protections we thought we original added 2+ years ago failed to actually do what we thought they did. And move on with bigger and better problems. Jeremy you even said in post #6 that if neutron documentation or config options says it specifically implements code to do the filter that it would be a vulnerability. Well the original code says it was suppose to filter ARP spoofing, it doesn't.

Re:  just that it was not a problem Neutron's anti-spoofing rules were originally designed to solve (much in the same way that a you wouldn't consider a helmet flawed just because it fails to protect your knees).

Or if thats not good enough - the original commit that added security group rules to begin with: 
https://github.com/openstack/neutron/commit/f14af5dc755706c7297a96fa504acdfe15ac1957#diff-65b266f9e013df37c4934f0b1007897cR168

The original function of that code piece was specifically called out to do ARP SPOOFING filtering/prevention.  It's just that the person who originally did it probably didn't realize that you cant correctly filter arp via iptables.  So lets call a spade a spade here.  Its not an "imperfect design", its not an "incomplete design", it not that "neutron or quantum didn't try to filter or have features to prevent arp spoofing/cache poisoning.  Its a bug going back since security groups were implemented in neutron(actually quantum).  This got masked by a few code refactors when allowed address pairs was added, but the intent to do arp filter since the "dawn of time" is clearly there.

Lets do the right thing here.   Backport the fix to the stable versions.  Admit that the protections we thought we original added 2+ years ago failed to actually do what we thought they did.  And move on with bigger and better problems.   Jeremy you even said in post #6 that if neutron documentation or config options says it specifically implements code to do the filter that it would be a vulnerability.  Well the original  code says it was suppose to filter ARP spoofing, it doesn't.