Anatomy of Software Defined Networks

Disclaimer
I submit this research paper as part of my Bachelor of IT Network security degree in 2016 and I haven’t re-visited the topic since. I am not an expert in SDN technologies, and SDN wasn’t a strong focus in the course for me. I’ve only skimmed through it since submitting it and I’m sure there are inaccuracies and out-right lies. For your own good, do not reproduce or cite this aricle. Do check out the references though, they’re probably fine. If you wish, you can email me about any  horrific misinformation and I’ll make an update. Maybe.

Anatomy of Software Defined Networks

The glimpse of SDN

Software Defined Networking (SDN) is an emerging paradigm in the computer networking field. The roots of Software Defined Networking roots can be traced back to various projects in the early 2000’s, however it’s only been in the last few years that SDN’s full potential and necessity has been realised, and that fully operational Software Defined Networks have been deployed.
The simplest way to explain of what a Software Defined Network is to someone who is already familiar with traditional networks, is that in SDN’s, the control plane has been decoupled from the data plane in network devices. In today’s networks, network devices, such as a routers and switches have three separate parts of their architecture that they use to handle and forward traffic; the data plane, forwarding plane, and the management plane.

The data plane is the part of the architecture that must decide what to do with packets that arrive on an interface, and the control plane is the part of the architecture that is mainly concerned with producing the network topology, so that the data plane can make the best decisions on handling each packet. The management plane consists of the interface in which a network engineer can manipulate the control plane.

Because each device has its own control plane stored locally, it must either be told explicitly about the network topology by a network engineer, or learn about the network topology from neighbouring devices (usually it’s a combination of both). Because of this, each device can and often will have a different view of the network topology. This can cause complications in the data plane for each device as if there are any misconfigurations or connection issues between devices, a control plane on a device might know the complete network topology – resulting in mishandling of network packets. In addition, if any changes are made to the network topology, or if additional protocols need to be introduced to the control pane, a network engineer may have to reconfigure every single device in the network.

In Software Defined Networks, each router or switch (referred to as a Forwarding Device) now works using only the data plane, making decisions on how to handle each packed based on a single SDN Controller – also called a Network Operating System (NOS). An SDN Controller is a essentially a server acting as a single control plane, with each Forwarding Device receiving instructions on how to handle packets. This results in every Forwarding Device gaining access to a centralised network topology. This removes such traditional networking obstacles as convergence times between networking devices when a link is unavailable; as the SDN Controller already has a complete view of the network, it may already have predetermined instructions on how to handle network traffic in various situations that can take effect instantly.

Network applications can be programmed and developed to sit on top of your NOS, similar to how applications are written to be installed on a personal computer. These network focused applications may serve many purposes such as being firewalls or management applications.
Software Defined Networking has seen the necessity for a vendor independent communications protocol to allow SDN controllers to determine the path of network packets across a switched network. The OpenFlow protocol was developed by the Open Networking Foundation to accommodate this need. In addition, OpenFlow allows network devices from different vendors to be managed remotely using a single, open protocol. It works by utilising flow tables on each of the forwarding devices. Flow tables are manipulated by the SDN controller, and the switch is able to move packets at wire speed – making this method faster than traditional IP based routing.

As time goes on, traditional networking infrastructure is becoming more expensive. Higher port densities and faster port speeds, combined with the fact that each networking device typically requires sophisticated licensed operating systems to manage the control plane is causing this. An SDN approach to network design may be attractive for network designers as instead of multiple sophisticated devices, a network may only require a single sophisticated and expensive device, and multiple ‘dumb’ forwarding devices. Combined with the potential for ease of scalability and flexibility, it is certain that Software Defined Network’s will become preferred in large networks in the very near future.

One of the most prominent examples of a Software Defined Network in operation, is Google’s global data centre network, built entirely on SDN technology which they developed themselves. Moving to a Software Defined Network became a necessity for Google’s as the company’s non-stop expansion and exponential bandwidth requirements moved them outside the capabilities of traditional networks. Since Google’s SDN deployment, other companies such as Microsoft and Amazon have begun to delve into the Software Defined Network field.

SDN in Different Environments – Data Centers

In data centers, virtualization has revolutionized the way new servers can be automatically provisioned using flexibility and scalability. Network technology, up until now, has failed to keep up, and it is now the outdated, underlying network infrastructure that serves as the bottleneck in many data centers. Technology professionals now believe that the way forward in moving data centers into a more reliable state is to move to a fully Software Defined Data Center (SDDC) – a concept where every aspect of the IT environment is brought into parity through virtualization. A Software Defined Data Center is enabled by using SDN technologies.

