An Efficient Approach for Detection of Compromised SDN Switches and Restoration of Network Flow

Software Defined Networking (SDN) is now generally acknowledged by the academic and business community. SDN is being used in a growing number of real-world applications as a potential network virtualization technology. The detachment of the controller plane from data plane and the concentration of network controlling functions, which enable network programming capability, deliver rapid and flexible network administration, and encourage network innovation, are the main innovations of SDN [1]. But this new design also comes with significant security threats, some of which are never encountered in conventional networks, such as the susceptibility in SDN controllers, SDN switches, and SDN controller applications. Such a flaw is unavoidable and may be used by the attackers to seize switches and controllers.

SDN switches that might be hacked could spy on private communications, block typical management and operation, and potentially harm the infrastructure. A corrupted switch can alter its own flow entries to implement malicious actions like packet dropping or unauthorized forwarding. Additionally, it can connect to a rogue controller and send fake OpenFlow messages which is one method an attacker might influence the control flow to his or her advantage. Added assault purpose is to trick the controller into thinking there are links that aren't there by taking advantage of the topology discovery function.

Therefore, it is crucial to identify compromised SDN switches as soon as possible. Otherwise, any network traffic via these corrupted switches may lead to any type of DoS or DDoS attack which eventually hamper the whole network. Isolation of compromised SDN switches and restoration of the network traffic flow is another important concern here. Maintaining the proper path from sender to receiver is a challenging task after the isolation of the compromised SDN switches because it requires a considerable amount of resource and there might be similar type of attack in the newly created path too. Therefore, only the removal of the compromised device may not be sufficient and hence we should remove all the links attached to them to maintain the network integrity. The detection of compromised switches, isolation of them and restoration of original network flow puts a considerable amount of burden on the controller and CPU but from the security perspective it is awfully important. Therefore, in our approach we have proposed deploying another secondary or backup controller along with the primary controller to work in tandem with the primary or master controller, in which all the aforesaid functionalities will be deployed. In our study we have used OpenDaylight (ODL) [2] as the master or primary controller and ONOS [3] as the slave or secondary controller for the prototype implementation and performance evaluation of our proposed algorithms. OpenFlow networks give users a single location where they can get data about participating switches, existing pathways, and flows, as well as swiftly calculate the best restoration strategies. The Path Computing Element (PCE), a specific computing platform in the SDN controller with the capability to take into account numerous restrictions for complex route calculation, is where the new pathways or diversions are computed. The SDN controller modifies the configuration of the compromised switches by adding or deleting flow entries from/to the associated switches with the flow tables of that path.

Data plane switches do not have any intelligence; all they do is transmit data packets towards the controller and other switches. This behavior creates a significant susceptibility that an attacker may take advantage of it. Network communications might be significantly disrupted by a rogue or malfunctioning SDN switch. There are five categories that may be used to group the abnormal behavior at an SDN switch.

• •    A corrupted or compromised switch may selectively or randomly stop passing network traffic, which is known as traffic loss.

• •    It is known as traffic misrouting when the traffic of a hijacked switch is sent to the incorrect address.

• •    Traffic reshaping, which is the process of altering the sequence of packets on a hacked switch.

• •    Contents of the traffic might be modified by the compromised switch which is known as traffic alteration.

• •    Traffic via a compromised switch might be delayed and poses a fatal threat in time bound communications known as traffic delay.

In this work an approach has been proposed to first detect the compromised switches, isolate them from the network and finally restore the network flow to maintain the sustainability of the whole network. The major contributions of this work are-

• •    In order to effectively detect compromised SDN switches with little overhead, we suggest using secondary controller(s) to verify the handling data of network updation data obtained from the main controller and its switches.

• •    We propose another solution approach to effectively restore the network flow after eliminating the compromised switches along with all subsequent connections to them.

• •    We outline the suggested approach, design the appropriate algorithm for detecting compromised SDN switches, and provide a thorough introduction to the prototype implementation evaluation.

• •    To validate the suggested techniques, we show the experimental findings and compared them with the existing state of the art solutions to establish the effectiveness of our algorithms.

