Advances in Network Services Chain

DistBlockNet:
A Distributed Blockchains-Based
Secure SDN Architecture for IoT Networks
Pradip Kumar Sharma, Saurabh Singh, Young-Sik Jeong, and Jong Hyuk Park

The rapid increase in the

number and diversity of
Abstract have been introduced to address these issues
[3-5]. Most of the existing work emphasizes the
smart devices connected The rapid increase in the number and diversity issue of state consistency among multiple control-
to the Internet has raised of smart devices connected to the Internet has lers. The mapping between the controllers and
the issues of flexibility, raised the issues of flexibility, efficiency, availabil- the forwarding devices is statically configured,
ity, security, and scalability within the current IoT which can result in uneven distribution of loads
efficiency, availability, network. These issues are caused by key mecha- between the controllers and bursting packets
security, and scalability nisms being distributed to the IoT network on a breaking down the controller. In addition to these
within the current IoT large scale, which is why a distributed secure SDN issues, we need a low response time and distrib-
network. These issues architecture for IoT using the blockchain tech- uted SDN network with high availability. Some
are caused by key mech- nique (DistBlockNet) is proposed in this research. methods try to offer a reliable and scalable solu-
It follows the principles required for designing a tion to the distributed network for management
anisms being distributed secure, scalable, and efficient network architec- [6–10], but none of them have completely solved
to the IoT network on ture. The DistBlockNet model of IoT architecture this problem. On the other hand, blockchains
a large scale, which has combines the advantages of two emerging tech- have recently drawn much attention from interest-
motivated the authors to nologies: SDN and blockchains technology. In a ed stakeholders in a wide range of industries [11,
propose DistBlockNet. verifiable manner, blockchains allow us to have a 12]. The reason behind this explosion of interest
distributed peer-to-peer network where non-con- is that with the blockchains technique, we can
fident members can interact with each other operate the applications in a distributed manner
without a trusted intermediary. A new scheme that could previously run through a trusted inter-
for updating a flow rule table using a blockchains mediary. We can accomplish the same function-
technique is proposed to securely verify a ver- ality with the same assurance without the need
sion of the flow rule table, validate the flow rule for a central authority. The blockchains technique
table, and download the latest flow rules table offers a distributed peer-to-peer network where,
for the IoT forwarding devices. In our proposed without a trusted intermediary, untrusted individ-
architecture, security must automatically adapt to uals can interact in a verifiable manner with each
the threat landscape, without administrator needs other [13, 14].
to review and apply thousands of recommenda-
tions and opinions manually. We have evaluated Require Design Principles for
the performance of our proposed model archi- Securely Distributed Architecture
tecture and compared it to the existing model In order to design high-performance architecture
with respect to various metrics. The results of our for the IoT network that is securely distributed in
evaluation show that DistBlockNet is capable of order to deal with current and future challenges
detecting attacks in the IoT network in real time and satisfy new service requirements, we need to
with low performance overheads and satisfying consider the following design principles based on
the design principles required for the future IoT previous work on designing distributed network
network. architecture, research new network technologies,
and investigate new service requirements.
Introduction Adaptability: Trends are evolving, and the
According to the recent Gartner’s report [1], 1 needs of clients are changing. These changing
million new Internet of Things (IoT) devices will trends require that the network architecture
be sold every hour, and $2.5 million will be spent is improved and is able to adapt to the chang-
per minute on IoT by 2021. We believe that the ing environment. Adaptability is vital to ensure
idea of a distributed IoT network is promising. its growth and survival. The network architec-
Meanwhile, software defined networking (SDN) ture should be able to adapt and have its usage
empowers easy management and network pro- broadened with the increase in clients’ needs and
grammability [2]. Initially, it brings up some issues demands.
of security, performance, reliability, and scalabil- High Availability and Fault Tolerance: The
ity due to the centralized control architecture. high availability of a network control system is
Recently, numerous distributed SDN controllers important in the actual operation of the network.

Digital Object Identifier: Pradip Kumar Sharma, Saurabh Singh, and Jong Hyuk Park are with Seoul National University of Science and Technology (SeoulTech);
10.1109/MCOM.2017.1700041 Young-Sik Jeong is with Dongguk University.

78 0163-6804/17/$25.00 © 2017 IEEE IEEE Communications Magazine • September 2017

