Research Trends In Security And DDoS In SDN - University Of Cincinnati

N. Dayal et al.Research Trends in Security and DDoS in SDNTable III. Security requirements by different domains [28].Figure 3. SDN flow sequence.1. Host A wants to forward certain data to Host B; ithands over the first packet to Switch.2. Switch searches its flow table; if the packet does notbelong to any entry in the flow table, it is forwardedto the controller as a packet in through OpenFlowprotocol.3. Controller processes the packet in to compute optimal path to be followed by flow and instructs theswitch about the path by sending a packet outmessage.4. Switch updates its flow table and forwards the packetto next hop.5. Next packet of this flow is sent to switch.6. For second packet onwards, switch has an entryfor the flow, and it need not forward the packet tocontroller again. It directly forwards the packet toHost B.2.4. Challenges in Software-DefinedNetworkIn existing network, control plane and data plane are integrated into a single network node that aims at providingreliability, scalability, and service management [8,9,26] tousers. So the main challenge of SDN is to provide all thesefacilities while dividing control and data plane with faulttolerance capabilities.Reliability: Failure of SDN controller could result insingle point failure that is why it must intelligently configure and validate network topology to prevent failure andincrease availability. In present networks, if one or morenetwork devices or routers fail, traffic can move throughalternate devices without breaking flow continuity. However, with centralized controller architecture in SDN, in theSecurity Comm. Networks 2016; 9:6386–6411 2017 John Wiley & Sons, Ltd.DOI: 10.1002/secDomainLevel of security requirementCorporateAcademicResearchData centerBackboneSpecial iumHighestabsence of standby controller, breakdown of the controllercan collapse whole network.Also, controller should have the ability to support multipath solution in case of link failures. Controller replicationcould be used to solve such problem. A cluster of one ormore controllers in an active standby mode should be used,such that when one controller fails, other should work,maintaining coordination and synchronization amongcontroller.Scalability: Another concern for deployment of SDNis scalability. Scalability could be identified as either controller scalability or network node scalability. Three mainchallenges for ensuring controller scalability are identified. The first challenge is latency introduced betweensingle controller and multiple nodes because of exchangeof network information. The second challenge is the communication between distributed controllers through eastbound and westbound APIs. And the third challenge is themaintenance of controller’s backend database’s size andoperation.Considering the first issue, a distributed or peer-to-peercontroller infrastructure would share the communicationburden of the controller. However, this approach does noteliminate the second challenge of controller-to-controllerinteractions, for which an overall network view is required.Because of lack of eastbound and westbound APIs, thistask becomes more difficult.With increase in number of switches and bandwidthrequirement, controller overhead also increases, resultingin flow setup delay. It is also a challenge to networkscalability.Security: Network being widely spread everywhereincluding industries to research centers makes it difficultto ensure appropriate security to it. Various domains havedifferent security requirements that need to be assured forproper deployment of the network; level of these requirements is given in Table III. Central placement of controllerresolves many of the security issues including authentication of devices and mitigation of attacks but at thesame time being centralized makes it vulnerable to variousthreats too. Without appending good security mechanismsto SDN, it cannot gain popularity. Controller’s centralplacement outside the switch as a software makes it vulner6389

