1. Looking Beyond the Flexibility Offered by
Software Defined Networking: Security Issues
"A thesis submitted to the Department of Computing
in partial fulfillment of the requirements of
MSc Degree in Information Security and IT Management”
Oladotun Joseph Ojebode
ID number: 22758267
MSc InformationSecurity & IT Management
Department of Computing
Supervisor: James Coleman
2015/16

2. i
Abstract
Majority of the research papers on Software Defined Networking (SDN) has focused
mainly on how this new emerging network architecture model can be exploited, to
overcome the limitations of the traditional networking architecture. However, little
scrutiny has been done on the security implications of deploying SDN, and how to solve
the security issues posed by it. Thus, this thesis performed a security analysis of the SDN
architecture using the STRIDE threat model and SDN mode of operation. Furthermore,
this thesis provided an implementation solution to mitigate against the main threat posed
by SDN which is the centralised controller threat. The implementation solution employed
the use of two SDN controllers and was deployed using the virtual network environment
known as Mininet. The tests showed that using a single SDN controller to control the
whole network poses a risk of network outage; on the contrary, deploying two SDN
controllers with one acting as a backup controller minimises the risk of network outage.
Suggestions on best practices to follow when planning to deploy SDN was also presented
based on technical evaluation of the SDN controllers. This thesis identified potential
security threat points in the SDN stack and provided some solution suggestions. Also, this
thesis confirmed that by exercising careful controls and risk mitigation implementations,
the benefits offered by SDN does not have to be realised at the cost of its security risk.

3. ii
Acknowledgement
Firstly, I want to thank the almighty God for his mercy and sustenance over my life, and
for directing me to Edge Hill University to undertake my Master’s degree.
I also want to express my sincere gratitude to my thesis supervisor, James Coleman.
James is a senior lecturer at the computing department of Edge Hill University and he
lectured most of my courses during my Master’s degree. He was very supportive both
throughout my courses and during my Master’s thesis in terms of time, useful remarks
and knowledge impartation that steered me in the right direction. I had prior interest in
this thesis topic but would not have embarked on it without James giving me the
encouragement to go for it.
I would like to acknowledge and thank Dr. Mark Liptrott who is also a senior lecturer at
Edge Hill University computing department for taking time out of his busy schedule to
point out areas for adjustment in my thesis.
I also want to thank Claire Moscrop who is also a senior lecturer at Edge Hill University
for taking time out to help me proof read part of my thesis whilst pointing out areas that
needs restructuring.
Lastly, I want to thank my parents especially my mother for investing heavily in me. No
amount of gratitude I express can repay your love, effort, expenses, prayers and
encouragement you offered me right from the time I was born.

4. iii
Declaration
I declare that this thesis is my own work and other contributions published by other
authors and researchers have been acknowledged and referenced appropriately to the best
of my knowledge according to academic standards. The intellectual content of this thesis
is the outcome of my own personal research, logical thinking and conducted experiment.

5. iv
Dedication
This Thesis is Dedicated
To my Parents
Mr and Mrs Ojebode
and
To my Siblings
Seun, Seyi, Peter and Tayo.
Thanks for your continuous support in assisting me to
achieve my academic goals.

6. v
Table of Contents
1.0 Introduction..................................................................................................................1
1.1 Subject Background and Motivation ..........................................................................1
1.2 Problem Domain.........................................................................................................2
1.3 Thesis Aim and Objectives.........................................................................................2
1.4 Scope...........................................................................................................................3
1.5 Thesis Structure ..........................................................................................................4
2.0 Software Defined Networking: Concept, Components and Benefits .....................5
2.1 Traditional Network Architecture...............................................................................5
2.2 SDN Network Architecture ........................................................................................7
2.3 SDN Network Devices .............................................................................................10
2.4 SDN Controllers .......................................................................................................12
2.5 SDN Applications.....................................................................................................13
2.6 SDN Communication Protocol.................................................................................14
2.7 Contributions of SDN to Networking and Security Field ........................................17
3.0 Methodology ...............................................................................................................20
3.1 Identifying Probable Security Issue Points in SDN..................................................20
3.2 Insight on SDN Operations and Security Issue Solution Code Implementation......22
3.3 Advice on Best Practices for SDN Deployment.......................................................24
4.0 SDN and Security.......................................................................................................25
4.1 Security Issues in SDN .............................................................................................25
4.2 Fabricated Traffic Flow ............................................................................................27
4.3 SDN Network Element Exploitation ........................................................................28
4.4 Forwarding and Control Plane Communication Link ..............................................30
4.4.1 Communication Link between Forwarding and Control Plane..........................30
4.4.2 Standard Southbound Communication Protocol................................................31
4.5 SDN controller..........................................................................................................32
4.6 Application and Control Layer Interface..................................................................35
4.7 Malicious applications ..............................................................................................36
5.0 Experimentation.........................................................................................................40
5.1 Technical Insight on SDN Network Operations.......................................................40
5.1.1 Test and Evaluation............................................................................................43
5.2 SDN Network High Availability Implementation....................................................44
5.2.1 Test and Evaluation............................................................................................45
5.3 Best Practices Suggestion for SDN Deployment: SDN Controllers ........................50
5.3.1 Open Source or Proprietary SDN Controllers? ..................................................50

7. vi
5.3.2 Securing Access to the SDN Northbound Interface...........................................55
6.0 Conclusions.................................................................................................................57
Bibliography.......................................................................................................................59
APPENDIX A: HP VAN SDN Controller Web GUI Features .........................................65
APPENDIX B: OpenDaylight Controller Web GUI Features...........................................66
APPENDIX C: Ettercap Capture Result for OpenDaylight Controller .............................67
APPENDIX D: MITMF Capture Result for OpenDaylight Controller .............................68
APPENDIX E: Urlsnarf Capture Result for OpenDaylight Controller .............................69
APPENDIX F: Ettercap Capture Result for HP VAN Controller .....................................70
APPENDIX G: MITMF Capture Result for HP VAN Controller .....................................71
APPENDIX H: Connection Error Message due to HSTS .................................................72
APPENDIX I: Iptables Parameters Definition ..................................................................73

8. vii
List of Figures
Fig 2.1 Traditional Network Architecture............................................................................6
Fig 2.2 Operating System Model.........................................................................................8
Fig 2.3 SDN Network Architecture .....................................................................................9
Fig 2.4 OpenFlow Switch Components .............................................................................15
Fig 2.5 Flow Table Entry Constituents ..............................................................................16
Fig 3.1 STRIDE Threats Modelling Cycle Process ...........................................................22
Fig 4.1 SDN Architecture Probable Security Issue Points ................................................26
Fig 4.2 Conventional Network Security Model.................................................................33
Fig 4.3 SDN Network Security Model ..............................................................................34
Fig 5.1 Mininet GUI Custom Network Topology .............................................................42
Fig 5.2 HP VAN SDN Controller Global Network View .................................................43
Fig 5.3 SDN Network High Availability logical topology ................................................46
Fig 5.4 Full SDN Network Connectivity ...........................................................................46
Fig 5.5 OpenDaylight SDN Controller Global Network View..........................................47
Fig 5.6 Gradual Network Connectivity after Primary Controller Down ...........................47
Fig 5.7 Network Outage after both Controllers Are Offline..............................................48
Fig 5.8 Different Controller for Different Network Segments ..........................................49
Fig 5.9 OpenDaylight Controller MITM Attack Setup .....................................................53
Fig 5.10 Iptables Configuration.........................................................................................56
Fig 5.11 Configuration Verification Output ......................................................................56

9. viii
List ofTables
Table 3.1 STRIDE Threats and Security Attributes ..........................................................21
Table 4.1 SDN STRIDE Threat Table...............................................................................38

10. ix
List of Abbreviations
API Application Programming Interface
ARP Address Resolution Protocol
CA Certificate Authority
CLI Command Line Interface
CPU Command Line Interface
DDoS Distributed Denial of Service
DoS Denial of Service
EIGRP Enhanced Interior Gateway Routing Protocol
GUI Graphical User Interface
HP Hewlett-Packard
HSTS HTTP Strict Transport Security
HTTP Hypertext transfer Protocol
ICMP Internet Control Message Protocol
IP Internet Protocol
IPS Intrusion Prevention System
IT Information Technology
MITM Man In The Middle
ONF Open Networking Foundation
OS Operating System
OVS Open vSwitch
QoS Quality of Service
REST REpresentational State Transfer
SDN Software Defined Networking
SIEM Security Information and Event Management
SSH Secure Shell
TCP Transmission Control Protocol
TLS Transport Layer Security
URL Uniform Resource Locator
USB Universal Serial Bus
WAN Wide Area Network

