Photonic Network Communications (2019) 37:1–23

https://doi.org/10.1007/s11107-018-0803-7

ORIGINAL PAPER

Security in OpenFlow-based SDN, opportunities and challenges

Jaouad Benabbou1 · Khalid Elbaamrani1 · Noureddine Idboufker1

Received: 24 July 2018 / Accepted: 27 September 2018 / Published online: 9 October 2018
© Springer Science+Business Media, LLC, part of Springer Nature 2018

Abstract
The SDN paradigm profoundly affects the architecture of networks in favor of more adaptability to the needs for new value-
added services. This article examines the positive and negative impacts of such a change on network security. While few
in-depth studies have attempted to cover this issue in a comprehensive way, we first tried to define the most relevant axes of
analyses with regard to this concept, namely availability, access control and application services oriented security. In relation
to these axes as well as to the state of the art of security, a number of researches and studies that have addressed this issue by
proposing solutions through the OpenFlow specification are analyzed with the aim to highlight the real opportunities and the
real challenges brought by this new concept for the network security.

Keywords Security · SDN · OpenFlow · Availability · Access control · Recovery

1 Introduction NTT’s Edge Gateway (a Software-defined Cloud-Gateway

automation system [4]) or also CISCO Application Centric
SDN concept brings a significant evolution in the manage- Infrastructure (an open Software-Defined networking plat-
ment of networks by decoupling the control logic from the form to simplify network operation and management with
data plane. Better programmability, high level of abstrac- application-focused network services [5]). The success of
tion and reduction in both CapEX and OpEX are the main these flagship implementations and the creation in 2011 of
motivations for this change. This development was neces- the Open Network Foundation (ONF) by some international
sary to enable networks to better meet application needs that leaders of the digital world (Google, Facebook, Microsoft,
continue to evolve over the time (mobility, cloud comput- Yahoo!, Verizon and Deutsche Telekom) reflects the con-
ing, virtualization, security, etc.). In fact, the idea consisting viction of the irreversibility of the trend toward open and
of separation the control logic from the data infrastructure programmable networks. Indeed, the main objective of the
has been raised well before the advent of SDN concept but Open Network Foundation is to promote, develop the concept
has been abandoned due to lack of applicative motivations. and encourage standardization efforts. Therefore, OpenFlow
For instance, SANE architecture [1] was designed with the (de facto standard and the first protocol designed specifically
aims to centralize the control logic for some security services for SDN [6]), is one of the major contributions of the ONF
(authentication of hosts and policy enforcement). SANE was which has built a solid ground for future SDN implementa-
later extended in the context of Ethane project [2] but with an tions. Industry acceptance of OpenFlow is significant since
approach that required less changes in hardware and software most network node manufacturers are already implementing
infrastructures. it on a wide range of their products (HP, IBM, NEC, Huawei,
Today, encouraged by the growing recognition of the many Juniper, Brocade, NoviFlow…).
limitations of the classical architectural model, the concept is Although it was not among the main drivers of this pro-
back in force and has been successfully adopted and deployed found conceptual shift, the security aspects must be placed at
in large-scale production platforms like B4 (WAN connect- the center of the considerations, as well in terms of opportu-
ing several Google’s data centers across the world [3]), nities as of challenges. Relatively, few studies have focused
on this important area; even fewer are those who addressed
B Jaouad Benabbou SDN security in a comprehensive manner. We argue that to
jaouadbenabbou@gmail.com
give a judgment on the matter, it is necessary to take into
1 Network and Telecommunication Department, ENSA account all the criteria of security at all levels (data plane,
Marrakech, Cadi Ayyad University, Marrakech, Morocco

123
2 Photonic Network Communications (2019) 37:1–23

control plane and application layer). Based on this princi- Create roung rules based on
Rules (Flow
ple, this article aims to give the broadest possible view of table)
the communicaon contents

the different characteristics of the SDN concept that may be

seen as advantages or drawbacks from a security point of Host A Rules (Flow
table)
view. We will address the criteria of availability, access con-
Controller
trol, integrity (security policy consistency) as well as network
security services at application layer. Host B Rules (Flow
table)

The issue of SDN security is divided into two parts:

Transmit and update the
roung rules
Transmit the communicaon

• Security by SDN Try to answer the question of how to

between host A and host
according to the roung rules

leverage the opportunities offered by the SDN concept to

better address traditional security issues; Fig. 1 Basic behavior of SDN
• Security of SDN Try to find solutions for new threats that
may arise with the SDN architectural concept.
• Difficulty to implement consistent policies (security,
access control and QoS) due to the necessity to separately
The question that this paper tries to answer is not whether configure several network nodes;
SDN networks are “more secure” than legacy architectures. • Dependence on vendors The ability to add new services is
But, given that generally major changes to the architecture limited by the dependence on hardware vendors. Equip-
designs are among the main causes of introduction of new ment development cycle is much longer than what is
flaws or vulnerabilities, we intend to detail how the benefits required by the needs of users (average 3 years).
of this concept are not provided at the expense of security.
We will address, by referring to the state of the art, these
The core element in the SDN architecture is the controller
aspects through the OpenFlow specification and some works
that translates policies for different application services into
that have proposed solutions to some of these aspects.
one or multiple flow rules configured at the data plane level
This paper is organized as follows. In Sect. 2, we present
(network nodes) using OpenFlow protocol. OpenFlow is an
the main concepts of SDN architecture, its components as
open standard that provides an interface to configure switches
well as the main benefit. In Sect. 3, we discuss about the most
at the data plane with a high level of abstraction. OpenFlow
relevant security challenges at all layers of SDN architecture
is based on a network node with an internal flow table and a
and then we present some notable related works in this area.
standardized interface to configure it by adding or removing
Sections 5 and 6 detail, respectively, security by SDN and the
flow entries [7].
security of SDN concept; we particularly detail availability,
Figure 1 shows how switches execute different actions
fast failure recovery, access control (in both southbound and
based on rules configured by an external and centralized con-
northbound interfaces) and security services at application
troller unlike the case of traditional networks where actions
layer by discussing and comparing some of the most relevant
are taken based on the internal intelligence of the network
related works. In Sect. 8, we conclude our study.
nodes.
The main advantages of such centralization are:

2 SDN concepts and architecture • Centralized control and coordination Centralization

allows more efficient control of implementations and poli-
The main idea in SDN architectures is the total separation cies updates. It also helps to define better coherent policies
between the control plane and the data plane. Such separa- compared to the case where they are defined separately
tion allows logically centralized control to be implemented across several distributed network nodes;
regardless the size and the complexity of the network. The • Programmability Developers do not have to worry about
control in this context means not only monitoring, but also internal logic of network devices to produce new appli-
all types of network services including routing, switching, cations that meet specific needs. SDN networks therefore
quality of service, access control, etc. evolve in functionality more by software development than
Following are the most important limitations of traditional by hardware upgrade. The lifetime of hardware is pro-
network architectures: longed resulting in a net cost optimization;
• Openness It is very difficult to develop new network or
• Complexity Administrators must update the configuration security services around traditional architectures due to
of several network nodes for almost any change in the the fact that they rely exclusively on proprietary and closed
network; platforms. OpenFlow as the first standard designed specif-

123
Photonic Network Communications (2019) 37:1–23 3

Table 1 SDN security challenges (ONF)

Feature Challenge Area of protection

Centralized control Controller as high-value asset is a Availability: DoS/DDoS protection,

privileged target for attackers scalability and performance issues
access control
Programmability Traffic and resource isolation Access control
(multi-tenant traffic)
Trust between third party applications Authentication/authorization (access
and the controller control)
Interface security protection on A-CPI Access control: Authentication and
and I-CPI (intermediate-controller authorization
plane interface)
Cross-domain Prevent abuse and secure channel Authentication/authorization (access
connection control)

ically for SDN provides APIs to easily program nodes at of access control (authentication, authorization, traceability)
the infrastructure layer; and resilience protection (availability and integrity) of the
• Performance Controllers run on platforms that have much network and its critical components. This is quite logical
higher processing capability in comparison with those of considering the high dependence of the network to the con-
conventional switches and routers. Furthermore, the deci- troller, which must first be protected in terms of availability
sions of switching or routing are taken based on a complete and then by access control mechanisms against a wide range
view of the network rather than a partial view. of threats.
Likewise, an Internet-Draft Document issued in 2012 by
SDN architecture defines three layers: the Internet Engineering Task Force (IETF) [9] establishes
the security prerequisites between the application and con-
• Transmission layer (or data plane) Composed of net- trol layers in an SDN context where external applications
work devices (commonly called switches). Its main role is interact with the resources managed by the controller. In this
enforcement of flow rules configured by an external con- document, six security prerequisites have been defined cover-
troller; ing authentication, authorization management, applications
• Control layer (or control plane) Consisting of one or more isolation, identity management in the case of a proxy-mode
controllers running the cores of different network services. controller and privacy.
It also allows to hide the complexity of hardware’s detail On the other hand, Kreutz et al. argue that SDN poses secu-
in favor of the application layer; rity problems of a new nature. They detail these problems in
• Application layer Is an integration platform for applica- [10] according to seven threat vectors capable of exploiting
tions developed to implement new network services that intrinsic vulnerabilities specific to the SDN architecture. Of
meet specific needs. The applications exploit standardized these seven vectors, three are specific to SDN concept and
interfaces to communicate with the controller. arise precisely because of the separation of the control plane
from the data plane. These are attacks on control plane com-
munications, attacks on and vulnerabilities in the controllers
and lack of mechanisms to ensure trust between the con-
3 SDN security considerations
troller and applications. To address these threats, the authors
propose to adopt a security by design approach: controller
In this section, we describe the real and potential effects of
replication across multiple instances, controller diversifica-
changing the architectural design of networks (as defined
tion (types) and dynamic device association, which mean
by SDN) on security aspects. We then develop our security
the ability of a switch to associate with multiple controllers.
analysis scheme against which this survey was conducted.
They also propose to opt for automatic trust management
The technical report issued by the Open Network Founda-
mechanisms between the controller and applications. The
tion in its document ONF TR-511 “Principles and Practices
secure design proposed by the authors is therefore based on
for Securing Software-Defined Networks” [8], points out the
strengthening the resilience of the network by the diversified
security challenges specific to SDN as mentioned in Table 1.
redundancy of the controller (availability) as well as access
While the consequences of exploiting security vulnerabil-
control mechanisms.
ities in the SDN context are of very different types, the
proposed protection measures essentially concern the areas

123
4 Photonic Network Communications (2019) 37:1–23

Table 2 Security survey scheme

Security criteria SDN layer Risk Attack vector Possible
countermeasures

Availability/resiliency Control plane Controller as SPOF Crash of controller Secured design

Potential impact: (software or hardware) (eliminate SPOFs
unavailability of Performance issue: components, critical
service, disruption of inability of controller resources protection,
service to deal with high load strong authorization
Impact of third party scheme) [P]
(buggy) applications Controller redundancy
DoS/DDoS attacks (failover or load
balancing options) [R]
Continuous monitoring
[D]
DoS/DDoS protection
mechanisms [R]
Control plane/data plane Failure of controller and Link or device failures Secured design
network devices to Performance issue: link (associate the switches
deal rapidly with link or device saturation in failure detection
or device failures DoS/DDoS attacks and recovery function,
Potential impact: mesh topology with
unavailability of backups paths) [D, R]
service, disruption of Continuous monitoring
service [D]
DoS/DDoS protection
mechanisms [R]
Access control Control plane Access to controller by Poor authentication at Access control:
malicious applications northbound interface Authentication [P],
Potential impact: loss of level Authorization
integrity and management [R],
confidentiality of Audit [D]
network configuration
Access to controller by Poor authentication at Access control:
rogues devices southbound interface Authentication [P],
Potential impact: Loss level Authorization
of integrity and management [R],
confidentiality Audit [D]
Data plane Insertion of malicious Poor authentication at Access control:
flow rules by a rogue southbound interface Authentication [P]
controller level
Potential impact: loss of
integrity and
confidentiality
Consistency of Control plane/data plane Flow rules conflict and Poor authorization Access control:
security policy inconsistency of policy Authorization
security policy Excessive privilege management within
Potential impact: least privilege
security flaws approach [P, R]

