A new approach for detecting violation of data plane integrity in Software Defined Networks

Abstract

The scale of Software Defined Networks (SDN) is expanding rapidly and the demands for security reinforcement are increasing. SDN creates new targets for potential security threats such as the SDN controller and networking devices in the data plane. Violation of data plane integrity might lead to abnormal behaviors of the overall network. In this paper, we propose a new security approach for OpenFlow-based SDN in order to detect violation of switches flow tables integrity and successfully locate the compromised switches online. We cover all aspects of integrity violation including flow rule adding, modifying and removing by an unauthorized entity. We achieve this by using the cookie field in the OpenFlow protocol to put in a suitable digest (hash) value for each flow entry. Moreover, we optimize our method performance by calculating a global digest value for the entire switch’s flow table that decides whether a switch is suspected of being compromised. Our method is also able to determine and handle false alarms that affect the coherence of a corresponding table digest. The implementation is a reactive java module integrated with the Floodlight controller. In addition, we introduce a performance evaluation for three different SDN topologies.

Keywords

Compromised switches data plane security floodlight controller SDN security Software Defined Networks (SDN)

1. Introduction

Software Defined Networking is considered a new paradigm in the field of computer networks and has become a hot research topic in academic society. SDN brings up the idea of centralized management by taking off the controlling ability from networking devices to a high-performance computer called the controller. Therefore, the network elements have turned into forwarding devices (OpenFlow Switches) obeying the commands sent by the controller. These commands are translated into rules called flow entries that reside in flow tables in an OpenFlow switch. OpenFlow protocol is responsible for communication between the controller and the switches to determine the network behavior through the exchange of various types of messages aimed to achieve a specific mission. SDN is generally divided into three main layers: Application layer, control plane and data plane. In the control plane, the entire network is managed by applications running upon the controller machine through the use of Northbound API. Then, the instructions will be turned into suitable OpenFlow messages and therefore sent to data plane through Southbound API. Building reactive applications will provide a dynamic and event-driven network acting interactively according to live changes.

However, despite all of SDN’s benefits, it suffers from many security issues because the programmability of the network leads to the occurrence of new kinds of attacks. Therefore, there is a need to propose security solutions that improve this promising technology architecture and protect its components. Lots of recent efforts [8,12,13,15] have presented SDN security challenges and vulnerability analyses with various attack scenarios. Consequently, the door has been opened for the presentation of convincing solutions that address security flaws of SDN.

According to [1,9,16,22], the SDN attack vectors have been classified into three categories:

Control plane specific: Includes all attack cases against SDN controller and application layer.

Control channel specific: Includes attack scenarios targeting the communication channel between the controller and OpenFlow switch.

Data plane specific: Comprises attack cases targeting network devices supporting SDN functions.

This classification helps to determine the target of an attack hence we could predict possible vulnerabilities in a particular component of SDN architecture. Network functionality is susceptible to be maliciously impacted through being manipulated, poisoned or abused by attackers. Hence network security is very important for a successful deployment of network technology.

The OpenFlow switches in data plane are vulnerable to various threats due to the lack of security mechanisms in the specification of all versions of OpenFlow protocol supported by Open Networking Foundation (ONF) [14]. The attacker could establish a logical or physical unauthorized access into a switch in many ways [20]. Moreover, the significant channel between the controller and switches is exposed to be hijacked by a Man-in-the-middle attack [3,21]. Data confidentiality and mutual authentication could be achieved through SSL/TLS between OpenFlow controllers and OpenFlow switches. However, SSL/TLS cannot be used to detect compromised switches. An attacker can get all secrets of a compromised switch and pass the authentication process [5]. Regardless of the attack’s logic, it may attempt to violate the device’s flow table integrity by adding, modifying or deleting one or more flow entries.

In this paper, we propose a new security solution for SDN to detect violation of data plane integrity and determine the compromised switches. Our approach is based on building a reactive application over an Open Floodlight controller in a pure SDN environment with a data plane that contains Open vSwitches (OVS). The application periodically monitors the condition of flow tables inside each OVS in the administrative area of the controller to raise alarms when unauthorized modifications are revealed. We took advantage of the flow entry’s cookie field to put in the value of the Massage Digest calculated by an expandable output hash function. This value helped us to decide whether a flow entry has been injected, manipulated or even forcibly deleted. In addition, we calculated a global Digest of the entire flow table for two reasons: To firstly determine whether a switch is suspected of being compromised. Secondly, to optimize our analysis algorithm which checks the integrity of each entry one by one.

2. Motivation and problem statement

According to the concept of SDN, the controller must be informed when an event appears in the network, especially which comes from switches indicating the changes in their status. This task relies on OpenFlow protocol through asynchronous sending of messages, initiated by a switch, to the controller. Regarding the flow table changes, OpenFlow v1.0, v1.2, v1.3 and v1.4 have only one type of notification, called Flow-Removed, which informs the controller about the removal of a flow entry from a flow table. Nevertheless, adding or modifying entries, will not trigger any notification event, so the controller could not detect any possible violation of a switch’s flow table. Unfortunately, OpenFlow-based switches (e.g., OVS) are not equipped with any integrity validation technique of Flow-Mod messages that could add, delete or modify flow entries. In this case, the main question will be “Is Flow-Mod legal or poisoned by a malicious third party?”.

