Open Stack

On Fri, Feb 20, 2015 at 12:45:46PM +0100, Miguel Ángel Ajo wrote:
> On Thursday, 19 de February de 2015 at 23:15, Kyle Mestery wrote:  
> > On Thu, Feb 19, 2015 at 3:55 PM, Ben Pfaff <blp at nicira.com (mailto:blp at nicira.com)> wrote:
> > > 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?
> Yes, having fine grained allows (matching on protocols, ports, and
> remote ips would satisfy the neutron use case).
> 
> Also we use connection tracking to allow reciprocal inbound traffic
> via ESTABLISHED/RELATED, any equivalent solution would do.
> 
> For reference, our SG implementation, currently is able to match on
> combinations of:
> 
> * direction: ingress/egress
> * protocol: icmp/tcp/udp/<raw number>
> * port_range:  min-max   (it’s always dst)
> * L2 packet ethertype: IPv4, IPv6, etc...
> * remote_ip_prefix: as a CIDR   or    * remote_group_id (to reference all other IPs in a certain group)
> 
> All of them assume connection tracking so known connection packets will
> go the other way around.

OK.  All of those should work OK.  (I don't know for sure whether we'll
have explicit groups; initially, probably not.)

> > > 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})
> 
> That sounds good and very flexible.
> > >  
> > > and let OVN implement it in OVS via the "conjunctive match" feature
> > > recently added, which is like a set membership match but more
> > > powerful.  
> Hmm, where can I find examples about that feature, sounds interesting.

If you look at ovs-ofctl(8) in a development version of OVS, such as
        http://benpfaff.org/~blp/dist-docs/ovs-ofctl.8.pdf
search for "conjunction", which explains the implementation.  (This
isn't the form that Neutron would use with OVN; that is the Boolean
expression syntax above.)

> > > 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.
> > >  
> As afar as I understood, given the way megaflows resolve rules via hashes
> even if we had lots of rules with different ip addresses, that would be very fast,
> probably as fast or more than our current ipset solution.
> 
> The only caveat would be having to update lots of flow rules when a port goes
> in or out of a security group, since you have to go and clear/add the rules to each
> single port on the same security group (as long as they have 1 rule referencing the sg).

That sounds like another good argument for allowing explicit groups.  I
have a design in mind for that but I doubt it's the first thing to
implement.