This document proposes enhancing security in OpenFlow networks. It discusses: 1) OpenFlow currently has security flaws like lack of authentication, encryption, and intrusion detection that can compromise the network. 2) The proposal is to use a network intrusion detection system as a middlebox to monitor traffic at the OpenFlow controller and detect suspicious activity. 3) Additional mechanisms like authentication, encryption, and forensics are needed to fully secure OpenFlow networks against vulnerabilities introduced by the separation of the data and control planes.

1. 1
Enhancing Security in OpenFlow
Capstone Research Project Proposal
April 22, 2016
Niketa Chellani
Prateek Tejpal
Prashant Hari
Vishal Neeralike
Interdisciplinary Telecommunications Program
University of Colorado Boulder
Abstract—The exponential growth in application-layer
programs in recent years has placed a severe constraint on the
underlying computer networks. To achieve the scalability necessary
to meet this growing demand, transition to a software-oriented
paradigm is essential. Software-defined networks (SDN) improve
network management and provide a higher quality of service while
achieving the desired scalability. However, the decoupling of data
and control planes introduces vulnerabilities in the network. The
shift to programmable networks can only be successful when the
inherent security concerns in software-defined networks are
addressed.
OpenFlow, the most widely used architecture for software-
defined networks, has several security flaws that can be exploited to
compromise the network. In this paper, we analyze the security
flaws in OpenFlow and the threats they pose to the SDN
architecture. We discuss the lack of authentication, encryption, and
intrusion detection and present a unified solution to address these
vulnerabilities.
Keywords—software-defined networking; OpenFlow; security;
middlebox; authentication; encryption; intrusion detection systems
I. INTRODUCTION
The unprecedented growth in computer networking
technology has created the need for a scalable networking
architecture. The concerns with traditional computer networks
are manifold; traditional networking protocols are static,
whereas the applications that run on top of these networks are
distributed in nature [1]. This in turn makes the networking
architecture complex and harder to scale [2]. The increasing
complexity makes it difficult for network administrators to
implement routing and administrative policies [3]. As a result,
network management becomes tougher and the quality of
service for the network suffers. To overcome these issues, it is
imperative to shift to software-defined networks.
Faculty Advisor: Joe McManus
University of Colorado Boulder
Industry Advisor: Jim Alexander
Senior Director, Charter Communications
The transition to software defined networks entails the
need for separate data and control planes. The diagram in
Fig.1 illustrates the de-coupling of control and data planes in a
Software Defined Network.
Fig.1. Architecture of a Software Defined Network
The logic of the network is implemented in the centralized
control plane, and the network switches are reduced to
forwarding elements [2] [3]. This provides an abstracted view
of the network to the higher-layer applications [3]. OpenFlow
not only provides the architecture for such a distributed
network, it also defines the communication between the
control and data planes. Thus, OpenFlow has become the
industry standard for implementing software-defined
networks.