Thus, the provisioning of a priori redundancies, bilities; and using malware concealed in websites, Protections must
the detection of failures, and the invocation of documents, networks, and guests. At present,
mitigation mechanisms are necessary steps for organizations need a single distributed secure dynamically adapt to the
action. architecture that includes powerful network secu- threat landscape with-
Performance: Ability to adapt performance lin- rity devices with proactive, real-time protection
out having to include
early. In current IoT environments, it is a common with high performance to meet the analyzed
challenge to try and achieve linear performance design principles. In this section, we propose a security administrators
over a large-scale distributed network architec- novel distributed secure SDN architecture called to manually process a
ture. DistBlockNet, its workflow, and a technique for
Reliability: When designing the distributed updating high-performance availability flow rule huge number of advi-
architecture, reliability is ranked as the highest tables in a distributed blockchain network. sories and approvals.
priority. It measures the correlation between the
DistBlockNet Design Overview These assurances must
corresponding performance required and the
total performance achieved by the system in all DistBlockNet adopts distributed secure network coordinate well into
environmental conditions of time and space. control in the IoT network by using the block- the more extensive IoT
Scalability: Scalability is an essential principle chain technology concept to improve security,
in designing a future-proof distributed network scalability, and flexibility, without the need for a environment, and the
architecture, which not only reduces costs, pro- central controller. Figure 1 shows the global and architecture must take
vides the flexibility to extend the network, and local views of the proposed architecture. In the
on a protective stance
supports unexpected services, but also involves proposed architecture, all controllers in the IoT
the deployment of new services and meets new network are interconnected in a distributed block- that cooperatively lever-
market requirements. chain network manner so that each IoT forward- ages both savvy inside
Security: Security must be everywhere in a ing device in the network can easily and efficiently
distributed network to build a secure distributed communicate. Each local network view comprises and outside sources.
architecture that is provided as a service to pro- OrchApp, Controller, and Shelter modules. The
tect the confidentiality, integrity, and availabili- Shelter and OrchApp modules in each local net-
ty of all connected information and resources. work handle the security attacks at a different
Therefore, securing the network must be one of level. OrchApp mainly functions at the manage-
the objectives of designing new distributed archi- ment or application layers, the controller-appli-
tectures. cation interface, and the control layer. Shelter
Research Contributions: On the basis of the operates at the data layer, the controller-data
discussion above, the main contributions to the interface, and the control layer. The DistBlock-
research of this work can be summarized as laid Net architecture provides not only operational
out below: flexibility, but also proactive and reactive incident
• We are proposing a distributed secure SDN prevention based on the recurring threat land-
architecture for IoT using the blockchain scape by inserting the rapidly changing, dynam-
technique. When using the proposed archi- ic, and high-performance OrchApp and Shelter
tecture, security must automatically adapt to modules. It offers a network infrastructure that
the threat landscape without administrators is agile, modular, and secure. Protections must
needing to manually review and apply thou- dynamically adapt to the threat landscape without
sands of recommendations and opinions. having to include security administrators to man-
• We are proposing a technique for updating ually process a huge number of advisories and
the high-performance availability flow rule approvals. These insurances must coordinate well
tables in the distributed blockchain SDN. into the more extensive IoT environment, and the
• We have evaluated the performance of our architecture must take on a protective stance that
proposed technique and compared it to the cooperatively leverages both savvy inside and out-
existing model with respect to various metrics. side sources.
The rest of the article is structured as follows. OrchApp: Its prime purpose is to offer pro-
We discuss the proposed distributed secure archi- gramming characterized fortifications and to set
tecture used for the IoT using the blockchain out them for execution at the appropriate appli-
technique. We also present the architecture work- cation layer enforcement points, whether imple-
flow and flow rule tables update technique in the mented using high-performance as host-based
distributed blockchain network. Next, we evaluate software on mobile devices, in the IoT network
the proposed model based on different perfor- or the cloud. Security classifications incorporate
mance metrics. Finally, we conclude the research. access control, data protection, and threat intel-
ligence. Based on the underlying domain knowl-
DistBlockNet edge from which security strategy plans are
drawn, these methods vary.
Distributed Secure Architecture Access control implements a security con-
According to the analysis in the previous sec- vention model of approved associations among
tion for rapidly growing IoT networks created resources and clients in the IoT network, as set
by the new communication paradigms, we have up by the management layer. On the other hand,
observed that the currently distributed network data protection focuses on the classification of
architecture, protocols, and techniques are not data rather than on behavior and interaction.
designed to meet the required design principles The management layer concludes the standards
for future challenges and satisfy new service or strategies for data flows in the organization.
requirements. The speed and complexity of this Threat intelligence provides the understanding of
development exponentially creates new catego- threats and their behavior. It is powered by apply-
ries of attacks; gathering known and mysterious ing collaborative intelligence to real-time threats
threats; taking advantage of “zero-day” vulnera- obtained from different communities.