A new monitoring mechanism has been presented in OpenFlow v1.5 [14] called Flow monitors, which keeps track of flow table changes. This enables the controller to be aware of changes made to the flow tables by other controllers. A controller can create a number of flow monitors; each flow monitor matches a subset of flow entries in some flow tables. Thus, events will be generated for any flow table’s changes that match one of the monitors. On the other hand, flow monitoring is an optional feature and might not be supported by all OpenFlow switches. Besides, the number of flow monitors that can be created on a switch may also be limited.

According to the OpenFlow standard, the cookie field of a flow entry, which is assigned by the controller, is an opaque data value not used when processing packets. This value may be used by the controller to filter flow entries affected by flow statistics, flow modification and flow deletion. Modify and Delete commands in Flow-Mod messages can be filtered by cookie value when the cookie_mask field contains a value other than 0. This constraint is that the bits specified by the cookie_mask in both the cookie field of the flow mod and a flow entry’s cookie value must be equal. In other words, (flow entry.cookie & flow mod.cookie_mask) == (flow mod.cookie & flow mod.cookie_mask). Hence, we conclude that the cookie field’s value could be used for meaningful purposes such as integrity assessment as our approach proposes. The normal use of the cookie field as provided by OpenFlow protocol does not change because the filtering process depends on the cookie mask rather than the cookie value. Consequently, incompatibilities with other SDN applications will be avoided.

3. Related work

Several research works have adopted the security of SDN’s data plane due to the importance of this layer. In [20], the authors focus on identifying challenges faced in securing the data plane of SDN. They have presented a survey of available solutions and their limitations as well as future research recommendations.

A detection method in [5] has been proposed to find compromised switches in a data plane by analyzing the behavior of these switches. This method depends on how a switch handles incoming packets that contravene the controller rules before deciding that the switch is compromised. The design is composed of two algorithms for detection: Forwarding Detection and Weighting Detection which has been implemented in Ryu controller. We agree with this method on the definition of compromised switches in SDN and propose a practical solution to detect them. But, randomly selecting a set of flow rules from random switches will reduce the chance of detection, i.e., the choice may fall on normal/legal flow rules in a compromised switch. In our work, the detection method considerably includes all switches with its flow rules, hence all cases of flow table manipulation have been addressed.

VeriFlow [11] acts as a middleware between the controller and data plane that allows pre-checking the Flow-Mod messages before reaching the network. These messages may cause violation changes of network invariant, break access control policies or even create forwarding loops. This work adopts the approach of data plane verification which resembles what we plan to do but the algorithm has been implemented as a shim layer between the controller and the network. From our point of view, such a solution does not follow the general logic of SDN and its architecture because planting a middle layer will modify the basic design of SDN. Furthermore, this layer will add extra security requirements due to its sensitive role in the network so that it will be as important as the controller itself.

An SDN security extension that has been presented in [18] called SDNsec, ensures consistent network behavior in data plane. An attack termed as Path deviation has been mentioned which indicates that a switch may forward packets over an authorized path. SDNsec is based on a reactive security method that checks whether an intended path has been followed or not. We share this methodology in addressing the problem occurred when one or more switches being compromised and where forwarding policies can be violated without getting caught by other switches or by the controller. In order to implement SDNsec on a software switch, the code of the switch had to be modified. Consequently, in a real SDN network, dedicated switches should be used rather than standard or commercial ones. Whereas, our solution is able to work in real networks without the need to modify the programming logic of OpenFlow-based switches.

A practical security solution is presented in [4] for determining the location of malicious switches that do not follow the installed flow rules by the controller. Attackers may inject a switch with falsified flow entries to violate the network logic. Three complementary techniques for data plane security are presented which are active probing, statistics checking and packet obfuscation. The method depends on generating test packets in switches to traverse all flow rules on controlled switches in the network, verifying if the rules are consistent with the controller’s knowledge. The controller maintains a rule graph representing the relationships between flow entries. The number of auxiliary rules increases with the number of adjacent switches, and thus adding counter rules may become a performance bottleneck and exhaust TCAM memory on switches. In contrast, our algorithm reactively communicates with the data plane, so there is no need to proactively install extra flow rules into a switch nor to generate test packets which avoids the previous situation.

The approach presented in [7] detects diverse attacks on data plane; it uses multiple observations based on Hidden Markov Model (HMM) to quantify the network status. It addresses scanning attack, ARP attack and switch compromised attack. It mainly consists of three parts: controller and switch information collector, attack features extractor and situation assessor. Many entities such as packets, traffic flows, and events are recorded in controllers and switches, making it possible to collect the information of the network situation through programming. This approach considers a switch as possibly compromised when its flow table has frequently been modified, whereas our method can certainly detect the first occurrence of a flow table integrity violation.

