Introduction

Currently, the IT industry is undergoing a major change from self-hosted services like ERP systems, databases, web applications, and many more to cloud-based services like SaaS (Software-as-a-Service) or PaaS (Platform-as-a-Service). With this change, the need for SDN networks is greater than ever before because the currently used systems like VPNs are not capable of the performance an SDN or a local network has. Therefore, the SDNs must be secure and reliable especially to comply with European GDPR policy.

SDN Architecture

SDN is based on the concept of network function abstraction. It divides the whole network into three plane that specialized on their function and therefore have a performance advantage over combined systems like the traditional LAN infrastructure. Because of the concept change additional communication interfaces had to be implemented which came in the form of APIs. These API represent the control and monitoring function of the abstracted plane. Most of the APIs are standardized through the OpenFlow standard, but a few providers also use their proprietary protocols like Huawei and Aruba. Communication through this API is secured via SSL/TLS encryption, but the standard configuration is without any encryption which can lead to a MITM-Attack that changes configurations and sends devices rogue.

Management and Orchestration Plane

There are two variants of this plane, since some providers are combining the orchestration and management functions, but others don’t. This paper will focus on the combined version of this plan. The management consists of multiple configuration steps that can include policy-based routings, bonding, performance dashboards and reliability indicators. The main focus of the management plane is to provide centralized management for all devices and functions in the SDN network. This is achieved through high-level abstraction of policy enforcement, configuration management, troubleshooting, monitoring, analytics, predictions, reporting, and service-related functions such as creating and managing services. On the other hand, the orchestration plane is responsible for configuring network devices for the first time and keeping track of the configuration version that is currently running on them. Additionally, it also takes care of the information distribution through the whole SDN network.

Control Plane

The control plane is the heart of the SDN network since it’s in the middle and connects the management plane to the data plane. It houses the SDN controller which can be a single installation or a cluster of controllers to expand the controlling capabilities. The clustered controllers communicate between them with an API since one of the controllers could run ONOS as controller software and the other one OpenDayLight. This control plane can also span multiple datacenters since interconnection between them is necessary for cloud service providers. Important features that are provided by the control plane are topology and network management optimizing structure/topology, device discovery together with the orchestration plane and path computation which are one of the most important steps. There are many controllers’ software on the market and a few of them are: Beacon, Floodlight, POX, ONOS, OpenDayLight. These differ from each other only through the installation environment and clustering capabilities, everything else is specified by the OpenFlow standard.

Data Plane

Routers, Switches and Gateways are part of the data plane. These network devices consist of two parts: the control plane and the data plane. The control plane is responsible for the maintaining and building of the routings tables as well as the forwarding rules. On the other hand, the data plane forwards and routes the packets based on the before received configuration. It is checking the input interfaces, routing tables, forwarding rules as well as egress interfaces. SDN devices in the data plane are designed to use an application interface like any other part of the SDN network. These application interfaces are to ensure interoperability and configuration via the control plane. There are several protocols that can be used through this interface such as OpenFlow which is most popular. The are two different types of OpenFlow switches:

OpenFlow Only

These switches can only be used in datacenters with an SDN architecture. Most of these are very powerful since they are capable of up to 70Tb/s switching on a single chip. These switches also have a network operating system running like ONOS or SONIC.

OpenFlow enabled

This means switches are capable of providing an OpenFlow interface to the control plane but can also undertake standard switching roles. These are switches in the lower performance sector since they are more common in access or simple server networks.

API

Since SDN is decentralized and every plane has their own purpose, APIs are the most important connection between those. There are multiple API standards that can be used but this paper is focused on OpenFlow. Another important detail is the differences between the APIs since there is the Northbound API, Southbound API and the East-Westbound API.

Northbound API

The Northbound API provides communication between the control plane and the management plane. This API is a key element since it is used by the network administrator to exchange data between the control plane and management plane to define policies and schedule those to the control plane. It also represents the network abstraction and controller functionality which then can be used by network applications. There are a variety of Northbound API types which are grouped into three main groups: REST, specialized ad hoc APIs and programming languages like Frenetic, Procera, FML (Flow-Based Management Language), NetCore and Pyretic. Most common solution is a REST (Representational State Transfer) based API since it is used by companies like Google, Microsoft, and Meta. There are controller solutions that fully support these REST API like ONOS or OpenDaylight, but many other controllers are using SOAP as an additional legacy interface.

Southbound API

