[openstack-dev] [Neutron] FWaaS: Support for explicit commit

Aaron Rosen arosen at nicira.com
Thu Aug 8 00:19:51 UTC 2013


Hi Sumit,

Neutron has a concept of a bulk creation where multiple things can be
created in one api request rather that N (and then be implemented
atomically on the backend). In my opinion, I think it would be better to
implement a bulk update/delete operation rather than a commit. I think that
having something like this that is generic could be useful to other api's
in neutron.

I do agree that one has to keep track of the order they are
changing/adding/delete rules so that they don't allow two things to
communicate that shouldn't be allowed to. If someone wanted to perform this
type of bulk atomic change now could they create a new profile with the
rules they desire and then switch out which profile is attached to the
firewall?

Best,

Aaron


On Wed, Aug 7, 2013 at 3:40 PM, Sumit Naiksatam <sumitnaiksatam at gmail.com>wrote:

> We had some discussion on this during the Neutron IRC meeting, and per
> that discussion I have created a blueprint for this:
>
> https://blueprints.launchpad.net/neutron/+spec/neutron-fwaas-explicit-commit
>
> Further comments can be posted on the blueprint whiteboard and/or the
> design spec doc.
>
> Thanks,
> ~Sumit.
>
> On Fri, Aug 2, 2013 at 6:43 PM, Sumit Naiksatam
> <sumitnaiksatam at gmail.com> wrote:
> > Hi All,
> >
> > In Neutron Firewall as a Service (FWaaS), we currently support an
> > implicit commit mode, wherein a change made to a firewall_rule is
> > propagated immediately to all the firewalls that use this rule (via
> > the firewall_policy association), and the rule gets applied in the
> > backend firewalls. This might be acceptable, however this is different
> > from the explicit commit semantics which most firewalls support.
> > Having an explicit commit operation ensures that multiple rules can be
> > applied atomically, as opposed to in the implicit case where each rule
> > is applied atomically and thus opens up the possibility of security
> > holes between two successive rule applications.
> >
> > So the proposal here is quite simple -
> >
> > * When any changes are made to the firewall_rules
> > (added/deleted/updated), no changes will happen on the firewall (only
> > the corresponding firewall_rule resources are modified).
> >
> > * We will support an explicit commit operation on the firewall
> > resource. Any changes made to the rules since the last commit will now
> > be applied to the firewall when this commit operation is invoked.
> >
> > * A show operation on the firewall will show a list of the currently
> > committed rules, and also the pending changes.
> >
> > Kindly respond if you have any comments on this.
> >
> > Thanks,
> > ~Sumit.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130807/ce10fd12/attachment.html>


More information about the OpenStack-dev mailing list