MASTER THESIS

TITLE: Improving Internet of Things Security with Software Defined

Networking

MASTER DEGREE: Master in Science in Telecommunication

Engineering & Management

AUTHOR: Raluca Ciungu

DIRECTOR: Ricard Vilalta and David Pubill

DATE: 26th of February 2016

1
Overview

Due to the heterogeneous amount of Internet of Things (IoT) applications,

different scenarios for the realization of an IoT network have been proposed,
though usually they are incompatible among them. Moreover, the
heterogeneity of the applications sets different requirements in terms of
networking resources such as low delay in emergency applications or dynamic
bandwidth allocation in video surveillance.

Another challenge of IoT in smart cities arises from the efficient transport of the
gathered information from the source nodes up to the processing and storage
centres. Namely, the future IoT will connect to the Internet billions of
heterogeneous smart devices with the capacity of interacting with the
environment.

Therefore, the proposed solutions from an IoT networking perspective must

take into account the scalability of IoT nodes as well as the operational cost of
deploying the networking infrastructure. This will generate a huge volume of
data, which poses a tremendous challenge both from the transport, and
processing of information point of view. Moreover, security issues appear, due
to the fact that untrusted IoT devices are interconnected towards the
aggregation networks.

In this master thesis, Improving IoT with Software Defined Networking (SDN),
SDN is the key enabler to address security challenges posed by IoT in the
context networking. SDN is a new networking paradigm aiming to overcome
the limitations of traditional IP networks, which are complex and hard to
manage in terms of network configuration and reconfiguration due to faults and
changes.

The idea is to separate the control plane from the data plane, thereby the
control logic in routers and switches will be moved to a centralized network
controller. That is SDN, can be viewed as a network operating system which
interacts with the data plane and the network applications by means of APIs.
Therefore, SDN addresses properly the IoT challenges. SDN allows the
enforcement of network security at the edge, and this project will benefit from
this approach.

3
Resumen

Debido a la enorme variedad de aplicaciones que utilizan datos de sensores,

se han propuesto diferentes soluciones para la realización de una red de
Internet de las Cosas (IoT), siendo muchas de ellas soluciones verticales.

Por otra parte, la heterogeneidad de estas aplicaciones establece diferentes

requisitos en términos de recursos de red tales como bajo retardo en
aplicaciones de emergencia o la asignación dinámica de ancho de banda en la
video vigilancia. Otro de los retos del IoT en el ámbito las “ciudades
inteligentes” (Smart Cities) surge del transporte eficiente de la información
obtenida de la fuente hasta los centros de procesado y almacenamiento. En el
futuro, IoT conectará a miles de millones de dispositivos inteligentes
heterogéneos con la capacidad de interactuar con el entorno.

Por lo tanto, las soluciones propuestas desde una perspectiva de red IoT
deben tener en cuenta la escalabilidad de los nodos, así como el coste
operacional de la implementación de la infraestructura de red. Esto generará
un enorme volumen de datos, lo que plantea un enorme desafío tanto para su
transporte como para su procesado. Por otra parte, aparecen problemas de
seguridad, debido al hecho de que los dispositivos maliciosos de IoT estarán
interconectados hacia las redes de agregación.

En este proyecto de master, titulado “Mejora de la seguridad IoT a traves de

Sofware Defined Networking (SDN)”, SDN es el factor clave para hacer frente
a los retos de seguridad planteados por IoT en el contexto de redes. SDN es
un nuevo paradigma de redes que tiene como objetivo de superar las
limitaciones de las redes IP tradicionales, que son complejas y difíciles de
gestionar en términos de configuración de red y reconfiguración cuando
ocurren fallos y cambios.

La novedad que propone SDN es la separación del plano de control y del

plano de datos, que se traduce en la separación de la lógica de control en
enrutadores y conmutadores a un controlador de red centralizada. Es decir,
SDN puede ser visto como un sistema operativo de red que interactúa con el
plano de datos y las aplicaciones de la red por medio de una API. Esto permite
que SDN aborde adecuadamente los desafíos de la IoT, permitiendo que la
aplicación de la seguridad de la red se ejecute en la periferia de la red.

4
Acknowedlegements
In these first lines of the Thesis, I take the opportunity to especially thank my
tutors Ricard Vilalta and David Pubill, for having guided the selection of my
Project Master Thesis and for their valuable assistance in the development
thereof.
I also want to thank Ricard and David for always being available when needed
and for sharing their research projects and extensive bibliographic information
that have served as basis and guided me in this project.

5
Table of Contents

INTRODUCTION ................................................................................................. 9  

CHAPTER 1. STATE OF THE ART .................................................................. 11  

1.1.   IoT ..................................................................................................................................... 11  
1.1.1.   Sensors and actuators ......................................................................................... 12  
1.1.2.   Wireless Sensors Networks ................................................................................. 12  
1.1.3.   IoT Gateway ......................................................................................................... 13  
1.1.4.   IoT Applications .................................................................................................... 13  

1.2.   SDN ................................................................................................................................... 15  

1.2.1.   SDN basic principles ............................................................................................ 15  
1.2.2.   OpenFlow Switch ................................................................................................. 16  
1.2.3.   SDN Controller ..................................................................................................... 19  
1.2.4.   SDN Applications ................................................................................................. 20  

1.3.   Security ............................................................................................................................ 22  

1.3.1.   IoT security architecture ....................................................................................... 22  
1.3.2   Anomaly detection methods .................................................................................. 27  
1.3.3   Anomaly mitigation strategies ............................................................................... 28  

CHAPTER 2. IOT SECURITY WITH SDN ........................................................ 30  

2.1.   IoT Security architecture ................................................................................................ 30  

2.2.   End-to-end Security Application .................................................................................... 31  

2.3.   Anomaly Detection .......................................................................................................... 32  

2.4.   Algorithm evaluation ....................................................................................................... 33  

2.5.   Simulation results ........................................................................................................... 35  

2.5.1 Analysed data: pkts/sec, N_SIGMA ......................................................................... 36  
2.5.2 Analysed data: pkts/sec, WINDOW .......................................................................... 37  
2.5.3 Analysed data: bytes/sec, N_SIGMA ....................................................................... 38  
2.5.4 Analysed data: bytes/sec, WINDOW ........................................................................ 39  

CHAPTER 3. EXPERIMENTAL RESULTS ...................................................... 41  

3.1   Testbed description ......................................................................................................... 41  

3.2   Testbed configuration ..................................................................................................... 44  

3.2.1   Flow description .............................................................................................................. 46  

3.2.2   Port monitoring (Collector)............................................................................................. 48  

3.3   Intrusion detection algorithm (Anomaly detection)...................................................... 50  

3.4   Anomaly Mitigation .......................................................................................................... 50  

CHAPTER 4. CONCLUSIONS AND FUTURE WORK LINES ......................... 52  

6
4.1   Conclusions and results ................................................................................................. 52  

4.2   Future work lines ............................................................................................................. 53  

4.3   Environmental aspects.................................................................................................... 53  

ABBREVIATIONS AND ACRONYMS .............................................................. 55  

BIBLIOGRAPHY ............................................................................................... 56  

ANNEX: SECURITY ALGORITHM ................................................................... 58  

7
Improving IoT Security with SDN

INTRODUCTION
Billions of objects will be connected to the internet in the coming years.
Therefore it is expected a real revolution on the amount of data gathered and
shared. This is known as the Internet of Things (IoT). Objects such as home
appliances, lampposts, traffic lights or irrigation outlets are some examples of
smart things. They are equipped with several sensors generating data, which
then should be gathered and analysed
Cloud computing means the ability to store and access data and programs over
the Internet. It is a service offered by centralized data centers, which might be
geographically distributed. Instead, fog computing is a decentralised and
distributed computing infrastructure in which application services are handled at
the network edge. Its goal is to improve efficiency and reduce the amount of
data that needs to be transported to the cloud for data processing, analysis and
storage [1].
The integration of IoT with fog and cloud computing is a valuable solution due to
the functionality of computing, storage and networking resources at the edge of
the network, thus allowing fast interaction with the data and low latency. Fog
and cloud computing are expected to allow the data storage and processing
from billions of smart things and IoT gateways, while delivering these
functionalities at the edge of the network. IoT gateways are key enablers for IoT
and typically consists of small gateways which are able to interconnect
distributed wireless sensors, interconnected through wireless sensor networks
(WSN), and acting as an internet gateway for the interconnected devices.
Software Defined Networking (SDN) [11] is expected to be a key enabler for the
next generation networks, the so-called 5G (5th generation of wireless systems),
which will need to integrate both IoT services together with traditional human-
based services. In this context, SDN enables a global orchestration of
distributed cloud, heterogeneous network and IoT resources required in order
to:
a) Transport the huge amount of data generated at the terminals, sensors,
machines, nodes, etc., to any distributed computing node, edge, or core
data center;
b) Allocate computing and storage resources in distributed data centers,
and;
c) Process the collected data (Big Data) and make the proper decisions
(cognition).
SDN automatically configures network devices, gathering the data needed for
the analysis, while keeping private the details of the underlying infrastructure of
devices. It is designed to authenticate users and devices and follow the
prescribed rules of access.
One of the biggest challenges IoT network administrators face, is the ability to
collect data and conduct analyses to produce a positive user experience on the
go. SDN makes it much faster and better than legacy network hardware. SDN is
able to redirect traffic automatically when needed, which significantly improves

9
Improving IoT Security with SDN

IoT applications. SDN can also provision the environment where is carried out
and instantly delivered the analysis of data.
Moreover, security issues appear, due to the fact that untrusted IoT devices are
interconnected towards the aggregation networks or external malware are
applied to the network [7]. It is in this context, where SDN can provide a huge
advantage with regard to security.
The technical solution proposed in this Master Thesis is intended to provide an
agile answer on how to overcome and improve the IoT security with software-
defined networks. The proposed work will consists in the programming of an
intrusion detection algorithm as an SDN application and the validation of this
intrusion detection algorithm in an experimental platform (network/environment).
SDN is a method for centralized control of the network and devices, while it is
allowing the network to be extremely flexible. The use of automated policy-
based control allows transparent access across any device or platform
(accepting Bring Your Own Device – BYOD policy). The permanent monitoring
of own devices behaviour allows the scanning for potential threats.
This Master Thesis has been performed in the premises of CTTC (Centre
Tecnològic Telecomunicacions Catalunya), a research center located in
Castelldefels (Spain). More exactly, the master thesis has been performed at
the cloud/fog computing platforms and transport network of the ADRENALINE
Testbed ®. In the context of evolving the capabilities of this testbed, my work
has consisted in:
- The debugging of the Fog node and its SDN controller, which was quite
unstable.
- The design of an overall architecture for the security application, which
takes into account the several needed modules in order to properly
analyse possible security threads.
- Design and validation of a simple algorithm (several have been studied)
in order to validate the proposed application. The algorithm has been
studied against a simulated security thread and its performance has
been evaluated.
- Develop a security application which interacts with the Fog node SDN
controller. Using a REST API, the flow statistics are read and analysed,
using the previously validated algorithm.

