Open Stack

On Friday, 20 de February de 2015 at 17:06, Ben Pfaff wrote:
> 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.)
>  
>  

That makes sense.

>  
> > > > 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.  
>  
>  

Amazing, yes, it seems like conjunctions will do the work quite optimally
at OpenFlow level.

My hat off… :)
> (This
> isn't the form that Neutron would use with OVN; that is the Boolean
> expression syntax above.)
>  
Of course, understood, I was curious about the low level supporting the
high level 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.
>  
>  

Of course, 1 step at a time. I will do a 2nd pass on your documents, looking a bit
more on the higher level. I’m very happy to see that the low level is very well tied
up and capable.

Best regards,
Miguel Ángel.
  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150220/fa6ee8b3/attachment.html>