2. 2
However, this decoupling also leaves the network open to
several vulnerabilities [4] [5] [6]. These vulnerabilities pose a
threat to the widespread implementation and adoption of
software-defined networks. Thus, it is crucial to address these
security flaws in OpenFlow to ensure the progression to
software-defined networks.
In this research proposal, we discuss the security concerns
with OpenFlow architecture and provide possible solutions to
mitigate them. Section II provides the backdrop for the
research problem through the research setting. Section III
analyzes the vulnerabilities in OpenFlow architecture. Section
IV provides a concise overview of the existing literature for
securing OpenFlow. Section V posits tentative solutions for
the vulnerabilities described in the previous sections. Section
VI gives a comprehensive plan for implementing the proposed
security solutions.
II. RESEARCH QUESTION AND PROBLEM SETTING
“Can a Network Intrusion Detection System be used as
a middlebox in the OpenFlow architecture to enhance the
security of OpenFlow networks?”
The decoupling of data and control planes in software-
defined networks has its limitations. These include threats
such as Denial of Service (DoS) attacks, information
disclosure and man-in-the-middle attacks [4] [5]. These threats
can compromise the confidentiality, integrity and availability
of the data in the computer networks. To prevent this, a
network intrusion detection system can be implemented as a
middlebox at the OpenFlow controller [6]. The Intrusion
Detection system can analyze the data at the controller to
detect any suspicious traffic flowing through the network.
However, malicious applications and compromised nodes can
find a workaround for this, and hence a more comprehensive
solution is essential. Thus, additional mechanisms are
necessary to ensure the networks are inherently secure. These
mechanisms include the use of authentication, encryption, and
forensics. Integrating these techniques with the OpenFlow
architecture will significantly enhance the security of
OpenFlow networks.
III. RESEARCH SUBPROBLEMS
A. Mitigating the Threat of a Single Point of Failure
The centralized controller presents a unique problem in
software-defined networks by introducing a single point of
failure [3] [6]. In existing computer networks, network
intelligence is distributed throughout the network in the form
of routing and forwarding tables at the routers. This
intelligence converges to a single point in OpenFlow
networks. Compromising a controller can compromise the
entire network. Thus, multiple instances of the controller are
necessary to counter the threat from a single-point of failure.
B. Ensuring Secure Communication
OpenFlow currently does not enforce encryption between
the data and control planes [4]. This leaves the network open
to man-in-the-middle attacks [4]. A single compromised node
can be used to eavesdrop communication between the
controller and switches. This can be further exploited to alter
flow tables, thus compromising the integrity and
confidentiality of the network. To prevent this, communication
between the data and control planes must be encrypted using
strong cryptographic standards.
C. Preventing Information Disclosure
OpenFlow relies on flow tables within an OpenFlow
switch to process packets [1]. The controller processes flows
and not individual packets from the OpenFlow switches [1].
This flow aggregation provides a global view of the network
to the applications in the application layer [5]. Malicious and
compromised applications can use this aggregated flow data to
discern aspects of the network that would otherwise not be
visible to them. It is, therefore, advantageous to match flows
to multiple flow rules. Further, authentication at the controller
as well as the application layer is needed.
D. Preventing Denial of Service attacks
The centralized architecture of OpenFlow leaves it
vulnerable to Denial of Service attacks. Compromised
switches can be used to alter flow tables and flood the
controller with traffic. This can bring down the entire network.
To protect the network from such attacks, it is essential to
limit packet flow-rates.
E. Using Forensics for Recovery and Investigation
OpenFlow currently does not implement any forensics
tools for data recovery and back-up. To minimize the damage
from an attack, it is crucial to incorporate security forensics
mechanisms in the OpenFlow protocol
F. Cost modelling for the proposed solution
The proposed middlebox should have a low-cost of
ownership to attract potential customers and competition from
competitors. However, the return on investment must be high
enough to incentivize the developers to implement the
solution.
IV. LITERATURE REVIEW
The concept of programmable networks originated in the