• •    Finally, a brief security analysis has been presented to discuss the impact of our work on security aspects.

2.    Related Works 3.    Impact of Compromised SDN Switches

Figure 1 depicts the SDN architecture with some compromised switches. It can be seen from the figure that in a typical SDN architecture SDN controller acts as a central communicator between the applications residing in the application layer and the data plane switches. Applications communicate with the controller via the northbound interface (NBI) and controller communicates with the data plane switches via the southbound interface (SBI). Therefore, applications need controller intervention to install flow rules in the data plane switches. Now as seen in the following figure, if somehow one or more switch is compromised by the attackers the whole network becomes either disconnected or unreliable. Any traffic via these switches is vulnerable and may impact the whole network tremendously. Therefore, immediate detection of this type of compromised switches is essential as well as the subsequent activity of isolation and flow reconstruction.

Fig.1. SDN Architecture with compromised switches

SDN has faced significant concerns from attacks on the data plane. Attackers can disable the control plane or observe its activities by using numerous hosts connected to OpenFlow switches without having much knowledge of the controller apps. DoS, topological poisoning, and side-channel attacks are some of these attacks [4]. SPHINX [5], one of the existing systems, has usable implementations. By abstracting network activities using incremental flow graphs, it may identify and counteract security threats started by malicious switches. Additionally, it recognizes assaults in accordance with the administrator's defined regulations and takes appropriate action. The nearest approach to SPHINX is called WedgeTail [6], and it is known as an excellent intrusion prevention solution for the data plane of SDNs. This operation is independent of rules that have already been established by an administrator, and it is capable of quickly identifying and addressing any implanted harmful forwarding devices. Two anomaly detection algorithms—Packet Droppers and Packet Swappers are proposed in another study, FlowMon [7]. The controller examines the real forwarding pathways and the port information gathered to find malicious switches. The idea was put forth by Haeberlen et al.[8] to allow each connecting node to request the security log of the other node in order to freely assess whether the behavior of the node deviates from expected behavior. The security log of each node would record the messages received and sent by the network node. A proper node is able to defend itself against malicious allegations based on the intended temper-evident record, and a malfunctioning node will be found by executing the feedback analysis procedure on it on a regular basis.

In order to ensure a seamless transition, Botelho et al. [9] suggested designing a fault resistant SDN controller plane and storing application and network states in common data storage. In order to prevent controller hijack, Qi et al. [10] suggested a control plane design to support numerous disparate controllers and carried out a theoretical examination of its efficacy without presenting the system implementation. Every request for network update is handled by several different controllers, according to this study, and the controllers will vote to select how it will be handled in the end. Al-Shaer and Al-Haj [11] suggested a technique to identify SDN switches with numerous conflicting policies. For the purpose of identifying non-bypass property violations, Son et al. [12] suggested modelling flow tables entries with the Yices SMT solver. Between the switches and their corresponding controller, Khurshid et al. [13] introduced a layer called VeriFlow to check dynamically and in real-time for any violations throughout the entire network. By utilising a collection of conceptual tools those maintain a graph of dependency among rules, Kazemian et al. [14] introduced a real-time tool for policy checking called NetPlumber based on Header Space Analysis (HSA) [15] to gradually verify the conformity of state changes.

Throughout the years, several different path calculation methods for backbone networks have been presented. Single-failure restoration methods are categorized rather thoroughly in [16], along with a comparison of their restoration timeframes. In [17] the authors provide an illustration of how to formulate a capacity maximization issue for single-failure path reconstruction. Although while few research [18,19] have taken into account numerous failure situations, but no answers are provided for the optimization problems based on multiple failures. Internal processing time is another point of consideration here which is missing in most of the literature. In case of multiple failure scenario this processing time poses significant impact on overall path restoration process [20]. Determining the shortest path is not the main issue in this situation since rerouting a failed flow via it may not be effective in terms of lowering the flow table processing time. Moreover, it is demonstrated in [21] that restoration strategies based on shortest path that disregard the processing time of the flow table may be unable to rapidly restore network flows, particularly in big networks supporting numerous network flows.

