Probably the solution is not selected to be backported because: * It’s an intrusive change * Introduces new dependencies * Probably it’s going to introduce a performance penalty because eatables is slow.
I’m asking in reviews for this feature to be enabled/disabled via a flag. In the future I hope OVS with connection tracking to be merged, so then we can finally have a proper openvswitch_firewall_driver supporting stateful firewalling without reflective rules or flag matching (one is slow, the other is insecure…) Miguel Ángel Ajo On Saturday, 16 de May de 2015 at 23:28, George Shuklin wrote: > On 05/15/2015 07:48 PM, Jay Pipes wrote: > > On 05/15/2015 12:38 PM, George Shuklin wrote: > > > Just to let everyone know: broken antispoofing is not an 'security > > > issue' and the fix is not planned to be backported to Juno/kilo. > > > > > > https://bugs.launchpad.net/bugs/1274034 > > > > > > What can I say? All hail devstack! Who care about production? > > > > George, I can understand you are frustrated with this issue and feel > > strongly about it. However, I don't think notes like this are all that > > productive. > > > > Would a more productive action be to tell the operator community a bit > > about the vulnerability and suggest appropriate remedies to take? > > > > Ok, sorry. > > Short issue: If few tenants use same network (shared network) one tenant > may disrupt network activities of other tenant by sending a specially > crafted ARP packets on behave of the victim. Normally, Openstack > prohibit usage of unauthorized addresses (this feature is called > 'antispoofing' and it is essential for multi-tenant clouds). This > feature were subtly broken (malicious tenant may not use other addresses > but still may disrupt activities of other tenants). > > Finally, that bug has been fixed. But now they says 'oh, it is not that > important, we will not backport it to current releases, only to > "Libery"' because of new etables dependency. > > > _______________________________________________ > OpenStack-operators mailing list > [email protected] > (mailto:[email protected]) > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > >
_______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
