On Thursday, 19 de February de 2015 at 23:15, Kyle Mestery wrote:
> [Adding neutron tag to subject, comments below.]
>
> On Thu, Feb 19, 2015 at 3:55 PM, Ben Pfaff <b...@nicira.com
> (mailto: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.)
> >
Ah, yes, I know it, I’m tracking that effort to benchmark and
shed some numbers over the OVS+OF vs OVS+veths+LB+iptables
stateful firewalling/security groups.
I guess also routing namespaceless router benchmarking would make
sense too.
> > 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.
> >
> > 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.
> > 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).
> > 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://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