When a packet is sent from a host to its nearby SDN switch, the switches will first search for a comparable entry in the flow table based on the routing-related information included in the packet. If the particular switch is unable to locate a matched entry inside flow table, it will encapsulate the packet content as an OpenFlow [22] PACKET_IN message and send it to the controller. Following that, the controller will take the packet out of the PACKET_IN message and gather the routing information. The controller programs will handle the deployment of transmission route for any packet and thereafter appropriate instructions are provided to switches to deploy necessary data flow via the southbound interface.

The compromised SDN switches have the malicious impact on both the controller and switches, thereby eventually it will impact the whole network too. As we know that controller is the main component of the SDN architecture, any adverse effect on the controller will also affect the whole network. The major attack points of compromised switches on the controller as well as on the whole network are summarized below-

• •    A controller utilizing a compromised switch may be instructed by the attacker to deactivate its switches by erasing all the entries in its flow table.

• •    By using the compromised switches, the attacker can arbitrarily take and use the system resources that belong to authorized users.

• •    Until the attack goal is reached, the attacker may keep stealing controllers to control other switches attached to them.

• •    The attacker may alter the flow table entries and the network topology, which would affect regular network operations.

• •    The hijacking attempt might not be discovered by operators if the attacker tampers with the controller's log.

4.    Insights of SDN Controllers 5.    Proposed Solution Approach

• 5.1.    Principle of Compromised Switch Detection

In our work we have used Open Daylight (ODL) as the primary controller and ONOS as the slave or secondary controller. The main responsibility of the primary controller is to maintain the normal traffic flow in the network whereas the main responsibility of the secondary controller is to dynamically check for any compromised switch(es) and to inform about this type of event(s) to the primary controller. As per the statistics provided by the backup controller, the primary controller then logically isolates compromised switch(es). Network flow restoration is the second major responsibility of the secondary controller and after creation of the new flow path this information is transmitted to the primary controller to maintain normal network traffic flow.

ODL and ONOS have been chosen as primary and secondary controller because using distributed approaches, modern distributed controllers, such as ODL and ONOS, have enabled the synchronization of network view between primary and secondary controllers. Consequently, the current synchronization technique may be used when the primary and secondary controllers are the same type of controller. If not, one of those distributed approaches must be implemented in each of the heterogeneous primary and secondary controllers to synchronize their network and application related states.

We have bifurcated our proposed solution mechanism into two major parts- first the detection process of compromised switches is performed which triggers the next process of switch isolation and network path reconstruction. The principles of both these activities are stated below.

Based on our investigation, it is essential to gather data of each network update event and the associated master controller and switch handling data in order to detect possibly compromised SDN switches in a reliable and timely manner. This is the first step to performing. Therefore, the following data are required to be collected primarily-

• •    Each request for network update.

• •    Network update instruction received by switches from both the controllers.

• •    Execution log of that request by the switches.

• 5.2.    Principle of Switch Isolation and Network Flow Reconstruction

• 5.3.    System Model

To collect this information as a whole set, an idiosyncratic ID is assigned for each network update request. The actions performed by the primary controller are mirrored in the secondary controller. Execution log of secondary controller and switches for any particular network update request ID contains information of network state update. The similar type of information is generated from master controller but is case of any comptonization of any switch its flow table entries does not match with which is obtained from the secondary controller. Therefore, these execution results from primary and secondary controllers can be compared to find any inconsistency in the execution log of the switches. If any such inconsistency is detected, then the corresponding switch is treated as a compromised switch, and it is subject to be isolated from the network.

Once detected, compromised switches can be isolated logically by deleting their corresponding flow table entries from the primary controller. As we are maintaining similar copies of flow table entries for both the primary and secondary controller, flow table entries in the master controller get updated too. At this point the network is fully or partially unreachable due to the absence of the switches or links and therefore network reconstruction is essential at this point to maintain the normal operational flow.