11. 1
1.0 Introduction
1.1 Subject Background and Motivation
Traditional networking architecture lacks the flexibility to easily adapt to the varying
requirements of present internet based-systems: especially in dynamic environments such
as those that use virtualisation. Achieving a consistent level of configuration across
network devices in traditional networks is quite challenging, due to individual
configuration of each network element (Xia et al., 2015). This makes network elements
susceptible to configuration errors which might impede proper network functionality.
Hence, there was need for a more flexible networking architecture that is able to address
this issue. Software Defined Networking(SDN) emerged as the new networking
architectural approach that promises to eliminate the limitations of traditional networking
architecture by moving configurations of all network devices to a centralised controller
(Akhunzada et al., 2015). SDN provides orchestration of network elements from a single
network point of view through the controller. What differentiates SDN from the
traditional networking architecture is the ability to detach the network hardware control
plane from its forwarding plane (Kreutz et al., 2015). This detachment allows to manage a
network from a centralised point of view. The centralised nature of the SDN controller
allows an abstract global presentation of the underlying network topology to other SDN
components. This allows the network to be tuned and optimized as needed to meet
various requirements.
SDN is a nascent technology that is already gaining ground in the IT industry. However,
its security implications are yet to be evident. Therefore, this thesis focuses on the
security issues with SDN. According to several forecast made on SDN, the SDN market
is expected to rise and be worth between an estimate of 11 to 35 billion dollars by the
year 2020 (Plexxi, 2013; Infonetics, 2014; Duffy, 2014 & Framingham, 2016). This
estimate shows an expected drastic increase in the SDN market when compared to the
current market rate of 3.7 to 4 billion in year 2016 (Kerner, 2015). Top IT companies
such as Google and Facebook are already deploying and integrating SDN into their
existing network infrastructure (Jain et al., 2013 & Vanian, 2014). In addition, a majority
of Internet Service Providers perceive SDN as a feasible alternative to their current
network infrastructure (Wagner, 2014 & Dix, 2015).

12. 2
1.2 Problem Domain
The motive for this work stems from the fact that SDN is gradually being adopted by
most IT organisations as a means to overcome the limitations posed by traditional
networking architecture. Recent studies showed that security is still of major concern for
the SDN architecture because of its design. The advent of SDN creates new attack
surfaces which when exploited by attackers can lead to disastrous effect on a network,
and can also lead to significant loss of revenue and status for an organisation. With SDN,
a whole network can be targeted and compromised as opposed to targeting and infiltrating
only important hosts in traditional networks. Primarily, when it comes to the trusting of
core network functionalities such as network management to a centralized server, the
security of SDN remains at risk. In one of the RSA conferences that took place on SDN,
Hinden (2014) emphasized on the danger that accompanies SDN technology by stating
how the SDN controller becomes a potential attack target. The point made by the speaker
was reasonably justified. He stated that instead of an attacker compromising a single host,
he could put all his effort in compromising the operating system of the network to gain
control of the whole network. With that being said, the programmability of SDN, which
is one of the main benefits offered by SDN, also serves as a weakness in terms of security
to the technology. Considering the high current rate of cybercrime, the main facilitator of
these attacks is code which is written and coupled with an exploit to execute into a
deliverable payload. This same attack surface, which is somewhat smaller in traditional
networks, becomes wider with SDN through the introduction of programmable interfaces
offered by SDN; thus, SDN applications are also vulnerable points of entry that can be
exploited to perform attacks on the network.
Considering the benefits offered by SDN, and its potential to revolutionise the IT
networking industries, it is obvious that SDN is here to stay and cannot be dismissed for
its security concerns. Consequently, the only way forward is to find ways to improve the
security of SDN.
1.3 Thesis Aim and Objectives
SDN is still an ongoing research field. One of the greatest challenges of SDN, which has
been spotted by IT professionals as the major security concern, is the centralized
controller mechanism on which SDN foundation is based on (Metzler, 2012; Haeffner,
2013 & Schneider, 2015). Previous studies on SDN have not practically addressed how to

13. 3
provide a resilient SDN architecture on a publicly known scale. The core part of this
thesis builds on the theoretical idea suggested by previous studies (Kalman, 2015; Cabaj
et al, 2014; Dabbagh et al., 2015) about having a standby or multiple controllers rather
than one that could take down the whole system in case of a failure or attack. The idea
was realised in this thesis and tested on one of the test environments developed for
researchers in the field of SDN. This makes this thesis topic an interesting one for this
dissertation because this paper aims to contribute to the research field by providing an
implementation scenario of how to mitigate the risk associated with the centralization
idea introduced by SDN. Another question aimed to be answered in this thesis is: what
can be considered best practices to follow for organisations planning to deploy SDN
technology?
Aim
The aim of this thesis is to identify probable security issue points in the SDN architecture
and provide solution implementation on how to mitigate against one of the identified
security issues.
Objectives
The objectives of this thesis are: 1) to explain the concept and components of SDN, 2) to
identify and discuss potential security issues in SDN, 3) to test and gain insight on how
SDN works, 4) to provide solution implementation to SDN centralised controller security
issue, and provide suggestions on best practices to follow when considering SDN
adoption.
1.4 Scope
This thesis provides a focused background and insight into SDN, and points out the
potential security issue points identified. This thesis does not attempt to provide solutions
to all probable identified security attack points. However, it does provide possible
recommendations on measures that can be taken to fix most of the issues identified and
also provides an implementation solution to the centralised controller issue that was
detected as the main security issue point.

14. 4
1.5 Thesis Structure
The remaining part of this thesis is composed of the following chapters.
Chapter 2: provides the reader with a focused background on SDN and its components,
how it addresses the challenges facing traditional network architecture, and its
contributions to the field of networking and security.
Chapter 3: discusses the methodology used in deriving the primary data of this thesis.
Chapter 4: discusses about the security issues in SDN.
Chapter 5: provides lab setup details and analysis of the experiments, solution to SDN
centralised controller security issue, and possible best practices to follow when planning
to adopt SDN.
Chapter 6: concludes the thesis.

15. 5
2.0 Software Defined Networking: Concept, Components and
Benefits
This chapter analyses the concept behind SDN, the components, and the benefits brought
about by it. However, this chapter starts by introducing the traditional network
architecture in order to gain a clear understanding of SDN.
2.1 Traditional Network Architecture
Conventional networks have been the networking standard for many years back up until
now. These networks have been successful in delivering services to users. However, due
to the increasing number of internet connectivity and users, and the advent of cloud
computing, these traditional networks kept on increasing in complexity as more devices
are connected, which makes them difficult to manage (Benson, Akella, & Maltz, 2009).
Certainly, the increasing complexity of traditional networks is an obvious claim that
almost every IT professional are aware of. This can be justified from the point of view of
traditional network devices being closed box that requires individual configuration before
they can perform their functions. Individual configuration of network devices can be less
tedious in a small size organisation. However, in a large organisation or production
network that requires running many devices in order to deliver an acceptable level of
network services, individual configuration of network devices can be a daunting task to
perform.
The individual configuration of network devices is just a minor issue among other issues
of traditional network devices. A more serious issue associated with conventional
networks is the ability to maintain a level of consistency, when configuring devices to
adhere with organisational policies and procedures. This notion was confirmed by Kreutz
et al. (2015) which stated that individual configuration of traditional network devices
makes it difficult to uniformly enforce predefined policies across a whole network, due to
possibility of misconfiguration. This discussion of the traditional network limitations is
important to this research because it helps in understanding how SDN solves the
limitations.
The inability of traditional networks to deliver and adapt to the varying requirements of
present networking needs has been established. However, the components that limits
traditional network devices, and makes them inflexible to adapt to varying emerging

16. 6
networking needs has not yet been discussed. Thus, the following paragraph analyses the
components that makes up the traditional network devices, and the reason why the
traditional network devices design limits innovation in the field of networking.
Fig 2.1 shows the traditional network devices architecture which is made up of the control
plane (device operating system) and the data plane. The traditional network devices
control and data plane are tightly coupled in a hardware box (Tri and Kim, 2014). The
control plane is the operating system of each network device that coordinates how packets
received should be processed and forwarded by the data plane (Akhunzada et al., 2015).
These control planes are designed by specific vendors to only accept specific syntax
commands for configuration. Thus, any other commands that violates the syntax
configuration will be rejected or lead to improper functioning of the device. Also, due to
the proprietary nature of each network device, only built-in applications can be used for
management purposes. Furthermore, due to all network devices having their own separate
control plane, each device needs to be configured separately before communication can
occur. This analysis of the traditional network architecture aid in understanding why the
architecture is inflexible, and helps to understand the SDN design and components in
subsequent sections.
Fig 2.1 Traditional Network Architecture

17. 7
To gain a clear perspective of why traditional networks gets complex as they grow, and
why the field of networking as a whole is not evolving, cisco IT company and routing
protocols are illustrated as an example.
Routing protocols are used by routers to govern how to get packets from one point to
another in networks. Enhanced Interior Gateway Routing Protocol (EIGRP) is a routing
protocol developed by cisco and used by many large enterprise networks due to its
flexibility, ability to scale well, and fast convergence over other routing protocols (Cisco,
2013). However, due to the proprietary nature of the protocol, only customers that deploy
cisco routers in their networks can enjoy the benefits of EIGRP. From this perspective,
the disadvantage of running proprietary devices and protocols can be drawn. The
implication is that, companies that implements the EIGRP protocol will not be able to
operate in a multi-vendor environment, due to interoperability issues which might result
in a vendor lock in situation. This limits them to only utilize services provided by cisco
devices alone. From this example, it is inferred that proprietary devices and protocols
limits flexibility and makes networks more complicated. This example is useful to this
research because it helps to understand the idea behind the standard southbound
communication protocol (OpenFlow) used by SDN devices to communicate with the
controller regardless of the devices vendor.
Ultimately, traditional networks are still performing their network functions effectively.
Notwithstanding, due to the proprietary nature of almost all network devices, tight
coupling of the control and data plane, and the absence of an open API to allow for
flexibility and custom application development, innovation in the field of networking is
moving at a very slow pace and networks are getting complex as they grow.
2.2 SDN Network Architecture
Software Defined Networking (SDN) is a networking concept that was introduced in the
year 2010 by Koponen et al. (2010). This group of researchers realised that the
conventional network architecture was no longer capable of delivering the requirements
needed to operate present networks efficiently due to lack of a common control platform.
So, the researchers came up with a new networking architecture idea, which decouples
the intelligence of network devices and centralises it for flexibility and dynamic network

