Journal of Network and Computer Applications 68 (2016) 126–139

Contents lists available at ScienceDirect

Journal of Network and Computer Applications

journal homepage: www.elsevier.com/locate/jnca

Review

A survey on OpenFlow-based Software Defined Networks: Security

challenges and countermeasures
Wenjuan Li a, Weizhi Meng a,b,n,1, Lam For Kwok a
a
Department of Computer Science, City University of Hong Kong, Hong Kong SAR, China
b
Infocomm Security Department, Institute for Infocomm Research, Singapore

art ic l e i nf o a b s t r a c t

Article history: Software-Defined Networking (SDN) has been proposed as an emerging network architecture, which
Received 6 December 2015 consists of decoupling the control planes and data planes of a network. Due to its openness and stan-
Received in revised form dardization, SDN enables researchers to design and implement new innovative network functions and
12 April 2016
protocols in a much easier and flexible way. In particular, OpenFlow is currently the most deployed SDN
Accepted 14 April 2016
concept, which provides communication between the controller and the switches. However, the dyna-
Available online 19 April 2016
mism of programmable networks also brings potential new security challenges relating to various attacks
Keywords: such as scanning, spoofing attacks, denial-of-service (DoS) attacks and so on. In this survey, we aim to
Software-Defined Networking give particular attention to OpenFlow-based SDN and present an up-to-date view to existing security
OpenFlow
challenges and countermeasures in the literature. This effort attempts to simulate more research at-
Control and data planes
tention to these issues in future OpenFlow and& SDN development.
Security challenges and countermeasures
Review and survey & 2016 Elsevier Ltd. All rights reserved.

Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
2. Background of SDN and OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
2.1. Software-Defined Networking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
2.2. OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
3. Security challenges for openflow-based SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
3.1. Switch-related security challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
3.2. Controller-related security challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
3.3. Channel-related security challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
3.4. Discussions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
4. Openflow-based SDN enhancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
4.1. Countermeasures for switch-related security challenges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
4.2. Countermeasures for controller-related security challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
4.3. Countermeasures for channel-related security challenges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
4.4. Further discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
5. Future directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

n
Corresponding author at: Infocomm Security Department, Institute for Infocomm Research, Singapore.
E-mail addresses: [email protected] (W. Li), [email protected], [email protected] (W. Meng), [email protected] (L.F. Kwok).
1
Previously known as Yuxin Meng.

http://dx.doi.org/10.1016/j.jnca.2016.04.011
1084-8045/& 2016 Elsevier Ltd. All rights reserved.
 W. Li et al. / Journal of Network and Computer Applications 68 (2016) 126–139 127

1. Introduction Traditionally, when a data packet arrives at a switch, this switch

mainly checks the packet's destination and forwards it according
With the development of computer networks, current network to the pre-defined rules. All packets going to the same place are
systems and data centers are becoming more and more feature- routed along the same path and treated in the same way. By
rich, complex and data excessive, so that the system designers contrast, in an OpenFlow-based SDN, researchers can add to,
often need to modify network software and orchestrate computer subtract from, and otherwise meddle with these rules. Due to
and network resources according to the specific requirements. these advantages, OpenFlow-based applications become popular
However, traditional network architectures are ill-suited to fulfill and have been studied in many areas such as VLAN (Yamasaki
the above requirements from enterprises, carriers, and end users. et al., 2011), wireless sensor networks (Luo et al., 2012), cellular
For instance, the decision-making capability of legacy networks is networks (Li et al., 2012), mobile network (Pentikousis et al.,
distributed across various network components, making a tedious 2013), Telecom domain (Hampel et al., 2013), intrusion detection
job of adding any new network devices or services (Jammal et al., (Mehdi et al., 2011) and so on.
2014). As a result, network management and configuration are Overall, SDN provides highly programmable switch infra-
becoming extremely laborious and error-prone. structures and computes optimal flow routing rules from remote
In order to overcome these limitations, Software-Defined Net- users to virtually spawned computing resources (Porras et al.,
working (SDN) is developed by network research community, 2012). However, as the network expands both in the number of
where network control is decoupled from the forwarding me- switches and the number of end hosts, the SDN controller may
chanism and can be directly programmable (Open Networking become a key bottleneck. For example, Tavakoli et al. (2009) es-
Foundation, 2012). That is, by decoupling the control logic from timated that a big data center which was composed of 2 million
the individual network devices into accessible computing devices, virtual machines may generate up to 20 million flows per second.
SDN makes more of the network system components program- Then, Benton et al. (2013) introduced some specific attacks for
mable and provides unified controls to the applications, such that OpenFlow such as man-in-the-middle and denial of service risks.
researchers, system designers and administrators can design new Some practical examples of how SDN can be both used and mis-
network functions and protocols in a much easier and flexible way. used were described in Crenshaw (2012). Thanks to these efforts,
A comparison between the legacy infrastructure and the SDN security challenges and issues of SDN have gained considerable
infrastructure is depicted in Fig. 1. attention from both researchers and practitioners (Kreutz et al.,
Generally, SDN relies on the fact that the simplest function of a 2013).
switch is forwarding packets based on a set of rules. One objective In this paper, we survey existing research efforts relating to
of SDN is to perform network tasks, which cannot be completed both security challenges and promising solutions for OpenFlow-
without additional software, by providing open user-controlled based SDN. In the literature, many SDN-related survey papers are
management of the forwarding hardware of a network element. available regarding SDN and its evolution (Farhady et al., 2015;
Another objective is to distribute part of the network complexity Hakiri et al., 2014; Hu et al., 2014; Jammal et al., 2014; Jagadeesan
from the hardware-based network devices to the software-based and Krishnamachari, 2015), whilst only a few surveys focus on
controller (Lara et al., 2014). To summarize, the major merit of SDN security issues (Alsmadi and Xu, 2015; Scott et al., 2013). Among
is logically constructing a centralized controller through the se- them, Scott et al. (2013) in 2013 first discussed several security
paration of control plane and data plane, which enables the cen- challenges in SDN without an analysis model. Additionally, they
tralized control and simplifies network management. did not provide a discussion of the potential countermeasures.
To date, the most deployed SDN concept is OpenFlow, which is Then, Alsmadi and Xu (2015) conducted a survey on SDN security
a communication protocol that gives access to the forwarding by means of STRODE threats model, which is the most related
plane of a network switch or router over the network (Too- work. But they did not give a detailed analysis of OpenFlow se-
toonchian and Ganjali, 2010). This standard essentially opens up curity. Different from them, in this paper, we provide a new se-
the Internet to researchers, allowing them to define data flows curity analysis based on the CIA triad and focus on OpenFlow-
through software, giving engineers’ access to flow tables, and de- based SDN, because OpenFlow is prominently successful and
signing rules to guide switches how to direct network traffic. It is others are not as successful in practice (i.e., have not been adopted
also able to protect the proprietary routing instructions that dif- by the major router vendors) (Farhady et al., 2015). As a result, the
ferentiate one company's hardware from another (Greenk, 2009). analysis model and emphasis differentiate our work from others

Applications Applications

Network Management Network Management

(e.g.,Firewalls, Policies) (e.g.,Firewalls, Policies)

Control Plane Control Plane Control Plane

Data Plane Data Plane Data Plane Data Plane Data Plane

(a) Legacy Infrastructure (b) SDN Infrastructure

Fig. 1. A comparison between (a) the legacy infrastructure and (b) the SDN infrastructure.
128 W. Li et al. / Journal of Network and Computer Applications 68 (2016) 126–139

Table 1
Main SDN interfaces (it is worth noting that east–westbound APIs are mainly used in distributed SDN architectures).

Terms Description

Northbound APIs These APIs offer the software interfaces between the application layer and the control layer, through providing universal data and functionality for
network applications.
Southbound APIs These APIs offer the software interfaces between the control layer and the infrastructure layer, and OpenFlow is the most popular southbound
interface.
Eastbound APIs These APIs are able to interconnect traditional IP networks with SDN networks, which often demand a translation module in-between.
Westbound APIs These APIs are able to provide information between multiple SDN controllers in different domains, and enable management of distributed SDN
architecture.

like (Alsmadi and Xu, 2015; Scott et al., 2013). Our work aims to into user-definable software. As shown in Fig. 1, the difference
complement the existing SDN security surveys and provide an up- between SDN and traditional networks is that a software compo-
to-date view in this area. nent running on a server or a CPU is added to the architecture of
The remaining parts of this paper are organized as follows. the network, where the software component is used as the control
Section 2 introduces the background of both SDN and OpenFlow. plane of the network. This centralized control server can enable
Then, Section 3 surveys security challenges and issues for Open- dramatically simplified and flexible network programming. It can
Flow-based SDN and Section 4 surveys existing promising coun- enhance the benefits of data center virtualization, increasing re-
termeasures in defending against these security challenges and source flexibility and utilization, and reducing infrastructure costs
enhancing the robustness of SDN. Later, Section 5 discusses several and overhead.
future research directions in this area. Finally, Section 6 concludes More specifically, the three-layer architecture of SDN is de-
this paper. picted in Fig. 2, including application layer, control layer and in-
frastructure layer. Application layer can enforce its policies with-
out a direct interaction with the infrastructure layer, through the
2. Background of SDN and OpenFlow northbound API that is supported by the control layer. On the
other hand, the interactions between the control layer and infra-
There is a misconception that SDN and OpenFlow are equiva- structure layer are supported by the southbound APIs. Logically,
lent. In fact, SDN is an emerging network architecture in which the network management is centralized in software-based SDN con-
network control is decoupled from forwarding and is directly trollers. Therefore, the network is able to act as a single and logical
programmable, while OpenFlow is a foundational element for SDN switch to both the applications and the policy engines. Under this
and it is the first standard interface of communications defined architecture, the underlying physical network and the topology are
between the control and forwarding layers of a Software-Defined hidden to users. Due to this design, enterprises can gain in-
Network architecture. Another possible reason for such mis- dependent control over the entire network from a single logical
conception is that SDN was coined after the design of OpenFlow point, which greatly simplifies the network design and operations.
(Greenk, 2009). Thus, this section illustrates the architecture of By centralizing network states in the control layer, a system
SDN and OpenFlow to ensure a better understanding. designer or network administrator in the application layer can
react to network events in real-time and deploy new applications
2.1. Software-Defined Networking and services more quickly. This architecture also supports a set of
APIs that make it possible to realize common network services,
Software-Defined Networking (SDN) consists of a set of un- like routing and multicast, to meet individual and business ob-
derlying programmable switches and a cluster of control entities, jectives. Thus, with the implemented APIs between the SDN con-
attempting to migrate as many network functionalities as possible troller and the application layer, business applications can operate
on an abstraction of the network in leveraging network services
and capabilities without being tied to the details of their specific
Application Layer implementation (Open Networking Foundation, 2012). For in-
stance, when a new flow reaches an SDN switch, this switch can
Business Applications send a route request to the centralized controller for the next
forwarding path. The controller computes a routing path and
API API distributes the forwarding rule to all relevant switches through a
Northbound APIs secure channel. As a result, all relevant switches can update their
flow tables. The main SDN interfaces are summarized in Table 1.
Westbound APIs

