Research Article

International Journal of Distributed

Sensor Networks
2017, Vol. 13(8)
Analysis of attacks on device manager Ó The Author(s) 2017
DOI: 10.1177/1550147717728681
in software-defined Internet of Things journals.sagepub.com/home/ijdsn

Tri-Hai Nguyen1 and Myungsik Yoo1,2

Abstract
The Internet of Things is a network of physical devices consisting of embedded systems and sensors that interact with
each other and connect to the Internet, and the quick growth of the Internet of Things industry has resulted in complex
inter-networking on the Internet. Software-defined networking is a recent advance in computer networking that rede-
fines the network paradigm for future communication, and the advantages of software-defined networking can also be
applied to Internet of Things, namely as software-defined Internet of Things. In this article, we investigate the vulnerabil-
ity of the software-defined Internet of Things platform device manager, which monitors the connected Internet of
Things devices in the network. Although being the one that performs one of the most crucial services, the device manag-
ers in current primary controllers have a big security issue as they do not include any device verification, authentication,
or authorization routines. Consequently, the device manager accepts all the changes of device information made by
other devices, which leads to potential attacks as demonstrated in this article. To address this problem, a comprehensive
and lightweight countermeasure is proposed and its effectiveness is verified through experiments.

Keywords
Internet of Things, software-defined networking, device manager, security, vulnerability

Date received: 17 January 2017; accepted: 6 August 2017

Academic Editor: Davide Brunelli

Introduction difficulty in an orchestration, and virtualizing sensor

The concept of the Internet of Things (IoT) refers to
communication technologies, embedded systems, smart
phones, cloud computing, and physical objects (e.g.
sensors, wearables, smart cars, and smart appliances)
that enable connecting people, places, and things to the
Internet, anytime and anywhere.1 The rapid growth of
IoT has forced new, complicated specifications to both
networking and inter-networking platforms in current
and future networks, particularly the Internet.2 In the
IoT ecosystem, wireless sensor networks (WSNs) are
essential elements. A WSN is a network of nodes that
collaboratively sense and may control the environment,
allowing interaction between persons or devices and
the around environment. However, WSNs are faced
with many IoT challenging issues such as inflexible
control, manual configuration of sensor nodes,
network resources.3
Software-defined networking (SDN) is a remarkable
technology that can tackle such challenges related to
WSN and IoT in the near future. SDN simplifies and
improves network control in a highly elastic manner by
decoupling the control plane from the data plane. The
SDN controller is a centralized software operation that
controls the entire network behavior to be agile,
1
Department of ICMC Convergence Technology, Soongsil University,
Seoul, Republic of Korea
2
School of Electronic Engineering, Soongsil University, Seoul, Republic of
Korea
Corresponding author:
Myungsik Yoo, School of Electronic Engineering, Soongsil University, 369,
Sangdo-ro, Dongjak-gu, Seoul 06978, Republic of Korea.
Email: myoo@ssu.ac.kr