This master thesis is organized as follows. In Chapter 1, an introduction on the

State of the Art is provided on the related several topics: IoT, SDN and security.
Chapter 2 proposes an SDN-enabled security architecture, which leverages the
available real-time network flows information in order to take decisions
regarding the provided security at the edge. A basic intrusion detection
algorithm is proposed to validate the architecture design and it is evaluated in a
simulated environment. In Chapter 3, the experimental evaluation and results
are provided for the proposed security architecture. Finally, Chapter 4 presents
the conclusions and proposals for future developments.

10
Improving IoT Security with SDN

CHAPTER 1. STATE OF THE ART

In this chapter, the state of the art for the Internet of Things and Software
Defined Networking is presented. Additionally, security applications and IoT
applications benchmarks are presented in order to offer a better approach and
understanding with regard on the market already created around the Internet of
Things.

1.1. IoT
The International Telecommunications Union defines the Internet of Things
(IoT) as the “global infrastructure for the information society, enabling advanced
services by interconnecting (physical and virtual) things based on existing and
evolving interoperable information and communication technologies” [22].
Currently, the IoT is composed by a large number of networks designed for a
wide range of applications. For example, the cars of today have different
networks for controlling engine operation, the safety functions, communication
systems, etc. Commercial and residential buildings have also various control
systems for heating, ventilation and air conditioning; telephone service; security
and lighting. As IoT progresses, these networks and many others, will be
connected and will have more security features, analysis and management (see
Fig.1.1) and will offer better services by breaking the silos built in through
different IoT Networks. As Mario Campolargo, DG CONNECT European
Commission states in [11] “IoT will boost the economy while improving our
citizens’ lives.”

Fig.1.1 IoT a network of networks

11
Improving IoT Security with SDN

At a wider level, cities are starting to adopt in different ways the IoT technology
by deploying sensors around the cities with the purpose of providing new
services for citizen (sensors parking, transport sensors, air quality sensors etc.),
municipality (smart building, energy efficiency, resilient city) and third parties.
This new services are grouped in the term smart cities. Thus, IoT is not only a
new paradigm in which respect the technology delivered but also is a business
ecosystem engine for the cities economic development.

1.1.1. Sensors and actuators

A sensor is a device whose main purpose is to detect and measure events or

environment changes, providing the corresponding measurement output.
Usually a sensor is compared with a transducer due to the fact that it converts
one form of energy to another. Sensors may provide various types of output, but
typically use electrical (analog or digital) or optical signals [22].

Sensors are used in innumerable applications or services, through large

deployments of devices such as touch elevator buttons (tactile sensor), parking
sensors, lighting sensors, industrial machine sensors etc. Applications include
manufacturing and machinery, airplanes and aerospace, cars, medicine and
robotics are also included in our day-to-day life.

With advances in easy-to-use micro controller platforms, the uses of sensors

have enlarged beyond the more traditional fields of temperature, air quality,
shadow detection and pressure or flow measurement.

An actuator is a type of device operated by a source of energy that can control

or move a system or a mechanism. The actuator can be compared with a
mechanism that converts energy in motion and through which a system acts
upon an environment. Typically the source of energy is electric current,
hydraulic fluid pressure or pneumatic pressure. The control system can be
simple (a fixed mechanical or electronic system), software-based (e.g. a printer
driver, robot control system), a human, or any other input.

1.1.2. Wireless Sensors Networks

A wireless sensor network (WSN) is a computer network composed by

autonomous devices that uses sensors to monitor environmental or physical
conditions such as vibration, temperature, sound, pressure or motion at different
locations. Wireless sensor networks are now used in many application areas
(e.g., smart cities, eHealth, Industry 4.0), including environment and habitat
monitoring, healthcare applications, home automation, parking, waste
management, air quality, noise measurement, traffic control and many others
useful applications [12].

The WSN is built of "nodes" – from a few to several hundreds or even

thousands, where each node is connected to one (or sometimes) several
sensors. Each sensor network node has typically several parts: a radio
transceiver with an internal antenna or connection to an external antenna, a
microcontroller, an electronic circuit for interfacing with the sensors and an
energy source, usually a battery or an embedded form of energy harvesting.

12
Improving IoT Security with SDN

Size and cost constraints on sensor nodes result in corresponding constraints

on resources such as energy, memory, computational speed and
communications bandwidth. The topology of the WSNs can vary from a simple
star network to an advanced multi-hop wireless mesh network.

1.1.3. IoT Gateway

A gateway is a network point that acts as an entrance to another network. An

example of gateway node can be considered the computers that control traffic
within a company network or at your local Internet service provider (ISP).

Gateways are simplifying the IoT networks by supporting the connection of

different network devices and by consolidating and mitigating the great variety
and diversity of disparate data coming from different network devices.
There are several ways to implement an IoT gateway, depending upon the
application. Two common approaches are a simple gateway and an embedded
control gateway. Both provide consolidated connectivity by aggregating data
from multiple end points. In general, a simple gateway organizes and
packetizes the data for transport over the Internet. It is also responsible for
distributing data back to end points in applications where two-way
communications is advantageous or required.
Is important to specify that a gateway is different from a router. A router
manages similar traffic, and it connects devices that share a common interface.
For example, the devices that connect to a home router all use IP.

A gateway acts as a bridge, thus is able to route different types of traffic and
convert these streams to a common protocol for access across the WAN. Some
devices might use IP natively while others might use PAN-based protocols like
Bluetooth, ZigBee or 6LoWPAN. Nodes that are simple sensors may need to be
connected to an ADC (Analog to digital converter) to convert their raw analog
voltage to a digital value before transport.

1.1.4. IoT Applications

Along with the increase in maturity of the IoT, the technology market is starting
to develop services that are key solutions for the society challenges. Below are
presented some of the market applications that are build based upon IoT
concepts [13]:

Table 1.1 IoT Applications

Smart Cities
01 Smart Parking
Monitoring of parking spaces availability in the city.
02 Structural Health
Monitoring of vibrations and material conditions in the buildings.
03 Noise Urban Maps
Sound monitoring in bar areas and centric zones in real time.
04 Smartphone detection
Detect iPhone and android devices and in general any device, which works with WiFi

13
Improving IoT Security with SDN

and Bluetooth, interfaces.

05 Electromagnetic field levels
Measurement of the energy radiated by cell stations and WiFi routers.
06 Traffic congestion
Monitoring of vehicles and pedestrian levels to optimize traffic and walking routes.
07 Smart Lighting
Intelligent and winter adapting streetlights.
08 Waste Management
Detection of rubbish levels in containers to optimize the trash collection routes.
09 Smart Roads
Intelligent highways with warning messages and diversions according to climate
conditions and unexpected events like accidents or traffic jams.

Smart Environment
10 Forest Fire Detection
Monitoring of combustion gases and pre-emptive fire conditions alert zones.
11 Air Pollution
Control of CO2 emissions of factories, pollution emitted by cars and toxic gases
generated in farms.
12 Snow Level Monitoring
Snow level measurement to know in real time the quality of ski tracks and allow
security corps avalanche prevention.
13 Landslide and avalanche prevention
Monitoring of soil moisture, vibrations and earth density to detect dangerous patterns in
land conditions.
14 Earthquake Early Detection
Distributed controls in specific places of tremors.

Smart Water
15 Potable water monitoring
Monitor the quality of tap water in cities.
16 Chemical leakage detection in rivers
Detect Leakages and wastes of factories in rivers.
17 Swimming pool remote measurement
Control remotely the swimming pool conditions.
18 Pollution levels in the sea
Control real-time leakages and wastes in the sea.
19 Water Leakages
Detection of liquid presence outside tanks and pressure variation along pipes.
20 River Floods
Monitoring the water level variations in rivers, dams and reservoirs.

The IoT technology takes shape and many applications of the sensors are
starting to be deployed through the cities. Nevertheless these applications need
to have a layer of security due to the fact that malware attacks are at the
moment a menace for the data owners.

14
Improving IoT Security with SDN

1.2. SDN
Software-Defined Networking (SDN) is a network architecture that allows the
programming of the network through clearly defined interfaces. SDN allows the
possibility of creating new services and more efficient applications based on the
interaction with networks traffic, network security implementation, or quality of
service.

1.2.1. SDN basic principles

Given the heterogeneity of networks, it is challenging to coordinate and optimize

the use of the heterogeneous network resources with the goal of satisfying as
many tasks and services as possible. It is conjecture that the SDN paradigm is
a good candidate to solve the resource management needs for network
environments for multiple reasons [1]:
• SDN allows for a clear separation between services in the control plane
(that makes decisions about how traffic is managed) and the data plane
(actual mechanisms for forwarding traffic to desired destinations). The
decoupling of the control plane from the forwarding plane encourages
abstractions of low level network functionalities.
• Logically centralized view of the network, which allows to perform
network optimization techniques. Redundancy and other mitigation
failures can be applied in order to avoid single points of failure.
• Network programmability allows the dynamic and fast introduction of new
network services.

Fig.1.2 SDN Architecture [19]

Figure 1.2 shows the SDN architecture, which is being defined by the Open
Networking Foundation (ONF) [2]. It basically consists of three layers:

15
Improving IoT Security with SDN

• Infrastructure layer, which consists of the OpenFlow-enabled network

elements, such as layer 2 switches.
• Control layer, which allows the dynamic provisioning of network services
by means of an SDN controller.
• Application layer, which allows the deployment of network-aware
applications on top of an SDN controller.

The OpenFlow protocol is an open source protocol that is a foundational

element for building SDN solutions. This protocol allows network controllers to
determine the flow paths across a network of switches thus enabling the easy
traffic management through the separation of the control plane from the
forwarding plane.

1.2.2. OpenFlow Switch

An OpenFlow Switch consists of one or more flow tables and a group table,
which perform packet lookups and forwarding, and an OpenFlow channel to an
external controller Fig. 1.3. The SDN controller manages the switch via the
OpenFlow protocol. Using this protocol, the controller can add, update, and
delete flow entries, both reactively (in response to packets) and proactively [2].

Fig.1.3 An OpenFlow communicates with a controller over a secure connection

using the OpenFlow protocol [18]

Each flow table in the switch contains a set of flow entries; each flow entry
consists of match fields, counters, and a set of instructions to apply to matching
packets.

OpenFlow is an open protocol that programs the flow tables in different

switches and routers with the aim to create a shared management of the traffic
flow. A usual example is the partition of the traffic into production and research
traffic flow. A network administrator can partition the network traffic flow into
research and production traffic flow, creating in this way a viable environment
for research. Therefore, on the same network researchers are provided with
entire control on their own flows by choosing the routes their packets follow.

16
Improving IoT Security with SDN

This easiness of network data management facilitates the research on security

models and scenarios addressing schemes, routing protocols and even
alternatives to IP, while isolating the network production traffic.

