<div dir="ltr">That patch was reverted because it relied on a non-obvious corner case to work. A port would not get any spoofing prevention if it had no IP addresses. <div><br></div><div>At first we reasoned that this would be okay since the only way to create a port without IPs was if the network has no subnets and it doesn't make sense for Neutron to do L3 protection on a network it doesn't manage L3 for. However, this was an issue once a subnet was subsequently added to the network. A port would still be remaining without IP addresses and it wouldn't have any spoofing prevention. We don't want these kind of corner cases in the API so we reverted it.</div><div><br></div><div>><span style="font-size:12.8000001907349px">One possible solution we could do to prevent this is to keep flow entries that block the port </span><span style="font-size:12.8000001907349px">from pretending to have an IP that is already part of the network (or subnet).</span></div><div><br></div><div>Three issues with this I can see right away:</div><div><ul><li>This breaks protection for provider network scenarios where the provider has a router that Neutron doesn't know about. </li><li>It introduces a window of attack where you can send gratuitous ARP for all of the IP addresses which aren't in use and collect traffic to new ports as they come online before the ARP entries time out.<br></li><li>Each L2 agent is now going to require an ARP flow rule for every other port's IP/MAC on the same network. This could easily be 10,000+ of rules on a densely packed node (50 VMs on 200 port networks). Syncing this info will need a reliability mechanism to make there are no missed messages (which result in vulnerabilities).</li></ul><div><br></div></div><div>Why can you just use the port security API to disable port security for the port? If the issue is just that you want MAC spoofing prevention but nothing else, then we need to adjust the port security API to be more fine-grained.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 2, 2015 at 1:37 AM, Gal Sagie <span dir="ltr"><<a href="mailto:gal.sagie@gmail.com" target="_blank">gal.sagie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hello All,<br><br></div>The un-addressed port spec [1] was approved for Liberty.<br></div>I think this spec has good potential to provide very interesting solutions for NFV use cases <br></div><div>but also for multi site connectivity and i would really want to see<br></div><div>it move forward with the community.<br><br></div><div>There are some issues we need to discuss regarding L2 population (both for the reference<br></div><div>implementation and for any "SDN" solution), but we can iterate on them.<br><br></div><div>This email relates to a recent revert [2] that was done to prevent spoofing possibility<br></div><div>due to recent work that was merged.<br><br></div><div>If i understand the problem correctly, an un-addressed port can now perform ARP spoofing<br></div><div>on an address of a port that already exists in the same network and listen to its traffic.<br></div><div>(a problem which becomes bigger with shared network among tenants)<br></div><div><br></div><div>One possible solution we could do to prevent this is to keep flow entries that block the port<br></div><div>from pretending to have an IP that is already part of the network (or subnet).<br></div><div>So there will be ARP spoofing checks that check the port is not answering for an IP that is already<br></div><div>configured.<br></div><div><u>Any thoughts/comments on that?</u><br><br></div><div>Unrelated to this, i think that an un-address port should work in subnet context when it comes<br></div><div>to L2 population and traffic forwarding, so that un-address port only gets traffic for addresses <br></div><div>that are not found, but are on the same subnet as the un-address port.<br></div><div>(I understand this is a bigger challenge and is not working with the way Neutron networks <br></div><div>work today, but we can iterate on this as well since its unrelated to the security subject)<br> </div><div><div><br>Thanks<br>Gal.<br><br>[1] <a href="https://github.com/openstack/neutron-specs/blob/master/specs/liberty/unaddressed-port.rst" target="_blank">https://github.com/openstack/neutron-specs/blob/master/specs/liberty/unaddressed-port.rst</a><br>[2] <a href="https://review.openstack.org/#/c/218470/" target="_blank">https://review.openstack.org/#/c/218470/</a><br></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>
</div>