Preserving Flow Table Integrity in OpenFlow

Networks through Smart Contract

Birglang Bargayary (  [email protected] )
Tezpur University
Nabajyoti Medhi
Tezpur University

Research Article

Keywords: Blockchain, Flow Table Integrity, FTISCON, OpenFlow, Software-De ned Networking

Posted Date: August 18th, 2023

DOI: https://doi.org/10.21203/rs.3.rs-3254673/v1

License:   This work is licensed under a Creative Commons Attribution 4.0 International License.
Read Full License

Additional Declarations: No competing interests reported.

Preserving Flow Table Integrity in OpenFlow
Networks through Smart Contract
Birglang Bargayary1,1* and Nabajyoti Medhi1,1†
1,2* Department of Computer Science and Engineering, Tezpur
University, Napaam, Sonitpur, 784028, Assam, India.

*Corresponding author(s). E-mail(s): [email protected];

Contributing authors: [email protected];
† These authors contributed equally to this work.

Abstract
SDN revolutionises network management by providing a centralised con-
troller that enables flexible and effortless configuration of networks.
However, this flexibility also leads to a vulnerability that enables the
adversary to trick the security system into allowing the installation
of unauthorised flow rules in the switches. Blockchain provides us
with a way to protect against malicious tampering with flow 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 flow 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 exist-
ing 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 offers a practical and efficient
remedy to prevent flow modification attacks within SDN networks.

Keywords: Blockchain, Flow Table Integrity, FTISCON, OpenFlow,

Software-Defined Networking

1
2 FTISCON

1 Introduction
In today’s interconnected world, computer networks have become indispens-
able, serving a critical role in facilitating communication and information
exchange across the Internet. However, the lack of programmability and flexi-
bility 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 net-
work 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 multi-
ple 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 communi-
cate 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 applica-
tions, leading to the installation of malicious flow rules on OpenFlow switches.
Moreover, the attacker can exploit vulnerabilities in the control plane to mod-
ify 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. There-
fore, 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 net-
works. Blockchain is a Distributed Ledger Technology (DLT) with characteris-
tics 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
 FTISCON 3

Fig. 1: Software-Defined Networking Architecture.

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 net-
work Khan et al (2021). The functions are executed when certain conditions
4 FTISCON

Fig. 2: Transaction Processing in Blockchain.

are met. Therefore, it is useful for automating the verification of flow rules
on the blockchain without the need for intervention. Furthermore, the decen-
tralised architecture of blockchain technology makes it suitable for the integrity
of SDN flow tables. The immutable nature of blockchain prevents the mali-
cious 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 modi-
fication 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 mecha-
nisms 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
 FTISCON 5

the experimental result analysis and discussion of the results. The concluding
remarks and future directions are presented in Section 5.

2 Related Work
2.1 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 speci-
fies 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 determin-
ing 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 pack-
ets 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.

2.2 Blockchain and SDN

The integration of SDN has brought tremendous improvements to the tra-
ditional 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
6 FTISCON

Fig. 3: OpenFlow 1.3 format of flow rules.

architecture that supports data immutability. The data or transaction is broad-

casted 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.

Table 1: Summary of Blockchain Based Flow Table Integrity mechanisms.

Solution Blockchain Network Deployed Domain

Sharma et al (2017) Private SDN-IoT network

Kataoka et al (2018) Public and Private SDN-IoT network
Boukria et al (2019) Private SDN network
Derhab et al (2019) Private SDN network
Bose et al (2019) Private SDN network
Rathore et al (2019) Private SDN-IoT network
Krishnamohan et al (2020) Private SDN network
Aujla et al (2020) Private SDN Smart City
Hu et al (2020) Private SDN-IoT network
Misra et al (2020b) Private SDN-IoT network
Weichen et al (2021) Private SDN network
Lahlou et al (2022) Private SDN-IoT network

2.3 Literature Review

Researchers have dedicated considerable effort to addressing the security chal-
lenges associated with the flow table on forwarding devices in Software-Defined
 FTISCON 7

Networking (SDN) Nisar et al (2020). Various studies have been conducted to

