mopdf.com

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 .