Research Trends in Security and DDoS in SDNable and difficult to secure overall network. As everythingin the network is centrally programmable, hacker needs togain access to the controller only to make changes in thenetwork or steal data. So SDN needs to provide securecommunication by incorporating security techniqueswith it.Interoperability: For complete deployment of SDN,there is a need to replace traditional networking deviceswith SDN enabled devices in the network. For closednetwork environment such as campus networks or datacenters, it is easier to do such swapping with less interference. But in the open network that supports variousbusinesses and critical systems, it is not easy to swap outthese network devices instantly.Therefore, transition of the traditional network to SDNwill require interoperability of SDN with existing networkequipment. For this purpose, Internet Engineering TaskForce’s Path Computation Element [50] could be a possiblesolution. All existing networking elements will use theirPath Computation Element, and it will perform a centralized role. Path Computation Element Protocol is used forcommunication between these network elements.Except southbound, SDN has northbound, eastbound/westbound interfaces. For eastbound or westbound, thereare information exchanges between controllers whereinformation passes through non-SDN control plane.Although the three interfaces make SDN powerful andflexible, but standardization of northbound interface andlack of eastbound or westbound interfaces are stilla challenge.3. SOFTWARE-DEFINED NETWORKSECURITY3.1. Security issues in software-definednetworkSoftware-defined network strengthens the network bymaking it flexible and programmable. It provides centralmanagement and reduces the overall cost of deployment.With security point of view, it provides the global viewof overall network that helps to authenticate and analyzedevices centrally, making it easier to detect and mitigateattacks [35]. Technological advancements have their limitations too. In case of SDN, its strength, that is, centralcontrol, often becomes its limitation that may become thebottleneck for the whole network in worst case scenarios. Researchers have analyzed security that componentsof SDN provide to users and their vulnerabilities too.One such feasibility study is performed in [75] that discussed the importance of SDN in securing network at thesame time its vulnerability to attacks. It analyzed the network functions such as in-line mode security, passive modesecurity, network anomaly detection, and advanced security functions to compare SDN with traditional network.It shows that whether SDN is being accepted widely to6390N. Dayal et al.improve the overall performance of network but in securityfront, more work needs to be done.Overall SDN framework could be divided into severallayers (or vectors as suggested by few researchers), to separately address security issues related to each layer. In[32], authors identified seven threat vectors in SDN as dataplane interfaces, switches, data-control plane interface,control plane, controller-management interface, administration, and untrusted resources. Whereas in [31], authorsidentified layers of SDN as application layer, applicationcontrol interface, control layer, control-data interface, anddata layer; it does not consider management plane, as itis an optional layer. A similar approach to distinguishlayers of SDN was used in [34], which categorized framework as application layer, control layer, infrastructure layer(data plane devices), southbound interface (control-datainterface), and northbound interface (application-controlinterface). Figure 4 presents various attack points in SDNarchitecture; these include dumb switches represented byattack point 1, malicious hosts represented by attack point2, southbound interface for communication between dataplane and control plane represented by attack point 3,controller represented by attack point 4, and northboundinterface for communication between controller and management plane represented by attack point 5. In Table IV,possible attacks in SDN are categorized according to theplane that may get affected by them. Further, we discussissues related to specific planes of SDN while elaboratingthe attack points in Figure 4.3.1.1. Data plane vulnerabilities.Data plane switches are dumb that make them quitevulnerable to various attacks. A compromised node(switch/host) could use this vulnerability against the network. Two studies [33,36] have focused on securityissues arisen because of these malicious nodes presentin data plane. Four studies [31,32,34,35] have discussedvarious attacks that are possible on data plane. Theseattacks include denial of service (DoS)/DDoS attacks, dataFigure 4. Attack points in software-defined network.Security Comm. Networks 2016; 9:6386–6411 2017 John Wiley & Sons, Ltd.DOI: 10.1002/sec