IEEE Communications Magazine • September 2017 79

 To identify the attacks OrchApp Shelter
Communicating to shelter
in the security policies Parser
Security policy Relay to the PACKET_IN STATS_REPLY FLOW_MOD FEATURES_REPLY
resulting from the Access control Data protection controller
Graph builder
actual changes made to External sources Threat intelligence Controller Metadata feature set Network topology
the system data plan, Sources Analysis Threat
Data storage
prevention Relay to the Data plane cache Verifier
which is linked to each controller Admin Migration agent
Internal sources Communicating to orchestrator
flowchart and to the Local network view
topological exchange
metadata, the graph
builder analyzes the Local network view Local network view Local network view Local network view Local network view Local network view

parsed dataset to con- OrchApp OrchApp OrchApp OrchApp OrchApp OrchApp

Controller Controller Controller Controller Controller Controller
struct and alter the flow Shelter Shelter Shelter Shelter Shelter Shelter
diagrams that are con- Global network view

nected to the network

traffic.
Distributed blockchain network
Controller 2 Controller 3 Controller 4 Controller 5
Controller 1 Controller 6

IoT forwarding devices

Figure 1. Overview architecture of DistBlockNet.

OrchApp provides the level of adaptability component takes care of the main functionality
sought to adapt to the new and dynamic threats of the network infrastructure as soon as the satu-
and modifies the enterprise network config- ration attack has occurred. Whereas, the packet
urations. The application layer provides a solid migration component sends a benign network
platform that can execute assurances at the stream to the OpenFlow controller without over-
application points all throughout the enterprise. loading. As shown in Fig. 1, the module units
Because the protections are software-controlled, define the flow analyzer as a control applica-
critical hardware deployed at these points of the tion on the controller platform. Furthermore, the
application does not need to be exchanged when migration agent of the migration component is
a new threat or attack technique is exposed or applied to a controller application between the
when new technologies are introduced in the control plane, the data plane, and an element of
industry. Protections should automatically take the cache data plane.
place in the threat landscape without requiring Parser: The attackers use the subset of Open-
manual monitoring of the analysis of a large Flow messages, such as Packetin, Flow_Mod, Fea-
number of opinions and endorsements. This is tures_Reply, and Stats_Reply, in order to change
accomplished by using an automated threat coun- the network’s view of the controller. Thus, to iden-
teractive action control that works together with tify abnormal behavior, we extracted the import-
the management layer that is only essential for ant metadata by monitoring and parsing incoming
human decision-making for when the threat indi- packets.
cators offer less assurance about recognizing an Graph Builder: To identify the attacks in the
attack or threat. security policies resulting from the actual changes
Shelter: Attackers often rank in the network to made to the system data plan, which is linked to
take advantage of the insider’s advantage points, each flowchart and to the topological exchange
and then launch attacks on the internal network. metadata, the graph builder analyzes the parsed
Given that our objective is to assert the appear- dataset to construct and alter the flow diagrams
ance of attacks on the network topology and the that are connected to the network traffic. Our
data plane and the aggression of identity of the model retains the flows of logical and physical
flow rules or the strategies within the SDN, our topologies and Flow_Mod transmission status
threat system perfectly identifies the scenarios messages to identify malicious update metadata.
where the antagonist initiates attacks within the Verifier: We generated path conditions offline
SDN. Thus, we designed the SDNs as a non-open and reactive rules online. In order to reduce the
system. Removing restrictions on unidentified overhead at runtime, we processed the path con-
external communications helps focus our analysis dition generator to navigate the possible paths
only on OpenFlow control packets or messages and to collect all path conditions offline. Online
within the SDN because the OrchApp handles all reactive rule generation monitors and assigns the
of these issues in the DistBlockNet model. current value of the global variables to the sta-
Shelter is composed of a flow control analyzer tus path. The input variables are symbolized in
and packet migration components. The analyzer the path conditions, and the reactive flow rule

