IN DEGREE PROJECT ELECTRICAL ENGINEERING,SECOND CYCLE, 30 CREDITS
, STOCKHOLM SWEDEN 2016
Simulative Evaluation of Security Monitoring Systems based on SDN
ALEXANDRA STAGKOPOULOU
KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF INFORMATION AND COMMUNICATION TECHNOLOGY
School of Information and Communication Technology (ICT)
KTH Royal Institute of Technology
Degree Project in Electrical Engineering
Simulative Evaluation of Security Monitoring Systems based on SDN
Alexandra Stagkopoulou, {[email protected]}
Examiner: Markus Hidell
Supervisor: Peter Sjödin
KTH, Royal Institute of Technology
Industry Supervisor: Marco Tiloca
SICS, Swedish ICT
Stockholm, 2016
i
ii
Abstract
Software Defined Networks (SDN) constitute the new communication paradigm of
programmable computer networks. By decoupling the control and date plane the network
management is easier and more flexible. However, the new architecture is vulnerable to a
number of security threats, which are able to harm the network. Network monitoring
systems are pivotal in order to protect the network. To this end, the evaluation of a network
monitoring system is crucial before the deployment of it in the real environment. Network
simulators are the complementary part of the process as they are necessary during the
evaluation of the new system’s performance at the design time.
This work focuses on providing a complete simulation framework which is able to
(i) support SDN architectures and the OpenFlow protocol, (ii) reproduce the impact of
cyber and physical attacks against the network and (iii) provide detection and mitigation
techniques to address Denial-of-Service (DoS) attacks. The performance of the designed
monitoring system will be evaluated in terms of accuracy, reactiveness and effectiveness.
The work is an extension of INET framework of OMNeT++ network simulator.
Keywords: SDN; Security; (D)DoS attacks; Monitoring System; OMNeT++; INET
iii
Sammanfattning
Software Defined Networks (SDN) utgör den nya kommunikationsmodellen av
programmerbara datornätverk. Genom separation av kontroll- och dataplanet blir
administrativ hantering av datornätverk enklare och flexiblare. Arkitekturen öppnar
emellertid upp nya säkerthets hot, övervakningssystem är därför väsentliga för att skydda
datornätverk. Till följd av detta är utvärdering av övervakningssystem kritiskt innan
driftsättning i produktionsmiljö. Nätverkssimulatorer är den kompletterande delen i
processen då de är nödvändiga för utvärdering av systemets prestanda under design fasen.
Detta arbete fokuserar på att tillföra ett komplettet simulations ramverk vilket är
kapabelet till; (i) ge stöd för SDN arkitekturer och OpenFlow protokollet, (ii) reproducera
skadegörelsen av cyber- och fysiska attacker mot datornäterk och (iii) förse sätt att
upptäcka och mildra Denial-of-Service (DoS) attacker. Prestanda av det designade
övervakningssystemet är utvärderat i form av exakthet, responstid och effektivitet. Arbetet
är en utvidgning av INET ramverket, som är del av OMNeT++ network simulator.
Nyckelord: SDN; Säkerhet; (D)DoS attacks; Övervakningssystem; OMNeT++; INET
iv
Acknowledgments
I would like to express my gratitude to my supervisor at SICS, Swedish ICT, Marco Tiloca
for the endless support and guidance during this project. Moreover, I would like to thank
my supervisor and examiner at KTH, Royal Institute of Technology, Peter Sjödin and
Markus Hidell for their valuable feedback and help. Last but not least, I am thankful to my
family and friends for their patience and support during this thesis.
v
Table of Contents
List of Figures .................................................................................................................. viii
List of Tables ...................................................................................................................... x
Abbreviations and Acronyms ............................................................................................ xi
1. Introduction .......................................................................................................... 1
1.1. Motivation ............................................................................................................ 2
1.2. Problem: SDN Security Risks .............................................................................. 2
1.3. Problem Statement ............................................................................................... 3
1.3.1.Simulative approach of security attacks against SDN ........................................ 4
1.3.2.SDN-related security risks: Why DoS? ............................................................... 4
1.4. Goal and Objectives ............................................................................................. 4
1.5. Methodology ........................................................................................................ 5
1.6. Outline .................................................................................................................. 7
2. Background .......................................................................................................... 8
2.1. Towards... Software Defined Networks (SDN) ................................................... 8
2.2. Software Defined Networks (SDN) ..................................................................... 9
2.3. OpenFlow Protocol ............................................................................................ 10
2.4. SDN and Simulative Approaches ....................................................................... 11
2.4.1. OMNeT++ & INET ......................................................................................... 12
3. SDN-based (DDoS) Security Monitoring .......................................................... 13
3.1. Statistics Collection ............................................................................................ 13
vi
3.2. Attack Detection ................................................................................................. 16
3.3. Mitigation ........................................................................................................... 17
3.4. Selected Methods ............................................................................................... 20
4. A use-case SDN Security Monitoring System ................................................... 21
4.1. SDN support in INET framework ...................................................................... 21
4.2. New Controller Overview .................................................................................. 24
4.3. Statistics Collection ............................................................................................ 26
4.4. Attack Detection ................................................................................................. 26
4.4.1. Entropy Algorithm ........................................................................................... 27
4.5. Mitigation ........................................................................................................... 30
5. Simulative Evaluation of Attacks, SEA++ ......................................................... 31
6. Evaluation........................................................................................................... 34
6.1. Topology and Traffic Scenario .............................................................................. 34
6.2. Defining Entropy Threshold................................................................................... 35
6.3. Experimental Overview.......................................................................................... 36
6.4. Total number of Received Packets per second ....................................................... 37
6.4.1. Fixed Statistic Collection Intervals ............................................................. 38
6.4.2. Fixed Attack Rate ............................................................................................ 40
6.5. Entropy Value .................................................................................................... 42
6.6. Conclusion Remarks .......................................................................................... 45
vii
7. Discussion and Conclusion ................................................................................ 47
7.1. Limitations ............................................................................................................. 48
7.2. Future Work ........................................................................................................... 48
7.3. Benefits, Economic & Environmental, Social & Ethical Aspects ......................... 49
7.3.1. Benefits ............................................................................................................ 49
7.3.2. Economic and Environmental Aspects ............................................................ 50
7.3.3. Social and Ethical Aspects .............................................................................. 50
7.4. Conclusion .......................................................................................................... 50
8. References .......................................................................................................... 52
viii
List of Figures
FIGURE 1: SDN ARCHITECTURE. THE SEPARATION OF CONTROL AND DATE PLANE AND THE
IMPLEMENTATION OF THE LOGIC IN A SOFTWARE CENTRALIZED CONTROLLER. THE
COMMUNICATION BETWEEN THE CONTROLLER AND THE SWITCHES IS BASED ON THE
OPENFLOW PROTOCOL. ................................................................................................ 1
FIGURE 2: METHODOLOGY FLOWCHART. ............................................................................. 6
FIGURE 3: SDN TOPOLOGY WHERE THE CENTRALIZED CONTROLLER INTERACTS WITH THE
SWITCHES. THE SWITCHES ACT AS SIMPLE FORWARDING DEVICES. ............................... 9
FIGURE 4: TRADITIONAL NETWORK SWITCHES WHICH INDICATE THE VERTICAL DEPENDENCY
BETWEEN THE CONTROL AND DATA PLANE. .................................................................. 9
FIGURE 5: OPENFLOW API. THE DOMINANT SOUTHBOUND INTERFACE BETWEEN THE
CONTROLLER AND THE FORWARDING DEVICES. .......................................................... 10
FIGURE 6: THE THREE COMPONENTS WHICH CONSTITUTE THE NETWORK MONITORING
SYSTEM ....................................................................................................................... 13
FIGURE 7: ACTIVE AND PASSIVE OPENFLOW-BASED MONITORING. (A) PASSIVE
MONITORING: WHEN THE FLOW EXPIRES, THE SWITCH SENDS THE COLLECTED DATA TO
THE CONTROLLER. (B) ACTIVE MONITORING: THE CONTROLLER PERIODICALLY
REQUESTS THE CURRENT VALUES OF THE COUNTERS. ................................................. 13
FIGURE 8: REPRESENTATION OF THE CENTRALIZED CONTROLLER IN INET FRAMEWORK. . 22
FIGURE 9: REPRESENTATION OF OPENFLOW-ENABLED SWITCH IN INET FRAMEWORK. .... 22
FIGURE 10: NEW REPRESENTATION OF THE CENTRALIZED CONTROLLER IN INET
FRAMEWORK. .............................................................................................................. 24
FIGURE 11: PACKET MATCHING FIELDS. ............................................................................. 25
FIGURE 12: ATTACK DETECTION ALGORITHM ................................................................... 29
FIGURE 13: SIMPLE EXAMPLE OF AN ATTACK DESCRIPTION USING THE ASL OF SEA++
ATTACK SIMULATOR. .................................................................................................. 32
FIGURE 14: THE CORE REPRESENTATION OF THE ATTACK SIMULATOR SEA++. THE NODES
HAVE BEEN ENHANCED WITH THE LEP MODULE, WHICH INTERCEPTS ALL THE PACKETS
ix
TRAVELING THROUGH THE STACK. GEP MODULE ALLOWS THE COMMUNICATION
BETWEEN THE NODES SUPPORTING MORE COMPLEX ATTACKS. ................................... 32
FIGURE 15: TOPOLOGY OVERVIEW. THE TOPOLOGY CONSISTS OF 1 OF SWITCH AND 1
CENTRALIZED CONTROLLER. THE 4 CLIENTS COMMUNICATE WITH THE 3 SERVERS.
CLIENT 3 IS THE COMPROMISED HOST AND SERVER 2 IS THE TARGET-VICTIM OF THE
SCENARIO. .................................................................................................................. 35
FIGURE 16: TOTAL NUMBER OF RECEIVED PACKETS BY THE VICTIM WITH POLLING INTERVAL
30SEC AND DIFFERENT ATTACK RATES. ...................................................................... 38
FIGURE 17: TOTAL NUMBER OF RECEIVED PACKETS BY THE VICTIM WITH POLLING INTERVAL
15S AND DIFFERENT ATTACK RATES ........................................................................... 39
FIGURE 18: TOTAL NUMBER OF RECEIVED PACKETS PER SECOND BY THE VICTIM WITH
POLLING INTERVAL 45SEC AND DIFFERENT ATTACK RATES. ....................................... 39
FIGURE 19: TOTAL NUMBER OF RECEIVED PACKETS PER SECOND BY THE VICTIM WITH
POLLING INTERVAL 60SEC AND DIFFERENT ATTACK RATES. ....................................... 40
FIGURE 20: TOTAL NUMBER OF RECEIVED PACKETS PER SEC BY THE VICTIM UNDER ATTACK
RATE OF 14 PACKETS PER SEC AND DIFFERENT POLLING INTERVALS. .......................... 41
FIGURE 21: TOTAL NUMBER OF RECEIVED PACKETS PER SECOND BY THE VICTIM UNDER
ATTACK RATE OF 25 PACKETS PER SEC AND DIFFERENT POLLING INTERVALS. ............ 41
FIGURE 22: TOTAL NUMBER OF RECEIVED PACKETS PER SECOND BY THE VICTIM UNDER
ATTACK RATE OF 40 PACKETS PER SEC AND DIFFERENT POLLING INTERVALS. ............ 42
FIGURE 23: ENTROPY VALUE UNDER ATTACK RATE OF 14 PACKETS PER SEC AND DIFFERENT
POLLING INTERVALS ................................................................................................... 43
FIGURE 24: ENTROPY VALUE UNDER ATTACK RATE OF 25 PACKETS PER SEC AND DIFFERENT
POLLING INTERVALS. .................................................................................................. 44
FIGURE 25: ENTROPY VALUE UNDER ATTACK RATE OF 40 PACKETS PER SEC AND DIFFERENT
POLLING INTERVALS. .................................................................................................. 45
x
List of Tables
TABLE 1: SELECTED CONFIGURATION PARAMETERS DURING THE EXPERIMENTS. ............... 37
xi
Abbreviations and Acronyms
API Application Programming Interface
ASI Attack Specification Interpreter
ASL Attack Specification Language
CPU Central Processing Unit
DoS Denial of Service
DDoS Distributed Denial of Service
GEP Global Event Processor
ICMP Internet Control Message Protocol
IP Internet Protocol
LEP Local Event Processor
MPLS Multiprotocol Label Switching
OF OpenFlow Protocol
OMNeT++ Objective Modular Network Testbed in C++
OS Operating System
OSI Open Systems Interconnection model
OSPF Open Shortest Path First
RAM Random Access Memory
SDN Software Defined Network
xii
SEA++ Simulative Evaluation of Attacks
SOM Self-Organizing Maps
TCP Transmission Control Protocol
TLS Transport Layer Security
UDP User Datagram Protocol
XML Extensible Markup Language
xiii
1
1. Introduction
Nowadays, it is the new era of networks which is defined by the Software Defined
Networks (SDN) paradigm [1]. By decoupling the control and data plane, the underlying
switches or routers become simple forwarding devices and the logic is implemented in a
software programmable centralized controller. The given opportunity of software
programmable networks leads the researchers to deploy more flexible protocols, build new
systems and efficiently manage the networks [1]–[3]. However, the infrastructure has
been proved to be vulnerable to attacks [4], so the demand of security monitoring systems
is even higher. In particular, Distributed Denial of Service (DDoS) attacks can be
considered a severe threat as they can easily exhaust the bandwidth between the control
and data plane and lead to increased packet loss and overall network congestion, as [4],
[5] show. Even in such context, the need for reliable simulation tools increases, because it
is inconvenient to apply a new system design directly into the real network without
validation of its legitimacy. Network simulators constitute a safety net for evaluation of
experimental efforts, as the new implementation can be thoroughly tested under various
network conditions and different network infrastructures. It is hence desirable to have a
complete simulation tool, which makes it possible to evaluate the performance of an SDN-
based network, as well as the effectiveness, efficiency and reactiveness of security solutions
for attacks carried out against the network.
Figure 1: SDN architecture. The separation of control and date plane and the implementation of the logic in a software centralized controller. The communication between the controller and the switches is based on the OpenFlow protocol.
2
1.1. Motivation
When it comes to the evaluation of a security monitoring system in terms of
robustness and efficiency against security attacks, it is pivotal to assiduously test the
anomaly detection system before the real deployment. The designer should be aware of
the network communication performance, the effects and the impact of the attacks against
the network and finally, the effectiveness and the accuracy of the deployed system. Thus,
network simulators are essential part of the deployment as they constitute a practical tool
to assess the designed system and especially, use it to represent large-scale networks and
test them against security threats.
Many studies [6]–[11] proposed monitoring systems and mitigation techniques
regarding the identification of the attacks and the protection of the SDN network
respectively. Observing the deployment approaches of the proposals, all the above works
have a three-part common structure. The first part is the implementation of the proposed
algorithm, framework or system based on existing implementations of centralized
controllers combined with network emulators in order to present a functional
representation of an SDN-based network. The second part is the selection of tools or
design of them in order to describe attack scenarios and evaluate their impact on the
network and the applications. Finally, the merger of the two previous parts is followed in
order to create a complete tool and evaluate the robustness and reliability of the network
during the design time.
The current lack of an existing simulation tool, which is able to evaluate the
performance of a SDN-network, the impact of cyber and/or physical security attacks
against the SDN architecture and finally, the effectiveness and reactiveness of security
monitoring and mitigation techniques makes the validation of a new SDN-based security
system process more complex.
1.2. Problem: SDN Security Risks
Taking into consideration the architecture of SDN and the OpenFlow protocol, it
is not difficult to recognize the vulnerabilities and the critical aspects of them with respect
to security. Apart from the traditional types of attacks such as the exploitation of
vulnerabilities of the forwarding devices or administration stations, attacks against the
3
network or compromised traffic flows in the data plane of the switches [12], SDN enables
new kinds of security attacks, which can aim either at the centralized controller, the virtual
infrastructure or the OpenFlow protocol itself [12], [13].
How secure OpenFlow is, is examined in [4] where the authors analyze the security
of the protocol under the STRIDE methodology [12]. The results show the vulnerabilities
of the protocol against Information Disclosure and Denial-of-Service (DoS) attacks. The
lack of TLS protocol usage between the centralized controller and the OpenFlow-enabled
switches enhances the sensitivity of the protocol under Information Disclosure attacks,
which help the attacker to discover, invisible otherwise, services on the network. On the
other hand, the communication link between the controller and the switches can be easily
saturated under a DoS attack leading to increased packet loss and overall network
congestion.
In DoS attacks and especially in DDoS attacks, where multiple compromised
clients are used to generate traffic, a large amount of packets are destined to a specific
host. As the name indicates, the purpose of the attack is to make the services of the host
unavailable. Usually, during such an attack the source IP address is spoofed and as a result,
each flow request is unique. When this attack is applied in SDN networks, the adversary
can easily exploit the fact that every new incoming unmatched packet is sent to the
controller. By flooding unique flow requests, the result is to saturate the communication
path between the controller and the switches as well as affect the limited buffering capacity
of the switches. The first option can be easily achieved in case where the switch sends to
the controller the whole new incoming unmatched packet, while the second option can be
accomplished when the switch buffers the packet and sends only the packet header to the
controller. An exclusive investigation about how the protocol behaves in the presence of a
DoS attack is conducted in [5] and specifically, it is presented how the bandwidth between
control and data plane as well as the switches’ memory can be exhausted due to the large
number of new incoming unmatched packets.
1.3. Problem Statement
The current degree project points out two main issues, which are related to the
simulation of security attacks against software defined networks as well as the design and
4
the implementation of a network security monitoring system, which addresses DoS
attacks.
1.3.1. Simulative approach of security attacks against SDN
Inspired by the motivational observation, there is not a present simulation
framework able to support the simulative approach of security attacks against SDNs. As it
was mentioned in the above section, currently the designers need to design and evaluate
the impact of the security attacks using extra software tools and thereafter integrate the
attack scenario in the network testing the monitoring system. This work will investigate
the provision of a single simulation framework able to support the simulation of security
attacks’ impact against a SDN-based network security monitoring system.
1.3.2. SDN-related security risks: Why DoS?
Among all the present security threats and vulnerabilities of the SDN architecture,
this thesis will study the effects of (D)DoS attacks, a severe threat against SDNs not only
because the architecture of the network itself is more sensitive to this type of attacks, but
also, the result of this threat can be twofold. While a specific host is targeted, at the same
time the path between the controller and the switches, a.k.a. saturation attack, or the
memory capacity of the devices are affected by the flooding of injected messages. What the
effects of the attack on the victim are as well as the factors, which determine the
performance of a network security monitoring system will constitute the main research
topic of this work.
1.4. Goal and Objectives
The aim of this work is to build a comprehensive simulation framework allowing
the evaluation of the impact of security attacks against a Software Defined Network
architecture and providing as well security monitoring and mitigation techniques. In
particular, the simulation tool must be able to:
Support the SDN architecture and the OpenFlow protocol
Reproduce the impact of security attacks
Support SDN-based monitoring systems to address (D)DoS attacks
In order to do so, an enhanced version of the INET framework [14] built on top of
OMNET++ discrete event simulator [15] will be presented. The attack simulator SEA++
5
[16], [17] will be used to reproduce the effect of attacks on the network. The SEA++ attack
simulator will be extended in order to support SDN architectures and the specifications of
the OpenFlow protocol. Appropriate OpenFlow communication messages will be included
as well as necessary functionalities will be implemented such as the detection and
mitigation modules.
We will rely on the developed tool in order to evaluate monitoring and mitigation
techniques in the presence of Denial of Service (DoS) attacks in terms of accuracy and
reactiveness as well as the resulting impact on the network infrastructure.
The purpose of the project is to prove the support of SDN architectures into the
attack simulator SEA++ in order to show the simulative approach of attacks against such
networks and secondly, the design of a simple security monitoring system based on
selected methods in order to demonstrate the quantitative evaluation of a system’s
performance under attacks.
1.5. Methodology
For the purposes of this work both quantitative and qualitative research methods
will be applied based on [18]. This work is about an experimental effort to build a
comprehensive simulation framework able to support a number of monitoring and
mitigation techniques and evaluate them under different attack scenarios.
First of all, our implementation will be based on the two already existing works
[17], [19] combining and extending them in order to achieve our specific goals. As soon as
the integration of the OpenFlow and SDN support in SEA++ simulator will be completed,
a qualitative research method will be applied afterwards. A literature study will be
conducted in order to review existing works and select the most appropriate monitoring,
detection and mitigation techniques that will be included in the tool and constitute the use
case monitoring system which will be tested. The final decision and selection among the
current works will be based on the comparison of the works regarding their performance,
complexity and efficiency as well as the needs of this work.
After the implementation and integration of the selected methods in the tool, an
evaluation of them will be performed. For this purpose, the quantitative research method
6
will be adopted and an experimental approach will be conducted. As there is no hypothesis
to be confirmed or falsified an iterative process will be followed in order to assess and
study the selected monitoring options in terms of efficiency, effectiveness and reactiveness
under different tuned attack scenarios. DoS attack scenarios will be designed and the
performance of the designed system will be evaluated under specific configuration
parameters. The results will be analyzed based on the specific attack scenarios constituting
the proof of concept without indicating the generalization of them under all the kind of
attacks.
The sequence of the steps which will be followed during this work is presented in
the below diagram.
Figure 2: Methodology flowchart.
Add SDN and OF support in
SEA++
•Extend SEA++ to support SDN architectures and OF.
Literature study
•Study current works
Selection of methods and techniques
•Select methods to be implemented to constitute the use case monitoring system
Design a use case SDN-based
monitoring system•Implementation of the selected methods
Design the attack
scenario
•Design tuned DoS attacks in different attack rates
Evaluate the implemented
system
•Evaluate the performance of the designed system in terms of effectiveness and reactiveness
7
1.6. Outline
The rest of the work is organized as follow: Chapter 2 presents in a more detailed
way the background about the SDN architecture. Chapter 3 describes existing works which
are related to SDN-based monitoring systems. Methods and techniques are presented
regarding the collection of the statistics, the attack detection and finally, the attack
mitigation. In chapter 4, the implemented monitoring system is described. How the
selected methods are adopted and implemented is shown in this chapter. The description
of the attack simulator SEA++ is illustrated in chapter 5. The experimental results are
shown in chapter 6. Finally, chapter 7 concludes the work discussing the benefits, the
limitations, the economic, environmental, social and ethical aspects of the current work.
Future extensions and improvements are also included in the chapter.
8
2. Background
In this chapter, a brief description of the transition to the new era of Software
Defined Networks will be presented as well as a more detailed illustration of the new
network architecture. What it is, how it works and how we can simulate such architectures
will be discussed.
2.1. Towards... Software Defined Networks (SDN)
Researches show that traditional networks have presented limitations and
restrictions regarding their flexibility to be managed [20]–[22]. Especially, in large
enterprise networks where the devices vary from switches and routers to middleboxes,
such as firewalls, load balancers and intrusion detection systems and the configuration of
each one is based on the vendor-closed specifications. For example, in an ISP Tier-1, the
configuration files of the devices can reach thousands of lines of commands describing
complex policies and routing decisions. Administrations should follow vendor-dependent
configurations based on the equipment and that imposes more difficulties and challenges
in infrastructure maintenance. It is mandatory for them to be specialists with the
specifications of each vendor in order to configure and troubleshoot the device. The
process of manual configuration has been proved in [20] that is time consuming, complex
and also, sensitive to human errors.
In order to illustrate all the boundaries, the costs and the complexity of traditional
network services in an enterprise network, a survey is conducted in [23]. The results show
that the most common cause of failures is based on human errors due to
misconfigurations. The complexity of the devices contribute to the increased errors,
because heterogeneous platforms require management expertise. The strict vertical
integration between the control and data plane of the traditional device’s architecture
involves the transformation of high level policies to low-level configuration commands,
hence the innovation of new protocols or more complex routing decisions are difficult to
be implemented. The answer to the question how network infrastructure can be more
manageable give the authors in Ethane project [2], where they present the concept of
programmable networks using a centralized controller. Ethane constituted the base of
9
Software Defined Networks revolution and led to be the ancestor of the dominant
OpenFlow protocol [1].
2.2. Software Defined Networks (SDN)
Software Defined Networks (SDNs) have become the new paradigm in network
design and constitute the result of extensive research regarding the simplification of
network management [2], [3], [24]. By decoupling the control and data plane, the
underlying switches or routers become simple forwarding devices while the control logic
is implemented in a software programmable centralized controller. The controller is
responsible to decide how the traffic will be handled and notifies the switches by installing
forwarding rules. Thus, a single program is able to control multiple data-plane devices
located within controller’s scope. Figures 3 and 4 illustrate the comparison between the
strict vertical structure of control and data plane on traditional switches with the new
architecture defined by SDN paradigm. Having the view of the whole network topology
and the ability to control the network from a centralized point, SDN makes network
monitoring more accurate and network management more efficient [13], [25]. SDN
empowers the researchers to design more flexible and innovative protocols avoiding
Figure 3: Traditional network switches which indicate the vertical dependency between the control and data plane.
Figure 4: SDN topology where the centralized controller interacts with the switches. The switches act as simple forwarding devices.
10
vendor-depended configurations [26], since they do not have to configure each device
individually but they take traffic forwarding decisions form a centralized point instead and
by referring to a single common API (i.e. OpenFlow protocol).
Many implementations of centralized controllers have been developed. Indicative
examples are POX [27] and RYU [28] whose implementation is based on Python,
OpenDayLight [29] and Floodlight [30], which are implemented in Java and finally, NOX
the first implemented controller [31]. Scalability issues between the controller and the
switches can be solved by using multiple, distributed controllers, such as ONIX [32],
ONOS [33] and PANE [24]. Even if there were doubts about the performance and the
scalability of the new architecture [34], [1] proved that SDN is able to form future
networks. By identifying the benefits of the new proposed architecture, industry has also
started integrating SDN in their enterprise networks such as Google with B4 project [35]
and Andromeda [36]. The open source OpenDayLight project and the Open Networking
Foundation [37] have motivated many companies to support and include SDN principle
in their networks [38], [39].
2.3. OpenFlow Protocol
OpenFlow protocol [40] is the first standard implementing the SDN concept both
in software and hardware [37] and is the preponderant implementation of southbound
interface between the forwarding devices and the centralized controller as indicating in
Figure 5. Providing a well-defined Application Programming Interface (API) enables
researchers to implement new ideas, run experiments and design networks composed of
heterogeneous devices, while being unaware of vendor-dependencies.
Figure 5: OpenFlow API. The dominant southbound interface between the controller and the forwarding devices.
11
The OpenFlow protocol is flow-based oriented. Each OpenFlow switch contains
one or more flow tables of multiple flow entries. Each flow entry contains multiple fields
such as the match and instruction fields, the lifetime duration and the priority of the rule
and counters about the matched packets. When a forwarding device receives a new packet,
it looks for an appropriate flow entry in the flow table, which matches to the flow the packet
belongs in. The comparison between the incoming packet and the match fields of the flow
entry is basically based on the ingress port and packet headers. If there is such a rule, then
the switch will forward the packet according to the instructions defined within the
instructions field of the rule. In case, there is no flow entry defining how to forward the
packet, the switch sends the packet to the controller using an OpenFlow message asking
for forwarding instructions. The controller is responsible to take the correct decisions
about the handling of such packets and informs the switch by installing a new flow entry
in the flow table. The switch is now aware of the way to process future incoming packets,
which match the recently installed rule. The rule is removed either by a forced decision by
the controller or due to expiration of the timeout interval.
2.4. SDN and Simulative Approaches
Considering the benefits of the network simulators as well as the new era of SDN,
it is seem that limited works have been conducted regarding the integration of OpenFlow
protocol in simulation tools. An effort is being under development in order for the
OpenFlow protocol to be included in ns-3 simulator [41]. Yet, only a very early version of
OpenFlow is supported, v.0.89, which is quite old since the current version of the protocol
is v. 1.5.1 [42]. EstiNet [43], [44] is a network simulator and emulator supporting multiple
versions of OpenFlow protocol compatible with a collection of multiple controllers, such
as POX [27], Ryu [28] and OpenDayLight [29]. It provides the possibility to simulate SDN
architectures by choosing the desired controller without any modification on it. According
to the official reference of the project, it is considered “the most accurate, fast, scalable,
and useful OpenFlow network simulator and emulator in the world” [43]. However, it is
not an open source project but a commercial one.
One interesting proposal has been presented in [45], where the authors integrate
the OpenFlow protocol v. 1.0 [46] in INET v.2.0. framework [14], [47] of OMNET++, the
discrete event simulator [15]. The authors consider OpenFlow switches, OpenFlow
12
controllers and the most important OpenFlow messages, which are exchanged between
the controller and the switches in order to extend the already existing and well-known
simulator with the support for OpenFlow features. As a result, the integration of the
protocol in the framework has been implemented offering now the possibility to simulate
OpenFlow-enabled devices and represent SDN architectures by means of a single
simulation tool. Yet, none of the above works provides the possibility to perform and
evaluate attacks against the network.
SEA++, Simulative Evaluation of Attacks, [16] allows the reproduction of the
effects of both physical and logical attacks on the network by describing attacks through a
high level description language without altering the actual simulation platform. It is a
complete tool for simulative evaluation of attacks’ impact related to two previous works
[48], [49]. SEA++ is based on the discrete event INET v.2.6 framework built on top of the
OMNET++ and according to the authors is a flexible and easy to use tool. The interesting
part of the tool is that it reproduces the effect of successful attacks allowing a quantitative
evaluation of their impact, while it does not consider the actual way attacks are mounted.
This makes it possible to model the effects of successful attacks without concerning about
their actual implementation and hence focusing on the evaluation of their impact. SEA++
has been tested in traditional and wireless sensor networks but not in SDN.
2.4.1. OMNeT++ & INET
INET framework is an open source library, which provides support for the
simulation of communication networks. The representation of the OSI stack is given
including Internet transport and routing protocols such as TCP, UDP, OSPF and MPLS.
The framework is available to the users to extend and design new protocols and network
scenarios. INET simulation framework is based on OMNeT++ discrete event simulator.
OMNeT++ is a C++-based library able to support the addition of network simulators on
top of it. The modeling of the library is based on components and the communication
among them is based on messages. More information about the frameworks can be found
at https://inet.omnetpp.org/ and https://omnetpp.org/ respectively.
13
3. SDN-based (DDoS) Security Monitoring
In order to prevent an attack against the network, an effective security monitoring
system should be built. The system is responsible to collect traffic information, analyze it
and possibly identify the threats against the network. In case, a threat has been recognized,
the system should try to mitigate the attack. The required components for successful
network monitoring system can be categorized as: (1) Collection of the statistics, (2)
Analysis of the collected data and detection of attacks and (3) Mitigation techniques to
neutralize the ongoing attacks. In the following sections, different techniques and methods
considered for the above components will be presented.
3.1. Statistics Collection
In order to identify an anomaly within the network, a continuous monitoring is
needed. Two prominent approaches can be adopted regarding the monitoring over SDN:
(a) (b)
Figure 7: Active and Passive OpenFlow-based Monitoring. (a) Passive Monitoring: When the flow expires, the switch sends the collected data to the controller. (b) Active Monitoring: the controller periodically requests the current values of the counters.
Figure 6: The three components which constitute the network monitoring system
(a) (b)
14
(i) flow-based and (ii) packet sampling-based approach. Taking advantage of the features
of the OpenFlow protocol itself, flow-based monitoring approaches can be implemented
either in a passive or an active way, as Figure 7 presents. During passive monitoring, when
a flow entry is expired in the flow table of the OpenFlow switch, the counters regarding
the collected statistics of the specific flow are sent to the controller. On the other hand,
during active monitoring, the controller periodically requests the current values of the
counters of all flows and each switch replies with the corresponding message.
Both approaches present strengths and weaknesses [50]. In the latter, the
increased overhead between the data and control plane path is obvious as the controller
periodically requests the statistics and the switches reply to that. If the system is under
attack, and especially a DDoS attack, the new incoming unmatched packets are excessive
in number and all of them should be sent to the controller in order for the switch to receive
instructions of how it will forward the packets. Adding these amount of messages in the
data-to-control plane path and including the periodic statistics request, the controller will
be finally collapsed and part of the system will be frozen under the hands of the adversary.
However, this way of statistics collection can be very accurate since there is timely
overview of the network’s status. Depending on the collection frequency and a fine-grained
monitoring an early detection of an attack can be achieved.
As it was mentioned above, the passive monitoring reduces the overhead in the
control-data plane path because the number of required messages is smaller. Yet, it leads
to a delayed detection of the attack, because the switch informs the controller only when a
flow entry is expired. Depending on the defined lifetime of a flow entry, the controller can
be informed about the counters’ values sooner or later. A tradeoff between the overhead
in the data-to-control plane path and the monitoring accuracy exists. When a rule has a
short lifetime duration, as soon as it is expired the controller collects the information for
the statistics too. However, on the next incoming packet related to that flow, the switch
requests again forwarding instructions, because the previous rule has been removed. As a
result, messages between the controller and the switches are added. On the other hand,
setting longer timeout intervals requires less communication between the switches and
the controller, but the controller collects the statistics later. Consequently, setting
parameters in the order to properly achieve both accurate monitoring and good system
performance is very challenging.
15
An alternative to the above methods is the approach based on packet sampling.
sFlow [51] was introduced in order to achieve an accurate monitoring on traditional
networks by retrieving statistical packet-based samples of the switch’s flows according to
different rates. When a packet arrives on the switch, filtering policies on the switch itself
determine whether the packet should be sampled or not. The decision is based on a rule
defining the sampling rate. If the packet should constitute a sample, then either the whole
packet or part of it is sent to the next module for analysis. The collected samples are sent
for analysis thereafter in order for anomalies in the network to be detected. In case of SDN-
based networks, switches send the collected packets to the controller and the latter is
responsible for the threat detection and mitigation. sFlow seems to be applicable as well
as efficient on SDNs as results show in [11].
All the current approaches regarding the statistics collections over SDN are listed
in [52]. The authors classify the approaching methods into three categories, each of them
point out to the problem from a different angle. The first approach is related to the
required balance between the monitoring accuracy and the added overhead. In this
category, improved versions of traditional OpenFlow approaches are presented. Inspired
by the OpenFlow baseline approaches, Payless [53] is an active monitoring approach,
which regularly requests for flow statistics. The adaptive polling interval to get statistics
makes it possible to trade accuracy with overhead. On the other hand, FlowSense [54]
exploits the passive monitoring way. The approach collects statistics not only when a flow
is removed from the flow table, but also when a new packet is sent to the controller for
handling instructions. FlowSense achieves low overhead and high accuracy using the
passive monitoring way. An adaptive way of flow monitoring is illustrated in [6], where a
prediction-based algorithm is used in order to dynamically change the granularity of
network flow measurement. The limitation of the work, is the delayed threat detection,
since the basic algorithm is based on comparison with historical data, but the accuracy of
the results is notable. The second challenge is between the usage of resources and the
measurement accuracy and DREAM [55] is a promising proposal for dynamical resource
allocation providing highly accurate results. However, a deeper analysis about this
category is out of the scope of this project. Last but not least, the tradeoff between the real-
time measurements and the accuracy is the third challenge during monitoring. In this
category, sample-based approaches have been proposed, with OpenSample [56] to give
adequate results with low latency and high accuracy. OpenSample platform is based on
16
the sFlow and uses TCP sequence numbers in order to provide an accurate passive
monitoring.
Attack Detection
An early work about how DDoS attacks can be detected over SDNs is also
illustrated in [9]. The authors use active monitoring in order to periodically collect
statistics and consider the Self Organizing Maps (SOM) [57] method to analyze the results
and successfully detect the threat. However, SOM-based approaches require training time
for collecting statistics and display better results as time passes and the total number of
collected packets increases, so improving the gathered statistics.
Four prominent methods have been proposed for data analysis [10], [13] and each
one can be used depending on the addressed threat. Threshold Random Walk with Credit
Based Rate Limiting (TRW-CB) [58] is a suitable algorithm for scanning worms detection
by observing the rate of a successful TCP connection. One more host-based anomaly
detector is Rate-Limiting algorithm [59], which detects virus propagation by observing
whether an affected host attempts to connect to many machines in a short period of time.
NETAD algorithm [60] is able to block suspicious traffic based on the packet header by
computing packet scores in order to identify the anomalous packets. In order to take a
decision based on traffic statistical features, the Maximum Entropy Detector [61] can be
used leading to classification of the packets into categories and distinction of the categories
as benign or malicious by using traffic distribution statistical methods. The main
drawbacks of this method are the required training time as well as the examination of
every packet, which are inefficient approaches for SDN-based networks.
However, entropy-based approaches seem to be ideal for DDoS detection [62].
Studies like [11], [62]–[64] use entropy-based approaches in order to identify DDoS
attacks both in traditional networks and SDNs. Entropy measures the randomness of
events happening. Entropy is applicable in computer networks as the method is able to
provide traffic distribution features that can be translated in valuable information
identifying traffic anomalies within the network. Based on the entropy value, the result of
the method can show if the total traffic is equally distributed within the network or
presents anomalies and lower randomness. Considering as an example the case of a DDoS
attack, the result of the entropy-based analysis can reveal information about the
17
destination IP address, the destination port, the source IP address or the source port. The
final result depends on the analysis angle and the investigated data set independently of
the traffic type (TCP, UDP or ICMP attack). During a DDoS attack, excessive amount of
traffic is destined to a specific host. Analyzing the data the randomness of the destination
of the total traffic decreases and as a result, the entropy value is low enough able to
generate a security suspicious warning. The authors in [62] applied the method in a SDN
in a light and effective way in order to early and successfully identify the attack targeting
a specific host.
Mitigation
As soon as the analysis of the collected data has been performed and the
characteristics of the anomaly have been identified, mitigation actions should be taken
into consideration in order to allow only the legitimate traffic to flow towards the intended
destination. Apart from the protection of the aimed host, it is also necessary to protect the
network and the system itself. It is up to the controller to take the right decisions regarding
the proper countermeasures. A list of countermeasures, depending on the corresponding
attack, is presented in [12]. The authors identify the most common mitigation techniques,
which are applicable in OpenFlow and SDN architectures in the presence of a DDoS attack.
Flow aggregation, packet dropping, rate limit and shorter timeouts are the most suitable
techniques applicable on controllers and forwarding devices in order to protect the system
while it is threatened. They are also recommended in the OpenFlow v.1.5 specifications
[42].
Packet dropping can protect both the data plane as well as the targeted host. When
the destination or the source IP address has been identified, then the controller can
prevent the flow of any suspicious traffic within the network by installing specific rules in
the forwarding devices to drop the matched packets. Rate limit can be combined with the
packet dropping technique directly on the switches in order to confine the number of
packets sent to the controller. For example, if the number of received packets per flow in
the forwarding device exceeds the defined threshold, then the next incoming packets are
dropped. Moreover, rather than installing fine-grained rules on the switches, flow
aggregation techniques exploit the use of wildcards and matches multiple flows to a simple
aggregative rule. The abstraction of the rule helps to prevent attacks on a specific target.
18
Finally, shorter timeouts can contribute to a faster identification of the attack while the
attacker should send forged packets at a high rate in order to update the life time duration
of the rule and avoid the expiration of it.
The implementation of middlebox functionalities provided by the devices is
illustrated in [50]. In this case, the switches behave like stateful or stateless firewalls
adding further protection to the network. A stateless firewall filters the packets based on
the current values in the headers and decides if the packet will be dropped or accepted.
The controller can install decision rules in order to implement this behavior. The
installation of the rules can be performed in two ways, the reactive or the proactive one.
During the proactive installation, the controller installs the rules in advance, namely
before the switch asks for further instructions. The main advantage of this approach is the
low additional delay between the switch and the controller. However, it may lead to larger
flow tables filled with unnecessary low entries. On the other hand, by considering the
reactive approach the switch sends the first packet to the controller asking for instructions.
The controller installs the appropriate rule representing the firewall behavior. Although
this way of communication leads to small flow tables, it adds additional delay because the
controller has to translate the firewall policies into forwarding rules.
A stateful firewall keeps tracking the status of a connection and the decisions are
not based only on the current packet header but on the history and the current status of
the connection. The decision rules should be installed on the switch using different
priorities in order to represent the correct functionality. Since this results in a more
complex implementation, in order to lighten the workload of the controller, specific
dedicated applications acting as middleboxes are adopted. Thereafter, the controller acts
as an intermediate interface between the switches and the specified applications. The
applications are responsible for analyzing the incoming packets and identifying the
suspicious or legitimate ones. Two typical ways are described in [65] and can be used in
order to implement a stateful firewall, the interception and the mirroring mode. Both of
them are totally applicable in OpenFlow as the authors in [50] mention. In interception
mode, the controller forwards the packet to the dedicated application and after the
analysis, the application can modify the installed rule on the switch. After receiving the
notification from the middlebox, the switch forwards the packet to the destined host or
dropped it. During mirroring mode, the application modifies the installed rule and at the
same time forwards the packet to the destination. While the mirroring mode avoids the
19
extra delays added by interception mode, it may delay to identify and block the malicious
traffic. Depending on the type of application, the right selection between the two modes
should be done.
Many studies have been conducted investigating efficient ways of network
monitoring and attack detection over SDNs. A packet sampling approach for statistics
collection over SDN is presented in [11]. The authors compare the native OpenFlow
methods for statistics collection with the sFlow-based approach [51] in order to prove the
efficiency of packet sampling method in a complete detection and mitigation system. In
order to mitigate the threat the authors propose the installation of new higher prioritized
rules indicating that suspicious flows targeting the victim (e.g. specific IP/protocol/port)
will be dropped. Although, this action is easy to be implemented, its drawback is that
benign traffic can be also dropped. In order to bypass this limitation, the authors use
whitelists in order to recognize the spikes of legitimate traffic. Before a drop rule is
inserted into the switch, the mitigation module firstly checks the identified target pairs
against the white list. If the suspicious IP or port belongs to a legitimate anomalous
behavior, then the packets are forwarded to the destination, otherwise, they are dropped.
In [7], an OpenFlow extension is proposed in order to detect threats, such as DDoS
and network scanning by adding some intelligence in the data plane. Even if this approach
can be characterized as controversial to the SDN philosophy, AVANT-GUARD, is a
complete flexible framework, which is based on two basic mechanisms, the connection
migration and the actuating trigger in order to detect and mitigate the threat. The basic
limitation is the detection of only TCP-based flooding attacks and not others, such as UDP
or ICMP flooding attacks. A system, which is able to deal with all types of flooding attacks
is proposed in [8]. The authors consider proactive flow rule installation in order to avoid
saturation attacks and a packet mitigation method that caches new incoming unmatched
packets in order to protect and distinguish the legitimate traffic from the malicious one
when the network is under attack. The cached packets are forwarded to the controller as
soon as the alert of the attack is over in order for forwarding instructions to be given. Even
though there is a delay when a host receives the packets, it is guaranteed that legitimate
packets are not being dropped but forwarded to the destination in the end.
20
Selected Methods
After studying the literature and taking into consideration all the existing methods
and approaches regarding a complete security monitoring system, for the purposes of this
work the below techniques are selected to form the use-case system, which will be
evaluated. The collection of the statistics will be implemented based on the native
OpenFlow approach. Since it is the first implementation and integration of the SDN
support into SEA++ simulator, the native OpenFlow approach is pivotal and will provide
a more concrete and complete support of the protocol. Furthermore, the attack detection
module will be based on the entropy algorithm, as the literature has proved that the
algorithm is suitable for the identification of DDoS attacks, because it analyzes the traffic
distribution and is able to provide valuable results regarding both the target and the
compromised source host. Finally, the selected technique, which will be used as mitigation
action, is the packet dropping. The implementation of the DROP action has been
considered essential to be implemented, as it is one of the most basic OpenFlow
instructions given by the centralized controller to the switches. Further details and a step
by step presentation of the deployment of the chosen monitoring system will follow in the
next chapter.
21
4. A use-case SDN Security Monitoring System
In order to reach the specified goal, namely the provision of a complete simulation
framework able to support detection and mitigation techniques to protect SDN
architectures, this work will constitute an extension of the INET v.2.6 simulation
framework based on OMNeT++ v.4.2 discrete event network simulator. An initial model
is presented in [45] and it consists of the two basic SDN components, the SDN centralized
controller and the OpenFlow enabled switch supporting the basic OpenFlow messages for
the flow establishment and communication between the components as an extension of
the INET framework. This project will enhance the work in [45] with additional OpenFlow
messages in order to support a network monitoring system and enable the packet
processing based on flow matching rules of arbitrary complexity. Before we continue to
the presentation of the implemented extensions, a brief description of the work in [45] will
be presented in the next section, as it provides the basic SDN components as well as the
support of the OpenFlow protocol and constitutes the fundamental basis of this work. The
rest of the sections will present the selected methods regarding the collection of the
statistics, the attack detection method and the selected mitigation technique which have
been implemented in order to accomplish the goal of this thesis.
SDN support in INET framework
The authors in [40] presented an initial model of the SDN architecture in INET
framework of OMNeT++ discrete event simulator. Their model is based on the integration
of the OpenFlow enabled switch and the implementation of a basic SDN centralized
controller including also, the basic implementation of the OpenFlow protocol v.1.0. They
designed the initial components in that way as it is illustrated in the below figures. The
SDN controller consists of a complete TCP/IP stack and can be easily represented as a
generic host node. The controller application, ofa_controller, is responsible for the
communication between the switches using OpenFlow messages. This includes the flow
establishment, update and revocation. The controller behavior represents all the possible
operational applications that can be built on it. The controller can act for example as
22
traditional L2 switch, Hub or Router. The desired forwarding behavior of the controller is
defined in this module.
The main characteristic of the SDN architecture is the separation of the control and
data plane of a switch. The authors aiming to follow and represent the new philosophy,
they designed the OpenFlow switch as a combination of two independent modules. The
left part of the figure below represents the control plane and the right part illustrates the
Figure 8: Representation of the centralized controller in INET framework.
Figure 9: Representation of OpenFlow-enabled switch in INET framework.
23
data plane. As it can be seen, both modules share the flow table, which contains all the
flow match rules.
All the Ethernet frames are received by the MAC module of the data plane. The
messages are forwarded to the Flow Forwarding Application, OF_Processing module. The
module searches for a flow match in the flow table. If such flow exists then it forwards the
packet from the port indicated in the instruction list. If there is no related match rule, the
OF_processing module sends a signal to the flow processing application, OFA_swtich.
This application is responsible for the communication with the controller. When the
module receives signal for unmatched packet, it establishes a new TCP connection to the
controller and sends the packet to it through OpenFlow message, OFP_Packet_In. The
switch will receive from the controller through the communication channel the
OFP_Packet_Out and the OFP_Flow_Mod messages. When the OFP_Packet_Out is
received the OFA_switch module will inform the OF_processing module through the
signal mechanism to apply the specific output action. As soon as the switch received the
OFP_Flow_Mod message, it will update the flow table inserting the new flow.
When the controller receives an OFP_Packet_In message, it notifies the defined
in the configuration file behavior application. The controller application emits a signal to
the behavior application including the packet in order for the later to process it. The
controller behavior application has a complete awareness of the network topology and is
the module which takes the forwarding decisions. As soon as it declares the action list, it
notifies the basic controller application to send the OFP_Packet_Out and
OFP_Flow_Mod messages to the switches.
All the implemented OpenFlow messages are listed below:
OFP_Features_Request & OFP_Features_Reply: The messages are necessary for
the initialization of the OpenFlow Channel between the controller and the
switches. The first message is sent by the controller and the reply is sent by the
switch.
OFP_Packet_In: This message is sent by the switch to the controller in order to
inform the module for the presence of a new incoming packet. The switch forwards
the packet to the controller asking for forwarding instructions.
24
OFP_Packet_Out: The centralized controller replies to the above request with this
message. The controller informs the switch which port should be used to forward
the packet.
OFP_Flow_Mod: The controller sends the switch the specific message in order to
establish a new flow in the flow table, or to update an existing one. The message
contains all the match fields will be checked when a packet arrives at the switch as
well as the instruction set list indicating the forwarding actions.
The following sections describe the extensions of this work in order to build new
functionalities in the centralized controller and the switches aiming to build a complete
security network monitoring system.
New Controller Overview
The below Figure 10 illustrates the new additional modules which are the basic
components of a complete security network monitoring system. All the new modules are
integrated as applications in the centralized controller. The new composed module of the
controller is enhanced with two new modules, AttackDetection and Mitigation. The
AttackDetection module is able to support multiple analysis methods in order to detect an
Figure 10: New representation of the centralized controller in INET framework.
25
anomaly. In this work, the Entropy algorithm is the integrated method of the module. The
Mitigation module is called whenever the AttackDetection module identifies a new
anomaly within the network. It is responsible to prepare the new flow entry, which will be
established on the switches and will be regarded to the protection of the victim.
Furthermore, it has to be mentioned that the controller acts as forwarding switch
running the “FwdSwitch” application. The controller does not base the forwarding
decisions only in the MAC address fields but based on the type of the packet. Let’s take the
below example into consideration. When the controller receives a new IP packet, then the
fields of the new flow entry about the IP source address, IP destination address, IP
Protocol, MAC source address, MAC destination address and Ethernet packet type will be
matched. The below graph illustrates the fields which are matched based on the packet
type.
The below sections analytically describe the implemented methods regarding the
statistics collection, the attack detection and the attack mitigation module respectively.
Figure 11: Packet matching fields.
26
Statistics Collection
For the purposes of this project, the statics collection is achieved by using native
OpenFlow messages via the flow-based active monitoring. More specifically, the
“OFPT_STATS_REQUEST” and “OFPT_STATS_REPLY” OpenFlow messages have been
implemented. The controller application periodically requests from all the switches to
report statistics about the packet matches and the accesses to their flow tables occurred
during the specified time window. The time interval is defined in the configuration file by
the user. When the switch, namely the OFA_switch module, receives this message parses
the flow table and collects all the current flow entries and their counters. All the
information is included in the OFPT_STATS_REPLY OpenFlow message, which is sent
back to the controller. When the controller receives replies from all the switches presented
in the network sends the information to the attack detection module.
Moreover, the OFPT_FLOW_REMOVED message has been also implemented.
The switches send this message when a flow entry expires to notify the controller about
the event. The message includes all the statistical information regarding this flow entry
containing also the total number of matched packets during this specific time interval. For
the purposes of this work, the particular message is not used further, but it proves that a
different system, which uses the passive monitoring way, can be supported.
Attack Detection
As it was discussed earlier, the attack detection module is based on the entropy
algorithm. The specific method has been proved to be able to identify easily DDoS attacks
based on the entropy value as it mainly measures the randomness of the traffic distribution
in the network. Collecting statistics periodically and exploiting the features of the entropy
algorithm, the controller is able to recognize if there are anomalies of the traffic
distribution in the network. It is a fact that during DoS or DDoS attacks, excessive volume
of traffic is destined to the target host giving as a result a concentrate traffic distribution.
Using the entropy algorithm, it is easily to identify the anomaly as the value of the
measurement decreases indicating lower randomness of the traffic distribution and reveal
information about the victim and the compromised host.
27
The two main characteristic parameters of the entropy algorithm are the threshold
and the window size. If the entropy value is lower than a predefined threshold, then there
is an alert for abnormal traffic distribution. The window size indicates the size of the data
set, which will be analyzed for anomalies. The window size can be determined either based
on time or number of packets and it defines the period when the algorithm will be applied.
Since the collection of the statistics are based on the active OpenFlow active approach, the
window size is based on time and the entropy algorithm is performed every polling
interval.
In order to minimize the false positive alerts a second check is followed. The
entropy algorithm generates an alert when the entropy value is lower than the threshold.
The alarm indicates suspicious traffic volume within the network. Before the mitigation
module takes action, a second check is performed is order to confirm the existence of an
anomaly. As soon as the entropy analysis returns a positive alarm, the packet counters of
the suspicious sender and the suspicious victim are checked against predefined
thresholds. If the number of sent packets within the window exceeds the threshold as well
as the receiver accepts more packets than the threshold, then the anomaly between this
pair is identified and the mitigation module is called.
4.4.1. Entropy Algorithm
Let W be the set of n elements and x events during the window size. The
randomness of the events’ distribution is calculated through the entropy value H, which is
the logarithmic sum of the probability pi of each element in the set, as equations (2) and
(3) show.
W = {𝑥1,𝑥2, … , 𝑥𝑛} (1)
𝑝𝑖 = 𝑥𝑖
𝑛 (2)
H = - ∑ 𝑝𝑖 ∗ log 𝑝𝑖𝑛𝑖−1 (3)
When the entropy value H is lower than the predefined threshold t, then an attack alarm is
generated.
28
The main purpose of the designed use case monitoring system is to detect traffic
anomalies aiming to any destination host or server. To do so, the data set W consists of all
the destination IP addresses, which are presented in the flow tables of the switches and
their cumulative counters illustrating the total number of packets received by each
destination IP address during the window size (polling interval). The entropy value is
computed based on the available information afterwards. If the entropy value is lower than
the predefined threshold, the algorithm returns a positive alert.
The below flow chart represents the steps followed by the attack detection module.
The collected statistics are given as input in the attack detection module. The module
collects all the information regarding all the present in the flow tables of the switches IP
destination addresses and their cumulative packet counters. The entropy algorithm will
be applied on this set in order to identify a possible anomaly within the network and
specifically, any victim among the given destinations. If the entropy returns a positive
alert, then the attack detection module will confirm the anomaly by checking the number
of the total received packets that the suspicious victim received. If the number exceeds the
predefined threshold then, the algorithm continues by looking for the suspicious
adversary. If there is any host sending more packets than the predefined threshold, then
the mitigation between this pair will be enabled.
29
Figure 12: Attack Detection Algorithm
30
Mitigation
As soon as the attack has been identified, the mitigation module is called. The
purpose of the module is to add protection in the network and especially to the victim by
dropping all the packets coming from the adversary. The module is responsible to prepare
the match fields of the new flow entry and emit the “Mitigation” signal to the main
controller application to notify about the new mitigation rule which will be installed. The
OFA_Controller module receives the signal and prepares the OFPT_FLOW_MOD
OpenFlow message including the action DROP according to the OpenFlow specifications.
The action field of this rule is empty representing the action DROP. Furthermore, the
network protocol is wildcarded as the mitigation module is interested only in IP traffic in
general regardless the transport protocol. Of course, this shows the flexibility of the
specific framework as each designer can implement any mitigation methods based on the
necessary specifications. The rule is installed with higher priority in the flow table in order
to verify that the traffic coming from the adversary will be matched with the mitigation
rule and will be dropped. If the new flow rule had the same priority as the rest flows, then
due to the wildcarded field none of the packets would match with it and the victim would
be exposed in the attack. As a result, the mitigation method would not be valid. The
controller forwards the new message to the switches in order for them to install the new
flow entry in their flow tables and the mitigation action has started.
Before, we continue to the presentation of the experimental results, the next
chapter will describe the attack simulator, SEA++ and how can be used in order to describe
physical or cyber-attacks.
31
5. Simulative Evaluation of Attacks, SEA++
The attack simulator SEA++ [16], [17] supports the simulative evaluation of the
impact of physical and/or cyber-attacks. It is easy to reproduce the attacks’ effects and
quantitatively evaluate their impact overlooking the actual way of how the attack is
mounted, but noticing their quantitative effect. Using a high level description language the
simulation of the attacks and their impact is performed without any modification to the
simulation platform. As a result, the prioritization of the attacks according to their severity
is possible and the selection of appropriate countermeasures is easier. SEA++ is based on
INET v.2.6 framework built on top of OMNeT++ network simulator and consists of 3 basic
components:
1. Attack Specification Language (ASL)
2. Attack Specification Interpreter (ASI)
3. Attack Simulator
Using the high level Attack Specification Language, ASL the users describe the
attacks to be evaluated considering their final effects and they are presented as a sequence
of events during the network simulation. The ASL supports two categories of primitives
that describe physical and cyber-attacks respectively. The node primitives account
physical attacks against a node such as the destruction or the misplacement of it. The
message primitives are used for the representation of cyber-attacks including actions as
eavesdropping, altering, injection and dropping. Conditional or unconditional statements
are supported in the language and the events are periodically repeated. An example of the
ASL is provided below. In this example, the adversary starts creating application messages
at simulation time 25 periodically generated every 0.01 sec. The packets will “magically”
appear in the transmission buffer of nodes in the “dstList”. This is performed by the Global
Event Processor-GEP which communicates with the Local Event Processor- LEP of each
node as Figure 13 shows. Before the simulation of the described attack, the script should
be converted to XML configuration file in order to be given as input to the network
simulator. The conversion is performed by the Attack Specification Interpreter, ASI.
32
The heart of SEA++ is the Attack Simulator engine which is responsible for the
creation and representation of the described attacks within the network. The Attack
Simulator is based on the basic modules of INET framework enhanced them with one
component, the Local Event Processor – LEP or Local Filter. LEP intercepts incoming
and outgoing network packets traveling through a node’s communication stack, between
each pair of layers. LEP is able to alter packets’ content, inject new packets or even drop
Figure 13: Simple example of an attack description using the ASL of SEA++ attack simulator.
Figure 14: The core representation of the attack simulator SEA++. The nodes have been enhanced with the LEP module, which intercepts all the packets traveling through the stack. GEP module allows the communication between the nodes supporting more complex attacks.
33
packets as well as change the physical position of the node. In order to represent tuned
synchronized attacks, each LEP module is connected to the global external module, the
Global Event Processor-GEP or Global Filter allowing the communication between the
nodes supporting more complex security attacks. Figure 14 illustrates the overall
architecture of the Attack Simulator.
34
6. Evaluation
The evaluation of the implemented work is performed in OMNET++ v.4.2 discrete
event network simulator and INET v.2.6 simulation framework. All the experiments run
in a HP laptop, with Ubuntu 12.04 OS, quad-core processor Intel i5-2410M @2.30GHz
CPU and 8.00 GB RAM. The duration of all the experiments is 250 seconds. The
monitoring metrics during the evaluation is the variation of the entropy value under
different attack rates and polling intervals of statistics collection, as well as the total
number of received packets on victim’s side. By measuring these values, the effectiveness,
reactiveness and efficiency of the designed system will be shown.
6.1. Topology and Traffic Scenario
The selected topology is simple and based on 4 hosts and 3 servers, all of them run
UDP traffic. The centralized controller and the OpenFlow-enabled switch are the new
enhanced INET modules. The centralized controller runs as forwarding switch. It
performs the MAC-learning function representing a typical Layer2 switch, but it is also
able to install flows based on the packet type as shown in section 4.2. The switch runs
under promiscuous mode receiving all the packets. The hard time of flow expiration is set
to 30seconds, which means that every 30 seconds all the flow entries of the flow table are
deleted.
Figure 15 illustrates the network setup. As the figure shows, there is one network
subnet, 192.168.2.0/24. According to the scenario client 2 and client 3 send packets to
UDP server 2, while client 1 sends packets to server 1 and client 4 communicates with
server 3. All the clients periodically generate UDP traffic and the traffic volume remains
stable at 23 packets per second in total. More specifically, client 1 generates 10 packets per
second, client 2 and client 4 generate 5 packets per second and client 3, which will
represent later a compromised host, sends 3.33 packets per second. The selected values
were randomly selected. After the simulation’s completion, 4196 packets are presented in
the network out of which 1799 packets received by server 1, 1498 packets received by server
2 and 899 packets are received by server 3.
35
The DoS attack starts at simulation time 90s. The attack is performed by client 3.
The compromised host injects malicious packets in three different attack rates by using
SEA++ attack simulator. 14, 25 and 40 malicious packets are injected every second. By the
end of simulation run 3500, 6250 and 10000 more illegal packets are injected in total in
the network. The controller requests statistical information from the switch every 15s, 30s,
45s and 60s. As soon as the attack is detected, the mitigation action is enabled. All the
traffic, both legitimate and malicious one, coming from the compromised host will be
dropped. In the results below, the overall performance of the system regarding the entropy
value and the total number of received packets on victim’s side will be described.
6.2. Defining Entropy Threshold
Before we evaluate the performance of the designed use-case monitoring system,
the entropy threshold should be defined. In order to do so, the mean value of the entropy
metric is observed under both legitimate and malicious traffic. The first step is to evaluate
the mean value of the metric when legitimate traffic only runs within the network. After
monitoring the entropy having different polling intervals, such as 15s, 30s, 45s and 60s,
the mean value is -9.65. The next step is the injection of malicious traffic using the SEA++
Attack Description Language. The attack rate is low, as 14 more packets are only injected
Figure 15: Topology overview. The topology consists of 1 OF switch and 1 centralized controller. The 4 clients communicate with the 3 servers. Client 3 is the compromised host and server 2 is the target-victim of the scenario.
36
per second. This corresponds to 30% adding more incoming malicious traffic to the total
normal traffic. Monitoring the entropy value under this attack rate and collecting statistics
every 15s, 30s, 45s and 60s, the mean value of the entropy measurement is set to -12.50.
After running a series of experiments, the mean value -12.50 is proved to be suitable for
the scenario, as the entropy threshold and the monitoring system will identify attacks
greater than this limit.
As it was mentioned above, the detection system is not only based on the entropy
value. The entropy analysis returns an alert when the recently computed entropy value is
lower than the predefined threshold. In order to attest the presence of the attack, there are
also packet thresholds, which need to be checked in order to prove the anomaly in the
network. When the suspicious host sends more packets than the allowed number of sent
packets and the suspicious victim-server receives more packets exceeding the received
packet threshold during the monitoring window, then the attack is confirmed and
identified between the pair <suspicious host, suspicious victim>. During this evaluation
and for the purposes of the work, the sent and received packet threshold is the maximum
number of legitimate sent and received packets per second respectively.
It has to be stated, that all the threshold values can be modified and changed based
on the network setup, the traffic volume and the designer’s needs. After all, this is one of
the benefits of simulative experimental setups.
6.3. Experimental Overview
At this point, an overview of all the network variables will be presented in order to
summarize the evaluation setup. As the entropy and the packet threshold have been
defined, different polling intervals should be defined regarding the collection of the
statistics. Therefore, 4 different polling intervals are selected showing the variation of the
monitoring units during multiple variables. The selected intervals are 15s, 30s, 45s, and
60s. The attacks are performed under 3 different rates illustrating low, medium and high
volume attacks against the victim. 14, 25 and 40 malicious packets are injected every
second. All the variables below are defined in the configuration file and can be changed
based on the needs of the designed system. The table below presents and summarizes all
the currently selected values of configuration parameters.
37
Simulation Time 250s
Flow Expiration 30s
Entropy threshold -12.50
Maximum allowed sent packets (per sec) 8
Maximum allowed received packets (per sec) 10
Statistics Collection 15s
30s
45s
60s
Attack Rate (injected packets per sec) 14
25
40
Table 1: Selected configuration parameters during the experiments.
6.4. Total number of Received Packets per second
In this section, we will analyze the total number of received packets per second on
the victim’s side illustrating the effects of the attack. The effectiveness and the reactiveness
of the system will be discussed under different cases. The system’s reactiveness is based
on the timely collection of the statistics. It will be presented that stricter network
monitoring provides more accurate network view. On the other hand, looser time intervals
may fail to identify some anomalies. The overall performance will be observed in two
different ways. Firstly, the network is monitored during fixed polling intervals under
multiple attack rates and a system’s analysis is followed describing how the system reacts
when it is triggered to analyze data in loose and strict time windows. Secondly, we present
38
and compare the system’s performance when the attack rate is fixed but a closer look is
given on the difference of multiple time intervals.
6.4.1. Fixed Statistic Collection Intervals
Keeping the querying intervals in a fixed value the below graphs show the effect of
attacks launching under different attack rates against the victim. Information regarding
the monitored traffic is gathered every 15s, 30s, 45s and 60s. It can be easily observed that
based on the frequency of statistics collection, the attack is identified at a different time
interval. The bigger the statistic collection’s window the later the mitigation is enabled.
Thus, the reactiveness of the detection system is based on the timely collection of the
statistics.
As it is seen in the first two graphs, Figure 16 and Figure 17, when the detection
module processes the gathered information every 15sec or 30sec, the attack is identified
in simulation time 115sec or 120sec respectively. The number of the total received packets
is based on the attack’s volume. When the attack is detected, the mitigation is enabled. As
was described earlier, the selected mitigation technique drops all the packets coming from
the compromised host including both malicious and normal traffic. When the
compromised host is absolutely isolated, the victim keeps receiving packets from the
second non-compromised host. Thus, the total number of received packets when the
mitigation is enabled, is lower than the initial number.
0 50 100 150 200 250
0
10
20
30
40
50
60
time (sec)
rcvd
pkt
s/se
c
Total Number of Received Packets per secondPolling Interval 15s
Attack Rate 14 pkts/sec
Attack Rate 25 pkts/sec
Attack Rate 40 pkts/sec
Figure 16: Total number of received packets by the victim with polling interval 30sec and different attack rates.
39
Increasing the collection window to 45sec the overall result is the same. The total
number of received packets increases based on the attack rate. The reactiveness of the
detection module changes though as Figure 18 shows. Depending on the collected statistic
information the detection module maybe fail to identify the attack on time, especially
when the attack has low volume. The detection of the threat can be harder when the
collection is performed after the flow expiration. This case can be easily observed in the
Figure 18, where the statistics are collected every 45s, but the flow expiration is performed
every 30sec. The module firstly fails to identify the attack as the reported statistics regard
0 50 100 150 200 250
0
10
20
30
40
50
60
time (sec)
rcvd
pkt
s/se
c
Total Number of Received Packets per secondPolling Interval 45s
Attack Rate 14 pkts/sec
Attack Rate 25 pkts/sec
Attack Rate 40 pkts/sec
0 50 100 150 200 250
0
10
20
30
40
50
60
time (sec)
rcvd
pkt
s/se
c
Total Number of Received Packets per secondPolling Interval 30s
Attack Rate 14 pkts/sec
Attack Rate 25 pkts/sec
Attack Rate 40 pkts/sec
Figure 18: Total number of received packets per second by the victim with polling interval 45sec and different attack rates.
Figure 17: Total number of received packets by the victim with polling interval 15s and different attack rates
40
information for the last 15sec. This information is not enough for a successful attack
detection. The entropy value is lower than the threshold but the attack rate is not so strong
to exceed the packet counter thresholds during this time. Monitoring the network over one
more period, the module successfully detects the anomaly in the network and enables the
mitigation.
Increasing further the statistics collection window, the module performs also well.
However, this is the case when the detection module is unable to identify the low-rate
attack as the packet counter thresholds are never exceeded in order to prove the existence
of the attack.
6.4.2. Fixed Attack Rate
In this section, the overall number of received packets by the victim is presented
once again. The attack rate is stable comparing the system’s behavior when the collection
of the statistics is performed on different time intervals. As we discussed in the section
above, when the attack has low volume (14 new injected packets per second), stricter
polling intervals help to detect it. The vertical lines present the system’s reactiveness in
attack’s detection. Statistics collection every 60 seconds fail to identify the small attack, as
was presented in the previous graph.
0 50 100 150 200 250
0
10
20
30
40
50
60
time (sec)
rcvd
pkt
s/se
c
Total Number of Received Packets per secondPolling Interval 60s
Attack Rate 14 pkts/sec
Attack Rate 25 pkts/sec
Attack Rate 40 pkts/sec
Figure 19: Total number of received packets per second by the victim with polling interval 60sec and different attack rates.
41
Increasing the attack volume to 25 new injected packets per sec, the system
successfully detects the anomaly. In the case of 45s, the attack will be identified on the
next analysis, as the final decision regarding the presence of an anomaly within the
network is affected by the flow expiration.
Figure 21: Total number of received packets per second by the victim under attack rate of 25 packets per sec and different polling intervals.
0 50 100 150 200 250
0
5
10
15
20
25
30
time (sec)
rcvd
pkt
s/se
cTotal Number of Received Packets per second
Attack Rate 14pkts/sec
15s
30s
45s
60s
Figure 20: Total number of received packets per sec by the victim under attack rate of 14 packets per sec and different polling intervals.
0 50 100 150 200 250
0
5
10
15
20
25
30
35
40
time (sec)
rcvd
pkt
s/se
c
Total Number of Received Packets per secondAttack Rate 25pkts/sec
15s
30s
45s
60s
42
Figure 22 illustrates the successfully reaction of the designed monitoring system,
where the attack is detected and mitigated on time depending on the polling interval. In a
presence of a large volume attack, both the entropy value and packet counters exceed the
predefined thresholds and the system is aware of the anomaly. The high volume attack is
timely detected.
6.5. Entropy Value
Keeping fixed attack rates the fluctuation of the entropy value is monitored during
the different windows of the collection of the statistics. As the graphs show below, the
threshold is the same for all the experiments at -12.5 value. The entropy value decreases
as the attack rate increases because the randomness of the traffic distribution decreases
too. Before t=90s the entropy is close to the threshold. Although in some cases the value
is lower than the threshold, an alert is generated by the analysis, but due to the packet
thresholds as a second and stricter check an attack correctly is not detected. Depending on
the traffic volume and the data to be analyzed the attack is detected sooner or later. It can
be observed that the patterns of the entropy value are the same in all the cases indicating
the correctness of the designed system and the mitigation’s affect.
Based on the attack volume, the entropy value drops accordingly. Increasing the
attack rate the entropy value is much lower than the threshold depicting the increased
0 50 100 150 200 250
0
10
20
30
40
50
60
time (sec)
rcvd
pkt
s/se
c
Total Number of Received Packets per secondAttack Rate 40 pkts/sec
15s
30s
45s
60s
Figure 22: Total number of received packets per second by the victim under attack rate of 40 packets per sec and different polling intervals.
43
volume of the traffic within the network. In all cases, the sudden drop of the entropy value
indicates the start of the attack. When the attack is detected and the mitigation of it is
enabled, the entropy value is stabilized following a pattern as the network traffic does not
change.
As the patterns of the entropy are the same regardless the attack rate as Figures
23, 24 and 25 show, let’s take a closer look on the polling intervals and how they are
correlated with the value. When the collection of the statistics is performed every 15 sec, it
is observed that the entropy value drops at t = 90s, when the attack starts and at t=115s,
which is the time when the attack is detected, it is stabilized. The spikes that are presented
are based on the narrow time window of 15sec and the analysis is more sensitive and
accurate on the size of the collected data. Such a narrow monitoring window reflects more
information about the existing traffic on the network. It is correctly indicates that the
legitimate traffic is slightly different every second.
When the polling interval is every 30 seconds the entropy value starts dropping
again at simulation time t=90s. The next data analysis is performed at t=120s, when the
detection module will identify the anomaly and will mitigate the threat. From that time,
the entropy remains stable.
0 50 100 150 200 250
-30
-25
-20
-15
-10
-5
0
time (sec)
entr
op
y va
lue
Entropy14 pckts/sec attack rate
15s
30s
45s
60s
Threshold
Figure 23: Entropy value under attack rate of 14 packets per sec and different polling intervals
44
Opposed to small polling intervals and considering the fact that all flow entries of
the flow table expire every 30sec, the polling interval of 45sec does not perform so well for
low and medium volume attacks, which is verified once again as it was discussed earlier.
As Figure 23 and Figure 24 present, the attack will not be detected on time, but one
interval later at 180s. This happens due to flow expiration every 30sec. The monitoring
system does not keep any history regarding the reported statistics during the interval and
it is difficult to identify the attack when the monitoring does not cover a whole interval
window. During the low and mid-volume attacks the entropy starts dropping at t=135sec
and the attack is mitigated at t= 180s. However, in the presence of a high volume attack
the value exceeds the threshold on time and the attack is detected at t=135s, as Figure 25
illustrates.
Last but not least, when the statistics are collected every 60seconds, the detection
system has enough data to analyze. The drop of the value starts the time t=90s and
decreases until the mitigation is enabled. After that point, the value remains stable as it
was expected. However, when the attack is weak, Figure 23, the collected data for analysis
do not help the detection of it. The entropy value is lower than the threshold but the
packets thresholds are not exceeded during this weak attack rate. As a result, a big interval
window is not so accurate in low volume attacks.
0 50 100 150 200 250
-40
-35
-30
-25
-20
-15
-10
-5
0
time (sec)
entr
op
y va
lue
Entropy25 pckts/sec attack rate
15s
30s
45s
60s
Threshold
Figure 24: Entropy value under attack rate of 25 packets per sec and different polling intervals.
45
6.6. Conclusion Remarks
In this section, the performance of the designed monitoring system under DoS
attacks was described. The quantitative effect of attacks against the victim was presented
under various attack rates. The results showed that the reactiveness of the monitoring
system is based on the time interval during which the collected statistics regarding the
network traffic are analyzed. Narrow windows of polling intervals detect faster the attack
as the detection module of the centralized controller has more detailed overview about the
current traffic within the network. Increasing the periodic collection of the statistics the
attack is identified later. Affecting by the flow expiration, window sizes such as 45s, do not
perform well as the reactiveness is not on time, but later on. The entropy value significantly
drops in most of the cases when the attack starts and is stabilized when the mitigation is
enabled. Based on the decision of the designed system to use extra packet counter
thresholds before the attack is finally detected, less false-positive alarms are generated.
However, in cases such as low-volume attack and big window of polling interval, the
attacker obtains to flood the victim without identification of the presence of malicious
traffic by the detection module, as the predefined packet thresholds are not exceeded. The
results based on the use-case monitoring system and selected attack scenarios prove the
easiness of design a monitoring system in an SDN network under cyber security attack as
well as the assessment of its performance in terms of reactiveness, effectiveness and
efficiency. However, it has to be mentioned, that the current design of the monitoring
0 50 100 150 200 250
-60
-50
-40
-30
-20
-10
0
time (sec)
entr
op
y va
lue
Entropy40pckts/sec attack rate
15s
30s
45s
60s
Figure 25: Entropy value under attack rate of 40 packets per sec and different polling intervals.
46
system is purely based on the selected configuration parameters without indicating the
generalization of the results under all the kind of attacks.
47
7. Discussion and Conclusion
The current work presented the provision of a complete simulation framework,
which is able to support the simulative approach of security attacks’ impact against SDN
architectures. Integrating the SDN architecture into SEA++ attack simulator, the
reproduction of the impact of security attacks against the network is possible. The
integrated security monitoring system consists of 3 basic modules, (i) the statistic
collection, (ii) the attack detection and (iii) the attack mitigation module all of them
running as applications on top of the centralized controller. For the purposes of this work,
the collection of statistics is performed in an active native OpenFlow- based way by
exchanging OpenFlow messages between the centralized controller and the OpenFlow-
enabled switches. The OpenFlow messages “OFPT_STATS_REQUEST” and
“OFPT_STATS_REPLY” have been implemented and they are periodically exchanged in
order for the controller to collect information about the flow entries of the switches’ flow
tables. The attack detection is based on the entropy algorithm. The literature has shown
that the algorithm is suitable for the detection of DDoS attacks as it measures the
randomness of the traffic distribution of the network. Using the entropy algorithm, it is
easily to identify the anomaly as the value of the measurement decreases indicating lower
randomness of the traffic distribution and reveal information about the victim and the
compromised host. Finally, the attack mitigation module is based on the packet dropping.
As soon as the detection module recognizes the threat between the source and the victim,
the “DROP” action of the OpenFlow protocol has been added and the traffic between the
targets is dropped.
The above security monitoring system was tested against DoS attacks in different
attack rates within a simple topology. The results show the reactiveness and the
effectiveness of the designed monitoring system. Based on the collection of the statistics
and the periodic request for data, the identification of a threat will be done sooner or later.
The mitigation of the attack is successfully established as soon as the threat has been
detected. According to the results, the attack detection module is the core of the network
monitoring system as it is responsible to identify any possible threat of the network. The
sensitivity of the selected algorithm based on the predefined threshold lead us to the
conclusion that a more flexible, adaptive detection module is needed.
48
7.1. Limitations
The work set two distinguish objectives. The first goal is the simulative support of
attacks against SDN architectures, which was achieved by integrating the OpenFlow
protocol to SEA++ attack simulator. The second deliverable is the implementation of a
security monitoring system in order to evaluate its performance under the launched
attacks. For the purposes of this work, the designed monitoring system focuses on the
detection of DoS attacks. The targeted victim is flooded by message requests by the
compromised host. The selected security monitoring system is simple and is based on the
native OpenFlow specifications. The detection module is the core component of a
monitoring system and based on the selected implemented method a simple, static and
non-adaptive monitoring system, which is very sensitive to the detection of the attacks, is
produced. A single change of one parameter’s value in the configuration file may lead to
false attack detection. The designed system was implemented and tested under specific
configuration parameters. The abovementioned results correspond to the specific scenario
without indication of the generalization of them under all the kind of attacks. Although it
proves the achievement of addressing DoS attacks, a more scalable and efficient system
can be designed.
7.2. Future Work
As future work, it would be interesting to compare a pure OpenFlow flow-based
monitoring system with the sFlow protocol, a packet sampling approach which was
introduced in traditional networks for accurate monitoring. Based on filtering decision,
the switch decides whether the new incoming packet should be sampled or not. Literature
shows that the algorithm can be adopted in SDN architectures and performs well.
Regarding the attack detection module, and aiming to a more flexible and accurate
monitoring system, a more adaptive algorithm is needed as the classic entropy algorithm
shows limitations based on the predefined threshold. Finally, regarding the mitigation
techniques, apart from the packet dropping using the “DROP” OpenFlow action, which
was a pivotal action in a work that provides functionalities of the OpenFlow protocol,
packet caching could be implemented as an alternative method of countermeasure.
49
Focusing on the attacks, there are also some interesting parts to be further
examined. One of them is the extension of SEA++ attack simulator in order to support the
simulation of DDoS attacks using only one compromised host. The representation of
multiple hosts but using only one compromised host will ease the simulation of the attack
and add functionality to the simulator. Moreover, it deserves to be investigated more, the
simulation of attacks based on compromised switches. Using and extending the
functionalities of SEA++, it would be interesting to investigate the impact of the attacks
having compromised switches in the network interacting with their flow tables and study
the quantitative effect of them within the network. The lack of usage of TLS between the
controller and the switches make easier for adversaries to focus on the unprotected
OpenFlow messages starting cyber-attacks by altering the messages and constitutes one
more research area.
Last but not least, the overall performance evaluation of the new simulator would
be interesting to be performed. Currently, the tool was tested under a simple topology and
scalability issues were not taken into consideration.
7.3. Benefits, Economic & Environmental, Social & Ethical Aspects
Before the conclusion of the work, a discussion about the benefits, the economic,
environmental as well as the social and ethical aspects of this project will be presented.
7.3.1. Benefits
The work is primarily based on simulation environment and it investigates the
effects of security attacks against a communication network. As it was described above,
the benefits of network simulators are valuable especially when security aspects are taken
into consideration. Many risks are hidden when a new implementation of a design,
protocol or architecture is applied directly on a real network. Usually the deployment of
the new idea hide dysfunctions, which are revealed during the testing phase. If a
dysfunctional implementation is applied on a real network, then the result will be
devastating since real-traffic will be affected by the included errors. Especially, when there
is the need to test the reliability and performance of a system in the presence of different
types of attacks. It is infeasible to be performed under real network topologies. Using a
virtual network like the one that network simulators provide, the designers are able to test
the new systems under different parameters, various network conditions and multiple
50
network infrastructures. When they are aware and assured of system’s robustness and
performance, the integration of it in the real world begins.
7.3.2. Economic and Environmental Aspects
As it is derived from the above, the benefits of virtual environments reveal also
their economic and environmental advantages. The cost of development of a new system
in a virtual environment is insignificant compared to the required cost of the development
of it in a real environment. By using simulators no money are spent on network
infrastructure and equipment in order to build and test an under development network.
In this way, not only money assurance is achieved but also the ecologic consciousness is
ensured. The environment is unaffected as the building and construction of unnecessary
infrastructures is avoided.
7.3.3. Social and Ethical Aspects
All the above present the benefits, the economic and the environmental facets of
network simulators. The second noteworthy parameter of the current degree project is the
impact of security attacks against the network. It is confirmed once again that a new
security monitoring system could not be deployed directly in a real environment as the
assessment of it under attacks would be held in real time. Ethical and penal prosecution
can be indicted by the affected customers, providers, users and all the victims against the
system designers. It is dishonorable to test the performance of a system using real traffic
and attacking on it in a real network.
The final deliverable of this project, in contrast, is an open source framework,
which is available to anyone. The word “anyone” includes also the adversaries. The
adversary can have access to the simulation tool in order to study and investigate further
the design, the advantages and the restrictions of the provided security monitoring
systems. As a result, the attacker is able and free to design new kind of attacks, which will
surpass the limitations of provided systems. New threats and more clever attacks can be
created and resulted by exploiting the specific work.
7.4. Conclusion
To conclude, we provided a complete simulation framework which is able to
support the simulation of attacks against SDN architectures. A simple OpenFlow-based
51
monitoring system was designed showing the flexibility of the framework to support
implementations based on the designer’s needs. The implementation and the design of the
provided modules is totally independent of the INET’s core, as they run as applications on
top of the controller and it helps each designer to build his/her own monitoring system
and quantitatively evaluate the performance of the designed system against cyber and
physical attacks in a flexible and easy way. The complete simulation framework aims to
help researchers to quantitatively evaluate their systems against security threats
reproducing the impact of the attack overlooking how the attack is mounted.
52
8. References
[1] N. Feamster, J. Rexford, and E. Zegura, “The road to SDN,” Queue, vol. 11, no. 12,
p. 20, 2013.
[2] M. Casado, M. J. Freedman, J. Pettit, J. Luo, N. McKeown, and S. Shenker,
“Ethane: taking control of the enterprise,” in ACM SIGCOMM Computer Communication
Review, 2007, vol. 37, pp. 1–12.
[3] O. N. F. ONF, “Software-Defined Networking: The New Norm for Networks (White
Paper),” 2013, p. 12.
[4] R. Kloti, V. Kotronis, and P. Smith, “Openflow: A security analysis,” in Network
Protocols (ICNP), 2013 21st IEEE International Conference on, 2013, pp. 1–6.
[5] R. Kandoi and M. Antikainen, “Denial-of-service attacks in OpenFlow SDN
networks,” in Integrated Network Management (IM), 2015 IFIP/IEEE International
Symposium on, 2015, pp. 1322–1326.
[6] Y. Zhang, “An Adaptive Flow Counting Method for Anomaly Detection in SDN,”
CoNEXT International Conference On Emerging Networking Experiments And
Technologies, pp. 25–30, 2013.
[7] S. Shin, V. Yegneswaran, P. Porras, and G. Gu, “AVANT-GUARD: scalable and
vigilant switch flow management in software-defined networks,” presented at the CCS,
Computer and Communications Security, 2013, pp. 413–424.
[8] H. Wang, L. Xu, and G. Gu, “FloodGuard: a DoS Attack Prevention Extension in
Software-Defined Networks,” in Dependable Systems and Networks (DSN), 2015 45th
Annual IEEE/IFIP International Conference on, Rio de Janeiro, 2015, pp. 239–250.
[9] R. Braga, E. Mota, and A. Passito, “Lightweight DDoS flooding attack detection
using NOX/OpenFlow,” in Local Computer Networks (LCN), 2010 IEEE 35th Conference
on, Denver, CO, 2010, pp. 408–415.
53
[10] S. A. Mehdi, J. Khalid, and S. A. Khayam, “Revisiting traffic anomaly detection
using software defined networking,” in Recent Advances in Intrusion Detection, 2011, pp.
161–180.
[11] K. Giotis, C. Argyropoulos, G. Androulidakis, D. Kalogeras, and V. Maglaris,
“Combining OpenFlow and sFlow for an effective and scalable anomaly detection and
mitigation mechanism on SDN environments,” Computer Networks, vol. 62, pp. 122–136,
Apr. 2014.
[12] D. Kreutz, F. M. V. Ramos, P. Esteves Verissimo, C. Esteve Rothenberg, S.
Azodolmolky, and S. Uhlig, “Software-Defined Networking: A Comprehensive Survey,”
Proceedings of the IEEE, vol. 103, no. 1, pp. 14–76, Jan. 2015.
[13] F. Hu, Q. Hao, and K. Bao, “A Survey on Software-Defined Network and OpenFlow:
From Concept to Implementation,” IEEE Communications Surveys & Tutorials, vol. 16,
no. 4, pp. 2181–2206, 2014.
[14] “INET Framework - INET Framework.” [Online]. Available:
https://inet.omnetpp.org/. [Accessed: 05-Feb-2016].
[15] “OMNeT++ Discrete Event Simulator - Home.” [Online]. Available:
https://omnetpp.org/. [Accessed: 05-Feb-2016].
[16] M. Tiloca, F. Racciatti, and G. Dini, “Simulative Evaluation of Security Attacks in
Networked Critical Infrastructures,” in Computer Safety, Reliability, and Security,
Springer, 2015, pp. 314–323.
[17] “seapp (SEA++) · GitHub.” [Online]. Available: https://github.com/seapp/.
[Accessed: 01-Apr-2016].
[18] A. H\a akansson, “Portal of research methods and methodologies for research
projects and degree projects,” in Proceedings of the International Conference on
Frontiers in Education: Computer Science and Computer Engineering (FECS), 2013, p.
1.
[19] “GitHub - lsinfo3/ofomnet:” [Online]. Available:
https://github.com/lsinfo3/ofomnet. [Accessed: 01-Apr-2016].
54
[20] D. Caldwell, A. Gilbert, J. Gottlieb, A. Greenberg, G. Hjalmtysson, and J. Rexford,
“The cutting EDGE of IP router configuration,” ACM SIGCOMM Computer
Communication Review, vol. 34, no. 1, pp. 21–26, 2004.
[21] A. Wool, “The use and usability of direction-based filtering in firewalls,”
Computers & Security, vol. 23, no. 6, pp. 459–468, Sep. 2004.
[22] A. Wool, “A quantitative study of firewall configuration errors,” Computer, vol. 37,
no. 6, pp. 62–67, 2004.
[23] J. Sherry, S. Hasan, C. Scott, A. Krishnamurthy, S. Ratnasamy, and V. Sekar,
“Making middleboxes someone else’s problem: network processing as a cloud service,”
ACM SIGCOMM Computer Communication Review, vol. 42, no. 4, pp. 13–24, Oct. 2012.
[24] A. D. Ferguson, A. Guha, C. Liang, R. Fonseca, and S. Krishnamurthi,
“Participatory networking: An API for application control of SDNs,” in ACM SIGCOMM
Computer Communication Review, 2013, vol. 43, pp. 327–338.
[25] H. Kim and N. Feamster, “Improving network management with software defined
networking,” Communications Magazine, IEEE, vol. 51, no. 2, pp. 114–119, 2013.
[26] R. Sherwood, G. Gibb, K.-K. Yap, G. Appenzeller, M. Casado, N. McKeown, and G.
M. Parulkar, “Can the production network be the testbed?,” in OSDI, 2010, vol. 10, pp. 1–
6.
[27] “POX Wiki - Open Networking Lab - Confluence.” [Online]. Available:
https://openflow.stanford.edu/display/ONL/POX+Wiki. [Accessed: 05-Feb-2016].
[28] “Ryu SDN Framework.” [Online]. Available: https://osrg.github.io/ryu/.
[Accessed: 05-Feb-2016].
[29] “The OpenDaylight Platform | OpenDaylight.” [Online]. Available:
https://www.opendaylight.org/. [Accessed: 05-Feb-2016].
[30] “Floodlight OpenFlow Controller -Project Floodlight.” [Online]. Available:
http://www.projectfloodlight.org/floodlight/. [Accessed: 05-Feb-2016].
55
[31] N. Gude, T. Koponen, J. Pettit, B. Pfaff, M. Casado, N. McKeown, and S. Shenker,
“NOX: towards an operating system for networks,” ACM SIGCOMM Computer
Communication Review, vol. 38, no. 3, pp. 105–110, 2008.
[32] T. Koponen, M. Casado, N. Gude, J. Stribling, L. Poutievski, M. Zhu, R.
Ramanathan, Y. Iwata, H. Inoue, T. Hama, and others, “Onix: A Distributed Control
Platform for Large-scale Production Networks.,” in OSDI, 2010, vol. 10, pp. 1–6.
[33] P. Berde, W. Snow, G. Parulkar, M. Gerola, J. Hart, Y. Higuchi, M. Kobayashi, T.
Koide, B. Lantz, B. O’Connor, and P. Radoslavov, “ONOS: towards an open, distributed
SDN OS,” 2014, pp. 1–6.
[34] S. Sezer, S. Scott-Hayward, P.-K. Chouhan, B. Fraser, D. Lake, J. Finnegan, N.
Viljoen, M. Miller, and N. Rao, “Are we ready for SDN? Implementation challenges for
software-defined networks,” Communications Magazine, IEEE, vol. 51, no. 7, pp. 36–43,
2013.
[35] S. Jain, A. Kumar, S. Mandal, J. Ong, L. Poutievski, A. Singh, S. Venkata, J.
Wanderer, J. Zhou, M. Zhu, and others, “B4: Experience with a globally-deployed software
defined WAN,” in ACM SIGCOMM Computer Communication Review, 2013, vol. 43, pp.
3–14.
[36] “Google Cloud Platform Blog: Enter the Andromeda zone - Google Cloud
Platform’s latest networking stack.” [Online]. Available:
http://googlecloudplatform.blogspot.se/2014/04/enter-andromeda-zone-google-cloud-
platforms-latest-networking-stack.html. [Accessed: 18-Feb-2016].
[37] “Open Networking Foundation.” [Online]. Available:
https://www.opennetworking.org/index.php. [Accessed: 05-Feb-2016].
[38] “OpenDaylight - An Open Source Community and Meritocracy for Software-
Defined Networking | OpenDaylight.” [Online]. Available:
https://www.opendaylight.org/news/foundation-news/2013/04/opendaylight-open-
source-community-and-meritocracy-software-defined. [Accessed: 18-Feb-2016].
[39] “Cisco DevNet: Open SDN Controller.” [Online]. Available:
https://developer.cisco.com/site/openSDN/. [Accessed: 18-Feb-2016].
56
[40] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford,
S. Shenker, and J. Turner, “OpenFlow: enabling innovation in campus networks,” ACM
SIGCOMM Computer Communication Review, vol. 38, no. 2, pp. 69–74, Apr. 2008.
[41] “ns-3: ns3::OpenFlowSwitchNetDevice Class Reference.” [Online]. Available:
https://www.nsnam.org/doxygen/classns3_1_1_open_flow_switch_net_device.html#d
etails. [Accessed: 05-Feb-2016].
[42] O. N. F. ONF, “OpenFlow Switch Specification Version 1.5.0 (Protocol version
0x06),” 2014, p. 277.
[43] “:::EstiNet Technologies:::” [Online]. Available:
http://www.estinet.com/products.php?lv1=13&sn=14. [Accessed: 05-Feb-2016].
[44] S.-Y. Wang, C.-L. Chou, and C.-M. Yang, “EstiNet openflow network simulator and
emulator,” Communications Magazine, IEEE, vol. 51, no. 9, pp. 110–117, 2013.
[45] D. Klein and M. Jarschel, “An OpenFlow extension for the OMNeT++ INET
framework,” in Proceedings of the 6th International ICST Conference on Simulation
Tools and Techniques, Brussels, Belgium, 2013, pp. 322–329.
[46] O. N. F. ONF, “OpenFlow Switch Specification (Version 1.0.0 (Wire Protocol 0x01)
).” Dec-2009.
[47] “GitHub - inet-framework/inet: INET framework for the OMNeT++ discrete event
simulator.” [Online]. Available: https://github.com/inet-framework/inet. [Accessed: 05-
Feb-2016].
[48] G. Dini and M. Tiloca, “ASF: An attack simulation framework for wireless sensor
networks,” in 2012 IEEE 8th International Conference on Wireless and Mobile
Computing, Networking and Communications (WiMob), 2012, pp. 203–210.
[49] G. Dini and M. Tiloca, “On simulative analysis of attack impact in Wireless Sensor
Networks,” in 2013 IEEE 18th Conference on Emerging Technologies Factory
Automation (ETFA), 2013, pp. 1–8.
57
[50] J. François, L. Dolberg, O. Festor, and T. Engel, “Network security through
software defined networking: a survey,” in Proceedings of the Conference on Principles,
Systems and Applications of IP Telecommunications, Chicago, United States., 2014, p. 6.
[51] P. Phaal, S. Panchen, and N. McKee, “InMon corporation’s sFlow: A method for
monitoring traffic in switched and routed networks,” 2001.
[52] A. Yassine, H. Rahimi, and S. Shirmohammadi, “Software defined network traffic
measurement: Current trends and challenges,” Instrumentation & Measurement
Magazine, IEEE, vol. 18, no. 2, pp. 42–50, Apr. 2015.
[53] S. R. Chowdhury, M. F. Bari, R. Ahmed, and R. Boutaba, “Payless: A low cost
network monitoring framework for software defined networks,” in Network Operations
and Management Symposium (NOMS), 2014 IEEE, 2014, pp. 1–9.
[54] C. Yu, C. Lumezanu, Y. Zhang, V. Singh, G. Jiang, and H. V. Madhyastha,
“Flowsense: Monitoring network utilization with zero measurement cost,” in Passive and
Active Measurement, 2013, pp. 31–41.
[55] M. Moshref, M. Yu, R. Govindan, and A. Vahdat, “DREAM: dynamic resource
allocation for software-defined measurement,” 2014, pp. 419–430.
[56] J. Suh, T. T. Kwon, C. Dixon, W. Felter, and J. Carter, “OpenSample: A Low-
Latency, Sampling-Based Measurement Platform for Commodity SDN,” 2014, pp. 228–
237.
[57] T. Kohonen, “The self-organizing map,” Proceedings of the IEEE, vol. 78, no. 9, pp.
1464–1480, 1990.
[58] S. Schechter, J. Jung, and A. Berger, “Fast Detection of Scanning Worm
Infections,” in Recent advances in intrusion detection: 7th international symposium,
RAID 2004, Sophia-Antipolis, France, September 15-17, 2004: proceedings, France:
Springer Berlin Heidelberg, 2014, pp. 59–81.
[59] J. Twycross and M. Williamson, “Implementing and testing a virus throttle,”
Proceeding SSYM’03 Proceedings of the 12th conference on USENIX Security
Symposium, vol. 12, pp. 20–20, 2003.
58
[60] M. V. Mahoney, “Network traffic anomaly detection based on packet bytes,” in
Proceedings of the 2003 ACM symposium on Applied computing, 2003, pp. 346–350.
[61] Y. Gu, A. McCallum, and D. Towsley, “Detecting anomalies in network traffic using
maximum entropy estimation,” in Proceedings of the 5th ACM SIGCOMM conference on
Internet Measurement, 2005, pp. 32–32.
[62] S. M. Mousavi and M. St-Hilaire, “Early detection of DDoS attacks against SDN
controllers,” in Computing, Networking and Communications (ICNC), 2015
International Conference on, 2015, pp. 77–81.
[63] S. Oshima, T. Nakashima, and T. Sueyoshi, “Early DoS/DDoS Detection Method
using Short-term Statistics,” 2010, pp. 168–173.
[64] G. Androulidakis, V. Chatzigiannakis, and S. Papavassiliou, “Network anomaly
detection and classification via opportunistic sampling,” Network, IEEE, vol. 23, no. 1, pp.
6–12, 2009.
[65] A. Bates, K. Butler, A. Haeberlen, M. Sherr, and W. Zhou, “Let SDN Be Your Eyes:
Secure Forensics in Data Center Networks,” 2014.
TRITA TRITA-ICT-EX-2016:117
www.kth.se
