Open Stack

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
> OpenStack-operators at lists.openstack.org (mailto:OpenStack-operators at lists.openstack.org)
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>  
>  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150517/d0914c0d/attachment.html>