18. 8
management. SDN can be defined as the restructuring of the link between network
devices forwarding planes and the software that governs their forwarding action (Nadeau
& Gray, 2013).
The major objective of SDN is to make networks open and programmable. In order to
understand how SDN functions, and the concept behind its implementation, an analogy of
the operating system (OS) model is presented and compared to the SDN architecture.
Fig 1.2 Operating System Model
Fig 2.2 shows the OS model that makes up a computer system. A computer system can be
said to be made up of three core layers which are the software, the OS, and the hardware.
The OS acts as an intermediary that administers access from applications to the
underlying hardware resources such as CPU, memory, storage and network interfaces.
Above the OS are the applications that request for system resources in order to perform
their intended tasks. The main point to be brought out from this analogy is the ability to
develop, install and uninstall applications on a specific OS. These abilities provided by
different OS platforms makes a system flexible and customisable to meet specific
requirements as needed. The OS analogy in Fig 2.2, when compared to the SDN
architecture in Fig 2.3, gives a clear perspective and understanding of how the SDN

19. 9
architecture can develop the field of networking at the speed of software. This idea is
important to this research because it helps in understanding the SDN architecture layers.
Fig 2.3 SDN Network Architecture
The SDN network architecture can be divided to three layers as shown in Fig 2.3. In
contrast to conventional networks, the infrastructure layer is made up of SDN capable
devices that has their control planes decoupled and moved to the control layer. The
network devices rely on the controller to give forwarding instructions and basically take
actions on packets based on the instructions pushed from the controller. The control layer
pushes flow commands to network devices through the southbound API by using a
standard protocol that will be discussed in subsequent section. Above the controller are
network applications just as in the OS model in Fig 2.2. The northbound API allows for
custom applications deployment that are used for network management purposes. For
example, if an organisation needs a peculiar type of network operation, an application
tailored to the requirement of the desired network behaviour can be developed. The
applications can be common networking applications such as security, Quality of Service
(QoS), monitoring, load balancing and many other new network applications that might

20. 10
emerge as SDN gain ground. An example of such networking application that has already
been developed by an IT company known as HP is the HP Network Optimizer SDN
application that is used for delivery of dynamic QoS (see LP, 2016a). For a visual
demonstration on how HP Network Optimizer works, see HPE Technology (2015). The
SDN architecture layers is essential to this thesis because it provides the basis for
identifying the potential security attack points in an SDN network.
In conclusion, automatic readjustment of networks to specific situations such as response
to real time network attacks or network optimisation to allow higher priority traffic to be
given preference in a dynamic environment is a challenging function to achieve with
conventional networks. However, with the advent of SDN, there is potential for all these
limitations of traditional networking architecture to be addressed.
2.3 SDN Network Devices
For devices to operate as a functional part of an SDN architecture, they have to conform
to specified standards that governs interaction between SDN components. The Open
Networking Foundation (ONF) is a non-profit organisation made up of big companies
like Google, Verizon, Facebook and others that own and manages some of the massive
networks in the world (Erickson, 2011). The ONF was developed for the sole purpose of
promoting the adoption of SDN through open standards (Open Networking Foundation,
2011) and is therefore the mind behind the open standard that governs the communication
between SDN devices.
SDN enabled network devices are networking devices such as routers and switches that
conforms to SDN standards such as having API which allows them to utilise a centralized
controller as the brain that governs their actions. SDN network elements can be either a
virtual element that runs without a dedicated hardware, or a physical element. The
physical elements can be deployed at the access layer in an office environment, with hosts
directly connected to their ports, whilst the virtual elements are more likely to be
deployed in cloud environments that uses mostly virtualisation technologies to deliver
services to clients. For a comprehensive list of both virtual and physical SDN enabled
network devices, and the name of the companies that developed them, see Open
Networking Foundation (2016).

21. 11
An example of a virtual SDN enabled network element is the Open vSwitch (OVS). OVS
is a multilayer, production quality virtual switch that is capable of facilitating vast
network automation in large data centres (SDxCentral, 2016). OVS software can be
deployed either as a standalone physical switch or can be deployed to run on top of a
hypervisor on a server that hosts virtual machines. It is an open source virtual switch that
is available for download at Open vSwitch (2014), and that is why it was the switch used
for the SDN experiment performed in this thesis. Software based SDN devices might be
less prone to resource constraint issues such as processing power and memory
(Goransson & Black, 2014). Nevertheless, in contrast to SDN physical hardware
elements, it can be reasoned that software based SDN devices are probable to operate
slower due to lack of hardware acceleration.
SDN network devices can operate either in a hybrid mode or non-hybrid mode
(Goransson & Black, 2014). In hybrid mode, network devices operate both in traditional
mode and SDN enabled mode, whilst in a non-hybrid mode, control is totally delegated to
the SDN controller. Obviously, the hybrid mode can be seen as a migration and
mitigation strategy that minimises the risk of entrusting the total control of network
devices to the controller.
An example of an IT organisation that deals in production of SDN network devices is
Meru Networks. Meru Networks has deployed several SDN devices such as Meru access
points, Meru controllers and Meru switches. Meru Networks has an uploaded demo
video that shows how their Meru SDN solution (which contains of an SDN controller,
SDN access point and a switch) can help organisations understand the benefits of
deploying SDN. Meru Networks SDN solution video is a great example that showed an
in-depth demonstration of how SDN enabled network devices can provide organisations
with highly improved network performance, end-to-end network-wide unified policy
enforcement, and unified wired and wireless management. To see a video demonstration
of the Meru SDN solution, see Meru Networks (2014).
In conclusion, SDN network devices are essential part of the SDN architecture. The
virtual OVS switch is an important SDN network element to this research. It was this
OVS switch that was deployed on Mininet and used in this thesis experiment to realise
the implementation solution provided in chapter 5.

22. 12
2.4 SDN Controllers
SDN controllers operate at the control layer of the SDN architecture, and can be seen as
the most critical layer due to the role it assumes as the brain that governs the network
activities. The SDN controller main purpose is to serve the underlying network elements
that depends on it for instructions. However, in addition to this main functionality, the
SDN controller also provides a network wide abstraction view of the underlying network
elements. This network wide view allows underlying forwarding network elements to be
programmed by the controller and allows other SDN components such as SDN
applications to carry out network management functions efficiently. The SDN controller
is a software that can be deployed on a dedicated server hardware or on a virtual machine.
Among the core functional modules of an SDN controller are topology and network
elements discovery, network statistics, flow management and network tracking
(Goransson & Black, 2014).
As shown in Fig 2.3, SDN controllers are meant to have two main API which are
northbound API and southbound API. The SDN controller is logically placed in-between
SDN applications and SDN network elements. This allows the controller to provide an
interface with SDN applications using the northbound API, and to provide an interface
with network elements using the southbound API. The northbound API can be designed
in a variety of ways based on the vendor. Some interfaces are designed in low-level API
which allows SDN applications to have the knowledge of individual network elements
without knowing their differences, whilst others are designed in high-level API to allow
applications deal with the network as a whole entity as opposed to dealing with individual
devices (Goransson & Black, 2014). These variety in API design allows different SDN
applications to manage the network based on the purpose for which they were designed.
For example, a high-level API that provides network wide view of underlying resources
might be more efficient for security applications that enforce policies across the network
as a whole.
The southbound interface of the SDN architecture uses a standardized open protocol
which will be discussed in the SDN communication protocol. In contrast to the
southbound interface, the northbound interface has no standard protocol yet for
communication between applications and the controller (Goransson & Black, 2014). This
lack of a standard northbound interface can be seen as a present imperfection of SDN.

23. 13
Furthermore, this lack of a standard northbound interface is the reason why there are
diverse vendor implementations as an alternative for communication between the
controller and SDN applications. Most controllers such as Floodlight (Admin, 2016) and
OpenDaylight (OpenDaylight, no date) northbound implementation uses a
Representational State transfer (RESTful) API as an interface to communicate with
applications. The use of REST API by these controllers makes it easier to manage them
due to the flexibility offered by REST design by using HTTP requests to POST, GET,
PUT and DELETE data (Khondoker et al., 2014). Other controllers provide interfaces
based on the language in which they were written and might be complex.
Present available SDN controllers can be categorised into two groups which are mainly
commercial and open source controllers. These controllers all share a similarity which is
the ability to allow a centralized device to coordinate a set of network elements.
However, they differ in the features that are offered by each of them, and in the
programming language in which each was developed, which also determines the
complexity of understanding and learning the controller. Among the vendors that
provides commercial SDN controllers are Big Switch, HP, Cisco, IBM, Ericsson Juniper
and NEC. For a comprehensive list of commercial SDN controllers, see SDxCentral
(2014a). There are various open source SDN controllers also and among the top popular
ones are Ryu, POX, OpenDaylight, Trema and Floodlight. For a comprehensive list of
open source SDN controllers, see SDxCentral (2014b).
In conclusion, SDN controllers are the main functional and critical part of the SDN
architecture. The SDN controller is the main essential element used for the basis of this
research. For the implementation solution provided in this thesis, both open source and
commercial SDN controllers were deployed to realise the aim of this thesis.
2.5 SDN Applications
SDN applications run in the application layer of the SDN architecture on top of the SDN
controller. SDN applications are primarily accountable for handling flows that are pushed
to network elements by using the API provided by the controller. Via this controller API,
applications are competent to perform series of actions on network elements. This actions
includes pushing flows that takes the best path to route packets between two nodes,
rerouting traffic for security purposes, load balancing across several paths, and

