What are the New Considerations for Securing a Software Defined Network?
If cloud was the buzz word of 2010, the new buzz word for 2013 is software-defined networking (SDN). The number of SDN startups have exploded, funded by venture capitalists looking for the next Nicira and a hefty payout (Nicira was acquired by VMware for $1.26B). Established infrastructure vendors like Cisco, Juniper and Arista have all implemented a variety of OpenFlow controller and OpenStack plugins within their switches. IBM has also announced an initiative called OpenDaylight featuring a consortium of companies to develop an open source, enterprise-grade OpenFlow controller.
Many enterprises have bought into the promise of SDN. In fact, various surveys by different organizations (Tail-F Survey, Information Week) show that enterprises are sure that they want it and believe in the value, but they don’t really understand what it is or what they need to purchase. There also continues to be tremendous confusion about the definition of SDN (and corresponding protocols like OpenFlow and VXLAN).
The good news is we are making progress. At the Open Networking Summit in April 2013, there was finally a general consensus on the SDN definition– a technology that separates the control plane from the data plane. But many have appropriately extended the definition to include additional characteristics or components of an SDN network:
– Separation of control and data plane
– Global network view and intelligence and dynamic configuration of flows via a centralized controller
– Programmable applications (API’s)
– Orchestration
Of course, this definition is still fairly vague.
In addition, there is further debate on how network virtualization fits in the SDN architecture. When looking at one of the use cases of SDN — building private clouds — one of the challenges for the network infrastructure is the limitation of VLANs (4,096). Network virtualization therefore is important to enable the mobility and adjacency of virtual servers in the network, regardless of their physical location, and beyond this physical VLAN limitation. Technologies like Virtual Extensible LAN (VXLAN) and Network Virtualization Generic Routing and Encapsulation (NVGRE) are encapsulation and tunneling mechanisms intended to virtualize networks and scale VLANs, although opponents complain these merely deliver address hiding but do not offer true network virtualization.
Benefits of an SDN Network
Why are the characteristics of an SDN network important? The separation of the control and data plane means that the controller now has the ability to manage traffic flows through a variety of paths in the network without being limited by physical devices and their proprietary software implementations. The network flows are typically (but not always) controlled using the OpenFlow protocol. Alternatives to the OpenFlow protocol include the Extensible Messaging and Presence Protocol (XMPP) and the Network Configuration Protocol (Netconf). In combination with the controllers, orchestration vendors can tie all the SDN component workflows together. Yet again, there are multiple vendor options available such as OpenStack®, CloudStack, vCloud Director and MS systems center. The challenge here will be deciding to go the route of collaborative, open source options where documentation may be lacking or to more proprietary offerings from vendors.
The additional benefits of the SDN network are around programmability via open API’s. The programmability provided within an SDN network enables the controller to define the behavior and performance of the network based on the applications that are running. This means that in real time, if a particular part of the network is congested, the application flows can be programmed to use a different path to optimize performance. The programmability aspect of SDN also extends to the easy automation of configuration and policy management tasks, and allows the network to quickly and dynamically react to business needs. This is ideal for enterprise private clouds and large provider networks that need to reroute traffic on demand or would like to customize a particular network flow for an application.
Security for the SDN Network
This all sounds great in theory, but where does security for the SDN network fit? As we define what may arguably be the “next big thing” for networking, did we leave network security as an afterthought? What are the new considerations for security in an SDN network?
• Programmability – One of the key benefits of the SDN architecture is in its programmability. Similarly, these are the same characteristics that need to be considered for security in an SDN network. Today, security policies are defined for security zones that are static and are tied to physical interfaces. As we move towards a more dynamic SDN network, the security zones become decoupled from the physical plane and in fact, network or host “objects” will be programmatically defined. Flows will need to be dynamically programmed so that appropriate security appliances are in the data path.
• Dynamic policies – Security policies correspondingly become more dynamic, where specific rules are applied based on applications, users, content, devices and network characteristics. Traditional security policies based on IP addresses have already evolved to rich next-generation firewall policies with application, user, and content. Now, on top of this, add another consideration around dynamic context. In an SDN network, traffic and flows can show up on any interface and more data will be needed to express security policies without just relying on traditional network contexts like location or 802.1q tags.
• Automation – Automation will become a foundational requirement for network security. The ability to implement network security policies in an automated manner instead of having to initiate manual changes per device will be critical. This means network security appliances will need robust APIs that enable automated security controls triggered by the controller. Separation of security and network duties will continue to be important in an SDN network. Security policies will continue to be independently pre-defined by security IT administrators, but networking and server operations teams will continue to manage SDN controller and application flows. In other words, the goal with SDN will be seamless insertion of security without delegation of policy creation.
• Tunneled traffic – A key component of the SDN architecture will include network virtualization to run virtual networks over existing physical infrastructures. Network security appliances will need to address this encapsulated traffic. For example, in order to properly inspect this traffic, network security solutions will need to support the ability to decapsulate the traffic, or depend on gateways and switches to translate SDN encapsulation and decapsulation protocols to VLANs for context.
As is typical of an early adopter technology, SDN deployments will be riddled with initial growing pains, including standards and interoperability pain points. Which protocols are ideal, and which switches will interoperate with what controllers? While the specific interoperability aspects of SDN are being worked out, look for network security solution vendors that already exhibit dynamic, programmable characteristics as defined above to ensure appropriate investment protection for your next-generation network.