SDN Security: A Survey

Sandra Scott-Hayward, Gemma O’Callaghan and Sakir Sezer

Centre for Secure Information Technolocy (CSIT)
Queen’s University Belfast
Belfast, BT3 9DT, Northern Ireland

ABSTRACT—The pull of Software-Defined Networking However, the same attributes of centralized control
(SDN) is magnetic. There are few in the networking and programmability associated with the SDN platform
community who have escaped its impact. As the benefits of introduce network security challenges. An increased
network visibility and network device programmability are
discussed, the question could be asked as to who exactly will potential for Denial-of-Service (DoS) attacks due to
benefit? Will it be the network operator or will it, in fact, the centralized controller and flow-table limitation in
be the network intruder? As SDN devices and systems hit network devices is a prime example. Another issue of
the market, security in SDN must be raised on the agenda. concern based on open programmability of the network
This paper presents a comprehensive survey of the research is trust; both between applications and controllers, and
relating to security in software-defined networking that has
been carried out to date. Both the security enhancements to controllers and network devices.
be derived from using the SDN framework and the security A number of solutions to these SDN security chal-
challenges introduced by the framework are discussed. By lenges have been proposed in the literature. These range
categorizing the existing work, a set of conclusions and from controller replication schemes through policy con-
proposals for future research directions are presented.
flict resolution to authentication mechanisms. Similarly,
a number of proposals have been made to exploit the
I. I NTRODUCTION
SDN framework for enhanced network security.
Software-defined networking (SDN) is rapidly moving An analysis of the security challenges of SDN is
from vision to reality with a host of SDN-enabled presented in this paper. The individual security issues
devices in development and production. The combination are categorized according to the SDN layer affected
of separated control and data plane functionality and or targeted. The proposed and emerging solutions to
programmability in the network, which have long been these challenges are then discussed and categorized. The
discussed in the research world, have found their com- requirement for further work to establish a secure and
mercial application in cloud computing and virtualization robust SDN is clearly identified from the gap between
technologies. the issues and the existing research. Without a significant
The advantages of SDN in various scenarios (e.g. the increase in focus on security, it will not be possible for
enterprise, the datacenter etc.) and across various back- SDN to support the evolving capability associated with,
bone networks have already been proven e.g. Google for example, Network Functions Virtualization (NFV)
B4 [1]. However, challenges exist for a full-scale carrier [3].
network implementation of SDN. A number of these
challenges have been presented in [2]. One key area, II. S ECURITY A NALYSES OF SDN
which is only beginning to receive the attention it
deserves, is that of security in SDN. The basic properties of a secure communications
The SDN architecture can be exploited to enhance network are: confidentiality, integrity, availability of in-
network security with the provision of a highly reactive formation, authentication and non-repudiation [4]. In
security monitoring, analysis and response system. The order to provide a network protected from malicious
central controller is key to this system. Traffic analysis attack or unintentional damage, security professionals
or anomaly-detection methods deployed in the network must secure the data, the network assets (e.g. devices)
generate security-related data, which can be regularly and the communication transactions across the network.
transferred to the central controller. Applications can The alterations to the network architecture introduced by
be run at the controller to analyze and correlate this SDN must be assessed to ensure that network security
feedback from the complete network. Based on the is sustained.
analysis, new or updated security policy can be prop- In an early iteration of what is known today as SDN,
agated across the network in the form of flow rules. Casado et al. [5] specifically considered the security
This consolidated approach can efficiently speed up the aspects of a separate control and forwarding framework.
control and containment of network security threats. Their SANE architecture, proposed in 2006, centred on
a logically centralized controller responsible for authen- posed, these techniques are not proven in the work.
tication of hosts and policy enforcement. At the time The OpenFlow switch specification [9] describes the
of its proposal, this was considered to be an extreme use of transport layer security (TLS) with mutual au-
approach that would require a radical change to the thentication between the controllers and their switches.
networking infrastructure and end-hosts, which could be However, the security feature is optional, and the stan-
too restrictive for some enterprises. dard of TLS is not specified. The lack of TLS adoption
Ethane [6] extended the work of SANE but used an by major vendors and the possibility of DoS attacks are
approach, which required less alteration to the original the focus of an OpenFlow vulnerability assessment [10].
network. It controlled the network through the use of two The authors found that the lack of TLS use could lead
components; a centralized controller responsible for en- to fraudulent rule insertion and rule modification.
forcing global policy, and ethane switches, which simply In [11] Kreutz et al. present a high-level analysis
forwarded packets based on rules in a flow table. This of the overall security of SDN. They conclude that
simplified network control allowed the data and control due to the nature of the centralized controller and the
plane to be separated to allow for more programmability. programmability of the network, new threats are intro-
Although the Ethane architecture gave us a closer look duced requiring new responses. They propose a number
at what SDN and OpenFlow would become, it suffered of techniques in order to address the various threats,
from a number of drawbacks. One of these is the fact including replication, diversity and secure components.
that application traffic could compromise network policy. Finally, the research network and testbed, ProtoGENI,
In today’s SDN architecture, applications are used to has also been analyzed [12]. The authors discovered that
provide various services, as, for example, with Network numerous attacks between users of the testbed along
Functions Virtualization (NFV). The compromise of with malicious propagation and flooding attacks to the
applications could potentially breach the entire network. wider internet were possible when using the ProtoGENI
Considering the specific issues with security in SDN network.
from the perspective of the SDN framework (Fig. 1), we The results of these analyses indicate the range of
can identify challenges associated with each layer of the the security issues associated with the SDN framework.
framework: application, control and data planes, and on In Table I, a categorization of the SDN security issues
the interfaces between these layers. is presented. A connection is drawn between the type
of issue/attack (e.g. unauthorized access) and the SDN
layer/interface affected by the issue/attack.
The control and data layers are identified in Table I as
clear targets of attack. This reflects the main distinctions
between the traditional network and the SDN; that of
the centralized control element and the altered datapath
elements to support programmability.
Although this analysis points towards security issues
related to the control and data layers, there has been
limited research in the field to tackle the challenges. In
fact, as detailed in the next section, greater attention has
been given to exploring the potential improvements in
network security to be derived from the SDN framework.

