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