3. 3
mid-90s, when the number of networks and their
dependency on each other grew to support a wide range of
applications. However, there has been limited work done to
find ways to secure SDN networks. Previous work on the
benefits of SDNs over traditional networks, vulnerabilities
in SDN and approaches to secure them are discussed in the
following sub-sections.
A. Software defined networking terms
A software defined network can be logically divided into
three layers: the first layer, which is the component layer,
consists of network devices like switches and routers. The
second layer is the controller layer and the third is the
application layer. Communication within the SDN
architecture takes place between the switches and the
controllers over the southbound interface, and between the
controller and the applications over the northbound interface
[7].
B. Advantages of software defined networks over
traditional networks
Network management is complex and error-prone due to
the tight coupling between the data plane and control plane
of a network [8]. This makes introducing functionalities like
load-balancing, intrusion detection, and deploying new
protocols a tedious and long process. Software defined
networking simplifies network management by decoupling
the data plane and control plane [1].
The program logic in such software defined networks is
responsible to carry out the control plane functionalities,
while the hardware components such as switches and routers
forward frames and packets. The centralized logic makes
introduction of new features and protocols into the network
hassle-free. Another advantage of this approach is that new
features can be tested without affecting the network before
introducing them, therefore, minimizing the occurrences of
network failures.
Centralization of the control plane decisions helps in better
network management by being able to control the
granularity, while ensuring a centralized policy enforcement
in Software Defined Networks [8]. One approach to achieve
this by adopting OpenFlow protocol for communication
between the control plane and data plane. OpenFlow is a
standardized way of managing traffic in switches by and
exchanging information between the switches and controller.
Due to their ability to provide consistency, scalability and
hassle free management of large, heterogeneous networks,
SDNs are becoming increasingly popular in the industry.
C. Security analysis of software-defined networks
Security issues are involved with both northbound
and southbound communication in SDNs. At the northbound
communication level, weak authentication methods between
the application and the controller and inappropriate
authorization, makes spoofing attacks and malicious access to
applications easy for the offender [10]. At the southbound
level, unencrypted exchange of information between the
switches and the controller, weak authentication method and
inappropriate authorization, makes this level susceptible to
man in the middle attack, eavesdropping, spoofing and
malicious access to flow rules [10].
D. Security vulnerabilities in OpenFlow
In SDN, a centralized program logic (at the controller) is
used to carry out the functions of the control plane. Though,
this has many benefits, the centralized nature of the control
plane, creates a lot of security concerns. Traditional networks
are inherently secure because of their heterogeneous hardware
and network policies that were difficult to exploit. The paper
[9] discusses seven threat vectors to software defined
networks that are discussed below.
1. An attacker can inject a large volume of traffic in the
network to launch a Denial of Service (DoS) attack on
OpenFlow switches. Intrusion Detection Systems (IDS)
and dynamic control of traffic flow can be used to
mitigate this threat.
2. Switches in the SDN architecture can be attacked by
manipulating their behavior to disrupt network operations.
In the paper, autonomic trust solutions, detection and
monitoring of network behavior are given as the possible
ways to mitigate this threat.
3. Lack of encryption for communication over the south
bound interface and authentication of the switches at the
controller makes the entire SDN network vulnerable.
Such lack of security can be used to gain unauthorized
access to data. Multiple authorization certificates,
enhanced cryptography techniques, with addition to
dynamic flow control can be used to mitigate this threat.
4. The fact that controllers are used to simply translate the
network commands can be exploited to introduce an
aggregated attack on the network. Strict application to
port mappings, periodic flushing of forwarding rules,
cryptographic keys at the controller, and detection of
abnormal behavior are some ways to mitigate this threat.
5. A lack of mechanisms to ensure trust on the northbound
interface, used for communication between the controller

4. 4
and applications, can introduce additional threats. This
can be avoided by allowing network access to trusted
applications or defining security policies for these
applications.
6. This threat is due to the vulnerabilities in the
administrative station, which can be reprogrammed to
attack a system. Stricter authentication techniques and
recovery mechanisms are possible techniques that can
mitigate such a threat.
7. The last type of threat is the lack of an incident response
in case of an attack. Methods to determine the nature and
type of an attack, and restore the network to an operable
state immediately after an attack are not implemented in
SDNs currently. Using network security forensic tools,
maintaining immutable logs of activities and creating
periodic backups are ways to quickly recover from an
attack.
E. Enhancing security in Software Defined Networks
Security in SDNs is an unexplored field, posing many
challenges and opportunities. The following approaches
have been proposed in the past to secure software defined
networks:
• Setting permission system for communication
between applications and the control plane: In a
permission system, various parameters can be
defined to specify the access level of any
application reaching the system [11]. This
approach allows access to trusted applications
only, greatly enhancing the security at the control
and application layers.
• Intrusion Detection and Prevention System
(IDPS): Intrusion detection is the process of
monitoring and analyzing events in the network
to protect it from any security violation. Intrusion
prevention is the process of enforcing policies in
order to prevent any security compromise.
Intrusion detection and prevention together serve
as a strong line of defense against network
attacks. The basic functionalities of an IDPS
include record network events, report suspicious
events to the administrator and generate reports.
IDPSs generate logs of the information collected
by them, which are then used to frame policies to
secure the network [12].
• Ensuring flow rule data confidentiality in
OpenFlow: Limited industry and research
community work has been done to address the
security issues related to SDN. The centralized
controllers are an attractive target for attacks in
the SDN architecture, since they are open to
unauthorized access and exploitation. The
OpenFlow protocol used for communication in
the southbound interface is unencrypted and is
susceptible to man in the middle attacks. A
security measure like encrypting the data being
transmitted on the south bound interface, by the
implementation of TLS (Transport Layer
Security) combined with authentication of the
controller at the switch, may provide the
necessary security and mitigate the threat to data
confidentiality [13].
• Blocking malicious traffic by implementation of
FRESCO and FORTNOX: Seugwon Shin
in [15] suggests that "the FRESCO design
provides security response directives that may
span many flow rules, or even address network-
wide attack scenarios". FRESCO consists of an
API (Application Programming Interface) and a
security enforcement kernel, incorporated into
NOX, which can be used to block flow from an
infectious machine or shun malicious traffic and
even prioritize flow rules to enhance the security
and performance of the network.
IV. RESEARCH METHODOLOGY
The architecture of our proposed solution enhances
the security of OpenFlow widely by the following two
mechanisms: (i) encrypting data on the southbound
interface and authenticating the switches to the controller
and vice versa by enforcing TLS on the southbound
interface; (ii) implementing middle-boxes concurrently
with the switches to provide monitoring, load-balancing,
and intrusion detection of upstream traffic in the
OpenFlow network. The diagram below (Fig.2) provides
an overview of the mechanisms adopted to secure
OpenFlow network proposed in this paper.