Fig. 1. SDN Functional Architecture illustrating the data, control and

application layers and interfaces III. S ECURITY E NHANCEMENT USING SDN

A number of security analyses have recently been The architecture of a software-defined network intro-
performed, which have found that the altered elements duces potential for innovation in the use of the network.
or relationship between elements in the SDN framework The combination of the global or network-wide view
introduce new vulnerabilities, which were not present and the network programmability supports a process of
before SDN. One such paper [7] completes an analysis of harvesting intelligence from existing Intrusion Detection
the OpenFlow protocol using the STRIDE threat analysis Systems (IDS) and Intrusion Prevention Systems (IPS),
methodology [8]. This paper focuses on the execution for example, followed by analysis and centralized re-
of Information Disclosure and DoS attacks, which the programming of the network. This approach can render
author established were possible to successfully execute. the SDN more robust to malicious attack than traditional
Although a number of mitigation techniques are pro- networks.
 TABLE I
C ATEGORIZATION OF THE S ECURITY I SSUES ASSOCIATED WITH THE SDN FRAMEWORK BY LAYER / INTERFACE AFFECTED

SDN Layer Affected or Targeted

Security Issue/Attack Application App-Ctl Control Ctl-Data Data
Layer Interface Layer Interface Layer

Unauthorized Access e.g.

Unauthorized Controller Access X X X
Unauthenticated Application X X X
Data Leakage e.g.
Flow Rule Discovery (Side Channel Attack on Input Buffer) X
Forwarding Policy Discovery (Packet Processing Timing Analysis) X
Data Modification e.g.
Flow Rule Modification to Modify Packets X X X
Malicious Applications e.g.
Fraudulent Rule Insertion X X X
Controller Hijacking X X X
Denial of Service e.g.
Controller-Switch Communication Flood X X X
Switch Flow Table Flooding X
Configuration Issues e.g.
Lack of TLS (or other Authentication Technique) Adoption X X X
Policy Enforcement X X X