prevent flow modification attacks in SDN networks. This literature survey aims
to explore the existing work in this area and highlight the different approaches
proposed to mitigate flow table threats.
Researchers have also explored the utilization of Intrusion Detection Sys-
tems (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 envi-
ronment. 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 main-
taining 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 fre-
quent 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 sig-
nificant 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 communicat-
ing with a blockchain network. Hu et al (2020) used Blockchain-as-a-Service
8 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 per-
formance 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 limi-
tations 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.

3 Proposed Technique
In this article, we propose a technique that utilized the blockchain smart con-
tract 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.

3.1 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 below-
a) SDN Controller: The SDN controller maintains the topology informa-
tion, forwarding rules from a central point. The controller can dynamically
adjust the network’s routing policies as the network changes. The con-
troller 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 appli-
cation type. The more the number of Blockchain nodes, the better the
 FTISCON 9

Fig. 4: Proposed Blockchain-Enabled SDN flow security System Architecture.

security of the system. However, in the Ethereum Private Blockchain Net-

work, it is recommended to have a minimum bound of seven nodes as a
validator. This will allow up to two nodes to be either malicious or go
offline. Each Blockchain node on the network maintains a copy of the
blockchain ledger and participates in the consensus process. The nodes
validate the transactions by following the consensus algorithm such as
Proof-of-Work(PoW), Proof-of-Stake(PoS) etc. to create the next block.
c) Smart Contract: The role of smart contracts in the blockchain is to
enable trustless transactions and automated execution of contractual
agreements. They allow for the creation of secure, tamper-proof, and
transparent agreements between parties, which are executed automati-
cally when certain conditions are met. A single SC is used for the proposed
solution. It maintains the rules, topology information and logic for the
verification of flow rules. All the functionalities and business logic are
governed by the SC in a decentralized manner.
d) Blockchain Agent: The Blockchain Agent is a separate entity which is
responsible for collecting the flow rules from the OpenFlow switches and
forwarding them to the blockchain network to perform the verification
through SC. It is also responsible for removing flows from the switches
if found invalid by the blockchain. This module is kept separate from
the SDN controller to avoid Single-Point-of-Failure (SPOF). Even if the
controller fails, the Agent can do the verification of the flows.
10 FTISCON

3.2 Smart Contract Design

A smart contract is a program that automatically executes a task when prede-
fined 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 infor-
mation. 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 SC- switch id,
switch name, and flows. The flow rule structure has the following fields-
switch 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 reg-
istration 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 con-
troller 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 verifi-
cation is successful; otherwise, an event is generated by the SC to remove
the flow from the switch.

3.3 System Initialization

