Sage Journals: Discover world-class research

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 redefines 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 vulnerability 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 managers 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

Introduction

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.¹ 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.² 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, difficulty in an orchestration, and virtualizing sensor network resources.³

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, programmable, and intelligent.^4,5 The major issues related to WSN and IoT can be solved if the advantages 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 technological 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, transportation, and smart infrastructure applications, any exposure of sensitive information (e.g. chat logs, patient medical records, financial data) is not acceptable.

In SDIoT, the device’s profile information is regularly updated by the device manager, which is a fundamental 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 performed on the device manager in the SDIoT controller. The vulnerabilities in the device manager allow an attacker to carry out device impersonation, eavesdropping, 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 lightweight 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 proposed 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, intelligent, self-configuring devices. The most important contributor in the IoT is WSN that is defined as intercommunication of distributed sensor nodes mainly related to monitoring and detection.³ In IoT, a large number of devices generate a huge amount of traffic that requires many processing operations to be converted into useful information. Moreover, any suspension 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 proposed 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 programming interfaces (APIs), which is explained as follows:

The application plane provides various applications and services, for example, traffic monitoring, security enhancements, topology discovery, load balancers. The application plane communicates with the control plane through north-bound interface APIs, and the control plane provides an abstraction of the network’s physical 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 example, Floodlight,¹¹ POX,¹² and OpenDaylight.¹³ The controller has a global vision of the full network 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.¹⁴

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 single packet processing or a Flow-Mod message to install new flow rules.^5,14

Figure 1.

Overview of the SDN architecture.

The benefits of SDN can be derived from four main features, including a network-wide visibility with centralized control, a flexible flow manager, a programmable 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.

Several previous studies have presented an integrated SDN with IoT, which is referred to as SDIoT. Qin et al.⁶ proposed an SDN controller design for the IoT network, which enables centralized flow scheduling according to the network calculus model. TalebiFard and Leung⁷ proposed an SDN-based scheme, which eliminates the rigidity of a conventional IoT network by granting dynamic reply to any shift in the environment. Galluccio et al.⁸ 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.⁹ proposed a software-defined IoT paradigm for separating smart urban sensing applications from underlying physical infrastructures. Recently, Jararweh et al.¹⁰ reported efforts in defining a generic high-level architecture 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, appliances, actuators), network infrastructure (e.g. switches, routers), SDN controller and IoT applications/services, as shown in Figure 2.

Figure 2.

SDIoT environment.

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 manager 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.¹⁵

Figure 3.

Device manager in SDIoT controller.

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, DHCP response, or IP packets. Therefore, it can identify 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 message, 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. TopoGuard¹⁵ is a security module in the controller that detects poisoning attacks on network visibility. SPHINX¹⁶ proposes a unified approach based on network 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 protect against most network topology attacks, they are powerless against complex attacks constructed by an adversary. NSV-GUARD¹⁷ 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 malicious routing policies generated by an unregistered routing applications. FADE¹⁸ 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 controllers contain a security mechanism to prevent malicious 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 networks. 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 vulnerability 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 information 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 illustrates the device impersonation attack where device B is the victim.

Figure 4.

Device impersonation attack in an SDIoT network.

To perform this attack, the attacker first sends the ARP request to the controller to probe the 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 network. 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 controller via the Packet-In message. Hence, the controller accepts the modification for the location of device A and device B to the location of the attacker. The controller 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.

Figure 5.

Eavesdropping attack in an SDIoT network.

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.

Figure 6.

Denial-of-service attack in an SDIoT network.

Potential solutions from traditional networking

A cryptographic technique, that is, public key infrastructure (PKI),¹⁹ may be used to solve this problem. The PKI establishes and maintains a trustworthy networking 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 information, using the controller’s public key and will sign it using the device’s digital signature. The digital signature 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 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 controller 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 migration 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 computational cost of the asymmetric algorithm such as PKI.²⁰ 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.²¹

Due to the limited computing and memory capability of the IoT devices, Ling et al.²² 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 contain a pre-shared secret value which is a random number 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 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 sender and has not been changed in transit. After successful 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 verification mechanism to check the spoofed packet. Hence, the authenticated device can still send the spoofed packet to change the information in the device database. 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 contents of the message.

Figure 7.

The controller without the spoofed packet-checking mechanism.

To address this issue, we propose a novel model, which is referred to a security patch for the device manager in the controller, as shown in Figure 8. The proposed 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 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 suspended by the proposed model. The details are shown below.

Figure 8.

The proposed device manager.

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 information 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 timestamp. Furthermore, the authentication status is necessary for the check-up and monitoring measurements.

Table 1.

The suggested structure format of the Device Profile Database.