A. The SDN Middle-box Based on these proposals, it would appear that a sim-
ple approach to network security provision would be to
Traditional networks use middle-boxes to provide introduce an appropriate middle-box and programme the
network security functions. Recently, there has been network to direct selected traffic through the middle-box.
discussion about the integration of security middle-boxes It is not, however, quite as straightforward as that. The
into SDN exploiting the benefit of programmability to appropriate placement and integration of SDN middle-
redirect selected network traffic through the middle- boxes must be determined along with the performance
box. For example, the Slick architecture [13] proposes a penalty that can be tolerated when traffic is diverted
centralized controller, which is responsible for installing through an additional link. Such questions have not yet
and migrating functions onto custom middle-boxes. Ap- been resolved.
plications can then direct the Slick controller to install
However, as illustrated in Table I, the range of attacks
the necessary functions for routing particular flows based
that pose threats to the network is well understood.
on security requirements.
As such, beyond middle-boxes, a series of solutions
The FlowTags architecture [14] proposes the use of have been proposed, which specifically exploit the SDN
minimally modified middle-boxes, which interact with framework to provide network security solutions.
a SDN controller through a FlowTags Application Pro-
gramming Interface (API). FlowTags, consisting of traf-
B. SDN = “Security Defined Networking”?
fic flow information, are embedded in packet headers to
provide flow tracking and enable controlled routing of Attackers use various scanning techniques to discover
tagged packets. A clear disadvantage of this architecture vulnerable targets in the network. One defense presented
is the fact that it works with only pre-defined policies to thwart these attacks is the use of random virtual
and currently does not handle dynamic actions. Internet Protocol (IP) addresses using SDN [16]. This
The SIMPLE policy enforcement layer [15] is an technique uses the OpenFlow controller to manage a
approach for using SDN to manage middlebox deploy- pool of virtual IP addresses, which are assigned to hosts
ments. In contrast to [13], [14], it requires no modifi- within the network, hiding the real IP addresses from
cations to SDN capabilities or middle-box functionality, the outside world. This presents moving target defense,
which makes it suitable for legacy systems. which is a form of adaptive cybersecurity.
 Monitoring Systems are essential in protecting the environment, it is vital that network security policy is