Let S = {s1 , s2 , ..., sm } be the set of switches in the SDN network where each
si consists of the dpid that is used to specify the switch is being modified.
Let the set of all transactions be denoted as T = {tn1 , tn2 , ..., tnm }, where
each transaction tni takes place between the SDN and blockchain network.
Since the flow rules are a combination of match and action fields, let us denote
M (tni ) as the set of match fields in transaction tni .
M (tni ) = {m1 , m2 , ..., mn } where each mi = {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(tni ) =
 FTISCON 11

Table 2: Notation Table

Symbol Definition

C SDN Controller
BA Blockchain Agent
Si OpenFlow enabled SDN switch
IPc IP address of SDN Controller
Wc Ethereum Wallet address of SDN Controller
Wba Ethereum Wallet address of Blockchain Agent
ts The time at which the transaction was initiated
src Source MAC
dst Destination MAC
inport Ingress port number
p Priority of the flow rule
dpidi Datapath ID of SDN Switch si
tn id Unique identifier for the transaction
drop Packet is blocked by the controller
outport Packet is transmitted through the given outport
normal Packet is transmitted as traditional Layer 2 convention
fold Flow rule already present on the blockchain
fnew New flow rule request for verification

{a1 , a2 , ..., an } be the action field specified in transaction tni where each
ai = {drop outport normal}.
Let F = {f1 , f2 , ..., fn } be the set of existing flow rules in the net-
work, where fi is the set of match field mi and action field ai i.e. f =
{(m1 , a1 ), (m2 , a2 ), ..., (mn , an )}.
The transaction between SDN and Blockchain can occur in three scenar-
ios: 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.

3.4 Transaction Formulation

3.4.1 Network Component Registration
The SDN Controller and Blockchain Agent create their wallet address Wc and
Wba 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(si ) transaction as per the algorithm 1. The transactions are given
below:

tn(C) = {tn id, Wc , IPc , ts} (1)

tn(BA) = {tn id, Wba , IPba , ts} (2)

tn(si ) = {tn id, Wc , IPc , dpidi , ts} ∀ si ∈ S (3)

12 FTISCON

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

3.4.2 New Flow Rule Registration

Let fold be the existing flow rule on the blockchain and fnew be the new flow
rule that needs to be registered on the blockchain. Then,

fold = {mold , aold } and fnew = {mnew , anew }

For the addition of a new flow rule on the blockchain, the BA sends the
transaction as:

tn(C) = {tn id, Wc , IPc , fnew , ts} (4)

When a new flow registration requests AddF low(tn(C)) is received by the
blockchain, the SC verifies that the flow rule specified in fnew 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 trans-
action 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 fold and fnew 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:

mold ∩ mnew ̸= ∅ (5)

aold ̸= anew (6)

The condition in equation 5 signifies that there is a potential conflict
between fold and fnew . Equation 6 signifies that the action specified by the two
rules is ambiguous. Therefore, if the above two conditions are satisfied then
the fnew will not be added to the blockchain (fold and fnew are in conflict).

3.4.3 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:

tnnew (BA) = {tn id, Wba , IPba , fnew , ts} (7)

The SC receives tnnew (BA) containing match (mnew ) and action (anew )
for the verification. It then compares these fields with the transaction history
(tnold ) associated with the flow rule to determine if there is a similar flow rule
already in the blockchain ledger. The conditions are expressed as:
 FTISCON 13

∃! mold ∈ tnold (8)

aold = anew (9)

Equation 8 signifies that the match field in both mold and mnew 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 fnew
is similar to an fold . If no such transaction exists, the function returns false.

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
4: return status
5: else
6: status ← True
7: return status
8: end if

Algorithm 2 Flow Rule Registration

Input: Datapath ID dpid, New flow rule to be added fnew , Controller and
Blockchain Agent wallet address Wc , Wba

1: Set status ← False

2: Compute h = sha256(abiencode(fnew , Wc , Wba ))
3: if dpid ∈ SWList then
4: if Rules[h] ̸= h then
5: Rules[h] ← fnew )
6: status ← True
7: end if
8: end if
9: return status

3.5 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
14 FTISCON

Algorithm 3 Flow Rule Verification

Input: Datapath ID dpid, New flow rule to be added fnew , Controller and
Blockchain Agent wallet address Wc , Wba

1: Set status ← False

2: Compute h = sha256(abiencode(fnew , Wc , Wba ))
3: if dpid ∈ SWList && Wba ∈ Agent Addr then
4: if Rules[h] = h then
5: status ← T rue
6: else
7: emit event Invalid()
8: return status
9: 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 net-
work. 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 con-
sensus 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:
a) Initially our Blockchain Agent collects the OpenFlow rules from the
switches in a certain time interval.
b) When a particular host requests a new flow for communication, the SDN
switch requests a new flow F1.
c) Simultaneously, the controller also transmits a duplicate of the flow rule
to the blockchain, creating a transaction.
d) This transaction is verified by the blockchain nodes and the corresponding
flow rule is stored in the blockchain.
e) Now the SDN Controller sends the flow rules for installation on the switch.
f) The Blockchain Agent initiates the VerifyFlow(F1) on the Blockchain
network.
g) The SC checks for the similarity between the received flow F1 and the
flow present on the blockchain. Once the flow is successfully verified, a
 FTISCON 15

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

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).

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

4.1 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.
16 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 imple-
mented 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.

Table 3: Experimental Setup Table

SDN Network
Content Name Version Quantity
Controller Ryu 4.34 1
South Bound API OpenFlow 1.3 -
North Bound API POSTMAN v9.4 -
Switch OpenVSwitch 2.16.x 5
End Host Ubuntu 18.04 LTS 2
Blockchain Network
Smart Contract Solidity 0.4.22 1
Nodes Geth v1.11.4 5
Consensus PoW - -

4.2 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 trans-
actions 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 call-
ing 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.

4.3 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.
 FTISCON 17

Fig. 6: The execution of addRules() function in Smart Contract.