80 IEEE Communications Magazine • September 2017

dispatcher components are used to parse each
status path. It is only with the paths that the final
decision is taken into account in processing a N7 N9
Controller/
small set of modifications to generate a status N4 N8 N Ni verification node
10
message. Finally, the reactive flow rules we need N3 N6 C3 C5 Nj Request/
N5
are established. N2 N15
N11
Nk
response node
N13
Migration Agent: The migration agent detects C1 N16 N19 N12 Nl
attacks and makes the appropriate decisions N1 N17 N20 N14 Nm
N18 C4
based on the type of alarms received. In order to N21 Nn
C2
generate new rules and migrate the missing table N22 N26 Nq C6
packet in the data cache, it triggers the flow rules N23
N24 N Nr Np No
of the parser during saturation attacks. It migrates 25

all missing packets to the data plan cache during

the generation of flow rules and the update stage. (a)
As a result, the controller does not overload itself
with the flooding packets. Finally, it processes all Flow rules version check
the missed packets stored in the cache after the request from Ni
flow rules are updated.
Data Plan Cache: During a saturation attack, Respond Verification
it temporarily caches the missing packets. During node (Nj) Depending node (Ci)
on the node receives
flooding attacks, most flood packages are redi- the request
rected to the data plan cache to avoid flooding F=F’? F=FNew?
the controller. By using the classifier, Packet in No (Ni’s flow rules Yes Yes
(Ni’s flow rules
No
generator, and buffer queue, it parses the header up-to-date?) up-to-date?)
of the migrated packets and stores them in the
appropriate queue. Ni’s flow rules Confirmation Verify Ni’s Update the
Yes version higher No of Ni’s verifier flow rules latest flow
by proof-of-work
Shelter Workflow than Ni’s flow
rules version
rules for Ni

As shown in Fig. 1, the Shelter module has three

different stages. In the first stage, in order to build Update the Update the
a complete network view, Shelter monitors and latest flow latest flow Verify Ni’s
flow rules
parses all of the packets communicating with the rules for Nj rules for Ni
controller and identifies the appropriate Open- (b)
Flow packets. In the second stage, to build an
incremental graph network with traffic flow, Shel- Figure 2. Updating scheme of flow rules table: a) distributed blockchain net-
ter analyzes all of these parsed OpenFlow pack- work; b) flowchart of flow rules table update.
ets to obtain the topological metadata and status
of the transmission. Shelter mainly maintains the ly, Shelter applies a custom algorithm to monitor
metadata feature set, the network topological and perceive the bytes of stream statistics by col-
state that is obtained from the OpenFlow pack- lecting STATS_REPLY messages at each switch in
et headers, actual measurements of traffic flow the flow path and determines whether the switch-
within network connections, and outbound flow es are diverging values of the transmitted byte
path configuration directives, respectively. In the account.
third stage, Shelter allows this metadata to flow
against a set of acceptable metadata values col- The Updating of Flow Rules Table in the
lected during the flow period, administrative rules, Distributed Blockchain Network
and strategies. Shelter identifies known attacks Figure 2a shows the overall DistBlockNet distrib-
through policies specified by the administrator, uted blockchain network. The distributed block-
although it uses precise flow activities obtained chain network includes the controller/verification
over time to detect unplanned and possibly mali- and request/response nodes. The verification
cious activity. node denotes the controller in the blockchain
Shelter does not issue an alarm signal when it network, which maintains the updated flow rules
detects a new flow behavior. Alternatively, Shelter table information in its own database. Request/
prompts an alarm signal when it detects untrusted response nodes are the IoT forwarding devices,
entities that invoke modifiers to the existing flow which update its flow rules table in a blockchain
behavior or where the flow resists any rules or network. IoT forwarding devices can be a request
security rules specified by the administrator. Also, node or a response node. If a node requests its
Shelter will not raise any alerts on flow reroutes flow rules table, the node becomes a request
because they are generated by FLOW_MOD node. At the point when a node sends a request
messages from the trusted controller. This dras- message to update its flow rules table, the rest
tically reduces the alerts that can occur if the of the other normal nodes are considered to
recognition of each new behavior is signaled, be response nodes from the viewpoint of the
which is possible in growing networks. However, requesting node.
malicious activity will be noticed by looking back Figure 2b shows the DistBlockNet architec-
when Shelter later reports authentic activities as ture model flow rules update in the distributed
being dubious, only to be deemed illegal by the blockchain network. When an IoT forwarding
administrator. Shelter can identify such false links device starts its flow rules table update by broad-
by allowing the flow metadata data plan transfer, casting a request packet with a version check,
which collects the flow charts of valid network it views it as a request node. Once the version
traffic along a path in the flow graph. Specifical- verification request packet is broadcasted in the

