A Survey of Security in Software Defined NetworksScott-Hayward, S., Natarajan, S., & Sezer, S. (2016). A Survey of Security in Software Defined Networks. IEEECommunications Surveys and Tutorials, 18(1), 623-654. d in:IEEE Communications Surveys and TutorialsDocument Version:Peer reviewed versionQueen's University Belfast - Research Portal:Link to publication record in Queen's University Belfast Research PortalPublisher rightsCopyright 2015 IEEE.Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, includingreprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution toservers or lists, or reuse of any copyrighted component of this work in other works.General rightsCopyright for the publications made accessible via the Queen's University Belfast Research Portal is retained by the author(s) and / or othercopyright owners and it is a condition of accessing these publications that users recognise and abide by the legal requirements associatedwith these rights.Take down policyThe Research Portal is Queen's institutional repository that provides access to Queen's research output. Every effort has been made toensure that content in the Research Portal does not infringe any person's rights, or applicable UK laws. If you discover content in theResearch Portal that you believe breaches copyright or violates any law, please contact [email protected] date:21. Jun. 2022

IEEE COMMUNICATION SURVEYS & TUTORIALS1A Survey of Security in Software Defined NetworksSandra Scott-Hayward, Member, IEEE, Sriram Natarajan, and Sakir Sezer Member, IEEE,Abstract—The proposition of increased innovation in networkapplications and reduced cost for network operators has wonover the networking world to the vision of Software-DefinedNetworking (SDN). With the excitement of holistic visibilityacross the network and the ability to program network devices,developers have rushed to present a range of new SDN-complianthardware, software and services. However, amidst this frenzy ofactivity, one key element has only recently entered the debate:Network Security. In this article, security in SDN is surveyedpresenting both the research community and industry advancesin this area. The challenges to securing the network from thepersistent attacker are discussed and the holistic approach tothe security architecture that is required for SDN is described.Future research directions that will be key to providing networksecurity in SDN are identified.Index Terms—Software Defined Networking, SDN, NetworkSecurity, OpenFlow, Secure SDN Architecture.I. I NTRODUCTIONOFTWARE-DEFINED networking (SDN) has rocketed tothe top of the networking agenda since its emergenceabout 5 years ago. A fundamental characteristic of the SDNarchitecture is the physical separation of the control plane fromthe forwarding plane. A logically centralized control functionmaintains the state of the network and provides instructionsto the data plane. The network devices in the data plane thenforward data packets according to these control instructions.While this architectural shift has gained significant attentionfrom both the academic and network industry, the concept ofseparating control and data plane functionality has been aroundfor much longer. In the 1980s, central network control [1]was explored followed by active networks in the 1990s [2] tointroduce programmability into the network. During this time,the driving application for the central/programmable networkwas missing. Then with the arrival of cloud computing andvirtualization in the data-center, the right application for SDNwas discovered.One of the proposals for separation of the control and forwarding planes, which led to SDN as it is known today specifically considered the security aspects of such a framework.The SANE architecture [3] centred on a logically centralizedcontroller responsible for authentication of hosts and policyenforcement. At the time of its proposal, this was consideredto be an extreme approach that would require a radical changeSCopyright c 2015 IEEE. Personal use of this material is permitted. However, permission to use this material for any other purposes must be obtainedfrom the IEEE by sending a request to [email protected] Scott-Hayward and S. Sezer are with the Centre for Secure InformationTechnologies, Queen’s University Belfast, Northern Ireland (e-mail: [email protected]; [email protected]).S. Natarajan is with Deutsche Telekom - Silicon Valley Innovation Center(T-Labs), U.S.A. (e-mail: [email protected]).Manuscript received September 30, 2014; revised March 03, 2015 and May19, 2015; accepted June 26, the networking infrastructure and end-hosts. Ethane [4]then extended the work of SANE but with an approach thatrequired less alteration to the original network. It controlledthe network through a centralized controller responsible forenforcing global policy, and Ethane switches that forwardedpackets based on rules in a flow table. This simplified networkcontrol allowed the data and control plane to be separatedto allow for more programmability. Following these earlyworks on security in programmable networks, the focus inthe literature transfers to OpenFlow [5]. OpenFlow is an openstandard developed as part of Stanford University’s clean slateproject. The goal of the project was to provide a platform toenable researchers to run experiments in operational networks.The successful adoption of OpenFlow by both researchersand industry has driven the SDN movement. SDN-enablednetworks have already proven to be successful in variousdeployment scenarios (e.g. Google’s backbone network [6],Microsoft’s public cloud [7], NTT’s edge gateway [8] etc.).In addition, network virtualization software has significantlyprogressed from trial evaluations to production deployments(e.g. VMWare NSX [9], Nuage Networks VSP [10]). Whilethese trends are promising, one area that has received minimalattention is that of security in SDN.There are clear security advantages to be gained from theSDN architecture. For example, information generated fromtraffic analysis or anomaly-detection in the network can beregularly transferred to the central controller. The centralcontroller can take advantage of the complete network viewsupported by SDN to analyze and correlate this feedback fromthe network. Based on this, new security policies to preventan attack can be propagated across the network. It is expectedthat the increased performance and programmability of SDNalong with the network view can speed up the control andcontainment of network security threats.On the down-side, the SDN platform can bring with ita host of additional security challenges. These include anincreased potential for Denial-of-Service (DoS) attacks due tothe centralized controller and flow-table limitation in networkdevices, the issue of trust between network elements due tothe open programmability of the network, and the lack ofbest practices specific to SDN functions and components. Forexample, how to secure the communication channel betweenthe network element and the controller when operated in thesame trust domain, across multiple domains, or when thecontroller component is deployed in the cloud?In the past few years, a number of industry working groupshave been launched to discuss the security challenges andsolutions. Meanwhile, researchers have presented solutions tosome SDN security challenges. These range from controllerreplication schemes through policy conflict resolution to authentication mechanisms. However, when the extent of the