Fig. 7: The execution of valid verifyRule() function in Smart Contract.

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.

4.3.1 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
18 FTISCON

Fig. 8: The execution of invalid verifyRule() function in Smart Contract.

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

POSTMAN API.

is modified to 99. Moreover, the matching field can be made blank to modify
the entire table on the switch.
 FTISCON 19

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 verifica-
tion transaction. Therefore, the attack detection rate of the FTISCON can be
expressed as-
No. of Alert Event in SC
DR = × 100 % (10)
No. of FLOW MOD
We measure the detection rate of all three methods using the same
Blockchain configuration. We tested two scenarios where the attacker manip-
ulates the match fields and another scenario where the action field is
manipulated. Table 4 shows that all three methods can detect the attack suc-
cessfully 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.

4.3.2 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.

4.3.3 Delay Analysis

The computational delay involved in the operations on the Blockchain is as
follows:

D = SDi + VDi + InstDi (11)

Where SDi is the time required for storing flow i on the blockchain, V Di
is the verification delay of flow i and InstDi 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.

4.3.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.
20 FTISCON

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

Table 4: Detection and Delay Comparison Table

Detection rate(%) Delay (sec)
Methods
max min avg
FTISCON 100 0.09 0.02 0.04
BlockFlow 100 1.75 0.52 1.09
BlockSDSec 100 1.56 0.36 0.94

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.

4.3.5 CPU Overhead on SDN Controller

The attacker often sends a large number of flow modification packets to over-
whelm 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
 FTISCON 21

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

Fig. 12: Gas Consumption comparison for different SC functions.

of flows entering the network in a short period of time. Then the SDN con-
troller will experience a high CPU overhead due to the need to process a large
number of flow updates.
22 FTISCON

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

Therefore, we perform an analysis of the CPU consumption of an SDN con-

troller 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 differ-
ent rate. We start at 100 Flow Mod/second and the CPU consumption remains
stable, as the Controller can handle the traffic using its available process-
ing 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 packet-
s/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.

4.4 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
 FTISCON 23

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 orga-
nization. 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.

4.5 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 fnew , the SC first checks for
flow conflict. So, it needs to iterate throughout all the existing flow rules
(fold ). However, the proposed method utilizes the dictionary (key-value
pair) structure to store the flow rules on the blockchain. The hashed value
for the fnew is stored as the key during the flow storage on the blockchain.
Therefore, the overall time for a fnew 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 fnew , the SC generate the
hash(fnew ) before iterating on the dictionary for similarity check. Then
the hashed value is then compared with the hashed of fold dictionary.
Therefore, the time complexity for verification of fnew is O(1).

Table 5: Time complexity comparison table

Solution Registration Verification
BlockSDSec Bose et al (2019) O(fold ) O(fold ) + O(consensus)
BlockFlow Krishnamohan et al (2020) O(fold ) O(2fold ) + O(consensus)
FTISCON O(1) O(1) + O(consensus)

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 iter-
ate 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.
24 FTISCON

4.6 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 sepa-
ration of Controller and Agent. The experimental result shows that FTISCON
possesses a reduction in execution time as one of our primary objectives. How-
ever, 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 eco-
nomically 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 vari-
ous 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
 FTISCON 25

validators. Ethereum 2.0 distributes the transaction data within the Ethereum
network which increases the throughput of the network substantially.

5 Conclusion
In this work, we presented FTISCON, a scheme to protect flow rule modifica-
tion attacks on OpenFlow switches in SDN using blockchain and incorporating
an SC implementation for flow rule verification. A proof-of-concept implemen-
tation 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.

Acknowledgement
The authors would like to thank the anonymous referees for their constructive
criticism and valuable suggestions. This work is funded by the Ministry of
Electronics and Information Technology, India with project no. 13(15)/2020-
CC&BT dated 21.07.2020

References
Alsaeedi M, Mohamad MM, Al-Roubaiey AA (2019) Toward adaptive and scal-
able openflow-sdn flow control: A survey. IEEE Access 7:107,346–107,379.
https://doi.org/10.1109/ACCESS.2019.2932422

Aujla GS, Singh M, Bose A, et al (2020) Blocksdn: Blockchain-as-a-service