To reconstruct the network flow, there are two major considerations- i.e. the link cost factor or link weightage between two switches and the flow table alteration cost (internal processing time) if any such link is inserted or removed from the existing flow table. In this study these two parameters are important because normally a network can be thought of as a connected directed graph where switches are like graph vertices and link between them are the edges. Removal or insertion of any edge means altering the existing flow table which incurs flow table alteration cost because subsequent flows must have to be altered to accommodate these changes. If there is a huge flow table modification then a considerable amount of processing power and time is wasted to perform this job, so flow table alteration cost should be minimized as far as possible. Another important concern is link weightage which might be thought as any feasible metric like distance, time etc. As we all know, that spanning tree is a tree which connects all the vertices of a graph and minimum cost spanning tree incurs minimum cost among them, MST is a good choice for network flow reconstruction. Therefore, from the set of all possible paths from source to destination, the path which will incur minimum link cost has been considered in this study assuming link cost factor as a constant, because internal processing time will pose serious time overhead on overall network and CPU performance if not tactfully managed and demands more research highlights. Detailed description of both the principles mentioned in 5.1 and 5.2 are presented in the next subsection.

According to the discussion in section 5.1 and 5.2 to detect compromised SDN switches four types of information are collected for each network update request under a single ID-

• •    The request for network update.

• •    The execution report by primary controller- E M

• •    The execution report by the secondary controller- E S

• •   The execution report by the switches- E T

Based on the above collected information, the secondary controller can take the decision whether a switch is compromised or not by comparing the execution log of both the controllers. This is informed to the master controller immediately to perform the subsequent actions of switch isolation and path reconstruction. The following might be observed by the secondary controller against each ID-

• •   E M =E S =E T which implies all the network update operations have been performed successfully without any

issue.

• •   E M ≠E S which implies execution report of master and secondary controller are not same and switch tampering

may occur.

• •   E S ≠E T which implies execution report of secondary controller and switches are not matching and that switch

has been compromised.

Let CON M denote the master controller and CON S denote the secondary controller. Req i is the network update request for any ID denoted by ID i where i=1,2,3.....n . S is the set of all switches controlled by CON M , S i is the set of all switches participating in Req i .

The detection algorithm is presented in figure 2 which takes a set of network request updates from all legitimate sources and provides a set of compromised SDN switches. It can be observed from fig 2 that compromised switch detection algorithm takes the parameters mentioned above and checks the execution report of primary controller, secondary controller and the switches and loosely predicts any anomaly if execution report of primary and secondary controller des not match. Afterwards the algorithm finally detects the compromised switch if there is a mismatch between secondary controller log and the same of the switches.

At this point all the compromised SDN switches are detected and hence comes the subsequent part of the process i.e. isolation and network flow/path reconstruction. For isolation of the compromised SDN switches corresponding flow table entries are removed from master controller as well as from the secondary controller too.

Now at this point we can consider the whole network as a weighted directed graph G(v,e) where v is the set of switches, e is the set of links between them, e ij is a link between node v i to v j . Here the term switch and node are operationally synonymous and used interchangeably in this literature. Cumulative cost of link e ij is denoted by cost ij >0

which may be any metric like weightage, delay, hop distance etc. We denote nth source-target pair by S n and D n respectively.

Input: A pool of network update requests from legitimate sources
Output: A set of compromised SDN switches
1 if	Controller is CO.Ywthen
2	Send Req, fi=],2,3...N) to CONsi
3	Execute Reqt
4 end
5 else if Controller is CONs then
6	Generate Record-, by using ID-;
7	Add Reqi to Record',
8	if Ext^Es then
9	।       The switch might be compromised;
10	end
11 end
12 else if E.-Ex then
13	VEr if Req-= ID-=S: and Es^Et then
14	1      The switch has been compromised;
15	eud
16	end

Fig.2. Detection algorithm of compromised SDN switches

In our approach to reconstruct the network flow we assume the following points-

• •   A link was there between S n and D n or can be established.

• •    P is a path between any two pair of nodes, and it contains no self-loop.

• •    The path cost denoted by cost ij is 1 if it traverses e ij and 0 otherwise.

• •    Path cost is additive.

Fig.3. Network flow reconstruction with 13 nodes