The authors in [6] have designed a security method to detect compromised switches that disobey forwarding rules. They have offered enhancements in detection efficiency and reduced additional traffic on the network. Their scheme verifies whether the matched flow entries on the switches work as expected or not. The main idea of the detection method is to assemble detection packets and send them into the network. Each goes through the switches in an aggregation tree, and should be sent back to the controller from expected switches finally if nothing goes wrong. On the other hand, our method does not require adding temporary entries into switches and sending additional detection packets which may cause flow rule flooding at one or more switches. Moreover, their approach can only detect forwarding loops in the topology as one of the consequences of switch flow table manipulation.

SDN-RDCD [23] is a suggested real-time method aiming to discover malicious switches in data plane by assuming that both the controller and the switch are not trusted. Some controllers are added as backups to audit network events that are collected by the primary controller. The detection method relies on recognizing unexpected behaviors among the three entities: backup controllers, primary controller and data plane’s switches. The auditor controller is responsible for collecting information about network update events from the master controller and the switch, respectively. The switch-side audit information needs to be delivered from switches to auditor controllers by utilizing and adjusting Flow_Removed message mechanism. We agree with this method that relying on the Flow_Removed messages is not enough, therefore any state update that happens in a switch needs to be captured. The implementation of SDN-RDCD requires adding extra functionalities into the switch’s program in order to enable the capture and the collection of relevant state update information. On the other hand, the implementation of our approach resides on the controller-side and doesn’t modify the code of a switch program, in addition to the complete dependency on standard functions provided by OpenFlow protocol.

A methodology proposed in [10] called FlowMon aimed to detect compromised switches through the analysis of reports collected in real-time. It investigates two kinds of abnormal behaviors expected from malicious switches which are packet swapping and packet dropping. Two anomaly detection algorithms have been presented that depend on data gathering, analysis and decision assistance in terms of reducing the effects of malicious behaviors.The selection of significant algorithm parameters leads to the trade-off between the sensitivity of the mechanism and the corresponding false alarm rate (some packets may be dropped due to transmission errors, for instance). According to FlowMon method, the detection rate is 77% in all considered cases of packet swapper, which suggests that some malicious switches remained undetected. Hence, this solution confines to specific abnormal behaviors expected from compromised switches while our approach generally covers all cases of switch’s flow table violation regardless of any possible malicious behavior that might occur accordingly.

4. Background

4.1. OpenFlow protocol

The arrival of OpenFlow is the point at which SDN was actually born and considered as the most widely adopted implementation of SDN. Its specification delineates the protocol used between the controller and the switch as well as the behavior expected of the switch. Figure 1 illustrates the simple architecture of an OpenFlow-based network. We could summarize the basic operation of this protocol as the following [14]:

The controller installs flow entries into a switch’s flow table on demand of a specific application.

When the switch receives a packet by one of its physical ports, it will try to find a matching flow with the packet’s header then performs the associated action.

In the case of reactive applications, when no match is found then the switch forwards the packet (Packet_In message) to the controller for instructions on how to deal with such packet.

In the case of proactive applications, when no match is found, the switch will drop the corresponding packet.

In general, each flow entry contains the following main components [14]:

Fig. 1.

The basic design of OpenFlow.

Match: consists of certain fields to match against packets (ingress port and packet headers).

Priority: matching precedence of the flow entry.

Counters: updated when packets are matched.

Instructions: a set of actions applied in case of matching.

Timeouts: indicates the expiry date of corresponding entry into the switch.

Cookie: opaque data value chosen by the controller. A flow table entry is identified by its match fields and priority thus they must not be duplicated.

4.2. Floodlight controller

Open Floodlight is an Apache-licensed, Java-based OpenFlow controller, supported by large development community and considered as the core of a commercial controller product from the Big Switch Networks [17]. It attains a set of common functions to control and inquire an OpenFlow network. Meanwhile, applications provided by Floodlight fulfill valuable features to meet different user needs over the network. Many packages implement components such as the web graphical user interface, the device manager, link discovery and learning switch.

4.3. Attacks on data plane

Since the data plane reflects the network behavior, it should be more secure. When a switch is compromised, two possible attacks might be launched which are passive and active attacks. Passive attacks run sniffers and collect information for further analysis without affecting the network. It is hard to detect this sort of attack because the switch will meanwhile act normally. In contrast, active attacks compel the switch to work abnormally unlike the way it has been programmed by the controller. Clearly, the detection methods rest on the controller and should react duly. We have listed and described some remarkable attacks in Table 1 that violate the integrity of data plane caused by compromised switches.

Table 1
Attacks against the integrity of SDN’s data plane

Attack Definition

Switch firmware abuse [20,22] An attacker may hijack the channel between the controller and switches to install numerous flow entries on the target switch. This will lead to filling up the flow table of the victim switch. Another case of this attack is when the attacker installs flow entries with a match containing fields of Data Link layer. As a result, this will cause additional processing load on the switch’s CPU.

