Towards Secure and Dependable Software-Defined

Networks

Diego Kreutz Fernando M. V. Ramos Paulo Verissimo

[email protected] [email protected] [email protected]
LaSIGE/FCUL, University of Lisbon, Portugal

ABSTRACT tion complexity, networks are dynamic, and operators have

Software-defined networking empowers network operators little or no mechanisms to automatically respond to network
with more flexibility to program their networks. With SDN, events. It is therefore difficult to enforce the required poli-
network management moves from codifying functionality in cies in such a continually changing environment.
terms of low-level device configurations to building software With the separation of the control plane from the data
that facilitates network management and debugging. By plane that lays the ground to the Software Defined Net-
separating the complexity of state distribution from network working paradigm, network switches 1 become simple for-
specification, SDN provides new ways to solve long-standing warding devices and the control logic is implemented in a
problems in networking — routing, for instance — while si- logically centralized controller — though in principle physi-
multaneously allowing the use of security and dependability cally distributed [1]. In SDN, the controller is the entity that
techniques, such as access control or multi-path. dictates the network behavior. The logical centralization of
However, the security and dependability of the SDN itself the control logic in a software module that runs in a stan-
is still an open issue. In this position paper we argue for dard server — the network operating system [2] — offers
the need to build secure and dependable SDNs by design. several benefits. First, it is simpler and less error-prone to
As a first step in this direction we describe several threat modify network policies through software, than via low-level
vectors that may enable the exploit of SDN vulnerabilities. device configurations. Second, a control program can auto-
We then sketch the design of a secure and dependable SDN matically react to spurious changes of the network state and
control platform as a materialization of the concept here thus maintain the high-level policies in place. Third, the
advocated. We hope that this paper will trigger discussions centralization of the control logic in a controller with global
in the SDN community around these issues and serve as a knowledge of the network state simplifies the development of
catalyser to join efforts from the networking and security & more sophisticated network functions. This ability to pro-
dependability communities in the ultimate goal of building gram the network in order to control the underlying data
resilient control planes. plane is therefore the crucial value proposition of SDN.
SDN provides new ways to solve age-old problems in net-
working (e.g., routing [3]) while simultaneously enabling the
Categories and Subject Descriptors introduction of sophisticated network policies, such as secu-
C.2.4 [Distributed Systems]: Network Operating Systems rity and dependability. An example is Ethane [4], an SDN
architecture that allows managers to enforce fine-grained ac-
Keywords cess control policies. However, the security and dependabil-
ity of the SDN itself has been a neglected topic up to now.
Security, Dependability, SDN, Threat Vectors, Controllers Only very recently has the community started to address
these issues. Porras et al. [5] provided a security enforce-
1. INTRODUCTION AND MOTIVATION ment kernel in SDN controllers to allow security based pri-
Operating and maintaining a computer network is an ar- oritization. By extending the original idea, the same authors
duous task. To express the required high-level network poli- proposed FRESCO [6], a framework to ease the development
cies, network operators need to configure each individual and deployment of security applications in SDN. Since many
network device separately — from a heterogeneous collec- commercial switches now support the OpenFlow 2 proto-
tion of switches, routers, middleboxes, etc. — using vendor- col [7], this technology has been deployed in a number of
specific and low-level commands. In addition to configura- production networks. Security and dependability issues are
therefore becoming a serious concern for the industry [8, 9].
Curiously, the main causes of concern lie in SDN’s main
Permission to make digital or hard copies of all or part of this work for personal or benefits: network programmability and control logic central-
classroom use is granted without fee provided that copies are not made or distributed ization. These capabilities actually introduce new fault and
for profit or commercial advantage and that copies bear this notice and the full cita-
tion on the first page. Copyrights for components of this work owned by others than 1
ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or re-
In this paper, we use the term switch(es) as an example of
publish, to post on servers or to redistribute to lists, requires prior specific permission
an SDN data plane device.
2
and/or a fee. Request permissions from [email protected]. The open interface between networking devices and the
HotSDN’13, August 16, 2013, Hong Kong, China. controller that is currently the enabler for the most com-
Copyright 2013 ACM 978-1-4503-2178-5/13/08 ...$15.00. mon materialization of an SDN.