IEEE Communications Magazine • September 2017 81

 Controller/
verification node
Request/
response node

6000

Packet-in arrival rate (packets/s)

5000

4000

3000

2000

1000 OpenFlow DistBlockNet Linear (DistBlockNet)

0 20 40 60 80 100 120 140 160
Time (ms)
(a) (b)

Figure 3. DistBlockNet performance on a large-scale network: a) distributed blockchain network with 6 controllers and 6000 nodes;
b) flow table update time vs. packet-in arrival rate.

distributed blockchain IoT network, the rest of Scalability

the IoT forwarding devices (i.e., response node To assess the scalability of the DistBlockNet
and all controller/verification nodes) will respond model, large-scale experiments are presented in
to the request packet of the version verification. this subsection with a cluster of 6 Intel i7 3.40
The response process varies depending on the GHz with 16 GB RAM servers. We built a dis-
node type. In the case of the controller/verifica- tributed blockchain network with 6 controllers/
tion node, it checks whether the request packet verifications and 6000 request/response nodes,
node has the up-to-date flow rules table or not. as shown in Fig. 3a. We used the OpenFlow soft-
The controller/verification node also checks the ware switch instead of the OpenVSwitch because
integrity of the flow rules table if the requesting when a large number of switches are emulated,
node has the up-to-date flow rules table. Oth- OpenVSwitch does not scale well. To compare
erwise, the controller/verification node sends a the performance of the flow rules table update
response packet with the latest version of the flow scheme of our proposed DistBlockNet model in
rules table to the requested node. a large-scale network, we also built a normally dis-
In another case, when the response node tributed SDN network. Figure 3b shows the result
receives the request, it checks the request’s of the flow rules table update time with respect to
node version of the flow rules table with its own the packet-in arrival rate in both the DistBlockNet
flow rules table version. If both the request and model distributed blockchain network and distrib-
response nodes have the same version of the uted SDN network. In this experimental result, we
flow rules table, the response node requests the observed that our proposed DistBlockNet model
other nodes in the distributed blockchain net- constantly performed superior to the distributed
work to verify the hash value of the flow rules SDN network as the rate of the packet-in arrival
table of the requested node. If the response increased.
node gets the confirmation of the hash value
from the other nodes in the network (i.e., proof- Defense Effects
of-work), the response node believes that the To assess the defense effects of our DistBlockNet
flow rules table is correct and sends the respond- model, we evaluated and compared it with an
ing packet to the requested node. In another existing OpenFlow network by considering both
case, when the request and response nodes software and hardware test environments [15].
have a different version of flow rules tables, the We used the MININET SDN emulation tool for
response node checks whose flow rules table is the software environment. We used the POX con-
the latest version. If the response node has the troller, OpenFLow switch, and server machines to
latest version, it will send the response packet to implement clients and data plane caches in the
the requesting node with the latest version of the hardware environment. We used some clients to
flow rules table. Otherwise, when the response dispatch a UDP floating attack to the switches.
node has a lower version of the flow rules table, We measured the bandwidth of clients without
it updates its own flow rules table from the and with flooding attacks generated by some cli-
request node packet. ents at different speeds to the switch. We evaluat-
ed the impact on the bandwidth with and without
Performance Evaluation the DistBlockNet model in both software and
In this section, we present the details of the imple- hardware environments separately because both
mentation, experimental environment, and eval- environments have different capabilities.
uation of DistBlockNet. We carried out different In the software test environment, as shown in
experiments to evaluate the scalability, defense Fig.4a, we noticed that the bandwidth starts at 1.9
effects, accuracy, and efficiency of our proposed Gb/s without the presence of any attacks. When
DistBlockNet architecture model. we started dispatching flooding attacks, the band-

