Thanks for both of those bits of information. I've added an "allow-related" action for v3.
On Thu, Feb 19, 2015 at 06:38:46PM -0800, Kevin Benton wrote: > Yes, if there is an action similar to the 'RELATED' and 'ESTABLISHED' > keywords, then that should be adequate to replace the iptables solution > that we have now. > > You are correct about the reason behind the explosion of rules. In security > groups, we allow the source/dest field to be a reference to a security > group. That was resulting in one security group rule turning into N > iptables rules, where N was the number of IPs in the security group. This > was resolved using IP sets. If OVN supports the set syntax you described, > that should achieve parity on that front as well. > > > On Thu, Feb 19, 2015 at 2:15 PM, Kyle Mestery <[email protected]> wrote: > > > [Adding neutron tag to subject, comments below.] > > > > On Thu, Feb 19, 2015 at 3:55 PM, Ben Pfaff <[email protected]> wrote: > > > >> [moving this conversation to openstack-dev because it's more > >> interesting there and that avoids crossposting to a subscribers-only > >> list] > >> > >> On Thu, Feb 19, 2015 at 10:57:02AM +0100, Miguel ??ngel Ajo wrote: > >> > I specially liked the VIF port lifecycle, looks good to me, Ionly > >> miss some > >> > ???port_security??? concepts we have in neutron, which I guess could > >> have been > >> > deliberately omitted for a start. > >> > > >> > In neutron we have something called security groups, and every port > >> > belongs to 1 or more security groups. Each security group has a list of > >> > rules to control traffic at port level in a very fine grained fashion > >> (ingress/egress > >> > protocol/flags/etc??? remote_ip/mask or security_group ID) > >> > > >> > I guess we could build render security_group ID to multiple IPs for > >> each port, > >> > but then we will miss the ingress/egress and protocol flags (like type > >> of protocol, > >> > ports, etc.. [1]) > >> > > >> > Also, be aware, that not having security group ID references from > >> neutron, > >> > when lot???s of ports go to the same security group we end up with an > >> exponential > >> > growth of rules / OF entries per port, we solved this in the > >> server<->agent > >> > communication for the reference OVS solution by keeping a lists of IPs > >> > belonging to security group IDs, and then, separately having the > >> > references from the rules. > >> > >> Thanks a lot for the comment. > >> > >> We aim to fully support security groups in OVN. The current documents > >> don't capture that intent. (That's partly because we're planning to > >> implement them in terms of some new "connection tracking" code for OVS > >> that's still in the process of getting committed, and partly because I > >> haven't fully thought them through yet.) > >> > >> My initial reaction is that we can implement security groups as > >> another action in the ACL table that is similar to "allow" but in > >> addition permits reciprocal inbound traffic. Does that sound > >> sufficient to you? > >> > >> Is the exponential explosion due to cross-producting, that is, because > >> you have, say, n1 source addresses and n2 destination addresses and so > >> you need n1*n2 flows to specify all the combinations? We aim to solve > >> that in OVN by giving the CMS direct support for more sophisticated > >> matching rules, so that it can say something like: > >> > >> ip.src in {<a>, <b>, <c>, ...} && ip.dst in {<d>, <e>, <f>, ...} > >> && (tcp.src in {80, 443, 8080} || tcp.dst in {80, 443, 8080}) > >> > >> and let OVN implement it in OVS via the "conjunctive match" feature > >> recently added, which is like a set membership match but more > >> powerful. It might still be nice to support lists of IPs (or > >> whatever), since these lists could still recur in a number of > >> circumstances, but my guess is that this will help a lot even without > >> that. > >> > >> Thoughts? > >> > >> 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! > > > > Thanks, > > Kyle > > > > > >> __________________________________________________________________________ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: > >> [email protected]?subject:unsubscribe > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: [email protected]?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > -- > Kevin Benton __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