55
attack planes, which open the doors for new threats that
did not exist before or were harder to exploit. Traditional
networks have “natural protections” against what would be
common vulnerabilities in regular IT systems. Namely, the
closed (proprietary) nature of network devices, their fairly
static design, the heterogeneity of software, and the de-
centralized nature of the control plane represent defenses
against common threats. For example, an attack exploiting
a peculiar vulnerability of a specific set of devices from a sin-
gle vendor would potentially harm only part of the network.
This diversity is comparatively smaller in SDNs. A com-
mon standard (e.g., OpenFlow) among vendors and clients
can also increase the risk, by the possible introduction of
common faults in compliant implementations of the pro-
tocols and the control plane software. An attack similar
to Stuxnet [10], a well-designed worm targeting very spe- Figure 1: SDN main threat vectors map
cific networked infrastructures, said to have impaired the
operation of hundreds of those devices by modifying their
control programs and configurations automatically, could
malicious user. An attacker can use network elements (e.g.,
have dramatic consequences in a highly configurable and
switches, servers, or personal computers) to launch a DoS
programmable network. It is more than likely that such
attack against OpenFlow switches (e.g., targeting to exhaust
targeted attacks, also called advanced persistent threats [11],
TCAMs) and controller resources. A simple authentication
will be developed against SDNs, if the opportunity of success
mechanism could mitigate the problem, but if an attacker
presents itself.
assumes the control of an application server that stores the
In summary, as we point out in this paper, SDNs bring a
details of many users, it can easily use the same authenti-
very fascinating dilemma: an extremely promising evolution
cated ports and source MAC addresses to inject authorized,
of networking architectures, versus a dangerous increase in
but forged, flows into the network.
the threat surface. We should preserve the benefits of the
Possible solutions: The use of intrusion detection systems
first, by counteracting the dangers of the second. Therefore
with support for runtime root-cause analysis could help iden-
we argue, in this position paper, for the need to consider
tify abnormal flows. This could be coupled with mechanisms
security and dependability as first class properties of future
for dynamic control of switch behavior (e.g., rate bounds for
SDNs, which should be built into the design from the first
control plane requests).
hour and not bolted on.
Threat vector 2: attacks on vulnerabilities in swit-
We continue by describing several threat vectors that may
ches, which can easily wreak havoc with the network. One
enable the exploit of SDN vulnerabilities in Section 2. In
single switch could be used to drop or slow down packets in
Section 3 we investigate the open questions and sketch the
the network, clone or deviate network traffic (e.g., for data
design of a secure and dependable SDN control platform as
theft purposes), or even inject traffic or forged requests to
an example materialization of the concept here advocated.
overload the controller or neighboring switches.
In section 4 we conclude the paper.
Possible solutions: The use of mechanisms of software at-
testation, such as autonomic trust management solutions
2. THREAT VECTORS for software components [12], is a possible mitigating fac-
Software-defined networks have two properties which can tor. Mechanisms to monitor and detect abnormal behavior
be seen as attractive honeypots for malicious users and a of network devices can also be useful to defeat this kind of
source of headaches for less prepared network operators. threats.
First, the ability to control the network by means of software Threat vector 3: attacks on control plane commu-
(always subject to bugs and a score of other vulnerabilities). nications, which can be used to generate DoS attacks or
Second, the centralization of the “network intelligence” in for data theft. As is well-known in the security community,
the controller(s). Anyone with access to the servers that using TLS/SSL does not per se guarantee secure commu-
host the control software can potentially control the entire nication, and that compromises the controller–device link.
network. Various papers report the weaknesses of TLS/SSL commu-
In this section we describe the seven main potential threat nications and its major anchor of trust, the PKI infrastruc-
vectors we identified in SDNs (Figure 1). Our goal is not to ture [13]. The security of those communications is as strong
use these potential problems to claim that software-defined as its weakest link, which could be a self-signed certificate,
networks are inherently less secure than current networks. a compromised Certificate Authority, or vulnerable applica-
What we argue is that SDNs pose threats of a different na- tions and libraries. For instance, there are many man-in-
ture that need therefore to be dealt with differently. On the the-middle vulnerable implementations of SSL being used
contrary, if the SDN is properly designed and deployed, we in world-wide critical systems [14]. Moreover, the TLS/SSL
believe this new network environment will definitely present model is not enough to establish and assure trust between
a quantum leap in network architecting, not only in func- controllers and switches. Once an attacker gains access to
tionality but also in resilience. the control plane, it may be capable of aggregating enough
Threat vector 1: forged or faked traffic flows, which power force (in terms of the number of switches under its
can be used to attack switches and controllers. This threat control) to launch DDoS attacks. This lack of trust guar-
can be triggered by faulty (non-malicious) devices or by a antees could even enable the creation of a virtual black