24. 14
accommodating changes in network topology such as detecting new added device and
failure of network links. Among common standard SDN applications that are been
deployed in present controllers is a graphical user interface (GUI) application for
managing the controller modules. An example of this is the OpenDaylight DLUX user
web interface used for this thesis (see Appendix B).
As opposed to conventional network applications, SDN network applications are not
limited to proprietary applications due to the availability of open development platforms
that allows developers to design various network applications as desired to suit
organisational needs. Examples of present SDN applications that have been developed
and available for sale on HP SDN app store are HPE Network Protector which secures
network elements in real-time, and HPE Network visualizer which captures packet in real
time and provides real-time network monitoring that allows to detect and fix network
incidents without delay (see LP, 2016a). There are other various SDN applications that
have also been developed to perform different network functions by the SDN community
and HP partners; see LP (2016a).
2.6 SDN Communication Protocol
OpenFlow is the current standard SDN southbound communication protocol (ONF,
2016). It is an API that provides an open standard interface to allow data planes of
network elements to be programmed by the controller. According to the OpenFlow switch
version 1.5.1 specification (Open Networking Foundation, 2015), an OpenFlow switch
consist of four main components which are OpenFlow channel, flow tables, group table
and meter table (see Fig 2.4). The OpenFlow channel is the link established between the
network elements and the controller that allows a bidirectional communication. The
OpenFlow protocol runs on the OpenFlow channel to allow network elements to
communicate with the controller and to allow the controller to manage the network
elements. The OpenFlow protocol allows the controller to perform series of operations
such as add, delete and update flow entries on network elements either reactively or
proactively (Open Networking Foundation, 2015). The controller performs reactive
actions when packets are forwarded by network elements to the controller to obtain
instructions on what to do with the packet. Proactive actions are taken when flows are
installed on network elements prior to the arrival of packets on forwarding device ports.

25. 15
Fig 2.4 OpenFlow Switch Components
An OpenFlow enabled forwarding device comprises of a group table, and one or more
pipeline of flow tables which determines what actions to take on packets arriving at
specific ports by looking up the flow table entries. As opposed to the first OpenFlow
specification version 1.0 which has only one flow table (OpenFlow specification, 2009),
the current number of flow tables in an OpenFlow forwarding device as improved over
time with the release of each enhanced version specification. OpenFlow enabled
forwarding devices such as routers and switches operates by forwarding packets that has
no match entry in the flow tables to the controller for instructions on actions to take on
the packet and subsequent packets that arrives with the same properties. In this situation,
the controller reacts to such request by installing flow entry actions on what to do with
the packet and similar actions are taken on packets that have same attributes as the
installed flow entry. A flow table is made up of several flow entries and each flow entry
specifies match criteria, instructions to apply to matched packets and a counter (Open
Networking Foundation, 2015). See Fig 2.5 for main fields that makes up the flow entries
in a flow table.

26. 16
The meter table contains entries that enables rate limiting per flow by gauging rate of
packets allocated to it. Rate limiting as explained by Open Networking Foundation (2015)
allows QoS function to be performed by limiting flows to a specified bandwidth.
Fig 2.5 Flow Table Entry Constituents
Fig 2.5 shows the main constituents of flow entries in flow tables. The first field which is
the match field defines packet attributes that can be extracted and matched to values
specified in those fields. An incoming packet with a match entry in the flow table
executes whatever action that is specified for that particular flow entry (see Fig 2.5 for
possible instruction set). However, an incoming packet that has no match criteria in the
flow table is termed as a table-miss (Open Networking Foundation, 2015). Each flow
table must have a table-miss flow entry that specifies actions to take if a packet matches
no flow entry. The actions are usually to forward the packet to the controller in order to
get a flow entry on what to do with the packet or to drop the packet in the case that the
packet was intentionally denied by only allowing specific IP packets. By taking a closer
look at the flow table entry components, having a prior knowledge of how firewalls work
can help deduce that the flow table can in fact serve as a firewall by specifying packet
attributes and a drop or forward action.
The match fields together with the priority field distinctively identifies a flow entry in a
particular flow table. For example, when a packet matches two flow entry rules in a flow

27. 17
table, the rule with the higher priority is given preference. If an entry in the flow table
with a priority value of 2 specifies that any packet with an IP address of 10.0.0.2 should
be forwarded out port 1, and another entry with a priority value of 1 specifies that any
packet with any source IP address to any destination IP address should be forward out
port 2, these two entries will match a packet with a destination IP address of 10.0.0.2.
However, the packet will be sent out through port 1 because it has the highest priority.
In conclusion, OpenFlow is just a standard protocol that allows interconnectivity of multi-
vendor network devices to a centralised controller, and specifies how these devices and
the controller should interact with each other. Even though OpenFlow is the only standard
SDN southbound communication protocol, there are other implementation variances that
achieves same aim as OpenFlow. Examples of those implementations are NETCONF,
LISP and ForCES; see Medved et al. (2014), Ermagan & Barkai (2014) and Haleplidis et
al. (2015) respectively.
The OpenFlow protocol is an essential element of this thesis because it was the protocol
used for communication between the SDN controllers and the virtual network elements
deployed on Mininet. Thus, this section of the literature review provided an insight on
how the protocol works.
2.7 Contributions of SDN to Networking and Security Field
In order to appreciate the value of SDN, it is important to state its contributions to the
field of networking and security. This section explains some of the benefits brought about
by SDN and how it is being used by some top IT companies.
 With the advent of SDN, networks can evolve at the speed of software. In contrast to
traditional networking devices which are closed box, SDN provides an API that
allows developers to develop specific networking applications to suit organisational
needs.
 SDN serves as a new source of revenue for IT organisations that develops network
applications. An example of such organisation that has already started benefiting from
this is HP. HP has developed some SDN applications which are on the HP SDN App
store for sale. For example, the HP Network Optimizer as of the moment of writing
this thesis costs $1999 (LP, 2016a). For a list of all SDN related applications
developed by HP, its partners, and the SDN community developers, see LP (2016a).

28. 18
 SDN allows network behaviour to be tuned from a logically central point as desired.
Furthermore, SDN eliminates the need for individual configuration of network
devices. Thus, the number of network administrators required to run a conventional
network efficiently in a particular organisation can be reduced in an SDN network.
 With SDN, multi-vendor devices that supports the OpenFlow standard can be
deployed without having to worry about interoperability issues or configuration of
each vendor specific device in its own vendor specific language.
 SDN increases scalability because network has to be managed from a central point as
opposed to individual management of network devices in conventional network. This
allows network to grow without the fear of getting complex.
 SDN improves network efficiency without concern for network and appliance (such
as firewalls and intrusion prevention systems (IPS)) overload which has been
recorded to be the main course of performance degradation and loss of connectivity
(Potharaju & Jain, 2013) in service providers’ networks. An example of an SDN
implementation which addresses this issue imposed by conventional networks that
implements middleboxes is the EnforSDN presented by Ben-Itzhak et al. (2015). The
EnforSDN implementation separates the policy enforcement layer of network
middleboxes from its resolution layer to achieve a reduced level of network and
appliance overload, and reduced network communication latency.
 SDN improves security by taking advantage of the bird's eye view it has over the
network. This new level of visibility offered by the SDN controller provides a new
way for traffic monitoring applications to detect threats. The controller has the ability
to instruct network elements to gather information about packets flowing through
them. This statistical data of network packets is sent to the controller on a set periodic
basis. The controller in turn exposes this data to external applications through an open
API that allows these applications to use approaches such as machine learning
techniques and data mining to detect traffics that has significantly deviated from a
profile of normal network traffic. An example of an IT security company which is the
first company to release a commercial version of an SDN application that deals with
denial of service (DoS) attacks is Radware. Radware developed an application named
DefenceFlow (Meyran, 2013) to detect and mitigate DoS attacks. For a visual
demonstration on how Radware application detects DoS attacks, see Radware (2013).

29. 19
 SDN also allows deployment of network wide unified security policies at an
optimized level. See NEC America (2014) for a video which contains detailed
information on how SDN accomplishes this in contrast to conventional networks.
 Google is another popular IT company that has exploited one of the advantages of
SDN to improve its wide area network (WAN) connectivity. Google enlightened in
their paper (Jain et al., 2013) on how they were able to efficiently and effectively
engineer traffics from a centralised location between their B4 software defined WAN
to WAN connectivity. Furthermore, google stated that the separation of the control
plane from the data plane allowed them to be able to swiftly deploy new network
control services such as dynamic bandwidth allocation to services that has higher
priority level than other traffics.
In conclusion, this literature review answered the objective of explaining the concepts and
components of SDN. These concepts and components are important to this research
because they form the basis for the primary data generated in this thesis and also helps in
understanding the implementation solution to the main security issue presented in chapter
5 of this thesis.
Also, this literature review identified the benefits brought about by SDN and how it is
being used by some companies. Various IT industries and businesses are trying to take
advantage of this new architecture to improve their network services. However, it is
important to note here that as with any new innovation comes the likelihood of security
concerns which should not be overlooked. SDN is still in its nascent state and this creates
new opportunities for hackers to look into areas of SDN architecture that can be exploited
to compromise a network. Several vulnerabilities such as a zero-day vulnerability that is
found in software now has a wider surface area with the introduction of open API to
networking that allows custom applications to be built. The consequences of a hacker
taking advantage of this vulnerability can have an adverse effect on an organisation such
as loss of revenue or reputation. As a result, it is important to take careful consideration
when deploying SDN to minimise the risk of falling victim of any new vulnerabilities that
comes with this architecture. Also, it is important to note that conventional networks are
capable of achieving what SDN can achieve in terms of network operations; however,
SDN performs these network operations better in an efficient and flexible manner than
conventional networks.