2IEEE COMMUNICATION SURVEYS & TUTORIALSFig. 1. Overview of the SDN Security Surveyissues is compared to the degree of attention placed on them, itis clear that without a significant increase in focus on security,it is possible that SDN will not succeed beyond the privatedatacenter or single organization deployments seen today.The main objective of this paper is to survey the literature related to security in SDN to provide a comprehensivereference of the attacks to which a software-defined networkis vulnerable, the means by which network security can beenhanced using SDN and the research and industry approachesto security issues in SDN.The paper is structured as follows: Section II provides acontext to the work by introducing the characteristics of SDN.In Section III recent SDN and OpenFlow security analysesare presented followed by a categorization of the potentialattacks to which the architecture is vulnerable. Research workpresenting solutions to these attack types is then presentedin Section IV. The arrows in Figure 1 indicate the attackcategories for which solutions have been proposed and, byextension, those areas which have not yet received researchattention. In Section V, the alternative view of SDN securityis introduced with a survey of the research work dealingwith security enhancements based on the SDN architecture.In Section VI, the two perspectives on SDN security arecompared with improved functionality, open challenges, andrecommended best practices identified. Section VII highlightsopen standards and open source industry group work on SDNsecurity. Future research directions are identified in SectionVIII. The paper is concluded in Section IX. For clarity, anoverview of the Security Survey structure is presented inFigure 1.II. C HARACTERISTICS OF S OFTWARE - DEFINEDN ETWORKSIn this section, the discussion begins with understandingthe SDN characteristics in detail. These characteristics arehighlighted in Figure 2 and represent the specific features ofthe SDN framework/architecture that may have an impact onSDN security whether through introducing vulnerabilities orenabling enhanced network security. The 6 characteristics aremarked in Figure 2 at the layer/interface/network element thatthey affect. Potential attacks are introduced in the next Section.1) Logically Centralized Control: A fundamental characteristic of SDN is the logically centralized, but physically distributed controller component. The controllermaintains a global network view of the underlyingforwarding infrastructure and programs the forwardingentries based on the policies defined by network servicesrunning on top of it. While early controller developments(e.g. NOX [11], Beacon [12], Floodlight [13]) werestructured around functioning as an OpenFlow [5] driver,various new implementations (e.g. OpenDaylight [14],OpenContrail [15]) have matured to provide the requiredabstractions to the network services and to support mul-