56
hole network (e.g., by using OpenFlow-based slicing tech- all components and domains of the network. Furthermore,
niques [15]) allowing data leakage while the normal produc- this data will only be useful if its trustworthiness (integrity,
tion traffic flows. authenticity, etc.) can be assured. Similarly, remediation
Possible solutions: The use of oligarchic trust models with requires safe and reliable system snapshots to guarantee a
multiple trust-anchor certification authorities (e.g., one per fast and correct recovery of network elements to a known
sub-domain or per controller instance) is a possibility. An- working state.
other is securing communication with threshold cryptogra- Possible solutions: Logging and tracing are the common
phy across controller replicas [16] (where the switch will need mechanisms in use, and are needed both in the data and
at least n shares to get a valid controller message). Addi- control planes. However, in order to be effective, they should
tionally, the use of dynamic, automated and assured device be indelible (a log that is guaranteed to be immutable and
association mechanisms may be considered, in order to guar- secure). Furthermore, logs should be stored in remote and
antee trust between the control plane and data plane devices. secure environments.
Threat vector 4: attacks on and vulnerabilities in
controllers, which are probably the most severe threats to Table 1: SDN specific vs non-specific threats
SDNs. A faulty or malicious controller could compromise Threats Specific Consequences in SDN
an entire network. The use of a common intrusion detection to SDN?
system may not be enough, as it may be hard to find the ex- Vector 1 no can be a door for DoS attacks
act combination of events that trigger a particular behavior Vector 2 no but now the impact is potentially
and, more importantly, to label it as malicious. Similarly, a augmented
malicious application can potentially do anything it pleases Vector 3 yes communication with logically
in the network, since controllers only provide abstractions centralized controllers can be
that translate into issuing configuration commands to the explored
underlying infrastructure. Vector 4 yes controlling the controller may
compromise the entire network
Possible solutions: Several techniques can be used, such as
Vector 5 yes malicious applications can now be
replication (to detect, remove or mask abnormal behavior), easily developed and deployed on
employing diversity (of controllers, protocols, programming controllers
languages, software images, etc.), and recovery (periodically Vector 6 no but now the impact is potentially
refreshing the system to a clean and reliable state). It is augmented
also important to secure all the sensitive elements inside the Vector 7 no it is still critical to assure fast re-
controller (e.g., crypto keys/secrets). Furthermore, security covery and diagnosis when faults
policies enforcing correct behavior might be mapped onto happen
those techniques, restricting which interfaces an application
can use and what kind of rules it can generate to program the
network (along the lines of security-based prioritization [5]). Table 1 summarizes the seven threat vectors and includes
Threat vector 5: lack of mechanisms to ensure information about its specificity to SDN. As can be observed,
trust between the controller and management appli- threats number 3, 4, and 5, are not present in traditional
cations, whereby similarly to threat number 3, controllers networks. They are specific to SDNs as they arise from the
and applications lack the ability to establish trusted relation- separation of the control and data planes and the conse-
ships. The main difference from the referred threat would quent introduction of a new entity in these networks — the
lie in the way the certification is made. The techniques used logically centralized controller. On the other hand, threat
to certify network devices are different from those used for vectors 1, 2, 6, and 7 were already present in traditional
applications. networks. However, the impact of these threats may be
Possible solutions: Mechanisms for autonomic trust man- potentially augmented — or at least it may be expressed
agement could be used to guarantee that the application is differently — and as a consequence it may need to be dealt
trusted during its lifetime. with dissimilarly.
Threat vector 6: attacks on and vulnerabilities in These seven threats we identified show that the attack sur-
administrative stations which, as it is also common in face for SDNs is augmented, when compared to traditional
traditional networks, are used in SDNs to access the network networks, and that different mitigation techniques need to
controller. These machines are already an exploitable tar- be put in place. We believe this offers strong arguments for
get in current networks, the difference being that the threat the need to consider security and dependability since the
surface as seen from a single compromised machine increases first steps of the design phase. With that motivation, in the
dramatically in SDNs. It becomes easy to reprogram the next section we sketch the design of a secure and depend-
network from a single location. able control platform that tries to address several of these
Possible solutions: The use of protocols requiring double threats.
credential verification (e.g., requiring the credentials of two
different users to access a control server). Also, the use of 3. SECURITY & DEPENDABILITY IN SDN
assured recovery mechanisms to guarantee a reliable state In this section we present some background on security
after reboot. and dependability and discuss mechanisms and techniques
Threat vector 7: lack of trusted resources for foren- to be considered on the design of a secure and dependable
sics and remediation, which would allow to understand control platform.
the cause of a detected problem and proceed to a fast and
secure mode recovery. In order to investigate and establish
facts about an incident, we need reliable information from