Flow-rule enforcement [2,19] An attacker could install certain flow entries on target switches to change the network behavior. For example, creating loops in a data plane or changing routing paths.

Flow-rule flooding [19,22] A special case of Switch firmware abuse since the attacker’s goal is to fill up the flow table of the victim switch.

Flow-rule modification [19,22] This attack intends to either modify or delete some flow entries in the target switch causing abnormal network behavior.

Flow table flushing [22] An attacker may send malformed OpenFlow messages that erase the whole content of a switch’s flow table.

Attack	Definition
Switch firmware abuse [20,22]	An attacker may hijack the channel between the controller and switches to install numerous flow entries on the target switch. This will lead to filling up the flow table of the victim switch. Another case of this attack is when the attacker installs flow entries with a match containing fields of Data Link layer. As a result, this will cause additional processing load on the switch’s CPU.
Flow-rule enforcement [2,19]	An attacker could install certain flow entries on target switches to change the network behavior. For example, creating loops in a data plane or changing routing paths.
Flow-rule flooding [19,22]	A special case of Switch firmware abuse since the attacker’s goal is to fill up the flow table of the victim switch.
Flow-rule modification [19,22]	This attack intends to either modify or delete some flow entries in the target switch causing abnormal network behavior.
Flow table flushing [22]	An attacker may send malformed OpenFlow messages that erase the whole content of a switch’s flow table.

5. The proposed approach

We introduce a new security solution for SDN, based on a prototype implementation to be integrated with the Floodlight OpenFlow controller. The aim of our approach is to maintain the integrity of a data plane that includes OpenFlow-based switches. Our method detects three integrity violations of a switch’s flow table: adding, modifying or deleting flow entries maliciously. As we had mentioned before, OpenFlow switch does not notify the controller when an entry is added or modified. Consequently, we periodically collect flow tables from the switches, which are analyzed in order to verify whether corresponding changes are legal or not. It is worth mentioning that there is no presumption that a switch has to be trusted by the controller, i.e., we have not required implementing SSL/TLS between control plane and data plane. Even if SSL/TLS is used to provide authentication, an attacker could illegally access a trusted switch, and then manipulate its flow table without getting caught. The task of the proposed model is to detect the situation of an authentic switch getting compromised. Since the proposed method is a Java module that runs on the controller machine as a security service, it will be ineffective if the controller is compromised. To conclude, detecting compromised controllers is out of the scope of this paper and could hopefully be covered in further studies. The implementation of the proposed solution consists of five main components: Flow entry digest, Message listener, Monitor thread, Tables digest and Integrity checker. The general design of the approach with the type of data passing between the components and the interaction with data plane is illustrated in Fig. 2.

Fig. 2.

The proposed basic design.

5.1. Flow entry digest

On the controller-side, when an SDN application decides to add/modify a flow entry in a switch, by Flow-Mod message, it has to calculate the hash value (Message Digest) for this entry. This value will be attached to the entry into the cookie field. In OpenFlow protocol, the cookie field length is 64 bits, hence if we use fixed-length hash functions like MD5 or SHA, the value will be truncated. To avoid truncation, we prefer using SHAKE256, an expandable output function, from the SHA-3 1

¹
SHA-3 is the latest member of the Secure Hash Algorithm family of standards, released by NIST on August 5, 2015.

family to produce suitable hash values with 64 bit length. The input of the digest function for a given entry is a concatenated string composed of the following fields:

Switch DataPath ID: Identification of the switch in data plane where the entry is installed.

Priority

Match

Instructions (List of actions)

Controller’s private key

When an attacker discovers the used hash function and input fields, then he could calculate a legal cookie value for a malformed entry. To prevent this situation, we have used unique information that no one owns it except the controller. By choosing to put controller’s private key into consideration, the attacker will not be able to produce a legitimate cookie. It should be noted that, the controller is assumed trusted and its private key is securely stored in JVM (Java Virtual Machine) KeyStore, on the local machine, and protected by a password. The compromised switches are not able to respond with an authentic flow table to the controller because they do not have the private key of the controller which is needed to calculate legal digest value for a flow entry. As a result, our method guarantees that a flow entry would not be considered genuine unless it had been legally generated by the controller.

5.2. Message listener

This component is considered as the main reactive module of the proposed SDN application that is to be loaded and run by Floodlight. It keeps listening to particular types of OpenFlow messages which affects the integrity of switches in data plane. The Flow-Mod messages, sent from the controller to a particular switch, will either add a new entry to a switch, delete or modify an existing one according to its flow_mod_command field. This module maintains a list of legal cookies produced by the controller via the Flow entry digest component. A cookie value will be added to the list when flow_mod_command is ADD or will be deleted when the command is DELETE. Whereas in case the command is MODIFY, the existing cookie in the list will be replaced by the updated one. The event of receiving Flow-Removed messages by our module indicates that an entry has been removed from a switch. As a result, the table digest value of the corresponding switch must be updated by the Tables digest component through analyzing Flow-Mod and Flow-Removed messages.

5.3. Tables digest

