[RFE] ovs openflow security group driver

[sean mooney]

when using standard kernel ovs it may be desirable for performance reasons to use an ovs based security group driver.
When using ovs with dpdk it is not possible to use a kernel(ip tables) based security driver.

one effort leveraging the newly added kernel connection tracker support in ovs is tracked by
https://bugs.launchpad.net/neutron/+bug/1461000

ovs integration with conntrack will be supported in the upcoming ovs 2.5 release.
At present the proposed 2.5 release will only support conntrack with the linux kernel dataplane,
as such a conntrack based openflow security group driver can not currently be used with dpdk,windows or bsd
dataplanes.

to support the security group api with ovs without conntrack we would like summit the learn action based openflow firewall driver
current hosted in networking-ovs-dpdk for inclusion in neutron.
https://github.com/openstack/networking-ovs-dpdk/blob/master/networking_ovs_dpdk/agent/ovs_dpdk_firewall.py

The networking-ovs-dpdk OVSFirewallDriver was originally developed for liberty with support for ipv4 only.
subsequently support for ipv6 and and multicast have been developed(should be completed this week).
As this security group driver utilities reflective learn actions instead of connection tracking it can in theory support
all ovs datapath. the driver has been developed and tested with ovs 2.4 and both the linux kernel and dpdk datapaths.
Note that while both the iptables and connection tracking approach provide a stateful security group implementation
the lean action based ovs firewall driver uses a stateless design.

If both the conntrack and learn based security group drivers are accepted for the mitaka cycle the deployed
will then be able to select which driver to use based on the requirement of there system.

if the system has ovs 2.5+ and the kernel datapath and a kernel with conntrack support the conntrack based security driver can be used.

if the system has ovs 2.4+ with the userspace netdev datapath(bsd/dpdk) or kernel datapath (linux and possible windows) the learn based security group driver can be used.

if the system has ovs <=2.3 and is using the linux kernel datapath the current iptables security group driver can be used.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/264131

[Armando Migliaccio (armando-migliaccio)]

I am totally at loss here, isn't this a duplicate for bug 1461000?

[Armando Migliaccio (armando-migliaccio)]

Why are we tracking this differently?

[Armando Migliaccio (armando-migliaccio)]

Should this be renamed firewall driver for DPDK ovs installations?

[Armando Migliaccio (armando-migliaccio)]

I wonder what it would take to make the 2.5 release support conntrack with dpdk. OVS stateless firewall drivers have been dismissed for lack of feature parity ever since the initial security groups design, and I am not sure we want to overrule this in favor of dpdk based installations.

To be fair, the driver is available in the networking ovs dpdk repo, and this RFE is simply promoting the code ownership transfer, and I am not convinced this is worth our while.

Let's discuss this further at the drivers meeting.

[Rodolfo Alonso (rodolfo-alonso-hernandez)]

This firewall is designed for OVS 2.4+ and it's not specifically designed for DPDK.

This firewall is different to bug 1461000 in the following points:
- This implementation uses "learn actions", instead of conntrack.
- Can be used with OVS 2.4, which is the latest version available. OVS 2.5 with conntrack support is not yet ready.
- The use of conntrack it's limited now to Linux/Unix. The implementation presented in this driver uses only OpenFlow 1.1+ and can be deploy in any existent architecture, supporting OF 1.1

[Rodolfo Alonso (rodolfo-alonso-hernandez)]

About the ownership transfer. This driver of course is available in networking-ovs-repo, but the porpoise of this RFE is to make public and easy to access a piece of code fully working, compatible with the latest software versions and better performance than the IPtables firewall solution.

[Armando Migliaccio (armando-migliaccio)]

@Rodolfo: the driver you propose has been rejected in the past because of the feature gap with the iptables driver. I see no reason to revert this decision. As for the ownership transfer, the code available networking-ovs-repo is already public and easy to access, so I am not sure I see your point.

[sean mooney (sean-k-mooney)]

@Armando
what is the feature gap with iptables?
are you refuering to the TCP connection-state tracking?
Stateful acls are not an explicit part of the security group api but rather an
implicit artifact of the iptables implementation.

if stateful rules are truly part of the api definition then should that not be exposed via the api?
for example the ablity to say what happens to established or related flows?

incidentally it is possible to match on tcp flags as part of openflow rules so it should be possible to extend the learn based
approach to incorporate some stateful rules also. apart from scope creep one of the the reason we have not incorporated that is there is no api to express how related or established flow show be handled.

for example it would be possible in the case of tcp to have a learned rule set its fin_timeout to 0 on seeing the first FIN packet so that when the second fin packet is sent the learned rule is evicted.
similarly you could restrict adding the learned rule for the rpely to a SYN packet denoting a new connection in the case of tcp.
it may also be possible track established flow by using the write_metadata action.

im not sure there is value in tracking this additional state in the implementation without an ability to denote what actions should be ascribed to these connection states via the api.