N. Dayal et al.Research Trends in Security and DDoS in SDNTable IV. Categorization of attacks in SDNAttackData modification/forgingTraffic hijackingController hijackingDenial of serviceLack of TLS adaptationARP poisoningLLDP spoofingSide channel attackTCAM exhaustionAffected securityfeatureAffects dataplaneAffects controlplaneAffects vailabilityConfidentiality, esNoYesYesYesYesYesNoNoNoNoARP, Address Resolution Protocol; LLDP, Link Layer Discovery Protocol; SDN, Software Defined Network; TCAM, Ternary ContentAddressable Memory; TLS, Transport Layer Security.Table V. TLS and security support in various commercial switches.Switch vendorHP [76]Brocade [62,67,77]Radware [59,78,79]NEC [59,80]Alcatel Lucent Enterprise [60,81]Open vSwitch [82,83]Security supportTLS supportHP Intelligent Management Center and sFlow at switchesMonitoring with sFlow in switches and OpenDaylight controllerDefensePro attack mitigation solutionDefensePro in collaboration with RadwareMonitoring with sFlow support in switchesVLAN isolation, traffic filteringNoNoNoYesNoYesTLS,Transport Layer Security; VLAN, virtual local area network.modification, repudiation, blackhole attack, and side channel attack. DoS and DDoS are most common and popularattacks on data plane that makes infrastructure device orchannel unavailable for a certain time period to legitimate users. In data modification-based attacks, a maliciousswitch may modify the data or flow rules, being forwardedthrough it to some other node, resulting in inconsistencyof forwarding table, losing data integrity. In Figure 4, thispoint is depicted by 2. Another method for exploiting dataplane vulnerabilities may involve sniffing ongoing datato obtain important information such as a node’s state,controller communication, topology, or the identity of anode. These information could be useful to perform certainattacks in the future, such as to have unauthorized access tosomeone’s data by forging its identity (repudiation), to create blackhole by sending forged messages to the controller,or even to perform side channel attacks. In Figure 4, thispoint is represented by 1.the-middle attack. It exploits the vulnerability of SecureSocket Layer (SSL) 3.0 to attack various TLS or SSL connections. Downgrading of TLS or SSL protocol to lowerversion is allowed for compatibility of communicationbetween two clients. It could be exploited to downgradethe controllers TLS version to SSL 3.0 and exploiting itsvulnerability for attack. In some implementations of SDN,TLS is kept optional [27–30]; there security issues suchas spoofing, data tampering by modifying ongoing data,and repudiation are easily possible. Lack of TLS adaptation could lead to insecure communication; packets withspoofed addresses could be easily forwarded to controller;also, one node may repudiate as some other node to haveaccess to content for that node. Table V analyzes fewswitch vendors with respect to security support and TLSsupport. Network DDoS is quite easy to execute betweencontroller and switches as single controller is serving manyswitches in the network [31–33,35].3.1.2. Southbound interface vulnerabilities.Southbound interface serving communication betweendata plane and controller uses OpenFlow protocol, whichhas been considered vulnerable by many researchers. InFigure 4, point 3 represents the attack point on southbound interface. OpenFlow protocol makes use of Transport Layer Security (TLS); in recent findings, this protocolis shown to be exposed to man-in-the-middle (POODLE)attack [84–86]. POODLE attack that stands for PaddingOracle On Downgraded Legacy Encryption is a man-in-3.1.3. Control plane vulnerabilities.Controller is the easiest target for DDoS in SDN; asthe first packet of each flow needs to be sent to the controller, it sometimes proves to be bottleneck for overallsystem [31–34,36]. Figure 4 represents control plane attackpoint by 4. A malicious controller may perform differentattacks such as DoS, blackhole, and generate fake flowrules [32,33,36]. As each first packet of a flow is initiallyforwarded to the controller, a huge number of fake flowscould be easily generated in the network to perform DoSSecurity Comm. Networks 2016; 9:6386–6411 2017 John Wiley & Sons, Ltd.DOI: 10.1002/sec6391