An OpenFlow Switch consists of at least three parts:

1) A Flow Table, with an action associated with each flow entry, to tell the
switch how to process the flow;

2) A Secure Channel that connects the switch to a remote control process,

called the controller, allowing commands and packets to be sent between
a controller and the switch;

3) The OpenFlow Protocol, which provides an open and standard way for a
controller to communicate with a switch. By specifying a standard
interface (the OpenFlow Protocol) through which entries in the Flow
Table can be defined externally, the OpenFlow Switch avoids the need
for researchers to program the switch.

OpenFlow provides remote administration of an up to layer 3 switch's packet

forwarding tables, by adding, modifying and removing packet matching rules
and actions, allowing controllers to make periodically or ad hoc decisions.
Decisions are translated into actions and rules with a configurable lifecycle,
which are deployed to a switch flow table.

Unmatched packets by the switch can be forwarded to the controller. The

controller can then decide to modify existing flow table rules on one or more
switches or to deploy new rules, to prevent a structural flow of traffic between
switch and controller. It could even decide to forward the traffic itself, provided
that it has told the switch to forward entire packets instead of just their header.

The OpenFlow protocol is layered on top of the Transmission Control Protocol

(TCP), and prescribes the use of Transport Layer Security (TLS).

A basic match table for flow definition, included in OF 1.3 includes the following
parameters [17]:

• Switch input port.

• Switch physical input port.
• Metadata passed between tables.
• Ethernet destination address.
• Ethernet source address.
• Ethernet frame type.
• VLAN id.
• VLAN priority.
• IP DSCP (6 bits in ToS field).
• IP ECN (2 bits in ToS field).
• IP protocol.
• IPv4 source address.
• IPv4 destination address.

17
Improving IoT Security with SDN

• TCP source port.

• TCP destination port.
• UDP source port.
• UDP destination port.
• SCTP source port.
• SCTP destination port.
• ICMP type.
• ICMP code.
• ARP opcode.
• ARP source IPv4 address.
• ARP target IPv4 address.
• ARP source hardware address.
• ARP target hardware address.
• IPv6 source address.
• IPv6 destination address.
• IPv6 Flow Label
• ICMPv6 type.
• ICMPv6 code.
• Target address for ND.
• Source link-layer for ND.
• Target link-layer for ND.
• MPLS label.
• MPLS TC.
• MPLS BoS bit.
• PBB I-SID.
• Logical Port Metadata.
• IPv6 Extension Header pseudo-field

The possible actions to be applied to a flow are the following (simplified) in OF

1.3:
• The Output action forwards a packet to a specified OpenFlow port.
OpenFlow switches must support forwarding to physical ports, switch-
defined logical ports and the required reserved ports.
• The set-queue action sets the queue id for a packet. When the packet is
forwarded to a port using the output action, the queue id determines
which queue attached to this port is used for scheduling and forwarding
the packet. Forwarding behaviour is dictated by the configuration of the
queue and is used to provide basic Quality-of-Service (QoS) support.
• There is no explicit action to represent drops. Instead, packets whose
action sets have no output actions should be dropped. This result could
come from empty instruction sets or empty action buckets in the
processing pipeline, or after executing a Clear-Actions instruction.
• Required Action: Group. Process the packet through the specified group.
The exact interpretation depends on group type.
• Switches may support the ability to push/pop tags to aid integration with
existing networks, such as the ability to push/pop VLAN tags.

18
Improving IoT Security with SDN

Moreover, the available flow counters per flow entry are the following:
• Received Packets
• Received Bytes
• Duration (seconds)
• Duration (nanoseconds)
Finally, OF v1.3 introduces a new message (i.e. OFPT_METER_MOD) which
enables the specification of traffic meters into the OF-switches, with an
associated Band-rate and a QoS-enabling strategy, such dropping packets at a
determined Drop-rate or Differentiated Services Code Point (DSCP) packet
tagging to allow DiffServ. Flows can be attached to these predefined meters,
associating a maximum rate to each flow. A Meter instruction has to be included
inside the OFPT_FLOW_MOD message indicating the Meter-Id desired to be
attached to.

Open vSwitch [20]: Open vSwitch sometimes abbreviated to OVS, is a

production quality open source implementation of a distributed virtual multilayer
switch. The main purpose of Open vSwitch is to provide a switching stack for
hardware virtualization environments, while supporting multiple protocols and
standards used in computer networks, such as OpenFlow. OVS have extensive
hardware support through the usage of Intel’s DPDK (DataPath Development
Kit), allowing faster responses and low latencies in Intel Network Interface
Cards (NIC).

Other examples of virtual software switches are the following:

• The OpenFlow eXtensible DataPath daemon (xDPd) is a multi-platform,
multi OF version, open-source datapath built focusing on performance
and extensibility.
• Lagopus switch is a high-performance software OpenFlow 1.3 switch.

1.2.3. SDN Controller

As defined in SDN architecture [1], the SDN controller is a software entity that
has exclusive control over an abstract set of data plane resources. An SDN
controller may also offer an abstracted information model instance to at least
one client.

An SDN controller may be implemented as any number of software

components, which reside on any number of physical platforms. The distributed
components are required to maintain a synchronized and self-consistent view of
information and state. This requirement bounds the concept of a single SDN
controller; software components that do not share this characteristic are
necessarily external to the controller.
Several open source implementations of an SDN controller are available, being
the most important the following.

19
Improving IoT Security with SDN

The OpenDaylight Project [14] is a collaborative open source project hosted

by The Linux Foundation. The goal of the project is to accelerate the adoption of
software-defined networking (SDN) and create a solid foundation for Network
Functions Virtualization (NFV).
By supporting open standards such as OpenFlow, OpenDaylight delivers a
common open source framework and platform for SDN across the industry for
customers, partners and developers.

A source code repository includes contributed source code from Big Switch
Networks, Cisco and NEC. Open Daylight project is sponsored by the LINUX
foundation, and it has its own website, wiki, and a mailing list available. These
resources appear to currently be aimed at developers wishing to contribute to
the project. The software is written in Java.

ONOS [15] is the SDN network operating system for service providers
architected for performance, high availability, scale-out and well-defined
northbound and southbound abstractions and interfaces. ONOS was open-
sourced on December 5th, 2014. The first open source release of ONOS was
called Avocet and the next is Blackbird. Blackbird, which was released recently
focuses on performance optimizations, defining metrics for measuring the
"carrier-grade quotient" of SDN control planes/controllers and publicly providing
the measurements for ONOS using these metrics.

RYU [16] is a component-based software defined networking framework. Ryu

provides software components with well-defined API that make it easy for
developers to create new network management and control applications.

1.2.4. SDN Applications

It is surprising to notice that actually both in research and commercial industries

there is a lot of research related with SDN architecture for security applied in
IoT but there is a lack of published security algorithms and applications.

By using the SDN controller, a wide range of applications can be developed

covering the following topics, among others:
1) TAP Monitoring fabric application: advanced network monitoring solution
that leverages high-performance bare metal Ethernet switches to provide
the most scalable, flexible and cost-effective monitoring fabric
2) Security application
3) Network performance optimization and monitoring application
4) Data center fabric application
A special focus is dedicated to security applications to offer a better
understanding on the commercial already developed solutions that apply
security to data networks by using SDN.
Security is a big concern in Data centers, sensor networks and industrial
environments, and use of SDN technology gives the capability to dynamically
adapt to new threats. Openflow is used both to get useful information from the

20
Improving IoT Security with SDN

L2/L3 switches as well as to redirect/drop the traffic in case a positive threat is

identified. SDN controllers work closely with DDos (distributed denial attack of
service) application platforms in most cases.
It has been decide to analyse the HP SDN VAN (Virtualized applications
networks) controller [21]. Although it wasn’t found a security application applied
in IoT with HP SDN VAN controller this solution could be used for IoT security.
Below is presented a benchmark of some examples of security applied with
SDN.

F5’s Big DDoS umbrella

F5’s Big IP platform is a DDoS (distributed denial attack of service) application
that monitors different kind of threats and once it confirms that the threat is real,
it talks to HP’S VAN SDN controller so that the traffic can be filtered out in the
edge. HP VAN SDN controller programs the OpenFlow switches to drop the
malicious traffic. This approach saves precious network bandwidth in the data
center.

BlueCat DNS director

This application is targeted towards security threats caused by BYOD (Bring
your own device). DNS director programs Openflow switches in the network
using HP VAN SDN controller to redirect requests for non-corporate DNS
servers towards BlueCat’s DNS server. BlueCat’s DNS server sends back
proper DNS response and the requestor will not even know that the DNS
request was intercepted.

HP Network protector
HP Network protector is a SDN application on top of HP VAN SDN controller,
which programs the Openflow switches. It’s mainly targeted for BYOD (Bring
your own device) scenarios in Enterprises. Some of the important features of
HP Network protector are:
• Creating custom white and black filter lists
• Monitoring suspicious DNS requests
• Malicious identity detection

Guardicore Defense suite

Guardicore’s Defense suite application is built on top of HP VAN SDN
controller. Its mainly targeted towards East-West traffic in Data Center. If there
is 1 malicious host that has got inside the data center somehow, that host can
target all other hosts in data center and external firewalls will not be able to
catch this. Most of the times, the suspicious connections gets blocked inside the
data center by firewalls. Defense suite monitors these blocked connections
using the SDN controller and redirects these connections to Active Honeypot
server that responds to these connections. The malicious host would not know
that it is talking to Honeypot. Using this approach, critical information can be
collected about the malicious host and this would prevent attacks before
happening.

21
Improving IoT Security with SDN

1.3. Security
The integration of Internet of Things (IoT) has provided the control of different
connected devices into a single network or smart device, such as different types
of wireless sensors networks, smartphones, tablets and at the same time gave
born to a new paradigm related with security in IoT networks due to the fact that
hacked devices can be easily introduced in the networks. Thus, IoT security has
become essential for citizens’, organizations, governments and utilities for
protection of data and infrastructures and is gaining power in day to day
deployment.

Since the beginning of the Internet era and development of networks, security
has always been a primary concern for everyone, be it enterprises, small and
medium businesses (SMBs), individuals or governments. Due to the increase of
the networking applications and technological advancement security has
converted in a big concern both in public a private environments. Prior to the
emergence of IoT, the adverse effect of threats was limited to theft of money
and intellectual properties. Now, the effect can lead to loss of human life,
hacking of critical infrastructures like electricity and nuclear power grids,
organizational productivity, and even national intelligence.

Initially, the connection of devices took place between PCs (personal

computers) and then threats and cyber attacks such as viruses and malwares
showed their presence and effects. To minimize the damages caused due to
such attacks and ensure proper security to prevent future attacks, cyber
security solutions such as anti-viruses and anti-malwares were designed.
Similarly, diversified networking led to the evolution of IoT and to secure the
IoT, cyber security vendors modified their solutions to ensure security in IoT.

The solutions such as intrusion detection and prevention systems, encryption,