Number	MAC address	IP address	Authentication status	Switch and port	Last seen timestamp
1	00:00:00:00:00:01	10.0.0.1	True	sw1, 1	11:13.45 26.12.2016
2	00:00:00:00:00:02	10.0.0.2	False	sw1, 2	09:13.33 27.12.2016
3	00:00:00:00:00:03	10.0.0.3	False	sw2, 1	N/A

Authenticator

The newly connected devices must be authenticated by the controller. In this module, we adopt the efficient and secure OTP authentication proposed by Ling et al.²² The used authentication method establishes a session key to encrypt the transmitted messages. Upon successful authentication, the authentication status of the device will be updated in the Device Profile Database.

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

Figure 9.

The controller using Port Monitoring in the device manager.

Evaluation

Our experiment is conducted using the Linux-based Mininet 2.2.1,²³ which provides a scalable platform to emulate the SDN network via virtualization. The proposed defense mechanism is implemented using the Floodlight 1.2 controller.¹¹ We also use Open vSwitch 2.5.1,²⁴ a software-based virtual SDN switch with the support of the OpenFlow protocol. The attack tools are ARP-spoof 1.5²⁵ and Wireshark 1.21.1.²⁶ All experiments 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 repeatedly 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 controller 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.

Figure 10.

Successful eavesdropping attack on the Floodlight controller.

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, which is a major cause of the device impersonation, eavesdropping, and DoS attack, can be prevented. Figure 11 shows the successful detection when a spoofing attempt occurs.

Figure 11.

Successful detection of the attacks on the device manager in the Floodlight controller.

We also consider the performance overhead of the controller 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 proposed countermeasure in terms of the processing time for device discovery of 100 devices and the average processing time per Packet-In message. The authentication mechanism 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.

Table 2.

The computational overhead of the controller.

Measure	Without proposed model	With proposed model
Processing time for device discovery of 100 devices	4.602 s	4.970 s
Average processing time per Packet-In message	1.12 ms	1.59 ms

Conclusion

This article considers the security of the device manager, 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 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.

Footnotes

Academic Editor: Davide Brunelli

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 support 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

Evans

. The internet of things: how the next evolution of the internet is changing everything. CISCO white paper 2011; 4(2011): 1–11.

Al-Fuqaha

Guizani

Mohammadi

et al . Internet of Things: a survey on enabling technologies, protocols, and applications. IEEE Commun Surv Tut 2015; 17(4): 2347–2376.

Akyildiz

Sankarasubramaniam

et al . A survey on sensor networks. IEEE Commun Mag 2012; 40(8): 102–114.

McKeown

. Software-defined networking. INFOCOM Keynote Talk 2009; 17(2): 30–32.

Kreutz

Ramos

Verissimo

et al . Software-defined networking: a comprehensive survey. Proc IEEE 2015; 103(1): 14–76.

Qin

Denker

Giannelli

et al . A software defined networking architecture for the Internet-of-Things. In: Proceedings of IEEE/IFIP network operations and management symposium (NOMS), Krakow, 5–9 May 2014, pp.1–9. New York: IEEE.

TalebiFard

Leung

. Context-aware dissemination of information and services in heterogeneous network environments. J Ambient Intell Humaniz Comput 2014; 5(6): 775–787.

Galluccio

Milardo

Morabito

et al . SDN-WISE: design, prototyping and experimentation of a stateful SDN solution for WIreless SEnsor networks. In: Proceedings of IEEE conference on computer communications (INFOCOM), Hong Kong, China, 26 April–1 May 2015, pp.513–521. New York: IEEE.

Liu

Chen

et al . Software-defined Internet of Things for smart urban sensing. IEEE Commun Mag 2015; 53(9): 55–63.

10.

Jararweh

Al-Ayyoub

Benkhelifa

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

Anderson

Balakrishnan

et al . OpenFlow: enabling innovation in campus networks. ACM SIGCOMM Comput Commun Rev 2008; 38(2): 69–74.

15.

Hong

Wang

et al . Poisoning network visibility in software-defined networks: new attacks and countermeasures. In: Proceedings of network and distributed system security (NDSS) symposium, San Diego, CA, 8–11 February 2015. Virginia: Internet Society.

16.

Dhawan

Poddar

Mahajan

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

Liu

Mao

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

Jiang

et al . Detecting forwarding anomaly 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

Lloyd

. Understanding PKI: concepts, standards, and deployment considerations. Boston, MA: Addison-Wesley Professional, 2003.

20.

Piotrowski

Langendoerfer

Peter

. 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 October 2006, pp.169–176. New York: ACM.

21.

Amin

Jahangir

Rasifard

. 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

Lee

Yang

et al . A secure and efficient one-time password authentication scheme for WSN. Int J Netw Secur 2017; 19(2): 177–181.

23.

Lantz

Heller

McKeown

. A network in a laptop: 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/