for software defined networking in smart city applications. IEEE Network
34(2):83–91. https://doi.org/10.1109/MNET.001.1900151

Barka E, Dahmane S, Kerrache CA, et al (2021) Sthm: A secured and trusted

healthcare monitoring architecture using sdn and blockchain. Electronics
10(15). https://doi.org/10.3390/electronics10151787

Bose A, Aujla GS, Singh M, et al (2019) Blockchain as a service for software

defined networks: A denial of service attack perspective. In: 2019 IEEE Intl
Conf on Dependable, Autonomic and Secure Computing, pp 901–906, https:
//doi.org/10.1109/DASC/PiCom/CBDCom/CyberSciTech.2019.00166
26 FTISCON

Boukria S, Guerroumi M, Romdhani I (2019) Bcfr: Blockchain-based con-

troller against false flow rule injection in sdn. In: 2019 IEEE Symposium on
Computers and Communications (ISCC), pp 1034–1039, https://doi.org/10.
1109/ISCC47284.2019.8969780

Derhab A, Guerroumi M, Maglaras L, et al (2019) Bloster: Blockchain-based

system for detection of fraudulent rules in software-defined networks. In:
6th International Symposium for ICS and SCADA Cyber Security Research
2019 (ICS-CSR), https://doi.org/10.14236/ewic/icscsr19.5

Ferrag MA, Derdour M, Mukherjee M, et al (2019) Blockchain technologies

for the internet of things: Research issues and challenges. IEEE Inter-
net of Things Journal 6(2):2188–2204. https://doi.org/10.1109/JIOT.2018.
2882794

Ghiro L, Restuccia F, D’Oro S, et al (2021) A blockchain definition to clarify its

role for the internet of things. In: 2021 19th Mediterranean Communication
and Computer Networking Conference (MedComNet), pp 1–8, https://doi.
org/10.1109/MedComNet52149.2021.9501280

Giotis K, Argyropoulos C, Androulidakis G, et al (2014) Combining openflow

and sflow for an effective and scalable anomaly detection and mitigation
mechanism on sdn environments. Computer Networks 62:122–136. https:
//doi.org/https://doi.org/10.1016/j.bjp.2013.10.014

Hu J, Reed M, Al-Naday M, et al (2020) Blockchain-aided flow insertion and

verification in software defined networks. 2020 Global Internet of Things
Summit, GIoTS 2020

Kataoka K, Gangwar S, Podili P (2018) Trust list: Internet-wide and dis-

tributed iot traffic management using blockchain and sdn. In: 2018 IEEE
4th World Forum on Internet of Things (WF-IoT), pp 296–301, https:
//doi.org/10.1109/WF-IoT.2018.8355139

Khan SN, Loukil F, Ghedira-Guegan C, et al (2021) Blockchain smart

contracts: Applications, challenges, and future trends. Peer-to-Peer
Networking and Applications 14(5):2901–2925. https://doi.org/10.1007/
s12083-021-01127-0

Khurshid A, Zhou W, Caesar M, et al (2012) Veriflow: Verifying network-wide

invariants in real time. In: Proceedings of the First Workshop on Hot Topics
in Software Defined Networks. Association for Computing Machinery, New
York, NY, USA, HotSDN ’12, p 49–54, https://doi.org/10.1145/2342441.
2342452

Klöti R, Kotronis V, Smith P (2013) Openflow: A security analysis. In: 2013

21st IEEE International Conference on Network Protocols (ICNP), pp 1–6,
 FTISCON 27

https://doi.org/10.1109/ICNP.2013.6733671

Kreutz D, Ramos FMV, Verı́ssimo PE, et al (2015) Software-defined net-

working: A comprehensive survey. Proceedings of the IEEE 103(1):14–76.
https://doi.org/10.1109/JPROC.2014.2371999

Krishnamohan T, Kugathasan J, P.R.L.C P, et al (2020) Blockflow: A decen-

tralized sdn controller using blockchain. International Journal of Scientific
and Research Publications (IJSRP) 10:p9991. https://doi.org/10.29322/
IJSRP.10.03.2020.p9991

Krishnan P, Jain K, Achuthan K, et al (2022) Software-defined security-by-

contract for blockchain-enabled mud-aware industrial iot edge networks.
IEEE Transactions on Industrial Informatics 18(10):7068–7076. https://doi.
org/10.1109/TII.2021.3084341

