NETRA: Enhancing IoT Security using NFV-based Edge Traffic Analysis

05/28/2018 ∙ by Rishi Sairam, et al. ∙ National University of Singapore 0

This is the era of smart devices or things which are fueling the growth of Internet of Things (IoT). It is impacting every sphere around us, making our life dependent on this technological feat. It is of high concern that these smart things are being targeted by cyber criminals taking advantage of heterogeneity, minuscule security features and vulnerabilities within these devices. Conventional centralized IT security measures have limitations in terms of scalability and cost. Therefore, these smart devices are required to be monitored closer to their location ideally at the edge of IoT networks. In this paper, we explore how some security features can be implemented at the network edge to secure these smart devices. We explain the importance of Network Function Virtualization (NFV) in order to deploy security functions at the network edge. To achieve this goal, we introduce NETRA - a novel lightweight Docker-based architecture for virtualizing network functions to provide IoT security. Also, we highlight the advantages of the proposed architecture over the standardized NFV architecture in terms of storage, memory usage, latency, throughput, load average, scalability and explain why the standardized architecture is not suitable for IoT. We study the performance of proposed NFV based edge analysis for IoT security and show that attacks can be detected with more than 95



There are no comments yet.


page 2

page 3

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

Internet of Things (IoT) is a technology that facilitates interaction between physical and digital world. It is comprised of sensors and other electronic equipments that are remotely controlled using the existing network infrastructure. A recent Gartner report [1] says, by 2021, $2.5 million per minute will be spent on these devices. IoT generates tonnes of data that can be extracted to give better quality of life by providing value-added services such as home automation, health care, industry automation etc. Though it is expected to change our lives rapidly, with huge volume of data on the network, it is exposed to general security threats such as denial of service (DoS) attacks and other cyber attacks. Thus, an important question is : how secure are these IoT devices?

Recent attacks like Mirai [2], IoTroop and Stuxnet answer the above question very well. These attacks focused to make use of vulnerabilities in IoT devices itself. With the emergence of low cost devices and cut-throat competitions, manufacturers rush these IoT devices to the market almost without any security features or with very minimal ones. Also, these low cost tiny resource-constrained devices are not fit to use conventional IT security measures. Hence, there is a pressing need to improve security in the IoT environment. Lots of research has been done on how to make the current security systems more robust and viable to take care of IoT [3]. As the IoT device level security is erratic, incorporation of security features at network edge may help securing these devices. In this paper, we focus to push our research towards the network edge i.e. more closer to the IoT devices.

Due to the massive number of heterogeneous devices, defining static rules for security purposes will not help. Instead, individual traffic analysis of these devices is required to understand their usual pattern and anomalous traffic. If this analysis is done in a centralized manner, scalability issues will arise. Thus, pushing the traffic analysis to the network edge will be helpful. Machine learning is used to cater various security needs of today’s networks 

[4]. In this paper, we make use of machine learning algorithms to perform traffic analysis at the network edge, thus deeming it useful for the IoT environment.

At the network edge, usually we find devices with lower computational capabilities such as IoT gateways, home routers etc. The challenge is to implement security features for IoT at these edge infrastructure. For this purpose, Network Function Virtualization (NFV) can be used. NFV is a technique by which we can virtualize the traditional network functions using their software counterparts. The use of NFV technology to provide IoT security has been attracting the attention of researchers recently. The number of companies that are pushing the research and development of NFV paradigm is growing steadily since NFV can improve cost efficiency, flexibility, performance and reduce the capital expenditures (CAPEX) and operational expenditures (OPEX).

The network functions that are implemented are called as virtual network functions or VNFs and are usually deployed on high-capacity servers or cloud infrastructure. Given the low computational requirement at the network edge i.e. IoT gateway, we need a virtualization technique that is lightweight and scalable [5]. As an alternative, Docker containers promise one such environment, which open up opportunities for the security functions to be implemented as Docker VNFs.

Feature Docker Virtual Machines
Start time 50 ms 30 - 45 seconds
Stop time 50 ms 5 - 10 seconds
System Overhead No overhead Overhead due to hypervisor
Storage space Tens of MBs in size Tens of GBs in size
Scalability Highly scalable Not easily scalable
CPU load when idle Normal 1.5% more than docker
Isolation Less isolation due to software virtualization More isolation due to hardware virtualization
Network round trip latency 75 s 60 s
I/O throughput (Read and Write) 100000 I/Os per second 50000 I/Os per second
TABLE I: Comparison of Docker and Virtual Machines

