<div>
<br>
</div>
<div><div><span style="color: rgb(160, 160, 168);">On Thursday, 19 de February de 2015 at 23:15, Kyle Mestery wrote:</span></div></div>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div><div dir="ltr">[Adding neutron tag to subject, comments below.]<br><div><div><br><div>On Thu, Feb 19, 2015 at 3:55 PM, Ben Pfaff <span dir="ltr"><<a href="mailto:blp@nicira.com" target="_blank">blp@nicira.com</a>></span> wrote:<br><blockquote type="cite"><div>[moving this conversation to openstack-dev because it's more<br>
interesting there and that avoids crossposting to a subscribers-only<br>
list]<br>
<br>
On Thu, Feb 19, 2015 at 10:57:02AM +0100, Miguel ??ngel Ajo wrote:<br>
> I specially liked the VIF port lifecycle, looks good to me, Ionly miss some<br>
> ???port_security??? concepts we have in neutron, which I guess could have been<br>
> deliberately omitted for a start.<br>
><br>
> In neutron we have something called security groups, and every port<br>
> belongs to 1 or more security groups. Each security group has a list of<br>
> rules to control traffic at port level in a very fine grained fashion (ingress/egress<br>
> protocol/flags/etc??? remote_ip/mask or security_group ID)<br>
><br>
> I guess we could build render security_group ID to multiple IPs for each port,<br>
> but then we will miss the ingress/egress and protocol flags (like type of protocol,<br>
> ports, etc.. [1])<br>
><br>
> Also, be aware, that not having security group ID references from neutron,<br>
> when lot???s of ports go to the same security group we end up with an exponential<br>
> growth of rules / OF entries per port, we solved this in the server<->agent<br>
> communication for the reference OVS solution by keeping a lists of IPs<br>
> belonging to security group IDs, and then, separately having the<br>
> references from the rules.<br>
<br>
Thanks a lot for the comment.<br>
<br>
We aim to fully support security groups in OVN. The current documents<br>
don't capture that intent. (That's partly because we're planning to<br>
implement them in terms of some new "connection tracking" code for OVS<br>
that's still in the process of getting committed, and partly because I<br>
haven't fully thought them through yet.)<br>
<br></div></blockquote></div></div></div></div></div></div></span></blockquote><div><span style="font-size: 14px;">Ah, yes, I know it, I’m tracking that effort to benchmark and</span></div><div><span style="font-size: 14px;">shed some numbers over the OVS+OF vs OVS+veths+LB+iptables</span></div><div><span style="font-size: 14px;">stateful firewalling/security groups.</span></div><div><span style="font-size: 14px;"><br></span></div><div><span style="font-size: 14px;">I guess also routing namespaceless router benchmarking would make</span></div><div><span style="font-size: 14px;">sense too.</span></div><div><span style="font-size: 14px;"><br></span></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div dir="ltr"><div><div><div><blockquote type="cite"><div>
My initial reaction is that we can implement security groups as<br>
another action in the ACL table that is similar to "allow" but in<br>
addition permits reciprocal inbound traffic. Does that sound<br>
sufficient to you?<br></div></blockquote></div></div></div></div></div></div></span></blockquote><div><span style="font-size: 14px;">Yes, having fine grained allows (matching on protocols, ports, and</span></div><div><span style="font-size: 14px;">remote ips would satisfy the neutron use case).</span></div><div><span style="font-size: 14px;"><br></span></div><div><span style="font-size: 14px;">Also we use connection tracking to allow reciprocal inbound traffic</span></div><div><span style="font-size: 14px;">via ESTABLISHED/RELATED, </span><span style="font-size: 14px;">any equivalent solution would do.</span></div><div><span style="font-size: 14px;"><br></span></div><div><span style="font-size: 14px;">For reference, our SG implementation, currently is able to match on</span></div><div><span style="font-size: 14px;">combinations of:</span></div><div><span style="font-size: 14px;"><br></span></div><div><span style="font-size: 14px;">* direction: ingress/egress</span></div><div><span style="font-size: 14px;">* protocol: icmp/tcp/udp/<raw number></span></div><div><span style="font-size: 14px;">* port_range: min-max (it’s always dst)</span></div><div><span style="font-size: 14px;">* L2 packet ethertype: IPv4, IPv6, etc...</span></div><div><span style="font-size: 14px;">* remote_ip_prefix: as a CIDR or * </span><span style="font-size: 14px;">remote_group_id (to reference all other IPs in a certain group)</span></div><div><br></div><div><span style="font-size: 14px;">All of them assume connection tracking so known connection packets will</span></div><div><span style="font-size: 14px;">go the other way around.</span></div><div><br></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div dir="ltr"><div><div><div><blockquote type="cite"><div>
<br>
Is the exponential explosion due to cross-producting, that is, because<br>
you have, say, n1 source addresses and n2 destination addresses and so<br>
you need n1*n2 flows to specify all the combinations? We aim to solve<br>
that in OVN by giving the CMS direct support for more sophisticated<br>
matching rules, so that it can say something like:<br>
<br>
ip.src in {<a>, <b>, <c>, ...} && ip.dst in {<d>, <e>, <f>, ...}<br>
&& (tcp.src in {80, 443, 8080} || tcp.dst in {80, 443, 8080})<br></div></blockquote></div></div></div></div></div></div></span></blockquote><div><br></div><div><span style="font-size: 14px;">That sounds good and very flexible.</span></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div dir="ltr"><div><div><div><blockquote type="cite"><div>
<br>
and let OVN implement it in OVS via the "conjunctive match" feature<br>
recently added, which is like a set membership match but more<br>
powerful. </div></blockquote></div></div></div></div></div></div></span></blockquote><div><span style="font-size: 14px;">Hmm, where can I find examples about that feature, sounds interesting.</span></div><div> </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div dir="ltr"><div><div><div><blockquote type="cite"><div> It might still be nice to support lists of IPs (or<br>
whatever), since these lists could still recur in a number of<br>
circumstances, but my guess is that this will help a lot even without<br>
that.<br>
<br></div></blockquote></div></div></div></div></div></div></span></blockquote><div><span style="font-size: 14px;">As afar as I understood, given the way megaflows resolve rules via hashes</span></div><div><span style="font-size: 14px;">even if we had lots of rules with different ip addresses, that would be very fast,</span></div><div><span style="font-size: 14px;">probably as fast or more than our current ipset solution.</span></div><div><span style="font-size: 14px;"><br></span></div><div><span style="font-size: 14px;">The only caveat would be having to update lots of flow rules when a port goes</span></div><div><span style="font-size: 14px;">in or out of a security group, since you have to go and clear/add the rules to each</span></div><div><span style="font-size: 14px;">single port on the same security group (as long as they have 1 rule referencing the sg).</span></div><div><br></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div dir="ltr"><div><div><div><blockquote type="cite"><div>
Thoughts?<br>
<br></div></blockquote><div>This all sounds really good to me Ben. I look forward to seeing the connection tracking code land </div></div></div></div></div></div></div></span></blockquote><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div dir="ltr"><div><div><div><div>and some design details on the security groups aspects of OVN published once that happens!</div></div></div></div></div></div></div></span></blockquote><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div dir="ltr"><div><div><div><div><br>Thanks,<br>Kyle<br> <br></div><blockquote type="cite"><div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></blockquote></div><br></div></div></div>
</div></div></span>
</blockquote>
<div>
<br>
</div>