Abstract
Multicontroller software-defined networks have been widely adopted to enable management of large-scale networks. However, they are vulnerable to several attacks including false data injection, which creates topology inconsistency among controllers. To deal with this issue, we propose BMC-SDN, a security architecture that integrates blockchain and multicontroller SDN and divides the network into several domains. Each SDN domain is managed by one master controller that communicates through blockchain with the masters of the other domains. The master controller creates blocks of network flow updates, and its redundant controllers validate the new block based on a proposed reputation mechanism. The reputation mechanism rates the controllers, i.e., block creator and voters, after each voting operation using constant and combined adaptive fading reputation strategies. The evaluation results demonstrate a fast and optimal detection of fraudulent flow rule injection.
1. Introduction
Software-defined networks (SDNs) [1] have been widely deployed in many application fields, as they replace the conventional TCP/IP architecture with another one that decouples the networking devices from their control management. This is achieved by moving the network functions that are performed by the network devices to a central entity, which allows an easy and low-cost network management.
To manage large-scale and multidomain networks, multicontroller SDN is proposed [2], where each controller is responsible for one domain. In multicontroller SDN, there are two types of communication: vertical and horizontal. In vertical communication, OpenFlow protocol [3] manages the southbound interface between the controller and the forwarding devices, e.g., switches, by telling switches where to send data flows. The northbound interface manages the communication between the controller and the applications. In horizontal communication, controllers exchange information about network topology between them via their east-west interfaces.
The horizontal communication allows controllers to share any update about network topology like the link state, network devices, changes in the flow table, list of network hosts, and the association between each switch and its controller. Thus, it is important for controllers to maintain the same global network view. To this end, an intercontroller traffic must be exchanged between the controllers, through their east-west interfaces. So, a logical centralized view of the network state must be guaranteed for SDN controllers to facilitate the development of advanced network applications.
The main concern for the network administrator and network programmer is to keep the SDN controllers synchronized and having similar network topology information to make the correct routing decisions. However, multicontroller SDN could be targeted by several attacks [4–6], including false data injection, where a compromised controller sends fraudulent flow information to other controllers. This could cause routing malfunctions, routing loops, and incorrect functionality of firewalls.
To deal with this issue, we propose a security architecture that integrates blockchain technology with multicontroller SDN. The main idea of the architecture is to associate a set of controllers to each domain. Differently from [7] that deploys many controllers for fault-tolerance purposes, our architecture is aimed at ensuring a secure and trustworthy intercontroller communication. To this end, the proposed architecture considers a master controller and redundant controllers for each network domain. Each controller can be master in one domain and redundant in other domains. The master controller creates blocks of network flow updates, and the redundant controllers decide whether to validate the created blocks or not. The architecture also integrates a reputation mechanism that rates the controllers after each voting operations using constant and adaptive fading reputation strategies. In this way, malicious master controllers and redundant controllers that provide incorrect voting will be detected. More specifically, the main contributions of the paper are as follows: (i)We propose BMC-SDN, a security architecture that integrates SDN and blockchain technologies to secure intercontroller communication. BMC-SDN assigns a single master controller and multiple redundant controllers to each domain. The controllers are members of the blockchain; the master controller creates blocks, and its behavior is monitored by the redundant ones.(ii)We integrate a reputation mechanism to BMC-SDN, which rates controllers according to two strategies: (1) constant fading reputation that allows forgetting past operations of the controller at a constant rate and (2) combined adaptive fading reputation that rates the controller using different constants according to the controller’s reputation. More precisely, the more the controller misbehaves, the faster positive histories are forgotten. On the other hand, the more the controller well-behaves, the faster negative histories are forgotten.(iii)We implement the proposed BMC-SDN architecture using different tools such as ONOS, MultiChain, and Mininet software platforms. The evaluation results show that BMC-SDN can detect all injected flows with a low detection delay. In addition, the reputation mechanism allows adaptive detection time of malicious controllers according to the requirements of the network administrator.
The rest of this paper is organized as follows: Section 2 presents related work. The system and threat model is given in Section 3. Section 4 provides a detailed description of BMC-SDN. The implementation and performance evaluation of BMC-SDN are presented in Sections 5 and 6, respectively. Finally, Section 7 concludes the paper.
2. Related Work
Security of SDN has attracted much attention from researchers [6, 8]. Tayfour and Marsono [9] proposed a collaborative technique to detect and mitigate distributed denial-of-service (DDoS) flooding attacks on software-defined network (SDN) across multicontroller domains, using sflow-RT [10] and Snort rules. Halder et al. [11] proposed a mechanism that detects conflicts in distributed SDN controller environment. Each controller generates a directed graph from the forwarding rules. The different graphs are merged to generate a global network state, which allows detecting any kind of flow rule violation and forwarding loops. Das et al. [7] proposed an SDN architecture that replaces the single controller with multiple independent controllers, which allows tolerance to controller failure. Varadharajan et al. [12] proposed a policy-based security architecture for a multidomain SDN network. The packet flows are analyzed to identify an eventual unauthorized flow and dynamically update security policies.
Blockchain has been adopted as an option to secure one-controller SDN. Derhab et al. [13] proposed BICS (Blockchain-based Integrity Checking System), which sends the traffic flow rules of the vSwitch to the blockchain. The fraudulent flow rules are detected if the rules sent by the SDN controller are different from the ones in the blockchain. In [14], the blockchain is also used to secure the communication between the SDN controller and the other network elements against false flow rule injection. In [15], a blockchain mechanism is proposed to protect against unauthorized access and DDoS attack. In this mechanism, the switches are registered and verified using zero proof of knowledge. They are also validated in the blockchain using a voting-based consensus mechanism. Also, a Boltzmann deep learning machine is applied to identify anomalous flow traffic. DistBlockNet [16] verifies and validates the version of the flow rule table using a blockchain and downloads the latest flow rules for the IoT forwarding devices. TrustBlock [17] computes the trust values of SDN nodes based on blockchain. The consensus mechanism of the blockchain is used to filter out dishonest nodes that provide unfair recommendations.
Blockchain is also used to secure multicontroller SDN. Fernando and Wei [18] proposed an infrastructure comprising two layers: (1) multicontroller SDN networking layer and (2) blockchain-based layer. The control/management commands of the SDN controller are hashed and recorded in a smart contract of the blockchain and sent to the targeted SDN controller. The latter verifies the integrity of the command by checking the smart contract. Yang et al. [19] proposed BlockTC, a distributed blockchain-based trusted multidomain collaboration for mobile edge computing, wherein all SDN controllers use the blockchain to obtain topology information of other domains and verify the legitimacy of the routing. Azab et al. [20] proposed a system, where multiple controllers manage the same set of switches. The blockchain is used to ensure consistency between SDN controllers. The switches and the controllers are considered nodes in the blockchain. When the switch broadcasts its request to all controllers, each node in the blockchain can verify and validate the request. Kataoka et al. [21] proposed a trust list that is distributed among IoT devices using blockchain and SDN. The IoT devices can only trust other devices and services that are whitelisted in the trust list.
Blockchain is also proved to be a promising technology to mitigate false data injection in IoT networks. For example, Cheikhrouhou and Koubaa in [22] leveraged blockchain technology to secure localization in IoT networks and guarantee the correctness of the shared information. The proposed solution permits detection of false data injection and therefore reduces the localization error.
3. System and Threat Model
As shown in Figure 1, we consider an SDN network with multiple and distributed controllers. The general SDN architecture contains three layers: application, control, and data layers. The application layer contains programs that explicitly communicate their network requirements and desired network rules to the controllers. The control layer contains controllers deployed in a distributed manner. The data layer contains devices that are configured in different domains. Each domain is controlled by one master controller, and each master controller has more than one slave or redundant controllers. In addition to its primary role, the master controller is configured as a redundant controller for more than one domain. The controllers in a distributed multicontroller SDN keep the same network global view (i.e., same topology and same link status). Any change in the state of each controller such as new flow configurations and link failures must be quickly sent to other controllers. If the controllers have an inconsistent view, the network strategies may not be executed correctly, which could cause network misconfigurations such as routing loops, packet losses, and firewall leaks.
Figure 2 shows the possible threats and attacks that could occur in a multicontroller SDN architecture. If the communication between controller C1 and the other controllers fails, then the network could be partitioned. In this case, if the network topology changes in the domain of controller C1, the other controllers cannot be informed and vice versa. Therefore, the controllers could make routing decisions based on their own old view of the network topology, which could lead to unforeseen events.
Moreover, an attacker can intercept the communication between controllers and injects false data. This man-in-the-middle attack (Figure 2: arrow 1) can lead to an inconsistent network view, which leads to routing errors such as routing loops (Figure 2: arrow 2), firewall leaks, poor and false routing decision, and congestion of critical links when the majority of the false flow rules go through the same link, which ultimately affects the performance of the network.
In addition, it is possible for an attacker in this communication model to spoof controllers (Figure 2: arrow 3) and send false information about the topology, the state of the links, and the hosts of each domain. This false information can cause several problems such as traffic congestion, device overloading, and wrong routing information.
Another critical attack could be launched by exploiting some APIs that are offered by the SDN controller [23]. These APIs allow developers to implement new network control applications. Indeed, if an application is compromised (Figure 2: arrow 4), the security of the entire network can be compromised. Such an attack can have dramatic consequences such as the modification of the behavior of the network and the intercepting of the network traffic, which can trigger large distributed denial-of-service attacks [24].
4. Blockchain-Based Multicontroller Software-Defined Network (BMC-SDN)
In this section, we provide a description of the proposed BMC-SDN architecture. The aim of BMC-SDN is to protect the control layer of the SDN architecture, previously presented in Figure 1, against the different attacks previously discussed in Section 3. To this end, BMC-SDN uses blockchain to protect the communication among controllers. Figure 3 gives a general overview of our proposed BMC-SDN solution. The control layer is protected thanks to blockchain. More precisely, all controllers are members of a blockchain network, and they communicate with each other via this blockchain. In BMC-SDN, we focus on the security of the control layer and the east-west communication of this layer. For the security of the communication between the controllers and the data layer devices, we consider our work in [13, 14]. Let be the number of controllers in the network. For each domain, we select a single master controller and redundant controllers, . The redundant controllers replace the master controller in case of failure. A redundant controller cannot replace several master controllers unless it is the only available redundant one. The selection of the redundant controller that will replace the master controller is made according to its identity. More precisely, the redundant controller with the smallest ID is selected. In addition, the redundant controllers of the same domain monitor the behavior of their master controller and participate in the consensus of validating the data blocks created by the master controller.
Figure 4 shows the sequence diagram that explains the main steps and operations in BMC-SDN. The master controller is responsible for orchestrating the traffic of its domain, and its redundant controllers monitor the domain, receive the same events, and apply the same updates as the master controller but have no influence on the domain. A redundant controller can control the domain in case the master controller fails as already explained. The controller has a local structure that contains OpenFlow commands [3] and local information such as network topology, list of hosts, and link state. This information could be changed due to several events such as topology change, link failure, and device failure. In case of any change, the master controller receives the corresponding event, performs the required update, and informs the other controllers. So, the master controller creates a block containing these updates and sends it through the blockchain to its redundant controllers. The latter, which have already received the same event as the master, validate this block according to the following consensus protocol: If the number of redundant controllers validating the block exceeds a threshold , then the consensus is reached. In this case, the block is considered valid and will be added to the blockchain. This allows all controllers to have a global view of the entire network. If the consensus is not reached, the block is considered invalid. In this case, the master controller and the redundant controllers who validated this block will be negatively rated, as explained in Section 4.2.
4.1. BMC-SDN Trusted Node
The trusted node in BMC-SDN has the read and write permissions on the blockchain. All the master controllers are considered trusted nodes. They can read from blockchain and create new blocks. The creation of a new block is triggered by receiving a new external event that is sent from the data layer. When a master controller receives new information from the data layer devices of its domain, like flow rule request, it creates a new block containing adequate information and shares this new block with the redundant controllers for validation. The validated block is shared with all controllers in the network. Therefore, each controller can build the same global network view.
4.2. BMC-SDN Consensus and Reputation Mechanism
The consensus process is performed by the redundant controllers. These controllers are considered miners. They are responsible for validating newly created blocks. After creating a new block by the master controller, the new invalid block is shared with the miners. The miners start the validation process by comparing the similarity between the information contained in the invalid block and their local information. The miners receive the same request as the master controller and then generate the needed reply. For example, they generate the same flow rule for the same flow rule request. So, the miner can check the similarity and accordingly validate the new block. Upon validation, the new block will be added to the chain. Miners who have a different opinion than the majority and the master controller whose block has not been validated could be considered a malicious controller. The detection of the malicious controller will be calculated based on the below reputation mechanism.
This reputation mechanism is seen as an additional layer of security to protect the control layer and therefore the entire network. This mechanism is based on the reputation management of controllers. Each controller has a reputation value shared between miners in the same blockchain. The value of is between 0 and 1 (). In this mechanism, each controller can be in one of the following three states, depending on its reputation value : (i)Trustworthy controller, if . In this case, the information sent by the controller is evaluated and taken into account by the miners.(ii)Suspicious controller, if . In this case, the information sent by the controller is evaluated but are not taken into account by the miners.(iii)Malicious controller, if . The communication traffic of this controller is ignored by others, until intervention of the network administrator. When , the reputation of is continuously updated and switches to the suspicious and the trustworthy states when and , respectively.
The miner controllers evaluate the controller according to the consensus result: (i)If the consensus is reached, the block sent by the master controller will be validated and the value of its reputation increases.(ii)If the consensus is not reached, the block sent by the master controller will not be validated, and thus, the value of its reputation decreases.(iii)For miners who have the same opinion as the majority, their reputation will increase.(iv)For miners who have a different opinion than the majority, their reputation will decrease.
More precisely, the value of is computed as follows: (i)We compute the reputation of controller , denoted by , during each time period (or observation interval). Formally, , where is the number of positive participation and is the total number of positive participation made by controller in blockchain operations (creation and validation of blocks).(ii)If , the reputation of during the current time period is set to 0. Otherwise, it is set to 1.(iii), where is a constant fading (or discount) factor for past participations.
By using the constant fading factor, both positive and negative histories are forgotten at the same rate. Let us consider the following scenario: (i)If is low, we have two scenarios: (a)If the controller is trustworthy and starts behaving maliciously, then the positive history will be forgotten slowly, and hence, detection time of the controller will be high.(b)If the controller is malicious and starts well-behaving, then the negative history will be forgotten slowly, and hence, redemption time of the controller will be high.(ii)If is high, we have two scenarios: (a)If the controller is trustworthy and starts behaving maliciously, then the positive history will be forgotten quickly, and hence, detection time of the controller will be low.(b)If the controller is malicious and starts well-behaving, then the negative history will be forgotten quickly, and hence, redemption time of the controller will be low. In this scenario, the controller could take advantage of the reputation system and act maliciously most of the time, and when its state becomes suspicious or malicious, it just needs to perform few positive operations to return back to the trustworthy state.
Based on the above scenarios, we can observe that using a constant fading factor has some disadvantages. To deal with this issue, we propose using different fading factors according to the reputation of the controller, as follows: where and . The above equation uses combined fading factors, i.e., the more the controller misbehaves, the faster (resp., the slower) positive histories (resp., negative histories) are forgotten. On the other hand, the more the controller well-behaves, the faster (resp., the slower) negative histories (resp., positive histories) are forgotten.
5. Implementation
5.1. Implementation Environment
In this section, we implement the blockchain-based secure multicontroller architecture, as shown in Figure 5, using the following components: (1)SDN Controller. We use the Open Network Operating System (ONOS) [25] to implement the SDN controller. It provides the control plane that supports the deployment of several controllers as a domain. The implementation parameters of the SDN controller are shown in Table 1.(2)Blockchain. We use MultiChain [26], an open source platform to implement a private blockchain. It can assign privileges to nodes and control who can connect, send, and receive transactions and who can create flows and blocks. Each MultiChain node is accessible through the MultiChain Web Demo [27], which is a simple web interface for multiChain blockchains.(3)Mininet [28]. It creates a virtual network supporting OpenFlow [3] and consisting of switches and real applications that are deployed on a single machine (virtual or real machine or cloud).
The code that we used to implement BMC-SDN can be found in [29]. In addition, we use other tools to implement our solution, such as Postman [30], an application that allows sending http requests and manage authentication. We also use SecureCRT [31], which is software for network administration and end-user access. Our solution is implemented using Python programming language, and some libraries like HTTPBasicAuth, and Requests that authenticate and interact with REST APIs of the ONOS SDN controllers, respectively. We also use JSON (i.e., JavaScript Object Notation) [32] in order to represent data that are processed by the controller data.
5.2. Data Structures
We handle data stores, which are the real distributed data structures in ONOS controllers; the main ONOS Stores are presented in Table 2.
Among the distributed stores presented in Table 2, there are those that are related to the behavior of the data plane such as the network topology store, the flow store, and the host store. The other distributed stores are considered application-specific.
6. Performance Evaluation
In this section, we evaluate the performance of BMC-SDN using the following metrics: (1)Total Execution Time. It represents the required time to transfer a flow through the blockchain, denoted by (). It is the sum of three elements, relating to the number of switches and the number of hosts in the network, namely, (1) the consensus time, (2) the time to send a block, and (3) the time to update data: (2)Detection Rate (DR). It represents the ratio of the number of detected attacks to the total number of injected attacks.(3)Detection Time (DT). It records the required time to detect malicious controllers.
To assess the robustness of our BMC-SDN solution, we inject fraudulent flows at the controller, as depicted in Figure 6. In Figure 7, we can see that these flows are detected as malicious and reported to the administrator by adding an entry to the log file, containing details of the detected anomaly.
Table 3 represents the detection rate according to the number of injected attacks. As shown in the table, BMC-SDN ensures the detection rate of , which indicates success in detecting all the injected attacks in the network. As the redundant controllers have the same network view as the master controller, any fraudulent flow that is injected by the master is detected by the redundant ones during the block validation.
As shown in Tables 4 and 5 and Figure 8, we can observe that the total execution time increases as the number of switches increases. We can also observe that the execution time of the consensus increases when the number of switches and hosts is increased. However, the recorded values of execution time are very low.
(a) Execution times vs. number of switches
(b) Execution times vs. number of hosts
Figure 9 shows the detection time of the reputation mechanism when the controller behaves maliciously under three values of constant fading factors and under the combined fading factor such that , , and . We can observe that the reputation of the controller decreases slowly under high constant fading factor, and hence, high detection time is achieved (i.e., ), and decreases quickly under low constant fading factor, and hence, low detection time is achieved (i.e., ). We can also observe that the combined fading factor employs different fading factors depending on the reputation of the controller. When , it slowly decreases when the fading factor is high (i.e., ). When , it decreases at a higher speed, and hence, lower detection time is achieved.
7. Conclusion
In this paper, we have proposed BMC-SDN, a blockchain-based multicontroller architecture for secure software-defined networks. In this architecture, we cluster network devices into SDN domains. One master controller and multiple redundant controllers are assigned to each SDN domain. We have used a blockchain where the master controller creates blocks of network flow updates, and redundant controllers validate the blocks. After each voting operation, a reputation mechanism is invoked to rate the controllers, i.e., block creator and voters. The reputation mechanism employs constant and adaptive combined fading reputation strategies to manage and customize the detection time of malicious controllers. The proposed security architecture has been implemented and tested using ONOS, MultiChain, and Mininet software platforms. The evaluation results have reached detection of flow rule injections in a short time. In addition, the proposed combined-fading reputation mechanism has allowed adaptive configuration of fading parameters to reach desired detection time. As BMC-SDN only considers the security of east-west interfaces, we plan as future work to cover the rest of the security planes of SDN architecture, especially the southbound interfaces.
Data Availability
We used data generated from attack scripts and simulators.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
Dr. Omar Cheikhrouhou thanks Taif University for its support under the project Taif University Researchers supporting project number (TURSP-2020/55), Taif University, Taif, Saudi Arabia.