30. 20
3.0 Methodology
This chapter of the thesis explains how the primary data provided in this thesis was
achieved. The threat model used to derive the probable security issue points in SDN as
discussed in chapter 4.0 is explained in this chapter. Furthermore, the software and
hardware implementation used to evaluate SDN, and used to develop the solution to one
of the main security issue points (centralised controller) identified in the SDN
architecture are also explained. This chapter is divided into three subheadings as defined
below.
3.1 Identifying Probable Security Issue Points in SDN
In order to fulfil the objective of identifying the potential security issue points in the SDN
architecture stack, the STRIDE threat modelling approach was adopted and tailored to the
SDN architecture. STRIDE is a threat modelling approach that is used by Microsoft to
design secure systems and detect security design flaws (Johnstone, 2010). The authors of
STRIDE emphasised that STRIDE can be applied to new context. Although STRIDE has
only been applied to threats modelling in conventional networks, this thesis adopted and
tailored STRIDE to SDN due to its general applicability approach to new contexts in
order to pin point possible threat issues. In order to complement STRIDE in detecting
possible threats in the SDN architecture, other threats were identified by exploring SDN
major components and mode of operation.
STRIDE is applied to systems by identifying every possible element in a system and
detecting which element is susceptible to different STRIDE threats. This thesis mapped
out each layer and element of the SDN architecture and applied the STRIDE threat
modelling to detect what elements and layers of the SDN stack is susceptible to the
STRIDE threats.
Understanding STRIDE Threats
STRIDE was developed around the standard security model goals and attributes of a
secured system. The following security attributes that STRIDE was developed around as
stated by Aura (2012) are explained below.
 Authentication: ensures that user identities are verified.
 Integrity: ensures that data and system are protected against unauthorised alteration
and manipulation.

31. 21
 Nonrepudiation: ensures that every user can be held accountable for their actions.
 Confidentiality: ensures that information is available only to intended entities.
 Availability: ensures that systems remains available and accessible to authorised
entities in timely manner.
 Authorisation: ensures that access to system resources are controlled.
STRIDE is an acronym designed around the above mentioned security attributes to ensure
that systems achieve them. The STRIDE acronym is defined below and mapped to each
security attributes in Fig 3.1.
Table 3.1 STRIDE Threats and Security Attributes
The diagram in Fig 3.2 shows the STRIDE threats modelling cycle. This thesis followed
the STRIDE threat modelling cycle by first drawing out the SDN architecture stack and
elements, and identified the threats in them. This thesis did not attempt to provide
mitigation solution to all identified threats; however, this thesis gives feasible suggestions
on how most of the threats can be fixed, and provided a mitigation implementation for the
main threat identified in the SDN architecture.

32. 22
Fig 3.1 STRIDE Threats Modelling Cycle Process
The validation stage of the STRIDE threats modelling process was only applied to the
mitigation implementation solution provided for the main threat identified in this thesis.
This was to ensure that the solution developed was capable of mitigating against the
threat.
3.2 Insight on SDN Operations and Security Issue Solution Code
Implementation
Due to the nascent state of SDN technology, there was need for practical experiments to
gain insights into how SDN functions, and to carry out tests that aim to solve security
issues associated with SDN. This thesis utilized an available research testbed for SDN
(Mininet), from Mininet (2016a), and other open source tools, to derive the information
that lead to fulfilling some of the objectives of this thesis.
Mininet (Mininet, 2016b) was used to emulate a real network virtually. Mininet was
designed in such a way that it allows users to design, implement and interact with a
virtual network through the command line interface (CLI) and an application
programming interface (API). Also, it is possible to deploy Mininet on a real hardware.
However, due to the limitation in the availability of hardware during the time of
conducting this thesis, only a single hardware that runs a type 2 hypervisor (Oracle VM
VirtualBox) on top of a windows operating system (OS) was used. Regardless, there was
no significant difference noticed in running the experiment on the hypervisor as opposed

33. 23
to physical hardware except for performance issues due to the specification of the host
that was running the hypervisor. The systems running on the hypervisor (SDN
controllers, Mininet and Kali Linux) were capable of producing results that are similar to
deploying them on real hardware in a real network. The alternative to deploying the
experiment on Mininet is to use a real physical network lab; however, this was
unavailable and left Mininet as the only alternative to perform the experiment. Mininet
provides documentation and walkthrough (Mininet, 2016b) which reduced the hassles of
getting familiar with Mininet virtual network.
The Mininet python API was used to interact with the Mininet network in this thesis, and
was also used to create a custom network topology python code to realise how the risk
associated with the centralisation issue of SDN can be mitigated.
Mininet development platform was used to write two python programs that each
addressed two distinct objectives of this thesis. Two SDN controllers which are HP VAN
SDN controller (LP, 2016b) and OPenDaylight controller (OpenDayLight, 2016) were
also used to control the network elements running on Mininet.
The first python program was written to create a custom topology that connects to a
single controller. The first program written was to gain in-depth understanding of SDN
networks as will be seen in the experimentation chapter. This custom program was
designed to create three switches and four hosts that runs inside Mininet. This program
was also given the IP address of the SDN controller that was running separately on an
Ubuntu 64-bit OS server (Canonical, 2016) on the hypervisor. In order to test for full
network connectivity, the Internet Control Message Protocol (ICMP) ping application
was used. The ping application is an IP level network connectivity testing tool that
functions by sending ICMP echo request to a specified network device and listens for
echo reply.
The second python program was written to maintain same network topology as the first
program. However, the program was enhanced such that high availability was created in
the virtual network running on Mininet by connecting the network to two separate
controllers. The reason for this implementation and the test results are explained in the
experimentation chapter. The ICMP ping application was also used to generate the test
results.

34. 24
The limitation of using Mininet to emulate a real network is that, rather than using virtual
time for measurements, it uses real time. This means that a network that runs at a speed of
100Gbs is difficult to emulate. Furthermore, running high speed links such as 10Gbps in
Mininet hinders performance because unlike a dedicated switching hardware, Mininet
uses software switches for packet forwarding which lowers performance due to shared
computing resources such has CPU and memory. Nevertheless, these limitations have no
impact on the results of the experiment conducted because the aim of the experiment had
nothing to do with SDN network performance. However, some delay was experienced in
terms of the time it took most of the functions in the Mininet environment to load up and
run due to shared computing resources between the applications running as guest on the
hypervisor and the host machine.
3.3 Advice on Best Practices for SDN Deployment
This section of the methodology provides the method for answering the thesis objective
of providing advice on best practices to follow when considering SDN adoption. In order
to provide recommendations on the best course of action to follow when planning to
deploy SDN, this thesis uses certain number of measures to evaluate SDN.
Two different popular SDN controllers (HP VAN SDN controller and OPenDaylight
controller) were deployed and evaluated for their features. The OPenDaylight controller
is an open source SDN controller, while the HP VAN SDN controller is a commercial
SDN controller. HP VAN SDN controller was chosen for commercial evaluation because
it was created by a top IT company known as HP and it is already on the app store for
purchase. OPenDaylight controller was chosen for open source evaluation because it has
lot of community development support as at the moment of writing this thesis.
Furthermore, hacking applications in Kali Linux (Linux, 2016) was used to attack both
controllers in order to detect the controller that offers more security protection. Based on
the findings from analysing the two controllers, along with other secondary data to
support the findings, this thesis was able to provide recommendations on what type of
controllers to deploy in a network and how to secure access to the controller.

35. 25
4.0 SDN and Security
This chapter discusses about the security issues that are of concern with the SDN
architecture. The approach taken to analyse and discuss the issues is by using the
traditional threat modeling known as STRIDE which was discussed in previous chapter.
STRIDE was tailored to the SDN architecture in this thesis in order to point out the
different part of the SDN architecture that are vulnerable to attacks based on its main
operational components. Each attack vector pointed out was explored separately and each
component of STRIDE that is likely to be a threat was pointed out in each potential attack
vector point.
4.1 Security Issues in SDN
The reason why the benefits of SDN was discussed in previous sections was to create
awareness of the different ways in which SDN overcomes the shortcomings of traditional
networking architecture, and how it provides new ways to approach network security.
However, the technology architecture in itself is a security concern. Nevertheless, as a
result of this architecture showing vast potential to contribute greatly to different aspect
of networking, the only way forward is to realise the benefits offered by SDN. This
benefits can be realised whilst exercising careful controls to minimise the probability of
threats exploiting possible vulnerable points of entry in the SDN stack to compromise a
network.
As stated by Akhunzada et al., (2015), SDN restructured the traditional network
architecture and provides network administrators with new exciting features such as
ability to program network elements to function in a desired behaviour, centralized view
of the network, and open API that allows developed network applications to interact with
network components. These are applaudable features offered by SDN when viewed from
an agile, innovative and flexible network perspective. However, in contrast with what
Akhunzada et al., (2015) stated about SDN features, Kreutz, Ramos, & Verissimo, (2013)
also argued that these features offered by SDN also makes the network vulnerable to be
programmed by an unauthorised entity. Thus, the architecture and features of SDN
(control centralization and programmability) that makes it unique to have an edge over
conventional network architecture also makes it vulnerable to an enlarged attack surface
than conventional networks.