An exemplary snapshot is presented in figure 3 and it can be noticed that in this network of 13 nodes there was a path between N1 and N6 via N11, N12, N13 and total link cost was 5 because cost ij is additive. At this point switch N11 and N7 were compromised, and their subsequent links were deleted from the flow table of the controller. Therefore, there are 4 alternatives with us to reach N6 from N1:P1=N1-N2-N3-N4-N5-N6, where cost ij =6, P2=N1-N2-N3-N12-N13-N6, where cost ij =7, P3=N1-N10-N12-N13-N6, where cost ij =5 and P4=N1-N10-N9-N13-N6, where cost ij =8. Hence P3 has been chosen as the newly constructed path because of minimum flow table alteration cost and corresponding flow table entries are updated in master and secondary controller as well.

Figure 4 depicts the network flow restoration algorithm which receives all the compromised SDN switches and associated links between them thereby providing a path by which switches can reconnect again after eliminating the compromised ones. It depicts that if there is a connection between two distinct nodes, then there might be different paths from these two nodes which may incur different cost values. Therefore, the minimum cost valued path has been chosen here as a path between two such nodes.

Input: A set of compromised switches and links in between.

Output: A path between any two pair of switches.

• 1    For any Source-destination pair S„ and D_n;

• 2    If any switch is designated as a compromised then;

• 3    Calculate Cost,, for each path available from S„ to D_n;

• 4    Choose the path with smallest Cost,; value;

• 5    If there is more than one path with same Cost,; value then choose any one of them;

6.    Testbed Setup, Implementation Result and Security Analysis 6.1.    Testbed Setup

Fig.4. Network flow reconstruction algorithm

As per the prototype implementation of our proposed algorithm for detection of compromised switches, a random switch MAC and link flooding attack has been initiated from Macof tool of kali linux. Detection time and overhead on CPU performance or utilization has been measured for the compromised switch detection algorithm and flow path construction time along with overhead posed on CPU for running the second algorithm has been measured for network flow reconstruction algorithm. Similar types of metrices are used for both the algorithms to achieve better symmetrical view. After successful detection, a network flow reconstruction algorithm has been implemented on a virtual linear network of 25 hosts and 25 switches. Three virtual machines were deployed for the setup configuration and switches were deployed using Mininet emulator using a linear topology in the data layer. All the VMs were implemented on a windows 10 host running on Intel core i5 CPU 3.8 GHz with 16 GB of RAM. The snapshot of the testbed setup is given below-

• •    Controllers- Opendaylight version 14 (Silicon) has been used as a primary controller installed on Ubnuntu 20.04 LTS VM. The same virtual machine has been used for the secondary controller i.e. ONOS version 2.6.0 (woodpecker).

• •    Emulator- An emulator called Mininet has been used to simulate a total of 25 hosts, 25 switches and 625 internal paths among them in a linear topology. It is installed on another virtual machine based on a similar type of VM.

• •    Attacker Machine- A device which is used to initiate the switch MAC flooding and link flooding attack by Macof tool and has been installed on Kali Linux.

• 6.2.    Prototype Implementation and Result Analysis

In the implementation scenario attack traffic has been generated by Macof tool installed in Kali linux which has generated both MAC flood and link flood traffic to overwhelm the switches and links in between. Afterwards both algorithms were implemented in the similar simulation environment described above to measure two major parameters i.e., running time and CPU overhead imposed by the algorithms. These two parameters are extremely important because larger detection time in compromised switch detection process increases the risk of overall DoS in the network and larger time in network restoration makes the whole network unusable. The major computing resource is CPU time therefore both the algorithms should be lightweight enough so that they can easily run and do not impose any major overhead on the overall network performance. We have compared both of our algorithms with the existing state of art and noticed significant improvement for both the parameters for both the algorithms which are described below.

In the experiment the PACKET_IN message has been selected as the initiator of the network update. Upon receiving the PACKET_IN message the master and secondary controllers execute this request and update their flow table. The switches send the execution reports to both controllers. For a switch whose report is different with master or secondary controller has been chosen as a compromised one. We have measured the average detection time after two successful packet and link flooding attacks and obtained 600 different values of the same. As per the experimental findings we found that all switches compromised by the attack have been detected successfully and the average time taken to achieve the highest performance is 4.85 milliseconds. A similar parametric value achieved in [1] was 7.4867milliseconds, therefore our algorithm has provided faster detection time which has been depicted in figure 5.