A Docker container is a stand-alone and light-weight executable package of software that includes everything needed to run it: code, settings, system libraries and system tools [6]. Containers isolate the software running in it from its surroundings thus giving us a software level isolation unlike the hardware level isolation of virtual machines (VMs). Architecture of both VMs and Dockers are shown in Fig. 1.

Fig. 1: Architectural Comparison of VMs and Dockers.

In Fig. 1, we can see that the hypervisor in VM, is replaced by the docker engine in containers. Containers are smaller than VMs that enable faster start up with better performance, less isolation and greater compatibility due to sharing of the host’s kernel. Also, huge disk space can be saved as bulky guest operating systems for each application, are not required. Each application can be built into a docker image and hosted in cloud. It results in zero building time as the same docker image can be used to spawn many docker instances of the same application. The other key differences between VMs and Dockers are shown in Table I.

In this paper, NETRA– a novel Docker based architecture is introduced for virtualizing network functions at IoT gateway. Here, each network function can be fetched from the cloud and deployed immediately onto the IoT gateway. Using the architecture, we implement VNFs that can improve the security of IoT environment and test using IoT devices like smart cameras, smart sockets etc. We collect real time traffic from a TP-Link smart camera to train our edge-analysis VNF discussed in Section III. Our models are able to successfully detect attacks with 95% accuracy in nearly a second.

The rest of the paper outlines the way to harness the power of Dockers and NFV to provide a secure platform for IoT. First, differences between the existing VM-based platform and the proposed Docker-based architecture are discussed. Later, performance evaluation is presented. Finally, we discuss related works in this domain before making concluding remarks.

Ii Architecture

In the domain of network function virtualization, number of research and development activities are going on to provide a robust and efficient platform. One such standardized platform is the Open Platform for Network Function Virtualization or OPNFV [7]. It is patronized by leading companies and organizations. OPNFV provides a platform for the development and evolution of many NFV components that can be deployed in various open source ecosystems. In this paper, we propose NETRA – a new architecture for deploying virtual network functions in low computational devices at the network edge like the IoT gateway. In order to compare, we have implemented both the architectures. In this section, we describe the existing VM-based architecture (OPNFV) and our proposed architecture using Docker containers (NETRA).

Ii-a VM-based Architecture

OPNFV (Open Platform for NFV) is basically an open-stack environment for deploying various VNFs using VMs. OPNFV provides various installers like Compass, Fuel etc., for deploying the same. Because of the ease of use, Fuel [8] has been selected and 5 VMs are created to set up the environment. Fig. 2 shows the high-level view of the environment based on the OPNFV architecture. We describe each of the three layers in the architecture below.

Fig. 2: OPNFV based OpenStack deployment of NFVs.

Ii-A1 OPNFV Master

This is the layer where the OPNFV master is deployed. In our case, it is the Fuel Master, which is responsible for deploying the OPNFV nodes in the bottom layers. As shown in Fig. 2, the master has a dedicated network card for each of the operations like administration, management, storage etc. It is important to note that this layer does not appear at the network edge rather it resides one layer above the nodes.

Ii-A2 OPNFV Nodes

This layer is the crux where the VNFs are deployed and it depicts the network edge in IoT scenario. We deployed 3 nodes or PODs (Point of Devices) that act as various elements of a NFV-based IoT environment. One VM is running OpenDayLight controller and the other two nodes are emulating different network functions (WAP and firewall). One of the biggest problems with an open stack deployment is the need for PXE booting ability, which is very unlikely to be present in the devices at this layer. Another noteworthy point is that, each of the nodes acts as a VNF, which implies that multiple VMs are required at the network edge.

Ii-A3 Client Layer

The client layer is at the user end wherein the Fuel client can be accessed using a web interface. Using the Fuel client, one can deploy various VNFs with the help of the OPNFV master. In our experiment, we deployed the nodes detailed above with the help of the OpenStack interface through the Fuel client.

In [9], it is discussed that IoT gateways have nearly the same specifications as that of a Raspberry Pi 3. Therefore, we model the network edge device with the help of a Raspberry Pi in this deployment. During the deployment, we noticed few shortcomings of OPNFV which renders it not suitable for use at network edge. The deployment of OPNFV demands at least 3 nodes (VMs) for deployment. This may be useful at an enterprise level environment. But it is futile to employ such an architecture at the edge of IoT network because the edge devices (i.e. IoT gateways) are of limited resource.

As explained later in Section IV, this approach is not beneficial for the network edge scenario. Typically, the VMs in the OPNFV architecture require high computational abilities that cannot be expected at the network edge. Also, the deployment times are also very slow with OPNFV. Though OPNFV provides a standardized approach for deploying VNFs, it is not feasible enough to be used at the edge of IoT network.