network from attack. In [17], the authors present a enforced. Model-checking becomes an important step
Distributed DoS (DDoS) detection method based on in detecting inconsistencies in policies from multiple
several traffic flow features. This system monitors NOX applications or installed across multiple devices. Model
(C++ based OpenFlow Controller) switches at regular checking combined with symbolic execution may be
intervals and uses Self Organizing Maps to identify used to test OpenFlow applications for correctness [25].
abnormal flows. In another approach, OpenSAFE [18] Binary Decision Diagrams can also be used to test
uses its ALARMS policy language to manage the routing for intra-switch misconfigurations within a single flow
of traffic through network monitoring devices. A similar table [26]. FlowChecker exploits FlowVisor [27], which
idea focusing on SDN in the cloud was presented by enables isolation by partitioning the network resources
Shin and Gu in [19]. CloudWatcher controls network into slices. Son et al. propose Flover [28], which uses
flows to guarantee that all necessary network packets assertion sets and modulo theories to verify flow policies,
are inspected by some security devices. This framework while VeriFlow [29] studies the verification of invariants
automatically detours network packets to be inspected in real-time. An additional layer, which sits between the
by pre-installed network security devices. SDN controller and the network devices, intercepts flow
These solutions are based on a centralized network rules before they reach the network. Although VeriFlow
management scheme; however other work encourages boasts low-latency of the checking process, it cannot
the delegation of some control back to network devices handle multiple controllers. In [30], the authors propose
and hosts. Resonance, for example, [20], provides dy- the use of language-based security to enable flow-based
namic access control enforced by network devices them- policy enforcement along with network isolation. This
selves based on higher-level security policies. Naous et solution is implemented as a NOX application and al-
al. [21] put forward the ident++ protocol to query end- lows the integration of external authentication sources to
hosts and users for additional information in order to provide access control. More recently, Splendid Isolation
make forwarding decisions; their argument being that [31] has been proposed as a means of verifying the
the central controller could become a bottleneck. While isolation of program traffic. This programming model
retaining the programmability characteristic of SDN, supports the idea of network slices to provide the funda-
these methods propose to involve the network devices mental security concepts of confidentiality and integrity.
in the control of the network, rather than relying on a There is a clear emphasis from the research community
single, centralized controller. on this issue of policy conflict resolution.
One specific form of monitoring system, the IDS, has However, proposals to aid in the design of secure
been the focus of a number of SDN solutions. Skowyra SDNs are limited. Fresco [32] is one notable contri-
et al. [22] propose a learning IDS, which utilizes the bution; which presents an OpenFlow Security Appli-
SDN architecture to both detect and respond to net- cation Development Framework incorporating FortNox
work attacks in embedded mobile devices. A hardware- [33]; a security enforcement kernel. The idea behind
accelerated NIDS (Network IDS) or NIPS (Network FRESCO is to allow the rapid design and development
IPS) scheme, as described in [23], allows the network of security specific modules, which can be incorporated
administrator to configure string patterns for use by a as an OpenFlow application. Porras et al. provide a
deep packet inspection (DPI) module. Finally, the value library of reusable modules which can be used for
of using SDN to provide intrusion detection in a Home the detection and mitigation of network threats. This
Office/Small Office environment is proposed in [24]. system incorporates the FortNox enforcement engine,
The possibility for improving and simplifying network which handles possible conflicts with rule insertion. If
security by means of the SDN architecture is evident a rule conflict arises as a result of a new OpenFlow
from this body of research. This potential has also been rule enabling or disabling a prohibited/allowed existing
recognised commercially with a range of SDN security rule, then the new rule is accepted or rejected depending
products at various stages of development. on the level of security authorization of the author to
the existing conflicting rule provider. Although FortNox
IV. S ECURITY C HALLENGES WITH SDN provides numerous components, which are necessary for
While security as an advantage of the SDN framework enforcing security, the authors feel that much work is still
has been recognized, solutions to tackle the challenges needed to offer a comprehensive suite of applications.
of securing the SDN network are fewer in number. Moving from the design space to implementation, one
SDNs provide us with the ability to easily program of the key industry concerns with security in SDN is
the network and to allow for the creation of dynamic satisfaction of the audit process. For network compliance
flow policies. It is, in fact, this advantage that may and operation, a controlled inventory of network devices
also lead to security vulnerabilities. Within this dynamic is required. This involves knowledge of what devices
 TABLE II
C ATEGORIZATION OF THE R ESEARCH ON S ECURITY IN SDN

Research Security OpenFlow SDN Layer/Interface

Work Analysis Enhancement Solution App App-Ctl Ctl Ctl-Data Data

[7], [10], [12] X X X X X

[11] X X X X X
[5] X X X
[13], [14], [21] X X X X X X X
[15] X X X X
[16] X X X X X
[17], [24] X X X X X
[18], [19] X X X X X X
[20], [22] X X X X X X
[23] X X X
[25] X X X X X
[26], [28]–[30], [32] X X X X X X
[31] X X X
[33], [34] X X X X X
[35] X X X X