A SURVEY OF SECURITY IN SOFTWARE DEFINED NETWORKS3Fig. 2. SDN Characteristicstiple programming interfaces (e.g. NETCONF, XMPP,BGP) to manage the forwarding devices.Similarly, evolving from a single controller design,several options for distributed control (controller cluster) have been proposed for scalability and reliabilityrequirements, as shown in Figure 3. Distributed control with multiple controller instances is proposed inOnix [16], SoftCell [17], HyperFlow [18], and Kandoo[19]. These approaches will be discussed in SectionIV. ONOS [20] and OpenDaylight [14] implementdistributed control with multiple instances forming acluster as illustrated in Figure 3. In each case, eachindividual controller instance is the exclusive master ofa set of switches and the controllers are clustered inMaster/Slave groups.2) Open Programmable Interfaces: Unlike traditional networking equipment, SDN physically separates the control and data plane entities. The primary motivation withthis characteristic is to simplify the forwarding devicesand allow the networking software in the controllerto evolve independently. This functionality introducesthe potential for innovation and easier adoption ofnovel solutions. A standardized programmable interface, OpenFlow [5], was adopted by the industry inorder to program multiple flavors of forwarding devices(i.e. ASIC, FPGA-based, Network Processors, virtualswitches) thereby abstracting the complexity of theunderlying hardware. Several interfaces are identifiedin Figure 4: the Control-Data Interface (also knownas the Southbound API such as OpenFlow, OF-Config,OVSDB, NETCONF), the Application-Control Interface(also known as the Northbound API such as REST API)and the East-West Interface between Controllers. TheEast-West interface refers to the bidirectional and lateralcommunication between SDN controllers. These con-(a)(b)Fig. 3. Distributed Control Frameworks for SDN (a) Controller Clustering,and (b) Hierarchical Controltrollers may belong to the same or different SDN controldomains. The east/westbound APIs for this interface arediscussed in [21]. It is noted that in [22], Jarschel et al.propose a definition referring to the east interface forcommunication between SDN controllers and the westinterface for communication between an SDN controllerand other, non-SDN control planes. The interoperabilitybetween SDN and legacy control planes is, however, outof scope of this work.