Ii-B Proposed Docker-based architecture

Having said about the issues faced by OPNFV, we require a robust and efficient architecture that can facilitate the deployment of VNFs at the edge of the network. In this section, we present our Docker-based architecture – NETRA for NFV-based Edge TRaffic Analysis. The proposed architecture helps in creating and deploying VNFs in low computational devices. Fig. 3 shows a high-level view of our proposed architecture. Layers of the architecture are discussed in detail below.

Fig. 3: Proposed Docker-based architecture with a Raspberry Pi at network edge.

Ii-B1 Core Network

In this layer, connections to the cloud servers are routed through the Internet Service Provider (ISP). When IoT devices in the lowest layer, are activated, they talk with their respective cloud servers viz. D-Link devices talk with D-Link cloud. In this layer, we have the Docker Hub, which is a repository for all the Docker images that we have created. The Docker images can be deployed from this layer with a docker pull command. When a new VNF has to be deployed, it only takes a couple of minutes to build and run the Docker VNFs.

Ii-B2 IoT Gateway

This layer represents the actual network edge of the IoT scenario. In our implementation, we use a Raspberry Pi 3 as the IoT gateway, which hosts various Docker VNFs. The IoT devices connect to the network that is created using the Wireless Access Point (WAP) VNF described in Section II-C. The communication between the IoT devices and external world go through this layer. Thus attacks can be detected and mitigated at this layer. As seen in the Fig. 3, we deploy a chain of multiple VNFs with the Raspberry Pi designated as an IoT gateway. This chain of VNFs work in tandem. We deploy security VNFs like firewall, intrusion detection, software defined networking (SDN) switch, edge analytics etc. as described in Section II-C.

Ii-B3 IoT Environment

In this layer, we have the smart things or the IoT devices that are connected to the Internet through the above layers. In our lab, we use devices like smart bulbs, IP cameras, smart remote controllers, smart sockets etc.

The architecture can be further extended with an SDN controller managing the Open vSwitch running on the IoT gateway as a VNF. As discussed in earlier sections, containers are light-weight and can be used to run any application with a very low overhead and faster deployment times. NETRA also addresses the core issue of OPNFV which requires at least three nodes at the edge. Here all the VNFs are on the same device, yet isolated. The performance comparisons between the two architectures in Section IV validate the fact that dockerizing VNFs is an effective way for bringing NFV to edge of the network.

Ii-C Virtual Network Functions for IoT Security

With the comprehensive analysis of the two architectures, it is evident that for an IoT environment, Docker-based VNFs are the best suitors. We implement some VNFs, those when coupled together, form an IoT gateway that is secure by itself and is lightweight at the same time. The details about the implemented VNFs are explained below.

Ii-C1 WAP as VNF

In order to serve as an IoT gateway, the Raspberry Pi must be able to connect to the devices and forward the packets to Internet. To facilitate this, the WAP VNF creates a wireless access point for the IoT devices to connect using the hostapd package and also acts as a DHCP server by running udhcpd. Since the Raspberry Pi is connected to the Internet through Ethernet port, a simple masquerading rule will help in forwarding the packets.

Ii-C2 Firewall

One of the most important yet simplest security function that any system demands is the firewall. Using this VNF, we create firewall rules to block a malicious user. The firewall rules are applied with the help of the iptables package. In case the user needs to be unblocked, we just need to stop the docker instance corresponding to that user’s MAC.

Ii-C3 Ids

Intrusion Detection Systems (IDS) are generally heavy on the processor and memory due to their large rule sets and continuous traffic analysis. In order to create a light weight version of IDS, we use minimalistic rules pertaining to the IoT environment on top of snort package running with low memory option. When the IDS VNF detects a malicious activity, it instructs the WAP VNF to kick out the malicious user and spawns the firewall docker VNF to block the user.

Ii-C4 Software Defined Switch

The Software Defined Switch is an advanced VNF added to the IoT gateway. This VNF uses Open vSwitch and harnesses the power of software defined switches in managing the flows in and out of the network.

Ii-C5 Edge Analytics

This VNF performs traffic analysis at the network edge using machine learning algorithm as discussed in Section III for detecting and mitigating malicious attacks. The detection phase comprises of two stages : anomaly detection and attack detection. When the incoming traffic is detected as anomalous, the traffic is analyzed to ascertain the type of attack. After successful detection, we mitigate the attack using the software defined switch mentioned above.

Iii Edge Traffic Analysis

