Russell, you had some thoughts about SFC in OVN. I had the impression that the approach you had in mind was more powerful than what John is suggesting here, yet still not very complicated. I think you said that you weren't going forward with it for now because other things were higher priority. Do you have any comments for John?
On Mon, Mar 21, 2016 at 09:16:18PM +0000, John McDowall wrote: > 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 > > 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 > > * python-neutronclient: Added the cli and REST interfaces to support > service function insertion. > Personal github repo: https://github.com/doonhammer/python-neutronclient > > * neutron: Added new db table to support service function insertion > Personal github repo: https://github.com/doonhammer/neutron > > * neutron and nova: Added changes to enable creation of L2 only ports > Personal github repo: https://github.com/doonhammer/nova > > 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]<http://go.paloaltonetworks.com/ignitereg> > _______________________________________________ > discuss mailing list > discuss@openvswitch.org > http://openvswitch.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