57
3.1 Background figure we can observe application B also replicated in all con-
To the best of our knowledge, none of the SDN controllers troller instances. This mixed approach ensures tolerance of
proposed thus far address security and dependability be- both hardware and software faults, accidental or malicious.
yond using simple authenticated communication channels Replication makes it possible to mask failures and to isolate
and control data replication among controller instances. For malicious or faulty applications and/or controllers. More-
example, no mechanisms are used to assure trusted switch- over, in case of a network partition, application B, with the
controller association (to avoid malicious devices in the net- proper consistency algorithms, will still be able to program
work) or to detect, correct or mask faults of system com- all network switches, contrary to application A.
ponents. Moreover, no techniques are used to assure data
integrity and confidentiality in or between controllers.
In a security and dependability perspective, one of the key
ingredients to guarantee a highly robust system is fault and
intrusion tolerance. The two main fault models are crash
and Byzantine (a.k.a., arbitrary faults). Crash fault toler-
ant services support only benign failures such as a crashed
process, operating system or machine, being a narrow sub-
set of the arbitrary model. Byzantine fault tolerant (BFT)
systems are capable of tolerating any abnormal behavior,
i.e., intentional or non-intentional faults, while the service
keeps its correct operation. Faults (e.g., bugs, misconfigu-
rations, attacks) and errors can be masked automatically as
they happen, by using state machine replication [17]. Fur-
thermore, in order to ensure the perpetual and unattended
operation of the system, errors can be removed with self- Figure 2: Secure & Dependable SDN
healing techniques [18], so that there is never an excessive
number of compromised devices. Both automatic recovery Diversity. Another relevant technique to improve the ro-
and perpetual and unattended operation seem to be relevant bustness of secure and dependable systems is diversity [25,
objectives in the context of SDNs. 26]. Replication with diverse controllers is a good starting
The literature on Byzantine fault tolerance is broad, rang- case. The basic principle behind this mechanism is to avoid
ing from large-scale systems [19, 20] to resource-efficient so- common-mode faults (e.g., software bugs or vulnerabilities).
lutions [19, 21, 22]. Nevertheless, BFT alone is not enough For example, it is known that off-the-shelf operating sys-
to guarantee a highly available dependable system, needing tems, from different families, have few intersecting vulner-
self-healing mechanisms as a complement. Techniques such abilities [26], which means that OS diversity constrains the
as proactive-reactive recovery [18], for example, can be used overall effect of attacks on common vulnerabilities. In SDNs
to assure the system liveness. These techniques rely on the the same management application could run on different
idea of rejuvenating compromised components (be it by ac- controllers. This can be simplified by defining a common
cidental or malicious faults). abstraction for applications (a northbound API).
Intrusion-tolerant architectures [23] are a step in the direc- Self-healing mechanisms. Under persistent adversary
tion of this automatic security paradigm. Intrusion-tolerant circumstances, proactive and reactive recovery can bring the
systems remain working correctly and are capable of assur- system back to a healthy state, replacing compromised com-
ing properties such as integrity, confidentiality and availabil- ponents, and keep it working virtually forever. When re-
ity, despite the presence of faulty or compromised compo- placing components, it is important that the replacement
nents due to successful attacks. be done with new and diverse versions of the components,
A secure and dependable control plane helps improve the whenever possible. In other words, we should explore di-
overall network resilience [24], which is our final goal. A versity in the recovery process, strengthening the defense
resilient system is one that self-adapts to the dynamics of against attacks targeting specific vulnerabilities in a system.
environment conditions, e.g., one that performs self-healing Dynamic device association. If a switch is associated
in the presence of persistent threats and where protection with a single controller, its control plane does not tolerate
parameters, such as number of replicas, length of keys, etc., faults. Once the controller fails, the control operation of
can automatically increase in case of a severe attack. the switch fails and the switch will need to associate with
another controller. For this reason, a switch should be able
3.2 Secure and Dependable Control Platform to dynamically associate with several controllers in a secure
In this section we present the general design of the secure way (e.g., by using threshold cryptography to detect ma-
and dependable SDN control platform we propose. Figure licious controllers and authentication, which would hinder
2 illustrates a simplified view of the architecture. In the man-in-the-middle attacks, for instance). A switch associ-
remainder of this section we briefly introduce and discuss ated with different controllers would be able to automati-
the several mechanisms which we consider using to address cally tolerate faults (crash or Byzantine, depending on the
the threat vectors identified in SDNs. configuration). Other advantages include increasing control
Replication. One of the most important techniques to plane throughput (several controllers could be used for load
improve the dependability of the system is replication. As balancing) and reducing control delay [27] by choosing the
can be seen in figure 2, our controller is replicated, with three quickest-responding controller.
instances in the example. Applications should be replicated Increasing the data plane programmability (near or in the
as well. Besides replicated instances of the controller, in the network switches) would be helpful in this respect. Two

58
approaches could be used for this purpose. One option would to reduce the window of vulnerabilities. Thus, a control
be to use general purpose CPUs inside the switch to replace platform should be deployed with mechanisms to assure a
some of the traditional functionality of custom ASIC, as smooth and secure way of doing updates. Solutions as those
in [28]. Another could be to have a proxy element acting on proposed in [30] can help in achieving this goal.
behalf of the switch. This element could be easily deployed To summarize, in Table 2 we identify each of the threat
in a small black box attached to the switch, with a general vectors that may be mitigated with the use of the solutions
purpose micro-computer. and mechanisms explored in this section.
Trust between devices and controllers. Establishing
trust between devices and controllers is an important re- Table 2: solutions to threat vectors
quirement for overall control plane trustworthiness. Network Solution/mechanism Threat vectors
devices should be allowed to associate with controllers dy- Replication 1, 4, 5, 7
namically but without incurring in less reliable relationships. Diversity 3, 4, 6
A simple approach would be to have authenticated white Self-healing 2, 4, 6
lists of known trusted devices, kept at controllers. However, Dynamic switch association 3, 4
this lacks the flexibility desired in an SDN. Another option Trust between controllers & devices 1, 2, 3
is therefore to trust all switches until its trustworthiness is Trust between controllers & apps 4, 5
questioned. Malicious or abnormal behavior could be re-
Security domains 4, 5
ported by other switches or controllers, based on anomaly
Secure components 4, 5, 7
or failure detection algorithms. Once the trustworthiness of
Fast and reliable update & patching 2, 4, 6
a switch or a controller would go below an accepted thresh-
old, the switch would be automatically quarantined by all
devices and controllers. The solutions just discussed form the core mechanisms of
Trust between applications and controllers soft- what we are considering in our implementation of a secure
ware. As software components present changing behav- and dependable control platform. We nevertheless believe
ior due to aging, exhaustion, bugs, or attacks, a dynamic such designs may benefit from the use of traditional tech-
trust model as the one proposed in [12] is required. In niques, such as firewalls or intrusion detection systems, and
this paper the authors propose and demonstrate the feasi- novel tools to specify and compose packet-forwarding poli-
bility of a model to support autonomic trust management in cies (and updating them in a consistent way) [31] and to
component-based software systems. They use a holistic no- check network-wide invariants in real time [32]. These are in
tion of trust to allow a trustor to assess the trustworthiness fact some avenues we are still exploring.
of the trustee by observing its behavior and measuring it
based on quality attributes, such as availability, reliability, 3.3 Security and Dependability by Design
integrity, safety, maintainability, and confidentiality. The We now advocate security and dependability by design
proposed model can also be applied to define, monitor, and through an example. Suppose that we have three repli-
ensure the trustworthiness of relationships among system cated controllers to keep our network in a healthy state. If
entities. one controller is buggy or gets compromised we still have
Security domains. Isolated security domains are a very two potentially correct controllers. This will be true if con-
common technique used in different types of systems. For trollers are designed in order that they can be easily repli-
instance, in operating systems user level applications are not cated, are capable of interoperating and providing support
allowed to access kernel level sub-systems. A recent exam- to execute applications across controllers. To achieve these
ple of effective security domains by design is Chromium [29]. characteristics, we need common interfaces for controller in-
Similarly to operating systems sandboxes, Chromium uses tegration and interoperation (e.g., three different controllers
sandboxes to isolate the rendering engine from the browser working together in a same environment), common north-
kernel. Thus, most of the attacks will affect only the ren- bound APIs, and common replication capabilities. In addi-
dering engine and not the system kernel. Security domains tion to this, the switches will also need to be able to dynam-
in SDN control platforms can be explored using techniques ically associate with more than one controller. Finally, if
such as sandboxing and virtualization. These techniques we rely on a single controller make for replication, bugs and
enable the design of strong isolation modes, through well- abnormal behaviors have a high probability of affecting all
defined interfaces that allow minimal (only restricted and instances in parallel. In this case, diversity helps improve
strictly necessary) set of operations and communication be- the robustness of the system. In summary, by applying these
tween different domains. three techniques — replication, diversity, dynamic switch
Secure components. These components are one of the association — in the design of our system, we are able to
essential building blocks of a secure and dependable system. increase its security and dependability from the first hour.
Secure elements can be used, for example, to provide trusted
computing bases (TCB) to assure security properties such 3.4 Related work
as confidentiality. A TCB is a tamper-proof device that
Security and dependability of SDN still is a field almost
can be used to store sensitive security data (e.g., crypto
unexplored, presenting many challenges and opportunities.
private keys) and execute basic operations on it. Thus, even
There are only a few closely related works, namely [5] and
if the system is compromised, sensitive data will have its
[6]. Their essential idea is to provide a security kernel (e.g.,
confidentiality assured.
by extending a controller like NOX) capable of ensuring pri-
Fast and reliable software update and patching.
oritized flow rule installation on switches. Applications are
As no software is free from bugs (or other vulnerabilities),
classified in two types, one for security related applications
fast and reliable software patching and update is essential
and another for all remaining applications. The first type