In this section, we discuss about the edge traffic analysis using NFV and machine learning (ML). We encapsulate the algorithms discussed below in an Edge Analytics VNF at the IoT gateway itself. We first extract the features for training our ML models so that we can detect anomalies in real time. The scapy

library in Python is used for performing the feature extraction using Algorithm 

1. We propose a majority vote type detection wherein three models detect whether the given datapoint comes from a malicious packet or not using Algorithm 2. Once an anomaly is detected, the attack detection module is spawned to identify whether it is a known attack and proper mitigation is achieved through the software defined Open Virtual Switch (OVS) VNF.

Iii-a Feature extraction

In order to have efficient detection, it is of utmost importance to have proper features to carry out the detection. Carefully selected features aid in creating an accurate predictive model. In our algorithm, the scapy librabry is used for extracting the packets and features. For the training data, we connected a TPLink camera to the raspberry pi and collected packets in different scenarios: 1) with benign traffic flows, 2) while attacking the camera with SYN flooding and 3) while attacking the camera with ICMP flooding. SYN and ICMP flooding are carried out using hping3 tool found in the Kali Linux distro connected in the same network. Wireshark tool is used to capture data in all the three scenarios and this datafile (.pcap file) is given as the input to Algorithm 1.

Input: pcap, dev-IP, attack-IP
      Output: featurelist (or) datapoint

1:if online then
2:      sniff packet
3:     extract packet (pcap, dev-IP)
5:     extract packet (pcap, dev-IP)
7:     for session do
9:         if IP == attack-IP then
10:               X represents the attack index
11:         end if
12:     end for
13:end if
Algorithm 1 Feature Extraction

In Algorithm 1, a sampling time is set to process the packets. This sampling time (samp) is expected to be in the order of seconds depending on the amount of packets at hand. When we have the pcap file, the training data gets generated and is called offline feature extraction. Once we have a model, the algorithm switches to an online mode, wherein real-time traffic is collected and extracted. The features are extracted in sessions that is dependent on the packet length (pktlen) and the previously set sampling time. Once the packet is extracted, we extract the features like SYN flag, ACK flag, PUSH flag, URG

flag, protocol, mean of packet duration, variance of packet length, mean of arrival times, variance of arrival times, total number of packets etc. A total of 21 features are chosen out of many as the prediction was not affected by adding more features. The training data is labeled, whether it is clean or SYN flood or ICMP flood, with the help of the attacker IP and attacker protocol. During online feature extraction, the packets are filtered using the device’s IP and protocol.

Iii-B Anomaly Detection

Anomaly detection is the technique that helps us in identifying any unusual pattern that does not match with expected behavior. Outliers detection or anomaly detection can thus be used to find any malicious activity going on in the network, if we can model the usual activities 


Input: clean data, attacked data (or) datapoint
      Output: prediction

1:if training then
2:      datapoints(clean csv)
3:      datapoints(attacked csv)
10:      Testing the model
16:end if
17:if  then
18:     Anomaly Detected
19:     attack_detection(datapoint)
20:end if
Algorithm 2 Anomaly Detection

The training data is obtained by capturing packets when there is no malicious activity and is further used to train the models of the usual behavior. Three models are considered for detection, namely:

  • One-Class SVM : One of the popular algorithms that learns a decision function for outliers detection is One-Class Support Vector Machine (SVM) and is used to classify new data as either similar or anomalous. The decision rule of the One-Class SVM is given by Equation 

    1 [11].


    where is the sign function, are the Lagrange functions that support the machine and is the kernel function. In our model, the radial base function (RBF) is chosen as the kernel.

  • Isolation Forest : Instead of constructing a model for the normal activities (packets in our case) and then identifying the outliers, Isolation Forest follows a model-based method that explicitly isolates anomalies. It does that through an algorithm that has a linear time complexity with a low constant and a low memory requirement [12]. The algorithm calculates an anomaly score (given by Equation 2) to distinguish between normal cases and anomalies.


    where is the average path length of a point x in the tree and is the average path length of an unsuccessful search in the binary search tree.

  • Elliptical Envelope : The Elliptical Envelope package uses the covariance between the features to detect anomalies in a Gaussian distributed dataset. It basically tries to find an elliptical boundary that can hold most of the data. Any data that falls outside this boundary is classified as anomalous. This model uses the FAST-Minimum Covariance Determinate method

    [13] to find the size and shape of the ellipse with the help of the Mahalanobis distance shown in Equation 3.


    where is the data vector and its mean. Equation 3 basically measures the deviation of a data vector from its mean.