5. 5
Fig.2. Proposed model to enhance security in SDN
A. Transport Layer Security to provide encryption and
authentication:
Transport Layer Security is a public key
infrastructure that implements the X.509 standard for
asymmetric encryption [23]. TLS enforces authentication
and encryption using two protocols: the TLS Handshake
Protocol and the TLS Record Protocol [24]. The
Handshake Protocol uses an asymmetric algorithm such
as the Rivest-Shamir-Adleman (RSA) for authentication
and secure key exchange. The Record Protocol then uses
this key as the input to a symmetric encryption algorithm
such as Advanced Encryption Standard (AES) to encrypt
data between the two endpoints, thus scrambling the data
and rendering it unreadable to an intruder.
TLS uses digital certificates to verify the identity of a
user/host. Digital certificates embed the public key of an
entity, along with other details such as the subject name,
the issuer name, validity period and the algorithm used for
signing [25] [26]. This certificate also contains the
algorithms that the entity supports for encryption. Digital
certificates are generally issued by Certificate Authorities
(CA). The Certificate Authority is a verified third party
that maintains digital certificates. When a user requests
the certificate of an entity from a CA, the CA signs the
certificate using its private key before sending it to the
user; the user then decrypts the signed certificate using the
public key of the CA. Thus, the user can verify that the
certificate is valid and has not been tampered.
Fig.3 shows a scenario where a controller uses TLS
to encrypt and authenticate the communication to an
OpenVSwitch.
Fig.3. Transport Layer Security over South-Bound Interface in
SDN
The switch first sends a Hello Packet to the
controller. This Hello indicates the version of TLS and the
encryption algorithm that the switch supports [27]. The
controller then responds with a Hello Packet of its own
[27], after which it proceeds to send its certificate to the
switch. Thus, the switch can authenticate the controller.
The switch then generates a private key and uses the
public key of the controller to encrypt the private key and
send it to the controller. Following this, the controller
switches over to TLS thus authenticates the controller;
however, this leaves the network open to attacks from
compromised switches. To prevent a rogue switch from
injecting malicious traffic, it is necessary to authenticate
the switches in addition to the controller. This is done by
authenticating the switches using their public key [27].
Once the controller sends its certificate to a switch, it will
then ask for the switch to verify its identity by sending a
public key. This prevents an adversary from adding
malicious switches to the network, thus greatly increasing
the security of the network.
B. Intrusion Detection System
Our design principle decouples traffic monitoring from
the flow control by introducing Middle-boxes in the
network. This is achieved in the following steps:
(i) Traffic from the switch access-ports is mirrored onto a
Switched Port Analyzer (SPAN)/ Mirror Port, which is
then forwarded to a Middle Box.
(ii) An Intrusion Detection System (IDS) is implemented
at the Middle Box to monitor malicious traffic by
generating alerts based on set of rules.
(iii) Any anomaly detected by the IDS is forwarded to the
‘Scrubber Network’, which then alters flow rules.
The working of the above listed mechanisms are
described below:

6. 6
• Port Mirroring for real-time monitoring of
ingress and egress flows:
Port mirroring or Switched Port Analyzer
(SPAN) port copies packet entering or exiting a
switch port to another local port for traffic monitoring
[1]. As shown in Fig.1, the ingress and egress traffic
at the OpenVSwitch (OVS) port connected to the host
is mirrored or copied to the ‘Mirror/SPAN’ port,
which then forwards these to the Middle Box for
traffic analysis.
Our design principle includes port-mirroring to
copy traffic entering and exiting the switch, primarily
because it can do so ‘real-time’. The diagram below
(Fig.3) illustrates the port-mirroring implemented on
the OpenVSwitch, installed on Ubuntu Server 14.0.4.
Fig.4. Port Mirroring on OpenVSwitch
The traffic entering the OVS on ports eth0 and
eth1 are mirrored on port m0, which are then
forwarded to the Middle-box.
• Intrusion Detection System implemented on
Middle Box using Snort and SiLk
Our security implementation in SDNs focuses
more on the high-level security policies and
automated reaction. Unlike other security
frameworks, our implementation exposes security
modules to external users or administrators who can
further define various security polices using the
modules developed. The main characteristic of our
implementation is that it uses parallel processing
units (middleboxes) that communicate with the
OpenVSwitch. Our approach allows operators to
customize the security of the network using pre-
defined policies and to customize how the switch
reacts automatically when malicious traffic is
detected.
Another important feature included in our
implementation is the automatic response to
threat alerts. Generally, a network administrator
will react to a warning by either ignoring it or
denying the source of the suspicious traffic. In
our implementation, pre-defined rules can be
used by the administrator to react in advance
using three solutions like warn, isolate or block.
For better scalability, the middleboxes in
conjunction with SiLK and YaF are used for
analyzing the traffic and detecting malicious
traffic. Additionally, the alerts generated will be
published on an interactive website to notify the
operator and take necessary actions.
Middleboxes are appliances that offers
functionality beyond simple routing and
forwarding to a network. Middleboxes are used
for additional features like deep packet
inspection or intrusion detection system in the
network.
A controller may be used to implement the
flow rules and firewalling, however, analyzing
traffic at the controller increases the risk of
having a bottleneck and also grows in
complexity. Additionally, because the link
between the controller and switch is the control
plane, it is usually of low bandwidth. Therefore,
by using middle boxes we not only reduce the
overhead on the controller but also obtain faster
bit rate on the data plane which is optimized to
handle big flows.
• Re-directing malicious traffic to Scrubber
Network
When a network administrator detects a
Denial of Service attack, the administrator
should take steps to ensure this attack does not
take the network down. This is accomplished
using a scrubber network. A scrubber network is
an alternate network that has a large bandwidth
dedicated to monitoring malicious network. The
hosts that are deemed to send malicious traffic
are cut-off from the OpenVSwitch and are
instead directed to the scrubber network. Here,
the data can be analyzed in detail; if it is indeed
malicious, this data is discarded and the hosts are
removed from the network. Fig.5 illustrates the
inclusion of Scrubber Network in the proposed
architecture.

