Recently, software-defined network (SDN) has gained great attention from both industry and academia as a tool to achieve more dynamic control and management compared with traditional networking architectures.11 However, SDN’s centralized control has introduced many drawbacks such as Denial of Service (DoS) attacks and single point of failure in the control plane, as well as additional security challenges related to application and data planes, since they need to communicate and interact with the control plane. Any flaw in this interaction can be viewed as a potential threat that must be seriously considered to limit its global impacts over a centralized SDN network. For instance, a hijacked SDN application allows the attacker to insert/modify flow entries of related SDN switches, and consequently exhausts the Ternary Content-Addressable Memory (TCAM) resources. It will be more secure if we authenticate all application flows before provisioning and configuration of data plane resources.
Key Insights
- In this work, we study the integration between SDN and blockchain. We provide a fine-grained taxonomy that classifies this integration, based on utilization area, into two main categories: BC for SDN and SDN for BC.
- In BC for SON, blockchain acts as an enabler for achieving a more secure and reliable environment compared with existing centralized SDN architecture. In SDN for BC, SDN is used to protect the underlying BC infrastructure against network-based attacks.
- We propose BC-Sec-SDN—a hierarchical architecture that utilizes consortium BC approach and decouples the control plane into two separate BC-enabled control planes—reactive and proactive BC-SDN
On the other hand, a new technology can be utilized to address these challenges by introducing a fault-tolerate, decentralized control capabilities to the SDN paradigm. Blockchain is one of the most promising solutions toward trustworthy services based on a fault-tolerant, decentralized, and secure distributed ledger. It can be employed in SDN paradigm to provide both operational and structural enhancements. Blockchain (BC) enables monitoring, auditing, and autonomously taking appropriate actions once the preconditions are met. This can be accomplished at the application, the resource, and the flow levels. BC-enabled SDN provides more secure and reliable environment compared with using centralized SDN applications. Additionally, smart contracts can play a vital role in SDN by offloading proactive decision making while protecting SDN against unauthorized parties based on BC principles.
However, various attacks on the BC network layer can impact its performance, anonymity, and availability. This is due to the fact the consensus layer depends on the data transmitted by the network layer. In this context, SDN can be used to protect the network layer of BC, and consequently maximize its availability and improve its resilience against potential threats including traffic analysis and DoS attacks, which aim to interrupt the data flow between BC nodes and ultimately limit their ability to reach consensus.
The integration between SDN and BC comes with additional challenges. For instance, adopting BC for securing SDN rises major issues in terms of how BC can meet the requirements of high throughput and low latency. This also may include introduction of new consensus protocols to satisfy these requirements. Moreover, considering SDN for protecting BC is also limited to network-based attacks, and potentially intruders may exploit the vulnerabilities of traditional SDNs to gain access to the underlying infrastructure, for instance, through poisoning the topology view of SDN via link spoofing attacks.23
In this article, we investigate the integration between SDN and BC. We also show how BC can be utilized to address the limitations of both centralized and distributed SDN architectures. Then, we introduce a detailed literature survey that covers the recent research efforts on this topic. We classify these works into two main categories namely SDN for BC and BC for SDN. Then, we provide a fine-grained taxonomy based on these two categories. Following this, we introduce a BC-enabled architecture that adopts BC to meet the requirements of more protected, decentralized, and fault tolerant SDN.
Li et al.16 briefly discuss the integration among SDN and BC. They summarize and present a generic framework for BC-enabled SDN based on Dist-BlockNet.32 They also discuss the main security challenges in SDNs along with possible solutions. Our work, however, clearly shows that several frameworks with different underlying goals have been proposed in the literature.8,9,11,12,14,25,26,27,28,30,32,33,36,37,38,39,40
In another study, Alharbi1 summarizes the existing literature on the same topic. However, this work lacks the appropriate categorization of different proposed solutions.
The SDN architecture simplifies decision making and facilitates development of new protocols as well as various SDN-tailored network applications.
In addition, this work does not discuss the limitations of BC. In contrast, our survey provides a fine-grained taxonomy that discusses the topic in a more detailed and comprehensive manner. We also highlight both the advantages and disadvantages of this integration. Furthermore, our proposed architecture decouples the control plane into two separate BC-enabled control planes namely reactive and proactive control planes. Finally, the survey suggests several directions for future research and improvement.
Software-defined networking. SDN has received considerable attention due to its central management and high flexibility. SDN replaces the local control plane in conventional hardware devices by a global controller, which programmatically manages packet forwarding on a per-flow level. The SDN architecture simplifies decision making and facilitates development of new protocols as well as various SDN-tailored network applications.
The controller manages the underlying data plane using the southbound application programming interface (API), where OpenFlow19 is the most prominent example of such an API. The northbound API, on the other hand, provides a common interface for developing SDN applications.15 An OpenFlow switch has several flow tables, each of which has matching rules along with actions that are executed when an incoming packet matches the corresponding rule. As a result, the behavior of an OpenFlow switch changes according to the rules installed by the SDN controller.15
In SDN, security is mainly integrated in the control plane, whereas mitigation of data modification/leakage takes place in the data plane.25 However, SDN propounds several additional threats such as single point of failure,24 DoS /Distributed DoS (DDoS) attacks,13 and illegal access through malicious SDN apps.34 Unfortunately, these threats have a high impact that could ultimately prevent large-scale deployment of SDNs in many scenarios.30 As a solution, distributed architectures can improve load distribution and avoid single controller failure. However, they come at the price of additional overhead due to cross-controller communication as well as increased latency due to the need for synchronized and consistent state management among different SDN controllers.
Blockchain. Recently, BC has gained increasing attention due to its capability as a fundamental technology for cryptocurrencies such as Bitcoin22 and Ethereum.35 Bitcoin22 is the first BC and also the most popular cryptocurrency, whereas Ethereum35 represents a generalized BC platform for developing decentralized apps. BC is basically a decentralized distributed ledger that provides trustworthy services to members of a peer-to-peer network without relying on a central authority.27 The decentralized distributed ledger is built and maintained through consensus among all BC members in a distributed fashion to achieve consistency while ensuring adequate fault tolerance.36 BC systems aim to achieve higher level of security and reliability compared to most of non-BC systems.3 In other words, BC systems can operate in potentially hostile settings.3
In BC, a series of data blocks are generated using cryptography to be secure, immutable, and tamper-proof.30 Each block contains the hash value of the previous block header, transaction data, a timestamp, and a nonce. Consequently, multiple blocks are connected to form a chain. Each new block is added through an agreement between BC nodes, thanks to consensus protocols, which define how to reach to an agreement without relying on any trusted third-party intermediaries. In general, there are three types of BC, including public, private, and consortium BCs. In public BC, every node can be involved in block creation whereas in private and consortium BCs only specific nodes can participate in this operation using a valid certificate obtained by an identity management infrastructure such as certificate authority (CA).27 In public BCs, committed transactions are visible to everyone while the read permission is restricted to participating nodes in private BCs. In consortium BCs, the organization may decide whether the approved transactions are public or private.41 Private BCs are fully controlled by one organization whereas consortium BCs consist of more than one organization.
Private and consortium BCs are more efficient compared to public BCs. The fact of having fewer validators results in higher transaction throughput and lower latency.41 Hyperledger Fabric2 is the most notable example for a business-oriented consortium BC. In addition, BC platforms, such as Ethereum35 and Hyperledger Fabric,2 provide smart contracts, which are automatically executed according to a preconfigured script code based on trusted data provided by decentralized distributed ledgers.36 In this context, BC systems must maintain backward compatibility to validate earlier transactions and potentially to be able to interact with older versions of a deployed smart contract.3 BC developers may also need to test and verify the security requirements of their smart contracts before being deployed.3
Several approaches were proposed to reach consensus between BC nodes. Proof of work (PoW)22 is used in Bitcoin network. In PoW, network nodes need to solve a computationally difficult problem (that is, cryptographic puzzle) to create a new block,5 where 51% of computational capability is considered the threshold of PoW to gain control of the BC network.41 The PoW procedure wastes the resources of the mining nodes to be authentic.41 As an alternative to PoW, Proof of Stake (PoS) requires the proof of ownership to validate a newly generated block, considering those with more cryptocurrencies are more trustful than those with fewer cryptocurrencies.5 Compared with PoW, PoS saves more energy and is more effective. However, attacks might occur since the mining cost is nearly zero.41 Practical byzantine fault tolerance (PBFT)4 can also be utilized as a consensus algorithm and can handle up to 1/3 malicious byzantine failures, where each node who votes for the consensus sends its vote to the other nodes.5 In each phase, a node will move to the next phase once it receives votes from 2/3 of all BC nodes.41 Hyperledger Fabric2 (in its version 0.6 and Hyperledger Sawtooth) employs PBFT to reach consensus among BC nodes. It is possible that valid blocks might be generated simultaneously when several nodes solve the puzzle at the same time, which results in branches (or forks).5 PoW and PoS solve this issue by choosing the longest chain whereas PBFT handles this issue through multiple communication rounds. We refer the reader to Dai et al.5 and Zheng et al.41 for further details.
Integration Between SDN And BC
BC can address the limitations of SDN in terms of security, reliability, and single point of failure by introducing a decentralized control-plane and securely sharing critical information at different levels including the application, the resource, and the flow levels. However, this would present new challenges in terms of how BC can meet the throughput and latency requirements of SDN. On the other hand, SDN can be utilized to improve the availability and to provide access control for BC nodes enforced by network devices and SDN control plane.
Distributed architectures improve load distribution and avoid the single controller failure; however, they bring additional overhead from controller-to-controller communication and increase the latency due to the need for consistent state/policy and synchronized global network view among different SDN controllers. On the other hand, decentralized architectures have attracted the attention of the research community as a solution to address the limitations of SDN. In this regard, BC is considered a promising approach, which acts as an out-of-band party that can be utilized to achieve a consistent and synchronized global view among different SDN controllers. BC can also ensure security, dependability, and traceability requirements of SDN.27 Security is required to define who has access to what, when, and in which conditions. This system should also be highly dependable in terms of reliability and availability. It also must provide an undisputable proof that cannot be fabricated or forged in possible compromises.
SDN as a networking layer for BC would provide a better protection for BC nodes. For instance, it can be used to maximize the availability of participating nodes against DoS/DDoS attacks33 and to achieve flow-based access control.9 The existing integration approaches can be classified according to many different criteria. However, the classification we have found to be the most beneficial is primarily focusing on the utilization area. This can be a useful basis for researchers seeking to identify the range of applicability, and the mutual benefits of combining these two different technologies. Therefore, we classify this integration as BC for SDN and SDN for BC. The first category improves SDN through BC, whereas the second category makes use of SDN to enhance BC. Figure 1 illustrates both SDN and BC architectures along with the major issues that can be solved by combining these two paradigms.
Figure 1. The integration between SDN and BC.
BC for SDN. As depicted in Figure 1, the SDN architecture consists of untrusted apps, resources, and controllers, which ultimately need to interact with each other. BC for SDN approaches make use of BC to secure traditional SDN paradigm. We categorize them into the following two groups: operational solutions that focus on enhancing the functionality of SDN, and structural solutions that provide core architectural refinements for the SDN paradigm.
Operational solutions. The operational solutions utilize BC to secure the core functionality of SDN through a cooperative defense among SDN controllers, and to protect that collaboration by authenticating and establishing trust at the controller, the application, and the flow levels. Accordingly, these solutions can be classified into the following three subgroups: cooperative defense, trust enhancement, and decentralized authentication.
Cooperative defense. Cooperative defense focuses on detecting sophisticated and coordinated attacks that require collaboration among different SDN controllers, which will allow a more effective mitigation near the origin of the attack and reduce the high volume of traffic exchanged across different SDN domains. BC is used to securely share critical information related to cooperative defense models and core SDN functionality such as routing among several network domains.
El Houda et al.8 propose a cross-domain collaborative DDoS mitigation scheme based on BC smart contracts, which allow multiple SDN-based domains to securely collaborate and transfer attack information in a decentralized manner. The collaboration is managed by the smart contract’s owner who can add/remove the collaborators that report suspicious IP addresses within their domains. This approach provides a secure, low-cost, and flexible solution to mitigate DDoS attacks in cross-domain SDNs.
Rathore et al.28 introduce a decentralized and cooperative architecture for IoTs using a combination of SDN and BC as well as fog and edge computing. Attack detection is performed at the fog layer using deep learning approach. Fog nodes and a cloud server share data using BC, which is also used to regularly update the attack detection model and flow rules in the SDN switches. The cloud server acts as a manager that manages and initiates the attack detection models using BC smart contracts.
Qiao et al.26 propose a BC-based approach to establish trust among SDN controllers for cross-domain routing. There are two types of transactions, the first one is related to cross-domain routing, and the other is related to network state information updating. Each transaction must be recognized by at least one node in each domain.
Cooperative defense approaches take advantage of BC to secure the information shared between SDN controllers and related applications, which removes the need to use a central entity and reduces the complexity of developing new protocols and/or modifying the existing ones. The effectiveness of these protocols also depends on global deployment and may suffer from single point of failure.8
Trust enhancement. Trust enhancement approaches make use of BC to establish trust among SDN controllers and related devices, which are connected within an SDN network. Trust management includes that each device connected to the SDN network to be registered into BC along with a trust level that changes over time based on the recent activities of that device. The advantage here is that BC ensures that trust scores stored within BC are secure, immutable, and tamperproof. Moreover, trust scores are stored through consensus among all BC nodes, which are more immune to fake information submitted by malicious devices.
Kataoka et al.14 utilize BC to prevent unsolicited traffic coming from IoT devices positioned at the edge of the network in a trustworthy, scalable, and distributed manner. To this end, they implemented a trust list across widely distributed edge networks using BC and SDN. First, SDN controllers receive the recent updates of BC, which contains profiles of validated devices. Then, they check whether the device is connected to their network. Finally, new flow rules are installed to allow that device to communicate with the server based on an existing service profile.
Zhao et al.40 focus on protecting the control plane of SDN through a trust management architecture. More precisely, they propose a secure and efficient resource allocation for software-defined vehicular networks (SDVN). The main goal here is to protect SDVN against fake information submitted by malicious vehicles, which aim to deteriorate the quality of service (QoS) of other legitimate vehicles. A joint proof-of-stake and modified practical Byzantine fault-tolerance (PoSmPBFT) algorithm is proposed to shorten the confirmation time and reduce the communication overhead of PBFT,4 where a fully trustworthy CA is used to collect, compare, and choose the leader.
Decentralized authentication. Decentralized authentication approaches utilize BC to authenticate legitimate devices that are connected to an SDN network. BC securely stores the information related to legitimate devices and reduces the re-authentication overhead among different SDN controllers.
BC can be used as an access control method for SDN components and their associated critical assets, where only authorized entities can access the SDN network.
Yazdinejad et al.38 propose a BC-enabled handover authentication for 5G within SDN. This approach provides secure and fast authentication by employing BC, which eliminates reauthentication in repeated handovers among heterogeneous cells, in which unique characteristics of mobile user are shared between current and adjacent cells. In this work, BC manages the control plane of SDN and sends user’s information to the SDN controller of that cell. Preshared-key handshakes are eliminated by using BC. In other words, the messages are approved by the BC instead of a third party. SDN, on the other hand, prepares the flow tables in accordance with a given policy.
Jindal et al. present SURVIVOR,12 an edge-as-a-service platform that utilizes BC to provide a secure energy trading in SDN-enabled vehicle-to-grid (V2G) environments, where BC is utilized to authenticate the energy trading transactions in the system using the PoW22 approach. The study showed that the time required to generate header value and validate the transaction increases as the number of transactions increases.
Pourvahab et al.25 introduce a BC-based approach for forensic purposes in SDN-based IoT environments. BC along with Linear Homomorphic Signature (LHS) algorithm are used to authenticate IoT devices based on a unique identity and Elliptic curve cryptography. An unauthenticated IoT device sends packets to the gateway, which forwards these packets to the switches and then authenticates them via the signature in SDN controllers. Event logs are used and stored on the blockchain.
Access control. BC can be used as an access control method for SDN components and their associated critical assets, where only authorized entities can access the SDN network. In addition, each entity signs related BC transactions to prove their identity. In this context, Yazdinejad et al.39 employ BC as an access control method for the IoT devices and their associated data, where they presented a secure and energy-efficient BC-enabled SDN architecture for IoT networks using a cluster structure, in which each SDN controller acts as a cluster head. The SDN controller manages several processes in each SDN domain via a private BC whereas different SDN controllers securely share data related to trusted IoT devices through a public BC. The authors replaced PoW with an authentication method to improve the performance of BC.
Structural solutions. The structural solutions take advantage of BC to enhance the structure of SDN paradigm. These solutions can be also categorized into the following groups: switch-level improvement, global view protection, and hybrid approaches. Switch-level improvement utilizes BC to enhance SDN’s data plane. Global view protection shares SDN’s global view through BC. Hybrid approaches apply BC technology to secure the SDN paradigm at different levels including the control and the data planes as well as the communication channel between the controller and the switch.
Switch-level improvement. The switch-level improvement approaches enhance SDN’s data-plane in terms of protecting flow tables and including the ability to utilize BC in SDN switches. Sharma et al.32 present DistBlock-Net, a switch-level solution, in which flow tables are verified, validated, and securely updated. The experimental results showed that DistBlockNet is capable of detecting attacks in the IoT network in real time with low performance overheads.
Yazdinejad et al.37 propose a BC-enabled packet parser (BPP) to support detecting attacks as well as BC structure in SDN’s data plane. BPP supports the policies and rules defined by the control plane. When BPP in each SDN switch detects a malicious behavior, it will inform the corresponding SDN controller, and then it will report that incident to other BPPs based on P2P communication among other SDN switches.
Global view protection. The global view protection approaches focus on using BC to securely share and synchronize SDN’s global view among multiple controllers. As BC provides an immutable and tamper-proof ledger, it would prevent external attackers from tampering with the global view provided that the fraction of malicious nodes does not exceed 1/3 of the total number of BC nodes, assuming PBFT4 is used. In other words, BC is utilized as an out-of-band party to reach consensus safely and dependably among different SDN controllers, without affecting the core functionality of SDN network. Qiu et al.27 use BC to collect and synchronize the global view among different SDN controllers. In this work, each controller collects its local events and OpenFlow commands and then stores them into the best BC system at the edge network.
Shao et al.30 collect view related information through features (Features Reply), statistics (Stats Reply), and Packet-In messages, and then store them on the BC to protect the global view of SDN. The requests for storing the global view are verified by the other controllers. To overcome the limitations of PBFT,4 they propose a Simplified PBTF (SPBFT), in which the messages are transferred and verified in a parallel manner. It also prioritizes the received requests to ensure urgent requests are handled quickly and efficiently.
Hybrid approaches. The hybrid approaches apply BC technology at different levels including: the control and data planes as well as the communication channel between the controller and the switch. Yang et al.36 propose BlockCtrl, a BC-based architecture to secure software-defined optical networking (SDON). In BlockCtr, a customizable smart contract is installed in each controller, which automatically performs the network functions loaded in the smart contract. On the other hand, the SDN switches use BC smart contracts to choose the optimal secondary controller on failure. BlockCtr achieves better service correlation and resource utilization when compared with BFT,4 since BlockCtrl considers the traffic data stored in the BC ledger when selecting a new primary controller.
Jiasi et al.11 use BC to address multiple security issues in SDN. They design a monolithic security mechanism for SDN based on BC, which decentralizes SDN’s control plane to tackle the single point of failure while maintaining the global view by sharing network events among multiple controllers. High-performance secure Diffie-Hellman protocol is combined with BC to authenticate the communication channel between the controller and the switch. This approach is considered as a hybrid approach since it utilizes BC to protect the global view at control plane level and to authenticate the communication channel between the controller and the switch.
SDN for BC. In permissioned BC, only certain nodes can be involved in block creation and validation.27 Permissioned BC uses Byzantine Fault Tolerance (BFT) protocols, such as PBFT, as a consensus protocol that employs state machine replication to cope with Byzantine failures. The advantages of permissioned blockchains are low cost and low latency. However, their performance is affected when BC nodes are faulty or under attack. To address this issue, SDN can be utilized to enhance the availability of BC nodes and to protect them against unauthorized access and various network attacks. As shown in Figure 1, SDNs can be used as a framework to protect and optimize the network layer of BCs. Accordingly, we categorized the research efforts to secure BC through SDN into the following two groups:
Availability. As we mentioned previously, permissioned BCs have a limited number of participants. Therefore, maximizing nodes’ availability is a major challenge in such peer-to-peer networks. To this end, Steichen et al.33 propose Chain-Guard, an SDN-based firewall for protecting permissioned BCs against DoS/DDoS attacks, which can influence how consensus is reached and can even prevent BC from working correctly. To prevent malicious actions, all traffic to BC nodes must be forwarded by at least one of the switches controlled by ChainGuard, which directly communicates with the BC nodes to distinguish between legitimate and malicious traffic that need to be filtered to protect BC nodes.
Flow-based access control. BC nodes must be protected against intruders that deliberately attack the infrastructure of BC to gain access or attempt to disturb legitimate BC transactions. To address this issue, El Houda et al.9 present ChainSecure to protect per-missioned blockchains from DNS amplification attacks. ChainSecure consists of the following three schemes. First, stateful mapping scheme (SMS) that performs one-to-one mapping between DNS requests and responses. Second, entropy calculation scheme (ECS) to measure randomness of data to detect illegitimate DNS requests using sFlow. Third, DNS DDoS mitigation module. The experimental results showed that ChainSecure can achieve high detection rate with approximately 30% of false positives. Figure 2 depicts the taxonomy for the integration between SDN and BC. Additionally, we highlight the advantages and disadvantages of this integration between SDN and BC in the accompanying table.
Figure 2. Taxonomy for the integration between SDN and BC.
Table. Summary of the advantages and disadvantages of the integration between SDN and BC.
Proposed Architecture
The nature of BC can be utilized to tackle the problem of single point of failure, and to ensure the consistency of global view among cross-domain controllers in a decentralized manner. In this section, we propose BC-Sec-SDN, a hierarchical architecture that adopts BC to fulfill the requirements of fault-tolerant, decentralized, and secure SDN based on consortium BC approach. In BC-Sec-SDN each SDN domain is managed by an SDN controller. Unlike the previously discussed approaches, our architecture decouples SDN control plane into two separate control layers namely reactive and proactive layers. The reactive control layer consists of SDN controllers that receive Packet-In messages from SDN’s data plane and prepare proposals of BC transactions and smart contracts accordingly. Whereas the proactive control layer executes previously committed BC transactions and smart contracts. We utilize BC to securely authorize SDN’s core components including applications, resources, and flows. Moreover, we securely offload proactive network functionality through smart contracts, which provide higher level of adaptivity, decentralization, and fault tolerance. However, the main goal of the proactive layer is to reduce the monitoring task on SDN controllers in the reactive layer, which allows them to focus on certain important events and take critical decisions based on the decentralized approach of BC.
As shown in Figure 3, controllers are positioned vertically with different responsibilities. The reactive control layer has multiple distributed SDN controllers, which instead of directly provisioning flow tables, they deploy appropriate smart contracts and asynchronously send BC transactions to the second level of hierarchy (that is, proactive control layer) without incurring any further delay in control plane’s processing time,29 which ultimately reduces the overall latency and increases the throughput. The SDN controllers utilize write-ahead-log approach,21 where all flow updates are written to a redo log10 before they are installed in the data plane. A redo log record is executed once the submitted transaction is committed by the BC controllers. This idea is mainly inspired by the transaction concept10 in database systems.
Figure 3. Proposed integration between SDN and BC.
On the other hand, from BC perspective, controllers in the proactive layer (that is, BC controllers) are full BC nodes, which are responsible for executing verified BC transactions and smart contracts as well as taking proactive decisions on behalf of the upper level of hierarchy via SDN’s southbound API. As a result, SDN here is implemented based on execution of verified transactions and BC smart contracts, which dictate how flow tables should be filled or updated and also determine how to trust and revoke privileges from the underlying forwarding devices.
In reactive settings, first the SDN switch submits a new signed Packet-In message to the corresponding SDN controller (step 1), which verifies the message (step 2), and then updates the transaction log and submits a new transaction proposal to the BC controller (step 3), which will send the appropriate BC transaction to other BC controllers for consensus (step 4). Once the transaction is committed, the SDN controller will be notified (step 5), which finally sends a new signed Packet-Out to the corresponding switch to add a new flow entry once the transaction is verified and matched with a corresponding entry in the transaction log (step 6). Figure 4 shows the reactive SDN control layer.
Figure 4. Reactive SDN control.
In proactive settings, as shown in Figure 5, once a flow is authorized further actions and access-control policies are defined by the proactive SDN layer based on committed BC smart contracts. The SDN controller submits the appropriate smart contract proposal (step 1). Next, the BC controller sends the appropriate contract to other BC controllers for PBFT [4] based consensus (step 2). Once the contract is committed (step 3), the BC controller periodically collects flow statistics from SDN switches using Stats Request messages (step 4) and then submits update transactions to the corresponding smart contract to update the current BC state (step 5). Theses updates will result in new events, which may further include offloaded or non-offloaded functionalities. Next, BC or SDN controller will be notified for provisioning offloaded or non-offloaded functionalities, respectively (step 6). Finally, the corresponding controllers send signed Packet-Out messages to provision the related switches with the appropriate flow entries (step 7). In case of failure, smart contracts will also allow SDN switches to connect to alternative controllers.
Figure 5. Proactive SDN control (Offloading proactive decision making to BC smart contracts).
The advantage of our architecture is securely sharing of the global view of SDN through BC, which reduces the communication and synchronization overhead among SDN controllers at the reactive control layer. More precisely, these controllers directly communicate with BC-controllers at the next level of hierarchy, which verify submitted transaction proposals and maintain committed transactions in a decentralized, distributed ledger. Moreover, our architecture securely offloads proactive decision making from SDN controllers to smart contracts to increase the level of adaptivity of the whole SDN network.
As SDN controllers delegate the proactive decision making to BC controllers, the overload on SDN controllers will be significantly reduced. Therefore, our architecture shows that BC not only protects the SDN network but also it can be efficiently utilized to replace dumb packet forwarding with more secure, distributed, and autonomous fashion.
However, due to communication overhead of PBFT,4 throughput and latency for large-scale SDNs are among the main technical challenges in our architecture. This is primarily because PBFT requires a quadratic number of messages in the number of participating BC nodes.18 Additionally, the requirement of low-latency BC-enabled SDN can limit the maximum block size in BC network.2
This also implies that BC controllers need to scale their computing power and storage resources in accordance with the increase in number of transactions.17 On the other hand, consensus protocols adopted in BC-Sec-SDN need to take into consideration that different controllers have different computational capabilities as well as the constantly exchanged messages in all-to-all communication pattern may affect the controller throughput. Therefore, there is a need to improve the performance of BC so that it can meet the requirements of SDN in realistic scenarios.
Our architecture falls into structural solutions according to our taxonomy. Apart from the approaches discussed in this paper, we divide the SDN control plane into reactive and proactive SDN layers, and securely offload proactive decision making to BC smart contracts.
Future Directions
Here, we discuss future research directions that must be considered to meet the requirements of SDN while adopting BC technology.
Lightweight consensus protocols. Consensus protocols need to be optimized to reduce the power consumption of the participating nodes, which may also need to perform different network functionalities while keeping the performance at a reasonable level. Lightweight consensus protocols can reach consensus in short time, which ultimately increases the overall throughput.
Security testing tools. Existing security testing tools commonly used for non-BC systems cannot be directly utilized in BC settings, and therefore, there is a need to design and implement BC-tailored tools that consider the main characteristics of BC systems.3
Decoupling data from block header. Decoupling data from block header allows BC transactions to be stored externally (that is, kept off-chain) to avoid consuming additional space while making node-specific (that is, SDN controller) inserting and querying faster.20 This approach also allows parallel insertion of new transactions in BC since these transactions are chained together in the same block based on the node’s block header.
Trust-based validation. Rather than validating all new transactions submitted to BC, trust evaluation algorithms can be employed to validate a fraction of these transactions based on each node’s trust score. This approach is adopted in Dorri et al.6,7 to provide a lightweight, scalable, and efficient blockchain for IoT environments. However, for new nodes which have no trust score, all their new transactions need to be verified. Additionally, BC nodes should not be fully trusted to defend against compromised nodes.6
Fine-grained multi-level trust. BC can also be used to provide finegrained trust and authentication mechanisms among SDN components at different levels including the application, the control, and the data planes. In other words, instead of utilizing BC to only validate flow-level data, one can use it to improve the trustworthiness of the core components of the SDN architecture. This may also imply that these components need to be redesigned to interact only with trusted SDN components.
AI-enabled BC. AI-enabled BC improves the capabilities of BC by analyzing the previous transactions submitted to BC to provide a better decision making and rewarding mechanisms for BC participants based on their collective behaviors. Additionally, AI-enabled smart contracts allow more complex decisions to be taken based on BC principles.31 Therefore, AI-enabled smart contracts can be utilized to support secure, decentralized, and intelligent decision making in SDNs.
Conclusion
In this work, we provided a detailed survey on the potential integration between SDN and blockchain. We categorized the existing works into two main categories namely BC for SDN and SDN for BC. Our work showed that operational and structural enhancements were proposed to achieve a fault-tolerant, decentralized, and secure SDN by blockchain utilization. Whereas SDN can be utilized to improve the availability and to provide flow-based access control for the primary nodes participated in permissioned BC. We also took a step forward by introducing BC-Sec-SDN, a hierarchical architecture that improves SDN in terms of security as well as synchronization of SDN’s global view in a cross-domain SDN network. Moreover, our architecture securely offloads proactive decision making from SDN controllers to smart contracts. The main challenges, however, are related to limitations of current BC systems in terms throughput, latency, and consensus protocols, which need to be improved to meet the requirements of SDN under high load scenarios.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment