Preserving Flow Table Integrity in OpenFlow Networks through Smart Contract

SDN revolutionises network management by providing a centralised controller that enables ﬂexible and eﬀortless conﬁguration of networks. However, this ﬂexibility also leads to a vulnerability that enables the adversary to trick the security system into allowing the installation of unauthorised ﬂow rules in the switches. Blockchain provides us with a way to protect against malicious tampering with ﬂow rules by storing them in the distributed ledger. In this work, we pro-pose FTISCON, a mechanism to preserve the integrity of the Open-Flow ﬂow table that utilizes blockchain technology. We employ the Ethereum Private Blockchain to implement the proof-of-concept and conduct a comparative analysis of the proposed scheme and existing related schemes, evaluating their performance in terms of delay, computation time, transaction cost, and detection rate. The proposed work is found to perform better in each of these. The study results suggest that the proposed approach oﬀers a practical and eﬃcient remedy to prevent ﬂow modiﬁcation attacks within SDN networks.


Introduction
In today's interconnected world, computer networks have become indispensable, serving a critical role in facilitating communication and information exchange across the Internet.However, the lack of programmability and flexibility in traditional network architecture often hinders its deployment (Kreutz et al, 2015).One of the primary drivers for this is the vertical integration of data and the control plane of traditional networking.The complexity of network elements makes managing these devices expensive and unreliable in case of frequent network failures.In traditional networking, the responsibility of managing packets that move through the network is distributed across multiple nodes rather than centralised in one location Alsaeedi et al (2019).These drawbacks in traditional networks slow down the innovation and evolution of networking infrastructures.The evolving landscape of applications requires a network architecture that is adaptable and readily customizable.
Software-Defined Networking represents a novel networking paradigm that has gained significant attraction due to its programmability by a centralized controller (see Figure 1).The SDN controller and SDN switches communicate through OpenFlow protocols.The forwarding rules act as a direction for the incoming traffic.In the OpenFlow protocol, a forwarding device matches the incoming traffic with the flow rules and takes action as specified in the matching flow rule.
The adoption of SDN is going to save error-prone manual configuration by enabling dynamic automation through a central controller, thus improving network flexibility.These benefits are attracting the use of SDN technology in Data Center Networks, the Internet of Things (IoT), and Fog Networks Yazdinejad et al (2020); Barka et al (2021).Due to the dynamic nature of IoT devices, traditional networks are not suitable for managing IoT networks.Furthermore, the SDN controller provides enhanced security by providing a special debugging facility from the central controller.
The flexibility and programmability offered by SDN controllers create a potential vulnerability where malicious actors can deceive security applications, leading to the installation of malicious flow rules on OpenFlow switches.Moreover, the attacker can exploit vulnerabilities in the control plane to modify or redirect network traffic, leading to security breaches and data leakage.The controller is the only device that can possibly determine whether a flow rule has been tampered with.So, the attacker with a rogue controller will try to tamper with the flow rules in the switches and cause network failure.Therefore, in this work, we plan to develop robust and effective security mechanisms to mitigate the impact of flow modification attacks.
As distributed networks are gaining popularity, efforts are being made by researchers to adopt Blockchain Technology for securing SDN-enabled networks.Blockchain is a Distributed Ledger Technology (DLT) with characteristics such as decentralization, immutability, non-reversibility, and peer-to-peer operation and has been widely adopted in various fields Krishnan et al (2022); Wang et al (2022); Roy et al (2021); Misra et al (2020a).Blockchain has been effectively used in the field of IoT to preserve the privacy of IoT devices and data-sharing schemes Ferrag et al (2019).In the healthcare sector, researchers are utilising blockchain to preserve the privacy of patients and maintain electronic medical records (EMR) in the block.
The concept behind blockchain is to record the transaction history in a chain of blocks across its peer-to-peer network.Blocks are connected in a chain, with each block containing a hash value that corresponds to the previous block.Therefore, mutating one block will make the entire chain invalid.Each node in the network takes a copy of the blockchain and performs a validation of transactions.Therefore, a consensus is made among the nodes before creating a new block, which makes it difficult for the eavesdropper to tamper with any block (once a block has been tampered with, it is visible to all nodes involved in the consensus).The consensus algorithms tell how the nodes agree to add the block to the chain.After the nodes have verified the transaction, it is approved, and the distributed ledger is updated.The updated ledger is then broadcasted to all nodes on the blockchain, ensuring that every node has an accurate and current copy of the data (see Figure 2).
Ethereum Smart Contracts are self-executing programs stored on the blockchain network.It is mainly used to automate the operations in the network Khan et al (2021).The functions are executed when certain conditions are met.Therefore, it is useful for automating the verification of flow rules on the blockchain without the need for intervention.Furthermore, the decentralised architecture of blockchain technology makes it suitable for the integrity of SDN flow tables.The immutable nature of blockchain prevents the malicious manipulation of flows by the attacker and makes it potential for SDN integrity.Therefore, it can be used to strengthen the integrity of SDN and make it more robust.This paper presents a scheme called FTISCON to detect flow rule modification attacks on OpenFlow switches in SDN networks by using Blockchain Technology.The main contributions of this paper are as follows: • A Smart Contract (SC) implementation of flow rule verification mechanisms to avoid the malicious manipulation of flows by an attacker.• A practical implementation of the proposed work using an Ethereum private blockchain was developed to demonstrate its feasibility.• A simulation-based experimental performance study of the proposed method in Mininet.• A formal and informal analysis of the detection rate, execution time, transaction cost, delay of the proposed work, and time complexity comparison in relation to existing techniques.The rest of this article is organized as follows.Section 2 describes related works on state-of-the-art SDN security threats and vulnerabilities.In Section 3, we discuss our system model and architecture of the FTISCON in detail.We also give a detailed description of the design of smart contracts based on the Ethereum Private Network and the flow verification process.Section 4 presents the experimental result analysis and discussion of the results.The concluding remarks and future directions are presented in Section 5.

OpenFlow Flow Rules
OpenFlow is a networking protocol that enables the separation of control and forwarding functions within a network.This allows network controllers to define how traffic should flow through a network of switches that can be programmed to follow the controller's policies.It uses a match-action pipeline to process packets on a switch.The match section of the pipeline compares incoming packets against a set of criteria or rules, while the action part specifies what to do with packets that match those criteria.OpenFlow rules contain a set of matching fields, instructions, and counters to measure the number of matches shown in Figure 3.The action phase of the pipeline involves determining the appropriate course of action for the packet, which can include directing it to a designated port, discarding the packet, making alterations to certain packet header attributes, or forwarding the packet to the controller.Each flow in the flow table is associated with a counter that keeps a record of the packets and bytes that correspond to specific rules or criteria in the match-action pipeline.These counters can help administrators understand which network applications or devices are using the most bandwidth, which can be helpful for capacity planning and network optimization.
The flow table becomes vulnerable to security threats such as DoS attacks.It becomes the target for the attacker in which the adversary tries to break into OpenFlow switches to install malicious rules.A malicious flow rule can direct the traffic to an attacker's node which then captures confidential information from the received traffic.Klöti et al (2013) performed an analysis from the security perspective and evaluated the adoption of OpenFlow in SDN.The study shows that OpenFlow is susceptible to a flow modification attack and an information disclosure attack.

Blockchain and SDN
The integration of SDN has brought tremendous improvements to the traditional network.The complexity of maintenance and static configuration of devices has now been simplified by introducing a centralized control plane.However, SDN also introduces security issues for the network.Monitoring the network traffic and maintenance of devices from a single controller becomes difficult.
The attacker's major target is to sniff the control packet sent from the controller and perform a flow modification attack to divert the traffic from the legitimate destination.Thus, network communication security is another concern while using SDN.Blockchain is a distributed, peer-to-peer network  architecture that supports data immutability.The data or transaction is broadcasted on the network to run a consensus and decide the validity of the transaction.If valid, the transaction is appended to the blockchain.Each block is hashed and linked to the others.If someone tries to tamper with the block, the remaining blocks will become invalid, which is also known as the domino effect Ghiro et al (2021).Thus, blockchain can be seen as a potential component to improve the integrity of SDN architecture.Researchers have also explored the utilization of Intrusion Detection Systems (IDS) as a means to identify and mitigate flow modification attacks.The work presented by Monshizadeh et al (2017), deployed IDS to filter malicious traffic and mitigate attacks through the SDN controller.
Another approach was proposed by Giotis et al (2014) that combines both the OpenFlow and sFLow to detect and mitigate anomalies in the SDN environment.In this method, sFlow is responsible for collecting statistics from the network components.However, their method often suffers from high costs and processing time due to heavy traffic loads.
The literature study shows that most of the existing work assumes the control channel is secure, which is not always the case.To address this, Li et al (2017) developed a lightweight mechanism based on Bloom filters to effectively detect man-in-the-middle (MITM) attacks.
Another approach was introduced by Qiu et al ( 2017), which involves maintaining a Global Flow Table (GFT) for the entire network.This approach computes the path for each flow and enables efficient searching for specific flows within the GFT, reducing the burden of suspicious flows.Similarly, Sasaki et al (2016) presented SDNSec, a solution based on symmetric-key cryptography to preserve the integrity of forwarding rules.VeriFlow, proposed by Khurshid et al (2012), acts as a tool to rigorously check for malicious OpenFlow rules installed at forwarding devices.These approaches focus on detecting malicious flow rules but may face scalability challenges when the network undergoes frequent changes.Kataoka et al (2018) maintained a trust list of IoT stakeholders to verify device authenticity, but relying on a central Trust List may present limitations.
In recent times, the utilization of blockchain technology has gained significant attention as an effective means to enhance the security of SDN networks and protect against flow modification attacks.Numerous scholars have explored the benefits of blockchain technology as a means to improve the security of SDN networks.Boukria et al (2019) proposed a blockchain-based trusted node acting as a firewall to retrieve flow information from forwarding elements and validate flow rules, but it lacks the validation of malicious flow rules.Sharma et al (2017) introduced DistBlockNet, which employs a distributed Blockchain network and a version number mechanism on flow tables to verify any changes made.However, this approach may suffer from high flow table update times if the response node has a low version.Bose et al (2019) introduced BlockSDSec, a virtual controller-based approach that detects malicious flows on forwarding elements by communicating with a blockchain network.Hu et al (2020) used Blockchain-as-a-Service FTISCON (BaaS) to verify and insert flow rules on OpenFlow switches, primarily focusing on implementing a reward scheme for the verifier.
Weichen et al ( 2021) addressed the problem with a different approach by introducing a voting scheme to check whether the flow rule has been tampered with.Krishnamohan et al (2020) introduced BlockFlow and used the concept of switch version number to detect changes in the forwarding rules.However, their method is not economically well suited for a large network as the transaction cost will be higher due to the re-installation of flow rules.
We present a summary of the literature review in Table 1 regarding the blockchain network used, the deployed domain, and its limitations.In summary, many works have been proposed in the literature using different approaches.However, these solutions possess a few pitfalls to satisfy the performance requirements for SDN applications.These solutions further lack preventive measures after the detection of the attack and deployment of the actual SDN platform.Therefore, in this work, we try to address these limitations by adopting blockchain to prevent the malicious manipulation of flow rules by attackers and taking preventive measures to eradicate the attack.This paper presents a new scheme to address these issues by integrating blockchain Smart Contracts with SDN to verify malicious flows before installing them on the forwarding devices through the Blockchain Agent.Then, we compare the effectiveness of our work with two existing works, BlockFlow Krishnamohan et al (2020) and BlockSDSec Bose et al (2019) that are closer to our work.

Proposed Technique
In this article, we propose a technique that utilized the blockchain smart contract to preserve the integrity of flow rules in the SDN network.The flow rules are stored on the blockchain.A blockchain agent is introduced to perform the verification of flow rules through the decentralized blockchain network.Finally, a detailed performance analysis is carried out in a private blockchain network.A detailed description of the proposed technique is given below.

Architecture
The architecture of the proposed model consists of the following modules-SDN Controller, Blockchain Network, a Smart Contract (SC) and a Blockchain Agent as depicted in Figure 4. We briefly explain each module belowa) SDN Controller: The SDN controller maintains the topology information, forwarding rules from a central point.The controller can dynamically adjust the network's routing policies as the network changes.The controller also communicates with the Blockchain node to store the flow information through the WEB3 API.b) Blockchain Network: The Blockchain network consists of multiple peer-to-peer nodes which participate in the consensus for verification of OpenFlow rules.The number of Blockchain nodes depends upon the application type.The more the number of Blockchain nodes, the better the

Smart Contract Design
A smart contract is a program that automatically executes a task when predefined conditions are triggered on the blockchain.The main objective of SC is to simplify and automate the operations of flow rule verification without the need for a centralized third party.All parties can perform the transaction in a trustless manner, solely depending on the digital contract.The data stored on the blockchain is shared between the validators to provide total transparency of the transactions to all parties.We maintain two structures for storing the topology and flow rule information.The SC allows the creation and updates operation on the blockchain for both topology and flow tables through the SC functions.
The switch structure consists of the following fields in the SCswitch id, switch name, and flows.The flow rule structure has the following fieldsswitch id, flow id, src mac, dst mac, protocol, inport, outport, and priority.
The different functions available in the SC are discussed below: a) addSwitches: This function is invoked by the SDN controller as soon as a new switch joins the network.It stores the dpid of the switch on the blockchain.Algorithm 1 represents the steps required for switch registration in the blockchain.Switches register themselves by providing datapath id and transaction timestamps.b) addRule: As the user tries to communicate over the network, the controller identifies the route to the destination in the form of OpenFlow rules.This function is invoked by the SDN controller to store a new flow rule on the blockchain.c) verifyRule: The blockchain agent invokes this function to verify the forwarding rules.Upon receiving this function call, the blockchain peers perform the consensus to validate the transaction.Then, it performs the similarity of the hashes with the flow information received from the agent and already stored hash.If it matches the hash value, then the flow verification is successful; otherwise, an event is generated by the SC to remove the flow from the switch.

System Initialization
Let S = {s 1 , s 2 , ..., s m } be the set of switches in the SDN network where each s i consists of the dpid that is used to specify the switch is being modified.
Let the set of all transactions be denoted as T = {tn 1 , tn 2 , ..., tn m }, where each transaction tn i takes place between the SDN and blockchain network.Since the flow rules are a combination of match and action fields, let us denote M (tn i ) as the set of match fields in transaction tn i .
M (tn i ) = {m 1 , m 2 , ..., m n } where each m i = {src, dst, p, inport}.We have used these four match fields to match the packet.However, we can also use the remaining fields to match the packet.Similarly, let A(tn i ) = .., f n } be the set of existing flow rules in the network, where f i is the set of match field m i and action field a i i.e. f = {(m 1 , a 1 ), (m 2 , a 2 ), ..., (m n , a n )}.
The transaction between SDN and Blockchain can occur in three scenarios: i) During the network components registration ii) During the addition of new flow rules and iii) During the verification of flow rules.The transaction formulation for each scenario is described in the following subsection.

Network Component Registration
The SDN Controller and Blockchain Agent create their wallet address W c and W ba respectively.They register themselves on the SC using the tn(C) and tn(BA) respectively.Similarly, the SDN switch is added to the blockchain using the tn(s i ) transaction as per the algorithm 1.The transactions are given below:

FTISCON
The transaction tn(C) and tn(BA) will run only once but tn(s i ) will run for each SDN switch in the network.The SC checks the duplication of the switch and then stores the s i in the SWList.

New Flow Rule Registration
Let f old be the existing flow rule on the blockchain and f new be the new flow rule that needs to be registered on the blockchain.Then, For the addition of a new flow rule on the blockchain, the BA sends the transaction as: ) When a new flow registration requests AddF low(tn(C)) is received by the blockchain, the SC verifies that the flow rule specified in f new does not conflict with existing flow rules in the network.Therefore, the transaction tn(C) is broadcasted to the network and is verified by the smart contract.If the transaction is valid, the new flow rule is added to the flow table of the specified switch, and the updated state of the flow table is recorded on the blockchain.
Flow rule f old and f new are in conflict when the match field of both flows overlap but actions specified by the two rules are different.We can express this condition as: a old ̸ = a new (6) The condition in equation 5 signifies that there is a potential conflict between f old and f new .Equation 6 signifies that the action specified by the two rules is ambiguous.Therefore, if the above two conditions are satisfied then the f new will not be added to the blockchain (f old and f new are in conflict).

Verification Transaction
The BA sends the request V erif yF low(tn(BA)) to the blockchain for each flow present on the SDN switch to preserve the integrity and avoid any potential flow modification attack.The transaction for verification request is expressed as: The SC receives tn new (BA) containing match (m new ) and action (a new ) for the verification.It then compares these fields with the transaction history (tn old ) associated with the flow rule to determine if there is a similar flow rule already in the blockchain ledger.The conditions are expressed as: Equation 8 signifies that the match field in both m old and m new are the same and equation 9 signifies that both the outport value is equivalent.If such a transaction exists, the function returns true, indicating that the f new is similar to an f old .If no such transaction exists, the function returns false.
end if 8: end if 9: return status

Flow Rule Verification in FTISCON
Initially, flow rules for each SDN switch will be stored in the blockchain for each flow request using the algorithm 2. In the meantime, the Blockchain end if 10: end if 11: return status Agent periodically collects the flow rules from the switches.For every new PACKET IN message, the controller will send a copy of the Blockchain network.The algorithm 3 is executed through a Blockchain Network.Therefore, proof-of-correctness is done through the Consensus algorithm (Proof-of-Work in our case).The Blockchain nodes reach an agreement by following the consensus algorithm.Once the consensus is successful among the nodes, a new block is added to the chain containing flow rule information.Subsequently, the controller will send add flow command to the OpenFlow switch.The Agent then calls SC function verif yF low(F ) to check the similarity between the flows installed on the switch and Blockchain.If flow verification fails due to a flow modification attack, the SC will automatically emit an event to remove flow from the switch.Figure 5 illustrates the sequence diagram of message exchange between nodes.
In the following steps, we elaborate on the process of flow rule verification in detail: positive response is sent back to the BA (This is denoted with the green line in Figure 5).h) The modified flow information is sent to the SDN controller attack for the new flow verification.i) The BA repeats the steps f and g.Once SC declares that F 1 is invalid, a negative response is sent back to the BA (Denoted with a red line).

Experimental Results
This section describes the experimental setup, smart contract analysis and evaluation based on the results obtained by the proposed technique.

Environment Setup
This subsection provides an overview of the simulation environment for both SDN and Blockchain networks.To simulate the SDN network we utilize the Mininet framework to create virtual switches and hosts which implement Open vSwitch as a software switch.A private Blockchain network is created using the Ethereum framework.We chose private blockchains because they are much faster, cheaper and have higher scalability.

FTISCON
The SDN network is managed by Ryu controller, a Python-based SDN controller.The controller makes the network discovery and stores the global overview of the entire network.A Python-based Blockchain Agent is implemented to communicate with the Blockchain network.
The corresponding wallet accounts are created to make transactions on the network.These Blockchain nodes can execute the functions present in the SC for which it requires Ethers in their account.We implemented the Smart Contract using the Solidity programming language and deployed it on the Blockchain network.

Smart Contract Deployment
In this subsection, we discuss the deployment of SC in remix IDE(A tool to develop, deploy and administer the SC on the browser) to visualize the transactions on the blockchain.Figure 6 depicts the execution of the addRules() function in a Smart Contract.The SDN controller sends a transaction to the Blockchain network as soon as it detects a new switch in the network.Then the Smart Contract executes the addRules() function and does the necessary authentication of the transaction.The Blockchain Agent verify the flow rules installed on the switch by calling the verif yRule() function on the Smart Contract.Figure 7 depicts the successful verification of flow rules.We modify the output port of flow id one to three, then call the verif yF low() function.Figure 8 shows that the Smart Contract successfully detect the malicious flow modification.

Performance Evaluation
In this subsection, we present the performance evaluation of the FTISCON in terms of Detection Rate, Execution Time, Delay and Transaction Cost incurred due to the execution of SC functions.We have implemented the BlockFlow and BlockSDSec method and used the same configuration to compare the performances.We perform the experiment for ten iterations for each analysis and plot the average result.To test the performance of FTISCON, we deploy our SC on the Ethereum Virtual Machine (EVM) running on Windows 10 Pro Dell PC Intel(R) Xeon(R) W-2145 CPU, 3.70GHz 64GB RAM machine.In the next subsection, we discuss the analysis of the proposed method.

Detection Rate Analysis
We analyse the integrity of the proposed method by modifying the flow rules explicitly by using FLOW MOD command from the POSTMAN API which modifies the existing flow rules on the switches.A sample of flow modification code is depicted in Figure 9 in which the output port of the OpenFlow switch   is modified to 99.Moreover, the matching field can be made blank to modify the entire table on the switch.
To evaluate the accuracy of the attack detection rate we compare the number of real-time alert events generated in the SC for each flow verification transaction.Therefore, the attack detection rate of the FTISCON can be expressed as- We measure the detection rate of all three methods using the same Blockchain configuration.We tested two scenarios where the attacker manipulates the match fields and another scenario where the action field is manipulated.Table 4 shows that all three methods can detect the attack successfully in both cases and delete the flows from the switch.However, the time required to remove the flows from the switch in the BlockFlow method takes comparatively more time than our method.

Execution Time Analysis
We evaluate the system performance to find out the impact of the network size on the verification of flow rules on the blockchain.We scale up the number of OpenFlow rules up to 3000 to evaluate the time required for verification.Figure 10 shows the results.
For a very small number of flows, all three schemes take about the same amount of time.But as the number of flows grows, the time taken by FTISCON tends to taper down a bit, while for BlockFlow it continues to grow linearly.For BlockSDSec also the time taken remains close to that of BlockFlow.This is because the Controller has to delete the flow rules and re-install the entire rule set on the switch as soon as it detects a new switch version.The delay in this process makes these schemes slower.For a higher number of flows, FTISCON takes 52.36% and 48.62% less execution time compared to BlockFlow and BlockSDSec respectively.

Delay Analysis
The computational delay involved in the operations on the Blockchain is as follows: Where SD i is the time required for storing flow i on the blockchain, V D i is the verification delay of flow i and InstD i is the time required for installing flow i on the switch.We measure these delays during execution and compute the average delay for each of the schemes as shown in Table 4.

Transaction Cost Analysis
Another factor that needs to be analyzed in the Blockchain network is the transaction cost.We use the standard Gas Price set by Ethereum (i.e.21000 gwei) to make the transaction.The equation of transaction cost is expressed as: Transaction Cost = gas price × gas used (12) The Figure 12 shows the result of transaction costs incurred by various SC functions.The transaction cost for addRule() will vary as per the number of flow rules.However, only mere reading of Blockchain data will not cost gas.Therefore, the methods verifyFlow() will not cost any fee.We plot the result of transaction cost with an increasing number of flows in Figure 11.From the figure, we observe that BlockFlow and BlockSDSec consume more gas compared to the proposed method.As we increase the no. of flows the transaction cost also increases linearly.

CPU Overhead on SDN Controller
The attacker often sends a large number of flow modification packets to overwhelm the SDN controller thereby causing it to crash or become unresponsive.The CPU overload may arise on the SDN controller due to a large number   Therefore, we perform an analysis of the CPU consumption of an SDN controller to identify if the controller is under heavy load and potentially being targeted by a flow modification attack.We perform a Flow Mod attack on the OpenFlow switch by injecting a synthetic flow modification attack at a different rate.We start at 100 Flow Mod/second and the CPU consumption remains stable, as the Controller can handle the traffic using its available processing resources (See Figure 13).However, after a certain point (around 500-600 packets/second), the CPU consumption starts to increase more rapidly with each incremental increase in packet IN rate.This is because the controller is required to process more and more packets.Finally, at around 1500 packets/second, the CPU consumption reaches its saturation point where it cannot process any more packets.The graph for CPU consumption shows a curve that initially steps upward slowly, then steepens as the packet IN rate increases.

Security Analysis
In this section, we briefly discuss the security analysis based on authenticity, integrity and resiliency against single-point-of-failure. a) Authenticity: The clients need to authenticate with their public-private key pairs to communicate with the Smart Contract and participate in the verification/consensus process.Thus any unauthorised client cannot access the SC functions to tamper with the data.b) Integrity: The flow information is stored on the blockchain using some hashing algorithm.Once a particular block is altered the hash of the block changes.This makes the remaining block invalid.Therefore, blockchain can preserve the integrity of the flow rules.c) Resiliency: The decentralised nature of the peer-to-peer networks increases the system's robustness.As more and more nodes participate in the consensus mechanism, the likelihood of failure decreases.Therefore, the fate of the data is not controlled by a single person, group or organization.The attack from a malicious node cannot disrupt the network entirely because the remaining nodes in the blockchain network will keep running the consensus process.

Complexity Analysis
In this subsection, we discuss the time and space complexity of the proposed scheme.The complexity of the FCISCON mainly depends on the number of flow rules present on the SDN switch because these flows are to be stored and verified.The time complexity for different operations is discussed below: a) Flow Registration: During the registration of f new , the SC first checks for flow conflict.So, it needs to iterate throughout all the existing flow rules (f old ).However, the proposed method utilizes the dictionary (key-value pair) structure to store the flow rules on the blockchain.The hashed value for the f new is stored as the key during the flow storage on the blockchain.Therefore, the overall time for a f new registration operation is O(1) + O(consensus).The time complexity of the consensus algorithm is difficult to express as it depends on several factors such as the computational power of the network, the difficulty level set for the mathematical puzzle and the rate of block creation.b) Flow Verification: For the verification of f new , the SC generate the hash(f new ) before iterating on the dictionary for similarity check.Then the hashed value is then compared with the hashed of f old dictionary.Therefore, the time complexity for verification of f new is O(1).We also compared the time required for the registration and verification process of a new flow rule in BlockSDSec, BlockFlow and our proposed method (see Table 5).The comparison table shows that the existing methods iterate through all the previous transactions before registering the flow on the blockchain.Similarly, during the verification, the existing methods perform the matching operation with the existing flow rules.Therefore, the proposed work is better in terms of time complexity when compared to existing methods for similar tasks.