access management and SDN (software defined management) are the major
solutions securing IoT.

In the following subsections, we explore the state of the art for:

• Security architectures for SDN and IoT
• Anomaly detection methods
• Anomaly mitigation strategies

1.3.1. IoT security architecture

Several architectures have been taken into consideration in order to propose
the IoT security architecture that better fits to the project requirements. The
most relevant architectures are described below:
• Generic Architecture Network Intrusion Detection System (ANIDS)
• Simplified model of Architecture Intrusion Detection System
• Malware Monitor
Generic Architecture Network Intrusion Detection System (ANIDS)

22
Improving IoT Security with SDN

Many Network Intrusion Detection Systems (NIDSs) have been developed by

researchers and practitioners [3]. However, the development of an efficient
Architecture Network Intrusion Detection System (ANIDS’s) architecture is still
being investigated.

A generic architecture of an ANIDS is shown in Fig. 1.4 [3]:

Fig.1.4 A generic architecture of a NIDSs

Fig.1.5 Steps for updating of configuration data in ANIDS

The main components of the generic model of the ANIDS are discussed below.

1) Anomaly detection engine: this module it attempts to detect occurrence

of any intrusion either online or offline. However, before sending any network
traffic to the detection engine, it needs pre-processing. If the attacks are known,
they can be detected using the misuse detection approach. On the other hand,
unknown attacks can be detected using the anomaly-based approach based on

23
Improving IoT Security with SDN

an appropriate matching mechanism.

Matching mechanism: It entails looking for a particular pattern or profile in

network traffic that can be built by continuous monitoring of network behaviour
including known exploits or vulnerabilities. The following are some important
requirements in the design of an efficient matching mechanism.

– Matching determines whether the new instance belongs to a known class

defined by a high dimensional profile or not. Matching may be inexact.
– Matching must be fast.
– Effective organization of the profiles may facilitate faster search during
matching.
2) Reference data: The reference data stores information about known
intrusion signatures or profiles of normal behaviour. Reference data needs to be
stored in an efficient manner. Possible types of reference data used in the
generic architecture of a NIDS are: profile, signature and rule. In case of an
ANIDS, it is mostly profiles. The processing elements update the profiles as
new knowledge about the observed behaviour becomes available. These
updates are performed in regular intervals in a batch-oriented fashion.
3) Configuration data: This corresponds to intermediate results, e.g.,
partially created intrusion signatures. The space needed to store such
information can be quite large. The steps for updating of the configuration data
are given in Fig. 1.5. Intermediate results need to be integrated with existing
knowledge to produce consistent, up-to-date results.
4) Alarm: This component of the architecture is responsible for generation
of alarm based on the indication received from the detection engine.
5) Human analyst: A human analyst is responsible for analysis,
interpretation and for taking necessary action based on the alarm information
provided by the detection engine. The analyst also takes necessary steps to
diagnose the alarm information as a post-processing activity to support
reference or profile updating with the help of security manager.
6) Post-processing: This is an important module in a NIDS for post-
processing of the generated alarms for diagnosis of actual attacks.
7) Capturing traffic: Traffic capturing is an important module in a NIDS. The
raw traffic data is captured at both packet and flow levels. Packet level traffic
can be captured using a common tool, e.g., Wireshark1 and then pre-processed
before sending to the detection engine
8) Security manager: Stored intrusion signatures are updated by the
Security Manager (SM) as and when new intrusions become known. The
analysis of novel intrusions is a highly complex task.  

Simplified model of Architecture Intrusion Detection System

Another architecture that has been studied for the security detection intrusion is
based on a simplified model composed by 3 modules:

24
Improving IoT Security with SDN

a) Collector,
b) Anomaly Detection,
c) Anomaly Mitigation

Fig. 1.6 [3] shows each module named accordingly with the functionality that
represents:

Fig.1.6 Architectural view of the proposed IDS on SDN environments

a) Collector Module: The Collector module is responsible for data gathering,

a prerequisite in order to perform flow-based anomaly detection. This module
collects flow information and periodically exports them to the Anomaly Detection
module.

b) Anomaly Detection Module: Data produced by the previous module are

subsequently fed to the Anomaly Detection module at periodic time intervals,
thus creating discrete time windows. For every time-window this module
inspects all flow entries, exposing any flow-related network anomaly and
identifying a potential attacker or the victim of the attack. Moreover, it performs
successfully not only in identifying the attack pattern, but also the attacker or the
victim (i.e. host under attack). As soon as an anomaly is detected in the
network, our algorithm inspects and correlates specific network metrics
identifying the attack and exposing all related information to the Anomaly
Mitigation module.
c) Anomaly Mitigation Module: The Anomaly Mitigation module aims to
neutralize identified attacks, inserting flow-entries in the flow table of the Open
Flow switch (or modify existing ones) in order to block the desired malicious
traffic. These flow-entries have higher priority than any other in the flow table. In
order to avoid blocking benign network flows that resemble malicious anomalies
behaviour, we choose to insert specific host-related rules in a white list table.
Malware Monitor

Finally the third type of architecture, called Malware Monitor [4], was studied
(Fig.1.7).

25
Improving IoT Security with SDN

Fig.1.7 Architecture of Malware Monitor

Bellow it is presented how is envisioned the implementation of each module that

composes the architecture [5]:

a) Elastic Load Balancer: The load balancer is an SDN application running

on an OpenFlow controller. It comprises a virtual machine (VM) Controller and
network slicing logic. The VM controller assesses the network load and spawns
a number n of machines implementing detection logic (detector nodes) from a
VM pool it controls – hence the notion of elasticity. The job of the network
slicing logic is to then logically partition the network into n slices, where a slice
is defined as all track having a particular characteristic such as a certain port,
protocol, or set of source addresses. It then creates flow rules in the data plane
to forward a copy of all packets from each slice to the corresponding detector
node.

b) Detector Nodes: Detector nodes first state fully inspect each received
packet for malicious content to detect events associated with malware infections
(e.g. DoS attacks or communication with malicious servers). Secondly, they
compute flow statistics for each flow they receive, such as byte and packet
counts or burst sizes. The second job can be accomplished by leveraging a
feature of OpenFlow where switches maintain flow statistics for each flow that
passes through them; thus the detector node can run an OF controller and
simply pull flow statistics from the upstream edge switch. More advanced
statistics can be calculated using simple utilities (tshark, capinfos, tcpdump)
available for Unix-based operating systems. The detector node then

26
Improving IoT Security with SDN

amalgamates the flow identification tuple (source/destination IP and port, and

protocol) with any detected malicious activity (as an alert message) and the
computed flow statistics, and sends it to the decision module.

c) Decision Module: The decision module examines the flow meta-data sent
by the detector nodes to compute a maliciousness score for each individual
flow. However unlike the detector nodes, which looked at only one flow at a
time, the decision module performs correlation across flows to discover
suspicious patterns or combinations of events – for example, a distributed DoS
attack, or a number of flows from different hosts connecting to a common
blacklisted IP (indicating members of a botnet). Thus it assigns a maliciousness
score to a flow based not only on the events that have been detected as part of
it but also on its similarity with other malicious flows this similarity can be seen
in common events occurring in a flow or similar statistical characteristics. We
believe that some stealthy flows that are able to disguise themselves
individually can be discovered in this manner.

1.3.2 Anomaly detection methods

In this section are presented several network anomaly detection methods that
are usually used for the development of detection anomaly algorithms.

These methods were studied in order to have a better approach on the suitable
method to be used for the security algorithm development.

A network intrusion detection system (NIDS) usually integrates a network

intrusion detection method within an architecture that comprises other
associated sub-systems to build stand-alone practical system that can perform
the entire range of activities needed for intrusion detection.

In the figure below, Fig.1.8. is presented the classification of methods that were
studied for the development of the security algorithm.

27
Improving IoT Security with SDN

Fig. 1.8 Classification of network anomaly methods [3]

A. Statistical methods and systems

An anomaly (from the statistical perspective) is behaviour considered being

partially or entirely inappropriate due to the fact that is not generated by the
stochastic model assumed.

Usually, statistical methods fit a statistical model to the given data and then
apply a statistical inference test to determine if an unseen instance belongs to
this model. Instances that have a low probability to be generated from the learnt
model based on the applied test statistic are declared anomalies.

B. Classification-based methods and systems

Classification based methods and systems is the method that identifies the
belonging of an observation to a set of categories, where the set of categories is
a training set of data containing observations whose category membership is
known.

C. Clustering and Outlier-based methods and systems

Clustering is the method of distributing a set of objects into groups called

clusters in such way that object from the same cluster are more similar (in
certain sense) than those from different clusters. Clustering method is used in
explorative data mining. For example, if we have a set of objects in two
dimensions, we may be able to cluster them into a defined number of clusters
by drawing circles or ellipses around them. Outliers are points from a dataset
that for a given model of data they are highly unlikely to occur.

D. Soft computing methods and systems

Soft computing is usually thought of as incorporating methods such as Genetic

Algorithms, Artificial Neural Networks, Fuzzy Sets, Rough Sets, Ant Colony
Algorithms and Artificial Im-mune Systems. This method is used for the network
anomaly detection because of the easiness to detect the exact solution.

E. Knowledge-based methods and systems

The objective of this method is to represent the attacks in a generic way to allow
for an easy detection of the malware. This method search for instances of
known attacks, by attempting to match with pre-determined attack
representations.

In the first instance the search of malware begins with a complete lack of
knowledge and subsequent, matching of activities against a known attack helps
acquire knowledge and enter into a zone with higher confidence.

1.3.3 Anomaly mitigation strategies

Two important mitigation strategies are discussed. The first focuses on limiting
the effect of an anomaly to the network bandwidth, while the second tries to

28
Improving IoT Security with SDN

minimize completely the impact of an anomaly, and can be understood as a

corner case of the first strategy.

Rate Limiting

In computer networks, rate limiting is used to control the rate of traffic sent or
received by a network interface controller. It can be induced by the network
protocol stack of the sender and also by the network scheduler of any router
along the way.

The rate limiting (or traffic shaping) is the regulation of the rate at which flows
are allowed to inject packets into the network and is therefore one of the
cornerstones of any QoS architecture.

OpenFlow 1.3 allows different rate limiting policies once a certain rate has been
reached:
– Drop: Drop (discard) the packet. Can be used to define a rate limiter
band.
– Dscp: decreases the drop precedence of the DSCP field in the IP header
of the packet. Can be used to define a simple DiffServ police.

Flow interruption

In order to do not allow any traffic of a suspicious flow, the flow rule can be
directly removed from the SDN controller.

29
Improving IoT Security with SDN

CHAPTER 2. IOT SECURITY WITH SDN

After analysing the current state of the art in previous chapter, this chapter
focuses on the following objectives:
- Propose an open source IoT security architecture based on SDN
principles.
- Describe different IoT security threats and design an anomaly detection
mechanism.
- Evaluate the behaviour of the proposed anomaly detection mechanism,
taking into account a specified IoT security threat.