For testing the model, we generate a simple SYN flood attack on the IoT device and extract features using Algorithm 1. Our majority voting model has helped in reducing the number of false positives and missed detections. If the model detects an anomaly, it returns -1 and if not, returns 1. As shown in Algorithm 2, we predict whether the test data is malicious or benign using all the three models and decide using majority votes. This way we harness the advantages of all the three models combined to get efficient detection. This algorithm runs inside a docker VNF in the IoT gateway to detect anomalies (malicious activities) in the environment. In order to detect the attack and block the malicious user, we call the attack detection algorithm once an anomaly is detected.

Iii-C Attack Detection and Mitigation

The attack detection module gets its input data point from the anomaly detection module, when the latter classifies it as being malicious. Once it gets its data point, it follows Algorithm 3 to detect the kind of attack and spawns the mitigation process if it is a known attack.

Input: labeled_data, datapoint
      Output: attack_type

1:if training then
8:      Testing the model
9:      Classification Error
12:     if  NORMAL then If not benign
13:         call OVS vNF
14:     end if
15:end if
Algorithm 3 Attack Detection

For this module, we took training data while attacking the IoT device using SYN flooding and ICMP flooding and labeled the data accordingly using Algorithm 1. Similarly, more attack signatures can be given. The model is tested with the same labeled data set by having a 60:40 split for training and testing respectively. We chose the RandomForest classifier for its high accuracy and effective classification.

Random Forest basically builds multiple decision trees and couples them all to form a stable and accurate prediction. Important reason for choosing Random forest is its ability to rank features based on importance, which we will observe in Section IV-B. Another advantage of this classifier is its randomness, due to which over-fitting problem is avoided [14].

Algorithm 3 is thus quite straightforward in its operation. It detects whether the data point from the anomaly detection module is a known attack or not. If yes, it calls the Open vSwitch VNF and applies appropriate flow rules to block the malicious traffic.

(a) Memory comparison between the two architectures.
(b) Memory usage of multiple docker instances.
(c) Latency comparison based on ICMP.
(d) Latency test between external host and docker containers using various sized ping requests.
Fig. 4: Memory requirements and Latency comparison.

Iv Performance Study

Iv-a Efficiency of Proposed Architecture (NETRA)

In this section, we compare the two architectures - VM-based (OPNFV) and Docker-based (NETRA) - in terms of key performance indicators such as storage, memory, latency, network and scalability [15]. Also, we discuss how a container based architecture helps us in deploying multiple VNFs in a single host/device.

All these results are based on the experiments carried out in lab setup. For the OPNFV architecture, the VMs were built on top of a performance laptop having Intel i5 7th generation processor, 16 GB RAM and 2TB HDD. For NETRA, the Raspberry Pi 3 Model B has a 1.2 GHZ quad-core ARMv8 Cortex A53 processor and a Broadcom IV GPU with 1 GB DDR2 RAM and in-built WLAN NIC.

Iv-A1 Storage

In the case of OPNFV, there are minimum size requirements that need to be met before deploying an open stack environment. For a node that acts as the SDN controller (based on OpenDayLight) with Ceph storage, OPNFV demands 72GB storage. Similarly, a typical VNF node with just the operating system requires a minimum of 25GB storage, which is very unlikely for a network edge device.

In the case of NETRA, we can have multiple VNFs on a Raspberry Pi which has only 16G of storage. Based on our experiments, a single Raspbian image takes up only 126MB, our WAP VNF image takes 182MB and our firewall VNF takes up 157M. The docker instances use still lower sizes with firewall instance taking 222B of storage and WAP instance taking only 18 KB of storage.

Iv-A2 Memory

As mentioned in Section II, OPNFV requires the nodes to be PXE bootable. Based on our tests, PXE booting with Fuel [8] required at least 1GB of RAM for each of the nodes. The controller node had higher memory requirement of 2GB for running the java based OpenDayLight controller. In our case, the Raspberry Pi 3 comes with only 1 GB of RAM. But due to the very low memory foot prints of docker, we are able to instantiate many VNF instances using the same.

The memory comparison of the two architectures is shown in Fig. 3(a). We observe that the memory of the node is high due to the OS, which shoots up even more after starting the hostapd service in the node. The peaks in the memory line indicate the start of a docker instance. It can be noted that each docker instance takes up only 1MB of RAM, which makes docker the best choice for VNFs at the IoT gateway.