36. 26
The diagram below in Fig 4.1 points out the possible different parts of the SDN
architecture that can be exploited to compromise a network. Some of these threat vectors
are not peculiar to SDN architecture; nevertheless, due to the nature of the SDN
architecture, the attack surface of these vectors has been enlarged.
Fig 4.1 SDN Architecture Probable Security Issue Points
The potential security issue points identified in Fig 4.1 are named below.
1. Fabricated traffic flow (Infrastructure Layer)
2. SDN network element exploitation (Infrastructure Layer)
3. Forwarding and Control plane communication link (Southbound Interface)
4. SDN controller (Control Layer)
5. Application and Control layer interface (Northbound Interface)
6. Malicious applications (Application Layer)

37. 27
4.2 Fabricated Traffic Flow
Forged traffic in SDN can be classified as one that aims to exploit the communication
between the controller and network elements to make network resources unavailable to
authorised users or to take down the whole network. Such form of forged traffic evolves
from a common attack known as DoS attack or distributed denial of service (DDoS)
attack. It is important to note here that DoS and DDoS attacks are not peculiar to SDN
networks; however, SDN has the potential to easily enlarge the surface for this attack due
to the nature of an SDN network. This was confirmed by Kandoi & Antikainen (2015)
who stated that flow rules timeout value in an SDN element along with the bandwidth
between the Data and control plane can significantly facilitate DoS attacks. Kandoi &
Antikainen (2015) stated that high timeout values of flows in OpenFlow switches can
prevent frequent communication between the data and control plane, thereby preventing
an attacker from taking advantage of the immense overhead involved in the frequent
communication to exhaust the control plane bandwidth. Nevertheless, a high timeout
value indicates that old rules maintains their flows in the flow table which may also have
its disadvantage.
As shown in Fig 4.1, a host machine can send fake traffic to SDN network elements such
as OpenFlow switches and controller in an attempt to consume their resources. In order to
understand how a DoS or DDoS attack can be used to compromise an SDN network by
exploiting the mode of operation of an SDN architecture, consider the following example.
It was stated in one of the previous section (2.6) that the controller performs both
reactively and proactively, and the possible actions a switch can take on a packet was also
depicted in Fig 2.5. Consider an incoming packet that has no flow entry installed in an
OpenFlow switch (reactive mode), the default reaction of the switch is to forward a copy
of the packet to the controller in order to get instruction on what action to take on the
packet. This nature of the OpenFlow switch contacting the controller every time it gets a
packet that has no flow entries installed can be used by an attacker to flood the switches
and the controller. Based on the capacity and the number of request that can be handled
by the switches and controller, an attacker can successfully compromise an SDN network.
The impact of this attack in an SDN network can lead to a network outage or other denial
of services running on the network. The implication of this attack on an organisation can
be very severe and can range from loss of revenue to reputation damage.

38. 28
The features provided by SDN also has the capability to prevent a DoS attack. Consider
an SDN controller that has specific flows installed on an OpenFlow switch (proactive
mode), a flow entry rule that explicitly states that any incoming packet that matches no
flow entry rules should be discarded will make the switch to drop all packets with
unspecified match criteria. This type of protection against DoS attacks can only be
implemented in scenarios whereby the flow properties of packets that needs to be allowed
are known in advance. Nevertheless, if an attacker is able to spoof the match criteria of a
legitimate user traffic, the attacker will still be able to perform a DoS or DDoS attack by
flooding the network with fabricated but authorised traffic. A possible solution to
counter-attack against this attack vector will be an intrusion detection system such as the
one presented by Radware (2013). DefenceFlow which is an SDN based DDoS control
application developed by Radware (2013) allows flow statistics to be gathered by the
controller and opened to the DefenseFlow application. Flow statistics that significantly
deviates from the normal traffic baseline are diverted to scrubbing centre for mitigation.
Kandoi & Antikainen (2015) argued that the main feature that distinguishes DoS attacks
and makes them easily detectable is the immense traffic magnitude. However, Alsmadi
and Xu (2015) also stated that enormous traffic coming from or destined to legitimate
hosts may also raise false positive alarms which might cause those legitimate traffics to
be dropped. When both authors side of the argument are evaluated, they both made a
valid point. Thus, a more accurate method of DoS attack detection that is distinct from
traditional approach that uses traffic size to determine occurrence of DoS attack is needed
for SDN architecture.
A suggested possible solution which can be implemented in OpenFlow switches is a data
plane request rate limit. The idea behind this is to allow a boundary to be placed on the
number of request that OpenFlow switches can make to the controller in certain amount
of time. This is to prevent the controller from being overwhelmed with many request
more than it can handle at a period of time. This idea should be theoretically and
practically effective because it is improbable that the switch will continue to receive rapid
traffics from different unknown addresses in very short time intervals.
4.3 SDN Network Element Exploitation
SDN network elements such as OpenFlow enabled switches and routers are another point
of attack in an SDN network. Conventional network elements are closed box that are

39. 29
capable of making decisions on their own based on their configuration settings. However,
SDN changes that closed box design because in an SDN stack, the network elements are
dumb devices that can only act based on instructions forwarded to them. Vulnerabilities
in SDN network elements that can be exploited by an attacker can lead to a catastrophe.
This is because a single compromised switch might be all it takes to perform an attack on
the whole network. For example, a single compromised switch can be instructed to drop
packets or can be used to generate forged traffic in an attempt to overload adjacent
network devices or the controller.
One particular way that an attacker might try to exploit a vulnerability in an OpenFlow
enabled switch is through the size of the flow entry table, and timeout value for each flow
entry rule. Kloti (2013) argued that flow rules timeout rate plays a role in the number of
flows present in a switch flow table at a specific time. Current SDN switches have finite
memory space to store flow rules. For example, HP is limited to 1500 flow entries space
(Shin & Gu, 2013) which can cause the switch to drop packets when the flow entries
space is completely exhausted. Thus, an attacker can exploit this limitation by performing
reconnaissance on SDN network elements in order to have an idea of the flow entry table
size of each forwarding device. A successful information gathering that gives an attacker
knowledge of the switch flow entry size limit can make the attacker to flood the switch
with numerous packets in an attempt to bring down a segment of the network. This attack
can be mitigated against if the timeout value of flow entries is reasonably configured.
Nevertheless, the size of each switch flow entry table is also a determinant factor for a
successful attack because a switch that is limited to a small size flow entry table is likely
to be more susceptible to such attacks.
A particular scenario considered by this thesis is the theft of data using OpenFlow
enabled forwarding devices. As shown earlier in Fig 2.5, switches can be instructed to
replicate packet and forward it out multiple ports. This feature of the switch makes it
possible for a compromised switch to be given instruction to replicate all incoming
packets and divert it to a secondary destination for data theft purpose. Thus, a form of
detection mechanism that monitors SDN network elements for irregular operation is
needed to detect compromised devices in the network.

40. 30
4.4 Forwarding and Control Plane Communication Link
SDN enabled forwarding devices depends on the controller for forwarding instructions.
This dependability of SDN devices on the controller to make forwarding decision
introduces a significant risk to network availability and theft of data. This section
explores two issues which are communication link between forwarding and control plane,
and the standard southbound protocol used for the communication (OpenFLow).
4.4.1 Communication Link between Forwarding and Control Plane
In the experiment conducted in this thesis, it was discovered that the option to select
which protocol to use for communication between network devices and the controller was
available in Mininet virtual network software. The two communication protocol options
were plain TCP and TLS. The reason to use a plain TCP in an SDN network environment
is understandable. Firstly, communication overhead cannot be tolerated and should be
reduced as much as possible. Secondly, deploying TLS in an SDN environment that
requires all network elements to establish connection to the controller implies that a
general site certificate will be generated, a controller certificate will be generated, each
network element certificate will be generated, all generated certificate will need to be
signed by the general site private key and each appropriate key and certificates need to be
installed on all devices. This actually looks tedious to perform in a large network
environment. Benton, Camp, & Small (2013) argued that enabling plain TCP as the
southbound communication protocol requires only the controller IP address as the input
parameter. This serves as incentive for administrators to decline the option of opting for
TLS instead of the plain TCP. However, disabling a security feature in an SDN network
will be at the expense of an unsecured network that is vulnerable to attacks such as data
interception, data modification and data fabrication. Security features that guarantees or
at least gives a certain level of protection to the network should not be optional but
mandatory. This optional communication security discovery was backed up by Samociuk
(2015) who stated that the use of TLS in OpenFlow was stated as a recommendation and
not a must in the OpenFlow specification.
Although the use of TLS to secure the southbound communication is optional, it is still
the only protocol available to secure the medium. The use of TLS does not totally assure
a secured southbound communication channel. There have been various papers over the
years that reports weaknesses concerning TLS. For example, attacks such as FREAK