N. Dayal et al.Research Trends in Security and DDoS in SDNattack on the controller. Another attack possible on the controller is by using fake information. Nodes in the networkmay provide fake information about the route to the controller; using this information controller may create a falseroute for certain hosts, resulting in blackhole. In anothercase, if a controller becomes malicious, it becomes quiteeasy for to generate fake rules resulting into conflicts inthe network.certain techniques to ensure security for not just OpenFlowand controller but other components of SDN too. Thesetechniques include replication, diversity, trust establishment, isolation, self-healing mechanism, dynamic switchassociation, and frequent software update. Replication ofcontroller and applications improves the dependability ofsystem, as in case of fault or failure of one controller,its replica may provide services, also replication isolatesmalicious and faulty controllers and applications to securenetwork. Diversity of applications improves the robustness of system by removing common mode faults. Usingdiverse applications and controllers removes the possibilityof exploiting known vulnerabilities of certain application.An attacker that has gained access to a controller could notbe able to bring down the whole network. Trust betweencontroller and devices or application needs to be ensuredto remove the chances of malicious node or application oreven a malicious controller to threaten the network. Isolation of security domains decreases the chances of attackingwhole system at once. If a domain is attacked, it hasminimal effect on other domains, hence increasing the reliability of the system. Self-healing is also suggested underpersistent adversary circumstances to bring system backto healthy state after any fault in the system. Self-healingmechanism automatically diverts the system back to a bugfree previous healthy state. Dynamic switch associationallows switches to dynamically select which controller toassociate with; it improves fault tolerance of the system.Frequent software updates and patches are used to reducevulnerabilities in the system. Attacks on different planesand countermeasures are discussed in Table VI. SDNbeing a recent technique has only few security proposals practically implemented. Most of the solutions proposepredefined set of policies or rules that are verified againsteach flow coming to the controller. A detailed analysis ofapproaches for securing SDN is presented in Table VII.3.1.4. Northbound interface vulnerabilities.Northbound interface that is used for controller to application layer communication is also a challenge as there areno standard APIs for it [87]. Anyone could exploit this vulnerability of the network. In addition to that, lack of trustedresources in the network also increases the threats to itssecurity. In Figure 4, point 5 represents vulnerability pointof northbound interface.Various solutions are proposed by different researchersto countermeasure these attacks that have been discussedin further section.3.2. Security solutionsBeing centralized, SDN resolves many problems in thetraditional network, while there are certain issues that arisebecause of its centralized nature. That is why, we have useda methodology to classify security solutions on the basis ofwhether they are security provided by SDN or they providesecurity to SDN. Various switch vendors have also focusedon providing security to SDN network with their switches,Table V. One study [28] suggested countermeasures thatcould be used to resolve security issues related to OpenFlow. It included limiting the rate of entering packets atthe controller, filtering desired events, dropping unwantedpackets, reducing time-outs, aggregating similar flows,and providing access control. Another study [53] presentsTable VI. Attack vectors, attacks, and their countermeasures.Threat vectorSpecific to SDNIssuePossible solutionData planeNoData modification, traffic hijacking,DDoS, ARP poisoning, LLDP spoofing,side channel attack, blackhole attack,TCAM exhaustionAggregating flows, self-healingmechanisms, dynamic switch association,frequent updatesControl planeYesLack of TLS adaption, DDoS, singlepoint of failure, blackhole attackFiltering events, replication, diversity,access controlData-control interfaceYesLack of TLS adaption, DDoS,repudiationTLS adaption, rate limiting, filteringevents reducing time-outs, aggregatingflows, access controlApplication planeNoLack of trusted APIIsolation, trust establishment, frequentsoftware updates, secure componentsControl-applicationinterfaceYesLack of trusted APIsTrust establishment, development oftrusted APIs, secure domainsAPI, Application Program Interface; ARP, Address Resolution Protocol; DDoS, Distributed Denial of Service; LLDP, LinkLayer Discovery Protocol; TCAM, Ternary Content-Addressable Memory; TLS, Transport Layer Security.6392Security Comm. Networks 2016; 9:6386–6411 2017 John Wiley & Sons, Ltd.DOI: 10.1002/sec

Security Comm. Networks 2016; 9:6386–6411 2017 John Wiley & Sons, Ltd.DOI: 10.1002/sec[90]OrchSecBy SDNFor SDNFor SDNFor SDNFor SDNFor SDNFor SDNBy SDNBy SDNBy SDNFor SDNFor SDNFor SDNFor SDNFor/by SDNAMQ, automated malware quarantine; SDN, software-defined nSec[43]SDN security considerations indata ably safe SDNFlowGuardSecure computationframework for SDN[39]SDN debugger, cementFrameworkEnhancementSolutionEnhancementType ofsecurityOn demand securityproviderStatistic

SDN security issues [31-37] Security policies in SDN [28,38-52] DDoS [53-56] DDoS vulnerability in SDN [33,36,57] Policies for rescuing SDN from DDoS [58-69] DDoS, distributed denial of service; SDN, software-defined network. focusing on DDoS issue, followed by the comparison of various proposed countermeasures for them. Table I has