Fig. 3(b) shows the memory graphs of the Raspberry Pi as a host when multiple docker containers are launched. We see that the memory requirements of the docker instances are very low and differ in the order of only 1 MB with 4 different tests. The experiments were done by instantiating up to 4 docker instances simultaneously in repeated iterations. The peaks in the graphs explain the start of the docker instance, which later come down.

Iv-A3 Latency

When working with a chain of VNFs, it is important to ensure that the latency between two VNFs is as low as possible. In this section, we compare the latency between different VNFs in both the architectures with the help of pinging the nodes through ICMP. Fig. 3(c) shows that the latency between the nodes in OPNFV is higher as compared to the dockerized VNFs. This is due to the fact that, the docker VNFs are in the same host while the VNFs in OPNFV are in different VMs. We also note that the latency between the IoT device and WAP VNF is quite high (10.2 ms), this is because, the device is connected wirelessly to the WAP, where the losses are quite high.

We carry out experiments to measure the latency with different sizes of ping command. In Fig. 3(d), we observe that the latency is small on the order of milliseconds.

Iv-A4 Network

Though the latency in NETRA is very less compared to OPNFV, the number of network interfaces is limited in our case, as the Raspberry Pi comes with only 2 NICs. In the case of OPNFV, the nodes have as many NICs as the VM can support.

With many NICs, we can have many services like administration, orchestration, management communicating without interference. But this comes with a trade-off, with more connections, each connection requires a higher bandwidth link, which is expensive. In NETRA, high bandwidth between the VNFs is ensured since all the VNFs are practically on the same device.

Configuration Bandwidth
Buffer Size
TCP (1 thread) 16.8 43.8
TCP (3 threads) 5.6 43.8
UDP 1.05 160
UDP with 100 Kbps bandwidth 0.1 160
TABLE II: Throughput tests with iperf tool

To calculate the throughput performance of docker containers, we make use of the iperf tool available in Linux platforms. As shown in Table II, we carry out simple iperf tests which involve data transfer between the iperf client, the Docker instance and an iperf server. A total of four tests are carried out, the first one involving a TCP connection, the second one with 3 parallel connections (the resulting throughput is per connection), the third one with an UDP connection which results in 2650 datagrams to be exchanged while the other test involving a constrained bandwidth of 100 kbps resulted in only 267 datagrams.

Iv-A5 Average Load

Another important performance metric to be considered is the average load of the host running the dockers. The dockers should not use up the resources of the host during their working. With low performance hosts as in our case, it is very important to have a stable average load in the long run. Fig. 5 shows the average load of the Raspberry Pi running 4 docker instances. We see that the 1-minute average increases with each docker instance, but the long-term averages remain stable, implying that the system is still stable. With these results, we can vouch that the Docker containers indeed consume very little resources and thus scale with even low performance edge devices.

Fig. 5: Average load of the host from top command.

Iv-A6 Scalability

The last, but important performance metric is scalability. We can clearly see from the storage and memory requirements that NETRA is very much scalable. For example, we can have hundreds of firewall VNFs with individual rule sets running on a simple raspberry pi having very less computational strength.

Another important aspect of scalability is the deployment times. In order to be scalable, the Docker environment should also provide faster deployment time. In Table III, we can see that the deployment time in running a Docker instance is as low as a second. Time for building the image for the first time, where it downloads everything from the cloud, is nearly 5 mins for our WAP VNF. In the case of OPNFV, we note that we cannot expect such short deployment time. This can be clearly seen from Table III as bringing up a complete node takes nearly 15-20 minutes.

Process Time taken
OPNFV Bring up a VNF minutes
OPNFV Start/Stop a VNF minutes
HostAP Docker Time to build container for the first time 2 minutes and 20 seconds
Firewall Docker Time to build container for the first time 4 minutes and 16 seconds
HostAP Docker Time to build container 9 seconds
Firewall Docker Time to build container 5 seconds
HostAP Docker Time to run container second
Firewall Docker Time to run container second
TABLE III: Deployment Time for VNFs

Iv-B Performance of NFV-based Edge Analysis for IoT Security

Feature Selection

We gather many features of the network traffic. Few of the features are selected based on their importance ranking to classify the traffic. In Fig. 6, features are plotted according to their importance/ranking that can be found using the feature_importance package in the RandomForest library.

Fig. 6: Feature ranking in terms of importance

Additionally, we analyze the features using Principal Component Analysis (PCA) with two components, that reduces the feature set to a two dimensional space. It is evident from Fig. 

7 that the data points from Normal and Attacked traffic are well separated and thus distinguishable.

Fig. 7: PCA component analysis
Traffic Classification