82 IEEE Communications Magazine • September 2017

 OpenFlow DistSoft
2 OpenFlow DistSoft
10
1.8
9
1.6
8
1.4
Bandwidth (Mb/s)

Bandwidth (Mb/s)
7
1.2
6
1
5
0.8 4
0.6 3
0.4 2
0.2 1
0

300

6 00

9 00

0
420

40
0
120

150

180

210

24 0

270

300

210

252

420

462
84

126

168

29 4

336

378

50
Packet-in arrival rate (attack rate) Packet-in arrival rate (attack rate)
(a) (b)

Figure 4. Effects on bandwidth during different attack rate in: a) software environment; b) hardware environment.

width decreased rapidly with an increase in the et. We used the custom traffic generator, which
attack rate. The bandwidth went down to almost generates 1500 FLOW_MOD/sec. ARP attacks
half when the packet-in arrival rate reached 800 and fake topology are easily identified when the
packets/s. The entire network started malfunc- PACKETiN messages are processed. The detection
tioning when the packet-in arrival rate reached times may fluctuate because in order to recognize
3000 packets/s. On the other hand, using the DDoS/DoS attacks, DistBlockNet occasionally
DistBlockNet model, the bandwidth started at 1.9 runs the flowchart validator and, as a result, the
Gb/s without the presence of an attack, and after flow diagram size increases. In another case, we
the packet-in arrival rate reached 3000 packets used Mininet to increase the number of hosts to
per second, the bandwidth remained practically 30K. Then we propelled DDoS, ARP poising, and
unchanged. fake topology attacks throughout the distributed
Figure 4b shows the results in the hardware blockchain network. We reiterated each examina-
test environment. In the hardware test environ- tion more than 15 times and noticed that under
ment, the bandwidth started at 9.5 Mb/s both the distinctive topologies, DistBlockNet effectively
with and without using the DistBlockNet model recognized each of the issues.
with any attack. In this experiment, we noticed We ran a pessimistic scenario on the false
that the bandwidth without using the DistBlock- alerts raised for a given d using conflicting TCP
Net model went up to half when the attack rate of iperf streams. The fair nature of the TCP will
the packet-in arrival rate reached 1000 packets/s create fluctuations in flow to cause changes in
and started malfunctioning when the attack rate the switches along the flow path, which would
reached 5000 packets/s. While using the Dist- raise some precautions. As shown in Fig. 5a, we
BlockNet model, the bandwidth was maintained observed that with the increase of d, the probabil-
above 9 Mb/s until the packet-in arrival reached ity of false alarms occurring decreases.
1600 packets/s. After that, the bandwidth started The recall and precision are zero due to the
to go down because the ternary content address- absence of a true positive. In these experiment
able memory was not available in our switch. We results, we observed that at the default value of d
used the OpenWRT software tool in place of the = 1.06, there were 7 alarms out of 10 competing
ternary content addressable memory to execute flows over 6 min. We also performed this experi-
a flow rule table. Although a software-based flow ment on our physical testbed and obtained com-
rule table is not able to achieve a similar level of parable results.
performance, we still noticed that DistBlockNet To assess the absence of real alerts for a given
conserves resources and provides significant pro- d, we defined the ratio between the number of
tection. checks that did not raise alerts to the total num-
ber of checks that raised alerts during verifica-
Accuracy tion. We evaluated the above metric among the
We evaluated the accuracy rate of the detection Mininet hosts for controlled flows, which are eight
of DistBlockNet under two different parameters hops apart. As shown in Fig. 5b, we observed
with one in the real-time identification of attacks that the absence of real alerts during verification
and another in the presence various traffic and increases as d increases. For a given d, the recall
many distinctive defects in the system. The Dist- and precision are identical, which is equal to one
BlockNet model has the ability to identify every minus the probability of the absence of real alerts
attack quickly. In the case of real-time identifica- at every data point.
tion, synthetic faults were used in parallel with
the suitable traffic with 6K for the Mininet emul- Overhead Analysis
sified hosts on our physical testbed. Here we To evaluate the performance overhead of our
viewed the detection time as the time required DistBlockNet model, we used l2 learning and l3
for issuing of an alert from the moment when the learning applications and recorded CPU utiliza-
DistBlockNet model received the offending pack- tion during a flooding attack. We simultaneously

IEEE Communications Magazine • September 2017 83

 3 flows
