Open Stack

Hi,
Thanks for posting this. This is very interesting. I think that there are a number of different things to take into account here:

  1.  There is a service chaining project in Neutron https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining. Is the API there sufficient or different?
  2.  I do not think that adding an extension to the OVN is the correct way to go here. That means that the community cannot share the common API (this is related to the point above). The plugin implementation details are specific to the networking solution.

Thanks
Gary

From: John McDowall <jmcdowall at paloaltonetworks.com<mailto:jmcdowall at paloaltonetworks.com>>
Reply-To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Monday, March 21, 2016 at 11:18 PM
To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: [openstack-dev] [networking-ovn][ovn4nfv]

All,

As a VNF vendor we have been looking at ways to enable customers to simply
scale up (and down) VNF’s in complex virtual networks at scale. Our goal
is to help accelerate the deployment of SDN and VNF’s and more
specifically enable zero-trust security at scale for applications.  This
requires the easy and fast deployment of Next Generation Firewalls (and
other VNF¹s) into the traffic path of any application.

Over the last several weeks we have created a prototype that implements
a simple VNF insertion approach. Before we do additional work we have a
couple of questions for the community:

Questions
‹‹‹‹‹‹‹‹‹

1. This approach has the advantage of being very simple and works with
existing VNF¹s, does it make sense to the community?
2. If it is of interest how could it be improved and or enhanced to make
it more useful and consumable?

Design Guidelines
‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹

At the start of the effort we created a set of design guidelines to
constrain the problem space.


* The goal is a Service Function Insertion (SFI) approach that is simpler
and easier to deploy than Service Function Chaining and is more applicable
to single function insertion or very short chains.
* The initial design target is DC/Enterprises where the requirements are
typically for insertion of a limited set of VNF¹s in specific network
locations to act on specific applications.
* Minimal changes to existing VNF, ours and others,
* Make the solution open to all VNF¹s.
* Leverage bump in the wire connectivity as this does not require L2 or L3
knowledge/configuration in the VNF.
* Firewalls want to inspect/classify all traffic on a link, so
pre-classifing traffic beyond ACL¹s is not necessary.
* Deploy on standard infrastructure; Openstack and Open vSwitch with
minimal changes
* Work with virtualization and containers and physical devices seamlessly.
* Insert and remove security is seconds, one of the drivers of the
requirement for speed is container deployment
* Simple to deploy and easy to debug is important - atomic insertion and
removal of VNF is an important aspect of this.


Approach
‹‹‹‹‹‹‹‹

We have developed a prototype, roughly using the ovn4nfv model proposed by
Vikram Dham and others in OPNFV.  The implemented prototype of ovn4nfv is
on OpenVSwitch 2.5 and Openstack Mitaka (development branch). I would like
to stress this is a prototype and not production code. My objective was to
prove to myself (and others) that the concept would work and then ask for
feedback from the community on level of interest and how best to design a
production implementation.

I have called this effort service function insertion (SFI) to
differentiate from service function chaining (SFC). This approach is
simpler than SFC and requires minimal or no changes to existing VNF¹s that
act as a bump in the wire, but it will probably not handle long complex
chains or graphs. It can possibly handle chaining one or two VNF¹s in a
static manner, but not sure if it could go beyond that. I am open to
suggestions of how to extend/improve it.

The traffic steering is implemented by inserting 2 ingress and 2 egress
rules in the ovn-nb pipeline at ingress stage 3. These rules have a higher
priority than the default rules. The changes to OVN and rules are listed
in the implementation section.

The control plane is implemented in both Open vSwitch and in Openstack. In
Openstack there is a set of extension interfaces added to the
networking-ovn plugin. There are both CLI and REST API¹s provided for
Openstack and CLI for Open vSwitch.

The OVN model enables logical changes to the flow rules and Openstack
neutron plugin model allows separation of changes to extensions to the
networking-OVN plugin. I have however violated a few boundaries for
expediency that would need to be fixed before
this could be easily deployed.

We are happy to contribute the code back to the community, but would like
to gauge the level on interest and solicit feedback on the approach. We
are open to any and all suggestions for improvements in both
implementation and approach.

Below I have given a rough overview of the implementation and the changes
I have made to the various code bases. Just to re-iterate this was done as
a quick prototype and was a learning experience in Openstack and Open
vSwitch on the way so the quality
of the code and architecture are not production ready. Links are provide
to my github repositories with the changes.

Implementation
‹‹‹‹‹‹‹‹‹‹‹‹‹‹

The approach atomically inserts rules into ovn-nb to intercept any traffic
going to or coming from a vm or a container, requires insertion of four
new rules. There are no other changes in Open vSwitch. While the prototype
is using a firewall as the VNF there is no requirement for that to be the
case any VNF that supports ³bump in the wire mode² should work.

App-1 is the application that needs to be protected
FW-2 is the input port of the firewall
FW-1 is the egress port of the firewall
App-2 is an application talking to App-1

The rules look like this:

Ingress Rules [App-1]

