[RFE] Support stateless firewall

Bug #1753466 reported by Giel Dops
42
This bug affects 5 people
Affects Status Importance Assigned to Milestone
neutron
Fix Released
Wishlist
Tom Stappaerts

Bug Description

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.

Changed in neutron:
assignee: nobody → Giel Dops (nuage.gieldops)
Revision history for this message
Nikolai de Figueiredo (ndefigueiredo) wrote :

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.

Revision history for this message
Giel Dops (nuage.gieldops) wrote :

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

tags: added: fwaas sg-fw
tags: added: api
Changed in neutron:
status: New → Confirmed
importance: Undecided → Wishlist
Revision history for this message
Miguel Lavalle (minsel) wrote :

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

tags: added: rfe-confirmed
removed: rfe
Revision history for this message
German Eichberger (german-eichberger) wrote :

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.

Revision history for this message
Nikolai de Figueiredo (ndefigueiredo) wrote :

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.

Revision history for this message
Miguel Lavalle (minsel) wrote :

@Giel,

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

Revision history for this message
Miguel Lavalle (minsel) wrote :

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

tags: added: rfe-triaged
removed: rfe-confirmed
Revision history for this message
Miguel Lavalle (minsel) wrote :

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

summary: - [RFE] Support stateless security groups
+ [RFE] Support stateless firewall
tags: added: rfe-approved
removed: rfe-triaged
Revision history for this message
Kris Sterckx (krissterckx) wrote :

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

Revision history for this message
Kris Sterckx (krissterckx) wrote :

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

Revision history for this message
Nguyen Phuong An (annp) wrote :

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/

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron-lib (master)

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

Changed in neutron:
assignee: Giel Dops (nuage.gieldops) → aditya_reddy.nagaram@nuagenetworks.net (adityarn)
status: Confirmed → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron-lib (master)

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

Revision history for this message
Tom Stappaerts (tstappae) wrote :

Hi everyone, with the merge in of the fullstack tests and the CLI commands, I regard this RFE as implemented now. Please let me know if there are any concerns.

Changed in neutron:
status: In Progress → Fix Committed
assignee: aditya_reddy.nagaram@nuagenetworks.net (adityarn) → Tom Stappaerts (tstappae)
Revision history for this message
Bernard Cafarelli (bcafarel) wrote :

As discussed in Victoria PTG, I created separate LP bugs to add OVS firewall and OVN support:
https://bugs.launchpad.net/neutron/+bug/1885261
https://bugs.launchpad.net/neutron/+bug/1885262

Revision history for this message
LIU Yulong (dragon889) wrote :

Is there anyone going to implement ml2 OVS backend stateless security group without iptables?

Changed in neutron:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.