In their OpenFlow vulnerability analysis, the Benton et al. • The controller’s ability to continue to operate in all cir-
[11] also stated that these two main aspects (availability and cumstances with satisfactory performances;
access control) are the main axes around which the SDN • The ability of the controller to deal with the failure of a
security must focus. network node or a link by maintaining a consistent and
Based on these various findings and as described in reliable forwarding state.
Table 2, our survey on SDN security will focus on the fol-
• Access control mechanisms The south and north commu-
lowing aspects:
nication channels are vulnerable to threats that may affect
the availability, performance, confidentiality and network
integrity;
• Network availability depends on:

123
Photonic Network Communications (2019) 37:1–23 5

• Integrity The consistency of security policy may be altered the literature. Basically, the three threats identified for the
through poorly managed applications authorizations (flow application plane concern access control and authorization
rules conflicts); management; for the control plane, availability is at the fore-
• The potential for improvement of classical security fea- front with access control in addition to scalability; for the
tures through the development of specific applications. data plane, access control, availability protection and access
control (authentication and authorization) are important. The
authors then list 9 advantages of SDN architectures com-
4 Related works pared to conventional security architectures ranging from
the opportunity to develop new security services through the
Several security surveys of Software-Defined Networks have API provided by the controller to the benefits of central-
been conducted in recent years. Yoon et al. [12] had inves- ized control that characterizes SDN (Flow sampling, content
tigated the attack surface of SDNs according to the analysis inspection, traffic monitoring, access control).
model based on the CIA triad (confidentiality, integrity and In [15], we find a survey dedicated to the opportunities
availability). They classify the critical assets of the SDN and challenges of the SDN concept in relation to detection
architecture according to three levels: control plane where and defense against DDoS attacks. The survey concludes that
they draw up a threat scheme that can target the controller there is a lack of a comprehensive method of protection that
as well as the applications, control channel (threats specific acts at the source of the attack.
to the OpenFlow channel between the controller and the
switches) and the data plane (threats targeting the network
nodes as well as the internal flow tables). For each threat, 5 Security by SDN
the authors give a list of vulnerabilities that may allow it to
materialize. At the same time, the authors disclose 12 new The total decoupling of control and data planes offers
vulnerabilities that have not yet been reported. We note that interesting opportunities that can be beneficial for security.
the new vulnerabilities reported mainly fall within the two Security in essence likes the centralization of control that is
axes of the intrinsic resilience of the controller (system time consistent with the basic idea of the SDN concept. Ali et al.
manipulation and malformed control message injection for [16] argue that the SDN paradigm improves network security
example) and that of access control (network service neu- especially in the area of detection, remediation and network
tralization due to lack of authorization and unauthorized correctness as well as security as a service. For example, it
application management due to lack of authorization for has been proven that an AAA access control policy loses effi-
example). The findings of this survey highlight the need for ciency when it is implemented in a decentralized way across
enhanced controller resilience (by design) to protect both its multiple network nodes. Relatively early, OpenFlow technol-
own critical resources and trusted applications through strong ogy was chosen to implement a new variant of Open Access
authentication and authorization control mechanisms. Scott- Networks (OAN) technologies called NAN (Neutral Access
Hayward et al. have published a broad survey of security Network) opting for a level 2 access approach in as part of the
in SDN [13] in which they enumerate seven main cate- NANDO project with value-added services like AAA access
gories issues and six main categories enhancements. Within control [17].
each category, threats or opportunities for improvement may Moreover, Dangovas et al. propose in [18] a system allow-
relate to one of the three layers of the SDN architecture (or ing both registration and authentication of switches by the
several at a time) as well as the two southbound and north- controller, authentication of machines and their binding to
bound channels. The authors refer in detail to the different corresponding switch ports, user authentication and data flow
researches that have dealt with each category while noting the management as well as user mobility. The contribution of the
absence of research works around two categories of problems SDN concept in this solution is the total mastery of the strict
(data leakage and data modification) and that consequently user/device binding as well as making it almost impossible
require more attention in the future. In relation to the security to bypass security checks which is a common problem in
contributions of the SDN concept, the authors note a lack classical architectures.
of consideration of the App-Control interface in the main Several studies have established that the centralization of
research work related to SDN security. They attribute this control that characterizes the SDN paradigm provides signif-
lack to the absence of a standard protocol dedicated to this icant advantages over conventional architectures, especially
interface and mention it as one of the aspects that require in terms of rapidity and accuracy of the detection of attacks
more studies in the future. as well as their neutralization [19–22]. In [23], an imple-
On their part, the Ahmad et al. [14] raise 11 types of threats mentation of the Frequency Sets Analyzer (FSA) concept
concerning the three layers of the SDN architecture while in SDN architecture is presented. While exploiting control
presenting the various solutions that have been proposed in centralization in SDN, this implementation divides the traf-

123
6 Photonic Network Communications (2019) 37:1–23

fic analysis load between two modules: local FSA (LFSA) works in an optimized fashion. The network administrators
at the switch level for rapid detection of threats that gen- are able to protect their network by writing a simple script.
erate large amounts of traffic, and Global FSA (GFSA) in In [29], the authors raise the classic issue of sources IP
the SDN controller for threats that cannot be detected at addresses validation, which is necessary to protect against
a single switch (stealth scanning for example). The GFSA a wide range of Internet attacks including IP spoofing and
module aggregates data received from LFSA modules and DoS attacks, by pointing out the inadequacies of the level
focuses on traffic that has not yet reported malicious activity of protection offered by SAVI solutions [30]. The authors
to avoid double detection that would penalize performance. propose Virtual Source Address Validation Edge (VAVE) that
In [24], the authors discuss how network defense services consists of a perimeter protection based on an OpenFlow
can be strengthened by exploiting SDN architecture to effi- switch within an OpenFlow/NOX architecture and a VAVE
ciently detect and block sophisticated DDoS attacks such application that analyzes the traffic based on a global view
as those that mobilize a large number of zombie machines and configures appropriates flow rules accordingly in case
sending each a small amount of seemingly legitimate traffic to of attack detection. Table 3 summarizes the main research
exploit certain application vulnerabilities. This kind of DDoS studies that have addressed opportunities to improve network
attack is difficult to detect by conventional network devices. security by exploiting the features of the SDN concept.
Indeed, a DDoS Blocking Application (DBA) specifically
developed to interact with servers subject to DDoS attacks.
In case of attack detection, the servers send a notification
to DBA and receive instructions from it to redirect traffic
6 Security of SDN
to another IP address representing a backup instance of the
same server. DBA also interacts with the controller to install
6.1 Availability
the flow rules needed to block malicious traffic. In [25], an
approach leveraging the global flow monitoring enabled by
The network is probably the component of the information
the SDN architecture to granularly control the variations of
system infrastructure most concerned by the availability cri-
the IP addresses (sources and destination) in order to quickly
terion. Service disruptions in production environments are
detect DDoS attacks is developed.
often caused by network problems. The reasons for the
The Chaitanya and Medhi [26] present FlowTrApps, a
unavailability of the network are numerous and of various
DDoS detection and mitigation approach that uses some
natures ranging from simple link or network device failure
bounds on two per flow-based traffic parameters (flow rate
to sophisticated attack like DDoS.
and flow duration). It attempts to detect attack traffics ranging
Traditionally, this issue has been addressed by the design
from low rate to high rate as well as long-lived to short-
of a mesh network topology in which federation components
lived attacks using an SDN engine. Besides, Bawany et al.
are redundant. In Software-Defined Networks, availability
have proposed ProDefense [27], a framework based on SDN
requires special attention, especially with regard to the crit-
technology, to proactively protect applications developed for
ical element that is the controller. Based on the principles
smart cities against DDoS attacks. ProDefense is designed
of security by design as well as in-depth security based on
with the idea that security needs differ between applications
the prevention–detection–reaction approach, we discuss the
according to their degree of criticality; this dictates the degree
problem of availability in SDN networks, as described in
of agility of the solution to be chosen (proactive or reactive
Fig. 2, in four main axes: intrinsic resilience of the con-
approach). The custom detection of attacks in ProDefense is
troller, redundancy and replication mechanisms, data plane
based on Exponentially Weighted Moving Average (EWMA)
resiliency and prevention against availability attacks includ-
filters. Indeed, the module Policy Engine, responsible for the
ing DDoS attacks.
definition of the attack detection policy, is used to configure
the adequate filter according to the criticality of the applica-
tion. Three filters are possible: highly reactive filter HR for
very low false-negative rate of attack detection and proactive 6.1.1 Availability aspects in OpenFlow specification
approach, intermediate reactive IR for solutions that neither
react before time nor delay the alert and least reactive LR for Many of the features mentioned in the OpenFlow specifica-
very low false-positive rate of attack detection and reactive tion serve (directly or indirectly) the availability objective.
approach. ProDefense supports many mitigation strategies We will focus in this section on those that are explicitly
including dropping packet, blocking ports and traffic redi- related to availability.
rection. The Shin and Gu [28] propose CloudWatcher that Failover and load balancing modes in multi-controller
provides dynamic monitoring of network flows in cloud net- environments are specified through some specific messages
[31]. The following messages refer directly to this aspect:

123
Photonic Network Communications (2019) 37:1–23 7

Table 3 Main research works on security by SDN

Area Research work Opportunity Main idea

Attacks and [20] Better performances and more Four anomaly detection algorithms
unauthorized accuracy in detection of malicious (TRW-CB, rate limitation, Maximum
activities detection activities in home office/small office Entropy Detector and NETAD) are
and mitigation networks deployed in NOX controller by exploiting
the standardized programmability of SDN
[22] Overcoming the limitations of Exploiting centralization control to gather
traditional IDS/IPS by exploiting statistical information from Switches with
SDN features the use of self-organizing maps (SOM) and
Artificial Neural Networks to detect
suspicious traffic
[23] Efficient and reliable detection and Implementation of the Frequent Sets Analyzer
reaction of various network attacks (FSA) concept within an SDN application
and its exploitation to quickly detect threats
and react against them by configuring
appropriate flow rules at the Switch level
DDoS protection [24] Overcoming the limitations of DDoS Blocking Application (DBA) running
traditional approaches to detect on the controller and communicating with
DDoS attacks by botnet that exploit the protected server. When protected server
application’s vulnerabilities notify DBA about an actual DDoS attack,
the application instruct it to redirect traffic
to another IP address (with CAPTCHA
protection) and install flow rules on the
Switches to block malicious traffic
[21] DDoS attack detection with lower Exploiting centralization control to gather
overhead compared to traditional statistical information from Switches with
approaches the use of self-organizing maps (SOM) and
Artificial Neural Networks (to detect hidden
relations among flows entering the network)
to detect suspicious traffic
[25] Detect DDoS attacks leveraging on Granular control of source and destination IP
SDN’s flow monitoring capability addresses to detect DDoS attacks
[26], Exploiting central control over the An SDN framework for datacenters which use
FlowTrApps network (i.e., global view) provided some bounds on two per flow-based traffic
by SDN to facilitate the detection of parameters (flow rate and flow duration of a
DDoS attacks flow) to detect and mitigate DDoS attacks
against data center applications
[27], Overcoming the disadvantages of Customizing DDoS protection strategy
ProDefense traditional approaches to detect (detection and mitigation) according to
DDoS attacks by botnet application requirements
Access [18] Combining SDN features with existing An extension of Floodlight controller with a
control/network network architecture to strengthen module to register and authenticate
management network access control switches, authenticate hosts and bind them
to switches, to authenticate users, and to
manage flows and user/host mobility
[28], Cloud- Enforce network security policy on all SDN application that monitor, control and
Watcher flows enforce redirection of all network flows
through relevant security services
[29], VAVE Solving source address validation Using OpenFlow devices to form a protective
problem using OpenFlow protocol perimeter that redirect any new packet that
does not match any existing flow rule to a
specific application. The detection
mechanism is based on known flow paths
between OpenFlow devices
[17], NANDO Securing Access Networks Using Deployment of a Neutral Access Network
OpenFlow characteristics based on OpenFlow switches with add
value security services