This interface connects the control plane with the data plane and is responsible for establishing connection between controllers and SDN network devices. This API can use a proprietary protocol or open-source protocol like the industry wide standard OpenFlow protocol. It is possible for the controller to manage and control the flow through the devices in the data plane. There are also other protocols like SNMP, NETCONF (Network Configuration Protocol), LSIP (Location Identifier Separation Protocol) or even the border gateway protocol. Additionally, there are specific protocols like the OVSB (Open vSwitch Database Management Protocol), OpFlex and ForCES (Forwarding and Control Element Separation).

East-West API

This API is responsible for allowing the controllers a common view over the network and coordinating with each other the implementations of policies and protocols. Through this interface controllers share data and transfer status data about routing and forwarding decisions as well as routing directions. Another important part of this interface is the improvement of communication across different domains of an SDN network (intra-domain and inter-domain) as well as improving scalability and interoperability. Functionalities of this API contains: provide monitoring and notification capabilities, provide algorithm for data consistency models and import or export data between controllers. Protocols in use for this interface are ALTO, SDNi and HyperFlow.

Vulnerabilities

Since SDN is like any other protocol/software it has vulnerabilities that can be exploited by attackers. Especially the API interfaces and the communication between the layers is very vulnerable against DDOS and flood attacks. The follow topics describe attacks based on different layers in the SDN stack.

Attack on the Data Plane

At this layer the attacks can target devices directly through physical or virtual unauthorized access. If an SDN device at this layer is compromised through leaked or unsecured access it can threaten other devices in the same layer since there is no separation. Most of these attacks are described as DOS or fuzzing attacks. As mentioned before there a several Southbound API protocols which all implement security differently. Since SDN technology is mostly used in datacenters to provide connection between multiple datacenters using datacenter interconnects (DCI). This technology is based on various protocols like VXLAN, NVGRE and STT. All these protocols are vulnerable through their design or how the provider implemented them. If an attacker gains access to these devices, there is a high possibility that this attacker will abuse these protocols to impersonate a device and get access to the control layer.

Attack on the Control Plane

Considering the role of the control layer it is very tempting to attackers to target and gain access to this layer. If an attacker gains access to one controller, he can instantly change flows, create new flows, dump data and routing tables, control devices via the Southbound API, redirect traffic to his own network and collect data from the management plane which applications are used how there are secured and forwarded. Additionally, the attacker can use some controller-based services to bring down the whole network regardless of redundant controllers.

Attack on the Management Plane

There are multiple different applications that are used by the SDN controllers depending on their purpose. All these applications have their own API implementation of the Northbound API, these also all have their own security vulnerabilities which leads to increased risk. The following table shows each layer and their corresponding security vulnerabilities.

Attack Vectors

Threat Vector 1

Forged or faked traffic is when an attacker tries to send fake traffic directly to network devices located in the data plane. This traffic can be sent from any device on the data plane as well as workstations, PCs or laptops. The attack only has to saturate the Southbound API of the network device to start a DDOS attack. To mitigate those issues an intrusion detections system can be implemented to identify anomalies and fake traffic. Also rate limiting is a very strong mechanism to contain the attack.

Threat Vector 2

One of the most basic attacks is to gain direct access to a switch regardless physical or virtual. With this access network packets can be discarded, data traffic can be redirected (data theft), or fraudulent requests can be injected to overwhelm and slow down nearby switches. Secure the switches physically and virtually, especially with management mechanisms that are implemented into the software. Another important security addition is the use trust systems with certificates and signed memory/access.

Threat Vector 3

These communications channels from data to control plane are very likely to get attacked. Standard SDN architecture uses SSL/TLS for the communication, but these protocols are not sufficient since man-in-the-middle attacks can be performed. If the attacker has taken over the control plane, he can control all switches in the same domain and thus carry out a DDOS attack. These issues can be solved by a common trust-anchor certification authority in best case one for each domain. Additionally, threshold cryptography can be used to change the keys every X hours.

Threat Vector 4

Attacks on the SDN controllers are the most severe attacks. If a controller fails, it may lead to a complete network compromise. Solutions for these outage scenarios are controller backup and replication, enough restore resource capacities, access, and restriction policies to prevent manipulated network rules.

Threat Vector 5

Another threat vector on the SDN controller side is the lack of mechanisms for trust and guarantee between the controllers. There is a significant difference between verifying applications and verifying communication between control and application plane. Since there is no mechanism to guarantee a trusted connection between application and controller, an independent lifecycle mechanism should be in place to guarantee reliability throughout the complete lifecycle.

Threat Vector 6