are running, how they are bound to the network etc. focus on exploiting SDN for enhanced network security
This directly concerns the potential for virtualization than on generating solutions to the identifed security
of network elements and functions as supported by issues. The enhancement work has centred on the use
the SDN framework. Although there is an unresolved of middle-boxes and monitoring systems for security
challenge regarding the feasibility of mapping network service insertion to dynamically detect and/or prevent
state across mobile and virtual functions, some related suspicious traffic during live network operation.
work regarding network verification is worth mentioning. There is further potential in this area to exploit the
In [34], the authors consider the problem of scalability dynamic and adaptive capabilities of the SDN framework
and security of OpenFlow networks and their use in using methods of moving target defense. The work pre-
the cyber-physical space. Verificare allows for specifi- sented in [16] is one such example where randomizing
cation modeling and verification of network correctness, the virtual IP addresses makes it more difficult for an
convergence and mobility-related properties. Hadigol et attacker to breach the network. Without a fixed system to
al. propose the use of a prototype network debugger observe and prepare to attack, the strength of the attacker
[35], which could be used to allow SDN developers to is reduced.
reconstruct the chain of events which lead to a bug and
New methods and techniques must be explored to
identify its root cause.
expand on the programmability of the network enabling
As identified in Section II, the SDN architecture can
dynamic adjustments in security monitoring, detection
be considered as a set of layers and interfaces. The
and prevention capabilities.
layer/interface affected by some of the SDN-specific
security issues was identified in Table I. In a similar A minor observation from the content of Table II
manner, the SDN security research work is classified is that the majority of the work references or im-
in Table II by the layer/interface, which the analysis, plements OpenFlow for the control-data interface. Al-
enhancement or solution targets. The results of this though any alternative to OpenFlow would have sim-
categorization are discussed in the next section. It can ilar attributes, it is worth noting that OpenFlow may
be noted that SANE [5] is included in Table II for not be the only/definitive control-data interface protocol
categorization with respect to affected layers/interfaces. in SDNs. For example, several Internet Engineering
However, as a separate architecture, it is not identified Task Force (IETF) groups have defined protocols re-
as an SDN security enhancement or solution. garding separation of forwarding and control planes,
network configuration and routing. These include IETF
V. D ISCUSSION ForCES (Forwarding and Control Element Separation),
Considering the categorization of research work in PCE (Path Computation Element), Netconf (Network
Table II, it can be seen that there has been greater Configuration), LISP (Locator/ID Separation Protocol)
and I2RS (Interface to the Routing System). In addition, by simultaneously exploiting the programmability and
proprietary protocols are being developed by individual the centralized network view introduced by SDN. The
companies. The work to identify and correct security- second is that these same two SDN attributes expose
related limitations of the OpenFlow protocol should be the network to a range of new attacks. In this article,
considered in the design and development of alternative we have categorized the SDN security challenges and
protocols. This could apply both to the control-data plane presented a comprehensive review of the research work
interface and also to the higher-level abstractions at the on security in SDN to date. Our analysis identifies that
application-control interface, which may present similar regardless of your school of thought, there is yet more to
concerns. be done; more untapped potential and more unresolved
The most significant element to highlight from the challenges. A concerted effort in both directions could
categorization of security-related SDN research is that yield a truly secure and reliable Software-Defined Net-
there is an identifiable disconnect between the security work.
analyses presented to date, which focus on the control-
data plane issues, and the solutions to security issues, R EFERENCES
the majority of which focus on one application-control [1] S. Jain, A. Kumar, S. Mandal, J. Ong, L. Poutievski, A. Singh,
plane issue; that of policy conflict resolution. S. Venkata, J. Wanderer, J. Zhou, and M. Zhu, “B4: Experience
with a globally-deployed software defined wan,” in Proceedings
Considering the breadth of potential security issues of the ACM SIGCOMM 2013 conference. ACM, 2013, pp. 3–14.
outlined in Table I, it is clear that a significant increase in [2] S. Sezer, S. Scott-Hayward, P. Chouhan, B. Fraser, D. Lake,
effort is required to identify solutions to these challenges. J. Finnegan, N. Viljoen, M. Miller, and N. Rao, “Are we ready for
SDN? Implementation challenges for software-defined networks,”
This requirement has been recognised in the past Communications Magazine, IEEE, vol. 51, no. 7, 2013.
year in some areas of the networking community. Since [3] “Network Functions Virtualization - Introductory White Paper,”
the beginning of 2013, various working groups have October, 2012. [Online]. Available: http://portal.etsi.org/NFV/
NFV White Paper.pdf
been established in both the standardization industry [4] C. Douligeris and D. N. Serpanos, Network security: current
and industry research groups. In the Open Network- status and future directions. Wiley. com, 2007.
ing Foundation (ONF) and the European Telecommu- [5] M. Casado, T. Garfinkel, A. Akella, M. J. Freedman, D. Boneh,
N. McKeown, and S. Shenker, “Sane: A protection architecture
nications Standards Institute (ETSI), groups focussed for enterprise networks,” in USENIX Security Symposium, 2006.
specifically on security in SDN and NFV, respectively, [6] M. Casado, M. J. Freedman, J. Pettit, J. Luo, N. McKeown, and
have been launched. In the Internet Research Task Force S. Shenker, “Ethane: Taking control of the enterprise,” in ACM
SIGCOMM Computer Communication Review, vol. 37, no. 4.
(IRTF) and the International Telecommunication Union ACM, 2007, pp. 1–12.
- Telecommunication Standardization Sector (ITU-T), [7] R. Kloeti, “OpenFlow: A Security Analysis,” April
general SDN study groups have been launched in which 2013. [Online]. Available: ftp://yosemite.ee.ethz.ch/pub/students/
2012-HS/MA-2012-20 signed.pdf
security in SDN is an identified issue. [8] S. Hernan, S. Lambert, T. Ostwald, and A. Shostack, “Threat
One of the recurring themes from these industry modeling-uncover security design flaws using the stride ap-
working groups is the importance of designing security proach,” MSDN Magazine-Louisville, pp. 68–75, 2006.
[9] “OpenFlow Switch Specification Version 1.3.2,” Open
in from the start. By this, it is meant that while SDN is in Networking Foundation. [Online]. Available: https://www.
the early stages of development, the associated security opennetworking.org
issues should be identified and resolved. However, SDN- [10] K. Benton, L. J. Camp, and C. Small, “OpenFlow Vulnerability
Assessment,” in Proceedings of the second ACM SIGCOMM
compliant hardware, software and services are already in workshop on Hot topics in software defined networking. ACM,
production and in service. While some of these solutions 2013, pp. 151–152.
are, in fact, SDN security products, many others have [11] D. Kreutz, F. Ramos, and P. Verissimo, “Towards secure and
dependable software-defined networks,” in Proceedings of the
been developed with little or no consideration of the second ACM SIGCOMM workshop on Hot topics in software
security implications of a wide area network deployment. defined networking. ACM, 2013, pp. 55–60.
It is, therefore, essential, that techniques, methods and [12] D. Li, X. Hong, and J. Bowman, “Evaluation of Security Vul-
nerabilities by Using ProtoGENI as a Launchpad,” in Global
policies to overcome the SDN security challenges are Telecommunications Conference (GLOBECOM 2011). IEEE,
explored and defined to enable robust and reliable wide 2011, pp. 1–6.
area SDN deployments. An increased emphasis on this [13] B. Anwer, T. Benson, N. Feamster, D. Levin, and
J. Rexford, “A Slick Control Plane for Network
now could avoid a reduction in the performance and Middleboxes,” Open Networking Summit, 2013. [On-
capability of future SDNs as a result of retrofit security line]. Available: http://nextstep-esolutions.com/Clients/ONS2.0/
solutions. pdf/2013/research track/poster papers/final/ons2013-final51.pdf
[14] S. Fayazbakhsh, V. Sekar, M. Yu, and J. Mogul, “FlowTags:
Enforcing Network-Wide Policies in the Presence of Dynamic
VI. C ONCLUSION Middlebox Actions,” in Proceedings of the second workshop on
There are two schools of thought on security in Hot topics in software defined networks. ACM, 2013.
[15] Z. A. Qazi, C.-C. Tu, L. Chiang, R. Miao, V. Sekar, and M. Yu,
software-defined networking. The first is that signifi- “SIMPLE-fying Middlebox Policy Enforcement Using SDN.”
cant improvements in network security can be achieved ACM SIGCOMM, August 2013.
[16] J. H. Jafarian, E. Al-Shaer, and Q. Duan, “Openflow random [26] E. Al-Shaer and S. Al-Haj, “FlowChecker: Configuration anal-
host mutation: transparent moving target defense using software ysis and verification of federated OpenFlow infrastructures,” in
defined networking,” in Proceedings of the first workshop on Hot Proceedings of the 3rd ACM workshop on Assurable and usable
topics in software defined networks. ACM, 2012, pp. 127–132. security configuration. ACM, 2010, pp. 37–44.
[17] R. Braga, E. Mota, and A. Passito, “Lightweight DDoS flooding [27] R. Sherwood, G. Gibb, K. Yap, G. Appenzeller, M. Casado,
attack detection using NOX/OpenFlow,” in IEEE 35th Confer- N. McKeown, and G. Parulkar, “Flowvisor: A network virtu-
ence on Local Computer Networks (LCN). IEEE, 2010, pp. alization layer,” OpenFlow Switch Consortium, Tech.Rep, 2009.
408–415. [28] S. Son, S. Shin, V. Yegneswaran, P. Porras, and
[18] J. R. Ballard, I. Rae, and A. Akella, “Extensible and scalable G. Gu, “Model Checking Invariant Security Properties
network monitoring using opensafe,” Proc.INM/WREN, 2010. in OpenFlow.” [Online]. Available: http://faculty.cse.tamu.edu/
[19] S. Shin and G. Gu, “CloudWatcher: Network security monitoring guofei/paper/Flover-ICC13.pdf
using OpenFlow in dynamic cloud networks (or: How to provide [29] A. Khurshid, W. Zhou, M. Caesar, and P. Godfrey, “VeriFlow:
security monitoring as a service in clouds?),” in 20th IEEE Verifying network-wide invariants in real time,” ACM SIGCOMM
International Conference on Network Protocols (ICNP). IEEE, Computer Communication Review, vol. 42, no. 4, pp. 467–472,
2012, pp. 1–6. 2012.
[20] A. K. Nayak, A. Reimers, N. Feamster, and R. Clark, “Res- [30] T. Hinrichs, N. Gude, M. Casado, J. Mitchell, and S. Shenker,
onance: dynamic access control for enterprise networks,” in “Expressing and enforcing flow-based network security policies,”
Proceedings of the 1st ACM workshop on Research on enterprise University of Chicago, Tech.Rep, 2008.
networking. ACM, 2009, pp. 11–18. [31] C. Schlesinger, A. Story, S. Gutz, N. Foster, and D. Walker,
[21] J. Naous, R. Stutsman, D. Mazieres, N. McKeown, and N. Zel- “Splendid isolation: Language-based security for software-
dovich, “Delegating network security with more information,” in defined networks,” in Proceedings of the first workshop on Hot
Proceedings of the 1st ACM workshop on Research on enterprise topics in software defined networks. ACM, 2012, pp. 79–84.
networking. ACM, 2009, pp. 19–26. [32] S. Shin, P. Porras, V. Yegneswaran, M. Fong, G. Gu, and
[22] R. Skowyra, S. Bahargam, and A. Bestavros, “Software- M. Tyson, “FRESCO: Modular composable security services
Defined IDS for Securing Embedded Mobile Devices,” for software-defined networks,” in Proceedings of Network and
2013. [Online]. Available: http://www.cs.bu.edu/techreports/pdf/ Distributed Security Symposium, 2013.
2013-005-software-defined-ids.pdf [33] P. Porras, S. Shin, V. Yegneswaran, M. Fong, M. Tyson, and
[23] A. Goodney, S. Narayan, V. Bhandwalkar, and Y. H. Cho, G. Gu, “A security enforcement kernel for OpenFlow networks,”
“Pattern Based Packet Filtering using NetFPGA in DETER in Proceedings of the first workshop on Hot topics in software
Infrastructure.” [Online]. Available: http://fif.kr/AsiaNetFPGAws/ defined networks. ACM, 2012, pp. 121–126.
paper/2-2.pdf [34] R. W. Skowyra, A. Lapets, A. Bestavros, and A. Kfoury,
[24] S. A. Mehdi, J. Khalid, and S. A. Khayam, “Revisiting traffic “Verifiably-safe software-defined networks for CPS,” in Proceed-
anomaly detection using software defined networking,” in Recent ings of the 2nd ACM international conference on High confidence
Advances in Intrusion Detection. Springer, 2011, pp. 161–180. networked systems. ACM, 2013, pp. 101–110.
[25] M. Canini, D. Venzano, P. Peresini, D. Kostic, and J. Rexford, [35] N. Handigol, B. Heller, V. Jeyakumar, D. Mazires, and N. McKe-
“A NICE way to test OpenFlow applications,” in Proceedings of own, “Where is the debugger for my software-defined network?”
the 9th USENIX conference on Networked Systems Design and in Proceedings of the first workshop on Hot topics in software
Implementation, 2012. defined networks. ACM, 2012, pp. 55–60.