123
8 Photonic Network Communications (2019) 37:1–23

Controller 1 Controller 2 OF Switch

Packet-In

Flow mod

Packet-Out

Keep-alive Failure detecon

me

Interface down
Fail detecon

OFPT_ROLE_REQUEST Role-change me

OFPT_ROLE_REPLY

Packet-In
Failover me
Flow Mod
Packet-Out

Fig. 3 Design of a control procedure for recovery [32]

flow tables at the moment of the connection failure even if

Fig. 2 SDN availability this state may not be up-to-date during the failure duration.
All packets and messages destined to the controllers are lost
and flow entries continue to expire according to their time-
• OFPT_ROLE_REQUEST the controller informs the outs. In the case of Switches supporting both OpenFlow and
switch that it changes its role. The new role is indicated by legacy protocols, fail-standalone mode could be the alterna-
the value of role field of the message. tive allowing a switch to act autonomously like any legacy
• 0: indicate that there is no role change; network device by using OFPP_NORMAL reserved port.
• 1: the controller is active in sense that it has a read/write Regarding performances, which are considered as a fun-
access on the switch (load balancing configuration); damental feature of the availability, some features were
• 2: the controller is active and acts at the same time as the introduced since 1.4.0 version to allow network device to
master for the cluster of controllers (only one controller react to a situations threatening availability. Freeing space
can act as a master at a time); for new entries when flow table is full is defined as eviction
• 3: the controller is passive in sense that it has only read mechanism and helps to mitigate the effects on performance
access on the switch (failover configuration). of such situation. In a more proactive manner, “vacancy
event” aims to send a message to the controller to alert it
• OFPT_ROLE_REPLY this message is sent of the impending saturation of the flow table based on a pre-
from the switch to the controller as a reply to defined threshold.
OFPT_ROLE_REQUEST message. The structure of Finally, the specification, through the Group Table func-
the message is similar to that of the previous one but with tionality, extends the OpenFlow configuration rules to enable
a value of role field that corresponds to the new role of advanced features, especially one that is intended to address
controller. availability issues. It relates to the liveliness monitoring of
the switch ports status to detect and react, as fast as possible,
Each controller must continuously monitor the state of the to failures of nodes or links. The OFPPC_PORT_DOWN
others to be informed as soon as possible when the master of bit of ofp_port_config message communicates the port sta-
them becomes unavailable in order to change its role conse- tus to the controller, while the OFPPS_LINK_DOWN bit
quently. It must be noted here that this issue is not covered of ofp_port_state communicates information on the status
by OpenFlow specification. Figure 3 shows the progress of of the link. The exploitation of Fast Failover Table Group is
a simple scenario using keep-alive messages for such moni- intended to enable the switch to respond to the failure of a
toring [32]. port or a link without having to return to the controller.
Connectivity issues between network device and con- Through the different versions of the OpenFlow specifi-
troller are also considered a serious threat for availability of cation, the requirements for the availability and performance
the network. This situation, in purely SDN networks, is even have been improved. However, the specification focuses
more problematic as the switch is totally dependent on the mainly on the support of several controllers by the OpenFlow
controller for any decision-making. The OpenFlow specifica- switch and the various related messages exchanged with the
tion defines two modes of operation of the Switch following controller. The synchronization of the cluster’s configura-
the loss of connection with the controller: fail secure and fail tion through the different controllers must be implemented
standalone. In fail secure mode, the switch continues to act by appropriate mechanisms that are not covered by the spec-
as an OpenFlow device using the configuration’s state of its ification.

123
Photonic Network Communications (2019) 37:1–23 9

6.1.2 Intrinsic resilience of the controller OpenFlow OpenFlow

controller 1 controller 2
Role: Master Role: Slave
Keep-alive messages
Availability in SDN is highly dependent on the controller Control plane

and therefore relies on its intrinsic resiliency. The design of

the controller’s defensive mechanisms against the various
events that may affect its normal functioning is the cor- Secure channel
nerstone of its resilience. In [33], the authors demonstrate, Physical connecon
with concrete examples of exploits on some popular con- Data traffic
trollers (Floodlight, OpenDaylight, POX and Beacon), that Asynchronous message
Data plane

the design of most controllers does not meet the intrinsic

robustness requirements that exist in other operation sys-
tems (lack of application isolation from controller resources, Fig. 4 MASTER/SLAVE controller
lack of application control, monolithic architecture). Indeed,
simple modifications performed on services running at the
application layer are able of seriously disrupting the con- Moreover, Yoon et al. report in a recent study [12] new
troller’s operation, or even blocking it completely. Through flaws that concern the intrinsic resilience of the controller. For
Rosemary, a network operating system with the primary goal example, they demonstrate that by manipulating some system
of enhancing controller resilience against compromised or time variables, the controller can become confused and gen-
malicious applications, the same authors present a protection erate errors in some operations that depend these variables
approach based on sandboxing and execution of applications (as in the case of packet timeouts calculation). The authors
within virtual environments with strict rules of isolation and state in this regard that the referencing untrusted external
access control to critical resources of the controller. variables could widen the attack surface of SDN controllers
On their part, Chandrasekaran et al. propose LegoSDN and advocate a design that avoids the use of external variables
[34], another solution to protect controller from the con- as they may be the target of specific attacks.
sequences of applications failures, fail-stop crashes and
byzantine failures. It consists of a redesign of the controller 6.1.3 Controller as single point of failure
to support isolation between applications and controller and
between applications with each other’s. LegoSDN consists One of the fundamental characteristics of SDN architecture
of two key components: is the introduction of controller as the only smart component
of the network. Therefore, the availability of network rests
• AppVisor An isolation technique (derived from OS archi- mainly on the availability of the controller. Redundancy in
tecture) that defines fault and resource allocation bound- such situations is naturally the first security measure to be
aries to protect controller’s resources from buggy SDN- taken as shown in Fig. 4.
Apps; Controller redundancy and its effects on availability and
• Netlog This module ensures that a set of actions (that performance was the subject of a number of research papers.
belong to a unique policy) is applied in an atomic manner The Nencioni et al. [35] present a study on the effect of the
(all or nothing). It also applies rollback actions if neces- number of controllers, their connectivity and their locations
sary and stores all relevant information about any flow rule within the network on availability. This study establishes
(timeout, counter…) before deleting it. the decisive effect of redundancy while demonstrating that
too many backup controllers (from three controllers in the
For the detection of applications failures, LegoSDN uses mentioned scenario) increase the operating cost without nec-
Crash-Pad, a system that provides failure detection and essarily improving the availability. In [36], we also find a
recovery support. It takes permanently a snapshot of SDN- study on the optimal number of controllers to be implemented
Apps to be restored if necessary. within a network but from a point of view impact on latency
Rosemary and LegoSDN are among the most serious rather than fault tolerance. The study establishes that in most
efforts that have addressed the resiliency of the control plan cases of medium-sized networks, only one controller is suf-
against threats that may come from the application plan. ficient to achieve the performance objectives.
LegoSDN focuses on the effects of application bugs and In the load balancing scenario with multiple controllers,
instabilities, while Rosemary also addresses the risks of it should be noted that it is important to adopt a proper load
malicious applications. For both solutions, there are still balancing and failover strategy to prevent the effects of cas-
improvements to be made for broader threat type coverage as cading failures of multi-controllers [37]. This is a potential
well as a better performance/security compromise especially scenario in which the backup controllers are unable to handle
in large networks. the load of a failed controller, which may eventually lead to

123
10 Photonic Network Communications (2019) 37:1–23

the failure of all controllers (due to the progressive and uncon- instructions of the controller. This situation can also saturate
trolled accumulation of the load of the failed controllers), and the switch–controller communication channel; indeed, when
the entire network consequently. The authors propose an opti- the switch memory is full, it sends the entire packet to the
mal strategy of load balancing to avoid such a problem with controller instead of just the headers under normal circum-
the definition of some important criterion and requirements, stances. The impact of such a situation on bandwidth can also
e.g., tolerance parameter, balancing initial load among all lead to a partial denial of service. It can also have a negative
controllers and load redistribution after a failure. impact on the performance of the controller itself.
Furthermore, the redundancy of the controllers requires Giotis et al. present in [41] an approach that detects and
the implementation of a synchronization mechanism of the mitigates DDoS attacks and other types of threats such as
controller cluster in order to guarantee the most reliable and worm propagation and port scanning by the combination
transparent recovery of the operation of the network. of OpenFlow with the sFlow protocol for data gathering.
CPRecovery for example proposed by the Fonseca et al. The adoption of sFlow for sampling and collection instead
[38] consists of a simple primary/backup replication mech- of OpenFlow’s native approach is dictated by the desire to
anism with the objectives of keeping two controllers in reduce the amount of data collected for analysis, particularly
active/passive mode. The three components, CPRecovery, in large networks. Regarding detection, for which the authors
Messenger and Switch, interact to ensure that the cluster con- opt for an entropy-based algorithm, the impact of sFlow sam-
figuration is continuously maintained in a consistent state. pling on the degree of accuracy of detection remains to be
CPRecovery has been tested on several primary controller evaluated. Note in this regard that we find in SDN practically
unavailability scenarios such as crash of the controller as a the same detection techniques used in conventional networks,
user process from an OS perspective, application malfunc- the most common are:
tion and DDoS attack. In the last scenario, the resilience
of the network also depends on the existence of a DDoS • Machine learning-based techniques Data correlation and
attack detection mechanism since the attack can also tar- feature extraction using techniques such as Bayesian net-
get the secondary controller. However, it is not mentioned works, SOM and fuzzy logic to detect the presence of
whether CPRecovery can evolve in order to anticipate ser- anomalies [21, 42, 43];
vice shutdowns by switching according to the response time • Entropy-based techniques Focus on the degree of random-
of the main controller. ness of incoming flows (source IP address, destination IP
On their side, the Botelho et al. [39] advocate a logically address, port number…) during a predefined time period
centralized SDN architecture with several controllers, within [41, 44].
a decentralized SDN architecture, sharing a fault-tolerant
data store (based on the State Machine Replica model) con- On their part, Wang et al. analyze the impact of DDoS pro-
taining consistently the network status data. Outsourcing tection solutions on normal traffic. They propose FloodGuard
network state data from controllers, similarly to what is done [45], an extension of the controller that can both act against
in the case of server clusters in SAN architectures, consider- DDoS attacks while ensuring continuity of service at the data
ably simplifies synchronization of controllers. plan level during attack periods by using the proactive flow
rules analyzer module. This analyzer uses an approach that
6.1.4 DoS/DDoS attacks against SDN combines symbolic execution and dynamic application track-
ing to proactively configure flow rules at the network nodes
Although the centralization of control supported by the SDN to relieve the controller of the need to process Packet-In mes-
paradigm can, as seen previously, offer a real opportunity sages during a DoS attack. To avoid sacrificing normal traffic
to improve network security, it adds potential flaws that during this period, the authors propose the use of the Packet
can be targeted by malicious attacks such as DOS/DDoS migration module which transfers table-miss messages to a
attacks [40]. The most obvious is the saturation of controller cache component at the data plane level and then sends them
resources to make the entire network unavailable. Other to the controller at a limited rate to preserve its performances.
types of DDoS attacks can target the data plane, such as
the saturation of the switch’s TCAM memory by the mas- 6.1.5 Fast failure recovery (data plane resiliency)
sive sending of table-miss packets, which forces the switch
to buffer them while sending Packet-In messages to the con- Network resilience is defined by the network’s ability to deal
troller and waiting as a response for as many Flow-mod or with various events that negatively impact its normal func-
Packet-out messages as Packet-In messages sent. This situa- tioning. Service disruption due to links or devices failures
tion will lead to the saturation of the resources of the switch is the most obvious example of such events. First of all,
either by the amount of data buffered or by the large number although links or devices failures may appear as an issue
of flow rules to be inserted into the flow table according to the that is not directly related to network security, we consider