7. 7
Fig. 5: Scrubber Network in SDN
C. Interdisciplinary Considerations
This product is a virtual appliance which will serve as
an add-on to the existing SDN infrastructure. We are
providing two different services. First is
authentication and encryption and second is an
intrusion prevention detection system. These services
will be installed as packages on the existing SDN
infrastructure. The prices at which the package will
be sold have not yet been decided upon. Secondly,
any upgrades made to a version of the package will
be installed without any recurring costs. Support for
these services will also be provided if an Annual
Maintenance Contract (AMC) is agreed upon. The
product we are developing will be a stand-alone. The
organization planning to deploy our security
packages will not have to incur the additional costs of
having to procure any hardware from us. It is our
attempt to decouple the software and the proprietary
hardware costs that are associated with the
deployment of a network. One of our value
propositions is that we are offering services that are
not platform specific and it gives organizations the
freedom to deploy their infrastructure without having
to be vendor specific. This provides organizations
with an opportunity to lower their costs since they
can deploy servers running OpenFlow and integrate
our security package with it not having to invest in
expensive hardware. Moreover, we are going to be
developing it on a Linux box and exporting our
service as an Oracle Virtual Appliance (OVA).
V. IMPLEMENTATION AND RESULTS
To realize an OpenFlow network, we used three
virtual machines that were deployed using Virtual
Box as the testbed. The first machine was used as the
SDN switch where an Open vSwitch version 2.5.0
image was installed. Two other virtual hosts (Host 1
and Host 2) were connected to the Open vSwitch and
they ran Ubuntu 14.0.4 OS. The second machine was
used as the SDN controller with an OpenDayLight
image installed. The controller and switch machines
are running Ubuntu 14.0.4 LTS OS. We also used a
simple Ethernet Hub between the two machines that
may be used by the attacker to exploit the
vulnerabilities. Finally, we used the third machine as
a middlebox to implement the security policies like
Intrusion detection system and flow analysis. Here,
OpenVSwitch was controlled by the Open Day Light
controller using OpenFlow version 2.5.0.
A. Encryption
In the OpenFlow architecture, we use a self-signed
root CA as the centralized CA. We implement this
using OpenSSL to realize a X.509 public key
infrastructure.
First, we initialized PKI on the OpenVSwitch.
Using this, we created two sets of key, one for the
controller, and the other for the switch. OpenFlow
allows us to implement this using these commands:
ovs-pki req+sign sc switch, ovs-pki
req+sign ctl controller [57]. This generates a
public-private key pair for the controller and the
switch [57]. Next, we created a key store that acts as
a repository for the controllers key pair. We then
created a trust store that stores the switch’s public
key [57]. Once this was completed, we modified the
TLS plug-in in OpenFlow to enforce encryption
between the controller and the OpenVSwitch.
Fig.6. Implementation of security features in SDN