59
represents specialized programs used to ensure security con- [12] Z. Yan and C. Prehofer. “Autonomic Trust
trol policies in the network, such as to guarantee or restrict Management for a Component-Based Software
specific accesses to the network or take actions to control System”. In: IEEE Trans. on Dep. and Sec.
malicious data traffic. Flow rules generated by security ap- Computing 8.6 (2011).
plications have priority over the others. The security ker- [13] R. Holz et al. “X.509 Forensics: Detecting and
nel is responsible for ensuring this behavior. FRESCO [6] is Localising the SSL/TLS Men-in-the-Middle”. In:
an extension of this work that makes it easy to create and Computer Security. LNCS. 2012.
deploy security services in software-defined networks. How-
ever, none of these works fosters or enforces the security of [14] M. Georgiev et al. “The most dangerous code in the
SDN itself, the goal we are pursuing. world: validating SSL certificates in non-browser
software”. In: ACM CCS. 2012.
4. CONCLUDING REMARKS [15] R. Sherwood et al. FlowVisor: A Network
Virtualization Layer. Tech. rep. Deutsche Telekom
In this paper we argue for the need to consider security
Inc. R&D Lab, Stanford, Nicira Networks, 2009.
and dependability when designing Software Defined Net-
works. We have presented several threats identified in these [16] Y. G. Desmedt. “Threshold cryptography”. In:
networks as strong arguments for this need, together with a European Trans. on Telecommunications 5.4 (1994).
brief discussion of the mechanisms we are using in building [17] F. B. Schneider. “Implementing fault-tolerant services
a secure and dependable SDN control platform. using the state machine approach: a tutorial”. In:
The novel concepts introduced by SDN are enabling a rev- ACM Comput. Surv. 22.4 (Dec. 1990).
olution in networking research. The know-how and good
practices from several communities (databases, program- [18] P. Sousa et al. “Highly Available Intrusion-Tolerant
ming languages, systems) are being put together to help Services with Proactive-Reactive Recovery”. In: IEEE
solve long-standing networking problems. We hope that this Trans. Parallel Distrib. Syst. 21.4 (2010).
paper will trigger discussions in the SDN community around [19] G. Veronese et al. “Efficient Byzantine
issues related to security and dependability, to serve as a Fault-Tolerance”. In: IEEE Trans. on Computers
catalyser of joint efforts in these critical issues. 62.1 (2013).
[20] G. Veronese et al. “EBAWA: Efficient Byzantine
5. ACKNOWLEDGMENTS Agreement for Wide-Area Networks”. In: IEEE
We would like to thank Vinicius Cogo for comments and HASE. 2010.
the anonymous reviewers for their helpful feedback. This [21] R. Kapitza et al. “CheapBFT: resource-efficient
work is partially supported by the EC, through project Sec- byzantine fault tolerance”. In: ACM EuroSys. 2012.
FuNet FP7-ICT-STREP-288349, by FCT, through project
[22] J. Hendricks, G. R. Ganger, and M. K. Reiter.
TRONE CMU-PT/RNQ/0015/2009, and by CNPq, through
“Low-overhead byzantine fault-tolerant storage”. In:
grant 202104/2012-5.
SIGOPS Oper. Syst. Rev. 41.6 (Oct. 2007).