In April of 2012, Google shocked the technology world when it announced at the Open Network Summit that it had successfully deployed its own Software Defined Network, and that it was running their internal WAN backbone used to interconnect their data centers on this SDN. More impressive, was that Google had built its own forwarding devices and SDN controllers from the ground up, and was using these devices to house their new network. At the time, no one else was utilising a live Software Defined Network at anywhere near the capacity Google was.

By moving to a Software Defined Network approach, Google was able to separate the hardware from the software (the data plane from the control plane) – effectively driving down costs of hardware as they only needed to build switches with the bare minimum physical specifications, and driving down the costs of software as they were able to choose software based on the minimum protocol requirements. The technology Google used with approach was OpenFlow. Each port on these switches supports speed of up to 10GE. On the back of this technology, Google has moved 100% of its production data-center-to-data-center traffic over to this Software Defined Network.

As the control plane is now centralized, convergence times have dramatically decreased in the event of a link failure – as the network has been programmed in a way that optimal paths are known ahead of time rather than traditional routing protocols being asked to calculate the optimal path only after a link has been interrupted – which as well as taking up valuable time, can also commonly lead to the less ideal path being chosen.

Since its implementation, Google’s Software Defined Network has seen higher network utilization (up to 100%), it is meeting the company’s SLA’s, and they are seeing a high degree of stability with minimal outages.

While companies like Google and Microsoft may seem more like futuristic entities with unlimited capital and resources at their disposal than they do your average company, they’re not the only companies who are moving to SDN technologies.

Phenix Energy Group Inc, a company that designs, builds and operates oil pipelines, began researching the idea of virtualizing its companies network when they witnessed a client lose money on a traditional network upgrade. The issue came to be as while in the middle of implementation, Cisco phased out production and support of the network switches being used, leaving them with a dead product. Phenix Energy Group set a goal to discover a solution where they could purchase inexpensive network switches from multiple vendors, and run them in unison using a single software layer.

At the same time, Phenix Energy Group were also investigating a separate issue – how to analyze increasingly vast amounts of critical network data. At first it seemed they were going to be forced to spend anywhere from 10 to 20 million dollars on sophisticated SPAN and tape devices, however they soon were put in touch with Arista Networks.

Arista Networks divulged to Phenix Energy Group that they had been developing in the Software Defined Networking field for the past few years. Phenix Energy Group realized that SDN was what they had been looking for, and that moving to SDN technologies would both meet their goal of running generic switches with a centralized software layer, and also meet their desire to monitor network traffic without investing in specialized hardware just to do that particular job.

Arista Networks were able to deliver this service using their own Extensible Operating System (EOS), which is the same Network Operating System that Google, Microsoft and Amazon are using to run their Software Defined Networks.

SDN Security Concerns

Networks are susceptible to vulnerabilities – and SDN’s are no exception. In fact, you could argue that security is even more important for Software Defined Networks, as if someone was able to access your SDN controller, they will be able to manipulate your traffic flow in any way they please. Due to the SDN controller being the single point of control, it also becomes the single point of failure and, potentially, the single point of attack – so, the most prominently talked about advantage of SDN, the centralized control plane, is also the biggest disadvantage from a security standpoint. Traditional networks don’t allow for the complete control of the behavior of an entire network from a centralized controller.

Skeptics of Software Defined Networks often identify security as their biggest concern. Such concerns are valid. As SDN has only recently moved from development to deployment, the technology has not matured to a point where all potential security vulnerabilities have been identified, addressed, or even though of.

Other security concerns stem from the ability for applications to be installed onto an SDN controller’s northbound interface. As these applications can reprogram the network, it would be possible for a hacker to trick network engineers into installing a malicious application. It’s also possible for a poorly coded application to unintentionally disrupt networks or open them up to vulnerabilities. Additionally, multiple OpenFlow applications running in unison may conflict with each other, causing undefined and undesirable network behavior.

Traditionally, network engineers can be quite lax when it comes to rolling up security patches on existing infrastructure, however this behavior must change in an SDN environment as there is more now brand new immature hardware and software in the mix. To tighten security, end devices, SDN controllers and every SDN application running on the controllers must be diligently updated – a habit network security engineers will need to adopt.