We perform experiments to choose the appropriate classifier in terms of efficiency of attack detection. In this experiment, we consider SYN attack, ICMP attack to be distinguished from normal traffic. In Table IV

, confusion matrix for different classifiers are presented. From the table, we observe that Random Forest is able to classify 626 out of 633 data points as normal traffic. One can see the diagonal elements of the confusion matrix to visualize the efficiency of the classifier. We calculate the accuracy for each of the classifiers as


where, TP, TN and FP, FN refer to True Positive, True Negative, False Positive and False Negative, respectively.

It is observed that Random Forest

classifier detects the attacks more accurately among others. This is evident as prior research shows Random Forest gives more accurate results than SVM or Logistic Regression with a multi-class data set 


Normal SYN attack ICMP attack
Linear SVM (Accuracy : 94.444%)
Normal 622 11 0
SYN attack 58 201 0
ICMP attack 0 0 350
Logistic Regression (Accuracy : 85.587%)
Normal 631 2 0
SYN attack 177 82 0
ICMP attack 0 0 350
KNN (Accuracy : 95.088%)
Normal 626 7 0
SYN attack 52 207 0
ICMP attack 1 1 348
Random Forest (Accuracy : 95.4911%)
Normal 626 7 0
SYN attack 49 210 0
ICMP attack 0 0 350
TABLE IV: Confusion Matrix
Response Time

The response time of the VNF is defined as the time difference between initiation and detection of the attack. We carried out a series of tests and found that the average response time of the VNF is less than a second.


During the attack the throughput abruptly increases before detection of the attack and subsequent mitigation. Abrupt increase of throughput (in the scale of thousands of bytes) due to attacks (TCP, ICMP flooding) can be observed in Fig. 8. Due to this surge in throughput, these attacks can be identified easily and mitigated. The attacks are carried out on IoT devices like TP-Link camera, D-Link smart camera etc. However, after attack mitigation is initiated by concerned VNFs, normal traffic is restored i.e. throughput drops down to hundreds of bytes.

Fig. 8: Increase in network throughput due to attacks

V Related Work

In this section, we present the existing works in the field of NFV and docker containers.

In [17], the advantages of using containers over the existing virtual machine solutions are discussed for virtualizing network components. It is stated that container-based environment provides lower latency and delay variations due to the usage of lower-performing networking schemes. Deployment of a container-based virtualized LTE core network is discussed in [18]. The scope of the work was to deploy OpenEPC, an EPC (LTE Evolved Packet Core) implementation using Docker containers. A framework for deploying VNFs in a light-weight Docker-based container environment is discussed in [19, 20]. The proposed OpenNetVM is a highly efficient packet processing framework is highly suited for high performance network environments that use complex service chains.

In [9], the opportunities of virtualizing at the network edge is discussed and Glasgow Network Function (GNF), a container-based NFV platform that spawns lightweight container VNFs, is presented. It is shown that this approach saves up the core network utilization and provides a lower latency. Requirements of IoT edge computing is discussed in [21]. Lightweight virtualization technologies, containers and unikernels, are compared as platforms for enabling scalability, security and manageability in IoT edge computing. In [22], various cybersecurity challenges and opportunities of IoT edge computing are discussed. An approach for enforcing global security policies in the federated cloud and IoT networks, by implementing the policies on network slices, is described in [23]. NFV and Service Function Chaining (SFC) are used here for implementing the security policies. While these works outline the possibility of using lightweight containers, they do not carry out implementation in the context of IoT edge security. Different from these works, we propose a novel lightweight Docker-based architecture for virtualizing network functions to provide IoT security, implement and carry out performance study.

Vi Conclusion