0.748 6 flows 1

Probability of absence of real alerts

9 flows 0.9
0.673 12 flows
15 flows 0.8
Probability of false alerts

0.598
18 flows
0.524 21 flows 0.7
0.449 24 flows 0.6
27 flows
0.374 30 flows 0.5
0.299 0.4
3% loss
0.224 0.3 6% loss
9% loss
0.15 0.2 12% loss
0.075 0.1 15% loss
18% loss

1.10

1.12

1.14

1.16

1.18
0

1.10

1.12

1.14

1.16

1.18

1.0

1.0

1.0

1.0

1.0
1.0

1.0

1.0

1.0

1.0

Similarity margin (δ) Similarity margin (δ)

(a) (b)

Figure 5. DistBlockNet accuracy rate: a) probability of false alerts with variation in flows and d; b) probability of absence of real alerts
vs. loss rate and d.

14 18
16
12
14
10
CPU utilization (%)

CPU utilization (%)

12
8 10

6 8
6
4
4
2 2

0.2 0.4 0.6 0.8 1.0 1.2 1.4 1.6 1.8 2.0 0.2 0.4 0.6 0.8 1.0 1.2 1.4 1.6 1.8 2.0
Time (s) Time (s)
(a) (b)

Figure 6. CPU utilization during flooding attack: a) running l2 learning application; b) running l3 learning application.

executed these two applications and used some protections, including threat prevention, data
clients to act as attackers and propelled the satu- protection, and access control, and mitigate net-
ration attack with a rate of 500 packets/s with a work attacks such as cache poising/ARP spoofing,
DistBlockNet model in the hardware environment. DDoS/DoS attacks, and detect security threats.
For each application, we monitored the consump- The DistBlockNet model also focuses on reducing
tion of the resources. Figure 6 shows the average the attack window time by allowing IoT forwarding
CPU utilization for all the controllers for different devices to quickly check and download the latest
applications with the DistBlockNet model during table of flow rules if necessary. The performance
flooding attacks. The flooding attacks began at evaluation is based on scalability, defense effects,
about 0.5 s, and we noticed that CPU utilization accuracy rates, and the performance overheads of
quickly increased for each application. Then CPU the proposed model. The evaluation results show
usage started to slowly decrease after we installed the efficiency and effectiveness of the DistBlock-
the migration rules of flow. Based on the results, Net model and have met the required design prin-
we observed that DistBlockNet provides effective ciples with minimal overhead.
protection and creates a more secure distribut- In the future, we will extend our research work
ed network without consuming many resources to build a distributed cloud computing architec-
during a saturation attack. ture with secure fog nodes at the edge of the IoT
network.
Conclusion
In this article, based on an analysis of the challeng- Acknowledgments
es that large-scale IoT networks face due to new This work was supported by the National
communication paradigms, DistBlockNet, a new Research Foundation of Korea (NRF) grant
distributed secure IoT network architecture consist- funded by the Korea government (MSIP) (No
ing of an SDN base network using the blockchains 2016R1A2B4011069)
technique, has been proposed to address the
current and future challenges and to satisfy new References
[1] “Top Strategic Predictions for 2017 and Beyond: Surviving
service requirements. DistBlockNet improves a sys- the Storm Winds of Digital Disruption,” https://www.gart-
tem’s performance and capacity. The core role of ner.com/doc/3471568? ref=unauthreader, accessed May
the DistBlockNet model is to generate and deploy 5, 2017

84 IEEE Communications Magazine • September 2017