This threat vector focuses on the attack of the administration console which is very high risk since from this station the whole SDN network can be reprogrammed. Mechanism against this include antivirus protection, multifactor authentication at the workstation and in best case no internet connection. Additional there should be a double credential verification process implemented which means to change anything on the management server the clearance of two people is needed.

Threat Vector 7

The last threat vector is not having enough or reliable resources to investigate activities and start remediation. For a successful investigation it is essential that trustworthy information from all elements and resources of a network is provided. This information contains all traffic and changes, as well as all access log and performance monitoring. For remediation it is crucial that snapshots from before the issue are taken to restore the network back to a working state.

Denial of Service Attacks

DoS has been growing in recent years and has become more and more a threat and a challenge to IT security. Most of the time targeted at banks. companies, government agencies or hospitals. The most widespread DoS attack is the Distributed Denial of Service attack. These attack types consist of a master server also called bot master and several infected systems also called zombies. These systems then create a huge amount of network traffic towards a specific organization to slow down their IT systems until they halt. There are multiple advantages of DDoS for the attackers:

Combined attacks

When a DDoS attack is initiated all zombies, each of them with different source IP addresses, generate their own traffic and flood the target. This accumulated traffic is considered as the threat, but blocking is not simple because of the individual IP addresses.

Simplify of hiding

Another advantage is that the real attacker can hide within all these zombie systems and the generated network traffic. It seems that this is nearly normal behavior of multiple users attempting to access a targeted system.

Multiple sources

As mentioned before, it is really difficult to get to the source since so many different IP addresses are attempting to access a targeted system.

With SDN there is a new possibility to detect DDoS attacks more efficiently and faster since it combines multiple aspects which isn’t possible when looking at traditional infrastructure. If a cloud provider uses SDN they can block traffic at the source where it enters their network and not only on the outlet or target systems. There are multiple types of DDoS attacks which consist of the following.

Volumetric Attacks

It is the most common form of DDoS attack, and because of how quickly its application is expanding, researchers and network security administrators are paying close attention to it. This attack is initiated by flooding the targeted system with an enormous amount of worthless, simple information packets. The target system must process this massive amount of data while also utilizing all available bandwidth between the victim’s system and the Internet to create congestion. Massive amounts of data are sent to a target using amplification forms or other methods of generating massive traffic, like requests from a botnet. DNS Amplification is a well-known example of a volumetric assault. In this kind of attack, the attacker sends a request to the DNS server using a faked IP address. The victim then receives a ton of responses from the server that it did not request, causing the system to crash.

Protocol Attacks

The vulnerabilities present in Layers 3 and 4 of the OSI model are utilized in this kind of attack to take advantage of a victim who is not reachable. Services may be interrupted by excessive use of the target’s resources or network components like load balancers and firewalls. SYN Flood is one of the most common varieties of this form of attack.

TCP-SYN Flood

TCP is a connection-oriented protocol, network connectivity must be established before delivering the data flow between the source and the destination. As a result, the attacker can take advantage of the TCP protocol’s weaknesses. Under the TCP communication protocol, the server is required to reply to each, and every SYN request it receives, regardless of the validity of the sender. The server has to hold onto the requests it has received in memory and wait for the recipient to confirm before creating a connection. By using the TCP communication protocol, an attacker can send a large number of SYN requests to the server with no intention of establishing a genuine connection (they typically use non-existent IPs for connections).

UDP Flood

With this technique, the attacker sends UDP packets to several ports on the targeted server using a number of clients. The server will reply to the requester with an ICMP response containing the relevant message that the destination is not reachable if the requested port is not in use by any services or if it is unable to resolve the request. This kind of request, which is sent to the passive ports by a collection of zombie machines that are infected, consumes up bandwidth on the network connection.

ICMP Flood

Certain network troubleshooting tools employ the ICMP protocol to help identify network connection issues. The ICMP protocol messages are used by the network tools to confirm the presence of network connection problems. As a result, the switch processes ICMP messages first and constantly while simultaneously giving internal messages processing precedence. This capability provides the attacker with the ability to create a high-traffic ICMP flood attack. Because this activity utilizes up all of the available bandwidth, it results in a denial of service. There are various kinds of the ICMP flooding assault, including SMURF and Ping of Death. Using ICMP broadcast messages, the SMURF attack creates a flooding attack that compels many hosts to respond. A denial-of-service attack takes place if the broadcast message is sent quickly and continuously because the target host will be overloaded with traffic. Request/reply and echo ICMP messages are used in the Ping of Death attack. A denial-of-service attack occurs when the attacker floods the target system with packets that have huge extensions (more than 64Kb). This prevents the target system from processing the packets.