8. 8
A testing client is connected to another host
machine through an OpenVSwitch. The objective of
the experiment is to protect the switch and host from
denial of service attacks. This testbed comprises of
transmitting malicious traffic and non-malicious
traffic to the server simultaneously. Normal (non-
malicious) traffic is created by replaying common
TCP/UDP requests such as video streaming, file
downloads and chat applications. Malicious traffic is
generated using a python script “flood.py”, developed
specifically for this network and nmap, a port
scanning tool. We then run the following attacks:
SYN flood, ICMP flood, Xmas tree scan, ping of
death, and TCP scan. These scans send 2,000 packets
each and scan multiple ports to explore which
protocols are exposed to the network.
To maintain this type of security architecture, TLS
strongly depends on confidentiality of private keys
and local Certificate Authority trust which is highly
critical to maintain the integrity of the information.
Since OpenFlow allows implementation of latest TLS
version, it is considered to be safe against well-
known attacks such as FREAK [28] and BEAST
[29]. Theoretically transport layer security can be
breached using attacks like SSL-Striping and SSL-
Spitting [30], however, due to novelty of SDNs with
TLS-secured OpenFlow architecture, no such attacks
have been reported or researched.
B. Intrusion Detection
A testing client is connected to another host
machine through an OpenVSwitch. The objective of
the experiment is to protect the switch from denial of
service attacks. This testbed comprises of
transmitting malicious traffic and non-malicious
traffic to the server simultaneously. Non-malicious
traffic is created by replaying common TCP/UDP
requests such as video streaming, file downloads and
chat applications. Malicious traffic is generated using
a python script “flood.py”, developed specifically for
this network and nmap, a port scanning tool. We then
run the following attacks: SYN flood, ICMP flood,
ping of death, and TCP scan. These scans send
multiple packets each and scan multiple ports to
explore which protocols are exposed to the network.
We detected Denial of Service attacks by writing
snort rules that alert an administrator when it detects
malicious traffic patterns. Snort also provides default
rule sets that can be used in conjunction with user-
defined rules. Once snort was up and running, we
flooded the network using different DoS attacks.
Snort generated alerts when it detected traffic that
matched the rules that we defined. They are as
mentioned below:
04/10-03:46:39.048071 [**] [1:1000001:2]
DDos attack detected [**] [Classification:
Attempted Denial of Service] [Priority: 2]
{ICMP} 100.67.1.1 -> 100.67.1.30
04/10-03:46:40.049305 [**] [1:1000001:2]
DDos attack detected [**] [Classification:
Attempted Denial of Service] [Priority: 2]
{ICMP} 100.67.1.1 -> 100.67.1.30
04/10-03:46:41.050658 [**] [1:1000001:2]
DDos attack detected [**] [Classification:
Attempted Denial of Service] [Priority: 2]
{ICMP} 100.67.1.1 -> 100.67.1.30
The above output shows the alerts generated using
SNORT. Very high detection rate was achieved using
this security mechanism that only affects TCP/UDP
traffic. Similarly when this is implemented in a larger
network where web traffic is majority of the traffic,
these security policies are useful to scan only normal
and malicious HTTP traffic.
VI. CONCLUSION
This paper is an attempt to enhance security and
build resilient OpenFlow architecture. We studied the
different vulnerabilities associated with the control
channel of SDNs and novel solutions to mitigate the
risks by implementing security policies such as
encryption, authentication and Intrusion Detection.
This security implementation provides benefits like
network administrator control, enhanced
authentication mechanism, reduced overhead on
controller and automated alert system. Moreover, the
implementation allows network administrators to
specify pre-defined rules to automatically respond in
case of malicious traffic. The experiments reveal that
proposed architecture protects the control channel
against various IP based attacks such as Denial of
Service, man-in the middle, and eavesdropping.
REFERENCES
[1] B. A. A. Nunes, M. Mendonca, X.-N. Nguyen, K.Obraczka, and
T.Turletti, ‘A Survey of Software-Defined Networking: Past, Present,
and Future of Programmable Networks’, IEEE Communications Surveys
& Tutorials, vol. 16, no. 3, pp. 1617–1634, Feb. 2014.