123
Photonic Network Communications (2019) 37:1–23 11

that it is useful to address it since the impact of such events is objective of AFRO) and the rapid detection of the failure
the total or partial unavailability of network services (or per- by the controller which may not be an easy task, particu-
formance degradation). The ability of the network to recover larly in complex networks. The Van Adrichem et al. [51]
quickly from network nodes and links failures in accordance propose, on their part, an approach (more complete since it
with predefined requirements is among key objectives of deals with both detection and recovery) that exploits Open-
maintaining network availability (e.g., recovery from fail- Flow’s Fast Failure Group Table feature to set preconfigured
ure within 50 ms sub interval in the carrier-grade networks backups paths, ready to use, in case of link-failure and the
[46]). use of Bidirectional Forwarding Detection protocol (BFD)
Overall, there are two strategies for data plane resiliency [52] to enable faster detection of the failure by the controller.
in an SDN environment, restoration and protection. The The main idea of this approach is to give the switches certain
restoration strategy consists of calculating and configuring autonomy to react instantaneously (without consulting the
the backup path after the failure has been detected, while controller) to link-failure incidents until the controller (once
that of protection pre-configures the backup paths before the notified) recalculates the new optimal forwarding state. This
occurrence of the failure so the switches know in advance ensures stronger network resilience since there is no down-
of alternative path to use. In [47], the authors show that time even if the preconfigured paths may not be the optimal
the restoration strategy, although less consuming of network paths at the time of the incident. As for the detection, the
node resources (smaller flow table), is not able to provide a authors base their solution on BFD but introduce the notion
service restoration that meets carrier-grade network require- of per-link BFD (rather than per-path BFD) meaning that
ments (beyond 100 ms instead of less than 50 ms for the each switch constantly monitors the state of the links with
recovery time from a failure). the adjacent switches rather than the state of end-to-end paths.
Kuzniar et al. [48] propose AFRO (Automatic Failure
Recovery for OpenFlow) which is based on the total decou- 6.1.6 Concluding remarks/discussions
pling between functional logic of controller and failure
recovery logic. The codes of controllers written to cover the The landscape of threats that can lead to service disrup-
two functions are more subject to errors and bugs (the code tions has continued to evolve in recent years. The transition
becomes longer and more complex), and thus to more inci- of the control plane from a distributed but proprietary sys-
dents of availability. tem to an open and logically centralized system is likely to
AFRO introduces a new instance of controller called expose this plane to new availability challenges. The first
shadow controller whose main role is the calculation of line of defense and best strategy in this direction must be
the correct forwarding state of the network with a particu- preventive (strengthen intrinsic resilience). This is the case
lar failure. Shadow controller performs this calculation in of several research projects that have dealt with the prob-
a totally virtualized environment equivalent to the real net- lem (Table 4). We mentioned in particular Rosemary [33]
work topology with the particular failure. Therefore, the time and LegoSDN [34] as they propose an approach based on a
needed to calculate the new forwarding state is significantly redesign of the controller to improve its ability to deal with
reduced compared to the case where the operation should various types of external threats that may impact its nor-
be accomplished on a real environment. Recalculation is mal operation. More analysis and tests remain necessary to
performed simply by processing Packet-IN messages pre- evaluate, and thus limit, the impact of such extensions on
viously recorded (under normal circumstances) in a virtual controller performance. Also, the two systems focus only
environment equivalent to that resulting from the failure. on the effects of application behavior without taking into
The main idea of AFRO consists of relieving controller account the vulnerabilities specific to the controller itself.
from some tasks and delegates them to other components To the best of our knowledge, there is little research in the
(shadow controller). We also find this principle in OpenState literature that addresses the intrinsic resiliency issue of the
SDN Project [49] which stipulates that we can take advan- controller in a comprehensive way. Therefore, we argue that
tage from the level of intelligence contained in OpenFlow this is an important subject that needs to be deepened in
switches to reduce the duration of the recovery. The same future research in accordance with the fundamental princi-
principle is defended in [50] but by providing the switch ple of security (resiliency) by design.
with the functionality of end-to-end connectivity monitoring Regarding the controller as single point of failure, the flag-
to allow the controller to be unloaded from this task necessary ship palliative action is to make it redundant. This is the
for the failure recovery process. preferred action to deal with accidental crashes or perfor-
Another observation concerning AFRO is that it does not mance degradation during periods of high load. However,
address the problem of time of failures detection. The accel- controller redundancy is not the optimal solution for deal-
eration of the failure recovery process assumes both rapid ing with malicious attacks since the backup controller may
recalculation of the new forwarding state (which is the main also be targeted by the same threat (mechanisms for intrinsic

123
12 Photonic Network Communications (2019) 37:1–23

Table 4 Major research on the availability of SDN networks

Area Research work Issue Main idea

Intrinsic resilience of [33], Rosemary Impact of buggy/malicious Sandboxing and protection of controller
controller application on controller resources
[34], LegoSDN Impact of applications failures, Protection of critical resources of controllers by
fail-stop crashes and using an isolation technique
byzantine failures on
controller
Resilience of data [48], AFRO Fast failure recovery Separation between functional logic of controller
plane and failure recovery logic. A shadow controller
is dedicated for failure recovery function
(support both restoration and protection
strategies)
[50] Fast failure recovery Relieving controller from some monitoring
functions needed recovery failure and
implementing of these functions on the network
nodes
[51] Fast failure recovery A failover mechanism based on per-link
Bidirectional Forwarding Detection and
OpenFlow’s Fast Failure Group Table feature to
set preconfigured backups paths
Controller [37] Cascading failures of Definition of optimal strategies of load balancing
redundancy–Repli- controllers to avoid such a problem with the definition of
cation–synchro- some important criterion and requirements,
nization e.g., tolerance parameter, balancing initial load
among all controllers, load redistribution after a
failure
[36] Effect of multiple controller on Recommendations (based on experiments) on the
latency optimal number of controllers by network size
[38], Controller as a single point of Configuration consistency between two nodes of
CPRecovery failure a controller cluster primary/backup using a
synchronization mechanism based on three
components (CPRecovery, Messenger and
Switch)
[39] Controller as a single point of Logically centralized SDN architecture with
failure several controllers, within a decentralized SDN
architecture, sharing a fault-tolerant data store
DDoS protection [41], DoS due to controller overload Optimizing the volume of data collected (for
OpenFlow during OpenFlow statistics anti-DDoS analysis) using sFlow and detection
and sFlow collection of attacks based on an entropy-based algorithm
combination
[21] Problem of accuracy detection Using self-organizing map (SOM) to classify
of DDoS attack in a timely traffic as normal or suspicious based on
manner features of traffic flow
[45], How to limit the impact of Proactive flow rules analyzer to guarantee the
FloodGuard traditional anti-DDoS policy enforcement during attack and migration
solutions on normal traffic? table-miss packets to a data plane cache
component before transmitting them to the
controller with a limited rate

resiliency are more appropriate in this case). We have referred Other key considerations in this pane are the number of con-
to some of the most relevant studies and researches on this trollers to configure within a topology, their locations within
topic and discussing their differences and complementarity the topology, the load balancing strategy and the replication
[35, 36, 38, 39]. The proposed solutions depend on the archi- mechanisms.
tecture as well as the size of the network and vary from a Regarding the availability aspect related to network device
centralized and full redundant system to a decentralized sys- or link failures, it is noted that the network resilience depends
tem with strategies for load balancing and fault tolerance. much more on the degree of mesh of the network than on

123
Photonic Network Communications (2019) 37:1–23 13

SDN Layer

SDN SDN SDN

Idenficaon Authencaon Authorizaon Audit Applicaon Applicaon Applicaon
• Basic prerequisite • Prevenve • Correcve • Deerent
for the following • Compensave • Detecve
phases
• Compensave

Northbound interfaces

SDN Controller
Fig. 5 Access control phases and security measures
Southbound interfaces

the type of network [53] (backup paths can be computed and Network Switch Network Switch Network Switch Network Switch
configured before the incident, in both SDN and conventional
Network Switch Network Switch Network Switch
networks). There is a wide consensus that a purely centralized
Physical network
SDN architecture is not advantageous for the function of
failure detection and recovery especially in the case of large
networks. The main researches to which we referred suggest Fig. 6 Two types of interfaces of the controller
unloading, at least partially, the controller of the fast failure
recovery function (by the mechanism of shadow controller Indeed, in the absence of a proper authentication mecha-
in [48], by the pre-configuration of paths of backups at the nism, the centralization of the control functions operated by
level of switches in [49, 51] and by extending the OpenFlow SDN allows any attacker having access to the management
switch software with end-to-end path monitoring capabilities network, to act at any moment on the switch settings and
in [50]). configure the production network as desired.
It is also possible for an attacker to stand as a man-in-the-
6.2 Access control middle to filter the commands of a legitimate controller as
well as notifications of various events sent by the switch to
Controller has theoretically no limit on its access rights to the controller.
the nodes of the data plane. As in the case of availability, In addition, it may also be possible, in a scenario of
security of the network depends closely of the security of the two controllers (master/slave), to exploit an authentication
controller which is, in the first place, an access control issue. deficiency to conduct denial of service attacks against the
An access control policy in accordance with the state of the controller. An attacker who could spoof the identity of a slave
art perfectly illustrates the principle of security in depth. In controller, by sending the message OFPT_Role_Request,
order to provide effective protection, security controls must can position himself as a master controller or at least pre-
cover all phases of the access control process, namely identi- vent a legitimate controller to change its status as master
fication, authentication, authorization and traceability by an controller.
optimal combination of different types of measures: preven- In their vulnerability analysis of OpenFlow, the Benton
tative, detective, corrective, compensatory and deterrent (as et al. [11] have placed the lack of adoption of TLS by ven-
shown in Fig. 5). Our analysis scheme for this security axis dors at the top of the list of vulnerabilities that can facilitate
will take into account these principles at the two controller the materialization of a large number of threats. Their analy-
interfaces (southbound and northbound) as shown in Fig. 6. sis, focused on OpenFlow version 1.3.0, showed that the vast
majority of controllers and OpenFlow switches on the mar-
ket do not support TLS in a way capable of ensuring secure
6.2.1 Securing southbound access implementations. This situation can be explained by the com-
plexity of the TLS implementation because of the complexity
Any authentication deficiency in both directions of south of managing the life cycle of certificates and cryptographic
channel could lead to introduction of illegitimate components keys. Ali et al. also add in [16] that using of SSL/TLS for
(switches or controllers). The OpenFlow specification states small devices such as sensor nodes is impractical and that
that the south channel can be established using TLS protocols there is a lack of more simple and secure alternatives.
or directly over a TCP connection without any encryption We add here that until the OpenFlow specification 1.5.0
level [31, 54]. (December 2014), no requirement on the TLS version to be
The use of TLS ensures confidentiality and integrity of used was mentioned. The latest version of TLS (1.2) fixes
the data exchanged in addition to the authentication that is several vulnerabilities detected in previous versions [55]. The
mandatory for the controller and optional for the switch. This version 1.5.1 of OpenFlow (released in March 2015) has not
is, in theory, the only mechanism capable of providing an brought significant improvements in this direction; it simply
adequate level of protection. recommends the use of TLS 1.2.

123
14 Photonic Network Communications (2019) 37:1–23

This version additionally specifies the ability to config- credential which means a reasonable degree of identification
ure the switch with a certificate to enable certificate-based and consequently of non-repudiation. AuthFlow has been
authentication with the controller. Again, the specification tested using a simple authentication method (MSCHAP v2
gives no details neither about the version of certificates to with an LDAP directory) but can be used with more complex
use nor on the required fields for mutual authentication. Sup- authentication methods like EAP-TLS.
port of CA certificates and certificate revocation lists (CRLs)
is optional. These specific needs to secure environments by 6.2.2 Securing northbound access
using public key infrastructures (based on X509 V3 standards
as the most suitable standard to ensure compliance with a cus- Having emphasized the consistency of security policy as a
tomized security policy) are even more obvious and urgent in major benefit of SDN networks, we actually assumed a purely
SDN environments and especially in multi-controllers envi- SDN environment free from middleboxes (applying dynamic
ronments where the authentication scheme becomes more and independents actions) that compete with the controller as
complex. Consequently, it appears extremely important to a brain of the network regarding specific services. In practice,
dedicate a full specification to the security of the southbound this configuration is not realistic at least in the short term. We
interface due to its criticality to ensure the resilience of the are still far from being able to do without certain proprietary
SDN architectural model [54]. security solutions. Although there are some solutions that
In the following, we give an overview of some research address this issue as FlowTags [59], we will in the follow-
related to access control in the southbound channel. Namal ing assume a purely SDN environment in which all network
et al. propose in [56] OFHIP (OpenFlow Host Identity Pro- and security services are managed exclusively through the
tocol), which is the integration between OpenFlow and HIP controller.
as a simpler and more secure alternative to the adoption Although the programmability of SDN networks via the
of TLS/DTLS especially in a high mobility environment. northbound interface can promote the development of new
OFHIP uses Encapsulation Security Payload (ESP of IPSec) security services as will be detailed in the next section, it
and offers approximately the same security services as can also offer a new attractive entering point for attackers to
SSL/TLS (end-to-end encryption, mutual authentication and introduce malicious applications.
secure key exchange) and also takes advantage from the more It is also possible that legitimate applications produce flow
interesting performances of cryptographic operations spe- rules in conflict with each other, which will have a negative
cific to the Elliptic Curves Cryptosystem algorithm (ECC). impact on network integrity. Here, the term “integrity” relates
OFHIP also offers an identity management solution based more precisely to the consistency of the network configura-
on a cryptographic namespace that uses addresses with the tion resulting from the coexistence of multiple applications
same format as IPv6 addresses. of different natures within the same network. The controller
Yu et al. discuss in [57] the problem of access control should incorporate functions dedicated for evaluation of the
in large SDN networks. The question the authors are trying relevance of produced flow rules with the current aggre-
to answer is how to minimize the impact of any failure of gate policy. It must also ensure in this regard an arbitration
access control mechanisms. For this reason, they propose a role between competitive applications. It is particularly in
hierarchical architecture consisting of several levels of con- multi-application environments with improper management
trollers between the root controllers (assumed to be of a high of permissions and authorizations where the risk is high that
level of trust) and the switches while dividing the control flow rules from different applications may create complex
load and management functions between the different levels. interdependencies or even conflicts.
It is mainly this load sharing that contributes to confining The integrity and consistency of SDN network security
the effects of unauthorized access to a local and restricted policy can be affected by two main types of threats:
level. Nevertheless, the authors emphasize the need for more
research to better address access control issue in large and • Intentional Through malicious or compromised applica-
heterogeneous SDN networks. tions;
The Mattos et al. [58] propose AuthFlow, a solution for • Accidental Through legitimate applications that are poorly
the strengthening of access control of machines (worksta- controlled in terms of privileges and authorizations.
tions or switches) to the SDN network. The idea is to prevent
any machine that has not met the requirements of authenti- In both cases, the protection of the integrity or consis-
cation based on 802.1X/Radius from accessing the network. tency of the network security policy is an authentication
In this scheme of access, privileges are granted based on and authorization management issue at northbound inter-
the access credentials profile instead of IP or MAC address. face level. Strong authentication is able to reduce the risk of
One of the most important contributions of AuthFlow is the introducing malicious or compromised applications, whereas
definition of forwarding rules based on the authentication the rigorous management of authorizations helps to reduce

123
Photonic Network Communications (2019) 37:1–23 15

alteration (intentional or unintentional) caused by excessive It is important to master the most relevant data exchanged
privileges. between the application layer and the infrastructure layer.
A number of studies have focused on this issue. In [60], Table 5 presents the most significant messages.
the authors propose OperationCheckpoint, which consists The mediation schema defines 4 policies:
of a permissions management system for applications. The
goal is to ensure that malicious or compromised applications • RCA (rule-based conflict analysis) This policy should be
cannot perform unauthorized actions (whether read or write applied to any message from the application layer to the
operations). OperationCheckpoint defines an access control infrastructure layer that consists of the addition of a new
scheme that focuses on applications identification require- flow rule or replacement of an existing flow rule. The addi-
ments (including uniqueness to ensure non-repudiation in tion or substitution should not conflict with an existing rule
addition of the detection and prevention of malicious activ- from an application belonging to a role of higher level than
ities) as well as the different privileges that applications that of the concerned application. The result is a stricter
can benefit from. It also focuses on traceability through control of the coherence of the security policy on the basis
the systematic logging of any illegitimate operation with of a strategy that is more role-oriented than discretionary.
the necessary details. It is noted for [60] that although the The conflict occurs when a candidate flow rule applies
authors raise the issue of flow rules conflict from legitimate action inconsistent with another already stated by an exist-
and authorized applications, OperationCheckpoint proposed ing rule (blocking, forwarding, redirection…). RCA policy
does not include a dedicated mediation module to solve this is applied mainly to rule Flow-mod messages and concerns
problem. all application roles;
We find almost the same approach of permissions manage- • Public Read Mediation policy for the events notified by
ment in PermOF [61] with the addition of system permissions network nodes to applications. These events do not affect
in order to protect the critical resources of the controller the flow tables in the infrastructure layer, but feed appli-
during application–controller interaction according to least cations with necessary information for their tasks. This
privilege principle. model defines two permission policies:
On their part, the Porras et al. [62] propose a more com-
plete approach based on a hierarchy of applications according • Global Read For events in the data plane which are
to three levels of role. This makes it possible to prioritize the notified to all interested applications (Flow removal
flow rules depending on the role attributed to the application messages and Flow error reply);
that produced the rule. The roles are: • Selected Read Refer to specific events for which some
applications have registered with the controller to be
notified (Barrier replies, Packet-In return, Switch con-
• ADMIN This role is assigned to static security rules defined fig reply, Switch stats report and Echo replies);
by the network administrator and hold the highest level of
priority. No other application can produce flow rules that
Public read policy restricts read access privileges of the
contradict them. A firewall security policy type dividing
applications on the network devices to a strict minimum nec-
the network into several zones with different levels of trust
essary for the fulfillment of their tasks. The state of the art
governed by Access Control Lists is a typical example of
of security stipulates that the application of least privilege
this role;
principle is fundamental to limit the damage that can result
• SEC-APP This role is assigned to applications that pro-
from accidental, error or unauthorized use [63].
vide security services that can produce dynamic flow rules
in response to threats identified at a particular time (high
priority but less than ADMIN role’s priority). For instance • Permission Case of operations that require explicit per-
the Network Admission Control (NAC), Data Loss Pre- mission before being allowed. These operations directly
vention, Intrusion Prevention System…; alter the flow management policy at the switch or allow
• APP (non-security applications) This role is assigned to the operator to control the configuration of the switch or
applications managing various network services and hold test its connectivity (Barrier request, Packet-Out, Switch
a normal priority (routing, load balancing, QoS…). port mod, Switch port status, Switch set config, Switch
get config, Switch stats request, Echo request, Vendor
A “control layer” is added to the controller; it applies a features and Vendor actions). Here again, the goal is to
mediation scheme on the data exchanged between the appli- limit the privileges of applications to operations required
cation layer and infrastructure layer. This scheme is designed for the accomplishment of their duties.
to preserve the integrity of the network configuration by
evaluating the consistency of the flow rules produced with The operations are no longer managed equally or in a man-
existing policy before allowing their implementation. ner that does not take into account their impact on security

123
16 Photonic Network Communications (2019) 37:1–23

Table 5 Mediation policies for

Flow direction Data exchange operation Mediation Policy Minimum authorization
data flows between Data and
Application layers [59] Application Flow rule mod Rule conflict analysis APP
layer → Infrastructure Barrier requests Permissions APP
layer
Packet-Out Permissions SEC
Switch port mod Permissions ADMIN
Switch set config Permissions ADMIN
Switch get config Permissions APP
Switch stats request Permissions APP
Echo request Permissions APP
Vendor actions Permissions ADMIN
Infrastructure Flow removal messages Global Read APP
layer → Application Flow error reply Global Read APP
layer
Barrier replies Selected Read APP
Packet-In return Selected Read APP
Switch port status Permissions ADMIN
Switch config reply Selected Read APP
Switch stats report Selected Read APP
Echo replies Selected Read APP
Vendor features Permissions ADMIN

policy consistency. It is the criticality of the operation and its that research of conflicts does not penalize performances, a
potential impact that defines what applications can initiate it synthetic representation of the flow rules is required. The rule
according to a multi-level role-based access control scheme. chains (set of interdependent rules or rules linked with each
It is possible, for flexibility reasons, to extend the schema of other, e.g., rule whose actions is to change headers “Set” or
roles by defining new roles or sub-roles by grouping some redirect flows to other tables) are aggregated to optimize the
specific operations. process of analysis and conflict detection. This algorithm is
In this sense, the Porras et al. [62] propose a security based on that named Alias-set Rule Reduction (ARR) [64]
kernel within Floodlight controller with authentication and having been implemented in the security kernel for NOX
authorization role-based management module. In fact, we controller.
can consider that it is a complete access control module as it is Finally, and taking into account the importance of audit
responsible for the identification, authentication, authoriza- trails as a valuable source of information in the mastery of
tion and audit trails management during any subject–object events impacting the stability of SDN networks, Floodlight
interaction. The subject in this model corresponds to the security kernel includes an audit trail management module. It
application and the object is the network device. is vital to be able to identify which application is the author of
The security kernel also incorporates an algorithm for what flow rule. This module was designed to satisfy the most
detecting and resolving conflict called Rule-chain Conflict significant traceability requirements according to the TCSEC
Analysis (RCA). To evaluate each new flow rule, the kernel standard of the US DoD. All relevant events in terms of the
must have a comprehensive and accurate view of the rules consistency and integrity of the network configuration are
of all flow tables at every switch, with respect to which he logged (time, message type, message content, application’s
is called to assess the consistency of the new flow rules to credentials…). The audit strategy provides “system halt pol-
be inserted. To have this precise view, continuously updated, icy” type policies required in military environments which
in addition to information about the authorization roles of consist to completely stop the control plan processing in the
applications that produces each flow rule, two modules State case where the system is no longer able to record more events
table Manager and Switch callback tracer are used. They due to performance issues (Fail safe Strategy).
constantly ensure the synchronization of data between the In conclusion, Floodlight security kernel (SE-Floodlight)
security kernel and flow tables of network devices. The notion provides the basis for an excellent approach to SDN security
of conflict is closely related to the concept of application role; that can be generalized on all other controllers. It is also a sig-
therefore, these two modules are also interested by the iden- nificant improvement compared to FortNOX [64] (developed
tity of the application that generated the rules as information for NOX controller), which does not address traceability and
to be recorded in the state table of the security kernel. In order audit aspects (Table 6).

123
Photonic Network Communications (2019) 37:1–23 17

Table 6 Main research works on access control in SDN networks

Interface Area Research work Issue Main idea

Southbound Authentication [57] Enhance network Hierarchical model of the SDN

channel resilience by a strong network around multi-tiered
Northbound authentication scheme controllers to limit the impact of
channel authentication problems
Identification/ [58], AuthFlow Authentication and Performing authentication at the
Authentication/ authorization of hosts Data Link Layer and pairing the
Authorization and network nodes identity of host with the flows
created by itself on the network.
The proposed mechanism is
based on IEEE 802.1X and
Extensible Authentication
Protocol (EAP)
Identification/ [56], OFHIP Meet identification and Integration between OpenFlow and
Authentication authentication HIP v1 to offer a simpler
requirements in high alternative to SSL/TLS in order
mobility network to guarantee an authentication
environments level as strong as TLS but much
less complex. HIP also offers a
global identifier whose format is
similar to that of IP v6
Northbound Identification/ [60], Opera- Problematic of the level A permission management system
Channel Authentication/ tionCheckpoint of trust granted to to restrict control operations to
Authorization/Audit applications only authorized applications
(only unauthorized
operations)
Authorization [61], PermOF Limitation of excessive A system with a set of permissions
privileges granted to and isolation mechanism to limit
applications developed application’s privileges during
by third parties interaction with network
infrastructure
Identification/ [64], FortNOX Detecting and A role-based authorization system
Authentication/ reconciling potentially used to prioritizing flow rules
Authorization conflicting flow rules from applications which
from OpenFlow incorporate a live rule conflict
applications detection engine
Identification/ [62], SEK- Protection of the A complete access control solution
Authentication/ Floodlight network security by a that includes identity scheme,
Authorization/Audit full access control authentication service, role-based
mechanism authorization, inline flow rule
conflict resolution and security
audit services

Regarding the performance aspect, it is difficult at this the way to attacks that can exploit the weaknesses of access
stage, to decide on the latency introduced by the Floodlight control mechanisms to introduce rogues components or to
security kernel as the tests performed on it have involved conduct unauthorized actions. Seen clearly the disastrous
a very simple environment consisting of one switch. It is impact of such scenarios, it is obvious that access control
necessary, for getting a clearer idea on the impact of security constitutes a major challenge for the security of SDN.
kernel on performance, that the state table includes flow rules Through the various versions of the OpenFlow specifica-
from multiple switches. tion, the requirements have been increasingly strengthened
in order to use TLS as the communication and authentication
protocol using X509 certificates at the southbound interface.
6.2.3 Concluding remarks/discussion Nevertheless, it should be pointed out that a specification
dedicated to the security of the southbound interface remains
The SDN concept promotes the openness of networks. It strongly desired at this stage.
introduces for this purpose two new crucial components that
are the controller and applications. It opens consequently

123
18 Photonic Network Communications (2019) 37:1–23

Regarding the researches that have been conducted on this • Low-level programming interface;
aspect, we find that the majority of them focus on authenti- • Two-Tiered system architecture;
cation and authorization management [56–58]. OFHIP [56] • Network race condition.
differs from the others by the fact that it also addresses the
issue of identification in a mobility context while offering To cope with these different challenges, the authors pro-
a simpler alternative to TLS for authentication management pose Frenetic, a high-level programming language whose
and security of data exchanged at the southbound channel. design offers a high level and declarative network query
As regards the northbound interface, we have referred language. Developers can create custom services without
to a number of researches focused on this issue. We have having to know the low-level details specific to the hardware.
explained the different requirements specific to access con- Frenetic also integrates a runtime system that guarantees con-
trol in [60–62, 64]. SEK-Floodlight [62] has been presented sistency and non-overlapping of the flow rules from different
and commented in detail as it offers a more complete applications.
access control approach. Indeed, according to the state of In a more security-oriented registry, we find FatTire
the art of security, it is a comprehensive approach based [67], which consists of a declarative programming language
on strengthening the various mechanisms of access con- designed to allow developers to write applications that meet
trol processes throughout these four fundamental steps: fault tolerance requirements (especially links or nodes fail-
identification, authentication, authorization and audit. More ures). It is inspired by NetCore language [68] while adding
importantly, the concept of role, which has been adopted in specific attributes for paths and regular expressions as well as
SE-Floodlight for the management of authorizations, allows annotations for fault tolerance. Compiling FatTire programs
the security to take full advantage of the centralization of con- aims to translate policies expressed as regular expressions
trol. Otherwise, the adoption of a discretionary approach to and fault tolerance requirements into directly configurable
the management of the security (which is incompatible with flow rules at the network nodes. For each policy, forwarding
the role concept) would have been equivalent to traditional graphs are constructed by using a NetCore extension as well
decentralized architectures. as atomic policy construction operations and subsequently
translated into NetCore policies.
6.3 Network security services programmability Shin et al. [19] propose a framework called FRESCO
(Framework for Enabling Security Control in OpenFlow net-
As stated earlier in this paper, the controller has permanently works) that aims to facilitate the development of security
a complete view on the traffic in the network. From a security applications specific for SDN environments. The goal of
point of view, this has a significant advantage since this gives FRESCO is meet the following challenges:
the opportunity to create services that implement consistent
security policies. However, the creation of mature security
services around OpenFlow requires the use of frameworks • Simplification of development of security services;
specifically designed for this purpose [65]. Most applications • Deficiency of useful security data gathered by the con-
running on the production implementations involve traffic troller;
engineering services. The OpenFlow actions most used by • Enforcement of the response to threats at the network node
such services are simple such as forward via port or drop. The level.
majority of available controllers were designed based on this
vision (mainly traffic engineering requirements) and there- The main components of FRESCO are:
fore do not offer some features needed for security services
(e.g., redirection of flows, quarantining, etc.). In addition, the • API for scripting;
only mandatory actions defined by OpenFlow specification • Sixteen reusable modules (written in python): several secu-
are Drop, Forward and Group. Set action is optional, and it rity features are provided by assembling these modules;
is precisely very useful in many security features. • FRESCO-DB: database for storage and management of
There is also a lack of programming languages with a high session’s information.
level of abstraction and modular programming to facilitate
the development of value-added security services.
In [66], the authors discuss the difficulties of programming FRESCO leverages set action by decomposing it into three
general network services (not just security services) around sub-actions, each relating to a particular security need as
the SDN architecture. The main problems they enumerate shown in Fig. 7:
are:
• Redirect Used to redirect traffic to a specific destination,
• Interactions between concurrent modules; e.g., redirect traffic to a proxy server;

123
Photonic Network Communications (2019) 37:1–23 19

Event Furthermore, within FRESCO DE, FRESCO scripting

a. Input o Acon
language enables developers to instantiate and defines
Parameter b. Output o Drop the interactions between predefined security modules
Input
Funcon…
Output c. Parameter o Forward (Python modules) to develop a new security functions.
d. Acon o Group
Finally, FRESCO-DB is used to store various kinds of
Acon
networks and switch state information. For any instance
Module e. Event o Set
o Redirect to get specific information, it has simply to request the
o Mirror FRESCO-DB;
o Quaranne

• Kernel layer FRESCO-SEK (Security Enforcement Ker-

Fig. 7 Security module elements and actions [19] nel): FRESCO manages security-oriented applications that
must coexist with other types of applications (such as
Development Resource traffic engineering). To manage the priority of the flow
environment controller
rules from these different applications, FRESCO-SEK
Applicaon layer OF applicaon OF applicaon
implements a priority management and arbitration strat-
egy identical to the one described in the previous section
(Securing northbound interface).
NOX Kernel layer (FortNOX)
(Controller)
In conclusion, FRESCO is primarily intended to simplify
the development of new advanced security services within
OpenFlow enabled networks. First, in terms of design, we
find that the resource controller (FRESCO-RC) belongs to
the application layer and at the same time, in some cases
Fig. 8 FRESCO’s architecture [19] (such as when the flow table is full), it ensures the enforce-
ment of flow rules at the switch’s flow table. The controller,
• Mirror Used to send a copy of traffic to another compo- through the FRESCO-SEK module, is best placed to decide,
nent for specific analysis (e.g., Intrusion Detection System, on the basis of a centralized security policy, about the flow
Provenance Verification Point…); rules of lower priority that need to be evicted. This will ensure
• Quarantine Insulation network traffic (infected mail, better compliance with the principle of segregation of duties
machine which is not in compliance with security poli- by dedicating control tasks exclusively to control layer rep-
cy…). resented by the Security Enforcement Kernel.
It is also conceivable to take advantage of advances in new
versions of OpenFlow to adopt more proactive approach to
Figure 8 illustrates the architecture of FRESCO which can
address the problem of saturation of the flow tables (vacancy
be described as follow:
events instead of eviction mechanism as discussed in the
first section). On another side, the design, including the 16
• Application layer consists of two main components,
predefined and extensible modules, not only greatly facil-
FRESCO development environment (DE) and FRESCO
itates the development of new security services, but also
resource controller (RC):
reduces errors made during the coding phase which can
• FRESCO resource controller (RC) Monitor the Open- have a negative impact on security. Finally, a major contri-
Flow switches and keeps track of their status. It collects bution of the FRESCO framework, which will undoubtedly
in a timely manner all data needed for various security be the main reason for its success, is the decomposition of
applications. It is also responsible for the immediate Set action defined by OpenFlow specification. Indeed, this
insertion of flow rules issued by the FRESCO applica- action, which is still optional according to the specification,
tions (security services with high level of priority). It can implement complex policies that are useful for security.
applies for that, an eviction mechanism on obsolete or Compared with other solutions such as [66, 69, 70], it
low priority rules when necessary (Switch monitor and should be noted that FRESCO is unique in that it is the only
garbage collection); one designed specifically to develop security applications; it
• FRESCO development environment (DE) Consists of is precisely for this reason that we have detailed above its
several tools and useful data to design and develop secu- operation and commented in detail on its design. Voellmy
rity controls. From 16 reusable modules that incorporate and Hudak [69] address in a more general way the problem
several classical security functions, one can aggregate of application development in the SDN environments and
them to create complex network defense applications. propose Nettle that is based on the concept Functional Reac-

123
20 Photonic Network Communications (2019) 37:1–23

tive Programming (FPR). Frenetic [66], Procera [70] and of flow rules). Access control mechanisms are critical in this
FatTire [67] provide declarative query language frameworks register and all phases (Identification, Authentication, Autho-
for managing distributed OF switches, describing high-level rization and Audit) must be taken into account to ensure deep
packet forwarding and specifying network policies. Frenetic protection (prevention, detection and response). In this sense,
is distinguished by a runtime system that converts rules into SE-Floodlight offers a model for a reinforced controller that
non-overlapping policies before ordering the controller to will be useful to enrich its role-based application prioritiza-
configure corresponding flow rules at the switch level. In tion scheme. Indeed, we can imagine scenarios where we
[71], Canini et al., propose NICE, an OpenFlow application need to make a distinction between the priority levels of
testing framework combining model checking with symbolic applications within the same hierarchical level (DLP applica-
execution in order to detect bugs and evaluate the resilience tion compared to a mail flow scan application for example).
of applications in relation to events and constraints specific It is also important to evaluate the performance impact of
to the network. such improvements to achieve a better security/performance
trade-off.