2.1. IoT Security architecture

Our proposed IoT security architecture consists of three basic components,

which are show in Fig. 2.1: An SDN/NFV edge node, an SDN controller and an
E2E security application.
The SDN/NFV Edge Node is a distributed computing infrastructure in which
some application services are handled at the network edge. The industry has
named this technology as fog computing. The goal of this fog node is to improve
efficiency and reduce the amount of data that needs to be transported to the
cloud for data processing, analysis and storage. This is often done for efficiency
reasons, but it may also be carried out for security and compliance reasons.
This Fog node has the ability to act as:
a. An OpenFlow-enabled switch. To this switch the different IoT
gateways are connected, as well as connectivity to aggregation
and transport networks is provided.
b. Virtual Machines running different services, such as an IoT
database, where the measurements of the different WSN are
stored for local processing.
The SDN controller shall be able to support OpenFlow control of flow tables,
meters and actions. A clear North Bound Interface (NBI) of the SDN controller
shall be described in order to ease the integration of higher level applications.

The End-to-end security application will be responsible for the monitoring of the
current flows, and through different anomaly detection mechanism it will be able
to identify malicious flows. Finally, this application will apply the desired security
policies with regard to the detected anomalies in order to mitigate them. It will
consists of three main modules shown in Fig. 2.1: (a) the Collector, (b) the
Anomaly Detection and (c) the Anomaly Mitigation.

30
Improving IoT Security with SDN

Fig 2.1 IoT Security Testbed

2.2. End-to-end Security Application

Below, the different components of the E2E security application are described.

Collector Module

The Collector module is responsible for data gathering, a prerequisite in order to

perform flow-based anomaly detection. This module collects flow information
and periodically exports them to the Anomaly Detection module.

If we focus on the available information from the SDN controller, the different
per flow counters might be obtained. From this information we can estimate the
following data per flow:

- Packets per second.

- Bytes per second.

These data will allow us to detect anomalies in the flows, such as for example
intrusion detection, or WSN malfunction.
Anomaly Detection Module
Data produced by the previous module are subsequently fed to the Anomaly
Detection module at periodic time intervals, thus creating discrete time
windows. For every time window this module inspects all flow entries, exposing
any flow-related network anomaly and identifying a potential attacker or the

31
Improving IoT Security with SDN

victim of the attack. Moreover, it performs successfully not only in identifying the
attack pattern, but also the attacker or the victim (i.e. host under attack). As
soon as an anomaly is detected in the network, our algorithm inspects and
correlates specific network metrics identifying the attack and exposing all
related information to the Anomaly Mitigation module.
In later sections of this chapter, we will describe an anomaly detection
mechanism and we will evaluate its behaviour against this kind of attack.
Anomaly Mitigation Module
The Anomaly Mitigation module aims to neutralize identified attacks, inserting
flow meters in the flow table of the Open Flow switch (or removing existing
flows) in order to block/mitigate the desired malicious traffic. These flow entries
have higher priority than any other in the flow table.
This module is presented in Chapter 3, in the experimental results.

2.3. Anomaly Detection

In data mining, anomaly detection (or outlier detection) is the identification of
items, events or observations, which do not conform to an expected pattern, or
other items in a dataset. Typically the anomalous items will translate to some
kind of problem such as bank fraud, a structural defect, medical problems or
errors in a text. Anomalies are also referred to as outliers, novelties, noise,
deviations and exceptions.

In particular in the context of abuse and network intrusion detection, the

interesting objects are often not rare objects, but unexpected bursts in activity.
This pattern does not adhere to the common statistical definition of an outlier as
a rare object, and many outlier detection methods (in particular unsupervised
methods) will fail on such data, unless it has been aggregated appropriately.
The most common measures of dispersion for continuous data are the variance
and standard deviation. Both describe how much the individual values in a data
set vary from the mean or average value. The variance and standard deviation
are calculated slightly differently depending on whether a population or a
sample is being studied, but basically the variance is the average of the
squared deviation from the mean, and the standard deviation is the square root
of the variance.

For the detection of the anomalies it has been envisaged an algorithm based on
the data variance gathered from a sensors network. The formula presented
below is the deviation calculated for the data provided by the sensors:

! !
Standard deviation: 𝜎 = ! !!!(𝑥! − 𝑥)! (2.1)

Where,

32
Improving IoT Security with SDN

𝜎 = 𝑠𝑡𝑎𝑛𝑑𝑎𝑟𝑑  𝑑𝑒𝑣𝑖𝑎𝑡𝑖𝑜𝑛
𝑥! = 𝑠𝑒𝑛𝑠𝑜𝑟  𝑑𝑎𝑡𝑎  
(𝑥) = 𝑚𝑒𝑎𝑛  𝑣𝑎𝑢𝑒  𝑐𝑎𝑙𝑐𝑢𝑙𝑎𝑡𝑒𝑑  𝑓𝑜𝑟  𝑡ℎ𝑒  𝑑𝑎𝑡𝑎  

The malware detection is sensed for the data processed by the sensors and is
conditioned by the following formula:

Condition: 𝑥!     < 𝑥   ± 𝑛 ∗ 𝜎 (2.2)

2.4. Algorithm evaluation

The IoT security algorithm has been developed by using Python programming
language. Python is an interpreted, object-oriented programming language with
dynamic semantics. The programming language is built in data structures,
combined with dynamic typing and dynamic binding, make it very attractive for
Rapid Application Development, as well as for use as a scripting or glue
language to connect existing components together. Python reduces the cost of
program maintenance due to it’s simple, easy to learn syntax emphasizes
readability and therefore. Python supports modules and packages, which
encourages program modularity and code reuse. The Python interpreter and the
extensive standard library are available in source or binary form without charge
for all major platforms, and can be freely distributed.
In the picture below, Fig.2.2, is depicted the module of flows creation algorithm.
It can be observed how dangerous flows are modelled.

a) A conformant flow is created with the following properties:

a. Using the base of 20 packets/second – which shall match for
example the readings of 20 sensors each second, we introduce a
small uniform variance.
b. The number of bytes per second is linearly obtained from the
packets per second (using a standard 100 bytes per packet).

b) A bad flow is created with a probability of 10%. A bad flow has different
properties:
a. The number of packets per second are duplicated (in comparison
with a conformant flow).
b. Packet size is also 50% increased.

33
Improving IoT Security with SDN

Fig.2.2 Flows creation

In the following figure are presented the modules of: mean function definition,
standard deviation definition and flows checking algorithm.

Fig.2.3 Definition of Mean function, standard deviation and check flows

The following module presents the evaluation of the algorithm. First the
algorithm is checking for bad flows through the flows created in the module
presented in Fig.2.2 then the algorithm it calculates the percentage bad flows
error by applying the condition presented through the formula 2.2 that is
comprised between, (N_SIGMA) threshold_up and (N_SIGMA)
threshold_down.

34
Improving IoT Security with SDN

Fig.2.4 Evaluation algorithm

2.5. Simulation results

In the previous section were presented the main modules of the security
algorithm, thus, during the simulation process, the main purpose was to
simulate the algorithm and to detect the ideal length of window and standard
deviation for which the error to detect the traffic malware is the smallest.

Also, is important to mention that the simulation was realized for 5 simulated
parameters N_SIGMA and 3 simulated parameters of WINDOW (see below
scenarios results a, b, c, d) for both types of traffic simulated, packets/s and
bytes/s, therefore the conclusions and explanations made for each scenario are
based strictly on these results.
For the simulation of the algorithm were modelled the following simulation
scenarios:

a) Standard Deviation: N_SIGMA, Simulated Traffic: packets/s, Detected

Error (%): error,
b) Simulated traffic: packets/s, Window of simulation: w, Detected error (%):
error
c) Standard Deviation: N_SIGMA, Simulated Traffic: bytes/s, Detected Error
(%): error
d) Simulated Traffic: bytes/s, Window of simulation: w, Detected Error (%):
error

35
Improving IoT Security with SDN

2.5.1 Analysed data: packets/sec, N_SIGMA

The main purpose of this simulation was to detect the best (smallest) standard
deviation of the flow for which the error to detect the traffic malware is the
smallest.

The simulation has been realized for 1000 samples.

For each N_SIGMA it has been simulated the algorithm 3 times and each time
the error was tracked, afterwards it has been calculated the mean value of Error
(%). The calculated mean value of Error (%) is presented in the table below:

Table 2.1 Simulation results Error  (%)  vs  N_SIGMA,  packets/s

N_SIGMA   2   4   8   10   12  
Error  (%)  vs  N_SIGMA   73,3   26,9   17,2   13,8   18,3  

By variations of the traffic standard deviation (sigma) it was noticed that when
incrementing sigma the error was decrementing reaching the best result for
N_SIGMA =10 and error = 13,8% (see values in Table 2.1).

As can be visualized in the Fig. 2.2 the best result has been obtained for
N_SIGMA = 10, error= 13,8%. If we take a deeper look, we can observe that is
an optimal value, due to the fact that for lower and higher values, the
performance of the algorithm decreases in terms of errors in detected security
threats. This optimal value for N_SIGMA is related somehow to the dangerous
flows properties, in terms of both the number of times that packets per second
are multiplied and the small standard deviation produced due to the fact that
only values from 20 to 23 packets/sec are generated.
If the selected N_SIGMA is lower that the optimal, the algorithm might detect
false positives, due to the proximity to standard flows. On the other hand, if the
selected N_SIGMA is higher than the optimal, the algorithm doesn’t detect
many possible threats due to the fact that only a small portion of dangerous
flows might have such a higher number of packets/sec.

36
Improving IoT Security with SDN

Error  (%)  vs  N_SIGMA  

80,0  

70,0  

60,0  

50,0  

40,0  

30,0  

20,0  

10,0  

0,0  
2   4   8   10   12  

Fig.2.2 Simulation Scenario a)

2.5.2 Analysed data: packets/sec, WINDOW

The simulation has been realized for N_SIGMA= 10 and 1000 samples.
For each WINDOW length it was simulated the algorithm 3 times and each time
the error was tracked, afterwards it has been calculated the mean value of Error
(%). The calculated mean value of Error (%) is presented in the table below:

Table 2.2 Simulation results Error  (%)  vs  WINDOW,  packets/s

WINDOW     5   10   20  
Error  (%)  vs  WINDOW     13,8   3,9   5,2  

As a first approach it was observed that when incrementing the window of

simulation from 5 to 10 the error was decrementing (see Table 2.2). This can be
explained due to the fact that a small window size, doesn’t leave time to
properly measure the flow standard deviation. Decisions made by this incorrect
measurement of standard deviation will be error prone. Nevertheless this
behaviour wasn’t linear as for incrementing the window length from 10 to 20, the
error incremented.

As can be visualized in the Fig. 2.3 the best result has been obtained for
WINDOW = 10, error= 3,9%.

37
Improving IoT Security with SDN