Discussion
In this subsection, we discuss the security and effectiveness of FTISCON.The related study work shows that the SDN network cannot guarantee the complete integrity and privacy of OpenFlow rules.Some of the works in the literature use Blockchain Technology to prevent the flow rule modification attack.The adversary may install false flow rules or modify the existing flow rules present in the switches.In this work, we have proposed a method to prevent the flow rule modification attack using Blockchain Technology in which flow rules are stored on the Blockchain and verified by the Blockchain Agent.
The Blockchain Agent acts as a trusted node that communicates with the Blockchain nodes and collects flow rules from the switches.In the design of our model, we keep the SDN controller and Blockchain Agent separate from each other.This is to protect the verification process from eventual attacks on the SDN controller.The FTISCON will be able to survive even if the controller goes offline.Furthermore, the communication overhead on the controller will be less as the verification process is handled by the Blockchain Agent.This is one of the advantages of our model.However, if the Blockchain Agent is compromised, the controller will not be able to do the verification.
Blockchain Technology offers immutability, transparency and integrity of the data through Smart Contract automation.The changes made to the EVM state will be recorded in the transaction history.Therefore, it makes it easier for the system to track down the adversary and isolate the compromised part of the network.However, the difficulty of making changes in the functionality of SCs are issue Peng et al (2021).If any error or loophole occurs in the run-time, it is almost impossible or expensive to correct.
The performance analysis result shows that FTISCON is significantly better in terms of execution time and transaction cost.This is due to the separation of Controller and Agent.The experimental result shows that FTISCON possesses a reduction in execution time as one of our primary objectives.However, the SDN controller has to look if any duplicate flows are being stored on the blockchain and this is done to reduce the unnecessary filling up of Blockchain storage as well as to reduce transaction cost.Thus making it economically acceptable in the real scenario.On the other hand, the BlockFlow Krishnamohan et al (2020) needs to invoke deleteRule() function multiple times.This causes the model to pay more gas fees to make these transactions.
The proposed method is deployed and tested in a Private local Blockchain network to make the transaction processing faster.However, there are various other methods of deployment and testing available such as Testnet, and Mainnet.
The current Ethereum 1.0 platform uses heavyweight Ethash PoW as a consensus algorithm.Since PoW is based on the ability to compute hashes per second, it becomes slow with the increasing complexity level.However, the development of Ethereum 2.0 will make it faster as it will implement the Proof-of-Stake to validate the transactions where it replaces the miners with validators.Ethereum 2.0 distributes the transaction data within the Ethereum network which increases the throughput of the network substantially.

Conclusion
In this work, we presented FTISCON, a scheme to protect flow rule modification attacks on OpenFlow switches in SDN using blockchain and incorporating an SC implementation for flow rule verification.A proof-of-concept implementation of the scheme is carried out using Ethereum private blockchain.Informal analysis based on the attack detection and experimental studies on running time and transaction cost is presented that validate the potential of FTISCON.The Performance analysis shows that the proposed method can significantly reduce the execution time, transaction cost and delay incurred due to the flow verification compared to BlockFlow and BlockSDSec.
In the future, smart contract design for SDN flow rule verification could be enhanced by incorporating machine learning techniques.For example, machine learning algorithms could be used to predict the potential impact of a flow rule on network traffic.

FTISCON Algorithm 3
Flow Rule VerificationInput: Datapath ID dpid, New flow rule to be added f new , Controller and Blockchain Agent wallet address W c , W ba1: Set status ← False 2: Compute h = sha256(abiencode(f new , W c , W ba )) 3: if dpid ∈ SWList && W ba ∈ Agent Addr then

Fig. 5 :
Fig. 5: Sequence diagram of exchange messages for flow rule verification.

Fig. 9 :
Fig. 9: A sample of synthetic flow modification attack generated from POSTMAN API.

Fig. 10 :
Fig. 10: Execution time comparison with respect to the number of Flows.

Fig. 11 :
Fig. 11: Gas Consumption comparison with respect to the number of Flows.

FTISCONFig. 13 :
Fig. 13: Overhead on Controller CPU with an increasing number of Flow Mod packets.

Table 2 :
Notation Table {a 1 , a 2 , ..., a n } be the action field specified in transaction tn i where each Algorithm 1 OpenFlow Switch Registration Input: Datapath ID dpid, Registration timestamp ts, Switch List in the Smart Contract SWList 1: Set status ← False 2: SC will check (dpid, ts) 3: if dpid ∈ SWList then Datapath ID dpid, New flow rule to be added f new , Controller and Blockchain Agent wallet address W c , W ba 1: Set status ← False 2

Table 3 :
Experimental Setup Table

Table 4 :
Detection and Delay Comparison Table

Table 5 :
Time complexity comparison table