2020 Second International Conference on Blockchain Computing and Applications (BCCA)

DPSec: A blockchain-based data plane

authentication protocol for SDNs
Majd Latah*1 , Kübra Kalkan*2
*Department of Computer Science
Özyeğin University
İstanbul, Turkey
majd.latah@ozu.edu.tr1 , kubra.kalkan@ozyegin.edu.tr2

Abstract—Software-Defined Networking (SDN) is a promising
networking architecture that enables central management along
with network programmability. However, SDN brings additional
security threats due to untrusted control and data planes. In
this work, we focus on authenticating SDN’s data plane since
it can be exploited to attack SDN’s control plane. As a result,
the whole SDN network will be paralysed. On the other hand,
Blockchain (BC) can be utilized to provide more secure data
plane by introducing a fault-tolerant, decentralized and secure
ledger without relying on any trusted third-party intermediaries.
To this end, in this work we propose, DPSec, a consortium BC-
based protocol for authenticating SDN’s data plane including
SDN switches and hosts. We also provide a proof-of-concept that
demonstrates the applicability and feasibility of our protocol in
SDNs. Finally, we present a security analysis that shows how
DPSec can address several attacks against SDNs including CVE-
2018-1000155 vulnerability [1] that targets SDN controllers due
to the untrusted data plane.
Index Terms—Software-defined networking (SDN), blockchain
(BC), network security.
I. I NTRODUCTION
SDN is considered as a promising paradigm to attain more
dynamic control and more flexible management compared
with traditional networking architecture. Recently, SDN has
gained increasing popularity, thanks to its elastic architecture
that separates the control plane from the data plane. SDN
has introduced the concept of central management achieved
by the SDN controller, which programmatically defines flow-
based forwarding rules. However, the lack of trust among SDN
components has introduced several security threats at different
layers including -application, -control and -data planes [2],
[3]. The situation may be even worse when such an unsecure
architecture is integrated into other larger systems [4].
Unfortunately, these threats have negative ramifications on
current and future adoption of SDN in many scenarios [5]. For
instance, intruders can launch massive DoS attacks against
SDN controllers. As a result, the controller may no longer
respond to normal networking events [6]. Furthermore, intrud-
ers may even deploy rogue switches/controllers to spoof the
corresponding control and data planes, respectively, in order
to be engaged in unauthorized activities. Moreover, flow tables
can be easily modified and ultimately this will result in firewall
rule conflicts [7]. As a result, there is a need to provide
authentication mechanisms for both SDN’s control and data
planes. Our work focuses on authenticating SDN’s data plane
since it can be deliberately used to paralyze the network brain
(i.e., the SDN controller).
BC can fundamentally eliminate the limitations of SDN in
terms of security and reliability by its unique characteristics.
This is due to the fact that BC empowers a decentralized,
distributed, immutable ledger that provides trustworthy ser-
vices on peer to peer basis without relying on third-party
intermediaries [8], which may probably belong to multiple
network and service operators [9]. The decentralized ledger
is updated through consensus among all BC peers to ensure
its completeness, consistency, and fault-tolerant properties [6].
Generally speaking, there are three types of BC, namely
public, private and consortium (semi-private) BCs. In public
BCs, everyone can join the block creation process whereas
in private and consortium BCs only specific nodes can par-
ticipate, based on a specific access control mechanism [8].
Consortium BCs provide a better decentralization than private
ones, since they consist of more than one organization. If we
want to utilize BC to secure SDN, each organization can be
seen as an SDN domain managed by an SDN controller. On
the other hand, BC provides the concept of smart contract,
which contains a set of rules and functionalities under which
the parties involved in BC agree to autonomously interact and
collaborate without any involvement of intermediate parties
[10]. In this work, we show how BC can be utilized to provide
a fault-tolerant, decentralized and secure authentication of
data plane components including SDN switches and hosts
requesting to join the SDN network. We choose consortium
blockchain approach since we aim to authenticate SDN data
plane in intra- and cross-domain settings.
II. R ELATED WORKS
1) Using BC to secure SDN: There are several works in the
literature that utilized BC to secure SDN. Authors in [8], [11]–
[14] take advantage of BC to secure the information shared
between SDN controllers and related applications, which re-
moves the need to use a central entity and also reduces the
complexity of developing new protocols and/or modifying the
existing ones. Yazdinejad et al. [15] proposed a BC-enabled
packet parser (BPP) to support detecting attacks as well as
BC structure in SDN’s data plane. Yang et al. [6] proposed
BlockCtrl, a BC-based architecture to secure software-defined
optical networks (SDON).

978-1-7281-8370-1/20/$31.00 ©2020 IEEE 22

Authorized licensed use limited to: Harbin Institute of Technology. Downloaded on September 02,2023 at 07:24:06 UTC from IEEE Xplore. Restrictions apply.
 2020 Second International Conference on Blockchain Computing and Applications (BCCA)
