[Adding neutron tag to subject, comments below.]
On Thu, Feb 19, 2015 at 3:55 PM, Ben Pfaff <b...@nicira.com> 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
