<div dir="ltr">[Adding neutron tag to subject, comments below.]<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 19, 2015 at 3:55 PM, Ben Pfaff <span dir="ltr"><<a href="mailto:blp@nicira.com" target="_blank">blp@nicira.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[moving this conversation to openstack-dev because it's more<br>
interesting there and that avoids crossposting to a subscribers-only<br>
list]<br>
<br>
On Thu, Feb 19, 2015 at 10:57:02AM +0100, Miguel ??ngel Ajo wrote:<br>
>    I specially liked the VIF port lifecycle, looks good to me, Ionly miss some<br>
> ???port_security??? concepts we have in neutron, which I guess could have been<br>
> deliberately omitted for a start.<br>
><br>
>    In neutron we have something called security groups, and every port<br>
> belongs to 1 or more security groups.  Each security group has a list of<br>
> rules to control traffic at port level in a very fine grained fashion (ingress/egress<br>
> protocol/flags/etc???   remote_ip/mask or security_group ID)<br>
><br>
> I guess we could build  render security_group ID to multiple IPs for each port,<br>
> but then we will miss the ingress/egress and protocol flags (like type  of protocol,<br>
> ports, etc.. [1])<br>
><br>
> Also, be aware, that not having security group ID references from neutron,<br>
> when lot???s of ports go to the same security group we end up with an exponential<br>
> growth of rules / OF entries per port, we solved this in the server<->agent<br>
> communication for the reference OVS solution by keeping a lists of IPs<br>
> belonging to security group IDs, and then, separately having the<br>
> references from the rules.<br>
<br>
Thanks a lot for the comment.<br>
<br>
We aim to fully support security groups in OVN.  The current documents<br>
don't capture that intent.  (That's partly because we're planning to<br>
implement them in terms of some new "connection tracking" code for OVS<br>
that's still in the process of getting committed, and partly because I<br>
haven't fully thought them through yet.)<br>
<br>
My initial reaction is that we can implement security groups as<br>
another action in the ACL table that is similar to "allow" but in<br>
addition permits reciprocal inbound traffic.  Does that sound<br>
sufficient to you?<br>
<br>
Is the exponential explosion due to cross-producting, that is, because<br>
you have, say, n1 source addresses and n2 destination addresses and so<br>
you need n1*n2 flows to specify all the combinations?  We aim to solve<br>
that in OVN by giving the CMS direct support for more sophisticated<br>
matching rules, so that it can say something like:<br>
<br>
        ip.src in {<a>, <b>, <c>, ...} && ip.dst in {<d>, <e>, <f>, ...}<br>
        && (tcp.src in {80, 443, 8080} || tcp.dst in {80, 443, 8080})<br>
<br>
and let OVN implement it in OVS via the "conjunctive match" feature<br>
recently added, which is like a set membership match but more<br>
powerful.  It might still be nice to support lists of IPs (or<br>
whatever), since these lists could still recur in a number of<br>
circumstances, but my guess is that this will help a lot even without<br>
that.<br>
<br>
Thoughts?<br>
<br></blockquote><div>This all sounds really good to me Ben. I look forward to seeing the connection tracking code land and some design details on the security groups aspects of OVN published once that happens!<br><br>Thanks,<br>Kyle<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div></div>