In this paper, we proposed NETRA- a light-weight Docker-based framework for deploying VNFs at the network edge in order to make NFV compliant with IoT environment. We described how this framework can be applied to enhance the security of IoT. We presented traffic analysis at the network edge for IoT security. This work suggests that NFV will greatly benefit from container-based virtualization. Experimental results have shown that Docker-based VNFs perform well for IoT than existing VM-based frameworks. Using the architecture, VNFs that can improve the security of IoT environment were implemented and tested using IoT devices like smart cameras, smart sockets etc. Real time traffic from a TP-Link camera were captured to train the edge-analysis VNF which is able to successfully detect attacks with approximately 95% accuracy within a second. The known attacks are mitigated using appropriate VNFs, and we will study the handling of zero-day attacks in future work. With this work, it is now possible to envisage a scenario where all security VNFs can be deployed at the IoT gateway itself effectively. Our research motivates further investigation in improving security of IoT devices at the network edge with the use of lightweight containers, thus resulting in a smart and secure world of things.


  • [1] Top strategic predictions for 2017 and beyond: Surviving the storm winds of digital disruption. Accessed on 24th April 2018. [Online]. Available:
  • [2] Mirai Malware 2016,, [Online; accessed 24-04-2018].
  • [3] K. Sood, S. Yu, and Y. Xiang, “Software-defined wireless networking opportunities and challenges for Internet-of-Things: A review,” IEEE Internet of Things Journal, vol. 3, no. 4, pp. 453–463, 2016.
  • [4] L. Xiao, X. Wan, X. Lu, Y. Zhang, and D. Wu, “Iot security techniques based on machine learning,” arXiv preprint arXiv:1801.06275, 2018.
  • [5] S. Natarajan, R. Krishnan, A. Ghanwani, D. Krishnaswamy, P. Willis, and A. Chaudhary, “An analysis of lightweight virtualization technologies for NFV,” IETF Draft, 2017.
  • [6] Docker website. Accessed on 24th April 2018. [Online]. Available:
  • [7] ”the OPNFV website”. Accessed on 24th April 2018. [Online]. Available:
  • [8] Fuel Danube - FUEL. Accessed on 24th April 2018. [Online]. Available:
  • [9] R. Cziva and D. P. Pezaros, “Container network functions: bringing NFV to the network edge,” IEEE Communications Magazine, vol. 55, no. 6, pp. 24–31, 2017.
  • [10] P. Choudhary, “Introduction to Anomaly Detection.” [Online]. Available:
  • [11] R. Vlasveld, “Introduction to One-class Support Vector Machines.” [Online]. Available:
  • [12] F. T. Liu, K. M. Ting, and Z.-H. Zhou, “Isolation Forest,” 2008 Eighth IEEE International Conference on Data Mining, 2008.
  • [13]

    P. J. Rousseeuw and K. V. Driessen, “A Fast Algorithm for the Minimum Covariance Determinant Estimator,”

    Technometrics, vol. 41, no. 3, pp. 212–223, 1999. [Online]. Available:
  • [14]

    N. Donges, “The Random Forest Algorithm – Towards Data Science,” Feb 2018. [Online]. Available:
  • [15] A. Morton, “Considerations for benchmarking virtual network functions and their infrastructure,” IETF RFC 8172, 2017.
  • [16] A. Statnikov and C. F. Aliferis, “Are random forests better than support vector machines for microarray-based cancer classification?” in AMIA annual symposium proceedings, 2007, p. 686.
  • [17] J. Anderson, H. Hu, U. Agarwal, C. Lowery, H. Li, and A. Apon, “Performance considerations of network functions virtualization using containers,” in International Conference on Computing, Networking and Communications (ICNC), 2016, pp. 1–7.
  • [18] J. Fontenla-González, C. Pérez-Garrido, F. Gil-Castiñeira, F. J. González-Castaño, and C. Giraldo-Rodriguez, “Lightweight container-based openEPC deployment and its evaluation,” in IEEE NetSoft Conference and Workshops (NetSoft), 2016, pp. 435–440.
  • [19] W. Zhang, G. Liu, W. Zhang, N. Shah, P. Lopreiato, G. Todeschi, K. Ramakrishnan, and T. Wood, “OpenNetVM: Flexible, high performance NFV,” in IEEE International Symposium on Local and Metropolitan Area Networks (LANMAN), 2016, pp. 1–2.
  • [20] Zhang, Wei and Liu, Guyue and Zhang, Wenhui and Shah, Neel and Lopreiato, Phillip and Todeschi, Gregoire and Ramakrishnan, KK and Wood, Timothy, “OpenNetVM: A platform for high performance network service chains,” in Workshop on Hot topics in Middleboxes and Network Function Virtualization (HotMiddlebox), 2016, pp. 26–31.
  • [21] R. Morabito, V. Cozzolino, A. Y. Ding, N. Beijar, and J. Ott, “Consolidate IoT Edge Computing with Lightweight Virtualization,” IEEE Network, vol. 32, no. 1, pp. 102–111, 2018.
  • [22] J. Pan and Z. Yang, “Cybersecurity Challenges and Opportunities in the New Edge Computing+ IoT World,” in ACM International Workshop on Security in Software Defined Networks & Network Function Virtualization, 2018, pp. 29–32.
  • [23] P. Massonet, L. Deru, A. Achour, S. Dupont, A. Levin, and M. Villari, “End-to-end security architecture for federated cloud and IoT networks,” in IEEE International Conference on Smart Computing (SMARTCOMP), 2017, pp. 1–6.