In the next experimental study, the impact of extra overhead on CPU usage has been studied with our algorithm and without our algorithm and it is found that 117.85% CPU overhead is achieved without the algorithm and 134.44% with our algorithm. The average overhead is therefore 17.24% approx. which is the resultant cumulative impact from all the switches. The same parameters are compared with the existing state of the art SDN-RDCD[1] which has an overhead of 136.34% approx. when the algorithm is running. Therefore, our algorithm is imposing 1.9% less overhead on overall CPU performance which has been depicted in figure 6.

Fig.5. Compromised switch detection time

Fig.6. CPU overhead comparison of compromised switch detection algorithm

Execution Time for Network Flow Reconstruction Algorithm

Fig.7. Execution time of network flow reconstruction algorithm

For the construction of network flow path, a sample of 25 switches and 25 hosts has been taken into consideration along-with 625 links among them. The proposed algorithm completed its execution within 5.56 milliseconds which is an average taken from 500 different execution cycles under normal operational environment. In a similar simulation environment, we have compared our simulation result with Astaneh et al. [23] which gives an execution time of 7.25 milliseconds. Therefore, the proposed algorithm achieves a significant 1.69 millisecond faster execution time which is very crucial in real time scenario. Figure 7 presents a graphical representation of the aforesaid claim.

The similar approach has been followed for testing the CPU overhead utilization of network flow reconstruction algorithm like the previous one i.e. compromised switch detection algorithm. Therefore in this approach the extra burden or load on CPU has been measured. It is found that 135.33% CPU overhead is achieved without the algorithm and 142.47% with our algorithm. Similarly this algorithm is also compared with Astaneh et al.[23] with the same simulation testbed and it provides 144.33% overhead on CPU with the algorithm. So we can conclude that our algorithm has a very marginal amount of load addition on the CPU performance which is illustrated in figure 8.

Fig.8. CPU overhead comparison of network flow reconstruction algorithm

• 6.3.    Security Analysis

The major intention of this work is to provide an algorithmic solution for the detection of compromised SDN switches and restoration of the network flow thereafter. In the normal implementation of the SDN architecture, there is no provision of any kind of security solution to detect such type of incident and therefore any type of attack by which switch(es) might be compromised is undetected which can cause a potential damage of the whole system. Therefore to maintain normal operational flow of the network, the solution approaches proposed by us provide a holistic approach. In our work we have presented a two controller approach so that the extra load of the algorithms can be handled by the secondary controller and overall network load remains same as before.

Therefore the following security aspects have been addressed by our work-

• •    Switch(es) which have been attacked and compromised by the attacker has been detected and isolated from the network successfully.

• •    Subsequent flow table entries have also been removed for those compromised switches.

• •    The entire network flow have been restored again after elimination of the compromised switches.

• •    In short, the work proposed by us manifests a two-fold approach, i.e. detection of threat and mitigation of the ill effects caused by that threat, which is a considerable achievement and security contribution.

7.    Conclusion and Future Scope

In this work an approach for the detection of the compromised SDN switches and reconstruction of network flow has been deduced which are then implemented and evaluated for their effectiveness as per their respective parameters. Two major parameters are considered in the study to evaluate the performance of both the algorithms and after comparing both of them with existing similar type of solutions it has been found that the first algorithm has achieved 35.22% of speed in running time and imposed 1.9% less overhead on computoing resource. In case of the second algorithm it has achieved 23.31% speed in running time and imposed 1.29% less overhead on computng resource. Therefore it can be concluded that both the algorithms are lightweight and efficient.

On the note of future scope there are two observations which can be addressed-firstly a controller can also be compromised like switches in a mutually trusted environment and the effects of that should be analysed properly. Secondly in the time of network flow reconstruction flow table alteration cost is an important factor which also demands further research exposure. We believe if the compromised switch isolation controller which is deleting the entries from primary and secondary controller and updating flow table entries could be designed through FPGA more get further level of security because, to secure the proposed algorithm itself.