Eastbound APIs

Control Layer
Overall, SDN is able to manage the entire network through
SDN Controller maintaining a global view and provide many benefits (e.g., on-
Network Services demand resource allocation, secure cloud services, and virtualized
networking). More specifically, one feature of the SDN is the
capability to provide a wide abstraction of network. The abstrac-
Southbound APIs
(e.g., OpenFlow)
tion enables SDN providing an easier way to configure a service or
device by hiding the complexity of the network. The devices
Infrastructure Layer themselves can only accept instructions from the controllers
without understanding and processing thousands of protocol
Network Device Network Device standards. Another feature of the SDN is that it enables innovation
and flexibility. The reason is obviously that the hardware-based
devices are usually hard to modify while the software-based
Fig. 2. The three-layer architecture of SDN. controller is easier to make a change and interaction.
 W. Li et al. / Journal of Network and Computer Applications 68 (2016) 126–139 129

OpenFlow switch. These switches are managed by OpenFlow

Control Plane controllers over a secure channel using the OpenFlow protocol.
A switch often consists of one or more flow tables that performs
Controller Controller packet lookup and forwarding. In particular, a flow table is
composed of a list of flow entries while each entry contains
header fields, counters and actions. Header fields are used to
… match against packets and contain information such as VLAN ID,
source and destination ports, IP address and so on. Counters are
mainly used to keep statistics about packets such as the number
of packets, the number of bytes and so forth. Actions give in-
structions on how to process and match packets in a flow, such
as forward to a given port, forward to a controller and drop the
OpenFlow OpenFlow packet (Open Networking Foundation, 2012).
Protocol Protocol
OpenFlow channel. This channel acts an interface to connect
OpenFlow switches and OpenFlow controllers. Through this
interface, the controller configures and manages the switch,
Open Flow Switch Open Flow Switch receives events from the switch, and sends packets out the
switch. Three main types of messages can be sent through this
channel: controller-to-switch, asynchronous and symmetric.
Controller-to-switch messages are sent by the controllers to di-
OpenFlow OpenFlow rectly manage and inspect the state of the switch. Asynchronous
Channel Channel messages are sent by the switch to update the controller about
network events and changes to the switch state. Symmetric
… messages can be initiated by either the switch or the controller
Flow Table Flow Table and sent without solicitation.

OpenFlow controller. This centralized controller is responsible for
maintaining, distributing and updating policies and instructions
to the network devices. It can determine how to handle packets
Fig. 3. Basic OpenFlow components and communications. without valid flow entries, and can manage the switch flow
table by adding or removing flow entries over the secure
2.2. OpenFlow channel. In addition, an OpenFlow switch can establish con-
nection and communication with one or multiple controllers. A
OpenFlow is defined by the Open Networking Foundation multiple-controller architecture can improve network reliability
(ONF) as the first standard interface of communications between when one switch fails to response. When OpenFlow operations
the control and the infrastructure layer of an SDN architecture. It start, the switch should connect to all its configured controllers
provides a means to control a switch without requiring the ven- at the same time, whereas relevant messages can only be sent
dors to disclose any source code of their devices. In other words, to the corresponding switch. Table 2 summarizes a list of
OpenFlow-based controllers.
OpenFlow allows direct access and manipulation of the forwarding
plane of network devices such as switches and routers, both
To sum up, an OpenFlow switch might include multiple flow ta-
physical and virtual (Open Networking Foundation, 2012). For in-
bles while each flow table can contain many flow entries. According
stance, it provides access to the flow table and instructs switches
to a flow table, the switch can look up its flow entries and make
how to direct network traffic. In this case, network managers can forwarding decisions for incoming packets. For each packet, the
change network flows in a short period. According to Jammal et al. switch aims to find an exact matching entry. If a match is identified,
(2014), there are two major types of OpenFlow-based switches: the corresponding instructions can be executed. The packet is mat-
OpenFlow-only and OpenFlow-hybrid. The former can only sup- ched against the table and only the highest priority flow entry that
port OpenFlow operations, whereas the latter can support both matches the packet must be selected. If there are multiple matching
OpenFlow operations and normal Ethernet switches. flow entries with the same highest priority, the selected flow entry is
As illustrated in Fig. 3, OpenFlow is mainly composed of three explicitly undefined. On the other hand, if a packet does not match
components: OpenFlow switch, OpenFlow channel and OpenFlow any flow entry in any flow tables (which is called “table-miss”), this
controller. packet can be sent to the controller or be dropped.

Table 2
A list of OpenFlow controllers written in C þ þ, java and Python.

Controller Description