Error  (%)  vs  WINDOW  

16,0  

14,0  

12,0  

10,0  

8,0  

6,0  

4,0  

2,0  

0,0  
5   10   20  

Fig.2.3 Simulation Scenario b)

2.5.3 Analysed data: bytes/sec, N_SIGMA

The main purpose of this simulation was to detect the best (smallest) standard
deviation of the flow for which the error to detect the traffic malware is the
smallest.

The simulation has been realized for 1000 samples.

For each N_SIGMA it has been simulated the algorithm 3 times and each time
the error was tracked, afterwards it has been calculated the mean value of Error
(%). The calculated mean value of Error (%) is presented in the table below:

Table 2.3 Simulation results Error  (%)  vs  N_SIGMA,  bytes/s

N_SIGMA   2   4   8   10   12  
Error  (%)  vs  N_SIGMA   73,3   30,7   14,6   6,5   20,0  

By variation of the traffic standard deviation (N_SIGMA) it has been noticed that
when incrementing sigma the error was decrementing. As can be visualized in
the Fig. 2.4 the best result has been obtained for N_SIGMA = 10, error= 6,5%.
This systems has the same behaviour as the scenario from section 2.5.1 as
somehow is similar with the one presented in this section, the change is that
analysis is realized for the traffic-bytes/s.

38
Improving IoT Security with SDN

Error  (%)  vs  N_SIGMA  

80,0  

70,0  

60,0  

50,0  

40,0  

30,0  

20,0  

10,0  

0,0  
2   4   8   10   12  

Fig.2.4 Simulation Scenario c)

2.5.4 Analysed data: bytes/sec, WINDOW

The simulation has been realized for N_SIGMA= 10 and 1000 samples.
For each WINDOW length it was simulated the algorithm 3 times and each time
the error was tracked, afterwards it has been calculated the mean value of the
Error (%). The calculated mean value of Error (%) is presented in the table
below:

Table 2.4 Simulation results Error  (%)  vs  WINDOW,  bytes/s

WINDOW     5   10   20  
Error  (%)  vs  WINDOW     6,53   0,03   0,56  

As a first approach it was observed that when incrementing the window of

simulation from 5 to 10 the error was decrementing (see Table 2.4). This can be
explained due to the fact that a small window size, doesn’t leave time to
properly measure the flow standard deviation. Decisions made by this incorrect
measurement of standard deviation will be error prone. Nevertheless this
behaviour wasn’t linear as for incrementing the window length from 10 to 20, the
error incremented.

As can be visualized in the Fig. 2.5 the best result has been obtained for
WINDOW = 10, error= 0,03%.

39
Improving IoT Security with SDN

Error  (%)  vs  WINDOW  

7,00  

6,00  

5,00  

4,00  

3,00  

2,00  

1,00  

0,00  
5   10   20  

Fig.2.5 Simulation Scenario d)

Overall, it has been observed that for both type of simulated traffic (packets/s
and bytes/s) the best behaviour of the algorithm is attained for window length
=10 and N_SIGMA=10. It results that the behaviour of the algorithm is stable for
the values mentioned before.

Additional to the simulation results it can be observed in the figure depicted

below (see Fig 2.6) that for flows which vary dynamically, smaller (but not too
small) – local- window sizes are better, as they allow the better tracking of flow
anomalies.

Fig.2.6 Window importance

40
Improving IoT Security with SDN

CHAPTER 3. EXPERIMENTAL RESULTS

3.1 Testbed description

In order to carry out the experimental part of this work an IoT platform has been
connected to the ADRENALINE Testbed®, developed by the researchers form
CTTC (Fig 3.1). The cloud/fog computing platforms and transport network offer
an integrated cloud and network orchestration which is capable of creating VMs
and establishing End-to-End (E2E) paths through heterogeneous networks
considering multi-domain SDN orchestration. The deployed architecture allows
providing E2E connectivity services of VMs located in different network
locations, interconnected though multi-layer multi-domain networks considering
heterogeneous SDN/OpenFlow (OF) and General Multiprotocol Label Switches
(MPLS)/Path Computation Element control planes [8].

The IoT platform (Fig 3.2) consists of a temperature and a dioxide carbon (CO2)
sensors, 2 Wireless Sensor Network (WSN) nodes and 2 gateways that gather
the data generated by the sensors, one SDN NFV Edge Node to control the
flows of data coming from the sensors and a database where the data is stored.
The SDN NFV Edge Node network element is able to provide computing,
storage and networking services, acting as a cloud edge node (fog node) and
has been introduced in [8].

Fig.3.1 presents the considered system architecture which includes the

proposed SDN/NFV-enabled edge node. The proposed node consists of an OF-
enabled switch, compute and storage resources. The switch is controlled via an
edge SDN controller, while the computation and storage resources are
controlled with an edge cloud/fog controller. On top of the proposed
architecture, the Integrated Cloud/Fog and Network Orchestrator is responsible
for handling a VM and network connectivity requests, which are processed
through the Cloud/Fog and Multi-domain SDN orchestrators.

Fig.3.1 Overall ADRENALINE Testbed

41
Improving IoT Security with SDN

The proposed E2E security application (Fig.3.2) runs on top of the SDN/NFV-
enabled edge node and it has been implemented as described in previous
chapter and the implementation has been done in python.

Fig.3.2 IoT Security Testbed

The proposed SDN/NFV edge node has been developed using an Intel NUC
NUC5i5RYH, with 16Gb RAM and 120 Gb SSD. Several USB to Ethernet port
converters have been included in order to extent the node switching
capabilities. RYU SDN controller and OpenStack nova services are run in the
node as well.

The WSN nodes are Z1 motes by Zolertia (Fig 3.3), which feature a 16-bit RISC
CPU @16MHz, an 8KB RAM and a 92 KB flash memory. They also include the
CC2420 transceiver, which is IEEE 802.15.4 compliant. These nodes support
ContikiOS, an open-source operating system for the IoT, which connects tiny,
low-cost, low-power microcontrollers to the Internet and supports Ipv6 through
6LowPAN. It is worth noting that each mote can operate as either a source or a
sink node.

42
Improving IoT Security with SDN

Fig.3.3 WSN node – Z1 mote by Zolertia

Finally, the IoT gateways are connected to 2 WSN sink nodes via USB. IoT
gateways have been implemented using a Raspberry Pi 2, using Raspbian,
based on Debian. The IoT gateway reads the measurements in the USB port
and it retransmits them to a processing software, which is run in a VM running
at the edge node.

Fig. 3.4 shows the network topology as seen by the SDN orchestrator. It can be
observed that the SDN/NFV- enabled edge node is depicted in red, and
interconnected towards the metro network.

43
Improving IoT Security with SDN

Fig.3.4 Network Topology

3.2 Testbed configuration

In Fig.3.5, the overall system from the networking perspective is depicted. First,
two IoT gateways are interconnected towards a virtual software switch (SW1),
running on the edge node. This external virtual software switch is
interconnected towards an internal virtual software switch (SW2) into with the
virtual machines are connected. Finally, the IoT virtual machine (test_iot) is
connected to this second switch.

44
Improving IoT Security with SDN

Fig.3.5 Overall system configuration

Fig.3.6 System motes

45
Improving IoT Security with SDN

3.2.1 Flow description

In the table below, are described the technical details of the flow, MAC
addresses and IP addresses that are configured in the IoT Security Testbed, for
the gateways and the SDN/NFV Edge Node. The details, in terms of flow traffic
were described in the Section 3.1 Testbed description. While iot-gw1 and iot-
gw2 are the external IoT gateways, test_iot is the virtual machine running in the
edge node, which is responsible for running the storage services (implemented
as a MySQL database).

Table 3.1 Testbed description

Name Gateway MAC Switch MAC address Port

IP address
flow address switches no.
iot-gw2 10.1.14.8
iot-gw2 b8:27:eb:8a:c5:ff 00:00:80:3f:5d:08:2b:72 3
private-iot 10.1.7.45
iot-gw1 10.1.14.7
iot-gw1 b8:27:eb:4f:67:5b 00:00:80:3f:5d:08:2b:72 1
private-iot 10.1.7.45
6f16ab70-
b9b6-47ca-
10.1.14.17
test_iot 886e- fa:16:3e:ef:ef:15 00:00:6a:5a:fb:3b:66:41 41
192.168.30.30
36b3c6696375
private-iot

Fig 3.5 shows the SQL Database, which is composed by the following data
columns: date and hour when the data has been recorded, id of the mote (in
this case id of the sensor), value recorder, description of the recorded value and
the id of the value.

46
Improving IoT Security with SDN

Fig.3.6 IoT SQL Database

Flow Description

The traffic is routed from IoT Gateway 1 with MAC address b8:27:eb:4f:67:5b
and IP address 10.1.14.7 through the source: OpenFlow switch with the
following MAC address 00:00:80:3f:5d:08:2b:72 and interface connected to port
1, with the following IP address 10.1.7.48 and the destination: a switch with the
following MAC address 00:00:6a:5a:fb:3b:66:41, this switch is in charge of
managing the traffic of the IoT SQL Database through an interface of the
controller, number 41, with the following IP address 192.168.30.30. Below is
presented the script of the flow.

47
Improving IoT Security with SDN

Source: {“routerId”:”00:00:80:3f:5d:08:2b:72”,”interfaceId”:”1”,”endpointId”:”iot-gw1”}
Dst:{“routerId”:”00:00:6a:5a:fb:3b:66:41”,”interfaceId”:”41”,”endpointId”:”test_iot”}
Traffic Params: {“reservedBandwidth”:”100000000”}
ConnectionType: {“direction”:”bidir”,”layer”:”48thernet”,”layerId”:”48thernet”}
Match: {“ethDst”:”fa:16:3e:ef:ef:15”,”ethSrc”:”b8:27:eb:4f:67:5b”}

The traffic is routed from Gateway 2 with MAC address b8:27:eb:8a:c5:ff and IP
address 10.1.14.8 through the source, OpenFlow switch with the following MAC
address 00:00:80:3f:5d:08:2b:72 and interface connected to port 3, with the
following IP address 10.1.7.49 and the destination: a switch with the following
MAC address 00:00:6a:5a:fb:3b:66:41 , this switch is in charged to manage the
traffic of the IoT SQL Data Base through an interface of the controller, number
41, with the following IP address 192.168.30.30. Below is presented the script
of the flow.

Src: {“routerId”:”00:00:80:3f:5d:08:2b:72”,”interfaceId”:”3”,”endpointId”:”iot-gw2”}
Dst: {“routerId”:”00:00:6a:5a:fb:3b:66:41”,”interfaceId”:”41”,”endpointId”:”test_iot”}
Traffic Params: {“reservedBandwidth”:”100000000”}
ConnectionType: {“direction”:”bidir”,”layer”:”48thernet”,”layerId”:”48thernet”}
Match: {“ethDst”:”fa:16:3e:ef:ef:15”,”ethSrc”:”b8:27:eb:8a:c5:ff”}