7 Discussions
8 Conclusion
Experience has shown that security cannot be made effective
without an approach that optimally combines both preven- After a number of successful implementations of SDN net-
tive and reactive measures. Our survey scheme took into works in production environments, this new technology is
account this observation by scrutinizing in detail the intrin- now expected to prove its resiliency in security before it can
sic resilience and access control axes in the literature with be adopted at a large scale. This is mainly due to the fact that
regard to best practices relating to the security of systems experience has shown that major changes that profoundly
and architectures. As long as the design of the components affect systems design (like one concerning the architectural
of the SDN architecture does not integrate security as a fun- design of networks in the case of SDN concept) often gen-
damental need early enough, it will result in it being an easy erate bad surprises in matter of security. The customers,
target for threats that evolve in both number and type. For therefore, will not accept to adhere without strong guar-
example, the lack of implementation of TLS (due to its man- antees that security aspects will be managed and enforced.
agement complexity) is raised by almost all research works We tried in this article to discuss, in relation to the state
on SDN security; however, it is still rare to find research that of the art, current major SDN security concerns with some
has proposed alternatives secure and simpler (e.g., OFHIP proposed solutions. We have adopted an approach that com-
which is designed to meet mobility needs). On the other prehensively covers both the relevant security criteria for
hand, it is also strongly desired that the OpenFlow speci- SDN networks and all layers defined in its architectural
fication defines in more detail the security requirements in model. It emerges that there is still need to strengthen security
a separate document dedicated to this purpose. The intrin- mechanisms around the SDN concept to enhance its intrinsic
sic resilience of the controller is also a fundamental criterion resilience.
of the preventive security approach (which must, according
to the best practices, be the preferred approach) to mitigate
the SPOF effect introduced by the SDN concept. This aspect References
requires more in-depth studies of the best way to provide
the controller with internal security mechanisms (includ- [1] Casado, M., Garfinkel, T., Akella, A., Freedman, M.J., Boneh, D.,
ing strengthening authentication and privilege control at the McKeown, N., Shenker, S.: SANE: a protection architecture for
northbound interface) to deal with a wide range of threats enterprise networks. In: USENIX Security Symposium (2006)
[2] Casado, M., Freedman, M.J., Pettit, J., Luo, J., McKeown, N.,
(whether malicious or accidental). Rosemary and LegoSDN Shenker, S.: Ethane: taking control of the enterprise. In: ACM
can be mentioned in this pane with broader threat coverage SIGCOMM Computer Communication Review, vol. 37, no. 4,
in the case of Rosemary that aims to protect against threats pp. 1–12. ACM (2007)
from malicious applications as well as the effects of buggy [3] Jain, S., Kumar, A., Mandal, S., Ong, J., Poutievski, L., Singh, A.,
Venkata, S., Wanderer, J., Zhou, J., Zhu, M.: B4: experience with
applications on the controller. However, we find that glob- a globally-deployed software defined wan. In: Proceedings of the
ally, there is a lack of consideration of the vulnerabilities ACM SIGCOMM 2013 Conference, pp. 3–14. ACM (2013)
specific to the controller as a threat vector against its intrin- [4] Natarajan, S., Ramaiah, A., Mathen, M.: A software defined cloud-
sic resilience. On the other hand, it is necessary to take into gateway automation system using OpenFlow. In: 2013 IEEE 2nd
International Conference on Cloud Networking (CloudNet), Nov
account the inevitable evolution of applications, in both num- 2013, pp. 219–226
ber and type, at the application layer and its potential risk on [5] ACI Fabric Endpoint Learning White Paper. https://www.cisc
the integrity of the network (competition and prioritization o.com/c/en/us/solutions/collateral/data-center-virtualization/ap

123
Photonic Network Communications (2019) 37:1–23 21

plication-centric-infrastructure/white-paper-c11-739989.html, [22] Jankowski, D., Amanowicz, M.: Intrusion detection in software

document ID: 1514948434204104. Accessed 22 Jul 2018 defined networks with self-organized maps. J. Telecommun. Inf.
[6] McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Peter- Technol 4, 3–9 (2015)
son, L., Rexford, J., Shenker, S., Turner, J.: OpenFlow: enabling [23] Cabaj, K., Wytr˛ebowicz, J., Kukliński, S., Radziszewski, P., Dinh,
innovation in campus networks. ACM SIGCOMM Comput. Com- K.T.: SDN architecture impact on network security. Warsaw Uni-
mun. Rev. 38(2), 69–74 (2008) versity of Technology, Warsaw (2014)
[7] Rajasri, K., Srikanth, K., Kingston, S., Bhaskar, R.: SDN and [24] Lim, S., Ha, J., Kim, H., Kim, Y., Yang, S.: A SDN-Oriented DDoS
OpenFlow tutorial. https://www.clear.rice.edu/comp529/www/pa Blocking Scheme for Botnet-Based Attacks. School of Informat-
pers/tutorial_4.pdf. Accessed 20 Apr 2018 ics Korea University, Next Communication Research Laboratory
[8] Open Networking Foundation: Technical report ONF TR-511. ETRI, Daejon (2014)
Principles and Practices for Securing Software-Defined Net- [25] Yang, X., Liu, Y.: DDoS attack detection under SDN context. In:
works, January 2015. https://www.opennetworking.org/images/ Proceedings of IEEE International Conference on Computer Com-
stories/downloads/sdn-resources/technical-reports/Principles_a munications IEEE (INFO COM16), San Francisco, USA (2016).
nd_Practices_for_Securing_SoftwareDefined_Networks_applie https://doi.org/10.1109/infocom.2016.7524500
d_to_OFv1.3.4_V1.0.pdf. Accessed 14 Jun 2018 [26] Chaitanya, B., Medhi, N.: FlowTrApp: an SDN based architec-
[9] Hartman, S., Wasserman, M., Zhang, D.: Security requirements ture for DDoS attack detection and mitigation in data centers. In:
in the software defined networking Model draft-hartman-sdnsec- Proceedings of 3rd International Conference on Signal Processing
requirements-01. IETF (2012). https://tools.ietf.org/html/draft-ha and Integrated Networks, Noida, India (2016). https://doi.org/10.
rtman-sdnsec-requirements-01. Accessed 15 Jun 2018 1109/spin.2016.7566750
[10] Kreutz, D., Ramos, F., Verissimo, P.: Towards secure and depend- [27] Bawany, N., Shamsi, J., Salah, K.: DDoS attack detection and
able software-defined networks. In: Proceedings of 2nd ACM mitigation using SDN: methods practices and solutions. Arab J
SIGCOMM Work. Hot Topics in Software Defined Networks, Sci Eng (2017). https://doi.org/10.1007/s13369-017-2414-5
pp. 55–60 (2013) [28] Shin, S., Gu, G.: CloudWatcher: network security monitoring
[11] Benton, K., Camp, L.J., Small, C.: OpenFlow vulnerability assess- using OpenFlow in dynamic cloud networks. In: IEEE Interna-
ment. In: Proceedings of the Second ACM SIGCOMM Workshop tional Conference on Network Protocols, Austin, USA, 2012,
on Hot Topics in Software Defined Networking. ACM, 2013, pp. 1–6. https://doi.org/10.1109/icnp.2012.6459946
pp. 151– 152 [29] Yao, G., Bi, J., Xiao, P.: Source address validation solution with
[12] Yoon, C., Lee, S., Park, H.K.T., Shin, S., Yegneswaran, V., Por- OpenFlow/NOX architecture. In: Proceedings of 19th IEEE ICNP,
ras, P., Gu, G.: Flow wars: systemizing the attack surface and 2011, pp. 7–12
defenses in software-defined networks. IEEE/ACM Trans. Netw. [30] IETF SAVI Working Group: https://tools.ietf.org/wg/savi/.
25, 3514–3530 (2017). (ISSN: 1063-6692) Accessed 5 Jun 2018
[13] Scott-Hayward, S., Natarajan, S., Sezer, S.: A survey of security [31] Open Networking Foundation: OpenFlow switch specification.
in software defined networks. IEEE Commun. Surv. Tutor. 18(1), Version 1.4.0 (Wire Protocol 0x05), October 14, 2013. Version
623–654 (2016). https://doi.org/10.1109/comst.2015.2453114 1.5.1 (Wire Protocol 0x05), March 26, 2015
[14] Ahmad, I., Namal, S., Ylianttila, M., Gurtov, A.: Security in soft- [32] Kuroki, K., Matsumoto, N., Hayashi, M.: Scalable OpenFlow
ware defined networks: a survey. IEEE Commun. Surv. Tutor. Controller redundancy Tackling Local and Global Recoveries.
17(4), 2317–2346 (2015) Integrated Core Network Control And Management Laboratory,
[15] Xu, X., Yu, H., Yang, K.: DDoS attack in software defined net- KDDI R&D Laboratories, Inc., Saitama (2013)
works: a survey. http://kns.cnki.net/kcms/detail/34.1294.TN.201 [33] Shin, S., Song, Y., Lee, T., Lee, S., Chung, J., Porras, P., Yeg-
70912.1054.002.html, published online September 12, 2017 neswaran, V., Noh, J., Kang, B.B.: Rosemary: a robust, secure,
[16] Ali, S.T., Sivaraman, V., Radford, A., Jha, S.: A survey of securing and high-performance network operating system. In: Proceedings
networks using software defined networking. IEEE Trans. Reliab. of the 21th ACM Conference on Computer and Communications
64(3), 1086–1097 (2015) Security (CCS), 2014.
[17] Matias, J., Jacob, E., Toledo, N., Astorga, J.: Towards neutrality in [34] Chandrasekaran, B., Benson, T.: Tolerating SDN application fail-
access networks: A NANDO deployment with OpenFlow. In: The ures with LegoSDN. In: Proceedings of the 13th ACM Workshop
Second International Conference on Access Networks ACCESS on Hot Topics in Networks, p. 22. ACM (2014)
2011 [35] Nencioni, G., Helvik, B.E., Gonzalez, A.J., Heegaard, P.E.,
[18] Dangovas, V, Kuliesius, F.: SDN-driven authentication and Kamisínski, A.: Impact of SDN Controllers Deployment on
access control system. In: The International Conference on Dig- Network Availability. Department of Telematics, Norwegian Uni-
ital Information, Networking, and Wireless Communications versity of Science and Technology, Trondheim (2017)
(DINWC2014). The Society of Digital Information and Wireless [36] Heller, B., Sherwood, R., McKeown, N.: The controller placement
Communication, pp. 20–23 (2014) problem. In; Proceedings of the First Workshop on Hot Topics in
[19] Shin, S.W., Porras, P., Yegneswaran, V., Fong, M., Gu1, G., Software Defined Networks, ser. HotSDN’12, pp. 7–12. ACM
Tyson, M.: FRESCO: modular composable security services for (2012)
software-defined networks. In: Proceedings of Annual Network [37] Yao, G., Bi, J., Guo, L.: On the cascading failures of multi-
and Distributed System Security Symposium (NDSS), San Diego, controllers in software defined networks. In: Proceedings of 21st
CA, USA, February 2013 IEEE ICNP, October 2013, pp. 1–2
[20] Mehdi, S.A., Khalid, J., Khayam, S.A.: Revisiting Traffic [38] Fonseca, P., Bennesby, R., Mota, E., Passito, A.: A replication
Anomaly Detection Using Software Defined Networking. Recent component for resilient OpenFlow-based networking. In: Network
Advances in Intrusion Detection. Springer, Berlin (2011). https:// Operations and Management Symposium (NOMS), 2012 IEEE.
doi.org/10.1007/978-3-642-23644-0_9 IEEE (2012)
[21] Braga, R., Edjard, M., Alexandre, P.: Lightweight DDoS flood- [39] Botelho, A., Ramos, F.M.V., Kreutz, D., Bessani, A.N.: On the
ing attack detection using NOX/OpenFlow. In: 2010 IEEE 35th feasibility of a consistent and fault-tolerant data store for SDNs. In:
Conference on Local Computer Networks (LCN). IEEE (2010). 2013 Second European Workshop on Software Defined Networks
https://dx.doi.org/10.1109/LCN.2010.5735752 (EWSDN) ,pp. 38–43. IEEE (2013)

123
22 Photonic Network Communications (2019) 37:1–23

[40] Shin, S., Gu, G.: Attacking software-defined networks: a first [57] Yu, D., Moore, A.W., Hall, C., Anderson, R.: Authentication
feasibility study. In: ACM SIGCOMM Workshop Hot Topics Soft- for Resilience: The Case of SDN. ser. Security Protocols XXI,
ware Defined Network (HotSDN13), Hong Kong, China, 2013, pp. 39–44. Springer, Berlin (2013)
pp. 165–166 [58] Mattos, D.M.F., Duarte, O.C.M.B.: AuthFlow: authentication and
[41] Giotis, K., Argyropoulos, C., Androulidakis, G., Kalogeras, D., access control mechanism for software defined networking. Ann.
Maglaris, V.: Combining OpenFlow and sFlow for an effective and Telecommun. 71(11-12), 607–615 (2016)
scalable anomaly detection and mitigation mechanism on SDN [59] Fayazbakhsh, S., Sekar, V., Yu, M., Mogul, J.: FlowTags: Enforc-
environments. Comput. Netw. 62(5), 122–136 (2014). https://do ing network-wide policies in the presence of dynamic middlebox
i.org/10.1016/j.bjp.2013.10.014 actions. In: Proceedings of the Second Workshop on Hot Topics
[42] Kokila, R.T., Selvi, S.T., Govindarajan, K.: DDoS detection and in Software Defined Networks. ACM, 2013
analysis in SDN based environment using support vector machine [60] Scott-Hayward, S., Kane, C., Sezer, S.: OperationCheckpoint:
classifier. In: Proceedings of IEEE Sixth International Conference SDN Application Control. In: 22nd IEEE International Confer-
on Advanced Computing, Chennai, India (2015). https://doi.org/ ence on Network Protocols (ICNP). IEEE, 2014, pp. 618–623
10.1109/icoac.2014.7229711 [61] Wen, X., Chen, Y., Hu, C., Shi, C., Wang, Y.: Towards a secure
[43] Barki, L., Shidling, A., Meti, N.: Detection of distributed denial controller platform for openflow applications. In: Proceedings of
of service attacks in software defined networks, In: Proceedings the Second ACM SIGCOMM Workshop on Hot Topics in Soft-
of IEEE International Conference on Advances in Computing, ware Defined Networking, pp. 171–172. ACM (2013)
Communications and Informatics (ICACCI), Jaipur, India, 2016, [62] Porras, P., Cheung, S., Fong, M., Skinner, K., Yegneswaran, V.:
pp. 2576–2581. https://doi.org/10.1109/icacci.2016.7732445 Securing the software-defined network control layer. In: Pro-
[44] Wang, R., Jia, Z., Ju, L.: An entropy-based distributed ceedings of the 2015 Network and Distributed System Security
DDoS detection mechanism in software-defined networking. Symposium (NDSS), February 2015
In: IEEE Trustcom/BigDataSE/ISPA, Helsinki, Finland, 2015, [63] Langford, J.: Implementing Least Privilege at your Enterprise.
pp. 310–317. https://doi.org/10.1109/trustcom.2015.389 SANS Institute. July 5, 2003. https://www.sans.org/reading-roo
[45] Wang, H., Xu, L., Gu, G.: FloodGuard: a dos attack prevention m/whitepapers/bestprac/implementing-privilege-enterprise-118
extension in software-defined networks. In: Proceedings of the 8. Accessed 30 May 2018
45th Annual IEEE/IFIP International Conference on Dependable [64] Porras, P., Shin, S., Yegneswaran, V., Fong, M., Tyson, M., Gu, G.:
Systems and Networks DSN’15, 2015 A Security Enforcement Kernel for OpenFlowNetworks. Texas
[46] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., Ueno, A&M University, College Station (2012)
S.: MPLS-TP requirements, RFC-5654, IETF, 2009. https://tools. [65] Shin, S., Porras, P., Yegneswaran, V., Gu, G.: A framework for
ietf.org/html/rfc5654. Accessed 23 May 2018 integrating security services into software-defined networks. In:
[47] Sharma, S., Staessens, D., Colle, D., Pickavet, M., Demeester, P.: Proceedings of ONS, 2013, pp. 1–2
OpenFlow: meeting carrier-grade recovery requirements. Com- [66] Foster, N., Harrison, R., Freedman, M., Monsanto, C., Rexford,
put. Commun. 36(6), 656–665 (2013) J., Story, A., Walker. D.: Frenetic: A Network Programming
[48] Kuzniar, M., Perešíni, P., Vasic, N., Canini, M., Kostic, D.: Language. In: ACM SIGPLAN International Conference on Func-
Automatic failure recovery for software-defined networks. In: tional Programming, 2011
Proceedings of the Second ACM SIGCOMM Workshop on Hot [67] Reitblatt, M., Canini, M., Guha, A., Foster, N.: FatTire: Declara-
Topics in Software Defined Networking, Hong Kong, China, tive Fault Tolerance for Software-Defined Networks, HotSDN’13,
August 16, 2013 August 16, 2013, Hong Kong, China
[49] Bianchi, G., Bonola, M., Capone, A., Cascone, C.: OpenState: Pro- [68] Monsanto, C., Foster, N., Harrison, R., Walker, D.: A compiler and
gramming platform-independent stateful OpenFlow applications run-time system for network programming languages. SIGPLAN
inside the switch. SIGCOMM Comput. Commun. Rev. 44(2), Not. 47(1), 217–230 (2012)
44–51 (2014) [69] Voellmy, A., Hudak, P.: Nettle: Functional Reactive Programming
[50] Kempf, J., Bellagamba, E., Kern, A., Jocha, D., Takacs, A., Skold- of OpenFlow Networks. In: Yale University Technical Report,
strom, P.: Scalable fault management for OpenFlow. In: IEEE 2010
International Conference on Communications (ICC), 2012 [70] Voellmy, A., Kim, J., Feamster, N.: Procera: A Language for
[51] van Adrichem, N.L., van Asten, B.J., Kuipers, F.A.: Fast recovery High-Level Reactive Network Control. In: Proceedings of ACM
in software-defined networks. In: EWSDN ’14 Proceedings of the Sigcomm HotSDN Workshop, 2012
2014 Third European Workshop on Software Defined Networks, [71] Canini, M., Venzano, D., Peresini, P., Kostic, D., Rexford, J.:
September 2014, pp. 61–66 A NICE way to test OpenFlow applications. In: Proceedings of
[52] D. Katz, D. Ward, “Bidirectional Forwarding Detection, RFC- the 9th USENIX Conference on Networked Systems Design and
5880”, IETF, 2010 Implementation, 2012
[53] Schehlmann, L., Abt, S., Baier, H.: Blessing or curse? Revisiting
security aspects of software-defined networking. In: Interna-
tional Conference on Network and Service Management (CNSM),
pp. 382–387 (2014) Jaouad Benabbou is network and telecom-
[54] Sezer, S., Scott-Hayward, S., Chouhan, P.K., CSIT, Queen’s Uni- munication engineer and professional of com-
versity Belfast, Fraser, B., Lake, D., Cisco Systems, Finnegan, puter security. Certified Information Secu-
J., Viljoen, N., Netronome, Miller, M., Rao, N., Tabula.: Are we rity Manager (CISM) of ISACA (Information
ready for SDN? Implementation challenges for software-defined Security Audit and Control Association) in
networks. IEEE Commun. Mag. 51(7), 36–43 (2013) which he is an active member since 2007. He
[55] Network Working Group, RFC 5246.: The Transport Layer Secu- is also Certified Information System Security
rity (TLS) Protocol Version 1.2 Professional (CISSP) of the ISC2 (Interna-
[56] Namal, S., Ahmad, I., Gurtov, A., Ylianttila, M.: Enabling secure tional Information System Security Certifica-
mobility with OpenFlow. In: Proceedings of IEEE SDN4FNS, tion consortium) in which he is also an active member since 2013.
2013, pp. 1–5 Former Chief Information Security Officer at the Ministry of Inte-
rior in Morocco, he is currently Head of the Information System

123
Photonic Network Communications (2019) 37:1–23 23

Security Department within RADEEMA (Morocco). His researches Noureddine Idboufker received a Ph.D.
interests focus on the Information System Security. He is also certi- degree in Computer Sciences; he is currently
fied ISO27001 Lead Implementer and Auditor and member of AFAI a Professor at ENSA-Marrakesh belonging
(French Association of IT Auditors). to the Moroccan University Cadi Ayyad.
From 1996 to June 2006, he was working
as an R&D engineer Maroc Telecom. He
worked on several projects, especially in the
Khalid Elbaamrani received his Ph.D. in IP field such as MPLS, QoS and ADSL. His
Telecommunication Engineering from the main research includes SDN, QoS, QoE and
University of Cadi Ayyad, Marrakech, constrained-based routing.
Morocco, in 2005. He is presently working as
an Assistant Professor in the ENSA of Mar-
rakech, University of Cadi Ayyad, Marrakech,
Morocco. His research interests include
packet switching architectures/algorithms,
networked systems, especially Software-
Defined Networks, digital communication theory.

123