Loading...Software-Defined Networking Control Challenges and Countermeasures: A survey
Abstract—
I. I NTRODUCTION
Security if a constant moving target, it shouldn’t come as a
surprise that cybersecurity is a different beast than it was 10,
or even 5 years ago. While traditional cyber threats such as
adware and spam emails are certainly still alive and kicking,
the threat surface has grown enormously with the advent of
Internet of Things (IoT) and cyber physical systems [20],
mobility, bring your own device (BYOD), and the cloud. It’s
a basic equation the more interconnected we get, the more
devices, the more digital traffic there is, control declines,
the more crevices there are for cyber threats to exploit
[23]. IoT is an information network of physical objects
(sensors, machines, cars, buildings, and other items) that
allows interaction and cooperation of these objects to reach
common goals over a network [14]. Applications include
among others smart cities, transportation, healthcare, smart
homes, smart grid and industrial environments [18].
Fig. 1 depicts the comparison of high level transformation
of traditional networking architecture and SDN architecture.
SDN is regarded as the hardware independent next gen-
eration networking paradigm in which networking device
from any vendors could be controlled through SDN. SDN
has decoupled data plane and control plane. The control
mechanism provided by SDN can lower the complexity
of IoT Computing architectures and implementations by
bringing novel approach to the networking and utilizing the
available resources in a more efficient manner. For instance,
a system that incorporates edge servers into the traditional
cloud data center, the traffic originated at the edge can be
dynamically routed to the tier and server that may provide
the highest quality service to the user by using the available
SDN mechanisms [21].
SDNs logically centralized control and programmable
interfaces are being used as a new way to look out for the res-
olution to many fault management issues which exist today,
for example, a global network view adds many possibilities
to the process of fault localization [24], [25], [27].
SDN architecture is composed of three layers: infras-
tructure layer/Data layer, which is exclusively responsible
for data forwarding and statistics storage, control layer,
which maintains the network view and provides core network
functions, and application layer, which uses abstractions
provided by control layer to implement network business ap-
plications(e.g. firewall, load balancer), enforcing networking
policies and requirements [22].
Fig. 1.
Comparison of traditional network architecture and Software-
Defined Networking
SDNs layered architecture presents new points for security
attacks, and even augments some issues already present in
legacy networks. SDN layers have independent and interde-
pendent security threat vectors. For instance, an intrusion
or Denial-of-service (DoS) attack on the controller may
compromise the entire network services affecting data plane.
In summary, as SDN brings new ways to tackle classic
network security issues it also brings new threat vectors that
need to be addressed.
Some of the attacks include; spoofing attacks, intrusion
attacks, anamoly attacks, DoS and DDoS attacks.They affect
data layer, control layer, data control interface, application
layer, application control interface, which results into rule
modification, leakage of data, malicious applications, unau-
thorized entry, entry of bugs, application failures, modifica-
tion of data, denial of service, flooding the controller and
flooding flow entries [28].
1.1 Survey organization
In this survey paper is organized as follows. Section II
provides background on SDN. Section III Security issues
in SDN. In Section IV provides a detailed study on SDN
security aspects pertaining to control plane.
The aim of this survey paper is to provide the recent works
towards the security aspects of SDN with a more focus on
various security threats that are resolved by SDN and new
threats that arise as a result of SDN implementation. Further,
present various security threats that are resolved by SDN andnew threats that arise as a result of SDN implementation.
II. B ACKGROUND
In this section we provide a detailed view of SDN archi-
tecture and how it relates to security issues in SDN.
A. Software-Defined Network Architecture
In traditional networks, control plane and data plane
are tightly coupled in network devices. Conversely, SDN
keeps only data forwarding functionality in network devices,
whereas it delegates control plane functionality to a physi-
cally separate layer, composed of one or more network enti-
ties called controllers, which provide the interface between
the high-level network applications and the network devices
[12]. The basic structure of SDN is represented in Fig. 2. It
consists of three different planes: Application plane, Control
plane and Infrastructure Plane.
1) Infrastructure/Data Plane: Also known as data plane
comprises of network devices such as router, switch and
access point. Both virtual switches such as Open vSwitch,
Indigo, Pica8, Nettle, OpenFlow and physical switches co-
exist in this layer [1], [2], [3]. The main function of the data
plane is forwarding the packets according to the assigned
rules/policies.
2) Control Plane: Control layer consists of a controller
which controls the overall SDN functions. This layer acts
as a mediator for infrastructure layer and application layer.
The controller is responsible for managing the entire traffic
flow and solely takes decisions on routing, flow forwarding
and packet dropping through programming [5], [6], [4]. The
controllers in the distributed environment communicate with
each other through east-bound and west-bound interfaces.
The control layer and the infrastructure layer communicate
with each other through south-bound API such as OpenFlow,
NetConf, etc. [2].
3) Application Plane: The Application layer is the fore-
most layer in the SDN as shown in Fig. 2. It is responsible for
handling software related business and security applications.
Network virtualization, Intrusion Detection Systems (IDS),
Intrusion Prevention Systems (IPS), firewall implementation
and mobility management are some examples of applications
handled by this layer. This layer communicates with the con-
trol layer using Application Control Plane Interface (A-CPI)
also called as northbound application interface [8] as shown
in Fig.2.
B. SDN Features
C. SDN Applications
III. SDN C ONTROLLER I SSUES
A. Fault Management
1) Fault tolerant programming platforms: Most dis-
tributed control plane architectures share their state
among replicas. This approach, at most, allows ap-
plications to configure consistency level desired. A
more flexible programming platform could give control
to network applications define different fault toler-
ance policies for different events and types of traffic.
Additionally, the programming platform may support
Fig. 2.
Software defined networking architecture
the definition of high-level fault tolerance objectives.
For instance, latest versions of ONOS [35] allow pro-
grammers to create intents, which represent high-level
control desires (e.g., connectivity between two hosts)
that are translated and constantly enforced through
low-level rules.
2) Geo-distributed recovery: Local fault tolerance may
be achieved in a domain through the partitioning
of management among independently managed clus-
ters, where controllers serve as backups to others in
case of failure. How- ever, a failure that affects the
whole domain (e.g. a disaster event) would require
geo-distributed state redundancy in order to recover
functionality. Authentication, latency, and inter-domain
management are some of the issues that must be
addressed in order to achieve efficient geo-distributed
recovery. SDN facilitates coordination between differ-
ent domains with different policies and access policies.
Some efforts proposed inter-domain failure manage-
ment mechanisms [36], [37], however, experiments
showed performance issues, demonstrating that there
is much to be improved. Gramoli et al. [38] showed
that the performance can be improved by extending
SDN with inter-domain communication primitives, in-
dicating that southbound protocol support may help to
achieve higher efficiency.
B. Scalability
1) Controller(s) failure: In a traditional network, when
one or more network nodes fail, flows are routed
through alternative paths/nodes to maintain the traffic
continuity. However, in an SDN architecture, failure
of the controller(s) may result in a chaos for the
specific part(s) of the network controlled by the failed
controller(s) due to two main critical reasons: (i)
The controllers are responsible for all configurations,
operations, and validations of the network topologies,
resources etc. and (ii) data plane devices lack an
ability for an online detour of flows. This problem
may become worse in the single controller design case.
In addition, distributing the load of a failed controllerto other controllers brings extra load on them, which
reduces performances thereby their scalability. This
distribution may even result in a cascading failures of
controllers because it can exceed the capacity of them.
One way to address this problem is to enhance the
network with backup/standby controllers [9], [41]. In
case of the main controller failure, these backup con-
troller(s) may take the responsibility of the network
operations over from the main controller. In this case,
controllers need to be synchronized to be in a consis-
tent status regarding network states.
In [10] , the authors present a disaster-aware control
plane design to reduce controller-related interruptions.
They model the problem of designing a disaster-
resilient control plane problem regarding the number
of controllers, their placement, and the control plane
topology. Pashkov et al. [16] propose a fault-tolerant
control plane design, High-Available Controller (HAC)
architecture, to address the fast recovery of the con-
trol plane by adding an additional cluster middleware
between the controller core and controller network
services and applications.
2) State/policy distribution/consistency: Another impor-
tant prob- lem regarding scalability is the network
state distribution and consistency between controllers
of a control plane. This problem mainly happens in
the distributed and/or hierarchical architectures due to
distribution of network states among controller repli-
cas. In addition, this distribution needs to be fast and
reliable to provide the consistency between controller
instances [30] . Moreover, policy consistency [7] in a
distributed control plane is required because network-
wide policies do not come from a single component
of a network, but rather, they are formed by different
functional modules such as routing, monitoring, and
access control as well as multiple human operators
controlling different parts of the network. These con-
flicts may result in serious inconsistencies such as
violation to another policy and wrong forwarding of
the packet etc. on the data plane. Therefore, more
efficient algorithms and mechanisms are needed to
maintain state/policy consistency among the distributed
controllers.
Distributing network state among local controllers in
the same domain does not necessarily deal with se-
curity issues. However, the Internet consists of many
networks managed by different authorities. Therefore,
the logically centralized control model of SDN must be
extended to account for inter-domain traffic. This ex-
tension requires peering, thereby state sharing, among
different administrative domains to have a relative
global network view in order to determine the next
hop. However, this distribution has to be secure, pri-
vate, and consistent. In addition, some other critical
questions regarding this sharing are how and what to
exchange with other domains. Yin et al. [99] state that
the types of messages exchanged among controllers
may be various such as reachability information, flow
setup/tear down/update requests, network parameters
(bandwidth, delay, loss etc.), service-level agreements
(SLAs), virtual network information and so on. In
[11], [17], [39], the authors propose a West-East (WE)
Bridge mechanism to enable different SDN adminis-
trative domains to securely peer and cooperate with
each other.
3) Flow rule setup latency: This problem refers to the
delay in new flow rule setup process in the context
of control plane scalability [15]. As explained earlier,
proactive mode and reactive mode are two prominent
modes to setup a new flow rule. The proactive mode
does not impose any latency in the flow rule setup from
the controllers point of view. In the reactive mode,
the controller response time (i.e. delay) is crucial.
Controllers having longer flow rule setup latencies
may not meet requirements of certain applications
such as fast fail-over and reactive routing of latency-
sensitive flows. Therefore, such control planes cannot
be scalable enough to satisfy the network needs. How-
ever, this delay can be relatively reduced by imposing
more controller and switch resources such as CPU,
memory etc. and devolving some control functions to
the switches.
In [42], the authors conduct various setup experi-
ments to test the latency of various controllers by
changing the number of switches, number of threads,
and controller workload. They conclude that adding
more threads beyond the number of switches does
not improve latency, and serving more switches than
available CPUs increases controller response time.
Some studies [13], [26] mitigate the flow rule setup
latency by leveraging the idea of Control Function
Devolvement. This idea relies on the delegation of
some of the control functions to the data plane so as to
alleviate the load on the controller(s), thereby reducing
controller-switch communication frequency.
4) Controller placement: In addition the number of con-
trollers, placement of the controller(s) [19] has impacts
on performance of the network as well. Suboptimal
controller placement affects many other problems such
as flow rule setup latency due to controller-switch
communication delay, controller-controller communi-
cation delay, control plane overhead, fault tolerance,
resiliency and so on. Although there are some studies
addressing this problem in the literature [43], we be-
lieve it is still an ongoing issue and needs further atten-
tion of researchers. Hu et al. [43] propose algorithms
to automate the controller placement decisions given a
physical network and the number of controllers. The
main objective of these algorithms is to maximize
resiliency of SDN to failures. In [45], [49] , the authors
address the controller placement problem to maximize
the reliability of control networks.
Rath et al. [46] present a non-zero-sum game-based
distributed technique to discuss optimal controllerplacement in SDN. Hock et al. [44] introduce the
Pareto-based Optimal COntroller-placement (POCO)
framework, which brings network operators a range
of options to select the controller placement based on
their particular needs regarding the metrics like latency,
load balancing etc. In [47] , the authors focus on the
controller placement problem for WAN. They use the
Spectral Clustering placement algorithm to partition
a large network into several small SDN domains.
Jimenez et al. [48] utilize the algorithm called k-
Critical to discover the minimum number of controllers
and their locations to create a robust control topology
that deals with failures and balances the load among
the selected controllers.
Furthermore, control plane overhead is affected by
the placement of controllers due to traffic between
switches and controllers ( packet in and flow mod
messages) and among controllers (e.g. state sharing).
Obadia et al. [40] challenge the problem of mini-
mizing control overhead by optimizing the number of
controllers and their placement. This approach differs
from others because they target minimization of control
overhead instead of minimization of switch-controller
delay.
C. Network update
Network is dynamic and requires update in the operation.
However, many confusions and problems can be caused
by careless schedule in the update process. Although the
problem has been investigated for many years in traditional
networks where the control plane is distributed, software
defined networking (SDN) brings new opportunities and
solutions to this problem by the separation of control and
data plane, as well as the centralized control [50].
Scenario
Update forwarding policy
Change access list of a
firewall
VM migration in Data
Center
Adjust traffic engineering
scheme
Confusion
Forwarding loop, forwarding black hole,
link congestion, network policy viola-
tion
Network policy violation
Forwarding black hole, link congestion
Link congestion
TABLE I
S OME SCENARIOS OF NETWORK UPDATE AND CORRESPONDING
CONFUSIONS [50]
1) Forwarding black hole: The forwarding black hole
confusion refers to the case that a packet entering an
SDN switch cannot match any rule in the forwarding
table during the network updating process.
2) Forwarding loop: The forwarding loop confusion
refers to the case that a packet suffers from forwarding
loops and cannot be delivered to its destination during
network update.
3) Link congestion: The link congestion refers to the
situation that link is congested by flows during the
network update process.
4) Network policy violation: Middleboxes (e.g., Firewall,
NAT, and Proxy) are widely deployed in modern
networks [18]. Packets have to follow network policies
which enforce packets going through a list of mid-
dleboxes. During the network policy update, packets
may violate the policies. Such confusion is known as
network policy violation.
D. Security
Security is a constant moving target, therefore securing the
controller is one of the most critical security measure to be
employed in an SDN network. Some of the security threats
include;
1) An intrusion attack is an unauthorized activity on
a network where attacks absorb network resources
intended for other uses. Due to the reconfigurablity
and programmability of SDN, the SDN can be imple-
mented as Intrusion Detection System (IDS) and Intru-
sion Prevention System (IPS) to monitor the network
activities continuously to detect intrusion attacks. Most
common intrusion attack vectors that can be defended
by using adaptability and programmability of SDN are
a) Asymmetric Routing Attack: The attacker use
more than one route to the targeted network
device to bypass certain network segments and
intrusion sensors. If networks is not set up for
asymmetric routing, they are vulnerable to this
attack.
b) Buffer Overflow Attacks: This attack overwrites
specific sections of device memory of a target
network or replaces normal data in certain mem-
ory locations with a malware to attack the net-
work with an aim of initiating denial-of-service.
c) Protocol-Specific Attacks: The network protocols
– such as TCP, UDP, ARP, IP, ICMP etc., may
inadvertently leave a backdoor for network intru-
sions through spoof- ing or so with an aim of
compromising or even crash- ing the targeted de-
vices on a network. For instance, while mapping
IP network addresses to the hardware addresses,
ARP protocol does not perform authentication on
messages, allowing attackers to execute man-in-
the- middle attacks.
d) Traffic Flooding Attacks: Attacker can generate
traf- fic loads too heavy for the network to
overwhelm the overall network resources. These
attacks can be easily controlled using SDN.
e) Trojan based Attack: This attack instigates DoS
attacks, erase stored data or open back doors to
permit system control by outside attackers.
2) Anomaly Attack is caused by unknown user by violat-
ing policies and compromising the entire system. For
instance traffic anomaly, a deviation from the normal
traffic pattern. An intrusion detection system (IDS)
may look for unusual traffic activities, such as a flood
of UDP packets or a new service appearing on the2) Threat vector 2 represents the attacks at SDN switches
in data plane which may occur from the in-flow and
out-flow of traffic.
3) Threat vector 3 represents the attacks that may occur
during the communication of data plane devices with
control plane device (controller).
4) Threat vector 4 represents the attacks on administrators
station which is linked with the controller e.g software
virus attack.
5) Threat vector 5 represents the attacks at the controller.
6) Threat vector 6 represents the attacks that occur be-
tween controller and application layer devices (includ-
ing admin systems).
7) Threat vector 7 represents the attacks targeting com-
munications between data layer and control layer.
8) Threat vector 8 represents the attacks on various ap-
plications running on the network.
9) Threat vector 9 represents the attacks targeting commu-
nications between control layer and application layer.
Fig. 3.
Attack Definition Application
Intrusion
Attacks An unauthorized activity
on a network where at-
tacks absorb network re-
sources intended for other
uses Cloud
computing,
smart grids,
virtual
machines,
data centers
Cloud
computing,
web
technologies
Cloud
computing,
mobile
infrastructure,
Internet
of
things, data
centers
SDN security threat vector map
network.
3) Distributed Denial-of-Service (DDoS) Attack: DDoS
attacks deny legitimate users to get access to network
services. These attacks can cause a significant damage
by compromising the entire network [33]. Conven-
tional networks have some methods to detect DDoS
attacks and protect the networks but do not offer very
reliable and flexible defense solutions [34].
IV. P ROPOSED SDN SOLUTIONS AND
COUNTERMEASURES
A. Security
SDN architecture by itself provides some level of security
protection over the network, in other words SDN serves as
a security solution. In this section we present SDN solution
for the different security attacks, before we do that here are
SDN attack vectors.
a. SDN Attack Vectors
Even though many SDN systems are relatively new and
SDN is still in the realm of the early adopters, we can be sure,
that as the technology matures and is more widely deployed,
it will become a target for attackers. It is anticipated that sev-
eral attack vectors will face SDN systems. The more common
SDN security concerns include attacks at the various SDN
architecture layers [29]. Lets look at the anticipated attacks
that could occur at each of these layers following Fig.3.
1) Threat vector 1 represents the fake traffic flows that
occur during intercommunication of SDN devices in
data plane. The attack may occur using the spoofed
identity of legitimate flows or fake identity of the
device.
Anomaly Caused by unknown user
Attacks
by violating policies and
compromising the entire
system.
DDOS
Attacker denys legitimate
Attacks
users to get access to net-
work services
Proposed
Defense
Technique
CloudWeather,
Snort SDN,
TIPS,
SDNIPS
Graphical
Approach
Mobile
malware
detection,
RTBH,
Botnet
detection
scheme,
privacy away
mitigation
of
DDOS
attacks
TABLE II
TYPICAL SECURITY APPLICATIONS OF SDN AS A SECURITY
PARADIGM
b. SDN as a security solution
Table 2 displays a summary of the different attacks, thier
definitions, application affected and the proposed defense
technique. The following are various security threats that can
be resolved using SDN [28];
1) SDN as Intrusion Detection System (IDS) and Intrusion
Prevention System (IPS): An intrusion attack is an unautho-
rized activity on a network where attacks absorb network
resources intended for other uses. Due to the reconfigurablity
and programmability of SDN, the SDN can be implemented
as IDS and IPS to monitor the network activities contin-
uously to detect intrusion attacks. Most common intrusion
attack vectors that can be defended by using adaptability
and programmability of SDN are1) Asymmetric Routing Attack: The attacker use more
than one route to the targeted network device to bypass
certain network segments and intrusion sensors. If
networks is not set up for asymmetric routing, they
are vulnerable to this attack.
2) Buffer Overflow Attacks: This attack overwrites spe-
cific sections of device memory of a target network
or replaces normal data in certain memory locations
with a malware to attack the network with an aim of
initiating denial-of-service.
3) Protocol-Specific Attacks: The network protocols –
such as TCP, UDP, ARP, IP, ICMP etc., may inadver-
tently leave a backdoor for network intrusions through
spoof- ing or so with an aim of compromising or
even crash- ing the targeted devices on a network.
For instance, while mapping IP network addresses
to the hardware addresses, ARP protocol does not
perform authentication on messages, allowing attackers
to execute man-in-the-middle attacks.
4) Traffic Flooding Attacks: Attacker can generate traffic
loads too heavy for the network to overwhelm the
overall network resources. These attacks can be easily
controlled using SDN.
5) Trojan based Attack: This attack instigates DoS at-
tacks, erase stored data or open back doors to permit
system control by outside attackers.
2) SDN for Anomaly Detection: Anomaly detection (or
out-lier detection) in a network is the identification of events
or observations which do not conform to an expected pattern.
These days attacks are becoming more sophisticated which
makes it hard to trace the actual origin of the attack [28].
SDN technology gives us a privilege to configure the devices
to serve our need. For instance, home router that is config-
ured using SDN works effectively to detect the malware and
spyware attacking the system [32].
3) SDN for Distributed Denial-of-Service (DDoS) Attack
Detection and Prevention: DDoS attacks deny legitimate
users to get access to network services. These attacks can
cause a significant damage by compromising the entire
network [33]. Conventional networks have some methods to
detect DDoS attacks and protect the networks but do not offer
very reliable and flexible defense solutions [34]. Due to the
programmable features and reconfigurable nature of SDN,
flexible and robust approaches can be designed, deployed
and evaluated to detect and prevent DDoS attacks.
B. Network Update
1) Solution to forwarding black hole
The forwarding black hole results from the reason
that there is no forwarding rule matching the packet.
Mahajan and Wattenhofer propose a solution to this
confusion as add before remove in Ref. [19]. The
scheme suggests that switches should update new
rules first before removing old rules. Then Reitblatt
et al. [20] implement a more generous version of add
before remove on the whole network to solve the
forwarding black hole confusion. As demonstrated in
Fig. 4.
Forwarding black holes solution
Fig. 4, each packet is stamped with a version number k
and forwarded through the network. When the update
process starts, new rules with version number k + 1 are
distributed to switches, while the switches still keep
old rules with version number k. After confirming that
all switches have received the new rules, controller
informs switches of stamping new packets injecting
into the network with new version number k + 1.
Then all switches wait for a time during which all
packets with version number k should have left the
network. After that, switches could remove old rules
with version k. Because switches keep both old and
new rules in forwarding tables during update process,
there will be no forwarding black holes.
2) Solution to forwarding loop
In order to solve forwarding loop confusion, we need
to avoid the existence of the loop during the update
process. We have mentioned that per-packet consis-
tency by Reitblatts solution [20] is a strong consistent
property in last subsection. Indeed, such per-packet
consistency not only keeps the forwarding black hole
free but also holds forwarding loop free.
However, Mahajan and Wattenhofer point out that
Reitblatts solution is too strong for forwarding loop
free property [19]. They show that a careful mix of
the old rule and new rule could hold forwarding-loop
free property. With the help of the example in Fig.
5, we illustrate Mahajan and Wattenhofers solution
to forwarding loop confusion. Fig. 5(a) shows the
forwarding path to node Z before network updating
and Fig. 5(d) shows the forwarding path to node Z
after network updating. All subfigures (a)(d) in Fig.
5 in sequence indicate the update schedule according
to Mahajan and Wattenhofers solution. The update
sequence is W-Y-X. This update schedule is based on
a dependency tree. The dependency tree is constructed
based on the forwarding path to node Z after update
shown in Fig. 5(d) according to principles: destination
node Z is the root of the dependency tree; node W
is the child of node Z and node X and node Y are
children of node W, resulting from node Z is the next
hop for node W and node W is the next hop for node
X and Y, as shown in Fig. 5(d). After building up the
dependency tree, the updating rule will be scheduled
as updating the root first, and then update children of
each node in sequence following the seemingly breadthFig. 5.
Forwarding loop solution
first search (BFS) rule.
3) Solution to link congestion
The link congestion confusion is caused by the over-
loading of link during the update process. Microsoft
demonstrates their inter-data center network solution
to link congestion SWAN [13] in 2013. The main
purpose of SWAN is to highly utilize the network
capacity even the traffic volume varies significantly by
time. SWAN leaves scratch capacity on links. Scratch
capacity will not be used until updating, and it proves
that when setting scratch capacity as s, update could
be finished in 1/s 1 steps without congestion. Idea of
this mechanism is similar to that of ICU [21]. They
both trade updating time with scarce resource which
in SWAN is link capacity and in ICU [21] is TCAM.
zUpdate [22] by Liu et al. aims to eliminate congestion
in data center updating progress. They point out that
in data centers switches utilize equal cost multipath
routing (ECMP) to split traffic evenly among all next
hops to make fully use of the redundant paths [22].
If one link fails, traffic on this link is evenly split
to the remaining links which may cause congestion.
zUpdate breaks the fairness among multiple paths
and split effected traffic on each path carefully when
failure happens. Like [20], optimization programming
model in zUpdate only requires operator to provide
final configuration without paying attention to update
details.
4) Solution to network policy violation
The origin of network policy violation is that a
packet cannot be matched with its original address.
Fayazbakhsh et al. point out that the key to solving
network policy violation con fusion is OriginBinding
[23]. They design a FlowTags mechanism for Orig-
inBinding as shown in Fig. 7. The NAT adds tags to
packets and sends the mapping between original IP and
tag to controller. Switches forward packets according
to tags in packet header. The FW consumes tags. Also,
They compare tags with the mapping received from
the controller and find out the original IP of packets,
so that no matter how many times a packet have
been edited, middleboxes and switches could always
map it with its original IP. For middlebox update
process, a middlebox can change its configuration rules
without worrying about the impact to downstream
middleboxes. In such a manner, network policy always
holds for every packet.
Fayazbakhshs solution helps switches to OriginBind a
packet with its original IP address, but there is still a
problem that may violet security polity. In a case which
is similar to Fig. 7, Host1 is multihoming to SW3.
Therefore, flows from Host1 may visit Internet through
SW3. How can we let flows from Host1 go back to
SW2 and blocked by the FW? Solution to the problem
is called waypoint enforcement provided by Ludwig et
al. [24]. In this case, SW2 is the waypoint that every
flow from Host1 must go through. Ludwigs solution
could guarantee that during update or any cases, flows
will always travel through the selected way point and
therefore security policy is hold.
C. Fault Management
Control plane architectures deal simultaneously with many
issues related to control plane failures.
1) Control plane state redundancy:
Fault-tolerant controller architectures can be catego-
rized with respect to two aspects: control distribution
and state redundancy. Control distribution can be, Cen-
tralized, where a primary controller is responsible for
domain management, while backup controllers keep
their state consistent with the primary, so they can
take over network control in case of primary failure;
or Distributed, where multiple controllers take control
of a network simultaneously, while coordinating with
each other to exchange network information necessary
to process their requests.
Control state redundancy can be achieved through
three approaches: State replication encapsulates net-
work view and/or applications state directly and sends
them to replicas, which must update their states; Event
propagation sends all, or selected, events in the same
order to each replica, so that they can achieve the
same state after event processing; Traffic duplication
replicates all traffic, at switch-level, into replica con-
trollers. Event and traffic replication approaches must
consider ordering, because message reordering may
lead controllers to inconsistent states.
2) Controller failover:
After controller failure, the backup controllers that will
take control of its orphan devices must be chosen
carefully. For example, if the orphan devices are as-
signed to a controller that is only accessed through
a congested link, the request processing latency may
increase. Some fault-tolerant control frameworks focus
on efficient controller failover approaches.Chan et al. [149] propose a fast controller failover
for multidomain SDN (FCF-M). In this distributed
approach, each domain is managed by a controller
which is replicated to a local backup using strong
consistency. Controller failure is detected using a
circular heartbeat mechanism, where each controller
checks whether its predecessor is still alive sending
probe packets. Controller failover is performed lo-
cally, if the backup controller is available, or using
controllers from other domains if necessary. Devices
are assigned to controllers by minimizing controller
distance and verifying whether its residual capacity is
enough to accommodate orphan switches. Otherwise,
orphan switches are distributed among other domain
controllers.
3) Controller-switch reliable communication:
Since controller state is updated through network
events, if an event is lost it may cause incorrect
behavior. For example, when there is a failure in a
primary controller, a backup replica takes over the
network control. Until this operation is complete, new
requests from switches can not be processed and will
be lost, leading the backup controller to an inconsistent
state. Thus controller-switch communication must be
reliable in order to guarantee network correctness.
Ravana [48] provide a message delivery guarantee
mechanism. During controller and switch communica-
tion, both exchange acknowledgement messages, while
the switch keeps the event in a temporary buffer in
case of controller failure in order to guarantee that
the events will be eventually delivered. The Open-
Flow protocol was also modified in order to support
the exchange of acknowledgment messages between
controller and switch, and buffer operations through
the following messages: EVENT ACK, an event arrival
notification; CMD ACK, a command arrival notification;
EBuf CLEAR and CBuf CLEAR are used to clear
event buffer and command buffer, respectively.
4) Controller placement and assignment:
A controller placement strategy needs to address two
network design choices: How many controllers are
needed and where they should be placed. Research
has demonstrated that the location of a controller can
affect network performance, from latency [50], [155]
to control and data network resiliency [156]. A fault
tolerant controller placement may prioritize different
network aspects, such as failure isolation (e.g. failures
of each partition do not affect others) [156], [157], or
control path resiliency [158]. Most of the approaches
model controller placement using graph representation
[159] or integer linear programming [153]. In general,
resilient controller placement efforts differ with respect
to the fault tolerance aspect they prioritize, metrics that
they consider and methods they use to optimize these
metrics.
Device assignment is a related problem, where the
switches are assigned to the controllers but the con-
troller location is already defined [160], [161].
Zhang et al. [156] tackle the controller placement mod-
eling as a graph partitioning problem. The proposed
method aims to reduce total failure likelihood min-
imizing inter-partition connectivity, using a modified
version of min-cut, where the network is partitioned
with minimum cuts across boundaries, while balancing
number of devices and links per partition. For each
partition, a controller is assigned to the location which
has the shortest paths to all devices in the same
partition.
5) Control Traffic
In this subsection we discuss efforts that focus on
improving control plane fault tolerance by quickly
detecting and responding to control channel failures.
a) Fault detection: Kotani et al. [69] propose a
control channel failure detection method. Each
switch sends probe messages to all controllers,
and as soon as the first one responds, it sets
its channel state to active, otherwise, it is set to
inactive. In order to avoid unnecessary commu-
nication overhead, a switch sends echo request
to control channels only after it sends a network
event to the controller. The controller checks
each switch individually sending an echo request
and, upon reply notification, it updates other
controllers with the information that the switch
is alive.
Lee et al. [11] also propose a failure detection
mechanism. Monitoring circle paths, composed
by a subset of network links, are responsible for
the detection of link failures. Initially, the con-
troller forwards a packet to the circle and waits
for a timeout period. If the controller receives a
response within this period, links of this circle are
considered as healthy, otherwise it starts a failure
location mechanism that sends a packet along the
suspected failed path, where each switch must
send a copy directly to the controller. The node
that does not send the packet is considered faulty.
In in-band control an extra round is performed to
check whether the failure affects control traffic. A
probe is sent along the in-band control tree, and if
one or more controllers fail to reply, the location
is determined by sending a probe packet to each
respective control tree node, and then, the root of
the subtree or leaf that fails to reply is finalized
as the failure location.
b) Fault recovery: Network control can be of two
types, out-of-band, control is performed directly
over dedicated communication channels, and in-
band, the same network is used for data and con-
trol traffic. Usually, in in-band control, switches
need to traverse intermediate devices to reach
con- troller. Consequently, if one intermediate
node fails, control traffic is lost.Petry et al. [177] investigates how cellular data
network can improve control plane resiliency pro-
viding out-of-band control. They added cellular
link between forwarding planes and the controller
that could be used in case of primary link failure.
It was demonstrated that cellular network band-
width was equivalent to ethernet network, while
the delay increased. Authors argue that further
investigation and optimization might be neces-
sary to guarantee that data cellular networks are
robust enough to handle data and control plane
failures. Sharma et al. [178] provide restoration
and protection mechanisms to control traffic in
in-band networks. In control path restoration, the
new path must be restored first on switches closer
to the controller to guarantee that its descending
switches will be able to receive restoration rules.
The controller sends barrier requests, which force
switches to process pending messages in order to
guarantee the restoration of ordering. In control
path protection, disjoint paths are pre-installed on
switches in order to mitigate failures.
V. C ONTROL P LANE S ECURITY
VI. C ONCLUSIONS
R EFERENCES
[1] F. Hu, Q. Hao, and K. Bao, A survey on software-defined network and
OpenFlow: From concept to implementation, IEEE Commun. Surveys
Tuts., vol. 16, no. 4, pp. 21812206, 4th Quart., 2014.
[2] [7] D. Kreutz et al., Software-defined networking: A comprehensive
survey, Proc. IEEE, vol. 103, no. 1, pp. 1476, Jan. 2015.
[3] W. Stallings, Software-defined networks and OpenFlow, Internet Pro-
tocol J., vol. 16, no. 1, pp. 16, 2013.
[4] Floodlight. Accessed on October 16, 2017 [Online]. Available:
http://www.projectfloodlight.org/
[5] K. Dhamecha and B. Trivedi, SDN issuesA survey, Int. J. Comput.
Appl., vol. 73, no. 18, pp. 3035, 2013.
[6] N. Gude et al., NOX: Towards an operating system for networks, ACM
SIGCOMM Comput. Commun. Rev., vol. 38, no. 3, pp. 105110, 2008.
[7] M. Canini, P. Kuznetsov, D. Levin, S. Schmid, Software transactional
networking: concurrent and consistent policy composition, in: Pro-
ceedings of the Second ACM SIGCOMM Workshop on Hot Topics in
Software Defined Networking, in: HotSDN 13, ACM, New York, NY,
USA, 2013, pp. 16, doi: 10.1145/ 2491185.2491200 .
[8] A. Voellmy, H. Kim, and N. Feamster, Procera: A language for high-
level reactive network control, in Proc. 1st Workshop Hot Topics Softw.
Defined Netw., Helsinki, Finland, 2012, pp. 4348.
[9] F. Botelho, A. Bessani, F. Ramos, P. Ferreira, On the design of
practical fault-tolerant sdn controllers, in: Software Defined Networks
(EWSDN), 2014 Third European Workshop on, 2014, pp. 7378, doi:
10.1109/EWSDN.2014.25 .
[10] S. Sedef Savas, M. Tornatore, M. Farhan Habib, P. Chowdhury,
B. Mukherjee, Disaster-resilient control plane design and mapping in
software-defined networks, ArXiv e-prints (2015).
[11] P. Lin, J. Bi, Z. Chen, Y. Wang, H. Hu, A. Xu, We-bridge: west-east
bridge for sdn inter-domain network peering, in: Computer Communi-
cations Workshops (INFOCOM WKSHPS), 2014 IEEE Conference on,
2014, pp. 111112, doi: 10.1109/INFCOMW.2014.6 84 9180 .
[12] Paulo F., Edjard M, ”A Survey on Fault Management in Software-
Defined Networks”, IEEE COMMUNICATION SURVEYS and TUTO-
RIALS, 2017
[13] M. Yu , J. Rexford , M.J. Freedman , J. Wang , Scalable flow-based
networking with difane, SIGCOMM Comput. Commun. Rev. 41 (4)
(2010) .
[14] Atzori L, Iera A, Morabito G The internet of things: a survey. Comput
Netw 54(15):27872805, 2010
[15] K. He, J. Khalid, S. Das, A. Gember-Jacobson, C. Prakash, A.
Akella, L.E. Li, M. Thottan, Latency in software defined networks:
Measurements and mitigation techniques, in: Proceedings of the 2015
ACM SIGMETRICS International Conference on Measurement and
Modeling of Computer Systems, in: SIGMET-RICS 15, ACM, New
York, NY, USA, 2015, pp. 435436, doi: 10.1145/2745844. 2745880
.
[16] V. Pashkov, A. Shalimov, R. Smeliansky, Controller failover for sdn
enterprise networks, in: Science and Technology Conference (Modern
Networking Technologies) (MoNeTeC), 2014 International, 2014, pp.
16, doi: 10.1109/MoNeTeC. 2014.6995594 .
[17] P. Lin, J. Bi, Y. Wang, Webridge: west-east bridge for distributed
heterogeneous sdn noses peering, Secur. Commun. Netw. 8 (10) (2015)
19261942, doi: 10.1002/sec.1030 .
[18] Whitmore A, Agarwal A, Da Xu L The internet of thingsa survey
of topics and trends. Inf Syst Front 17(2):261274. doi:10.1007/s10796-
014-9489-2, 2015
[19] B. Heller , R. Sherwood , N. McKeown , The controller placement
problem, in: Proceedings of the first workshop on Hot topics in software
defined networks, in: HotSDN 12, 2012, pp. 712 .
[20] D. B. Rawat, J. J. Rodrigues, and I. Stojmenovi, Cyber-Physical
Systems: From Theory to Practice. Boca Raton, FL, USA: CRC Press,
2015.
[21] A. C. Baktir, A. Ozgovde, and C. Ersoy, How Can Edge Computing
Benefit from Software-Defined Networking: A Survey, Use Cases &
Future Directions, Article in IEEE Communications Surveys & Tutorials
June 2017
[22] P. Fonseca and E. Mota, A Survey on Fault Management in Software-
Defined Networks, IEEE COMMUNICATION SURVEYS & TUTORI-
ALS 2017
[23] Security
is
a
constant
moving
target.
Ac-
cessed
October
17,
2017
[Online]
Available:
https://www.forbes.com/sites/patrickmoorhead/2017/05/05/security-
is-a-constantly-moving-target-isnt-it-time-to-secure-the-
hardware/#70cdbfec547a
[24] S. S. Lee, K.-Y. Li, K. Y. Chan, G.-H. Lai, and Y. C. Chung, Software-
based fast failure recovery for resilient openflow networks, in Reliable
Networks Design and Modeling (RNDM), 2015 7th International Work-
shop on, (Munich,Germany), pp. 194200, IEEE, Oct. 2015.
[25] S. S. Lee, K.-Y. Li, K.-Y. Chan, G.-H. Lai, and Y.-C. Chung, Path
layout planning and software based fast failure detection in survivable
OpenFlow networks, in Design of Reliable Communication Networks
(DRCN), 2014 10th International Conference on the, pp. 18, IEEE,
2014.
[26] A.R. Curtis, J.C. Mogul, J. Tourrilhes, P. Yalagandula, P. Sharma, S.
Banerjee, Devoflow: scaling flow management for high-performance
networks, SIGCOMM Comput. Commun. Rev. 41 (4) (2011) 254265,
doi: 10.1145/2043164.2018466.
[27] U. C. Kozat, G. Liang, and K. Kkten, On diagnosis of forwarding
plane via static forwarding rules in Software Defined Networks, in IEEE
Conference on Computer Communications, INFOCOM 14, (Toronto,
Canada), pp. 17161724, April 2014.
[28] D. B. Rawat, and S. R. Reddy, Software Defined Networking Architec-
ture, Security and Energy Efficiency: A Survey, IEEE COMMUNICA-
TIONS SURVEYS & TUTORIALS, VOL. 19, NO. 1, FIRST QUARTER
2017.
[29] SDN
Security
Attack
Vectors
and
SDN
Hardening,
Accessed
on
October
16,
2017
[Online].
Available:
https://www.networkworld.com/article/2840273/sdn/sdn-security-
attack-vectors-and-sdn-hardening.html
[30] D. Levin, A. Wundsam, B. Heller, N. Handigol, A. Feldmann, Log-
ically centralized?: State distribution trade-offs in software defined
networks, in: Proceedings of the First Workshop on Hot Topics in
Software Defined Networks, in: HotSDN 12, ACM, New York, NY, USA,
2012, pp. 16, doi: 10.1145/2342441. 2342443 .
[31] H. Yin , H. Xie , T. Tsou , D.R. Lopez , P.A. Aranda , R. Sidi ,
SDNi: A Message Exchange Protocol for Software Defined Networks
(SDNS) across Multiple Domains, Internet-Draft, Internet Engineering
Task Force, 2012.
[32] S. A. Mehdi, J. Khalid, and S. A. Khayam, Revisiting traffic anomaly
detection using software defined networking, in Recent Advances in
Intrusion Detection. Heidelberg, Germany: Springer, 2011, pp. 161180.
[33] Q. Yan and F. R. Yu, Distributed denial of service attacks in software-
defined networking with cloud computing, IEEE Commun. Mag., vol.
53, no. 4, pp. 5259, Apr. 2015.[34] M. Abliz, Internet denial of service attacks and defense mechanisms,
Dept. Comput. Sci., Univ. Pittsburgh, Pittsburgh, PA, USA, Tech. Rep.
TR-11-178, 2011.
[35] P. Berde, M. Gerola, J. Hart, Y. Higuchi, M. Kobayashi, T. Koide,
B. Lantz, W. Snow, G. Parulkar, B. OConnor, and P. Radoslavov,
ONOS: Towards an Open, Distributed SDN OS, Proceedings of the
third workshop on Hot topics in software defined networking, pp. 16,
Aug. 2014.
[36] M. Gerola, M. Santuari, E. Salvadori, S. Salsano, P. L. Ventre, M.
Campanella, F. Lombardo, and G. Siracusano, ICONA: Inter Cluster
ONOS Network Application, in Network Softwarization (NetSoft), 2015
1st IEEE Conference on, pp. 12, IEEE, 2015.
[37] K. Kuroki, N. Matsumoto, and M. Hayashi, Scalable OpenFlow
controller redundancy tackling local and global recoveries, in The Fifth
International Conference on Advances in Future Internet, pp. 6166,
Citeseer, 2013.
[38] V. Gramoli, G. Jourjon, and O. Mehani, Disaster-tolerant storage with
SDN, in International Conference on Networked Systems, pp. 293 307,
Springer, 2015.
[39] P. Lin, J. Bi, S. Wolff, Y. Wang, A. Xu, Z. Chen, H. Hu, Y. Lin, A
west-east bridge based sdn inter-domain testbed, Commun. Mag., IEEE
53 (2) (2015) 190197, doi: 10.1109/MCOM.2015.7045408.
[40] M. Obadia, M. Bouet, J.L. Rougier, L. Iannone, A Greedy Ap-
proach for Minimizing SDN Control Overhead, in: Network Soft-
warization (NetSoft), 2015 1st IEEE Conference on, 2015, pp. 15, doi:
10.1109/NETSOFT.2015.7116135 .
[41] P. Fonseca, R. Bennesby, E. Mota, A. Passito, A replication component
for resilient openflow-based networking, in: Network Operations and
Management Symposium (NOMS), 2012 IEEE, 2012, pp. 933939, doi:
10.1109/NOMS.2012. 6212011.
[42] J.C. Mogul, J. Tourrilhes, P. Yalagandula, P. Sharma, A.R. Curtis, S.
Banerjee, Devoflow: Cost-effective flow management for high perfor-
mance enterprise networks, in: Proceedings of the 9th ACM SIGCOMM
Workshop on Hot Topics in Networks, in: Hotnets-IX, ACM, New York,
NY, USA, 2010, pp. 1:11:6, doi: 10.1145/1868447.1868448 .
[43] Y. nan HU, W. dong WANG, X. yang GONG, X. rong QUE, S. duan
CHENG, On the placement of controllers in software-defined networks,
J. China Univ. Posts Telecommun. 19, Supplement 2 (2012) 92171.
http://dx.doi.org/10. 1016/S1005- 8885(11)60438- X .
[44] D. Hock, M. Hartmann, S. Gebert, M. Jarschel, T. Zinner, P. Tran-
Gia, Pareto-optimal resilient controller placement in sdn-based core
networks, in: Tele-traffic Congress (ITC), 2013 25th International,
2013, pp. 19, doi: 10.1109/ITC. 2013.6662939 .
[45] Y. Hu, W. Wang, X. Gong, X. Que, S. Cheng, On reliability-optimized
controller placement for software-defined networks, Commun., China
11 (2) (2014) 38 54, doi: 10.1109/CC.2014.6821736 .
[46] H. Rath, V. Revoori, S. Nadaf, A. Simha, Optimal controller placement
in soft- ware defined networks (sdn) using a non-zero-sum game,
in: World of Wireless, Mobile and Multimedia Networks (WoWMoM),
2014 IEEE 15th International Symposium on a, 2014, pp. 16, doi:
10.1109/WoWMoM.2014.6918987 .
[47] P. Xiao, W. Qu, H. Qi, Z. Li, Y. Xu, The sdn controller placement prob-
lem for wan, in: Communications in China (ICCC), 2014 IEEE/CIC
International Conference on, 2014, pp. 220224, doi: 10.1109/IC-
CChina.2014.7008275 .
[48] Y. Jimenez, C. Cervello-Pastor, A. Garcia, On the controller placement
for designing a distributed sdn control layer, in: Networking Conference,
2014 IFIP, 2014, pp. 19, doi: 10.1109/IFIPNetworking.2014.6857117 .
[49] Y. Hu , W. Wendong , X. Gong , X. Que , C. Shiduan , Reliability-
aware controller placement for software-defined networks, in: Inte-
grated Network Management (IM 2013), 2013 IFIP/IEEE International
Symposium on, 2013, pp. 672675.
[50] D. LI, S. WANG, K. ZHU, S. XIA, survey of network update in SDN,
Comput. Sci., 2017, 11(1): 412