Several security vulnerabilities in different SDN technologies, such as OpenDaylight and ONOS (Open Source Network Operating System) have been identified by security professionals. Each of these vulnerabilities serve as a demonstration of the attacking surface of SDN, as well as being examples of some of the attacks that may be carried out.

One of the first security The XML eXternal Entity (XXE) vulnerability in OpenDalyight netconf. Netconf provides a way for network configuration changes to be made using XML. A flaw was discovered where user-supplied XML documents could be parsed to netconf interfaces. An attacker could use this flaw to obtain network configuration details from an OpenDaylight SDN controller, including plaintext credentials.

Another vulnerability that was discovered was a DoS flaw in ONOS. This vulnerability is made possible due to the way that OpenFlow handles packets. When OpenFlow encounters a packet that does not fit into any of the defined forwarding rules, it passes this packet to the SDN controller for instruction. At the time this vulnerability was discovered, ONOS had a flaw, where, upon receiving any malformed, truncated, or maliciously crafted packets, would throw an exception. These exceptions were not handled correctly by the controller, resulting in the switch that forwarded the packet to the controller to be disconnected due to an exception occurring in an I/O thread. This vulnerability is an example of how the data plane of an SDN, although being decoupled, can exploit a vulnerability in the control plane.

Another flaw that has been reported, has been defined as ‘topology spoofing via host tracking’. A lot of SDN controllers include a feature called host tracking, allowing physical or virtual hosts to migrate to different physical locations in the network. This functionality does not require any validation, authorization or authentication – meaning an attacker could exploit this feature to spoof a host, causing the SDN controller to route packets meant for a particular host, to a host controlled by an attacker.

While the above vulnerabilities are new in the terms that they’re being applied in an SDN scenario, the underlying ideas are very similar to attacks seen on traditional networking infrastructure. For example, XXE is a common issue that has affected several Java-based applications. DoS attacks are also nothing new, and the topology snooping flaw is very similar to MAC address spoofing. Because of this, network security personnel may take a similar approach and use the same countermeasures when securing SDN based networks.

There are, however, some new challenges that SDN network engineers will face due to the nature of how Software Defined Networks work. For example, the automated creation of a large number of virtual network segments could then see each of these have different security needs. Ultimately, network engineers will need to implement rigorous security testing and quality control methods to address potential security vulnerabilities when making changes to the network.

Another consideration, is that that with SDN, changes you make on the control plane can be reapplied throughout the entire network, meaning a misconfiguration now effects an entire network. This is contrasted with traditional network topologies, where a configuration error would only effect one part of a network topology.

Indeed, it’s likely that once the technology is more matured, Software Defined Networking users will demand clear policies and best practices, and it is only a matter of time before these policies and practices are defined.

Due to the multilayered concept of SDN, security also needs to be implemented appropriately at each of the layers.

In the data plane layer, TLS should be used to authenticate and encrypt traffic between end points and SDN controllers to avoid eavesdropping and unauthorized southbound connections. SSH should be used over Telnet, and any other proprietary protocol methods should be used to encrypt data between network hosts and controllers.

As most SDN controller operating systems will be running on Linux distributions, all the same security practices that one would apply to internet facing Linux servers should apply here, with additional monitoring for suspicious activity in place for good measure. Configuration for secure, authenticated access should be applied, and a method in place to track login activity and audit trails should also be available.

A High-Availability (HA) approach to designing the network would mitigate downtime in the event that an SDN controller was taken down due to power failure or DoS attacks. This could include deploying redundant SDN controllers, redundant links and UPS devices.
In a data center, an Out-of-Band (OOB) network would be the most secure way to connect the northbound and southbound communications. Secure coding practices for northbound applications that require SDN resources should be used, in the same way that secure coding practices harden web applications.

It’s too early to speculate how attackers may try to breach Software Defined Networks, as the technology, deployments and protocols are new. There are currently no data to analyze on real world SDN attacks. A network security professional must look at each of the SDN layers, think like an attacker, and harden each portion of the network appropriately.

Security should be integral to part of the network design at the early stages. This will assist in deciding what hardware to use, which protocols to use, which applications to use, and which NOS to run it all on. Implementing security after the network has been deployed, could result in many service-affecting issues.

While there is certainly a degree of security risks with Software Defined Networks, many of these vulnerabilities already exist in traditional networks, and many security professionals agree that in the long run, SDN will actually has the potential to provide even better security measures through SDN security applications applied to northbound interfaces.

References