We have assigned a global digest value to each switch’s flow table in a data plane that is subject to change according to any modification made by the controller. The values list of all switches flow table digest is stored locally in the controller machine. If we calculate a table digest by passing all entries contents to the hash function, it would have taken a long time. Instead, we have optimized the algorithm by selecting only one field from each entry which is the cookie. To calculate a table digest, if we use the sum of all cookies it may lead to an overflow situation in case the number of entries is big enough. Thus, we have chosen XOR bitwise operation that has commutative property and produces fixed length output (64 bits in our case). In general, a table digest represents the XOR of all table’s entries cookies that will be updated according to the following cases:

Adding a flow entry: Since the cookie value of the added flow entry (new cookie) was not included in the calculation of table digest, so it will be included as follows: $\begin{matrix} new table digest = new cookie \oplus old table digest . \end{matrix}$

Modifying an existed flow entry: When the controller sends a flow modification message to a switch, then the new digest (new cookie) will be calculated. Since the existing flow entry will be replaced by a new one, therefore its digest value (existing cookie) must be subtracted from the calculation of table digest as follows: $\begin{matrix} new table digest = new cookie \oplus (old table digest \oplus existing cookie) . \end{matrix}$

A flow entry has been removed from a switch: We propose additional analysis to the Message listener component in terms of determining whether the flow entry has legally been deleted or not. As we had mentioned before, the Message listener keeps a list of legal cookies produced by authorized SDN applications running on top of the controller. When our module receives a Flow-Removed event from a switch, it will check if the value of a field called flow_removed_reason equals “2”; which indicates that the corresponding flow entry has been evicted by a DELETE flow mod message. If the cookie value of this flow entry is found within the list of legal cookies, then the entry was maliciously deleted beyond the knowledge of the controller, thus the switch will be considered compromised. Otherwise, the switch will be considered normal because if the cookie corresponding to the entry is not found in the list then it has already been deleted by the controller through an authorized Flow-Mod. Hence, when a flow entry has been normally evicted by authorized Flow-Mod message or other reasons (flow_removed_reason doesn’t equal “2”) such as an entry’s lifetime has exceeded its timeout, then it will be removed from the legal cookies list and the table digest of the corresponding switch will be updated as follows: $\begin{matrix} new table digest = old table digest \oplus removed flow’s cookie . \end{matrix}$

Previous cases maintain the consistency of tables’ digest values which are associated with each switch in data plane.

5.4. Monitor thread

This task periodically collects the flow tables of all switches in the network by sending FlowStatsRequest messages. Every switch responds accordingly with a FlowStatsReply message containing a list of switch’s flow entries. These messages, provided by the OpenFlow API in Floodlight, are turned into Multipart OpenFlow messages. Request or reply is encoded as a sequence of multipart messages with a specific multipart type and re-assembled by the receiver. Multipart messages are primarily used to request statistics or state information from a switch. When a FlowStatsReply message is received by Monitor thread, a new thread of Integrity checker will be created for the switch in order to verify the integrity of its flow table.

5.5. Integrity checker

This thread accepts a list of flow entries of the corresponding switch from the previous component. Afterward, a current table digest will be calculated for the switch by performing XOR operation on all its entries cookies and then comparing it with the stored table digest. If both current and stored table digest are equal then there is no integrity violation of the corresponding switch. We have optimized the algorithm of this component through the previously mentioned comparison, i.e., no further analysis is needed when the current table digest is equal to the last stored digest. However, when these two values are not equal for a switch, then its flow entries would go through the analyzing phase.

During the analyzing phase, each entry’s digest is being calculated by the Flow entry digest component. If the calculated value is equal to the entry’s attached cookie, then there is no violation; otherwise, an alarm will be raised indicating that integrity violation is detected. Once an analyzing phase is done and no violation is revealed, this means it is a false alarm. The false alarm, which is false positive, occurs in case of Flow-Mod message failure sent from the controller to a switch, for instance: when a switch rejects adding flow operation because it has already reached the maximum number of flow entries. Eventually, the value of flow table digest is recalculated in order to keep its coherence and reserve the detection method stability.

To conclude, the proposed security solution has achieved a detection accuracy of 100% by handling all possible network events that affect the integrity of data plane. The Tables digest component successfully determines whether a switch is suspected as being compromised, through the corresponding global digest value that has been assigned to the switch. The previously mentioned false positive alarm is a special case of the incoherent value of a switch’s digest value which indicates that the concerned switch is suspected and might be compromised. Consequently, the Integrity checker component will make the final detection decision by checking the integrity of all flow entries (one by one) for the suspected switch. A switch will be considered compromised when at least one true violation is detected in its flow table. Factually, none of false negative alarms has occurred in our solution regarding its accurate detection method. We recommend isolating compromised switches by logically disconnecting them from the controller to keep the SDN network working normally.

6. Evaluation