[2] J. M. Batalla et al., “On Cohabitating Networking Technolo- [15] J. M. Batalla et al., “A Novel Methodology for Efficient
gies with Common Wireless Access for Home Automation Throughput Evaluation in Virtualized Routers,” 2015 IEEE The performance eval-
System Purposes,” IEEE Wireless Commun., vol. 23, no. 5, ICC, June 2015, pp. 6899–905.
Oct. 2016, pp. 76–83. uation is based on scal-
[3] D. Levin et al., “Logically Centralized?: State Distribution Biographies
Trade-offs in Software Defined Networks,” Proc. 1st ACM Pradip Kumar Sharma ([email protected]) is a Ph.D. schol- ability, defense effects,
SIGCOMM Wksp . Hot Topics in Software Defined Net- ar at Seoul National University of Science and Technology. He
accuracy rates and the
works, Aug. 2012, pp. 1–6. works in the Ubiquitous Computing & Security Research Group.
[4] S. Stefan and J. Suomela, “Exploiting Locality in Distributed Prior to beginning the Ph.D. program, he worked as a software performance overheads
SDN Control,” Proc. 2nd ACM SIGCOMM Wksp. Hot Topics engineer at MAQ Software, India. He received his dual Master’s
in Software Defined Networking, Aug. 2013, pp. 121–26. degree in computer science from Thapar University (2014) and of proposed model.
[5] X. Wu et al., “A Multipath Resource Updating Approach for Dis- Tezpur Univerity (2012), India. His current research interests are
tributed Controllers in the Software-Defined Network.,” Science focused on security, SDN, SNS, and IoT. The evaluation results
China Info. Sciences, vol. 59, no. 9, Sept. 2016, pp. 92,301–10.
[6] H. Lu et al., “Hybnet: Network Manager for A Hybrid Net- Saurabh Singh ([email protected]) is a Ph.D. scholar
show the efficiency and
work Infrastructure,” Proc. Industrial Track, 13th ACM/IFIP/ at Seoul National University of Science and Technology carrying effectiveness of the
USENIX Int’l. Middleware Conf., Dec. 2013, pp. 1–6 out his research in the field of ubiquitous security. He holds
[7] D. Drutskoy, K. Eric, and J. Rexford, “Scalable Network Vir- a strong academic record. He received his Bachelor’s degree DistBlockNet model and
tualization in Software-Defined Networks,” IEEE Internet from Utter Pradesh Technical University and holds a Master’s
Computing, vol. 17, no. 2, Mar. 2013, pp. 20–27. degree in Information Security from Thapar University. His have met the required
[8] Z. Qingyun et al., “On Generally of the Data Plane and Scal- research interests include cloud security, IoT, and cryptography.
ability of the Control Plane in Software-Defined Network- Finally, he has the experience of being a lab leader of the UCS
design principles with
ing,” China Commun., vol. 11, no. 2, Feb. 2014, pp. 55–64 lab, SeoulTech Korea. minimal overhead.
[9] Y. Sung et al., “FS-OpenSecurity: A Taxonomic Modeling of
Security Threats in SDN for Future Sustainable Computing,” Young-Sik Jeong ([email protected]) is a professor in the
Sustainability, vol. 8, no 9, Sept. 2016, pp. 919–44. Department of Multimedia Engineering at Dongguk University,
[10] Q. Vuong, H. M. Tran, and S. T. Le, “Distributed Event Korea. His research interests include cloud computing, mobile
Monitoring for Software Defined Networks.” Proc. 2015 computing, IoT, and wireless sensor network applications. He
Int’l. Conf. Advanced Computing and Applications, IEEE, received his B.S. degree in mathematics and his M.S. and Ph.D.
Nov. 2015, pp. 90–97. degrees in computer science and engineering from Korea Uni-
[11] K. Christidis and M. Devetsikiotis, “Blockchains and Smart versity, Seoul, in 1987, 1989, and 1993, respectively.
Contracts for the Internet of Things,” IEEE Access, vol. 4,
May 2016, pp. 2292–303. J ames J. (J ong H yuk ) P ark ([email protected])
[12] F. Tschorsch and B. Scheuermann, “Bitcoin and Beyond: A Tech- received his Ph.D. degrees from the Graduate School of
nical Survey on Decentralized Digital Currencies,” IEEE Commun. Information Security, Korea University, and the Graduate
Surveys & Tutorials, vol. 18, Mar. 2016, pp. 2084–2123. School of Human Sciences, Waseda University, Japan. He is
[13] X. Xu et al., “The Blockchain as a Software Connector,” now a professor at the Department of Computer Science and
Proc. 13th Working IEEE/IFIP Conf. Software Architecture, Engineering, Seoul National University of Science and Tech-
Apr. 2016, pp. 1–10. nology, Korea. He has published about 200 research papers
[14] K. Ahmed et al., “Hawk: The Blockchain Model of Cryptog- in international journals/conferences. He has served as Chair
raphy and Privacy-Preserving Smart Contracts.” Univ. MD and Program Committee member for many international con-
and Cornell Univ., May. 2015, pp. 1–32. ferences and workshops.

IEEE Communications Magazine • September 2017 85