NOX (Gude et al., 2008) The first OpenFlow controller, which is written in C þ þ.
SNAC (https://github.com/bigswitch/snac) It is a graphical-interface-supported OpenFlow controller, which is written in C þ þ.
RouteFlow (https://sites.google.com/site/routeflow/home) It aims to provide virtualized IP routing services over OpenFlow enabled hardware (based on Cþ þ ).
Maestro (http://zhengcai.github.io/maestro-platform/) A scalable control platform written in Java which supports OpenFlow switches.
Beacon (https://openflow.stanford.edu/display/Beacon/Home) It is a cross-platform and Java-based OpenFlow controller supporting both event-based and threaded
operation.
Floodlight (http://www.projectfloodlight.org/floodlight/) It is an enterprise-class, Apache-licensed, Java-based OpenFlow Controller.
IRIS (https://github.com/bjlee72/IRIS) It is the Openflow-based recursive SDN Openflow controller.
Jaxon (http://jaxon.onuos.org/) It is an OpenFlow controller and works with NOX Classic.
POX (https://github.com/noxrepo/pox) It is a networking software platform written in Python.
Ryu (https://github.com/osrg/ryu) It is a component-based software defined networking framework.
130 W. Li et al. / Journal of Network and Computer Applications 68 (2016) 126–139

From version 1.1, OpenFlow supports multiple flow tables and

pipeline processing. Pipeline processing enables packets to be sent
to subsequent tables for further processing and allows information
Open Flow Controller
to be communicated between tables. Table pipeline processing
stops when the instruction set associated with a matching flow
entry does not specify the next table; at this point the packet is
usually modified and forwarded. To date, various OpenFlow ver- Secure
Policy
sions have been released (i.e., started from version 1.0) (OpenFlow Channel

Switch Specification version 1.5.0, 2014).

Attacker

Open Flow Switch

3. Security challenges for openflow-based SDN

OpenFlow is a leading reference implementation of the SDN.

However, by decoupling the control plane into a centralized ap- (a)
plication, the SDN controller itself is likely to become a key bot-
tleneck. In addition, OpenFlow itself may introduce many potential
Controller
security challenges to the network security community (Kloeti
et al., 2013). In Fig. 4(a), we depict the potential attacking targets
for OpenFlow-based SDN from the perspective of intruders.
In this section, we mainly focus on the identification of po-
tential security challenges for OpenFlow-based SDN, through re-
ferring to existing research efforts in the literature. It is worth OpenFlowSwitch
noting that current attacks on SDN have become more compli-
Target Network
cated, which can include attack vectors across OpenFlow con- OpenFlow
Channel
troller, switch and channel. To keep simplicity, we introduce the Source
Network
security challenges based on the three major assets in a typical Flow Table
OpenFlow-based SDN: switch-related, controller-related and
Insert Adverse
channel-related challenges. Rules

Moreover, we will employ the CIA triad model to evaluate those

challenges in terms of confidentiality, integrity and availability
(Perrin et al., 2012). In this context, confidentiality is a set of rules
(b)
that limits access to information, integrity is the assurance that the Controller
information is trustworthy and accurate, and availability is a
Attack
guarantee of reliable access to the information by authorized
people.
Request Response

3.1. Switch-related security challenges

OpenFlowSwitch
The switch-related security challenges mainly refer to vulner-
abilities at the switch level (data plane), where attackers may OpenFlow
Target Network
utilize to compromise the SDN. OpenFlow switch and flow table Source Channel
Network
are likely to become a major target, since they contain information
Flow Table
related to network management, routing and access control. More
specifically, attackers can target the network elements within the
network itself. An attacker can first attempt to gain unauthorized (c)
physical or virtual access to the network, or compromise a host
that is already connected to the SDN, and then try to perform at- Controller

tacks to destabilize the network elements.

For example, attackers may try adversely inserting some mal-
icious flow rules to a flow table, causing the whole security me-
MITM Attacker
chanism to be compromised. In addition, through flooding the
flow table with a large number of useless flow rules, the data plane OpenFlow Switch
might be unable to store normal flow rules and response to nor-
mal requests. One example of inserting malicious rules is de- OpenFlow
Channel
scribed in Fig. 4(b). We discuss these security challenges according Source Target Network
Network
to the CIA triad as below. Flow Table

Confidentiality. At the switch level, confidentiality means to

preventing sensitive information (e.g., switch data and flow (d)
table) from disclosure to unauthorized parties. It is noted that
Fig. 4. (a) Potential attacks for OpenFlow-based SDN. (b) A case of security chal-
attackers may try various approaches to infer interested in- lenges at the switch level: inserting malicious rules. (c) A case of security chal-
formation such as scanning, spoofing, hijacking and so on. lenges at the controller level: DoS attacks. (d) A case of security challenges at the

Integrity. At this level, integrity refers to protecting elements' channel level: man-in-the-middle attacks.
 W. Li et al. / Journal of Network and Computer Applications 68 (2016) 126–139 131

information from being modified by unauthorized parties, example, attackers can take advantage of replay attacks to ele-
where elements here include switch itself, flow tables and vate privilege, which can spoof and hijack switches or devices.
hosts. OpenFlow switch allows us to update its flow table by
adding or removing flow rules; however, control policy is 3.2. Controller-related security challenges
usually not implementation-specified and enhanced in such
network, which may open a hole for attackers. The controller-related security challenges mainly refer to vul-

Availability. In the data plane, availability refers to ensuring that nerabilities at the controller level, in which attackers can utilize to
authorized parties are able to access the switch and related compromise the CIA triad of SDN. The programmability of SDN
information when needed. As flow tables are an important controllers presents a double-edged sword. As SDN separates the
element in an OpenFlow switch, which contain a list of flow control plane from the data plane to enable a centralized con-
rules to specify the operations, attackers may compromise it troller to deal with all incoming network flows, the controller itself
through various intrusions like denial-of-service (DoS) attacks. is likely to become a key bottleneck for SDN and a major target for
various attacks such as flooding attacks and denial-of-service
At the switch level, attackers may compromise the above CIA (DoS) attacks.
aspects through malicious actions and inputs such as scanning, For example, the data plane in the SDN has to ask the control
spoofing and so on. plane to obtain flow rules when it receives unseen network
packets (as it does not know how to manage). Thus, attacking the
1. Scanning. Scanning can be used by attackers as the first step to control plane can cause it to be unavailable to response to the
know the basic information about the whole network (e.g., to- requests from the data plane. An example can be illustrated in
pology) and prepare necessary knowledge for inferring sensitive Fig. 4(c). We discuss these challenges based on CIA triad as follows.
information. Attackers can sniff network information such as
topology, hosts’ features and communication details between
Confidentiality. At the controller level, confidentiality means to
switches and hosts. It is often used by attackers as the first step preventing sensitive information (e.g., controller data, rules and
to launch a large attack (e.g., DoS attacks). policies) from disclosure to unauthorized parties.
2. Spoofing. This kind of attack refers to intruders successfully
Integrity. Regarding the controller, integrity refers to protecting
masquerade as another (e.g., switch or host), by falsifying data controller's information from being modified by unauthorized
and thereby gaining an illegitimate advantage. At present, parties, or controller's policy from being adversely tuned.
spoofing attacks in SDN mainly include Address Resolution OpenFlow controller should maintain many flow rules and
Protocol (ARP) spoofing and IP spoofing. In particular, ARP firewall rules; however, attackers may orchestrate several rules
spoofing aims to associate the attacker's MAC address with the to bypass the detection.
IP address of a legitimate host (Feng et al., 2012). On the other
Availability. At the control plane level, availability refers to en-
hand, IP spoofing is the creation of Internet Protocol (IP) packets suring that authorized parties are able to access the controller
with a legitimate source IP address. for requested information when needed. SDN controller pre-
3. Hijacking. This type of attack aims to take control of a commu- sents a double-edged sword, because it is both a central point of
nication element, which is much stronger than spoofing attacks influence in a network and a potential central point of failure.
(as intruders can totally control an element rather than im- Thus, attackers may compromise SDN by conducting denial-of-
personation). In OpenFlow-based SDN, if attackers successfully service (DoS) attacks to the controller (Dover, 2013).
hijack the switch, they can know all flow rules and commu-
nication data (Hong et al., 2015). On the other hand, if attackers Similar to switches, at the controller level, attackers may con-
hijack any host, they can impersonate a legitimate user and duct various malicious behaviors and intrusions such as scanning,
infer communication data from other hosts (e.g., tokens and spoofing, hijacking and so on.
passwords).
4. Tampering. This type of attack refers to unauthorized modifica- 1. Scanning. Similar to attacking switches, scanning can be used by
tion of network information (i.e., modifying flows in flow ta- attackers as the first step to understand the whole network (e.g.,
bles). As shown in Fig. 4(b), attackers can insert malicious flow topology) and prepare for inferring sensitive information at the
rules that may cause network misbehavior. Hong et al. (2015) controller level. Attackers can further sniff network information
presented an attack of Fake LLDP Injection, in which an through the controller.
adversary generates fake LLDP packets into an OpenFlow net- 2. Spoofing. If attackers successfully conduct this type of attack,
work to announce bogus internal links between two switches. they can impersonate as the controller. Then, attackers can
By monitoring the traffic from OpenFlow switches, the adver- create entries in the flow tables of network elements and the
sary can obtain the genuine LLDP packet. SDN engineers would not have visibility to those flows from the
5. Denial-of-service (DoS) attack. This type of attack attempts to perspective of the production controller. In this case, attackers
make a network resource unavailable to its intended users, would have complete control of the network.
which includes flooding, Smurf and DNS amplification (Yao 3. Hijacking. At the control plane, if attackers successfully hijack
et al., 2011). Attackers may flood many legitimate flows to the controller, they can infer any sensitive information freely
OpenFlow switch, causing flow tables unable to store other such as passwords, communication data and so forth. They can
flows coming from other network elements. It is worth noting also tamper or modify any data and redirect traffic to any des-
that such attacks can be conducted at the switch level or the tinations. In this case, OpenFlow-based SDN will be completely
flow table level. For example, Shin and Gu (2013) studied such compromised. For example, Hong et al. (2015) proposed an
kind of DoS attacks, named data plane resource consumption, by attack called host location hijacking attack, which can spoof the
faking flow requests to cause lots of useless rules that need to identity of a target host to hijack its location information inside
be handled by a data plane. This type of attack is the major OpenFlow controllers.
threat to availability, but it sometimes needs some supports 4. Tampering. Similar to tampering attacks at the data plane, the
from other intrusions such as scanning, spoofing, etc. attacker would want to instantiate new flows at the controller
6. Other attacks. In addition to the typical attacks above, intruders by either spoofing northbound API messages or spoofing
can utilize relevant vulnerabilities to achieve the same goals. For southbound messages toward the network devices. If an
132 W. Li et al. / Journal of Network and Computer Applications 68 (2016) 126–139

attacker successfully tampers flows from the legitimate con- 3.3. Channel-related security challenges
troller, then he/she would have the ability to allow traffic to
flow across the SDN at their will and possibly bypass security The channel-related security challenges mainly refer to vul-
policies. nerabilities at the channel level, where attackers can utilize to
compromise the SDN. Note that channel includes the commu-
A concrete example of tampering is dynamic flow tunneling: an nication between the components and the administrators.
attacker might try to orchestrate several rules, where no single One key challenge for OpenFlow-based SDN is that no appro-
flow violates any firewall rules but they can indeed violate firewall priate trust mechanism between controllers and switches, which
rules in a collaborative way. Porras et al. (2012) designed such an opens a hole for attackers to compromise the security by inter-
attack and indicated that OpenFlow controller can generate opti- ception. Fig. 4(d) illustrates one of such challenges: man-in-the-
mal flow routing rules from remote clients to virtually spawned middle (MITM) attacks, where an attacker secretly relays and
computing resources. As the state of an OpenFlow switch should possibly alters the communication between two parties who be-
be reprogrammed to address the current flows, it is very difficult lieve they are directly communicating with each other. We discuss
to predict the new policy. The main challenge is that as different these security challenges based on CIA triad as below.
control policies (or rules) may be inserted by various applications

Confidentiality. For the OpenFlow channel, confidentiality means
and users dynamically, it is hard to guarantee that these inserted
to providing a secure communication between controllers and
policies or rules are not in conflict with each other.
switches, and defending against the disclosure of sensitive in-
An example of dynamic flow tunneling is given by Porras et al.
formation to unauthorized parties.
(2012). Suppose there are three hosts:

Integrity. At the channel level, integrity refers to ensuring that
the transmitted information is consistent, accurate, trustworthy
(1) Source host: 10.0.0.2
and non-repudiate.
(2) Target host1: 10.0.0.3

Availability. For the OpenFlow channel, availability refers to en-
(3) Target host2: 10.0.0.4
suring that authorized parties like controllers and switches are
able to access each other when needed.
For the firewall, assuming that there exists one rule: blocking
network packets from the source host to the web service (port 80)
At the channel level, attackers may perform various attacks to
running on the target host2, and that some OpenFlow applications
infer sensitive information, such as man-in-the-middle attacks,
aim to insert three new flow rules to the OpenFlow controller as
monitoring, repudiation and so on.
below:
1. Man-in-the-middle (MITM) attacks. Without robust trust me-

Modifying the source IP address of a packet to 10.0.0.1, if this chanism, MITM attacks are feasible and effective. This type of
packet is sent from 10.0.0.2 to 10.0.0.3 (port 80). attack is able to compromise all the CIA aspects. For example,

Modifying the destination IP address of a packet to 10.0.0.4, if attackers can impersonate the legitimate elements and send
this packet is sent from 10.0.0.1 to 10.0.0.3 (port 80). inaccurate information across the network. In addition, attack-

Forwarding a packet from 10.0.0.1 to 10.0.0.4 at port 80. ers can impersonate another party but do not response to any
request, causing the paralysis of the entire network.
Thus, if the source host of 10.0.0.2 sends a packet to the target In the literature, Lara et al. (2014) specified a situation that
host1 at port 80, this packet can bypass the firewall as it is not OpenFlow specification allows but not forcibly to use Transport
directly sent to the target host2 but target host1. Specifically, we Layer Security to secure the communication of the SDN net-
use a pair of {source IP, destination IP} to explain this case. Initially, works. In this case, it is possible for the controller and the
this pair is {10.0.0.2, 10.0.0.3}, after arriving at OpenFlow con- OpenFlow switches to use plaintext traffic. What is worse, even
troller, this pair will be modified as {10.0.0.1, 10.0.0.4}. Based on if the traffic is encrypted, the man-in-the-middle attack is still
the last flow rule of forwarding, the packet from the source feasible between switches and controller (Benton et al., 2013).
10.0.0.2 can get to the target host2 of 10.0.0.4. This is an example In this case, an attacker can intercept the traffic to compromise
showing that it is feasible to evade a firewall or an OpenFlow- the security and privacy of an SDN network, whereas the
based application by simply adding a few flow rules. network is hard to identify and response to it.
2. Network monitoring. Under this attack, intruders can try to
5. Denial-of-service (DoS) attack. An attacker might try to perform monitor the OpenFlow channel and learn the communicated
a DoS attack to the controller or use other means to cause the data between the switches and controllers. This type of attack
controller to fail. For example, attackers may try some forms of can also be realized by MITM attacks. On the other hand, Shin
resource consumption attacks on the controller to bog it down, et al. (2013) pointed out that OpenFlow offers very limited
cause it to respond extremely slowly to incoming packets, and support for network monitoring, which makes it become very
make it slow to send messages out. Shin and Gu (2013) difficult for many security applications to learn and retrieve
demonstrated a feasible and effective DoS attack to SDN net- (critical) changes in network traffic patterns. In this case, these
works, which contains two steps. (1) To fingerprint whether a security applications cannot detect and identify an attack
given network uses SDN/OF switches. The identification of a effectively and efficiently.
SDN switch is based on the observation that the response times 3. Repudiation. This situation means that an entity denies to be
for a receiving packet may be different since the flow setup time involved in a communication. As a result, non-repudiation ap-
can be added in the case of new flow. (2) To generate crafted pears so as to ensure such denial does not occur. This issue can
flow requests from the data plane to the control plane. also be caused by MITM attacks, through hijacking the channel
6. Other attacks. There are other attacks that can be used to com- between two parties and persuading that they are the other
promise the confidentiality, integrity and availability of SDN party.
such as replay attacks, privilege elevation and so on. Those at- 4. Other attacks. Many other attacks like replaying attacks can fa-
tacks can utilize relevant vulnerabilities at the controller level to cilitate the success of MITM attacks. The OpenFlow applications
achieve the same purpose. with possible vulnerabilities can be exploited to launch attacks.
 W. Li et al. / Journal of Network and Computer Applications 68 (2016) 126–139 133

For instance, Spoofing and hijacking attacks can be conducted to Table 3

achieve this purpose. A summary of security challenges in terms of confidentiality, integrity and
availability.

3.4. Discussions Our category CIA triad Attacks

Switch-related Confidentiality Scanning, spoofing, hijacking, re-

As compared with traditional networks, OpenFlow-based SDN challenge playing attacks, etc.
is an emerging architecture, which separates the control plane Integrity Tampering, hijacking, replaying at-
from the forwarding plane to support virtualization. With the ra- tacks, etc.
Availability Scanning, DoS, etc.
pid development and increasing adoption, it has already become a
big target for attackers. There are three major components in such Controller-related Confidentiality Scanning, spoofing, hijacking, re-
challenge playing attacks, etc.
network: switch, controller and channel. Integrity Tampering, hijacking, replaying at-
At the switch level, there are numerous southbound APIs and tacks, etc.
protocols used for the controller to communicate with the net- Availability Scanning, DoS, etc.
work elements. Among them, OpenFlow is the most widely Channel-related Confidentiality MITM attacks, network monitoring,
adopted protocol. Other protocols include Open vSwitch Database challenge etc.
Integrity MITM attacks, repudiation, etc.
Management Protocol (OVSDB), Path Computation Element Com-
Availability MITM attacks, hijacking, etc.
munication Protocol (PCEP), Interface to the Routing System (I2RS)
and so on. Each of these protocols has their own mechanisms of
securing the communications between network elements. How- 4. Openflow-based SDN enhancement
ever, most protocols are very new and may leave a hole during the
implementation (i.e., does not implement in a secure way). For In this section, we summarize and analyze existing research
example, an attacker would like to eavesdrop on flows to check efforts in mitigating the aforementioned security challenges. These
what flows are in use and what traffic is being permitted across countermeasures are described according to OpenFlow switch,
the network. Thus, he or she can try to eavesdrop on southbound controller and channel, but it is worth noting that most current
communication between the network element and the controller. approaches in the literature can enhance more than one SDN layer
The sniffed information could be useful for a replay attack or by covering several vulnerabilities, with the purpose of defending
simply for reconnaissance purposes. increasingly advanced attacks.
At the controller level, various attacks are developed in prac-
tice. For example, controllers usually run on some Linux operating 4.1. Countermeasures for switch-related security challenges
systems, where the vulnerabilities of that OS may become vul-
nerabilities for the controller. As another example, attacking the As described earlier, OpenFlow switch is vulnerable to various
security of the northbound protocol can be a vector. There are attacks such as scanning, spoofing, hijacking, tampering, DoS and
many northbound APIs but most of them are not standardized. If so on. In order to address these security challenges, some me-
attackers could leverage the vulnerable northbound API, then the chanisms can be made to enhance the security at the switch level
attacker would have full control over the OpenFlow controller such as authorization and policy enforcement. A list of existing
network through hijacking, man-in-the-middle attacks, etc. In this efforts are given in Table 4.
case, attackers are able to create their own SDN policies and thus Spoofing defend. Validating elements' address is very im-
portant to defend against spoofing attacks. Feng et al. (2011)
gain control of the SDN environment. In addition, the OpenFlow
proposed three extensions of OpenFlow about flow table, control
controllers have to communicate with the high level applications,
mode and OpenFlow protocol and designed a commercial Open-
where attackers can use malicious applications to trick the con-
Flow-enabled router, named OpenRouter, aiming to facilitate the
troller (i.e., allowing malicious elements to join the network)
deployment of OpenFlow in production network. Xiao et al. (2013)
(Scott, 2014).
extended this idea and proposed an OpenFlow-based method of
For the OpenFlow channel, the key challenge is the lack of trust
intra-AS source address validation named O-CPF, to filter out
mechanism between the controllers and the switches. For in-
traffic with forged source IP, based on the idea of centralized
stance, Transport Layer Security (TLS) is allowed but not enforced
computing forwarding path.
to secure the communication of the SDN networks. Even worse,
In addition, Mendonca et al. (2012) introduced AnonyFlow, an
many actual controllers are not even implementing or adopting it.
in-network anonymization service designed to efficiently and
It is worth noting that ARP poisoning will become feasible, if SSL
seamlessly provide privacy to users as they communicate with
encryption is not employed between the switches and the other endpoints and services. Jafarian et al. (2012) introduced a
controllers. moving target technique called OpenFlow Random Host Mutation
In Table 3, we summarize those security challenges and related (OF-RHM) aiming to mutate IP addresses of end-hosts randomly
attacks in our discussions. Nevertheless, it is worth noting that and frequently, which can avoid being targeted by attackers. In
with the development of OpenFlow-based SDN, attacks are often addition, end hosts in OpenFlow-based SDN can be mapped to
becoming more complicated through taking advantage of the actual or physical IP addresses. Later, Bifulco and Karame (2014)
vulnerabilities across different layers. These hybrid security chal- introduced NPoL, an OpenFlow application which can be used by
lenges can largely threaten the security of such networks. For in- registered users to acquire secure location proofs from the net-
stance, hijacking and spoofing attacks can compromise more than work operator.
one aspect of the CIA triad model through attacking OpenFlow Tampering defend. This type of attack is mainly caused by the
switches and controller. It seems that this trend will continue and lack of policy enforcement. The dynamic and traffic-dependent
more advanced attacks could be designed by attackers in future to modifications induced by middleboxes make it difficult to reason
invade and compromise the OpenFlow-based SDN. Thus, effective about the correctness of network-wide policy enforcement, so
countermeasures should be designed to provide protections in there is a need of flow tracking capability to ensure consistent
different layers. policy enforcement in the presence of such dynamic traffic
134 W. Li et al. / Journal of Network and Computer Applications 68 (2016) 126–139

Table 4
A list of existing solutions for switch-related security challenges.

Work in literature Implementation Year Confidentiality Integrity Availability

Al-Shaer and Al-Haj (2010) FlowChecker 2010 √ √

Feng et al. (2011) OpenRouter 2011 √ √ √
Khurshid et al. (2012) VeriFlow 2012 √ √
Mendonca et al. (2012) AnonyFlow 2012 √ √
Jafarian et al. (2012) OF-RHM 2012 √ √
Bifulco and Karame (2014) NPoL 2014 √ √
Lara and Ramamurthy (2014) OpenSec 2014 √ √ √
Matias et al. (2014) FlowNAC 2014 √ √ √
Wang et al. (2014) OF-GUARD 2014 √ √ √
Kamisinski and Fung (2015) FlowMon 2015 √ √

modifications. Fayazbakhsh et al. (2013) argued there is a need of and aims to protect switches and controller when an attack occurs.
using flow tracking to ensure consistent policy enforcement in the Data plane cache is a machine that stores proactive flow rules,
presence of such dynamic traffic modifications. They then pro- caches table-miss packets and distinguishes fake packets from
posed FlowTags, an extended SDN architecture in which mid- normal packets. In fact, this mechanism can protect both switch
dleboxes add Tags to outgoing packets, aiming to provide the ne- and controller levels according to specific requirements (i.e., they
cessary causal context (e.g., source hosts or internal cache/miss proposed FloodGuard that can protect the controller, Wang et al.,
state). These Tags are used on switches and (other) middleboxes 2015).
for systematic policy enforcement. In addition, Matias et al. (2014) presented FlowNAC, a Flow-
Misconfiguration identification. OpenFlow makes it easier for based Network Access Control solution that allows granting users
researchers to run their own experiments by providing a virtual the rights to access the network depending on the target service
slice and configuration in real networks. Misconfiguration pro- requested. It uses a modified version of IEEE 802.1X to authenti-
blems can arise when a user writes conflicting rules for single flow cate users and service-level access control based on proactive
table or even within a path of multiple OpenFlow switches. deployment of flows. Under this context, SDN can add the ap-
FlowChecker (Al-Shaer and Al-Haj, 2010) was proposed to identify propriate granularity (fine- or coarse-grained) depending on the
intra-switch misconfiguration within a single flow table. It en- target scenario and dynamically identify the services at the data
codes tables' configuration using Binary Decision Diagrams and plane as a set of flows to enforce the adequate policy. Recently, Liu
then uses the model checker technique to model the inter-con- et al. (2016) designed a two-layer OpenFlow switch topology for
nected network of OpenFlow switches. Kamisinski and Fung implementing security policies, which considers the limitation of
(2015) focused on detection of compromised switches through flow table size in a single switch and the complexity of configuring
real-time analysis of the periodically collected reports. Two types security policies to these switches. They also introduced a safe way
of malicious behavior of compromised switches were investigated to update the configuration of these switches one by one for better
such as packet dropping and packet swapping. They then proposed load balance when traffic distribution changes.
FlowMon, a malicious switch monitoring and detection system On the whole, flow checking, software attestation and trust
using the OpenFlow protocol. For their solution, the controller management mechanisms are promising to handle those security
analyzes the collected port statistics and the actual forwarding challenges at the switch level.
paths to detect malicious switches in SDN.
The OpenFlow switch enables exciting new network function- 4.2. Countermeasures for controller-related security challenges
ality, at the risk of programming errors that make communication
less reliable. To address this issue, Khurshid et al. (2012) designed To protect the SDN controller from various threats such as DoS
VeriFlow, a separate layer between the SDN controller and net- attacks, trust models and validation mechanisms should be added
work devices aiming to dynamically check for network-wide in- to protect this key component. Several existing approaches are
variant violations when each forwarding rule is inserted. This tool summarized in Table 5.
can run in real-time, but a major weakness is that it requires a Spoofing defend. The validation of source addresses can be
complete view of the entire network, which is very difficult to performed at the controller. For example, Yao et al. (2011) pro-
achieve in practice. Sonchack et al. (2015) presented OFX, an posed a solution at the controller named Virtual source Address
OpenFlow extension framework that can provide a better tradeoff Validation Edge (VAVE), which can verify the address of external
between performance and deployability for SDN security applica- packets. Then, Matias et al. (2012) implemented an address re-
tions by allowing them to dynamically install software modules solution mapping (ARM) module in the controller, which can track
onto network switches. MAC addresses from authorized users. In this case, controllers can
Policy enforcement. Lara and Ramamurthy (2014) proposed discard ARP responses that are not validated by this module. Feng
OpenSec, an OpenFlow-based security framework that allows a et al. (2012) demonstrated a solution of intra-AS IP source address
network security operator to create and implement security po- validation with OpenRouter and showed OpenRouter is feasible to
licies written in human-readable language. The user can describe a validate the source address of a packet. Hong et al. (2015) pre-
flow in terms of OpenFlow matching fields, define which security sented TopoGuard, a security extension to the OpenFlow con-
services must be applied to that flow (deep packet inspection, trollers, which provides automatic and real-time detection of
intrusion detection, spam detection, etc.) and specify security le- Network Topology Poisoning Attacks. The evaluation on the
vels that define how OpenSec reacts if malicious traffic is detected. Floodlight controller showed that TopoGuard can effectively se-
Then, Wang et al. (2014) introduced OF-GUARD, a scalable, effi- cure network topology while introducing a minor impact on nor-
cient and lightweight framework for SDN networks to prevent mal operations of OpenFlow controller.
data-to-control plane saturation attack by using packet migration DoS migration. Regarding this issue, Tootoonchian and Ganjali
and data plane cache. Packet migration detects flooding attacks (2010) presented HyperFlow, a distributed event-based control
 W. Li et al. / Journal of Network and Computer Applications 68 (2016) 126–139 135

Table 5
A list of existing solutions for controller-related security challenges.

Work in literature Implementation Year Confidentiality Integrity Availability

Tootoonchian and Ganjali (2010) HyperFlow 2010 √

Suh et al. (2010) CONA 2010 √ √
Yao et al. (2011) VAVE 2011 √ √ √
Porras et al. (2012) FortNOX 2012 √ √ √
Canini et al. (2012) NICE 2012 √ √
Matias et al. (2012) ARM 2012 √
Wen et al. (2013) PermOF 2013 √ √
Hu et al. (2014) FlowGuard 2014 √ √
Fichera et al. (2015) OPERETTA 2015 √
Wang et al. (2015) FloodGuard 2015 √
Hong et al. (2015) TopoGuard 2015 √ √ √

plane for OpenFlow. By passively synchronizing network-wide framework, aiming to facilitate accurate detection and effective
views of OpenFlow controllers, HyperFlow localizes decision resolution of firewall policy violations in dynamic OpenFlow-
making to individual controllers, thus minimizing the control based networks. It checks network flow path spaces to detect
plane response time to data plane requests. In other words, it is firewall policy violations when network states are updated. Kotani
logically centralized but physically distributed. It also enables in- and Okabe (2014) proposed a filtering mechanism to reduce
terconnecting independently managed OpenFlow networks, an Packet-In messages without dropping important ones for network
essential feature missing in current OpenFlow deployments. control. In their mechanism, switches record the values of packet
Then, Suh et al. (2010) proposed a Content-oriented Network- header fields before sending Packet-In messages, which are spe-
ing Architecture (CONA) where the hosts request contents from its cified by the controllers in advance, and filter out packets that
agents. In CONA, an access router is extended to identify what have the same values as the recorded ones.
contents are requested, and its agent receives a content request Overall, to overcome this kind of security issues, it is considered
from an attached host and delivers the requested content. In this that trust models, security policy enforcement and monitoring
way, CONA achieves the accountability and can take a counter- tools (Yuzawa, 2013) are effective. Additionally, replication and
measure against resource-exhaustive attacks like DDoS. A proto- recovery mechanisms can be applied as well.
type was built on the NetFPGA OpenFlow platform but its perfor-
mance was not evaluated in large and practical experiments. Fi- 4.3. Countermeasures for channel-related security challenges
chera et al. (2015) presented OPERETTA, an OpenFlow Remedy to
TCP SYNFLOOD attacks, which relies on the use of an SDN ap- To mitigate these security challenges, a clean and secure
proach to protect the OpenFlow controller from TCP SYNFLOOD channel should be safeguarded. Obviously, encryption is a neces-
attacks. It can be implemented in the controller that manages sary and the first step to achieve this goal. For example, applying
incoming TCP SYN packets and rejects fake connection requests. TLS or SSH or other methods to securing northbound commu-
Later, Wang et al. (2015) studied the data-to-control plane sa- nications and controller management. Then, the communications
turation attack in reactive controllers and developed FloodGuard, a from the applications and services, which request services or data
lightweight and protocol-independent defense framework, to from the controller, should be secured using authentication and
protect the controller from being overloaded. In particular, their encryption methods. Several existing research studies are listed in
approach consisted of two techniques: proactive flow rule analy- Table 6.
zer and packet migration. The former combines symbolic execu- Monitoring. To protect the OpenFlow channel, appropriate
tion and dynamic application tracking to derive proactive flow monitoring is useful to detect malicious states in a quick manner.
rules in runtime. The latter migrates, caches, and processes table- Liyanage et al. (2014) proposed a secure control channel archi-
miss packets by using rate limiting and round robin scheduling. tecture based on Host Identity Protocol (HIP) to enhance the
Design enhancement. For the design, Canini et al. (2012) pro- communication between the switches and the controllers. The
posed NICE, a tool that efficiently uncovers bugs in OpenFlow architecture uses the IPsec tunneling and security gateways tech-
programs, through a combination of model checking and symbolic nologies to protect the channel. The experiments reveal that the
execution. They also presented a simplified OpenFlow switch proposed architecture protects the control channel against various
model (to reduce the state space), and effective strategies for IP based attacks such as DoS, spoofing, replay and eavesdropping
generating event interleavings to uncover bugs. Then, Porras et al. attacks. However, they noticed that there is a performance penalty
(2012) proposed FortNOX, a software extension that provides role- of security due to the establishment of IPsec tunnel. A suggestion
based authorization and security constraint enforcement for the to this drawback is to utilize security specific hardware and keep
NOX OpenFlow controller (Gude et al., 2008). It can check flow rule the established tunnels for a longer period.
contradictions in real time and there are three authorization roles: DoS migration. For this issue, Sherwood et al. (2010) proposed
human administrators, security applications and non-security-re- FlowVisor to slice the network hardware by placing a layer be-
lated OF applications. The rule is that no other applications, other tween the control plane and the data plane. In implementation,
than human administrators, can insert flow rules which conflict FlowVisor uses OpenFlow and sits between an OpenFlow switch,
with those rules inserted by a security application. the forwarding element and multiple OpenFlow controllers. The
Kreutz et al. (2013) presented a general design of a secure and major issue is that it has no instantiate network security con-
dependable SDN control platform, but no implementation and straints within a slice.
experimental results were provided. Then, Wen et al. (2013) pro- Then, Shin et al. (2013) proposed AVANT-GUARD to integrate
posed PermOF, a fine-grained permission system containing a set both connection migration and actuating triggers in a reference
of OF-specific permissions and an isolation mechanism to enforce SDN (OpenFlow) software switch. This tool can significantly re-
the permissions, aiming to safeguard the controller platform. Hu duce the amount of data-to-control-plane interactions under DoS
et al. (2014) later introduced FlowGuard, a comprehensive attacks, and solve the communication bottleneck between the data
136 W. Li et al. / Journal of Network and Computer Applications 68 (2016) 126–139

Table 6 Spoofing and hijacking defend. Spoofing and hijacking are of-
A list of existing solutions for channel-related security challenges. ten part of a large attack such as flooding and DoS attacks. These
spoofed and hijacked elements like devices can be further utilized
Work in Implementation Year Confidentiality Integrity Availability
literature as botnets to launch distributed DoS attacks. Generally, authenti-
cation and address validation techniques can be used to defend
Sherwood FlowVisor 2010 √ √ against these attacks. For example, network information can be
et al. frequently changed and hidden from externals, including not only
(2010)
Shin et al. AVANT-GUARD 2013 √ √ √
IP addresses, but also topology and routing tables (Alsmadi and Xu,
(2013) 2015).
Liyanage HIP 2014 √ √ √ DoS defend. This type of attack is a major threat for OpenFlow-
et al. based SDN, as it can disable the whole network such as degrading
(2014)
network performance, dropping packets and so on. In addition, as
OpenFlow controller is a key component for network control and
management, it has become a bottleneck and is greatly threatened
plane and the control plane. The objective of connection migration by such attacks. Reliable encryption cannot secure SDN from being
is to add intelligence to the data plane to differentiate those attacked, but enhanced trust mechanisms and access policies can
sources that will complete TCP connections from sources that will mitigate such attacks. At the switch level, it is desirable to have a
not. Actuating triggers enable the data plane to asynchronously capability to re-evaluate flow table rules, ensuring services to le-
report network status and payload information to the control gitimate hosts and denying unauthorized access. Current Open-
plane. However, it cannot defend against application layer DoS Flow switches have not implemented such intelligence while extra
attacks. overhead is the major concern.
Overall, encryption, credential verification and trust mechan- On the whole, a desirable security mechanism should ensure
isms can be applied to enhance the channel security between the both the controller and the switches can quickly recover from
controller and switches. large volume traffic attacks. Proper monitoring and response me-
chanisms are expected to be active when detecting DoS attacks.
4.4. Further discussion For instance, Shirali-Shahreza and Ganjali (2013) proposed FleX-
am, a flexible sampling extension for OpenFlow that enables the
It is worth emphasizing that current solutions usually focus on controller to access packet-level information, which can help de-
several weak points of OpenFlow-based SDN by combining a set of tect DoS attacks. Moreover, flow information is useful in detecting
techniques rather than solving only one security issue. For in- most DoS attacks, through analyzing traffic. As an example, flow
stance, AVANT-GUARD integrates both connection migration and headers can be used to detect DoS attacks if there is an unbalance
actuating triggers to address saturation attacks and the respon- between incoming and outgoing traffic.
siveness challenge in SDN (Shin et al., 2013). Wang et al. (2015)
developed FloodGuard, which can address the data-to-control
plane saturation attack. This attack can produce a large amount of 5. Future directions
table-miss ‘packet_in’ messages to consume resources in both
control plane and data plane. SDN is an emerging architecture, which is suitable for the high-
Besides, monitoring mechanism should be implemented in any bandwidth, dynamic nature of today's applications. It can help
SDN. As an example, Shin and Gu (2012) proposed a framework, organizations accelerate application deployment and delivery, and
called CloudWatcher, to provide monitoring services for large and dramatically reduce IT costs through policy-enabled workflow
dynamic cloud networks. It can detour network packets using pre- automation. It also enables cloud architectures by delivering au-
installed devices and all these operations can be implemented by tomated, on-demand application delivery and mobility at scale
means of a simple policy script. A weakness is that this approach (Cisco: Software Defined Networking, SDN, 2015). For the future
cannot produce a routing path and may have problems if there are design of OpenFlow-based SDN, more research efforts should be
many new flows. made to protect its switches, controller and communication
In addition, intrusion detection systems (IDSs) can be tuned from channel.
traditional network (Meng et al., 2014) and applied in SDN to iden- OpenFlow switches. At the switch level, more research efforts
tifying malicious flows, rules and commands (Kamisinski and Fung, are expected to be made to securing flows and protecting various
2015). As an example, Mehdi et al. (2011) showed how to implement switch vulnerabilities.
four prominent traffic anomaly detection algorithms in an SDN using Based on our analyses above, intruders are likely to conduct
Openflow compliant switches and NOX controller. It is expected that various attacks on flows, flow rules and flow tables. Such intru-
more security applications and techniques could be developed to sions can be triggered by faulty (non-malicious) devices or by
enhance OpenFlow-based SDN in future research studies. malicious users. For example, an attacker can use network ele-
Scanning defend. Network scanners are developed by attackers ments, such as switches, servers and personal computers, to
to collect information about SDN as an initial step to disclose launch a DoS attack against OpenFlow switches (Kreutz et al.,
sensitive information. In general, encryption algorithms can be 2013). To safeguard the OpenFlow switches, intrusion detection
used to defend against this type of attack. In addition, intrusion systems can be deployed as the first defense line, with support for
detection systems can be applied to both switches and controllers runtime root-cause analysis which could help identify abnormal
to identify various attacks as well (Mehdi et al., 2011; Seeber and flows. In addition, under SDN, it is possible to directly apply se-
Rodosek, 2015). Additionally, some methods focus on constructing curity policies in traffic flows.
filters to redirect malicious traffic. For example, Schehlmann and On the other hand, taking advantage of switch vulnerabilities,
Harald (2013) presented COFFEE, which can process the whole attackers can easily compromise the whole network security. For
traffic to filter out candidates of a command-and-control com- example, hijacked switches could be used to drop or slow down
munication (Botnet). By contrast, some methods attempt to take packets in the network, clone and deviate network traffic (e.g., for
active countermeasures to increase the cost of intruders (Kampa- data theft), or even inject traffic or forged requests to overload the
nakis et al., 2014). controller or neighboring switches. For defense, software
 W. Li et al. / Journal of Network and Computer Applications 68 (2016) 126–139 137

attestation such as autonomic trust management is a promising and a logically centralized server to grant access to services. The
solution. Moreover, monitoring mechanisms are desirable to de- major disadvantage is that the highly centralized control network
tect abnormal behaviors of network devices, which can help environment cannot be opened to others. By extending this idea of
identify such threat in a fast manner. SANE, the same authors proposed Ethane (Casado et al., 2007), a
OpenFlow controller. The controller is a critical element in new architecture to allow managers defining a single network
OpenFlow-based SDN, more research regarding access control and wide fine-grain policy and directly enforcing it. Ethane is easier to
policy enforcement is desirable to defend against various be implemented than SANE; however, the same problem is that
intrusions. centralized control is vulnerable to attacks without openness.
DoS attacks are a big threat for the controller, as it is the entity In addition, Nayak et al. (2009) proposed Resonance, a system
that dictates the network behavior. Once an attacker gains access to enforces dynamic access control policies based on both flow-level
the control plane, it may be capable of aggregating enough power information and real-time alerts. The major weakness is that it
force to launch DDoS attacks to other elements and allow data must depend on the existence of a secure and reliable channel
leakage in normal traffic flows. As a defense, establishing trust between the controller and switches. It uses programmable
models with multiple certification authorities is a promising solu- switches to manipulate traffic at lower layers; these switches take
tion to reduce unauthorized links. Additionally, the use of dynamic, actions (e.g., dropping or redirecting traffic) to enforce high-level
automated and assured device association mechanisms can be security policies based on inputs from both higher level security
considered to enhance the controller. Taking dynamic address al- policies and distributed monitoring and inference systems.
location as an example, it can help quickly identify malicious enti- Moreover, Shin et al. (2013) designed FRESCO, a security appli-
ties and reduce unauthorized traffic (e.g., zombie network). cation development framework that enables the rapid design and
In addition, attackers can utilize malicious applications from modular composition of OpenFlow-enabled detection and mitiga-
the top level to compromise the controller and cause adverse tion modules. It exports a scripting API that enables security prac-
configuration commands to the underlying infrastructure. To de- titioners to code security monitoring and threat detection logic as
fend against such threat, autonomic trust management could be modular libraries. These modular libraries represent the elementary
used to guarantee that one application is trusted during its life- processing units in FRESCO, and can be shared and linked together
time. Moreover, it is important to secure all the sensitive elements to provide complex network defense applications. It can offer
inside the controller and apply policy enforcement to restrict minimal overhead and rapid creation of security functions; however,
which interfaces an application can use and what kind of rules it the framework itself should be further evaluated in the aspect of
can generate to program the network. security. Overall, OpenFlow and SDN present promising applications
OpenFlow channel. The channel is a very important element to mitigate other network security issues, which is an interesting
for OpenFlow-based SDN, which links the controller and switches. direction. In return, this can help promote their own development.
Actually, most enhancement and protections at the channel level
can benefit both the controller and switches. In the literature, 6. Conclusions
more studies are expected to research how to design a secure and
clean communication channel. With the separation of the control plane from the data plane,
Ensuring TLS in all switches and controllers is a simple way, SDN brings a fascinating evolution of networking architectures;
whereas this may add additional configuration cost on the net- however, its network programmability and control logic cen-
work operators. Another method of protecting the plaintext tralization also increase security risks. OpenFlow is currently the
communication is to use auto-generated keys and trust-of-first- most deployed SDN concept, but due to the rapidly evolving nat-
use method that performs in the same manner as SSH. This may ure, many vendors of both switches and controllers have not fully
require a network operator to verify the thumbprint of each de- implemented the specification and have skipped the TLS entirely,
vice's public key, when the first time a switch connects to a con- which may open a hole for attackers (i.e., launching spoofing, hi-
troller (Benton et al., 2013). jacking, DoS attacks, etc.).
To defend against man-in-the-middle attacks, it requires to In this paper, we focus on OpenFlow-based SDN and analyze
establish a more robust authentication mechanism between the security challenges based on OpenFlow switches, controller and
controller and the switches. Furthermore, it may limit the window channel, by means of the CIA triad model. It is found that security
for a malicious behavior to a small time-frame between when the should be an important factor in future SDN design. We later
switch is connected to a network and before it has connected to summarize and analyze existing research efforts in enhancing
the controller for the first time. such networks. It is expected that more research efforts should be
SDN applications. Our current survey mainly discusses the made to validating elements' address, establishing trust mechan-
security of OpenFlow-based SDN itself; however, many studies in isms between elements, ensuring strong encryption and so on. Our
the literature have given attention to how to utilize such network effort attempts to complement existing surveys and stimulate
to address various security issues. These promising applications more research studies in this area.
help motivate and accelerate the development of OpenFlow &
SDN. For example, Braga et al. (2010) proposed a lightweight
method to detect flooding attacks based on traffic flow features. Acknowledgements
Their method was implemented over a NOX-based network,
where OpenFlow switches keep flow tables with statistics about
The work was partially funded by the Innovation to Realization
all active flows. It then uses Self Organizing Maps, a kind of un-
Funding Scheme of the City University of Hong Kong (under the
supervised artificial neural networks, and trains them with the
Project no. 6351018).
selected features. As compared to traditional approaches, this
method can extract needed information with a very low overhead.
The major weakness is that they did not evaluate its performance
References
in real scenarios.
SDNs are also considered as a solution for large networks. For
Al-Shaer, E., Al-Haj, S., 2010. FlowChecker: configuration analysis and verification of
instance, Casado et al. (2006) developed SANE, a protection layer federated openflow infrastructures. In: Proceedings of the 3rd ACM Workshop
for enterprise networks to govern all connectivity in the enterprise on Assurable and Usable Security Configuration, Chicago, IL, USA, pp. 37–44.
138 W. Li et al. / Journal of Network and Computer Applications 68 (2016) 126–139

Alsmadi, I., Xu, D., 2015. Security of software defined networks: a survey. Comput. Kotani, D., Okabe, Y., 2014. A packet-in message filtering mechanism for protection
Secur. 53, 79–108. of control plane in openflow networks. In: Proceedings of the 10th ACM/IEEE
Benton, K., Camp, L.J., Small, C., 2013. OpenFlow vulnerability assessment. In: Pro- Symposium on Architectures for Networking and Communications Systems
ceedings of the 2nd ACM SIGCOMM Workshop on Hot Topics in Software De- (ANCS), pp. 29–40.
fined Networking (HotSDN), Hong Kong, China, pp. 151–152. Kreutz, D., Ramos, F.M.V., Verissimo, P., 2013. Towards secure and dependable
Bifulco, R., Karame, G.O., 2014. Towards a richer set of services in software-defined software-defined networks. In: Proceedings of the 2nd ACM Workshop on Hot
networks. In: Proceedings of SENT, San Diego, CA, USA. Topics in Software Defined Networking (HotSDN), Hong Kong, China, pp. 55–60.
Braga, R., Mota, E., Passito, A., 2010. Lightweight DDoS flooding attack detection Lara, A., Kolasani, A., Ramamurthy, B., 2014. Network innovation using openflow: a
using NOX/OpenFlow. In: Proceedings of the 35th Conference on Local Com- survey. IEEE Commun. Surv. Tutor. 16 (1), 493–512.
puter Networks (LCN), Denver, Colorado, USA, pp. 408–415. Lara, A., Ramamurthy, B., 2014. OpenSec: a framework for implementing security
Beacon: Java-Based OpenFlow Controller 〈https://openflow.stanford.edu/display/ policies using OpenFlow. In: Proceedings of the IEEE Global Communications
Beacon/Home〉. Conference (GLOBECOM), Austin, Texas, pp. 781–786.
Canini, M., Venzano, D., Perešíni, P., Kostić, D., Rexford, J., 2012. A nice way to test Li, L.E., Mao, Z.M., Rexford, J., 2012. Toward software-defined cellular networks. In:
OpenFlow applications. In: Proceedings of the 9th USENIX Conference on Proceedings of 2012 European Workshop on Software Defined Networking
Networked Systems Design and Implementation (NSDI), San Jose, CA, USA, pp. (EWSDN), Darmstadt, Germany, pp. 7–12.
1–14. Liyanage, M., Ylianttila, M., Gurtov, A., 2014. Securing the control channel of soft-
Casado, M., Garfinkel, T., Akella, A., Freedman, M.J., Boneh, D., McKeown, N., ware-defined mobile networks. In: Proceedings of the 2014 IEEE 15th Inter-
Shenker, S., 2006. SANE: a protection architecture for enterprise networks. In: national Symposium on World of Wireless, Mobile and Multimedia Networks
Proceedings of USENIX Security Symposium, Vancouver, BC, Canada, pp. 1–15. (WoWMoM), Sydney, Australia, pp. 1–6.
Casado, M., Freedman, M.J., Pettit, J., Luo, J., McKeown, N., Shenker, S., 2007. Ethane: Liu, J., Li, Y., Wang, H., Jin, D., Su, L., Zeng, L., Vasilakos, T., 2016. Leveraging software-
taking control of the enterprise. In: Proceedings of the 2007 ACM SIGCOMM. defined networking for security policy enforcement. Inf. Sci. 327, 288–299.
Kyoto, Japan, pp. 1–12. Luo, T., Tan, H.P., Quek, T.Q.S., 2012. Sensor OpenFlow: enabling software-defined
Cisco: Software Defined Networking (SDN), 2015 〈http://www.cisco.com/web/solu wireless sensor networks. IEEE Commun. Lett. 16 (11), 1896–1899.
tions/trends/sdn/index.html〉. Matias, J., Borja, T., Alaitz, M., Jacob, E., Nerea, T., 2012. Implementing layer
Crenshaw, A., 2012. Security and Software Defined Networking: Practical Possibi- 2 network virtualization using OpenFlow: challenges and solutions. In: Pro-
lities and Potential Pitfalls. Available online 〈http://www.irongeek.com/i.php? ceedings of the 2012 European Workshop on Software Defined Networking,
page¼ security/security-and-software-defined-networking-sdn-openflow〉. pp. 30–35.
Dover, J., 2013. A Denial of Service Attack Against the Open Floodlight SDN Con- Matias, J., Garay, J., Mendiola, A., Toledo, N., Jacob, E., 2014. FlowNAC: flow-based
troller. Dover Networks, Research Report. network access control. In: Proceedings of the 3rd European Workshop on
Farhady, H., Lee, H., Nakao, A., 2015. Software-defined networking: a survey. Software Defined Networks (EWSDN), Budapest, pp. 79–84.
Comput. Netw. 81, 79–95. Mehdi, S.A., Khalid, J., Khayam, S.A., 2011. Revisiting traffic anomaly detection using
Fayazbakhsh, S.K., Sekar, V., Yu, M., Mogul, J.C., 2013. FlowTags: enforcing network- software defined networking. In: Proceedings of the 14th International Con-
wide policies in the presence of dynamic middlebox actions. In: Proceedings of ference on Recent Advances in Intrusion Detection (RAID), Menlo Park, Cali-
the 2nd ACM Workshop on Hot Topics in Software Defined Networks (HotSDN), fornia, pp. 161–180.
pp. 19–24. Mendonca, M., Seetharaman, S., Obraczka, K., 2012. A flexible innetwork IP anon-
Feng, T., Bi, J., Hu, H., 2011. OpenRouter: openflow extension and implementation ymization service. In: Proceedings of the 2012 IEEE International Conference on
based on a commercial router. In: Proceedings of the 19th IEEE International Communications (ICC), Ottawa, ON, pp. 6651–6656.
Conference on Network Protocols (ICNP), Vancouver, BC, pp. 141–142. Meng, W., Li, W., Kwok, L.F., 2014. EFM: enhancing the performance of signature-
Feng, T., Bi, J., Hu, H., Yao, G., Xiao, P., 2012. InSAVO: Intra-AS IP source address based network intrusion detection systems using enhanced filter mechanism.
validation solution with OpenRouter. In: Proceedings of INFOCOM. Comput. Secur. 43, 189–204.
Fichera, S., Galluccio, L., Grancagnolo, S.C., Morabito, G., Palazzo, S., 2015. OPER- Maestro Project 〈http://zhengcai.github.io/maestro-platform/〉.
ETTA: an openflow-based remedy to mitigate TCP SYNFLOOD attacks against Nayak, A.K., Reimers, A., Feamster, N., Clark, R., 2009. Resonance: dynamic access
web servers. Comput. Netw 92, 89–100. control for enterprise. In: Proceedings of the 1st ACM Workshop on Research
Floodlight: Apache-Licensed, Java-Based OpenFlow Controller 〈http://www.pro on Enterprise Networking (WREN), Barcelona, Spain, pp. 11–18.
jectfloodlight.org/floodlight/〉. Open Networking Foundation, 2012. Sofware-Defined Networking: The New Norm
Greenk, K., 2009. TR10: software-defined networking. MIT Technol. Rev. 112 (2), 54. for Networks. White Paper, April 〈https://www.opennetworking.org/images/
Gude, N., Koponen, T., Pettit, J., Pfaff, B., Casado, M., McKeown, N., Shenker, S., 2008. stories/downloads/sdn-resources/white-papers/wp-sdn-newnorm.pdf〉.
NOX: towards an operating system for networks. ACM Comput. Commun. Rev. OpenFlow Switch Specification Version 1.5.0, 2014. Technical Report, December 19
51 (7), 105–110. 〈https://www.opennetworking.org/images/stories/downloads/sdn-resources/
Hampel, G., Steiner, M., Bu, T., 2013. Applying software-defined networking to the onf-specifications/openflow/openflow-switch-v1.5.0.noipr.pdf〉.
telecom domain. In: Proceedings of 2013 IEEE Conference on Computer Com- Pentikousis, K., Wang, Y., Hu, W., 2013. Mobileflow: toward software-defined mo-
munications Workshops (INFOCOM WKSHPS), Turin, Italy, pp. 133–138. bile networks. IEEE Commun. Mag. 51 (7), 44–53.
Hakiri, A., Gokhale, A., Berthou, P., Schmidt, D.C., Gayraud, T., 2014. Software-de- Porras, P., Shin, S., Yegneswaran, V., Fong, M., Tyson, M., Gu, G., 2012. A Security
fined networking: challenges and research opportunities for future internet. Enforcement Kernel for OpenFlow Networks. In: Proceedings of the 1st
Comput. Netw. 75, 453–471. Workshop on Hot topics in Software Defined Networks (HotSDN), pp. 121–126.
Hong, S., Xu, L., Wang, H., Gu, G., 2015. Poisoning network visibility in software- Perrin, C., 2012. The CIA Triad, Retrieved May 31 〈http://www.techrepublic.com/
defined networks: new attacks and countermeasures. In: Proceedings of NDSS, blog/it-security/the-cia-triad/〉.
San Diego, USA. POX: A Python-Based OpenFlow Controller 〈https://github.com/noxrepo/pox〉.
Hu, F., Hao, Q., Bao, K., 2014. A survey on software-defined network and OpenFlow: RouteFlow Open Source Project 〈https://sites.google.com/site/routeflow/home〉.
from concept to implementation. IEEE Commun. Surv. Tutor. 16 (4), 2181–2206. Ryu 〈https://github.com/osrg/ryu〉.
Hu, H., Han, W., Ahn, G.-J., Zhao, Z., 2014. FLOWGUARD: building robust firewalls for Scott, H., 2014. SDN Security Attack Vectors and SDN Hardening. Available online
software-defined networks. In: Proceedings of the 3rd Workshop on Hot Topics 〈http://www.networkworld.com/article/2840273/sdn/〉.
in Software Defined Networking (HotSDN), Chicago, Illinois, USA, pp. 97–102. Scott-Hayward, S., O'Callaghan, G., Sezer, S., 2013. SDN security: a survey. In: Pro-
IRIS 〈https://github.com/bjlee72/IRIS〉. ceedings of the 2013 IEEE SDN for Future Networks and Services (SDN4FNS),
Jammal, M., Singh, T., Shami, A., Asal, R., Li, Y., 2014. Software defined networking: Trento, pp. 1–7.
state of the art and research challenges. Comput. Netw. 72, 74–98. Shirali-Shahreza, S., Ganjali, Y., 2013. Efficient implementation of security applica-
Jagadeesan, N.A., Krishnamachari, B., 2015. Software-defined networking para- tions in OpenFlow controller with FleXam. In: Proceedings of the 2nd ACM
digms in wireless networks: a survey. ACM Comput. Surv. 47 (2). SIGCOMM Workshop on Hot Topics in Software Defined Networking (HotSDN),
Jafarian, J.H., Al-Shaer, E., Duan, Q., 2012. Openflow random host mutation: trans- Hong Kong, pp. 167–168.
parent moving target defense using software defined networking. In: Pro- Schehlmann, L., Harald, B., 2013. COFFEE: a concept based on OpenFlow to filter and
ceedings of the ACM Workshop on Hot Topics in Software Defined Networks erase events of botnet activity at highspeed nodes. In: Proceedings of IN-
(HotSDN), Helsinki, Finland, pp. 127–132. FORMATIK, Darmstadt.
Jaxon 〈http://jaxon.onuos.org/〉. Seeber, S., Rodosek, G.D., 2015. In: Proceedings of the 9th International Conference
Kampanakis, P., Perros, H., Beyene, T., 2014. SDN-based solutions for moving target on Autonomous Infrastructure, Management, and Security (AIMS), Ghent, Bel-
defense network protection. In: Proceedings of the 2014 IEEE 15th International gium, pp. 134–139.
Symposium on a World of Wireless, Mobile and Multimedia Networks Sherwood, R., Gibb, G., Yap, K.-K., Appenzeller, G., Casado, M., McKeown, N., Par-
(WoWMoM), Sydney, NSW, pp. 1–6. ulkar, G., 2010. Can the production network be the testbed. In: Proceedings of
Kamisinski, A., Fung, C., 2015. FlowMon: detecting malicious switches in software- the 9th USENIX conference on Operating systems design and implementation
defined networks. In: Proceedings of the 2015 Workshop on Automated Deci- (OSDI), Vancouver, BC, pp. 1–6.
sion Making for Active Cyber Defense (SafeConfig). Shin, S., Gu, G., 2012. CloudWatcher: network security monitoring using OpenFlow
Khurshid, A., Zhou, W., Caesar, M., Godfrey, P.B., 2012. VeriFlow: verifying network- in dynamic cloud networks. In: Proceedings of the 20th IEEE International
wide invariants in real time. In: Proceedings of the 1st Workshop on Hot Topics Conference on Network Protocols (ICNP), Austin, TX, pp. 1–6.
in Software Defined Networks (HotSDN), Helsinki, Finland, pp. 49–54. Shin, S., Porras, P., Yegneswaran, V., Fong, M., Gu, G., Tyson, M., 2013. FRESCO:
Kloeti, R., Vasileios, K., Paul, S., 2013. OpenFlow: a security analysis. In: Proceedings modular composable security services for software-defined networks. In: Pro-
of the 21st IEEE International Conference on Network Protocols (ICNP), Got- ceedings of the ISOC Network and Distributed System Security Symposium
tingen, German, pp. 1–6. (NDSS), San Diego, California, USA, pp. 1–16.
 W. Li et al. / Journal of Network and Computer Applications 68 (2016) 126–139 139

Shin, S., Gu, G., 2013. Attacking software-defined networks: a first feasibility study. Jose, CA, pp. 1–6.
In: Proceedings of the 2nd Workshop on Hot Topics in Software Defined Net- Wang, H., Xu, L., Gu, G., 2014. OF-GURAD: A DoS Attack Prevention Extension in
works (HotSDN), Hong Kong, China, pp. 165–166. Software-Defined Networks. ONS.
Shin, S., Yegneswaran, V., Porras, P., Gu, G., 2013. AVANT-GUARD: scalable and Wang, H., Xu, L., Gu, G., 2015. FloodGuard: a DoS attack prevention extension in
vigilant switch flow management in software-defined networks. In: Proceed- software-defined networks. In: Proceedings of the International Conference on
ings of ACM SIGSAC Conference on Computer and Communications Security Dependable Systems and Networks (DSN), pp. 239–250.
(CCS), ACM Press, Berlin, Germany, pp. 413–424. Wen, X., Chen, Y., Hu, C., Shi, C., Wang, Y., 2013. Towards a secure controller plat-
Sonchack, J., Aviv, A.J., Keller, E., Smith, J.M., 2015. OFX: enabling openflow exten- form for openflow applications. In: Proceedings of the 2nd ACM Workshop on
sions for switch-level security applications (POSTER). In: Proceedings of the Hot Topics in Software Defined Networking (HotSDN), Hong Kong, China, pp.
22nd ACM SIGSAC Conference on Computer and Communications Security 171–172.
(CCS). Xiao, P., Bi, J., Feng, T., 2013. O-CPF: an OpenFlow based intra-AS source address
Suh, J., Choi, H., Yoon, W., You, T., Kwon, T., Choi, Y., 2010. Implementation of validation application. In: Proceedings of CFI, Beijing, China.
content-oriented networking architecture (CONA): a focus on DDoS counter- Yamasaki, Y., Miyamoto, Y., Yamato, J., Goto, H., 2011. Flexible access management
measure. In: Proceedings of the 1st European NetFPGA Developers Workshop, system for campus VLAN based on OpenFlow. In: Proceedings of 2011 IEEE/IPSJ
ACM Press, Cambridge, UK, pp. 1–5. 11th International Symposium on Applications and the Internet (SAINT), Mu-
SNAC 〈https://github.com/bigswitch/snac〉. nich, Germany, pp. 347–351.
Tavakoli, A., Casado, M., Koponen, T., Shenker, S., 2009. Applying NOX to the da- Yao, G., Bi, J., Xiao, P., 2011. Source address validation solution with OpenFlow/NOX
tacenter. In: Proceedings of HotNet. ACM Press, New York City, NY, pp. 1–6. architecture. In: Proceedings of the IEEE International Conference on Network
Tootoonchian, A., Ganjali, Y., 2010. HyperFlow: a distributed control plane for Protocols (ICNP), Vancouver, BC, Canada, pp. 7–12.
openflow. In: Proceedings of the Internet Network Management Workshop/ Yuzawa, T., 2013. OpenFlow 1.0 Actual Use-Case: RTBH of DDoS Traffic While
Workshop on Research on Enterprise Networking (INM/WREN). Usenix, San Keeping the Target.