41. 31
(Beurdouche et al., 2015), and BEAST and CRIME (Goodin, 2012) are recent attack
means that were used to defeat TLS before the flaws exploited in performing those
attacks were patched up.
The major operational technique of TLS by itself is secured; however, the underlying
infrastructure that guarantees the security is susceptible to being compromised. The
security of TLS is as strong as its vulnerable points. This could be a Certificate Authority
(CA) that has been compromised or certificates that are self-signed.
An architecture such as SDN which with its benefits also introduces significant risks by
those functions (programmability and centralised control) that makes it beneficial needs a
more sophisticated security measures that are specifically designed for the architecture.
This is because unlike conventional networks that uses conventional security protocols
such as SSL/TLS to secure individual communication between devices, SDN entrusts the
whole communication decision between devices to the controller. Thus, using security
protocols that are used in conventional networks for SDN can be considered as an
underestimation of the security implications of a compromised SDN network. If an SDN
network using Transport Layer Security (TLS) for communication between devices is
compromised, the adverse effect can be more drastic than its impact in a conventional
network.
4.4.2 Standard Southbound Communication Protocol
OpenFlow is the only standard SDN southbound communication protocol as discussed
earlier in chapter 2. However, there are other implementation variances (NETCONF,
LISP and ForCES) of southbound protocols that aims to provide similar functionality that
OpenFlow uses to manage network elements. This different variances of southbound
communication protocols all have their own way of securing the communication with the
network devices. Nevertheless, this protocols are still new and yet to be deployed on a
large scale. Thus, there are likelihood that these protocols might have vulnerabilities that
are yet to be discovered. A hacker that discovers a zero-day vulnerability at a later time in
these southbound communication protocols can lead to undesirable outcomes. For
example, an attacker can leverage a security hole in any of these protocols to initiate
spoofed flow entries into the network devices in order to permit certain types of traffic
that might be needed to compromise the network. Other attacks that exploits the structure
and mode of operation of the OpenFlow protocols can be used to perform DoS or DDoS

42. 32
attacks. For example, an attacker that is able to compromise the control plane such that he
has the underlying control of network elements can use those network elements has an
intermediary to initiate a DDoS attack.
It is important to note also that securing the southbound communication alone is not
enough to guarantee security against attacks. Some form of authentication mechanism
that allows only authorised network elements to join the network should be available.
This is to prevent rogue network elements from being added to the SDN network. For
example, the controller should be able to detect which network elements are authorised to
be on the network; conversely, the network elements should be able to validate the
authenticity of the controller they are communicating with in order to prevent a rogue
controller from coordinating the network elements.
4.5 SDN controller
The centralisation approach adopted by SDN allows occurrences within the network to be
gathered. The resulting comprehensive, more cogent and more precise view of the
network simplifies enforcement of security policies and monitoring. Nevertheless, along
with this great benefits offered by the SDN controller also comes a larger attack surface
area than conventional networks. The centralised controller approach adopted by SDN
can be considered the main security threat in the SDN architecture. Some numbers of
security issues can be raised regarding the centralised nature of the SDN controller. The
reasons why it is considered the main threat in this thesis are explained below.
Firstly, the SDN controller is simply a software deployed on a server with connection to
network elements. Most cyber-attack occurrences in present networks are commonly as a
result of bugs in software that can be exploited to compromise a system. Such bugs which
can be classified under zero-day vulnerabilities should be expected in coming years as
SDN gains ground in organisations. The only anticipated difference between zero-day
attacks in conventional network and SDN architecture is the level of attack impact on the
network systems. With SDN, the damage expected to be done if a controller gets
compromised using a zero-day vulnerability will result in more adverse effect than in a
conventional network. For example, an attack analogous to Stuxnet which is a worm that
spreads over a computer network, targets specific system logic controllers and capable of
performing four zero-day vulnerability exploits (Kushner, 2013) could have drastic
effects in a programmable network like SDN. Stuxnet worm replicates itself across
computer systems through the network or through a USB drive. It evaluates a

43. 33
compromised system to check if it was among the system it was designed to take control
of and if yes, it spies on the targeted system operations and uses the collected system
information that was gathered to control the system in such a way that it causes a system
failure. Such carefully designed attack can also be developed to exploit zero-day
vulnerabilities in SDN.
Secondly, a compromised SDN controller that is being controlled by an attacker could
definitely achieve almost any network manipulation needed. For example, an attack
similar to Flame which is a worm that allows a remote access backdoor to a system by
connecting to the command and control server after installation (Kushner, 2013) can be
designed to target SDN controllers to gain control of the network. This kind of attack can
go undetected especially considering the type of control flexibility offered by SDN. To
gain a better understanding of how compromised controller can be used by an attacker,
consider the following diagram scenarios.
Fig 3.2 shows the conventional network architecture security model. With this security
model, security policies are enforced through physical network topology that places
security devices at the perimeter of the network thereby ensuring all incoming and
outgoing traffic passes through the security devices.
Fig 4.2 Conventional Network Security Model
Fig 4.3 shows the SDN network security model which in contrast to the conventional
network security model does not enforce security through physical topology since
network is virtual. With SDN network security model, flow rules govern whether traffic
passes through a security device or not. With the knowledge of this capability in mind, an
attacker can compromise an SDN controller and install rules such that malicious traffics

44. 34
that replies back to the command and control server is routed around the security device
to avoid been detected or blocked.
Fig 4.3 SDN Network Security Model
Thirdly, the SDN controller represents a single point of failure in the network. If the SDN
controller goes down, so does the whole network elements that relies on the controller for
instructions on where to forward incoming packets. A feasible attack that can cause
unavailability of the controller is a DoS attack. A possible mitigation strategy to ensure
that the controller remains available even when under attack is to have a backup
controller. The availability of the controller during an attack was one of the main core of
this thesis that was realised using the Mininet SDN virtual environment development
platform, and is discussed further in the experimental chapter of this thesis.
Other forms of attacks such has address resolution protocol (ARP) and IP address
spoofing are possible attack scenarios in SDN that can be used to deceive both controllers
and network elements. For example, a man-in-the-middle attack (MITM) is possible
between the controller and network elements when communication link is unsecured and
unauthenticated. This attack was realised in the experimental section of this thesis to
show that a controller that lacks TLS support is totally vulnerable to attacks such as eaves
dropping and data modification. In order to prevent repudiation attacks such as those
caused by MITM attacks, proper authentication and encryption systems should be
deployed. Furthermore, the controller should have a security information and event
management (SIEM) system that logs events such as login failures and changes in
security configuration and policies to prevent repudiation and facilitate security auditing.
A suggested approach to minimise the risk of a compromised controller is to avoid
delegation of the whole network to a single controller. Instead, networks can be

45. 35
segregated into segments that is controlled by different controllers. This kind of
implementation minimises the risk of compromising the whole network. In the event that
a controller gets compromised, only the segment controlled by the controller will be
affected. Furthermore, the controller should be configured in such a way that access to it
is minimised. For example, all applications and management stations that needs access to
the controller should be identified and configured for access whilst any other unspecified
systems should be denied access. An example of this implementation is shown in the
experimental section using Linux iptables. A safer option for the controller management
is to avoid remote management if possible to minimise the risk of an attacker gaining
elevated privileges since the administrative account is likely to have root access in most
cases. A further suggested security control to secure the SDN controller is to ensure that
the use of multi-factor authentication is enforced in all SDN controller design
specifications.
4.6 Application and Control Layer Interface
The backbone behind the orchestration of SDN network is made possible by the network
applications that uses the northbound API to issue commands to the underlying network
infrastructure. As at the time of writing this thesis, there is no standard northbound SDN
interface between the controller and network applications. Various SDN controllers uses
proprietary API such as REST or Java API to enable the northbound interface. For
example, the two controllers used in this thesis uses two different northbound API
respectively. The HP VAN SDN controller uses a RESTful API whilst the OpenDaylight
controller uses a Java API. There are probable security issues that might arise in the
northbound interface as discussed below.
The ability for any developer to develop network applications for an SDN architecture
opens new ways to attack and compromise a network. The issue of trust between network
applications and the controller is a point to be addressed. Controllers need to be able to
trust applications and verify that applications are authorised to issue commands to the
underlying network infrastructure. However, there is a noticeable lack of trust and
authentication mechanism between controllers and the applications running on top of
them in most present SDN controllers. Thus, a recommended solution is to secure access
to the REST or Java API layer of the controller by creating an access chain that contains
list of external applications that requires access to the controller’s REST or Java API

46. 36
layer using iptables. This is certain to prevent any unauthorised application access that
might allow unauthorised network manipulation or information gathering pending the
time that sophisticated means of creating trust between controllers and applications will
be developed. This proposed solution was tested using iptables in the experimental
section and proved to be effective. During the evaluation of controllers for this thesis,
one of the factors that made HP VAN SDN controller a preferred and proposed controller
for deployment is the fact that it restricts installation of unsigned third party applications
by default on the controller. This restriction imposed on unsigned third party applications
acts as a security mechanism that guards against installation of malicious third party
applications. Nevertheless, HP recognises that the controller might be used for
development purposes to test unsigned applications and therefore created an option to
turn off application signing validation. This option should however remain turned on in a
production or business environment to minimise the risk of getting compromised by a
malicious application.
Furthermore, the API implementation itself may be vulnerable to attack considering that
different vendors are trying to leverage the emergence of SDN to create their own SDN
solutions. A poorly designed controller can leave security holes that might be discovered
by an attacker to compromise the controller.
4.7 Malicious applications
The ability to develop custom network applications is one of the benefits introduced by
SDN. This ability serves as an advantage from the perspective that it promotes network
and security application innovation. However, this same ability also introduces another
way to compromise an SDN network. Compromising a network through vulnerable
applications is not a new occurrence in conventional networks; nevertheless, the attack
surface of compromising an SDN network through network applications may increase
significantly with the introduction of third party application developments. In order to
elaborate on the security implications of allowing third party application developments,
consider the following situations.
Firstly, SDN applications instruct controllers to modify an underlying SDN infrastructure
based on their respective functions. This allows network application developers to
develop applications that allows different network policy rules to be enforced at different
points in the network. These applications created for different network purposes have the

