[RFE] Support stateless firewall

[Giel Dops]

Neutron currently only provides stateful security groups. The rules of these security groups are then configured in a stateful manner.

The goal of this RFE is to support stateless security groups. Analogous to stateful security groups, all rules of a stateless security group will be implemented as stateless. The statefulness of a security group can be modified only if it has no associated ports. By default, security groups are stateful.

For some use cases, this statelessness will allow operators to choose for optimized datapath performance whereas stateful security groups impose extra processing on the system. On the downside, operators need to provision security group rules for ingress and egress to their exact intent, as reverse traffic is no longer automatically allowed.

The motivation for defining statefulness/statelessness at security group level and not at rule level is to avoid operational complexity when mixing up both. However, it would be possible to assign both stateless and stateful security groups to the same port.

From an API point of view, a new boolean attribute `stateful` will be added to security groups, defaulting to True. When the attribute is set to False, a stateless security group is created. As this attribute will be persisted, alembic migration is needed. Currently existing security groups will all be set to stateful during the alembic migration.

The following OpenStack components will need to be modified when implementing this feature:
  - neutron: implementing stateless security groups and unit tests
  - python-openstacksdk: add new resource property
  - python-openstackclient: support for the new security group attribute
  - horizon: adding the new security group attribute
  - heat: adding a resource property

We will implement and verify this feature for OVS/iptables.

[Nikolai de Figueiredo (ndefigueiredo)]

The introduction of stateless firewalling (much like ACLs) was discussed at the Rocky PTG. Are you aware of this? There is interest in this as an addition to the FWaaS sub-component of Neutron however the extension of security groups was not discussed.

[Giel Dops (nuage.gieldops)]

I was not aware of this actually. This RFE has been in the pipeline since before the PTG last week.

[Miguel Lavalle (minsel)]

Yes, we discussed stateless firewalling with the FWaaS team in Dublin Friday morning. The FWaaS is on-board with it. I think this should be one effort

[German Eichberger (german-eichberger)]

We had a brief discussion about this RfE in the weekly FWaaS meetings as well (http://eavesdrop.openstack.org/meetings/fwaas/2018/fwaas.2018-03-15-14.00.log.txt) and we would like to combine efforts as minsel suggested. Let's make sure we don't duplicate work.

I am also curious if we actually need that functionality in SG if we would add it to FWaaS.

[Nikolai de Figueiredo (ndefigueiredo)]

I was wondering the same thing. Should this extension be implemented as a part of SG or FWaaS?

I have created a summary of the feature and the possible approaches I can think of (https://docs.google.com/document/d/1pWU5wSIlba7oixpKT8CSxpJnFCJt8zJj18c-mVE9uUM/edit?usp=sharing).

I am of the opinion that this should be implemented as a part of FWaaS.

[Miguel Lavalle (minsel)]

@Giel,

Any feedback as to whether you are an on-board with pursuing this in the context of FWaaS?

[Miguel Lavalle (minsel)]

Stateless firewall is already being implemented by the Firewall team. Since we haven't heard from the submitter of this RFE, we will assume that approaching this from the FWaaS side is acceptable

[Miguel Lavalle (minsel)]

This RFE was discussed during today's drivers meeting. We agreed in continuing it as part of FWaaS. With that, the RFE is approved

[Kris Sterckx (krissterckx)]

Hi @minsel,

Apology for late response. Replying on behalf of Giel who left the team and Giel leaving caused the delay in our response.

At Nuage/Nokia we believe that as long as Security Groups are not deprecated in OpenStack, it would make sense the support statelessness for Security Groups as well.
If you're interested in what we did and share progress one to another, we could upload a patchset for a prototype implementation that we meanwhile have. We had some questions about how to deal with mixing stateless & stateful SG's on a given port though, hence initially we thought of disallowing that at the API (as a baseline implementation)

Let me know your thoughts.
Again, apology for late reply.

Kris

[Kris Sterckx (krissterckx)]

Hi

Please look at https://review.openstack.org/#/c/572767/ for what has been done by Nokia team so far wrt Stateless SG's.

It has at this stage been manually tested.

Also at this stage one can't combine stateful and stateless SG's on a same port.

Thanks

[Nguyen Phuong An (annp)]

Hi Kris,

From my understanding, I'd suggest you implement stateless firewall in FWaaS V2, then combining stateful and stateless on a same port is resolved. Because firewall group can work co-existence with security group at port-level.

[1]http://superuser.openstack.org/articles/firewall-service-openstack/

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/696070

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/696070
Committed: https://git.openstack.org/cgit/openstack/neutron-lib/commit/?id=f470973446e8ef9b25f5a038c4c6f1fbd854f7a2
Submitter: Zuul
Branch: master

commit f470973446e8ef9b25f5a038c4c6f1fbd854f7a2
Author: Aditya Reddy Nagaram <email address hidden>
Date: Tue Nov 26 12:46:10 2019 +0100

    add "stateful-security-group" api extension

    commit adds "stateful-security-group" API extension to
    neutron-lib for implementing stateless security groups.

    Needed-By: https://review.opendev.org/572767

    Partial-Bug: #1753466

    Change-Id: I72addb21b7515d7120768c91e02660258959373e