3.2.2 Port monitoring (Collector)

As explained in the section 3.1 IoT Security Architecture, the Collector module
is responsible for data gathering, a prerequisite in order to perform flow-based
anomaly detection. This module collects flow information and periodically
exports them to the Anomaly Detection module.

Below are presented the scripts that are collecting the traffic from the switch
OF_1 (Fig.3.5) and send them to the algorithm presented in the section 2.4:

48
Improving IoT Security with SDN

Fig.3.7 Script 1: traffic collection

Fig.3.8 Script 2: traffic collection

The flows are recorded as per packets per second and bytes per second as
presented in the traffic frame presented below.

Flow 1:

Flow 1match: {u’dl_type’: 2048, u’nw_dst’: u’0.0.0.0’, u’dl_vlan_pcp’: 0, u’dl_src’:

u’b8:27:eb:8a:c5:ff’, u’nw_proto’: 0, u’tp_dst’: 0, u’tp_src’: 0, u’dl_dst’:
u’fa:16:3e:ef:ef:15’, u’dl_vlan’: 0, u’nw_src’: u’0.0.0.0’, u’in_port’: 3}
Flow 1 packets per second: 10.1859442215
Flow 1 bytes per second: 1013.40158784
packets_per_second [10.185960712699861, 10.185944221504872]
packets_per_second diff -1.64911949891e-05
bytes_per_second [1008.6098352771432, 1013.4015878414848]
bytes_per_second diff 4.79175256434

Flow 2:

Flow 2match: {u’dl_type’: 2048, u’nw_dst’: u’0.0.0.0’, u’dl_vlan_pcp’: 0, u’dl_src’:

u’b8:27:eb:4f:67:5b’, u’nw_proto’: 0, u’tp_dst’: 0, u’tp_src’: 0, u’dl_dst’:
u’fa:16:3e:ef:ef:15’, u’dl_vlan’: 0, u’nw_src’: u’0.0.0.0’, u’in_port’: 1}
Flow 2 packets per second: 3.99448802511
Flow 2 bytes per second: 365.495654297
packets_per_second [3.994500008345081, 3.99448802510669]
packets_per_second diff -1.19832383909e-05
bytes_per_second [365.4967507635749, 365.49565429726215]
bytes_per_second diff -0.00109646631273

49
Improving IoT Security with SDN

Flow 3:

Flow 3match: {u’dl_type’: 2048, u’nw_dst’: u’0.0.0.0’, u’dl_vlan_pcp’: 0, u’dl_src’:

u’fa:16:3e:ef:ef:15’, u’nw_proto’: 0, u’tp_dst’: 0, u’tp_src’: 0, u’dl_dst’:
u’b8:27:eb:8a:c5:ff’, u’dl_vlan’: 0, u’nw_src’: u’0.0.0.0’, u’in_port’: 8}
Flow 3 packets per second: 6.19145643892
Flow 3 bytes per second: 458.567225282
packets_per_second [6.091620344662047, 6.1914564389153695]
packets_per_second diff 0.0998360942533
bytes_per_second [456.7716632210525, 458.567225282248]
bytes_per_second diff 1.7955620612

Flow 4:

Flow 4match: {u’dl_type’: 2048, u’nw_dst’: u’0.0.0.0’, u’dl_vlan_pcp’: 0, u’dl_src’:

u’fa:16:3e:ef:ef:15’, u’nw_proto’: 0, u’tp_dst’: 0, u’tp_src’: 0, u’dl_dst’:
u’b8:27:eb:4f:67:5b’, u’dl_vlan’: 0, u’nw_src’: u’0.0.0.0’, u’in_port’: 8}
Flow 4 packets per second: 1.99724420276
Flow 4 bytes per second: 156.783669917
packets_per_second [1.99725537763938, 1.9972442027629256]
packets_per_second diff -1.11748764544e-05
bytes_per_second [156.78454714469135, 156.78366991688966]
bytes_per_second diff -0.000877227801681

The fist part of the algorithm, collector module, is devoted to generate the flows
in packets per second and bits per second. In the first step is depicted, through
def create bad_flows function, the percent of error (bad_flow) that will be
generated.
In the second approach are depicted the flows comprised between a range of 0
and N_Flows, where N_Flows is 5. The depiction of the dangerous flows starts
when the condition if not create bad_flow () is not accomplished.

3.3 Intrusion detection algorithm (Anomaly detection)

As explained in the Section 3.1 IoT Security Architecture, the data produced by
the previous module (Data Collector) are subsequently fed to the Anomaly
Detection module at periodic time intervals, thus creating discrete time
windows. For every time-window this module inspects all flow entries, exposing
any flow-related network anomaly and identifying a potential attacker or the
victim of the attack. Moreover, it performs successfully not only in identifying the
attack pattern, but also the attacker or the victim (i.e. host under attack). As
soon as an anomaly is detected in the network, our algorithm inspects and
correlates specific network metrics identifying the attack and exposing all
related information to the Anomaly Mitigation module.

3.4 Anomaly Mitigation

The Anomaly Mitigation module aims to neutralize identified attacks, inserting
flow-entries in the flow table of the Open Flow switch (or modify existing ones)
in order to block the desired malicious traffic.

50
Improving IoT Security with SDN

A widely used and easy to be implemented method for the flow mitigation is the
flow limiting in the OF Switch. In the picture depicted below can be visualized
through Wireshark the flow traffic eliminated from the switch OF_1, IP address
10.1.7.45.

Fig.3.9 Wireshak: Flow limiting in the OF Switch

51
Improving IoT Security with SDN

CHAPTER 4. CONCLUSIONS AND FUTURE WORK

LINES
This chapter presents the conclusions and possible future improvements of the
project. Moreover, are also described some aspects related with the ambient
impact of the project.

4.1 Conclusions and results

This master thesis final project has been motivated by the growing globalization
experienced by IoT applications that are covering a wide area of fields, such as
energy efficiency, transport, home, health etc. As explained in the first chapter
of this thesis, is proved that the IoT presents numerous benefits to consumers
and to all types of cities, developed and emergent, from all over the world. IoT
has the potential to change the ways that consumers interact with technology in
fundamental ways and is likely to fusion the virtual and physical worlds together
in ways that are currently difficult to grasp and imagine. From a security
perspective, the predicted widespread deployment of sensors and sensing
devices through a wide area, such as cars, homes, through the cities (managed
by the cities municipalities), even the body – stances particular challenges. As
physical objects in our everyday lives increasingly detect and share
observations about us, consumers will likely want to interact with a secure
environment. On the other side, IoT network administrators are handling with
big challenge in terms of IoT network security due to the fast market
deployment of heterogeneous IoT networks and missing mass research on the
IoT security side.

In this complete scenario surrounded by IoT market concerns and challenges

related with security, the results obtained through the work developed in this
master thesis are delivering a simple, detached and efficient security algorithm
for IoT sensors networks for uses related with sensing of temperature and air
pollution. Nevertheless, the Software-Defined Networking (SDN) is a viable
alternative network architecture that allowed for programming the network and
opening the possibility of creating a more efficient security application.
This master thesis has been performed in the premises of CTTC, a research
center located in Castelldefels (Spain). More exactly, the master thesis has
been performed at the cloud/fog computing platforms and transport network of
the ADRENALINE Testbed ®. In the context of evolving the capabilities of this
testbed, my work has consisted in:
- The debugging of the Fog node and its SDN controller, which was quite
unstable.
- The design of an overall architecture for the security application, which
takes into account the several needed modules in order to properly
analyse possible security threads.
- Design and validation of a simple algorithm (several have been studied)
in order to validate the proposed application. The algorithm has been
studied against a simulated security thread and its performance has
been evaluated.

52
Improving IoT Security with SDN

- Develop a security application which interacts with the Fog node SDN
controller. Using a REST API, the flow statistics are read and analysed,
using the previously validated algorithm.

The results obtained during the experimental process are valuable insights in
which regards the election of the most proficient parameters (standard deviation
and window supervision length) that ensure the efficiency of the algorithm. By
knowing and implementing the most efficient parameters, it ensures the best
effort of the algorithm and therefore is created a secure environment for the
proposed testbed.

4.2 Future work lines

In terms of future improvements, is desirable to run the algorithm in an
extended network (composed by more than 4 sensors) in order to test the
efficiency of the algorithm and to make further improvements. Although the
algorithm is efficient, when tested in the proposed testbed of the project, it could
be the case that the algorithm will require further improvements in order to cope
with the challenges encountered in the extended IoT network.

Another further improvement of the security algorithm will be to extend the

functionalities for other types of applications such as car sensor based
networks, health sensor based networks, parking sensors, etc., that contain
different types of sensors than the ones used in the testbed of this project.
Added interesting future work line will be to analyse a different type of security
architecture, as for example Generic Architecture Network Intrusion Detection
System (ANIDS) described in section 1.1.3 IoT Security Architecture. This
architecture contains a dedicated module for the anomaly detection, called
Anomaly Detection Engine, that attempts to detect occurrence of any intrusion
either online or offline. At a first glance, this architecture is more efficient in
terms of anomaly detection due to the fact that it executes a pre-processing of
the traffic before sending it to the detection engine. If the attacks are known,
they can be detected using the misuse detection approach. On the other hand,
unknown attacks can be detected using the anomaly-based approach based on
an appropriate matching mechanism.
In terms of improvement of anomaly detection it could be also studied others
Anomaly Methods as for example K-means clustering algorithm that is an
unified approach to cluster the data and identify the outliers. This approach has
been studied for the implementation of the project security algorithm but the
development of the programming algorithm it wasn’t realized due to the fact that
it was considered more appropriate the implementation of the standard
deviation algorithm. Anyhow, is worth to continue the development of this
algorithm for further possible improvements of the security algorithm.

4.3 Environmental aspects

As explained in this Master Thesis, in the testbed of the project was used the
fog concept, which brings the cloud computing at the edge of the network. The
use of the fog computing delivers a faster response in terms of data stored in

53
Improving IoT Security with SDN

the IoT database. Along with the fast testbed repose it is improved the energy
use of the networks due to the fact that the fast network response is translated
by a decrement of the energy used to obtain the query data.

54
Improving IoT Security with SDN

Abbreviations and Acronyms

Acronym Description
ADC Analog to digital converter
ANIDS Architecture Network Intrusion Detection System
ARP Address Resolution Protocol
BOS bit Bit Oriented Signalling
BYOD Bring your own device
CTTC Centre Tecnològic Telecomunicacions Catalunya
DDos Distributed denial attack of service
DNS Domain Name System
ECP Explicit Congestion Notification
ICMP Internet Control Message Protocol
ISP Internet Service Provider
OF Open Flow
OVS Open Vswitch
ONOS Open Network Operating System
PAN Personal Area Network
PBB Provider Backbone Bridge
I-SID Backbone Service Identifier
MPLS Multiprotocol Label Switching
NIDS Network intrusion detection system
RSPAN Remote Switch Port Analyser
WSN Wireless Sensors Networks
WAN Wide Area Network
SCTP Stream Control Transmission Protocol
SDN Software Defined Networking
SPAN Switched Port Analyser
TLS Transport Layer Security
VAN Virtualized application networks