Creative Commons CC-BY: This article is distributed under the terms of the Creative Commons Attribution 4.0 License
(http://www.creativecommons.org/licenses/by/4.0/) which permits any use, reproduction and distribution of the work without
further permission provided the original work is attributed as specified on the SAGE and Open Access pages (http://www.uk.sagepub.com/aboutus/
openaccess.htm).
2 International Journal of Distributed Sensor Networks
programmable, and intelligent.4,5 The major issues
related to WSN and IoT can be solved if the advan-
tages of SDN are integrated.
For all these reasons, the software-defined Internet
of Things (SDIoT), as an integration of SDN and IoT,
is notable.6–10 It will undoubtedly simplify network
control using a common protocol in every technologi-
cal domain, but it also poses some risks. Apart from
the reliability and efficiency of its communications,
information security is also an essential requirement for
SDIoT. In industrial, medical and healthcare, transpor-
tation, and smart infrastructure applications, any expo-
sure of sensitive information (e.g. chat logs, patient
medical records, financial data) is not acceptable.
In SDIoT, the device’s profile information is regu-
larly updated by the device manager, which is a funda-
mental and crucial service to ensure the proper
operation of the IoT services and applications.
However, it is found that the device manager accepts
all migrations and changes of device information
because it lacks a security mechanism within. Thus, an
attacker could easily corrupt the profile information of
the target device in the controller, which can lead to
various types of serious attacks.
Briefly, the major contributions of this article are as
follows. First, a security analysis is thoroughly per-
formed on the device manager in the SDIoT controller.
The vulnerabilities in the device manager allow an
attacker to carry out device impersonation, eavesdrop-
ping, and denial-of-service attacks in the network.
Second, comprehensive countermeasures are proposed
and discussed. Finally, an experiment is carried out to
show that the proposed prevention method is light-
weight and effective.
The rest of this article is organized as follows.
Related knowledge is described in section ‘‘Background
and related work.’’ Section ‘‘Vulnerability of the device
manager’’ analyzes the security issues and possible
attacks on the device manager in the controller. Section
‘‘Countermeasure and evaluation’’ discusses the pro-
posed defense method and evaluates its performance.
Finally, the summary is presented in section
‘‘Conclusion.’’
Background and related work
In this section, we provide an overview of the SDIoT
and the device manager in the SDIoT controller. The
related work is also mentioned.
SDIoT
The IoT is a flexible, globally interconnected, intelli-
gent, self-configuring devices. The most important con-
tributor in the IoT is WSN that is defined as
intercommunication of distributed sensor nodes mainly
related to monitoring and detection.3 In IoT, a large
number of devices generate a huge amount of traffic
that requires many processing operations to be con-
verted into useful information. Moreover, any suspen-
sion in communication among the devices will
negatively impact the performance and accuracy of the
system. Thus, these problems require a new paradigm
to improve the effectiveness of the IoT architecture.1,2
Recently, SDN, a novel network paradigm, was pro-
posed to decouple the control plane from the data
plane, and it can be programmed directly.4,5 As shown
in Figure 1, the SDN framework can be divided into
three planes, including application, control, and data
planes with their corresponding application program-
ming interfaces (APIs), which is explained as follows:
 The application plane provides various applica-
tions and services, for example, traffic monitor-
ing, security enhancements, topology discovery,
load balancers. The application plane communi-
cates with the control plane through north-
bound interface APIs, and the control plane
provides an abstraction of the network’s physi-
cal network infrastructures for the application
plane.
 The control plane manages the entire network
through the SDN controller. There are some
major SDN controllers in the market, for exam-
ple, Floodlight,11 POX,12 and OpenDaylight.13
The controller has a global vision of the full net-
work topology at the data plane (i.e. switches
and links), and it communicates with the switch
using a standard southbound interface API, for
example, OpenFlow.14
 The data plane consists of many OpenFlow
switches. Each switch has the Flow Tables,
which accommodate the thousands of rules that
are used to define the forwarding decisions.
When a new packet passes through a switch, the
switch checks if the packet matches any current
rules. If so, the switch will handle the packet
according to the rule. Otherwise, the switch
transmits a Packet-In message to the controller
to request for suitable operations. The controller
then supplies a Packet-Out message for the sin-
gle packet processing or a Flow-Mod message to
install new flow rules.5,14
The benefits of SDN can be derived from four main
features, including a network-wide visibility with cen-
tralized control, a flexible flow manager, a programma-
ble capacity, and a simplified forwarding mechanism.
The SDN can solve a range of IoT challenges and can
provide a robust, flexible, scalable scheme for the IoT
services.
Nguyen and Yoo
Figure 1. Overview of the SDN architecture.
Several previous studies have presented an inte-
grated SDN with IoT, which is referred to as SDIoT.
Qin et al.6 proposed an SDN controller design for the
IoT network, which enables centralized flow scheduling
according to the network calculus model. TalebiFard
and Leung7 proposed an SDN-based scheme, which
eliminates the rigidity of a conventional IoT network
by granting dynamic reply to any shift in the environ-
ment. Galluccio et al.8 introduced SDN-WISE that
supports stateful SDN and reduces the amount of
information exchanged between the sensor nodes and
the controller. SDN-WISE also introduced the WISE-
Visor which creates and manages several virtual WSNs
based on the same physical sensor nodes. Liu et al.9
proposed a software-defined IoT paradigm for separat-
ing smart urban sensing applications from underlying
physical infrastructures. Recently, Jararweh et al.10
reported efforts in defining a generic high-level archi-
tecture to deal with the integration of IoT and SDN. In
general, the view of the SDIoT scheme includes the
devices/things (e.g. smartphone, wireless sensors, appli-
ances, actuators), network infrastructure (e.g. switches,
routers), SDN controller and IoT applications/services,
as shown in Figure 2.
Device manager in SDIoT controller
In contrast with traditional networks or IoT schemes,
the device manager in SDIoT networks is unique due
to its logically centralized controller. The device man-
ager helps the controller identify the location (i.e. the
corresponding switch port attached) of the device in
the network that is provided to the upper IoT services/
applications, as shown in Figure 3.15
The device manager learns the end devices passively
or actively. In the case of passive learning, the device
manager gets the MAC and IP addresses from the
Packet-In message, which encapsulates the ARP reply,
3
Figure 2. SDIoT environment.
DHCP response, or IP packets. Therefore, it can iden-
tify where the devices are. In the case of active learning,
the device manager will send ARP requests to all the
ports and then receive ARP responses from devices
attached to these ports. Through ARP responses, the
device manager is able to determine where the devices
are.
The device profile is built based on the Packet-In mes-
sage, which contains information such as the IP address,
MAC address, switch and port number, and last seen
timestamp. A device profile is usually indexed by the
MAC address. For instance, OpenDaylight indexes the
device profile with MAC and IP addresses. The device
manager in Floodlight supports both the VLAN ID and
MAC addresses for indexing and querying.
When a device comes in and sends its first packet to
the network, the switch forward this packet via a
Packet-In message to the controller, and the device
manager then creates a new device profile based on the
payload information of the Packet-In message. When a
device moves from one switch to another, the controller
updates the database for the migrated device based on
the Packet-In message received from another switch
port.
Related work
Few prior studies have investigated security issues for
fundamental services in an SDN or SDIoT controller,
especially for the network topology service.
TopoGuard15 is a security module in the controller that
detects poisoning attacks on network visibility.
SPHINX16 proposes a unified approach based on net-
work flow graphs to detect the attacks that violate the
learned flow graphs/modules, but it is ineffective in
large-scale networks. Although these models can pro-
tect against most network topology attacks, they are
powerless against complex attacks constructed by an
4 International Journal of Distributed Sensor Networks
Figure 3. Device manager in SDIoT controller.
adversary. NSV-GUARD17 is a new model that can be
used to secure routing path construction in SDN. This
method is based on a network security virtualization
technique combined with dynamic trust evaluation of
the network resources. However, it only deals with mal-
icious routing policies generated by an unregistered
routing applications. FADE18 uses dedicated flow rules
to collect flow statistics of a minimal set of flows, and
with these flow statistics, it identifies forwarding
anomalies. However, the system has a negative impact
on the network throughput.
Vulnerability of the device manager
To the best of our knowledge, none of the existing con-
trollers contain a security mechanism to prevent mali-
cious packets that are received by the device manager.
Even well-known open-source controllers currently in
the market, such as Floodlight, POX, and
OpenDaylight, still have this problem. In this section,
we first analyze the vulnerability of the device manager
service, and three types of network attacks that exploit
this security hole are presented. Then, the potential
solution to this problem is suggested and discussed.
The security analysis of device manager
The device manager provides information related to the
location of the device which is required for monitoring
traffic, assisting in traffic routes, and determining the
source of the packets. If this service works incorrectly,
all dependent services will be affected.
The device manager controls the device entities in a
database based on the MAC addresses, network addresses
mapped to the devices, and their locations in the net-
works. We analyze the source code of the device manager
in current mainstream controllers, that is, Floodlight,
POX, and OpenDaylight, and find some vulnerabilities in
their device manager. Specifically, the isEntityAllowed()
API allows any device to join the current network without
any validation. The learnDeviceByEntity() API looks up
the entity information in the database based on the device
key, that is, a device’s MAC address. However, spoofed
internet control message protocol requests or spoofed
ARP reply with a fake MAC address can bypass the
lookup for the entity database. Thus, the device manager
can accidentally grant the spoofed individual access to
controller’s resources. Furthermore, the device manager
does not contain any device verification, authentication,
or authorization mechanism. By discovering the vulner-
ability in the device manager, an attacker can tamper with
the device profile information in the controller because
the device manager accepts all changes of the device infor-
mation via spoofed packets, causing some serious attacks,
including device impersonation, eavesdropping, and
denial-of-service.
Device impersonation. In this attack scenario, the attacker
will receive packets intended for the victim and can reply
to these packets on behalf of the victim. Figure 4 illus-
trates the device impersonation attack where device B is
the victim.
To perform this attack, the attacker first sends the
ARP request to the controller to probe the
Nguyen and Yoo
Figure 4. Device impersonation attack in an SDIoT network.
corresponding MAC address of the IP address for
device B. The attacker then injects the spoofed ARP
reply, which contains the IP address of device B and
the MAC address of the attacker device, to the net-
work. The controller receives the spoofed ARP reply
packet from the switch via a Packet-In message and
then accepts the change in the profile information of
device B, that is, the MAC address for device B changes
to the MAC address of the attacker’s device. Since the
device profile is indexed by the MAC address, the meta
information for device B, that is, the DPID and port
number, is also changed into meta information of the
attacker device. The controller then sends a Flow-Mod
message to modify the Flow Table of the switch based
on the forged information of the device profile. As a
result, the attacker successfully impersonates device B.
Therefore, when another device, for example, device A,
attempts to connect to device B, the attacker’s device
will communicate with device A.
Eavesdropping. An eavesdropping attack is a well-known
attack where an adversary aims to listen to the private
communication between two devices without them
knowing. We consider the network topology, which
consists of an attacker device, device A and device B, as
shown in Figure 5. The attacker first sends the fake
ARP reply packet, which has the IP addresses of device
A and device B but the MAC address of the attacker’s
device. The switch will then send this packet to the con-
troller via the Packet-In message. Hence, the controller
accepts the modification for the location of device A
5
and device B to the location of the attacker. The con-
troller then sends the Flow-Mod message to change the
flow rules in the switch based on the new device profile
of device A and device B. Once this has been done,
when device A attempts to contact device B, the traffic
from device A will go through the attacker device and
then to device B. Device A and device B believe that
they have a direct connection to each other.
DoS. Different from traditional denial-of-service (DoS)
attack, in this DoS attack scheme, the attacker device
runs an attacking script to craft the fake packets and
sends them to the controller to make the profile of the
target device in the controller contain bogus profile
information such as a fake MAC address, a non-
existing port. Hence, the victim’s device (e.g. banking
servers, DNS servers) cannot communicate with others.
Figure 6 shows the result of the DoS attack where
the victim is device B. The attacker periodically sends
spurious ARP reply packets to the controller to change
the MAC address of device B to an unreal one. Since
the device manager accepts all changes in the device
profile, the device profile is misconfigured by the
spoofed message. The controller then sends a Flow-
Mod message to change the Flow Table of the switch
according to the misconfigured device information
database. Consequently, the flow rules of the Flow
Table are erroneous, that is, the MAC address of
device B in the flow rules is changed to a non-existing
one. Hence, the communication between device B and
the other devices is blocked.
6 International Journal of Distributed Sensor Networks
Figure 5. Eavesdropping attack in an SDIoT network.
Figure 6. Denial-of-service attack in an SDIoT network.
Potential solutions from traditional networking
A cryptographic technique, that is, public key infra-
structure (PKI),19 may be used to solve this problem.
The PKI establishes and maintains a trustworthy net-
working environment by providing key and certificate
management services to enable encryption and digital
signature capabilities. When a device moves to a new
location or newly joins the network, the device will be
authenticated by the controller. The device will then
encrypt the packet, which contains the location infor-
mation, using the controller’s public key and will sign it
using the device’s digital signature. The digital signa-
ture is made of the device’s private key and the message
digest. The device then sends the processed message to
the controller via the Packet-In message. To prove the
identity, the device needs to use a digital certificate
Nguyen and Yoo
Figure 7. The controller without the spoofed packet-checking mechanism.
provided by a Certification Authority (CA). After
receiving the message from the device, the controller
decrypts the message with its private key and verifies
the message digest using three elements, including the
hash algorithm, the authenticity with the device’s public
key, and the device’s digital certificate. Then, the con-
troller can identify the location of the device through
the received packet information.
Since it is impractical for an attacker to obtain the
device’s certificate, this solution seemingly prevents the
attacks. Unfortunately, there are several limitations
that make it difficult to be deployed in the fields. First,
SDIoT is usually a dynamic, large-scale network where
the device (e.g. mobile device, wearable device) changes
its physical location frequently. When a device migra-
tion event occurs, the device will be re-authenticated. If
re-authentication happens frequently, the controller’s
computing overhead to process each Packet-In message
will increase dramatically due to the high computa-
tional cost of the asymmetric algorithm such as PKI.20
In worst case, the controller can even turn off due to
the overload. IoT devices (i.e. sensors) are generally
limited in power and resources, making it difficult to
apply this complex cryptographic algorithm.21
Due to the limited computing and memory capabil-
ity of the IoT devices, Ling et al.22 proposed an efficient
and secure one-time password (OTP authentication
suitable for devices with limited computing resources
and power. In their method, the hash chain is removed
to reduce the computational load for the device, but it
still retains the one-way hash function to achieve
mutual authentication. The device is assumed to con-
tain a pre-shared secret value which is a random num-
ber chosen by the controller, and the controller keeps
it. The OTP is formed by passing the value of a secret
value and a timestamp through a cryptographic hash
function of the device. Then, the controller obtains the
device’s secret value and timestamp value from a device
7
table and generates the same OTP. The two passwords
must be matched to authenticate the device.
Countermeasure and evaluation
In this section, we detail the idea and implementation
of the defense method to protect the SDIoT networks
against device manager attacks. Also, an experiment is
conducted to analyze the performance of the proposed
attack prevention method.
Countermeasure
Note that the message authentication scheme is used to
confirm that the message comes from the initiating sen-
der and has not been changed in transit. After success-
ful authentication, depending on the system, the
contents of the message need to be checked. However,
in SDIoT, as we mentioned before, the device manager
in the existing controller does not contain the verifica-
tion mechanism to check the spoofed packet. Hence,
the authenticated device can still send the spoofed
packet to change the information in the device data-
base. As shown in Figure 7, although the authentication
mechanism is activated, the attacker (authenticated as a
normal device) can still send a fake message, which is
accepted by the controller without considering the con-
tents of the message.
To address this issue, we propose a novel model,
which is referred to a security patch for the device man-
ager in the controller, as shown in Figure 8. The pro-
posed model consists of a Device Manager Checker,
Authenticator, Port Monitoring, and Device Profile
Database. The new device must be authenticated by the
Authenticator using the lightweight authentication
method. When the device moves to another location, a
verification of the previous port of the device has to be
made via Port Monitoring. If the connection is still
8 International Journal of Distributed Sensor Networks
Figure 8. The proposed device manager.
Table 1. The suggested structure format of the Device Profile Database.
Number MAC address IP address Authentication status
1 00:00:00:00:00:01 10.0.0.1 True
2 00:00:00:00:00:02 10.0.0.2 False
3 00:00:00:00:00:03 10.0.0.3 False
active, the migration of the device must be spoofing
action and will be blocked by Device Manager
Checker. Otherwise, the migration request will be
accepted and updated by Device Profile Database.
Hence, all the spoofing actions, which lead to three
kinds of discussed attacks (i.e. device impersonation,
eavesdropping, DoS attack), can be detected and sus-
pended by the proposed model. The details are shown
below.
Device profile database. It is structured as a list as shown
in Table 1 where each row contains the device profile
and its networking status. Each item of device informa-
tion is stored in its respected column. Each device
should have at least the entries on its MAC address, the
location of the connected switch, and the last seen time-
stamp. Furthermore, the authentication status is neces-
sary for the check-up and monitoring measurements.
Authenticator. The newly connected devices must be
authenticated by the controller. In this module, we
adopt the efficient and secure OTP authentication pro-
posed by Ling et al.22 The used authentication method
establishes a session key to encrypt the transmitted
messages. Upon successful authentication, the authenti-
cation status of the device will be updated in the Device
Profile Database.
Switch and port Last seen timestamp
sw1, 1 11:13.45 26.12.2016
sw1, 2 09:13.33 27.12.2016
sw2, 1 N/A
Port Monitoring. Without checking the contents of the
packet, the authenticated device can still send the
spoofed packet to impersonate other devices. With
the use of Port Monitoring, a duplicate appearance of
the device in the database can occur only if the device
has moved and the database has not been updated, or
if it is a result of a spoofing attempt. Thus, a check-up
of the original device location has to be made via Port
Monitoring. An efficient way of check-up is to check
the status of the port where the device was previously
connected. If the connection is still active, the change
must then be a spoofing action, and the Device
Manager Checker will block this request. If the connec-
tion is inactive, then the change request can be
accepted, and the Device Profile Database will be
updated. Figure 9 shows the result of using the Port
Monitoring when an attacker performs a spoofing
attack.
Evaluation
Our experiment is conducted using the Linux-based
Mininet 2.2.1,23 which provides a scalable platform to
emulate the SDN network via virtualization. The pro-
posed defense mechanism is implemented using the
Floodlight 1.2 controller.11 We also use Open vSwitch
2.5.1,24 a software-based virtual SDN switch with the
support of the OpenFlow protocol. The attack tools are
Nguyen and Yoo 9

Figure 9. The controller using Port Monitoring in the device manager.

Figure 10. Successful eavesdropping attack on the Floodlight controller.

ARP-spoof 1.525 and Wireshark 1.21.1.26 All experi-
ments are conducted on a PC with an Intel Xeon CPU
E3-1230 V2 running at 3.30 GHz with 16 GB of RAM.
In the first experimental scheme, we perform an
eavesdropping attack without enabling the security
extension of the device manager. The other discussed
attack scenarios, i.e., device impersonation and DoS
attack can operate in the same manner. We consider a
network containing three devices: an attacker device (IP
address: 10.0.0.1, MAC address: 00:00:00:00:00:01,
switch port: 1), device A (IP address: 10.0.0.2, MAC
address: 00:00:00:00:00:02, switch port: 2), and device B
(IP address: 10.0.0.3, MAC address: 00:00:00:00:00:03,
switch port: 3). The attacker uses ARP-spoof to repeat-
edly send spoofed ARP reply packets using the MAC
address of the attacker’s device and the IP address of
two targets, device A and device B. Hence, the profiles
for device A and B in Device Profile Database are
updated with fake information. The Floodlight control-
ler sends the Flow-Mod message to modify the flow rules
of the switch. We can see the flow rules in Figure 10, and
the network traffic between device A and device B goes
through port number 1, which is the attacker’s location.
As shown in Figure 10, the attacker successfully wiretaps
the communication between the two victim devices, A
and B, as shown in the Wireshark software.
In the second experimental scheme, the new device
manager is activated, and the feedback of the device
manager is indicated using the console output of the
Floodlight controller. The attack is also performed
same as in the previous experiment. However, with our
proposed prevention method, the spoofing attacks,
10
Figure 11. Successful detection of the attacks on the device manager in the Floodlight controller.
Table 2. The computational overhead of the controller.
Measure
Processing time for device discovery of 100 devices
Average processing time per Packet-In message
which is a major cause of the device impersonation,
eavesdropping, and DoS attack, can be prevented.
Figure 11 shows the successful detection when a spoof-
ing attempt occurs.
We also consider the performance overhead of the con-
troller with and without the proposed model. The network
is created by a tree topology with a depth of 2 and fanout
of 10 containing 100 devices in Mininet. Table 2 shows the
comparison of the controller with and without the pro-
posed countermeasure in terms of the processing time for
device discovery of 100 devices and the average processing
time per Packet-In message. The authentication mechan-
ism adds an extra 8% processing time of the controller.
Port Monitoring also brings a small delay on Packet-In
message processing. However, the overhead of average
delay for each Packet-In message processing is quite small
(below 0.5 ms). The result shows that the impact of the
new device manager is acceptable in order to obtain a
trustworthy device manager in the controller.
Conclusion
This article considers the security of the device man-
ager, a crucial and fundamental service in an SDIoT
controller. The profile database of the device manager
can be easily forged due to a lack of security mechanism
in this service. Several serious attack scenarios are thus
International Journal of Distributed Sensor Networks
Without proposed model With proposed model
4.602 s 4.970 s
1.12 ms 1.59 ms
performed according to the discovered vulnerability for
the device manager. The potential security solutions are
also examined, which cannot be applied directly in
SDIoT. Hence, a lightweight, dynamic countermeasure
is proposed and then evaluated through experiments.
The results show that the proposed defense method can
effectively prevent attacks on a device manager in
SDIoT networks in real time. Further experiments on a
large scale of devices will be conducted in future work.
Declaration of conflicting interests
The author(s) declared no potential conflicts of interest with
respect to the research, authorship, and/or publication of this
article.
Funding
The author(s) disclosed receipt of the following financial sup-
port for the research, authorship, and/or publication of this
article: This research was supported by the MSIT (Ministry
of Science and ICT), Korea, under the ITRC (Information
Technology Research Center) support program (IITP-2017-
2012-0-00646) supervised by the IITP (Institute for
Information & Communications Technology Promotion).
References
1. Evans D. The internet of things: how the next evolution
of the internet is changing everything. CISCO white
paper 2011; 4(2011): 1–11.
Nguyen and Yoo
2. Al-Fuqaha A, Guizani M, Mohammadi M, et al. Inter-
net of Things: a survey on enabling technologies, proto-
cols, and applications. IEEE Commun Surv Tut 2015;
17(4): 2347–2376.
3. Akyildiz IF, Su W, Sankarasubramaniam Y, et al. A sur-
vey on sensor networks. IEEE Commun Mag 2012; 40(8):
102–114.
4. McKeown N. Software-defined networking. INFOCOM
Keynote Talk 2009; 17(2): 30–32.
5. Kreutz D, Ramos FM, Verissimo PE, et al. Software-
defined networking: a comprehensive survey. Proc IEEE
2015; 103(1): 14–76.
6. Qin Z, Denker G, Giannelli C, et al. A software defined
networking architecture for the Internet-of-Things. In:
Proceedings of IEEE/IFIP network operations and man-
agement symposium (NOMS), Krakow, 5–9 May 2014,
pp.1–9. New York: IEEE.
7. TalebiFard P and Leung VC. Context-aware dissemina-
tion of information and services in heterogeneous net-
work environments. J Ambient Intell Humaniz Comput
2014; 5(6): 775–787.
8. Galluccio L, Milardo S, Morabito G, et al. SDN-WISE:
design, prototyping and experimentation of a stateful
SDN solution for WIreless SEnsor networks. In: Pro-
ceedings of IEEE conference on computer communications
(INFOCOM), Hong Kong, China, 26 April–1 May
2015, pp.513–521. New York: IEEE.
9. Liu J, Li Y, Chen M, et al. Software-defined Internet of
Things for smart urban sensing. IEEE Commun Mag
2015; 53(9): 55–63.
10. Jararweh Y, Al-Ayyoub M, Benkhelifa E, et al. SDIoT: a
software defined based Internet of Things framework. J
Ambient Intell Humaniz Comput 2015; 6(4): 453–461.
11. Floodlight controller, http://www.projectfloodlight.org/
12. POX controller, https://github.com/noxrepo/pox
13. OpenDaylight controller, https://www.opendaylight.org/
14. McKeown N, Anderson T, Balakrishnan H, et al. Open-
Flow: enabling innovation in campus networks. ACM
SIGCOMM Comput Commun Rev 2008; 38(2): 69–74.
15. Hong S, Xu L, Wang H, et al. Poisoning network visibi-
lity in software-defined networks: new attacks and
11
countermeasures. In: Proceedings of network and distribu-
ted system security (NDSS) symposium, San Diego, CA,
8–11 February 2015. Virginia: Internet Society.
16. Dhawan M, Poddar R, Mahajan K, et al. SPHINX:
detecting security attacks in software-defined networks.
In: Proceedings of network and distributed system security
(NDSS) symposium, San Diego, CA, 8–11 February
2015. Virginia: Internet Society.
17. Wang M, Liu J, Mao J, et al NSV-GUARD: constructing
secure routing paths in software defined networking. In:
Proceedings of the 6th international conferences on big data
and cloud computing, Atlanta, GA, 8–10 October 2016,
pp.293–300. New York: IEEE.
18. Pang C, Jiang Y, Li Q, et al. Detecting forwarding anom-
aly in software-defined networks. In: Proceedings of IEEE
international conference on communications (ICC), Kuala
Lumpur, Malaysia, 23–27 May 2016, pp.1–6. New York:
IEEE.
19. Adams C and Lloyd S. Understanding PKI: concepts,
standards, and deployment considerations. Boston, MA:
Addison-Wesley Professional, 2003.
20. Piotrowski K, Langendoerfer P and Peter S. How public
key cryptography influences wireless sensor node lifetime.
In: Proceedings of the fourth ACM workshop on security
of ad hoc and sensor networks, Alexandria, VA, 30 Octo-
ber 2006, pp.169–176. New York: ACM.
21. Amin F, Jahangir AH and Rasifard H. Analysis of
public-key cryptography for wireless sensor networks
security. Int J Comput Elec Autom Contr Inf Eng 2008;
2(5): 529–534.
22. Ling CH, Lee CC, Yang CC, et al. A secure and efficient
one-time password authentication scheme for WSN. Int J
Netw Secur 2017; 19(2): 177–181.
23. Lantz B, Heller B and McKeown N. A network in a lap-
top: rapid prototyping for software-defined networks. In:
Proceedings of the 9th ACM SIGCOMM workshop on hot
topics in networks, Monterey, CA, 20–21 October 2010,
p.19. New York: ACM.
24. Open vSwitch, http://openvswitch.org/
25. ARP spoofing, http://su2.info/doc/arpspoof.php
26. Wireshark, https://www.wireshark.org/