4IEEE COMMUNICATION SURVEYS & TUTORIALS3) Switch Management Protocol: A companion interfaceto the programmable interface described above is theswitch management protocol (e.g. OF-Config, OVSDB[23]). Such a protocol is required to standardize theconfiguration and management functions of the programmable hardware. For instance, the OF-Config protocol is used to configure and manage an OpenFlowcapable switch as well as multiple logical switches thatcan be instantiated on top of the device. Internally,the protocol uses NETCONF as the transport protocolthat defines the set of operations over a messaginglayer (RPC), which exchanges the switch configurationinformation between the configuration point and thepacket forwarding entity (i.e. (3) in Figure 2).4) Third-party Network Services: SDN allows the integration of third-party network services in the architecture.In a monolithic SDN controller implementation (e.g.RYU, POX, NOX), these applications are compiled andrun as part of the controller module while controllers likeOpenDayLight allow the instantiation of applicationsat run-time, without restarting the controller module.This is analogous to operating systems, wherein softwaremodules and libraries can be downloaded and integratedwithin a running environment. From a deployment standpoint, this drives innovation, allows customization of services, introduces flexibility in the overall architecture toadapt to new features, and reduces the cost of proprietaryservices. Depending on the controller implementation,third-party services can communicate to a controllermodule via internal APIs or open northbound APIs (e.g.REST APIs) supported by the controller.5) Virtualized Logical Networks: Virtualizing the SDNcomponents supports multi-tenancy in the infrastructure.In a typical SDN network, multiple logical switches canbe instantiated in a shared physical substrate such thateach entity can represent individual tenants/customers.The goal here is to containerize the SDN components thereby guaranteeing customized performance, security, and Quality of Service (QoS) based on tenant requirements. While SDN is developing in the ITcommunity, Network Functions Virtualization (NFV) isbeing developed by the Telecommunications industry.NFV uses IT virtualization technologies to virtualizenetwork functions/services previously implemented inproprietary hardware appliances. This supports dynamicand agile network service provision. NFV and SDN areclosely connected offering a software-based networkingparadigm.6) Centralized Monitoring Units: Although not unique tothe SDN architecture, a centralized monitoring unitunifies the analytical capabilities of the infrastructureand creates a feedback control loop with the controller to automate updates to the networking function.For example, a TAP monitoring unit can feed datatraffic to Deep Packet Inspection (DPI) engines thatcan assess the data traffic, identify attack patterns andthen programmatically update the forwarding table toblock attack traffic. (Note: For illustration purposes, themonitoring units are separated from the controller inFigure 2. It is equally possible that this functionality becollocated with the controller.) While the SDN entitiescan internally include several monitoring capabilities, atypical network deployment would consider deployingdedicated monitoring solutions in the infrastructure. Forexample, the OpenFlow protocol provides statistical andstatus information about the switch and its internal state(e.g. the flow state maintained in the Flow Table, thestatus of the ports and links, statistical information onflows, ports, queues, and meters). These are inherentmonitoring functions that are part of the underlyingarchitecture components. As discussed before, a practical deployment can also deploy visibility tools andsolutions like sFlow, NetFlow, or integrate third partyvisibility fabric for monitoring purposes. The monitoringlogic that is part of the feedback loop is responsible forcomprehending the collected information and updatingthe controller for required updates to be provided to thenetwork devices.If the features in Figure 2 are simplified to a set of layersand interfaces as shown in Figure 4, the challenges associatedwith each layer of the framework and on the interfaces betweenthe layers can be identified. This framework is used throughoutthe survey to categorize both the challenges and the proposedsolutions for SDN security.Fig. 4. SDN Functional Architecture illustrating the data, control andapplication layers and interfacesIII. S ECURITY A NALYSES AND P OTENTIAL ATTACKS INSDNGiven the SDN characteristics detailed in Section II, existingsecurity analyses in SDN are discussed next and the potentialsecurity issues in the system are then classified.A. Analyses of SDN SecurityA number of SDN/OpenFlow security analyses precedethis survey [21], [24]–[34]. The first of these references isour initial contribution on this subject of SDN security [24].This current document significantly expands on the original

A SURVEY OF SECURITY IN SOFTWARE DEFINED NETWORKScontribution with detailed discussion of the SDN characteristics and potential attacks, security issues and enhancements,analysis of the industry work on SDN security, and inclusionof recommended best practices and future research directions.In the case of each analysis work [21], [24]–[34], theauthors found that the altered elements or relationship betweenelements in the SDN framework introduce new vulnerabilities,which were not present before SDN. However, the more recentanalyses [24], [30]–[34] also identify security enhancementsintroduced by SDN.OpenFlow is currently the most commonly deployed SDNtechnology. As a result, a number of the security analysesfocus only on OpenFlow. In [25] an analysis of the OpenFlow protocol using the STRIDE threat analysis methodologyis completed [35]. The work focuses on the execution ofInformation Disclosure and DoS attacks, which the authorestablished could be successfully executed. Although a numberof mitigation techniques are proposed, such as aggregatingflow rules to reduce the flow table size, these techniques arenot proven in the work.The OpenFlow switch specification [36] describes the useof Transport Layer Security (TLS) with mutual authenticationbetween the controllers and their switches. However, thesecurity feature is optional, and the standard of TLS is notspecified. The lack of TLS adoption by major vendors (and inthe majority of open-source controllers and switches) and thepossibility of DoS attacks leading to fraudulent rule insertionand rule modification is discussed in [26].In [27] a high-level analysis of the overall security ofSDN is presented with the conclusion that new responses arerequired to the new threats arising from centralized controland network programmability. Three of the seven identifiedthreat vectors are specific to SDN and relate to controllersoftware, the control-data interface, and the control-applicationinterface. A number of solution techniques are proposed. Forexample, replication of controllers and applications to providealternative management/control in the case of hardware orsoftware faults, diversity of controllers for robustness againstsoftware bugs and vulnerabilities in any single controller, andsecure components such as trusted computing bases (TCB)to protect the confidentiality of sensitive security data. Acomprehensive survey of SDN [21] has also been co-producedby the authors of [27]. The security and dependability of SDNare reviewed with a specific focus on the security of OpenFlow and countermeasures for security threats in OpenFlownetworks.The vulnerability of the SDN network to attack has alsobeen tested [28], [29]. In [28], the research network andtestbed, ProtoGENI, has been analyzed. It was discoveredthat numerous attacks between users of the testbed alongwith malicious propagation and flooding attacks to the widerinternet were possible when using the ProtoGENI network.More recently, a preliminary work considered the feasibilityof a fingerprinting attack against an SDN network [29]. Inthe attack, the network is first fingerprinted to determinewhether it uses SDN/OpenFlow switches. The SDN networkis then subjected to a DoS attack on the control plane viathe data-control plane communication path and on the data5plane via the flow table of the network device. A DoS attackrefers to an attempt to make a machine or network resourceunavailable to its intended users. In the case of SDN, thenetwork devices require access to the control plane to receivetraffic management instructions and traffic across the networkrequires access to the network device flow tables to dictatetraffic management policies. The data-control plane interfaceand the network device flow table are therefore points ofvulnerability to DoS attack.The extent to which network security management is improved in SDN-based networks is discussed in [30]. The discussion is split by infrastructure, software stack, and networkprotocols with the majority of the discussion focussed onprotocol security, which the authors define as confidentialityand authentication. They conclude that security of the switchcontroller and controller-controller communication protocolsrequire further work. The security of switch-controller communication has inspired several research works presented laterin this article and, indeed, the industry standardization bodiessecurity group work. Consideration of controller-controllercommunication security is less well explored and an importantconsideration for wide deployment of SDN.In [31], an evaluation methodology is presented for thesecurity of SDN and security by SDN as compared to conventional networks. To evaluate the security of SDN (i.e. securityof the reference architecture), the criteria of confidentiality,authenticity, integrity, availability, and consistency are used.To evaluate the security by SDN (i.e. benefits provided bySDN), the criteria are: network management, costs, and attackdetection and mitigation. The conclusion is that the benefitsoutweigh the drawbacks. Although the authors argue that manyof the threats identified in SDN also exist in conventionalnetworks, they do not explore the greater attack surfaceexposed by the layered architecture of SDN and the impact ofthis on the overall vulnerability of the architecture. As in [30],security challenges related to inter-provider SDN deploymentsare identified for future consideration.In a combination of a security analysis and a frameworkproposal in [33], the authors recommend the use of SDNfor security enhancement in wireless mobile networks. Thework includes a limited survey of SDN-based security solutions categorized by target environment. Several requirementsare identified for the SDN security design; interoperability,responsiveness, compatibility, adaptation, and simplicity. Aframework with a wireless mobile security layer above thecontrol plane interacting with local agents at the data plane isproposed to meet these requirements.The close link between SDN and NFV has been highlightedwith respect to the Virtualized Logical Network characteristicof SDN described in Section II. In [34], the impact of SDNon cloud security and the potential risks introduced whenSDN is deployed within and across clouds are discussed. Theopportunities and vulnerabilities are mixed in the discussion.However, a clear observation is made; that the expansionof SDN deployments from campus networks to wide areanetworks will require increasingly complex security considerations to be incorporated into SDN design. This stemsfrom securely exposing SDN programmability and providing