6. REFERENCES [23] P. Verissimo et al. “Intrusion-tolerant middleware:

the road to automatic security”. In: IEEE Security &
[1] T. Koponen et al. “Onix: a distributed control Privacy 4.4 (2006).
platform for large-scale production networks”. In: [24] J. Korniak. “The GMPLS Controlled Optical
OSDI. 2010. Networks as Industry Communication Platform”. In:
[2] N. Gude et al. “NOX: towards an operating system IEEE Trans. on Industrial Informatics 7.4 (2011).
for networks”. In: Comp. Comm. Rev. (2008). [25] S. Neti, A. Somayaji, and M. E. Locasto. “Software
[3] M. Caesar et al. “Design and implementation of a diversity: Security, Entropy and Game Theory”. In:
routing control platform”. In: NSDI. 2005. 7th USENIX HotSec. 2012.
[4] M. Casado et al. “Rethinking Enterprise Network [26] M. Garcia et al. “Analysis of operating system
Control”. In: ACM Trans. on Networking 17.4 (2009). diversity for intrusion tolerance”. In: Software:
Practice and Experience (2013).
[5] P. Porras et al. “A security enforcement kernel for
OpenFlow networks”. In: HotSDN. ACM, 2012. [27] B. Heller, R. Sherwood, and N. McKeown. “The
controller placement problem”. In: HotSDN. 2012.
[6] S. Shin et al. “FRESCO: Modular Composable
Security Services for Software-Defined Networks”. In: [28] J. C. Mogul and P. Congdon. “Hey, you darned
Internet Society NDSS. 2013. counters!: get off my ASIC!” In: HotSDN. 2012.
[7] N. McKeown et al. “OpenFlow: enabling innovation [29] A. Barth et al. The Security Architecture of the
in campus networks”. In: Comp. Comm. Rev. (2008). Chro-mium Browser. Tech. rep. Stanford University,
2008.
[8] S. Sorensen. Security implications of software-defined
networks. 2012. url: http://goo.gl/BiXH2. [30] J. H. Perkins et al. “Automatically patching errors in
deployed software”. In: ACM SIGOPS SOSP. 2009.
[9] S. M. Kerner. Is SDN Secure? 2013. url:
http://goo.gl/lPn2V. [31] N. Foster et al. “Frenetic: a network programming
language”. In: SIGPLAN Not. (2011).
[10] D. Kushner. The Real Story of Stuxnet. 2013. url:
http://goo.gl/HIEHQ. [32] A. Khurshid et al. “VeriFlow: verifying network-wide
[11] C. Tankard. “Advanced Persistent threats and how to invariants in real time”. In: HotSDN. 2012.
monitor and deter them”. In: Network Sec. (2011).

60