SDN switches can behave like a firewall, but they may not be a replacement for the real thing
Many people anticipated that enterprise organizations would adopt Software Defined Network (SDN) technologies later than service providers or multi-tenant data centers and cloud service providers. We are now seeing more use of Network Functions Virtualization (NFV) within enterprises and some enterprises are starting SDN pilot projects. As enterprises consider how to utilize SDN technologies in their data center environments, they start to consider what new security capabilities SDN can provide. SDN switches can drop packets for flows that are not permitted by the controller. This article explores if SDN switches can behave like a traditional firewall.
Software Defined Networking evolved from the concept of decoupling the lower-layer packet/frame forwarding from the control function that intelligently determines how application traffic should be transported. The separation of the control plane from the forwarding plane allows networks to facilitate packet processing in new and innovative ways and created a new paradigm for network virtualization. SDN has opened up a whole new world of network design and enabled creative approaches to networking. SDN has also caused us to reconsider how security policies are enforced within the network.
In the OpenFlow SDN model, the flows within a network switch are placed there by an OpenFlow controller. If a flow is not present (table-miss), then the switch punts to the controller to ask for help determining how the packet should be forwarded. The OpenFlow technical specifications state that if the table-miss flow entry is not present in the switch and there is no rule to send the packet to the controller, then the packet is dropped by the switch. If the switch punts the packet to the controller, then the controller processes the Packet-in message and determines the fate of that packet. The controller then determines if the packet should be forwarded or dropped. This behavior sounds like the SDN switch is behaving like a firewall and enforcing the “that which is not included in the flow table, is dropped” standard security policy. This can be thought of as similar to the default “Fail-Safe Stance” that was also mentioned in the book Building Internet Firewalls, by Elizabeth D. Zwicky, Simon Cooper and D. Brent Chapman. On first blush, this sounds like a great new form of security and makes it seem like every port of an SDN switch can behave like a firewall.
Many SDN switches behave much like a standard Ethernet switch and flood traffic out all ports for Ethernet frames destined to broadcast, multicast or unknown MAC addresses. Most SDN switches flood normal ARP traffic like a typical hardware-based Ethernet switch. In most situations, the default behavior for an SDN switch is to act like an Ethernet bridge, or learning switch. However, it is possible to put an SDN switch into an explicit forwarding mode whereby only flows allowed or configured/pushed by the controller are allowed.
If every Ethernet switch in the environment could perform like a traditional firewall, it would change the way security policy is implemented in a networked environment. Imagine if every Ethernet switch were a multi-port firewall, then firewall policies could be implemented throughout the network at every ingress switch port and on every link between switches. There would be firewalls for every server, desktop, every link, and the firewall policy would be implemented by a controller that maintained a global view of the current application traffic and what traffic should be permitted. Having security policy enforced throughout the environment would mean the complete erosion of the security perimeter. Having that many security policies implemented and maintained manually would be an administrative nightmare. However, with a controller architecture, the policy would be created once and then pushed down to every network device for enforcement.
Network slicing is one of the popular use cases of SDN. A network can be logically carved up into logically separated networks overlaid upon the same physical network hardware. Network slicing is a popular use case within universities because they would like to separate different departments (admissions, finance, residence halls, computer science departments, etc.) into their own logical network enclaves. The SDN can separate the networks similar to Virtual Routing and Forwarding (VRF) instances may be used to separate layer-3 forwarding. This can also be done by adding a slicing layer between the control plane and the data plane, thus making the security policies slice-specific. Enforcement of strong isolation between slices in “Flowspace” means that actions in one slice do not affect another slice. For more information look at Flowvisor and the FSFW: Flowspace firewall. An example of this would be the Cisco Extensible Network Controller (XNC) with the Networking Slicing application. In these ways, SDNs can provide the “Diversity of Defense” concept which was also mentioned in Building Internet Firewalls.
The key concept to the feasibility of using an SDN-enabled switch as a firewall is the state that it would maintain of the application traffic flows. Access Control Lists (ACLs) are not stateful and do not have awareness of when the connection started or ended. Even with the good-old Cisco ACL CLI parameter “established”, the ACLs became only slightly “statefulish”. ACLs typically do not pay any attention to the three-way TCP handshake (SYN, SYN-ACK, ACK) or the FIN/ACK session teardown. Stateful firewalls, on the other hand, observe the session establishment and close process and apply their policies directionally using Stateful Inspection.
So, how do modern SDN products implement security and could they behave like a traditional firewall? When it comes to Cisco’s Application Centric Infrastructure (ACI), the Nexus 9000 switches operate in a stateless manner. The Application Network Profiles (ANPs) configured in the Application Policy Infrastructure Controller (APIC) are deployed to the switches in the ACI fabric in a stateless fashion. Therefore, an ACI system would not be able to operate with the same level of security as a standard stateful firewall. This is why ACI allows for Layer-4-to-7 Service Graphs to be configured and integrated into the ACI fabric.
When it comes to Open vSwitch (OVS), it has supported only stateless matches on policies. It is possible to configure OVS policies that match TCP flags or configure rules to use a “learn” method to establish the return flow of traffic. However, neither of these methods are stateful like a traditional stateful inspection firewall. There is work being done by the Open vSwitch community to have connection tracking (Conntrack) to allow the OVS to notify a Netfilter (think iptables) connection tracker and maintain a state table of existing sessions.
Project Floodlight can configure ACLs, however, these also operate like a stateless firewall. Floodlight has a Firewall application module that enforces ACL rules by inspecting Packet-In behavior. This works in a reactive way, with the first packet helping to instantiate the flow and traffic is allowed or denied based on the priority-sorted policy rule-set. Rules are allows to have overlapping flowspace but the priority creates the first-match rule action top-down policy.
VMware NSX has the ability to configure security policies within the SDN environment. NSX for vSphere supports logical switching/routing, firewall, load balancing, and VPN functionality. The firewall rules are enforced at the vNIC, but the firewall policy is associated with the VM and when the host moves, so does the policy. The NSX Distributed Firewall is a kernel loadable module and provides stateful L2/L3/L4 dual-protocol firewalling and can do anti-spoofing. The VMware NSX firewall polices operate like a Cisco router with a reflexive ACL. When it comes to Equal Cost Multi-Path (ECMP) designs or High-Availability (HA), the NSX Edge Services Gateway firewall functions in a stateless manner. In other words, stateful firewalling and load balancing or NAT are not supported by the Edge Services Gateway with an HA or ECMP topology.
There are groups who are working to try to create SDN systems that provide robust security policy enforcement. Research projects like FlowGuard and a paper titled “An OpenFlow-Based Prototype of SDN-Oriented Stateful Hardware Firewalls” written by Jacob Collings at the University of North Dakota show that there may be potential to establish statefullness within the SDN network devices.
From this analysis, we can conclude that SDN switches that obtain their forwarding policies from a controller are not necessarily stateful. These SDN-enabled switches are, therefore, unable to provide the same level of protection as a stateful firewall. It is important to ask the vendor about the details of the statefulness of their firewall capabilities in their SDN solutions and understand how they operate. Because many of these SDN systems may operate in a stateless way, if your organization requires stateful firewall protections, then you must use the SDN policies to steer the traffic with service-chaining toward a stateful packet inspection Network Functions Virtualization (NFV) firewall.
Best Microsoft MCTS Certification, Microsoft MCITP Training at certkingdom.com