Lahlou S, Moukafih Y, Sebbar A, et al (2022) Td-ra policy-enforcement

framework for an sdn-based iot architecture. Journal of Network and Com-
puter Applications 204:103,390. https://doi.org/https://doi.org/10.1016/j.
jnca.2022.103390

Li C, Qin Z, Novak E, et al (2017) Securing sdn infrastructure of iot–fog

networks from mitm attacks. IEEE Internet of Things Journal 4(5):1156–
1164. https://doi.org/10.1109/JIOT.2017.2685596

Misra S, Deb PK, Pathak N, et al (2020a) Blockchain-enabled sdn

for securing fog-based resource-constrained iot. In: IEEE INFO-
COM 2020 - IEEE Conference on Computer Communications Work-
shops (INFOCOM WKSHPS), pp 490–495, https://doi.org/10.1109/
INFOCOMWKSHPS50562.2020.9162706

Misra S, Deb PK, Pathak N, et al (2020b) Blockchain-enabled sdn

for securing fog-based resource-constrained iot. In: IEEE INFO-
COM 2020 - IEEE Conference on Computer Communications Work-
shops (INFOCOM WKSHPS), pp 490–495, https://doi.org/10.1109/
INFOCOMWKSHPS50562.2020.9162706

Monshizadeh M, Khatri V, Kantola R (2017) Detection as a service: An sdn

application. In: 2017 19th International Conference on Advanced Communi-
cation Technology (ICACT), pp 285–290, https://doi.org/10.23919/ICACT.
2017.7890099

Nisar K, Jimson ER, Hijazi MHA, et al (2020) A survey on the architecture,

application, and security of software defined networking: Challenges and
open issues. Internet of Things 12:100,289. https://doi.org/https://doi.org/
10.1016/j.iot.2020.100289
28 FTISCON

Peng K, Li M, Huang H, et al (2021) Security challenges and opportunities

for smart contracts in internet of things: A survey. IEEE Internet of Things
Journal 8(15):12,004–12,020. https://doi.org/10.1109/JIOT.2021.3074544

Qiu X, Zhang K, Ren Q (2017) Global flow table: A convincing mechanism for
security operations in sdn. Computer Networks 120:56–70. https://doi.org/
https://doi.org/10.1016/j.comnet.2017.04.002

Rathore S, Wook Kwon B, Park JH (2019) Blockseciotnet: Blockchain-based

decentralized security architecture for iot network. Journal of Network
and Computer Applications 143:167–177. https://doi.org/https://doi.org/
10.1016/j.jnca.2019.06.019

Roy C, Saha R, Misra S, et al (2021) Soft-health: Software-defined fog archi-

tecture for iot applications in healthcare. IEEE Internet of Things Journal
pp 1–1. https://doi.org/10.1109/JIOT.2021.3097554

Sasaki T, Pappas C, Lee T, et al (2016) Sdnsec: Forwarding accountability for

the sdn data plane. In: 2016 25th International Conference on Computer
Communication and Networks (ICCCN), pp 1–10, https://doi.org/10.1109/
ICCCN.2016.7568569

Sharma PK, Singh S, Jeong Y, et al (2017) Distblocknet: A distributed

blockchains-based secure sdn architecture for iot networks. IEEE Com-
munications Magazine 55(9):78–85. https://doi.org/10.1109/MCOM.2017.
1700041

Wang KIK, Zhou X, Liang W, et al (2022) Federated transfer learning based

cross-domain prediction for smart manufacturing. IEEE Transactions on
Industrial Informatics 18(6):4088–4096. https://doi.org/10.1109/TII.2021.
3088057

Weichen L, Zhaobin L, Chao G, et al (2021) Frchain: A blockchain-based flow-

rules-oriented data forwarding security scheme in sdn. KSII Transactions on
Internet and Information Systems 15(1):264–284. https://doi.org/10.3837/
tiis.2021.01.015

Yazdinejad A, Parizi RM, Dehghantanha A, et al (2020) An energy-efficient

sdn controller architecture for iot networks with blockchain-based security.
IEEE Transactions on Services Computing 13(4):625–638. https://doi.org/
10.1109/TSC.2020.2966970