2) Data plane authentication: The following approaches
are mainly focused on providing authentication mechanisms
for SDN data plane. Kang et al. [16] introduced a lightweight
data plane authentication scheme to solve the data plane
identifier (DPID) duplication problem using encrypted session
keys. However, this approach requires extending the OpenFlow
protocol. Moreover, the secret keys are generated by the switch
itself, therefore malicious switches can easily generate their
own keys to communicate with the SDN controller.
Lam et al. [17] proposed identity-based cryptography (IBC)
to secure SDN data plane. In this work, public keys are derived
from the identity of the user, and then used to deliver symmet-
ric session keys, which requires symmetric key distribution [3].
Liyanage et al. [18] utilized the Host Identity Protocol (HIP)
to authenticate SDN switches. This approach includes major
modifications on SDN architecture and switch design since
it introduces security gateways (SecGWs) as an intermediate
device between the controller and SDN switches via IPSec
tunneling [3]. Ranjbar et al. [19] improved the quality of
secure sessions in SDN data plane by analyzing the handshake
messages exchanged between the controller and switches.
However, the overall load on the controller is increased since
it needs to analyze all the handshake messages exchanged
between the controller and underlying SDN switches.
Yigit et al. [3] proposed Secure Communication Architec-
ture for Software-Defined Networks (SECAS) to generate cer-
tificates that are used for securing the communication among
SDN entities (controller, switch, and application). SECCAS
improves the communication security by using access control
lists (ACLs) and hardening Transport Layer Security (TLS)
configuration. Since key generation is implemented as an SDN
application, which also issues and manages corresponding
X.509 certificates, it may result in a single point of failure.
Gray et al. [20] proposed a fingerprinting-based approach to
authenticate SDN switches when cryptography-based authen-
tication mechanisms are unavailable. However, since it relies
on static features, attackers can easily mimic the behaviour
of legitimate switches in order to deceive the SDN controller.
[21] and [22] focused only on host authentication using BC
approach. Thus, the SDN controller is still susceptible to
attacks launched from malicious SDN switches.
None of these approaches discussed how BC can be used
to provide a secure component − level data-plane. In other
words, instead of using BC to only store a flow-level infor-
mation, we can use BC to enhance the security of the main
components placed at SDN’s data plane. This can be done if
BC is efficiently utilized to provide security at both switch and
host levels rather than considering only flow-level information.
This also implies that the control plane needs to be improved
in order to interact only with a trusted data plane and also to
refuse to communicate with untrusted data plane components.
III. T HREAT MODEL
Our protocol is mainly designed to react against malicious
SDN data plane. We assume that the attacker does not possess
any cryptographic keys related to all SDN nodes or blockchain
Authorized licensed use limited to: Harbin Institute of Technology. Downloaded on September 02,2023 at 07:24:06 UTC from IEEE Xplore. Restrictions apply.
clients, and the signature scheme and Certificate Authority
(CA) used for each SDN domain are secure (i.e., not possible
to forge a signature without knowing the private key). As
our focus is on authenticating SDN’s data plane, we assume
that the controller is authenticated through SSL/TLS and
is not compromised. Spoofing attacks are allowed. There-
fore, internal attacks can be launched from legitimate SDN
switches/hosts, which may try to act as another legitimate
SDN switch/host (i.e., perform switch spoofing 1 or MAC/IP
spoofing 2 ) and also may add unauthorized flows 3 . Ex-
ternal adversaries may utilize rogue switches/hosts to launch
different attacks including switch spoofing 4 and MAC/IP
spoofing 5 as well as DoS/DDoS attacks 6 against the
SDN controller (see Fig. 1).
DoS/DDoS
Attack Control Plane
6
Switch
Spoofing
SDN Controller West/East API SDN Controller
Southbound
External
attacks Rogue
4
API
Switch
MAC/IP
Spoofing
Data controllers
untrusted Plane
5
Flow Table
Rogue
Host
MAC/IP Switch Unauthorized
Spoofing Spoofing Flow
2 1 3
Internal attacks
Fig. 1: Threat model in DPSec.
IV. P ROPOSED AUTHENTICATION PROTOCOL
In this section, we propose DPSec, a protocol that lever-
ages BC to authenticate the data plane of SDN. We ensure
that OpenFlow events are received from trusted devices.
Consequently, SDN controllers will only consider the events
received from those trusted devices. We employ BC smart
contracts to provide a fault-tolerant, decentralized and secure
authentication of SDN’s data plane. Our system consists of
a cross-domain SDN network denoted as D = [D1 , ..., D` ]
managed by a group of SDN controllers C = [C1 , ..., C` ].
Each SDN domain Di includes a group of SDN switches
Si = [si,1 , ..., si,j ] and SDN hosts Hi = [hi,1 , ..., hi,k ]
managed by Ci . In addition, Bi,j ⊂ Si indicates the set of
border switches that exist in Di and connect between Di and
Dj . We consider a consortium BC to securely authenticate
the data plane of domain Di consisting of Si ∪ Hi over
Cauth ⊆ C. Each domain Di includes a group of pre-selected
endorsing peers denoted by Ei = [ei,1 , ..., ei,n ] and a group of
committing peers represented by Vi = [vi,1 , ..., vi,m ]. A peer
can act asSan endorser and committer, therefore m >= n. The
`
set V = k=1 Vk contains all committing peers in D. Each
node v ∈ V writes accepted transactions to its own replica of
BC ledger. Assuming that less than one-third of the endorsing
peers in Di are faulty (fi ), then Di should consist of at least n
= 3fi + 1 endorsing peer to tolerate faulty peers. DPSec also
requires 2fi + 1 peers to agree on BC transactions received
from Di . Thus, we define E(i)accept ⊆ Ei as the minimum
cardinality subset of endorsing nodes required to accept a
23
 2020 Second International Conference on Blockchain Computing and Applications (BCCA)

transaction Ti in Di where E(i)accept = {(e1 , ..., en ) | e ∈ retrieve these attributes to check whether the caller is allowed
Ei , n = 2fi + 1}. From BC perspective, both Ci and si,j ∈ Si to update the BC state and perform the requested functionality.
are BC clients, which can submit and verify BC transactions.
However, Ci has a higher level of privilege compared with si,j C. Intra-domain switch authentication
on the basis of attribute based access control (ABAC). Each
Di has its own certificate authority CAi managed by Ci and After successful enrollment to CAi , each SDN switch si,j
responsible for providing digital certificates, and delivering ∈ Si can interact with BC using its own P ubK and certificate
cryptography keys for each SDN switch si,j ∈ Si and host Cert(sw)i,j signed by CAi . Next, we describe our switch
hi,j ∈ Hi . authentication mechanism in the following steps (see Fig. 2):
Step 1 Switch si,j sends signed Join Request along with
Definition 1. Each SDN controller Ci ∈ C has a its certificate Cert(sw)i,j , which also includes its P ubK , to
T rusted Switches table, which includes information related at least one endorsing peer(s) e ∈ E(i)accept .
to switches si,j ∈ Si authenticated through BC smart contract. Step 2 Each endorsing peer e ∈ E(i)accept verifies
Definition 2. Each SDN controller Ci ∈ C has a Cert(sw)i,j and it signature Sig(sw)i,j . Then invokes a
T rusted P orts table, which includes port-related information smart contract that includes Switch Join F unction (see
related to hosts connected to an authenticated switch si,j ∈ Si . Algorithm 1) responsible for updating the BC state with a
new transaction that consists of a combination of DP ID,
A. Registration T imestamp and T imeOut.
SDN controller Ci and SDN switches in Si are registered Step 3 Upon acceptance, each committing peer v ∈ V
and enrolled to BC using the existing CAi , which is used updates its own replica.
in order to achieve the access control policy for domain Di Step 4 The smart contract returns a 2 byte nonce (we call
and for the corresponding BC peers as well. The controller it BC N once) to si,j and emits a new event to the notify
Ci has an identity with admin role whereas SDN switches the controller Ci ∈ Cauth .
si,j ∈ Si are registered with client role. Additionally, SDN Step 5 Ci updates its own T rusted Switches table, which
hosts hi,j ∈ Hi are registered with user role. includes the information received from the smart contract.
Step 6 si,j initiates OpenFlow handshake using OF Hello.
B. Attribute-based Access Control Step 7 The controller Ci responds with OF Hello and
DPSec utilizes attribute-based access control (ABAC) [23] OF F eatures Req.
in order to provide a simple, flexible and fine-grained access Step 8 si,j then replies with our modified
control for BC-enabled SDN data plane. CAs issue certificates OF F eatures Reply message, which includes
with attribute values, which are used to achieve access control BC N once received from the smart contract, where
in DPSec. These attributes are issued by CAs according to we replaced 2 padding bytes of OF F eatures Reply with
the role of each entity in DPSec. Therefore, each switch has BC N once since they are not utilized.
a unique identity along with its corresponding attributes such Step 9 Ci matches the information included in
as Role, DP ID, ControllerID and DomainID obtained OF F eatures Reply with T rust Switches table
from CAi . Each host also has a unique identity along with entries, then updates si,j state accordingly.
its corresponding M AC attribute. In DPSec, smart contracts Step 10 Finally, Ci configures si,j using OF Set Conf ig.

SDN Switch Endorser Smart SDN Controller

(BC client) Peer(s) Contract (BC client)
1
Signed Join Req

2
{ Verifiy

Invoke Switch Join Function

3
Update BC State

4 [DPID, BC_Nonce,TimeOut]
BC_Nonce Notification Event 5
6 Update Trusted Switches

OF_Hello
OF_Hello
7
OF_Features_Req
[BC_Nonce]
OF_Features_Reply

{
8 Check Trusted Switches
9
10
Update Switch State
[Trusted Switch = 1, Timeout > 0]
OF_Set_Config

Fig. 2: Switch authentication in DPSec

24
Authorized licensed use limited to: Harbin Institute of Technology. Downloaded on September 02,2023 at 07:24:06 UTC from IEEE Xplore. Restrictions apply.
 2020 Second International Conference on Blockchain Computing and Applications (BCCA)

Algorithm 1: Switch Join Function a smart contract with an endorsement policy defined by
Input : caller, DPID E(i,j)accept , where |E(i,j)accept | = 2fi + 2fj + 2. Also, SDN
caller BC client; controllers Ci , Cj ∈ Cauth have T rusted Switches tables
if caller.role == client then that include information related to S(i,j)cross = Bi,j ∪ Bj,i .
if caller.dpid == DP ID then
Add a new record (DPID, Joined BC,timestamp);
Emit a new event to notify Ci that si,j has joined D1 D2
BC with generated BC N once; SW11 SW12 SW21 SW22
Return BC N once to the caller;
else
Reject the request;
Update caller state to U ntrusted; SW13 SW14 SW23 SW24
Emit a notification event for caller.dpid new status;
end SW31 SW32
Smart contract
else
Reject the request; Cross-domain switch
end
Intra-domain switch
SW33 SW34
Cross-domain link
Intra-domain link D3
Fig. 3 shows the state diagram for SDN switches in DPSec,
where Joined BC state indicates that Join Request is suc- Fig. 4: Cross-domain SDN in DPSec
cessfully committed. T rusted state indicates that the Switch
is authenticated within the allowed time limit. U ntrusted E. Intra-domain host authentication
state represents the failure of Join Request or issuing a new Next, we build our host authentication mechanism on
event without updating BC. Disconnected state indicates that top of our switch authentication approach, where host
the switch is currently disconnected from the SDN network. hi,j ∈ Hi , which is connected to switch si,j ∈ Si ,
Upon failure to join or exceeding a given time period, the can interact with SDN using its own P ubK and certifi-
switch moves to the U ntrusted state. The switch remains cate Cert(h)i,j signed by CAi as follows (see Fig. 5):
in T rusted state providing that BC is updated with each Step 1 Host hi,k sends its first packet to switch si,j ∈ Si .
new event received from that particular switch, otherwise it Step 2 Once si,j receives the packet from hi,k , it will
will be in U ntrusted state. Finally, when the switch is in send a new signed P ort Req to the corresponding endorsing
Disconnected state, it has to send a new Join Request in peer(s) e ∈ E(i)accept .
order to return to the Joined BC state. Step 3 Each endorsing node e ∈ E(i)accept verifies
Cert(sw)i,j and its signature Sig(sw)i,j and invokes the
corresponding smart contract, which includes Add P ort
Joined BC Fa
iled
F unction (see Algorithm 2).
Jo
in
|| T
Step 4 Upon acceptance, each committing peer v ∈ V
im
Successful join eO
ut
Ex
updates its replica and controller Ci ∈ Cauth will be notified.
& TimeOut Valid pir
ed Step 5 Ci will check T imeout and adds a new entry to
New Join Req New Event &
BC not Updated its T rusted P orts table, which includes the MAC address
Trusted Untrusted
and the corresponding InPort.
Step 6 Ci adds a temporary flow to switch si,j .
New Event &
BC Updated Connection Step 7 hi,j sends a new signed Auth Req along with its
End certificate Cert(h)i,j to si,j .
Step 8 si,j submits a new P acket In message to Ci .
Step 9 Ci checks the T rusted P orts table to determine
Trusted
Disconnected
whether the message is received from a trusted Port/MAC
pair within a specific time period. If there is no match for the
Fig. 3: State diagram for SDN switches in DPSec. packet received from the same port, then it will be removed
from T rusted P orts and also Ci will update the port record
on BC to be invalid. Additionally, the MAC address needs
D. Cross-domain switch authentication to be matched with MAC attribute in Cert(h)i,j which also
As shown in Fig. 4, border switches mainly connect two needs to be verified. Ci also checks Certificate Revocation
separate domains (Di , Dj ). Therefore, they must be endorsed List (CRL) to determine whether the certificate is revoked.
by peers e ∈ Ei ∪ Ej . Since we already defined E(i)accept and Then, Ci needs to verify the message received from hi,j .
E(j)accept , we define E(i,j)accept = E(i)accept ∪ E(j)accept as Step 10 Ci sends a new F low M od message to si,j in
the minimum cardinality subset of endorsing nodes required order to add a new flow entry that includes Port:MAC:IP
to accept a transaction Ti over Di and Dj . Thus, we deploy information to match with the incoming traffic.

25
Authorized licensed use limited to: Harbin Institute of Technology. Downloaded on September 02,2023 at 07:24:06 UTC from IEEE Xplore. Restrictions apply.
 2020 Second International Conference on Blockchain Computing and Applications (BCCA)

SDN Switch Endorser Smart SDN Controller

Host
(BC client) Peer(s) Contract (BC client)
1
First_Packet 2
Signed Port Req

3
{ Verifiy

{
Invoke Add Port Function

4 Update BC State

Notification Event
5
Check the Timeout
6 Update Trusted Ports
[Trusted Switch = 1, Timeout > 0]
7 Add Temp Flow
Signed Auth Req &
Client Certificate 8
Packet_In
Trusted Check Trusted Ports,
Switch Client Certificate, CRL,
9
Listener Timeout and Verify
10 the Host Signature
[Trusted Switch = 1, Trusted Port = 1,
Host Verified =1, Timeout = valid]
Update Flow

Fig. 5: Host authentication in DPSec

Algorithm 2: Add Port Function in T rusted P orts entries. U ntrusted state indicates that
Input : caller, DPID, MAC, InPortID the host has sent an Auth Req that does not match with
caller BC client; T rusted P orts table entries or its signature and/or certifi-
if caller.role == client then cate are not valid. Disconnected state indicates the host is
if caller.state == T rusted then disconnected from SDN network.
if caller.dpid == DP ID then
if (M AC, caller.DomainID) does not exist as
a valid record then
Sig Au
Add a new record Connected na th R
utr
e | eq &
(InP ortID,M AC,DP ID,caller.DomainID); | In
va (Unv
lid e
Emit a new event to notify Ci ⊆ CAuth Auth Req & Ce rifie
rtifi d
Verified Signautre & ca
that caller.dpid added a new port record Valid Certificate te)
(InP ortID,M AC,caller.DomainID);
else Verified Untrusted

Reject the request; q & tch

Re isma
th
Update hi,j state to U ntrusted; New Connection
w
Au rts M
o
Trusted Ports Ne d P
Emit a new event to notify Ci about hi,j Match ste
Tru
status change; Connection End
end Trusted
else
Reject the request; New Auth Req &
Trusted Ports Match Connection End
Update caller state to U ntrusted;
Emit a new event to notify Ci about caller.dpid
status change; Disconnected
end
else
Reject the request; Fig. 6: State diagram for hosts in DPSec.
end
else When Auth Req is committed and host signature and
Reject the request;
certificate are verified, the host will be in V erif ied state.
end
Upon failure to commit or verify the signature, the host will
move to the U ntrusted state. The verified host will move to
the T rusted state when its Port/MAC pair is matched with
Fig. 6 shows the state diagram for hosts in DPSec. T rusted P orts table entries. The host remains in T rusted
Connected state indicates that the host is connected to state as long as its Pair/MAC is found in T rusted P orts
SDN through a trusted switch. V erif ied state indicates that table, otherwise it will move to the U ntrusted state. Finally,
the host is successfully verified. T rusted state indicates when the switch is in Disconnected state, it has to send a
that the Port/MAC pair of the verified host is not found new Auth Req in order to return to the Connected state.

26
Authorized licensed use limited to: Harbin Institute of Technology. Downloaded on September 02,2023 at 07:24:06 UTC from IEEE Xplore. Restrictions apply.
 2020 Second International Conference on Blockchain Computing and Applications (BCCA)
F. Cross-domain host authentication
SDN hosts that request to connect to d different domains
Dauth = {Di , ..., Dj }, DAuth ⊆ D must be endorsed by
E(i) ∪ ... ∪ E(j) . Thus, we can define the endorsement policy
with minimum number of peers as E(i,...,j)accept = E(i)accept
∪ ... ∪ E(j)acceptPwhere |E(i,...,j)accept | = |E(i)accept | + ... +
|E(j)accept | = 2( y∈Dauth fy ) + d.
V. P ROOF - OF -C ONCEPT
In this section, we provide a proof-of-concept (PoC) that
demonstrates the applicability and feasibility of our protocol.
We extended the LINC-Switch [24] to interact with BC. We
chose LINC in our PoC due to its modular and flexible
architecture. As an SDN controller, we used Ryu [25] with
OpenFlow1.3 on Ubuntu 14.04 system, installed on VirtualBox
with a system equipped with 8GB RAM and intel i7-8550u
processor, where we allocated one virtual CPU for our virtual
machine. We used Hyperledger Fabric 1.4 [26] for our BC part.
Our consortium BC part includes 2 organization and consists
of 4 peers in total, 2 peers for each. For simplicity, we focus
on intra-domain authentication and assume that the number of
faulty nodes f 1 =f 2 = 0.
We used Mininet to emulate our SDN network. We com-
pared the latency of DPSec with that of traditional SDN. In
traditional SDN P acket In messages are directly submitted
to the SDN controller whereas in DPSec those messages are
firstly submitted to and verified by the BC, then temporary
flows are added to the corresponding switch by our controller
according to the Host-Auth step in our protocol. We measured
the latency for each step separately, then we reported the
obtained results for latency metric. Fig. 7 depicts the topology
used in our PoC where we gradually increased the number of
SDN switches (k = 1, 5, 10, 20, 30) and also hosts connected
to the SDN network (i = 1, 5, 10, 20, 30).
Org 2 Org 1
CA CA
SDN Controller
Peer 2 Peer 0
(Anchor) (Anchor)
Switch 1 ...
Peer 3 Peer 1
CA-traffic ...
BC-traffic
Openflow traffic Host 1 Host i
Fig. 7: Topology used in our PoC
A. Switch-Auth Latency
Fig. 8 shows that DPSec has higher latency than traditional
OpenFlow handshake. The latency in DPSec is due to the fact
that each new Join Request must be verified and accepted
by 2fi + 1 peer within the corresponding SDN domain Di
and committed by |V | peers in our BC, which allows fault-
tolerant, decentralized and secure authentication. Moreover,
since handling of Join Request messages is offloaded to
Authorized licensed use limited to: Harbin Institute of Technology. Downloaded on September 02,2023 at 07:24:06 UTC from IEEE Xplore. Restrictions apply.
Latency (Sec)
Number of switches
Fig. 8: Comparing latency of basic OpenFlow handshake in
traditional SDN and switch authentication in DPSec
the smart contract, the overall load on the SDN controller
is reduced compared with other approaches [19] that require
analyzing of handshake messages exchanged between the
SDN controller and underlying SDN switches. The overall
average delay is 1.186 second per switch. Additionally, switch
authentication in DPSec is 1.75x slower than basic OpenFlow
handshake. DPSec, however, has lower latency when compared
with securing southbound interface with Host Identity Protocol
(HIP) [18], which has more than 2.5x latency on average.
DPSec provides also more flexible and secure cross-domain
authentication compared with [3], which utilizes ACLs to
restrict access in cross-domain networks.
B. Host-Auth Latency
To measure the Host-Auth latency, first we measured the
time required to receive the first packet and update the
T rusted P orts table using P ort Req, which also requires
updating the BC and notifying the controller. Then, we mea-
sured the time required to send and verify the Auth Req.
Latency (Sec)
Number of hosts
Switch k
Fig. 9: Latency of host authentication in DPSec
As shown in Fig. 9, the time required to complete
P ort Req is higher than the time required for Auth Req
since P ort Req takes 0.94 seconds per transaction on average,
whereas Auth Req takes 0.5 seconds per host on average.
The overall latency is 1.44 second per host on average.
The major latency in host-auth is due to the fact each new
P ort Req must be verified and accepted by at least 2fi + 1
peer within the corresponding SDN domain Di and committed
by |V | peers in our BC. However, this enables fault-tolerant,
decentralized and secure cross-domain authentication based
on unique blockchain characteristics. Unlike [21], [22] which
focused only on host authentication, DPSec ensures that each
host is connected to a trusted switch beforehand.
27
 2020 Second International Conference on Blockchain Computing and Applications (BCCA)
VI. S ECURITY A NALYSIS
This section presents a security analysis of DPSec. To this
end, we divide the possible attacks that can be realized into
internal and external attacks:
A. Internal attacks
These attacks, are launched from legitimate SDN data plane,
where the attacker may try to gain unauthorized access on
other existing components within the SDN network.
1) Unauthorized flows: since each flow is added only by
a trusted switch and our smart contract also inspects the
DP ID and DomainID for each switch, it is not possible to
add unauthorized flows. Therefore, a new flow is only added
when the caller DP ID is matched with submitted DP ID.
Moreover, such an attack will be detected by the smart contract
and consequently the switch will be in U ntrusted state.
2) Switch spoofing: it is not possible to spoof SDN switches
in DPSec since each switch receives random BC N once
from our smart contract for each time it needs to join
the SDN network. Additionally, the caller DP ID must be
matched with submitted DP ID at the smart contract side
and also DP ID/BC N once pairs must be matched with
T rusted Switches entries at the controller side. Such an
attack will be early detected by the smart contract.
3) MAC spoofing: Since our smart contract refuses to add
existing valid MAC addresses, internal adversaries will be
detected since spoofed MAC addresses will not be matched
with T rusted P orts entries. Additionally, its not possible to
spoof any MAC address even if is not added to the BC, since
Auth Req needs to be verified through host’s P ubK along
with its certificate obtained from CAi , which also includes
host’s original MAC address. Therefore, MAC spoofing will
also be detected by the SDN controller since the submitted
MAC address does not match with the MAC attribute in its
certificate, and consequently the host will be in U ntrusted
state.
4) IP spoofing: Since the MAC addresses are verified in
DPSec, and the SDN controller also installs flow rules that in-
clude Port:MAC:IP information, all unmatched packets will be
dropped. Moreover, the controller can keep the corresponding
IP address in its own T rusted P orts table.
B. External attacks
These attacks can be launched from malicious SDN data
plane to exploit or gain unauthorized access to an existing
SDN network.
1) DoS attacks: our protocol significantly reduces the DoS
launched from malicious SDN data plane since it authenticates
SDN switches at the handshake stage. Therefore, the SDN
controller will not receive events from untrusted switches.
Whereas connection attempts from malicious external hosts
are detected since those malicious Auth Req messages in-
clude forged certificate and signature. These attacks will be
detected by the SDN controller at the handshake stage and
the corresponding switch/host will be in U ntrusted state.
Authorized licensed use limited to: Harbin Institute of Technology. Downloaded on September 02,2023 at 07:24:06 UTC from IEEE Xplore. Restrictions apply.
2) Distributed DoS attacks: these attacks may affect the
SDN network due to large number of temporary flows. The
controller can monitor the switch under attack and adds flows
only for verified hosts. Thus, it avoids adding temporary
flows. Additionally, DPSec can eliminate malicious traffic
generated using spoofed MAC/IP addresses, which will reduce
the overall impact of most or all of the reflection attacks.
3) Switch spoofing: it is also not possible to spoof SDN
switches since we enforce attribute based access control
through the certificate authority and also we utilize random
BC N once value to secure the handshake stage, therefore
fake switches will be detected at the handshake stage.
4) MAC/IP spoofing: it is not possible to spoof the MAC
addresses in DPSec since each packet must be received from
a trusted port. Also, the MAC address must be matched
with incoming port, otherwise it will be removed from the
T rusted P orts table. Furthermore, each Auth Req needs
to be verified through the P ubK of the corresponding host.
MAC spoofing will be detected by the SDN controller when
the P acket In message is received. IP spoofing is implicitly
detected since the MAC address is spoofed.
It is also not possible to add unauthorized flows by ex-
ternal adversaries since the controller does not accept any
event received from U ntrusted switches. In addition, DPSec
addresses CVE-2018-1000155 vulnerability [1], which is due
to untrusted data plane, by providing an authentication mech-
anism at the handshake stage and also verifying the DPID of
every switch in the SDN network.
VII. C OMPUTATIONAL C OST
The computational cost in DPSec can be analyzed as
follows. For switch authentication, each switch needs to
sign Join Request two times, since Hyperledger Fabric
splits each transaction into 2 steps: 1) Join Request pro-
posal and 2) endorsed Join Request. This also applies for
P ort Request. Additionally, for intra-domain authentication
2fi + 1 endorsing peers need to verify received switch
certificate and signature to authenticate their communicating
party and then sign the received proposal. Whereas for cross-
domain authentication 2fi + 2fj + 2 endorsing peers need
to verify received switch identity and then sign the proposal.
Finally, each committing peer v ∈ V needs to verify the
endorsement policy of each accepted transaction. Thus, the
computational cost for intra-domain switch authentication is
O((2fi + 3)s + (2fi + |V | + 1)v) where s and v denote
signature generation and verification, respectively. Whereas
for cross-domain switch authentication the computational cost
is O((2fi + 2fj + 4)s + (2fi + 2fj + |V | + 2)v). The
computational cost for intra-domain host authentication is
O((2fi + 3)s + (2fi + |V | + 3)v) since the SDN controller has
to verify the received host certificate and its signature.Also,
the computational cost for cross-domain
P host authentication
on Pd different domains is O((2( y∈Dauth fy ) + d + 2)s +
(2( y∈Dauth fy ) + |V | + d + 2)v). In addition to the over-
head produced by encryption-decryption operations due to the
utilization of the SSL/TLS protocol.
28
 2020 Second International Conference on Blockchain Computing and Applications (BCCA)
VIII. C OMMUNICATION OVERHEAD
In intra-domain settings, SDN switches have to send a
signed proposal to 2fi + 1 endorsing peers. Whereas in
cross-domain settings, they need to submit 2fi + 2fj + 2 or
P International Conference on Wireless and Satellite Systems. Springer,
2( y∈Dauth fy ) + d transaction proposal for switch and host
authentication, respectively. Each proposal consists of 1096
bytes that contain header and payload. In addition, between
70-72 bytes for ECDSA signature of the corresponding switch.
Endorsed transactions are submitted to |V | committing peers.
Join Request and P ort Request endorsed by one peer
require 3071 and 3261-bytes, respectively. As shown in Fig.
10, the size of endorsed transactions increases according to the
number of endorsing peers. For host authentication the host
also needs to send a packet that contains between 70-72 bytes
for host signature and 1500 bytes for host certificate. Different
network protocol headers are also included. 20-byte header for
IP, and 20-byte header for TCP with no options. Utilization
of SSL/TLS requires 7x4-bytes for 7-handshake headers, 4x5-
bytes for 4 TLS records, 170-bytes for ClientHello. 32-bytes
for SessionID. 75-bytes for ServerHello. 4x1500-bytes for
host certificate (assuming 4 certificates are used). 130-bytes
for ClientKeyExchange. 2x1-bytes for 2-ChangeCipherSpec.
2x12-bytes for 2-Finished messages. Thus, 7x4 + 4x5 + 170
+ 32 + 75 + 4x1500 + 130 + 2x1 + 2x12 = 6481 bytes per
SSL/TLS handshake. However, when session resumption is
enabled SSL/TLS overhead reduces to 4x4 + 3x5 + 170 + 32
+ 75 + 2x1 + 2x12 = 334 bytes.
Transaction Size (Bytes)
Number of Endorsing Peers
Fig. 10: Transaction size according to involved endorsing peers
IX. C ONCLUSION
In this work, we proposed, DPSec, a protocol to authenticate
SDN’s data plane based on consortium BC. DPSec authen-
ticates both SDN switches and hosts placed in SDN’s data
plane. We implemented a proof of concept that shows the
applicability and feasibility of DPSec, which enables a fault-
tolerant, decentralized and secure authentication for SDNs. We
also presented a security analysis that shows how DPSec can
be utilized to address several attacks against SDNs including
CVE-2018-1000155 vulnerability [1].
R EFERENCES
[1] NIST, 2020 (Last accessed date May 25, 2020). [Online]. Available:
https://nvd.nist.gov/vuln/detail/CVE-2018-1000155
[2] D. Kreutz, F. M. Ramos, and P. Verissimo, “Towards secure and depend-
able software-defined networks,” in Proceedings of the second ACM
SIGCOMM workshop on Hot topics in software defined networking,
2013, pp. 55–60.
[3] B. Yigit, G. Gur, B. Tellenbach, and F. Alagoz, “Secured communi-
cation channels in software-defined networks,” IEEE Communications
Magazine, vol. 57, no. 10, pp. 63–69, 2019.
Authorized licensed use limited to: Harbin Institute of Technology. Downloaded on September 02,2023 at 07:24:06 UTC from IEEE Xplore. Restrictions apply.
[4] Y. Jararweh, S. Otoum, and I. Al Ridhawi, “Trustworthy and sustainable
smart city services at the edge,” Sustainable Cities and Society, p.
102394, 2020.
[5] Z. Shao, X. Zhu, A. M. Chikuvanyanga, and H. Zhu, “Blockchain-
based sdn security guaranteeing algorithm and analysis model,” in
2019, pp. 348–362.
[6] H. Yang, Y. Liang, Q. Yao, S. Guo, A. Yu, and J. Zhang, “Blockchain-
based secure distributed control for software defined optical networking,”
China Communications, vol. 16, no. 6, pp. 42–54, 2019.
[7] P. K. Sharma, S. Singh, Y.-S. Jeong, and J. H. Park, “Distblocknet: A
distributed blockchains-based secure sdn architecture for iot networks,”
IEEE Communications Magazine, vol. 55, no. 9, pp. 78–85, 2017.
[8] C. Qiu, F. R. Yu, H. Yao, C. Jiang, F. Xu, and C. Zhao, “Blockchain-
based software-defined industrial internet of things: A dueling deep q-
learning approach,” IEEE Internet of Things Journal, 2018.
[9] I. Al Ridhawi, M. Aloqaily, A. Boukerche, and Y. Jaraweh, “A
blockchain-based decentralized composition solution for iot services,”
in ICC 2020-2020 IEEE International Conference on Communications
(ICC). IEEE, 2020, pp. 1–6.
[10] L. Hang and D.-H. Kim, “Sla-based sharing economy service with smart
contract for resource integrity in the internet of things,” Applied Sciences,
vol. 9, no. 17, p. 3602, 2019.
[11] Q. Qiao, X. Li, Y. Wang, B. Luo, Y. Ren, and J. Ma, “Credible routing
scheme of sdn-based cloud using blockchain,” in International Con-
ference of Pioneering Computer Scientists, Engineers and Educators.
Springer, 2019, pp. 189–206.
[12] Z. A. El Houda, A. S. Hafid, and L. Khoukhi, “Cochain-sc: An intra-and
inter-domain ddos mitigation scheme based on blockchain using sdn and
smart contract,” IEEE Access, vol. 7, pp. 98 893–98 907, 2019.
[13] S. Rathore, B. W. Kwon, and J. H. Park, “Blockseciotnet: Blockchain-
based decentralized security architecture for iot network,” Journal of
Network and Computer Applications, vol. 143, pp. 167–177, 2019.
[14] K. Kataoka, S. Gangwar, and P. Podili, “Trust list: Internet-wide and
distributed iot traffic management using blockchain and sdn,” in 2018
IEEE 4th World Forum on Internet of Things (WF-IoT). IEEE, 2018,
pp. 296–301.
[15] A. Yazdinejad, R. M. Parizi, A. Dehghantanha, and K.-K. R. Choo, “P4-
to-blockchain: A secure blockchain-enabled packet parser for software
defined networking,” Computers & Security, p. 101629, 2019.
[16] J. W. Kang, S. H. Park, and J. You, “Mynah: enabling lightweight data
plane authentication for sdn controllers,” in 2015 24th International Con-
ference on Computer Communication and Networks (ICCCN). IEEE,
2015, pp. 1–6.
[17] J. Lam, S.-G. Lee, H.-J. Lee, and Y. E. Oktian, “Securing sdn south-
bound and data plane communication with ibc,” Mobile Information
Systems, vol. 2016, 2016.
[18] M. Liyanage, M. Ylianttila, and A. Gurtov, “Securing the control
channel of software-defined mobile networks,” in Proceeding of IEEE
International Symposium on a World of Wireless, Mobile and Multimedia
Networks 2014. IEEE, 2014, pp. 1–6.
[19] A. Ranjbar, M. Komu, P. Salmela, and T. Aura, “An sdn-based approach
to enhance the end-to-end security: Ssl/tls case study,” in NOMS 2016-
2016 IEEE/IFIP Network Operations and Management Symposium.
IEEE, 2016, pp. 281–288.
[20] N. Gray, T. Zinner, and P. Tran-Gia, “Enhancing sdn security by device
fingerprinting,” in 2017 IFIP/IEEE Symposium on Integrated Network
and Service Management (IM). IEEE, 2017, pp. 879–880.
[21] A. Yazdinejad, R. M. Parizi, A. Dehghantanha, and K. R. Choo,
“Blockchain-enabled authentication handover with efficient privacy pro-
tection in sdn-based 5g networks,” IEEE Transactions on Network
Science and Engineering, pp. 1–1, 2019.
[22] M. Pourvahab and G. Ekbatanifard, “An efficient forensics architecture
in software-defined networking-iot using blockchain technology,” IEEE
Access, vol. 7, pp. 99 573–99 588, 2019.
[23] E. Yuan and J. Tong, “Attributed based access control (abac) for web
services,” in IEEE International Conference on Web Services (ICWS’05).
IEEE, 2005.
[24] LINC-Switch, 2015 (Last accessed date May 17, 2020). [Online].
Available: https:// github.com/FlowForwarding/LINC-Switch
[25] Ryu, 2014 (Last accessed date May 17, 2020). [Online]. Available:
https://ryu.readthedocs.io/en/latest/
[26] Hyperledger, 2019 (Last accessed date May 17, 2020). [Online].
Available: https://hyperledger-fabric.readthedocs.io/en/release-1.4/
29