9. 9
[2] K. Kirkpatrick, ‘Software -defined networking’, Communications of the
ACM, vol. 56, no. 9, pp. 16–18, Sep. 2013.
[3] K. Cabaj, J. Wytrębowicz, S. Kukliński, P. Radziszewski, and K. T.
Dinh, ‘SDN Architecture Impact on Network Security’, 2014 Federated
Conference on Computer Science and Information Systems, vol. 3, pp.
143–148, Sep. 2014.
[4] K. Benton, L. J. Camp, and C. Small, ‘OpenFlow vulnerability
assessment’, Proceedings of the second ACM SIGCOMM workshop on
Hot topics in software defined networking - HotSDN ’13, pp. 151–152,
Aug. 2013.
[5] R. Kloti, V. Kotronis, and P. Smith, ‘OpenFlow: A security analysis’,
2013 21st IEEE International Conference on Network Protocols (ICNP),
pp. 1–6, Oct. 2013.
[6] D. Kreutz, F. M. V. Ramos, and P. Verissimo, ‘Towards secure and
dependable software-defined networks’, Proceedings of the second ACM
SIGCOMM workshop on Hot topics in software defined networking -
HotSDN ’13, pp. 55–60, Aug. 2013.
[7] K. Cabaj et al., “SDN Architecture Impact on Network Security,” in
Position papers of the 2014 Federated Conference on Computer Science
and Information Systems, Warsaw, Poland, 2014, pp. 143–148.
[8] Open Network Foundation. (April 13, 2012). Software-Defined
Networking: The New Norm for Networks.
[9] Diego Kreutz, Fernando M. V. Ramos and Paulo Verissimo, “Towards
Secure and Dependable Software-Defined Networks,” in HotSDN '13
Proceedings of the second ACM SIGCOMM workshop on Hot topics in
software defined networking, ACM SIGCOMM, NY, USA, 2013, pp.
55-60
[10] Antoine Feghali, Rima Kilany and Maroun Chamoun, “SDN Security
Problems and Solutions Analysis,” in International Conference on
Protocol Engineering (ICPE) and International Conference on New
Technologies of Distributed Systems (NTDS), Paris, France, 2015, pp.
1-5.
[11] Wen, Xitao, et al. "Towards a secure controller platform for openflow
applications. Proceedings of the second ACM SIGCOMM workshop on
Hot topics in software defined networking. ACM, 2013.
[12] Scarfone, Karen, and Peter Mell. "Guide to intrusion detection and
prevention systems (idps)." NIST special publication 800.2007 (2007):
94.
[13] Sakir Sezer et al., "Are We Ready for SDN? Implementation Challenges
for Software-Defined Networks," in IEEE Commun. Mag., vol. 51,
issue 7, Jul 2013, pp. 36 – 43
[14] P. Porras, S. Shin, V. Yegneswaran, M. Fong, M. Tyson, and G. Gu, ‘A
security enforcement kernel for OpenFlow networks’, Proceedings of the
first workshop on Hot topics in software defined networks - HotSDN
’12, pp. 121–126, Aug. 2012.
[15] Seugwon Shin et al., "FRESCO: Modular Composable Security Services
for Software-Defined Networks," in NDSS Symposium, 2013, San
Diego, CA
[16] Sandra Scott-Hayward, Gemma O’Callaghan and Sakir Sezer, "SDN
Security: A Survey," in Workshop on Software Defined Networks for
Future Networks and Service, Trento, Italy, 2013, pp. 1 – 7
[17] Xenofon Foukas, Mahesh K. Marina and Kimon Kontovasilis. Software
Defined Networking Concepts [Online]. Available FTP:
http://homepages.inf.ed.ac.uk/ Directory: mmarina/papers/ File: sdn-
chapter.pdf
[18] R. Holz et al. “X.509 Forensics: Detecting and Localising the
SSL/TLS Men-in-the-Middle”. In: Computer Security. LNCS. 2012
[19] Vipul Gupta et al., “Performance Analysis of Elliptic Curve
Cryptography for SSL,” in WiSE '02 Proceedings of the 1st ACM
workshop on Wireless security, NY, USA, 2002, pp. 87-94
[20] Kulkarni, Vikram, and Jayesh Kawli. "Analysis of OpenFlow
Networks."
[21] Bob Lantz, Brandon Heller, and Nick McKeown. A network in a laptop:
“Rapid prototyping for software-defined networks”. In HotNets, pages
1– 6, 2010
[22] Shalimov, Alexander, et al. "Advanced study of SDN/OpenFlow
controllers."Proceedings of the 9th Central & Eastern European
Software Engineering Conference in Russia. ACM, 2013.
[23] D. Cooper and rfcmarkup version 1, "Internet X.509 public key
infrastructure certificate and certificate revocation list (CRL) profile,"
2008. [Online]. Available: https://tools.ietf.org/html/rfc5280#.
[24] T. D. <tim@> and rfcmarkup version 1, "The transport layer security
(TLS) protocol version 1.2," 2008. [Online]. Available:
https://tools.ietf.org/html/rfc5246.
[25] R. Holz, L. Braun, N. Kammenhuber, and G. Carle, "The SSL
landscape," ACM, 2011, pp. 427–444. [Online]. Available:
http://dl.acm.org/citation.cfm?id=2068856.
[26] "The public key infrastructure approach to security," 2001. [Online].
Available:
https://docs.oracle.com/cd/B10501_01/network.920/a96582/pki.htm.
[27] Microsoft, "Public key infrastructure," 2016. [Online]. Available:
https://msdn.microsoft.com/en-
us/library/windows/desktop/bb427432%28v=vs.85%29.aspx.
[28] T. Duong and J. Rizzo, “Here come the ninjas,” Unpublished
manuscript, 2011, p. 4. [29] D. Goodin, “Crack in internets foundation
of trust allows https session hijacking,” Ars Technica, 2012, pp. 1–2.
[29] M. Marlinspike, “New tricks for defeating ssl in practice,” BlackHat
DC, February, 2009, pp. 1–11a

10. 10