6IEEE COMMUNICATION SURVEYS & TUTORIALSTABLE IC OMPARISON OF S ECURITY A NALYSES OF SDN AND O PEN F LOWResearch WorkSecurity AnalysisVulnerabilitiesEnhancementsOFAppSDN Security Survey [24]XOF Security [25], OF Vulnerability [26], ProtoGENI [28]XSecure and Dependable SDN [27]XComprehensive Survey [21]XXAttacking SDN [29]XVulnerability of FlowVisor [32]XSDN for Network Security [30]XXXBlessing or Curse? [31]XXXSDN Wireless Mobile [33]XXXCloud Computing Security [34]XXappropriate trust boundaries to secure each layer of the SDNmodel. In Section VIII of this work, future research directionswill be discussed identifying approaches to optimize securityand performance of SDN.The security analyses described in this section are comparatively presented in Table I in terms of their consideration ofOpenFlow and the SDN Layer/Interfaces discussed (Figure 4).As previously mentioned, the focus of many of these analysesis the OpenFlow protocol and a framework that supportsapplications to modify the network state in the forwardingdevice via OpenFlow protocol. As a result, the majority ofissues presented in this Section relate to control and data planesecurity and the control-data interface. A few of these analyses[21], [24], [27] specifically highlight the security issue ofintroducing 3rd party applications to the network. In this paper,a deeper analysis of these issues is provided (Section IV).B. Attacks and Vulnerabilities in SDNTo elaborate the security analysis work, the SDN securityissues are categorized by type and with respect to the SDNlayer/interface affected by each issue/attack. As shown inTable II, the issues are split into seven main categories andprovide a number of specific examples of the way in whichthe security issue might arise. Only network security issues orattacks specific to the SDN framework are detailed. Details ofthe attack scenarios are provided in the following subsectionsand the impacted entities in the architecture are highlightedin Table II. The security issues identified in Table II are alsomapped to the SDN architecture in Figure 5 to highlight theentity and interface impacted by the attack or vulnerability.It can be noted that several of these attacks relate directly tothe characteristics identified in Section II e.g. Potential Attack- Unauthorized Access links to Characteristic - LogicallyCentralized Control. These links will be identified in thesubsequent sections.1) Unauthorized Access: This category relates to accesscontrol. One of the original characteristics of SDN is describedas centralized control. With the evolution of the technology,XXSDN XXXXXXXXXXXXXXXXXXXXXXXthis is more accurately described as logically centralized control, which in many implementations is distributed. In the functional architecture of SDN, it is therefore possible for multiplecontrollers to access the data plane of the network. Similarly,applications from multiple sources (3rd party apps) may linkto a pool of controllers. The controller provides an abstractionto applications so that the applications can read/write networkstate, which is effectively a level of network control. If anattacker impersonated a controller/application, it could gainaccess to network resources and manipulate the networkoperation.2) Data Leakage: There are a variety of potential actionsdescribed in the OpenFlow switch specification [36] for packethandling. These include forward, drop and send to controller.It is possible for an attacker to determine the action appliedto specific packet types by means of packet processing timinganalysis. For example, the time to process a packet passeddirectly from input port to output port will be shorter than fora packet to be redirected to the controller for processing. Theattacker can therefore discover the proactive/reactive configuration of the switch. With a further set of crafted packets, anattacker could infer additional information about the networkdevice. Having discovered the packet type that is redirectedto the controller, the attacker can then generate a volume offake flow requests leading to a Denial of Service (DoS) attack.The relationship between this type of data leakage to the DoSattack is illustrated in [29].Another open challenge in the SDN architecture is thesecure storage of credentials (e.g. keys and certificates) formultiple logical networks in the programmable data plane. Previously, cross-VM (virtual machine) side channel attacks havebeen demonstrated in the cloud environment. In that attack, amalicious VM identifies a vulnerable VM and extracts secureinformation from the targeted resource [37]. Similar dataleakages are possible in the SDN environment. For example,OF-Config instantiates multiple OF-Logical switches on-topof an OpenFlow capable switch. Assume each logical entity isassigned to a different customer. Then, if the logical networksand their associated credentials (e.g. keys, certificates) are

A SURVEY OF SECURITY IN SOFTWARE DEFINED NETWORKS7Fig. 5. SDN Potential Attacks and Vulnerabilitiesnot securely isola

Fig. 1. Overview of the SDN Security Survey issues is compared to the degree of attention placed on them, it is clear that without a significant increase in focus on security, it is possible that SDN will not succeed beyond the private datacenter or single organization deployments seen today. The main objective of this paper is to survey the .