* If dst-ip = app-1 and src-mac = fw-2-mac then dst = app-1 [Priority 250]
* If dst-ip = app-1 then dst = fw-2                         [Priority 200]

Egress Rules [App-1]

* If src-ip = app-1  and src-mac = app-1 then dst = fw-1    [Priority 250]
* If src-ip = app-1 and src-mac = fw-1 then dst= app-2      [Priority 200]


This enables the deployment of a zero trust model of security for any
application. We would envision that the deployment of an application would
be "wrapped" with security to ensure that security is consistently and
always deployed.

Open vSwitch Changes
‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹


In OVN the interface looks like:

$ ovn-nbctl lservice-add LSWITCH, LAPP-PORT, LSERVICE-PORT-IN,
LSERVICE-PORT-OUT [NAME]
$ ovn-nbctl lservice-list LSWITCH
$ ovn-nbctl lservice-del NAME

The prototype is tailored to inserting a Next Generation Firewall (such as
Palo Alto¹s implementation). However I have made no changes to our
Firewall to support ovn4nfv. The solution will work with any ³bump in the
wire² VNF. The prototype assumes that the
VNF has two data plane interfaces but the solution would work with a
single interface, if the ³add² operation only has one interface the rules
would be changed slightly internally to support an VNF with a single port.

The only changes I have made to OVN are as follows:


* ovn-nb.ovsschema: Added a new table to support lservice
* ovn-nb.xml: To document the schema
* ovn-nbctl.c: Added CLI commands for lservice
* ovn-northd.c: Added new rules into stage 3 of ingress pipeline with
higher priority than existing rules.

Personal github repo: https://github.com/doonhammer/ovs<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_doonhammer_ovs&d=BQMGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=kQigDYSmS0qPsRGWS-ZCVOvl2wUCAKmgBVI0i6IZbQg&s=Zy_RDBkxZg4kfsHgOeIvUFWcUHb2rpdLhETLAt94AM8&e=>

I have done simple testing and can insert a firewall dynamically in front
of any application with no changes to application or infrastructure. This
enables the deployment of a L7 zero-trust security model with minimal
effort.

Openstack Changes
‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹

In Openstack the interface looks like:

$ sfi-add LSWITCH, LAPP-PORT, LSERVICE-PORT-IN, LSERVICE-PORT-OUT [NAME]
$ sfi-list LSWITCH
$ sfi-del NAME

In Openstack I have had to make slightly more changes, but this is
probably due to my lack of familiarity with Openstack. I did try and
follow the neutron plugin/extension model, but with more on making it work
rather than pure modularity. The following are
the areas where I modified Openstack:

* networking-ovn: Added the extensions to support service function
insertion as an extension to the networking-ovn plugin.
Personal github repo: https://github.com/doonhammer/networking-ovn<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_doonhammer_networking-2Dovn&d=BQMGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=kQigDYSmS0qPsRGWS-ZCVOvl2wUCAKmgBVI0i6IZbQg&s=xfR1LmO5rjuRefmsXs4TMWA4D9EG9HPx5CiqVyVj8So&e=>

* python-neutronclient: Added the cli and REST interfaces to support
service function insertion.
Personal github repo: https://github.com/doonhammer/python-neutronclient<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_doonhammer_python-2Dneutronclient&d=BQMGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=kQigDYSmS0qPsRGWS-ZCVOvl2wUCAKmgBVI0i6IZbQg&s=tMYOalJ2aJbjn696fMOYWIiL3efmldMpwqvfYB0p2-g&e=>

* neutron: Added new db table to support service function insertion
Personal github repo: https://github.com/doonhammer/neutron<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_doonhammer_neutron&d=BQMGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=kQigDYSmS0qPsRGWS-ZCVOvl2wUCAKmgBVI0i6IZbQg&s=cgJaPbnhFjYW16IV2Vp0Zoo0CkXJ0lGo5o9DHn0PQKU&e=>

* neutron and nova: Added changes to enable creation of L2 only ports
Personal github repo: https://github.com/doonhammer/nova<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_doonhammer_nova&d=BQMGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=kQigDYSmS0qPsRGWS-ZCVOvl2wUCAKmgBVI0i6IZbQg&s=3jPYkkmcP9fQP6VFunBP3rVVzt64fVtGtgqbGNMmgJM&e=>

Known Issues
‹‹‹‹‹‹‹‹‹‹‹‹

1. To make the prototype work I had to manipulate the src and dst mac
addresses in the actions, if I could filter by switch ports this would not
be necessary.
2. Need to add the VNF mac addresses to application ports for port
security - if 1 could be fixed this would not be necessary.
3. Have not tested scale and performance so impact of adding new rules has
not been determined.


[Palo Alto Networks Ignite 2016]<https://urldefense.proofpoint.com/v2/url?u=http-3A__go.paloaltonetworks.com_ignitereg&d=BQMGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=kQigDYSmS0qPsRGWS-ZCVOvl2wUCAKmgBVI0i6IZbQg&s=zrRMW45VDmQFJVqDKXebodenYItCLBBPKA3yTO9mgN0&e=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160322/5a729154/attachment.html>