The components of our approach are implemented as native Java using OpenFlow APIs provided by Floodlight. The experimental networks are pure SDN built with Mininet which is a network emulator, or perhaps more precisely a network emulation orchestration system. Mininet runs a collection of end-hosts, OpenFlow switches and links on a single Linux kernel. Floodlight, OVSs and end-hosts behave just like real machines that run on a single Ubuntu machine equipped with Intel Core2 Duo 2.20 GHz CPU and 4GB memory. The empirical environment is composed of the following software packages:

Floodlight SDN controller version 1.2 is compatible with Java OpenJDK-8 and supports different versions of OpenFlow including OFv1.2, OFv1.3 and OFv1.4.

Eclipse IDE (neon_4.6) to set up, develop and run Floodlight.

Open vSwitch (OVS) as a multilayer software switch licensed under the open source Apache 2 license.

The trials include three topologies (illustrated in Fig. 3) with one controller and a variable number of switches, so that we can observe the execution time of Monitor thread and Integrity checker on the controller-side. We have configured these network topologies to experiment and investigate the performance of the proposed method on diverse scale networks represented by topo1 as a small network, topo2 as medium and topo3 as large. We have enabled a service built in Floodlight called Learning Switch that constructs the switches flow table to provide network connectivity over the Data Link layer. The count of flow entries in each switch depends on the number of switches, links and hosts in the topology. The resulting amount of flow entries within each switch is illustrated in Fig. 4 including its ID and the topology to which it belongs. As noted, topo3 has the highest amount of flow entries among other experimental topologies because it has more switches and hosts. There is no restriction on the number of SDN network applications; various modules might have been running by Floodlight as well as the Learning Switch module such as routing protocols, firewalls, and others. To clarify, before applying our proposed security solution, data plane is left vulnerable to flow table integrity violation due to the absence of standard detection mechanisms. Every switch in the network is exposed to any kind of data plane integrity attacks that cannot be detected, thus compromised switches might behave abnormally regardless of the way it had been programmed by the controller.

Fig. 3.

Experimental SDN topologies.

Fig. 4.