[Armando Migliaccio (armando-migliaccio)]

Hi Sean,

Yes, that's the gap I am referring to. Your point on API is fair, I wish I could find the record of the many conversations we had on this very topic but I am unable to do so. Nonetheless the fact remains that for this reason (amongst other reasons like potential lack of scalability - do we have an idea of how many rules are being accrued in large deployments), a stateless driver was dismissed in the past.

We're pretty close to getting a fully functional firewall driver based on OVS. I realize that this is not quite there yet and may not work for dpdk, but what would it take to make it so, rather than promoting a totally different architecture?

[sean mooney (sean-k-mooney)]

hi armando,
i vaguely remember the conversations related to stateful vs non stateful firewall implementation
that took place at i want to say the paris summit? it was a while ago so i cant remember all the details
directly but i understand the rational for why the stateful approach is preferred. while we can support
new,established and closed state i our implementation if we wanted to the related flow are not possible with
our approach.

the openstack piece of the connection tracking driver tracked by https://bugs.launchpad.net/neutron/+bug/1461000
should work unmodifed with the dpdk datapath when the userspace conntrack implementation is merged.
we hope to pull down the ovs patches and start testing with the prototype conntrack driver probably next week.
if there are minor compatible tweek needed to make the conntrack driver work with dpdk we will submit patches to
ensure you can just drop in ovs with dpdk and use the driver when its available.

in parallel to our testing one of my counterparts in our vswitch team will be looking at the userspace patch series.
There is a currently a 12 patch series for adding this support proposed to the ovs mailing list.
My understading is that the 2.5 branch of ovs is already feature frozen so ignoring the fact that its ~2K lines of code it
is unlikely that it could be added to the 2.5 releases.

we have some concerns that the conntrack implementation may be a non trivial performance hit though the design of the
code does have some point where it could be optimised. incidentally the only public performance figure i am aware of was the following presentation (https://youtu.be/UQdiG3a_bpU?t=908) form the ovs conference in 2014 which suggested there was a 15-20% performance impact from connection tracking which seam high but until we actually test it we wont know how the proposed solution preforms.

[Assaf Muller (amuller)]

I think that the main use case for a learning based driver is DPDK, which is not a "core" feature. Couple that with our desire to make the conntrack based OVS firewall driver merged and work with DPDK in under a year, that makes the learning based driver a temporary piece of code whose main use case is a "niche" feature, that, to me, is the definition of something that should live out of tree. I also don't think the Neutron community can maintain 3 or 4 drivers (iptables, ovs conntrack and ovs learning, possibly nftables also). We should be narrowing our scope, not expanding it. I'm gonna side with Armando here.

[sean mooney (sean-k-mooney)]

i think your comment regarding maintaining 3-4 drivers is fair.

i would say their are two usecases:
1 dpdk
2 distros with old kernels but ovs 2.4+

for example centos 7.2 still uses 3.10 and conntrack requires 4.3 correct?
granted on centos you could simply use the iptables driver if your using ovs instead
so it is not a requirement.

we had intended on maintaining the driver in our stable/liberty branch of networking-ovs-dpdk
we can do the same for mitika. part of the reason for opening this bug was to gauge the appetite for
having multiple in tree drivers. another motivation was to raise awareness in the community that if you
want to have security groups when using dpdk there is a solution (albeit non stateful) available for liberty/mitaka
until conntrack support is added later this year in ovs 2.6

if there is general agreement in the neutron core team that it would be better to keep this out of the core tree then i can
withdraw/close the RFE and maintain this in networking-ovs-dpdk.

[Armando Migliaccio (armando-migliaccio)]

To me it's not so much out vs in (even though it plays an important part in my thinking process), but it's a matter of promoting the 'right' long term driver, because once people get their hands on them, it's difficult to get them to move away.

Obviously, the stateless driver is out there and anyone after the adequate due diligence is entitled to deploy it if they want to, but I simply don't think it's right for the Neutron community to endorse it as a viable long-term solution.

That said, this has been a great and educational chat for me and I have appreciated the input. For now, I am going to mark this provisionally as won't fix.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Rodolfo Alonso Hernandez (<email address hidden>) on branch: master
Review: https://review.openstack.org/264131

[sean mooney (sean-k-mooney)]

@Armando
hi i just wanted to add that now that
https://review.openstack.org/#/c/268192/ has been merged we no longer have the vlan informant we require
to implement our driver which means that we cannot support security groups with dpdk.

without another mechanism to pass the local vlan information to our driver we will have to wait till userpace conttrack is implemented. this is less then ideal as those who chose to depoly ovs-dpdk are forced to not have security group support for the foreseeable future.

[Armando Migliaccio (armando-migliaccio)]

Sean, the initial bug will need a new fix, which doesn't introduce a vulnerability. In fact I had opened 1512636 back.

[Armando Migliaccio (armando-migliaccio)]

bug 1512636