<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>
<div>I always thought that ebtables was below the stack in the iptables schema - but still part of netfilter - thus should be reasonably fast (I would argue faster than a user space lookup to openvswitchd). Considering the rules being added are small in number
and trivial (on this port allow src/dst mac of blah). Do you have any performance data showing that its slow? A quick google search shows nothing relevant :-). Additionally, libvirt anti-spoofing rules configured via nova using nwfilter uses ebtables to
do the anti spoofing rules. No one seems to complain about the performance of that...</div>
<div><br>
</div>
<div>Additionally, some of us don’t want to run OVS, so an OVS only solution is effectively imho - crap. We are actively looking at removing OVS from our environment due to a number of reasons. So saying if you run neutron and care to have *REAL* network
protection - you need to run OVS - seems like a stretch if you aren't using GRE/vxlan tunneling for all of your guests.</div>
<div><br>
</div>
<div>I personally agree with George, this stance of "We never said that neutron would provide anti-spoofing on flat networks thus we wont backport this, because it now brings into scope ebtables", seems to be a pretty huge gap in what neutron says it does and
the protection it actually provides. We supply security group rules, but stealing someone else's IP or the gateway that doesn't belong to you - yep that totally cool with us. It strikes me that neutrons goal to deliver networking is basically two fold. 1.)
Provide multi-tenant networking 2.) Make sure tenants cant stomp on each other. Without number 2 (anti-spoofing) you kinda fail to provide number 1. Since, flat networks are a 100% supported and viable way of doing tenant networking I would say that this
is a bug and should be backported to kilo/juno.</div>
<div><br>
</div>
<div>I don’t personly buy the new dependency reason, new to neutron - maybe - but not new to people running nova/libvirt. Ebtables is used by libvirt for nwfilter, assuming an pretty standard libvirt install ebtables should be installed by default. Additionally,
this would have already been a dependency in nova-compute due to anti-spoofing support there.</div>
<div>
<div>
<div>____________________________________________</div>
<div> </div>
<div>Kris Lindgren</div>
<div>Senior Linux Systems Engineer</div>
<div>GoDaddy, LLC.</div>
<div><br>
</div>
</div>
</div>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Miguel Ángel Ajo <<a href="mailto:majopela@redhat.com">majopela@redhat.com</a>><br>
<span style="font-weight:bold">Date: </span>Sunday, May 17, 2015 at 6:33 AM<br>
<span style="font-weight:bold">To: </span>George Shuklin <<a href="mailto:george.shuklin@gmail.com">george.shuklin@gmail.com</a>><br>
<span style="font-weight:bold">Cc: </span>"<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a>" <<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [Openstack-operators] Raising the degree of the scandal<br>
</div>
<div><br>
</div>
<div>
<div>
<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>
</div>
</div>
</span>
</body>
</html>