47. 37
potential to interfere and contradict each other. The result of this interference and
contradiction might lead to unexpected circumstances that might put the network at risk.
SDN controllers needs the ability to be able to give priority to one application over
another in order to prevent less crucial applications from overriding rules installed by
critical security applications. For example, consider the following scenario whereby a
network element is isolated from the rest of the network by a security application that
detects that the network element is functioning in a compromised way. Another network
application such as load-balancing can view the network element as the least loaded
device due to its isolated state and start redirecting traffic to it. The resulting effect of this
situation can have severe consequences on the network. Thus, controllers need the
sophistication to be able to prioritise and isolate applications from each other to prevent
interference and contradiction.
Secondly, the ability to develop new network applications gives attackers a new way to
create malicious applications purposely to compromise a potential victim network. A
hacker who spends enough time on performing reconnaissance on a network can gain
knowledge of the applications running on the network. The knowledge of those
applications can be used to deceive network engineers into installing a malicious network
application. For example, an attacker can develop a legitimate network application that is
coupled with a remote access Trojan. Once the application is able to find its way into a
network and able to execute its payload, it can beacon back to a command and control
server and take further instructions. The intention of SDN which is to allow third party
application development further complicates this situation because applications might be
installed without thorough verification by a trusted party. HP VAN SDN controller
mitigates against malicious applications by verifying that applications developed by its
partners and the community are verified and signed before being put on the application
store for sales and download. Due to the increasing number of controller vendors, a
suggested solution is to make the northbound API standard as the southbound to allow for
a common application development platform across controllers. Once a standard
northbound API is created, a trusted third party that certifies the credibility of network
applications can be established to verify that applications are genuine and harmless before
being put out for deployment.
Thirdly, legitimate applications can be compromised to gain access to network due to
flaws. An attacker that is able to compromise an application might be able to use the

48. 38
application privileges to manipulate the network or further attack other applications.
Furthermore, a flaw in an application might allow an attacker to escalate privileges to
gain control of the network at a higher level. For example, an application given a read
only permission on the underlying SDN layers such as a network statistic collector can be
compromised and modified such that it can write and execute other functions. Thus, a
suggested solution is to log all changes in application behaviour and access modifications.
Furthermore, routine network services that does not require administrative privileges
should be run with only the privilege they need to perform their network operations. This
provides a level of protection by minimising access and damage in case an application
becomes compromised. All network applications should also be kept up to date and
patches should be installed immediately when released.
STRIDE Threat Table for SDN Probable Security Issue Points
The table in Fig 4.4 shows the STRIDE threat attributes identified for each components
and layers of SDN discussed above.
Table 4.1 SDN STRIDE Threat Table
In conclusion, this chapter of the thesis has successfully identified and discussed the
potential security issue points in SDN to answer one of the objectives of this thesis. SDN
introduces new benefits and opportunities. However, this benefits and opportunities
comes at the expense of larger attack surface area and introduces new threat and attack
vectors as discussed above. Conventional networks naturally protect against common
vulnerabilities in IT systems due to their closed proprietary nature. The diversity of
software and the tight coupling of the control and data plane in a single hardware
represents resistance against usual threats. For example, an attack targeting specific
vendor devices will only affect those devices in a network as opposed to an SDN network
that is likely to compromise the whole network.

49. 39
Although this thesis does not cover in great depth the benefits and opportunities brought
about by SDN, most security professionals and researchers stated that the benefits offered
by SDN outweigh its potential threats (Open Networking Foundation, 2013). Thus, the
benefits of SDN which has helped in solving limitations faced with conventional
networks should be conserved whilst its security issues and dangers should be eliminated
as much as possible.

50. 40
5.0 Experimentation
This chapter of the thesis explains the technical details of how the lab was setup, the tests
conducted and the evaluation. This chapter is further broken down into subsections to
explain how each thesis objectives related to this chapter was achieved.
LAB SETUP DETAILS
The software and hardware used to conduct this experimentation part of the thesis are
specified below.
Hardware Specification
Platform: Dell Inspiron 5558
Processor: Intel Core i7-5500U CPU 2.40GHz
System type: 64-bit OS
Ram: 8 GB
Hard Disk: 1TB (at least 10GB space needed for software installation)
Software Requirement
Hypervisor (Type 2): VirtualBox
Server: Ubuntu Server (Version: 14.04 LTS)
SSH Terminal: Putty
X server: Xming
SDN Realistic Virtual Network: Mininet (Version: 2.2.1)
Open Source Controller: HP VAN SDN controller (Version: 2.7.10-x64)
Commercial Controller: OpenDaylight (Version: Beryllium-SR2)
Penetration Testing Software: Kali Linux
5.1 Technical Insight on SDN Network Operations
The reason for this section is to provide a technical insight on how SDN network
functions. This section will allow novice in the research area of SDN to gain an
understanding of how SDN components interacts together by providing images from the
test lab. Furthermore, it will complement the previous discussions on what this thesis
considered the major security issue in SDN.
The SDN network operations was realised in this thesis by using a realistic virtual
network known as Mininet. Mininet was created for the purpose of research, testing,
prototyping, development and teaching in the field of SDN (Mininet, 2016b). Mininet
emulates a real network by creating virtual network elements, links and controllers. The

51. 41
interesting aspect of Mininet is that any successful development carried out on Mininet
can be deployed on hardware for real-world implementation (Mininet, 2016b). The only
changes that needs to be made is to ensure that all emulated elements and specifications
used for the network design in Mininet must be replicated to exactly match the physical
lab design and topology. Due to the design of Mininet interfaces, any SDN controller it
connects to sees it as a physical SDN network rather than virtual (Mininet, 2016).
Mininet is able to achieve a realistic virtual network by running actual Linux kernel and
by using a process based virtualisation to create network elements. This process based
virtualisation approach used by Mininet makes it possible to create isolated network
elements that are impervious to each other on a single machine by using Linux containers.
Mininet creates unique network namespaces for each process that it creates. The switches
created in Mininet runs in the root namespace and this can be verified after running a
network by issuing the ‘ifconfig’ command from the CLI. In order to connect network
elements (network namespaces) together in Mininet, Mininet uses virtual Ethernet pairs.
The diagram in Fig 5.1 shows the custom topology used in this thesis which consist of
four hosts and three switches. Mininet allows to create graphical representation and
configuration of networks by using a simple GUI known as MiniEdit. However, the
Linux distribution on which Mininet runs does not allow access to graphical contents.
Hence, an X server (Xming) that allows access to graphical contents, and an SSH
terminal application (Putty) that allows for remote access connection to applications
running on Mininet, and for easier administration was needed. Putty was configured to
enable X11 forwarding in order to allow graphical contents to be displayed through the
Xming server.

52. 42
Fig 5.1 Mininet GUI Custom Network Topology
In order to realise this thesis objective, the Mininet python API was used to write a
python code that creates a custom network topology that connects to a remote controller.
The part of the main code stated below shows the lines of code that specifies the remote
IP address of the HP VAN SDN controller that Mininet should connect to and the
OpenFlow TCP port number on which the controller will listen for incoming connections.
# Add a controller to the network by specifying the IP address and port number of the
remote controller
info(‘*** Adding/connecting to remote controllern’)
network.addController(‘c0’, controller=RemoteController,
ip="192.168.63.52",port=6633)
This part of the code defines the number of hosts to be created and the IP address to
assign to created hosts
# Define variables to add hosts to the network with a specified IP address
info( '*** Joining four hosts to networkn' )
lSH1 = network.addHost( 'h1', ip='50.0.0.1' )
lSH2 = network.addHost( 'h2', ip='50.0.0.2' )
rSH1 = network.addHost( 'h3', ip='50.0.0.1' )
rSH2 = network.addHost( 'h4', ip='50.0.0.2' )
This part of the code defines the number of switches to be created.
# Define variables to add switches to the network

53. 43
info( '*** Joining three switches to networkn' )
topSwitch = network.addSwitch( 's1' )
leftSwitch = network.addSwitch( 's2' )
rightSwitch = network.addSwitch( 's3' )
5.1.1 Test and Evaluation
In order to check that the code works as wanted and creates a topology similar to the one
in Fig 5.1, the python script was compiled and executed. After executing the code,
Mininet attempted to connect to the remote HP VAN SDN controller and was able to
establish a connection. To verify that the network elements can communicate with each
other, the ICMP ping application was used to issue an echo request between all network
elements and an echo reply response was gotten for all devices to indicate a full network
connectivity.
In order to verify one of the attributes of SDN which is a global view of the network, the
web GUI for the HP VAN SDN controller was accessed by issuing the HP VAN SDN
controller IP address and port number as URL input. After logging in, the OpenFlow
topology tab was clicked on and the SDN controller was able to detect and present a
global view of the network elements in the custom python code that was ran as shown in
Fig 5.2.
Fig 5.2 HP VAN SDN Controller Global Network View