Count of switches flow entries in the experimental SDN topologies (sw# – a switch ID).

6.1. Monitoring execution time

The performance of Monitor thread per switch is related to many factors including the number of flow entries in the corresponding switch and the traffic load on the communication channel with the controller. The monitoring task consumes additional time when the number of the switch’s flow entries rises and the load on channel increases. It is worth noting that we have not applied extra load on the communication channel in all experiments. The execution time (in Millisecond) of Monitor thread per switch for the three experimental topologies is illustrated in Fig. 5. The results have shown low execution time for small topology represented by topo1 but relatively higher for large topology represented by topo3.

Fig. 5.

The execution time of monitor thread per switch (sw# – a switch ID).

6.2. Threat model

Every switch in data plane is susceptible to many kinds of attacks that might violate the integrity of switch’s flow table. By performing Man-in-the-middle attacks, an attacker could impersonate the controller role and send malformed Flow-Mod messages to a switch in order to add, modify or delete its flow entries. In addition, unauthorized access attacks could launch remotely or locally (insider threats) on a switch device by passing the authentication process, so that an opponent could gain control of a switch and maliciously manipulate its flow table. In the conducted experiments, we have assumed that an attacker had launched an unauthorized access attack, regardless of the attack mechanism, and maliciously manipulated the flow table by using ovs-ofctl which is a command-line tool for OpenFlow switches administration. This tool supports commands such as add-flows to add flow entries, mod-flows to modify actions in specific entries and del-flows to delete all flow entries or specific ones. We have performed the previously listed attacks in Table 1 in the conducted experiments. Switch firmware abuse, Flow-rule enforcement and Flow-rule flooding attacks have been executed by add-flows command. Whereas, Flow-rule modification has been executed by mod-flows command; Flow table flushing has been executed by del-flows. Since the common goal of these attacks is integrity violation of the flow table, our method successfully detects them because the table digest of the corresponding switch has been changed. Consequently, the Integrity checker would detect the malicious entry via its illegal cookie value therefore the switch is considered compromised. Importantly, an attacker could not create legitimate flow entries because he does not have the controller’s private key to calculate a legal cookie value. As we had mentioned in Section 5.1, even if an attacker discovers the used hash function and input fields, a legal cookie value could not be produced for a malformed flow entry.

6.3. Integrity checker execution time

During the monitoring phase, a new thread of Integrity checker is created per switch in order to verify its integrity status. We have observed the total execution time of all created threads for each topology. A topology without compromised switches will not take long execution time for the Integrity checker (10.87 ms for topo1, 15.85 ms for topo2 and 20.97 ms for topo3). If there were a compromised switch, then the corresponding thread would go through the analyzing phase which would consume extra time. We have concluded that the performance of all threads is essentially related to the number of compromised switches within a topology. As illustrated in Fig. 6, the execution time rises when the number of compromised switches increases. For instance, in presence of four compromised switches (cs=4; sw1, sw2, sw3 and sw4), the execution time will be 112.97 ms, 223.68 ms, and 387.14 ms for topo1, topo2, and topo3, respectively. In addition, the more numbers of switches flow entries, the longer the execution time.

Fig. 6.

The total execution time of all integrity checker threads in presence of variant numbers of compromised switches per topology (cs – number of compromised switches).

6.4. Average detection time

According to the proposed approach, Monitor thread runs periodically over a period of time p, subsequently Integrity checker creates and starts a new thread for each switch in the data plane. The average detection time for a switch s could be calculated according to the following Equation: $\begin{matrix} Average detection time = \frac{\sum_{j = 0}^{n} (n - j) + m_{s} + i_{s}}{n} \end{matrix}$ An attack on a switch in the data plane could take place at any moment during p; n indicates the number of timestamps in seconds within p. For instance, when p equals one minute then n will be 60. Monitor thread takes time $m_{s}$ to fetch the flow table’s entries from the switch s then Integrity checker would take time $i_{s}$ to detect the integrity violation. We have observed the average detection time of our approach for the three experimental topologies (topo1, topo2 and topo3) with n=60, and n=300 as illustrated in Fig. 7(a), Fig. 7(b), respectively. The results have shown a low average detection time for a short monitoring period while begins rising with longer periods. As noted, we have performed variable monitoring periods in the conducted experiments to demonstrate its influence on detection time. Hence, selecting a proper period of Monitor thread should take into consideration that short periods fulfill high-level security because the resulted average detection time is relatively low. Meanwhile, this leads to generate extra network traffic on the controller-side which would be discussed in the next section. So, the network administrator should make a trade-off between obtaining a low average detection time and the generated network overhead in choosing the monitoring period.

Fig. 7.

The average detection time of the proposed approach per topology.

6.5. Impact on overall system performance

We can describe our methodology as fast and lightweight because its implementation makes use of logical operators rather than complex arithmetic. The suffered effort of handling threads life cycle by JVM and operating system is the key point of producing extra load on the CPU of the overall system that is running Floodlight controller. When using Tables digest as an optimization criteria in detection algorithm, CPU utilization slightly increases as the number of switches in the network increases. Furthermore, extra load on the CPU will be seen as the number of compromised switches increases. We have observed the system’s CPU utilization ratio in the case of topo3, which contains the highest number of switches, according to two scenarios. Data plane is considered not subject to attacks in the first scenario, so that all switches in the topology are normal (not compromised). A slight increase has been observed in CPU utilization ratio while our method was running; the peak has been reached at timestamp 20 as illustrated in Fig. 8(a). In the second scenario, where all 16 switches are compromised, a noticeable increase has been observed in CPU utilization ratio while our method was running. The peak has been reached at timestamp 30 as illustrated in Fig. 8(b). It is worth mentioning that the obtained results include the impact of our method on both controller and the entire switches running in the empirical environment.

Fig. 8.

Overall system’s CPU utilization ratio using the proposed method in topo3.

During the use of Monitor Thread in our proposed solution, which collects flow tables from every switch in data plane, additional network traffic is being generated on the controller-side. In order to obtain a switch’s flow table, a Multipart_Request message had to be sent from the controller, hence specific number of Multipart_Reply messages containing all flow entries would be received accordingly. The size of the response message is proportional to the individual entry’s size and the total number of entries inside the concerned switch. According to the conducted experiments, we have evaluated the total rate of outgoing and incoming traffic generated while applying our solution; the results are listed in Table 2.

Table 2

Total rate of generated network traffic on the controller-side

Experimental topology	Outgoing traffic rate	Incoming traffic rate
topo1	1.04 KB/s	70.32 KB/s
topo2	1.42 KB/s	138.68 KB/s
topo3	1.87 KB/s	302.74 KB/s

7. Conclusion

This paper proposed a new approach to improve SDN data plane security against various attacks that target integrity. In particular, we presented an efficient detection method as a reactive module integrated with Floodlight controller. The implementation consists of five components cooperating online with each other. Our contribution lies in the use of cookie field in the standard of OpenFlow protocol to put in the digest value for the corresponding flow rule. Moreover, we optimized the detection algorithm by assigning a global digest value to a switch’s flow table. Our security solution successfully detects the following attacks: Switch firmware abuse, Flow-rule enforcement, Flow-rule flooding, Flow-rule modification and Flow table flushing. Once a switch is detected to be compromised, it would get disconnected from the controller in order to keep the overall network work safely.

8. Future scope

Further studies might enrich the proposed approach by adding more security services to the SDN data plane. There is a wide scope for enhancing the performance of each presented component. In prospective works, we intend to develop our methodology in order to support SDN topology with multiple controllers.

References

N.A.

Aziz,

Mantoro and

M.A.

Khairudin, Software Defined Networking (SDN) and its security issues, in: 2018 International Conference on Computing, Engineering, and Design (ICCED), IEEE, 2018, pp. 40–45. doi:10.1109/ICCED.2018.00018.

Benton,

L.J.

Camp and

Small, OpenFlow vulnerability assessment, in: Proceedings of the Second ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking, 2013, pp. 151–152. doi:10.1145/2491185.2491222.

Brooks and

Yang, A man-in-the-middle attack against OpenDayLight SDN controller, in: Proceedings of the 4th Annual ACM Conference on Research in Information Technology, 2015, pp. 45–49. doi:10.1145/2808062.2808073.

T.W.

Chao,

Y.M.

Ke,

B.H.

Chen,

J.L.

Chen,

C.J.

Hsieh,

S.C.

Lee and

H.C.

Hsiao, Securing data planes in software-defined networks, in: 2016 IEEE NetSoft Conference and Workshops (NetSoft), IEEE, 2016, pp. 465–470. doi:10.1109/NETSOFT.2016.7502486.

P.W.

Chi,

C.T.

Kuo,

J.W.

Guo and

C.L.

Lei, How to detect a compromised SDN switch, in: Proceedings of the 2015 1st IEEE Conference on Network Softwarization (NetSoft), IEEE, 2015, pp. 1–6.

Y.C.

Chiu and

P.C.

Lin, Rapid detection of disobedient forwarding on compromised OpenFlow switches, in: 2017 International Conference on Computing, Networking and Communications (ICNC), IEEE, 2017, pp. 672–677. doi:10.1109/ICCNC.2017.7876210.

Fan,

Xiao,

Nayak and

Tan, An improved network security situation assessment approach in software defined networks, Peer-to-Peer Networking and Applications 12(2) (2019), 295–309. doi:10.1007/s12083-017-0604-2.

Haggag, Network optimization for improved performance and speed for SDN and security analysis of SDN vulnerabilities, International Journal of Computer Networks and Communications Security 7(5) (2019), 83–90.

Jose and

Kurian, Survey on sdn security mechanisms, International Journal of Computer Applications 132(14) (2015), 0975. doi:10.5120/ijca2015907602.

10.

Kamisiński and

Fung, Flowmon: Detecting malicious switches in software-defined networks, in: Proceedings of the 2015 Workshop on Automated Decision Making for Active Cyber Defense, 2015, pp. 39–45. doi:10.1145/2809826.2809833.

11.

Khurshid,

Zou,

Zhou,

Caesar and

P.B.

Godfrey, Veriflow: Verifying network-wide invariants in real time, in: Presented as Part of the 10th USENIX Symposium on Networked Systems Design and Implementation (NSDI 13), 2013, pp. 15–27.

12.

Mubarakali and

A.S.

Alqahtani, A survey: Security threats and countermeasures in Software Defined networking, in: 2019 IEEE 2nd International Conference on Information and Computer Technologies (ICICT), 2019, pp. 180–185. doi:10.1109/INFOCT.2019.8711319.

13.

J.C.

Nikoue,

Butakov and

Malik, Security evaluation methodology for Software Defined Network solutions, in: 2019 International Conference on Platform Technology and Service (PlatCon), IEEE, 2019, pp. 1–6.

14.

Nygren,

Pfaff,

Heller,

Lantz,

Barker,

Beckmann,

Cohn,

Malek,

Talayco,

Erickson and

McDysan, Openflow switch specification version 1.5. 1, Open Networking Foundation, 2015, Tech. Rep, ONF TS-025.

15.

T.V.

Ortiz,

Kimura,

Ueyama and

Rosset, Experimental Security Analysis of Controller Software in SDNs: A Review, 2019, arXiv preprint arXiv:abc/1906.09546.

16.

Patil,

Patil and

R.N.

Awale, Security challenges in software defined network and their solutions, in: 2017 8th International Conference on Computing, Communication and Networking Technologies (ICCCNT), IEEE, 2017, pp. 1–5.

17.

Project Floodlight, https://floodlight.atlassian.net/wiki/spaces/floodlightcontroller (accessed at October 10, 2020).

18.

Sasaki,

Pappas,

Lee,

Hoefler and

Perrig, SDNsec: Forwarding accountability for the SDN data plane, in: 2016 25th International Conference on Computer Communication and Networks (ICCCN), IEEE, 2016, pp. 1–10.

19.

Scott-Hayward,

O’Callaghan and

Sezer, SDN security: A survey, in: 2013 IEEE SDN for Future Networks and Services (SDN4FNS), 2013, pp. 1–7.

20.

Shaghaghi,

M.A.

Kaafar,

Buyya and

Jha, Software-Defined Network (SDN) data plane security: Issues, solutions, and future directions, in: Handbook of Computer Networks and Cyber Security, Springer, Cham, 2020, pp. 341–387. doi:10.1007/978-3-030-22277-2_14.

21.

Shah and

Cosgrove, Mitigating ARP cache poisoning attack in Software-defined Networking (SDN): A survey, Electronics 8(10) (2019), 1095. doi:10.3390/electronics8101095.

22.

Yoon,

Lee,

Kang,

Park,

Shin,

Yegneswaran,

Porras and

Gu, Flow wars: Systemizing the attack surface and defenses in software-defined networks, IEEE/ACM Transactions on Networking 25(6) (2017), 3514–3530. doi:10.1109/TNET.2017.2748159.

23.