55
Improving IoT Security with SDN

Bibliography
[1] Bonomi, Flavio, et al. "Fog computing and its role in the internet of things."
Proceedings of the first edition of the MCC workshop on Mobile cloud
computing. ACM, 2012.

[1] Nadeau, Thomas D., and Ken Gray. SDN: software defined networks.
O'Reilly Media, Inc., (2013).

[2] Bhuyan, Monowar H., Dhruba Kumar Bhattacharyya, and Jugal Kumar
Kalita. Network anomaly detection: methods, systems and tools. pp. 303-336
Communications Surveys & Tutorials, January 2014

[3] Li, Bingdong, et al. "A survey of network flow applications." Pp 567-581,
Journal of Network and Computer Applications 36.2 (2013)

[4] Abaid, Zainab, Mohsen Rezvani, and Sanjay Jha. "MalwareMonitor: An sdn-
based framework for securing large networks." Proceedings of the 2014
CoNEXT on Student Workshop. ACM, (2014)

[5] Giotis, K., et al. "Combining OpenFlow and sFlow for an effective and
scalable anomaly detection and mitigation mechanism on SDN environments."
Pp 122-136, Computer Networks 62 (2014)

[7] Telefonica, “Trend Report. Insecurity in the Internet of Things”, pp 3-10,

(2015)

[8] R. Vilalta, A. Mayoral, R. Muñoz, R. Casellas, R. Martínez, Multi-Tenant

Transport Networks with SDN/NFV, IEEE/OSA Journal of Lightwave
Technology, Vol. 34, No. 8, April 2016.

[9] R. Vilalta, A. Mayoral, D. Pubill, R. Casellas, R. Martínez, J. Serra, C.

Verikoukis, R. Muñoz, End-to-End SDN Orchestration of IoT Services Using an
SDN/NFV-enabled Edge Node , in Proceedings of the Optical Fiber
Communication Conference and Exhibition (OFC), 20-24 March 2016,
Anaheim, California (USA).

[10] Seugwon Shin, Philip Porras, Vinod Yegneswaran, Martin Fong, “FRESCO:
Modular Composable Security Services for Software Defined Networks”, ISOC
Network and Distributed Security Symposium (2013)

[11] Dr. Ovidiu Vermesan, Dr. Peter Friess, Internet of Things: Converging
Technologies for Smart Environments and Integrated Ecosystems, River
Publishess Alborg, 2013

[12] Dinesh Kumar Gupta , “A Review on Wireless Sensors Networks”, Network

and Complex Systems , ISSN 2224-610x (Paper)

[13] IoT Applications:

http://www.libelium.com/top_50_iot_sensor_applications_ranking/

56
Improving IoT Security with SDN

[14] OpenDayLight Project: https://www.opendaylight.org

[15] ONOS: http://onosproject.org

[16] Ryu: https://osrg.github.io/ryu/

[17] OpenFlow 1.3 switch specification:

https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-
specifications/openflow/openflow-spec-v1.3.0.pdf

[18] OpenFlow Switch Specifications, version 1.1.0 implemented, February

28, 2011: http://archive.openflow.org/documents/openflow-spec-v1.1.0.pdf

[19] SDN Architecture: https://www.opennetworking.org/sdn-resources/sdn-

definition

[20] Aparicio Carraza, Julio Tax, Jose Reyes Alamo, “Building a Future in SDN
with one Controller”, The City University of New York,
https://openlab.citytech.cuny.edu/jreyesalamo/files/2012/08/Building-a-Future-
in-SDN-with-one-Controller.pdf

[21] HP SDN VAN Controller:

http://h17007.www1.hp.com/docs/networking/solutions/sdn/4AA4-
8807ENW.PDF

[22] ITU-T Y.2060 (06/2012), Overview of the Internet of things.

57
Improving IoT Security with SDN

Annex: Security algorithm

#!/usr/bin/python  
import  time  
import  random  
import  math    
 
TIME_WINDOW  =  1  
 
N_FLOWS  =  5  
 
T_MAX  =  1000  *  TIME_WINDOW  
 
flow_results_db  =  {}  
 
values_db  =  {}  
 
N_SIGMA  =10  
WINDOW  =  10  
#CHECK_PARAM='packets_per_second'  
CHECK_PARAM='bytes_per_second'  
 
ALGOERRORS  =  0  
ALGODECISIONS  =  0  
FLOWS  =  0  
BADFLOWS  =  0  
BADFLOWS_ERROR  =  0  
 
def  create_bad_flow  (percent=10)  :  
       return  random.randrange(100)  <  percent  
 
def  read_flows(T)  :  
       #print  "reading  flows"  
       for  i  in  range(0,  N_FLOWS):  
               #select  if  flow  is  ok  or  not  
               base_pkts_sec  =  20  
               if  not  create_bad_flow():  
                       
flow_results_db[i]['timestamp'].append(  time.time()  )  
                       
flow_results_db[i]['packets_per_second'].append(  base_pkts_sec  +  
random.randint(  0,  i+4)  )  
                       flow_results_db[i]['bytes_per_second'].append(  100  *  
flow_results_db[i]['packets_per_second'][-­‐1]  )  
                       flow_results_db[i]['bad_flow']  =  False  
               else:  
                       #print  "Creating  dangerous  flows"  

58
Improving IoT Security with SDN

                       
flow_results_db[i]['timestamp'].append(  time.time()  )  
                       
flow_results_db[i]['packets_per_second'].append(  2*(  base_pkts_s
ec  +  random.randint(  0,  i+4)  )    )  
                       
flow_results_db[i]['bytes_per_second'].append(  150*flow_results_
db[i]['packets_per_second'][-­‐1]  )  
                       flow_results_db[i]['bad_flow']  =  True  
               #print  "Flow:  "  +  str(i)  +  "  packets_per_second  "  +  
str(flow_results_db[i]['packets_per_second'][-­‐1])  +  "  
bytes_per_second:  "  +  
str(flow_results_db[i]['bytes_per_second'][-­‐1])  
                 
 
#def  mean  function    
def  mean(values):  
       return  sum(values)*1.0/len(values)  
 
#def  standard  deviation  mean  
def  stanDev(values):  
  length=len(values)  
  m=mean(values)  
  total_sum=0  
  for  i  in  range  (0,length):  
         total_sum+=  (values[i]-­‐m)**2  
  under_root=total_sum*1.0/length  
  return  math.sqrt(under_root)  
   
def  check_flow(flow_id):  
       global  ALGODECISIONS,  ALGOERRORS,  FLOWS,  BADFLOWS,  
BADFLOWS_ERROR  
       ALGODECISIONS  =  ALGODECISIONS  +  1  
       FLOWS+=1  
       result  =  False  
       if  CHECK_PARAM=='packets_per_second':  
               #check  pkts_per_sec  
               result  =  check_flow_param(flow_id,  
'packets_per_second'  )  
       else:  
               #check  bytes_per_sec  
               result  =  check_flow_param(flow_id,  'bytes_per_second'  )  
 
       #evaluating  algorithm  
       if  ALGODECISIONS  >=  WINDOW  *  N_FLOWS  :  
               if  flow_results_db[flow_id]['bad_flow']:  
                       BADFLOWS  +=  1  
                       print  "Checking  a  bad  flow"  
               if  (result  !=  flow_results_db[flow_id]['bad_flow']  ):  

59
Improving IoT Security with SDN

                       print  "ALGO  OK"  

               else:  
                       print  "ALGO  FAILED"  
                       ALGOERRORS  =  ALGOERRORS  +  1  
                         
                       if  flow_results_db[flow_id]['bad_flow']:  
                               BADFLOWS_ERROR  =  BADFLOWS_ERROR  +1  
         
         
       print  "ALGORITHM  ERROR  PERCENTAGE:  "  +  str(  ALGOERRORS  *  
100.0  /  ALGODECISIONS  )  +  "%"  
       if  BADFLOWS  >  1:  
               print  "BAD  FLOWS  NOT  DETECTED  PERCENTAGE:  "  +  
str(  BADFLOWS_ERROR  *  100.0  /  BADFLOWS  )  +  "%"  
       print  "BAD  FLOWS  PERCENTAGE:  "  +  str(  BADFLOWS  *  100.0  /  
FLOWS  )  +  "%"  
 
def  check_flow_param(flow_id,  param)  :  
       values  =  values_db[flow_id]  
       #values  =  flow_results_db[flow_id][param][0:-­‐1]  
       print  values  
       if  len(values)  <  WINDOW  :  
               print  "Not  checking.  SMALL  WINDOW.  Adding:  "  +  
str(flow_results_db[flow_id][param][-­‐1])  
               
values_db[flow_id].append(flow_results_db[flow_id][param][-­‐1])  
               return  True  
 
       #condicion  
       print  "Flow:  "  +  str(flow_id)  +  "  Current  param  "  +  param  +  
"  mean:  "  +  str(mean(values))  +  "  stanDev:  "  +  
str(stanDev(values))  
       threshold_up  =  mean(values)+N_SIGMA*stanDev(values)  
       threshold_down  =  mean(values)-­‐N_SIGMA*stanDev(values)  
 
       print  "Flow:  "  +  str(flow_id)  +  "  Current  param  "  +  param  +  
"  value:  "  +  str(flow_results_db[flow_id][param][-­‐1])  +  "  
threshold_up:  "  +  str(threshold_up)  +  "  threshold_down:  "  +  
str(threshold_down)  
 
       if  (  flow_results_db[flow_id][param][-­‐1]  >    threshold_up  )  
or  (  flow_results_db[flow_id][param][-­‐1]  <  threshold_down  )  :  
               print  "Security  warning  in  Flow  "  +  str(flow_id)  +  "  
parameter:  "  +  param  
                 
               return  False  
         
       values_db[flow_id].pop(0)  

60
Improving IoT Security with SDN

       values_db[flow_id].append(flow_results_db[flow_id][param][-­‐
1])  
       return  True  
 
def  process_flows():  
       for  i  in  range(0,  N_FLOWS):  
               check_flow(i)  
 
 
         
if  __name__  ==  '__main__':  
       #print  "SECURITY  APP"  
       T  =  0  
 
       #INIT  
       for  i  in  range(0,  N_FLOWS):  
               flow_results_db[i]  =  {  'timestamp'  :  [],  
'packets_per_second'  :  [],  'bytes_per_second'  :  [],  'bad_flow'  :  
False  }  
               values_db[i]  =  []  
 
       #START  FLOW  LOOP  
       while(T<=T_MAX):  
               print  "HI.  Current  time:  "  +  str(T)  
               read_flows(T)  
               process_flows()  
               #time.sleep(TIME_WINDOW)  
               T  +=  TIME_WINDOW

61