Seediscussions,stats,andauthorprofilesforthispublicationat:https://www.researchgate.net/publication/290477553

SecurityinSoftware-DefinedNetworking:ThreatsandCountermeasures

ARTICLEinMOBILENETWORKSANDAPPLICATIONS·JANUARY2016

ImpactFactor:1.05·DOI:10.1007/s11036-016-0676-x

READS

33

6AUTHORS,INCLUDING:

JiafuWan

SouthChinaUniversityofTechnology

47PUBLICATIONS506CITATIONS

SEEPROFILE

DiLi

SouthChinaUniversityofTechnology

53PUBLICATIONS1,274CITATIONS

SEEPROFILE

AthanasiosVasilakos

474PUBLICATIONS6,794CITATIONS

SEEPROFILE

Allin-textreferencesunderlinedinbluearelinkedtopublicationsonResearchGate,

lettingyouaccessandreadthemimmediately.

Availablefrom:JiafuWan

Retrievedon:23January2016

Security in Software-Defined Networking:Threats and Countermeasures

Zhaogang Shu1& Jiafu Wan2

& Di Li2 & Jiaxiang Lin1& Athanasios V. Vasilakos3 &

Muhammad Imran4

# Springer Science+Business Media New York 2016

Abstract In recent years, Software-Defined Networking(SDN) has been a focus of research. As a promising networkarchitecture, SDN will possibly replace traditional network-ing, as it brings promising opportunities for network manage-ment in terms of simplicity, programmability, and elasticity.While many efforts are currently being made to standardizethis emerging paradigm, careful attention needs to be also paidto security at this early design stage. This paper focuses on thesecurity aspects of SDN. We begin by discussing characteris-tics and standards of SDN. On the basis of these, we discussthe security features as a whole and then analyze the securitythreats and countermeasures in detail from three aspects,based on which part of the SDN paradigm they target, i.e.,the data forwarding layer, the control layer and the application

layer. Countermeasure techniques that could be used to pre-vent, mitigate, or recover from some of such attacks are alsodescribed, while the threats encountered when developingthese defensive mechanisms are highlighted.

Keywords Software-defined networking . SDN . Security .

Security countermeasures

1 Introduction

With the advent of the era of clouds [1], cloud service providersneed to satisfy various network service requirements (such asbandwidth, service quality, safety or reliability) for differentusers, which requires that the network architecture has high elas-ticity and flexibility, and that the network resources can be allo-cated flexibly by way of network function virtualization. How-ever, in traditional network architectures, commonly used closednetwork equipment (such as routers or switches) have the fol-lowing drawbacks: a) software and hardware are tightly coupled;b) Network protocols that are too complicated are integrated intothe devices; c) Almost all devices are manufacturer-proprietary,whichmeans it is difficult to change their functionality or updatethem. With the ever increasing network scales, the above char-acteristics make traditional networks increasingly cumbersome,leading to a situation where cloud service providers cannot cus-tomize and optimize network resources effectively according tospecific user requirements [2, 3].

The Software Defined Network (SDN) [4] refers to a noveland revolutionary network architecture, which can currentlybe considered as a best practice for network functionvirtualization. The basic idea is to strip the complex controllogic out from all the network nodes, and form a logical con-trol center to guide the packet forwarding; this change wouldachieve the goal of controlling all network traffic freely by

* Jiafu Wanjiafu_wan@ieee.org

Zhaogang Shuzhaogang.shu@gmail.com

Di Liitdili@scut.edu.cn

Jiaxiang Linlinjx2015@qq.com

Athanasios V. Vasilakosvasilako@ath.forthnet.gr

Muhammad Imrancimran@ksu.edu.sa

1 Fujian Agriculture and Forestry University, Fuzhou, China2 South China University of Technology, Guangzhou, China3 Lulea University of Technology, Luleå, Sweden4 King Saud University, Riyadh, Saudi Arabia

Mobile Netw ApplDOI 10.1007/s11036-016-0676-x

software programming without changing existing network to-pology. As one of the most promising technologies, SDN hasincomparable advantages over traditional network architec-tures: a) The decoupling of forwarding and control allowsapplication innovation and equipment upgrades to be indepen-dent from each other, which would accelerate the develop-ment and deployment of new network applications; b) SDNsimplifies the network management model, which allows op-erators to manage the network conveniently; c) The central-ized control logic has a global view of the network, which canprovide enough information for the operator to optimize net-work utilities or improve network performance. Therefore,SDN makes up for the defects of traditional networks, andcan meet multi-tenant network requirements in a cloud envi-ronment more effectively.

Currently, OpenFlow [5] is the de facto standard of SDN, itwas proposed by the research team Cleanslate of Stanford Uni-versity. The widespread acceptance of OpenFlow by academiaand industry makes this SDN standard very successful [6]. Inindustry, many commercially-oriented SDN-enabled networkshave been deployed, such as Microsoft’s datacenter network[7] and Google’s backbone network [8, 9]. What’s more, a lotof SDN-enabled network virtualization software has been sig-nificantly developed, such as VMWare NSX [10] and NuageNetworks’ VSP [11]. In academia, the top international confer-ence, SIGCOMM, has established a special workshop namedhotSDN since August 2012, which calls for papers that reportthe latest research achievements on SDN. In addition, manywell-known universities, such as Stanford and Princeton, havealso sprung up research projects related to OpenFlow/SDN,which involves controller design, forwarding performance,routing decisions’ optimization, network virtualization applica-tions, programmable wireless networks, energy saving indatacenter networks, etc.

Except for the research topics mentioned above, there isalso a research direction that has not attracted much attention,which is the security of SDN [12, 13]. If the security of SDNcannot be ensured, their development will encounter a lot ofresistance during the process of replacing traditional networkarchitecture, and even become altogether irrelevant. In the pastfew years, in order to address security threats of SDN, relatedworking organizations have been founded to study the corre-sponding security challenges and solutions [14]. At the sametime, some solutions against SDN security threats have beenproposed, which include controller replication schemes, au-thentication and authorization mechanisms, schemes to pro-tect controllers against Denial of Service or Distributed Denialof Service (DoS/DDoS) attacks, traffic monitoring and analy-sis, flow-table overflow attack protection, and others [15].

In this article, we analyze SDN from a security perspectivewith the objective of shedding light on the new security capa-bilities and the new security threats that accompany this newarchitecture. Furthermore, we also survey countermeasures

against these threats, through which SDN security can be en-hanced. The main contributions of this paper include: a) Acomparison of advantages and disadvantages of SDN as op-posed to traditional networks regarding security issues fromthe perspective of overall architecture. b) A dissection of thesecurity threats of SDN from the perspective of different func-tion layers and attack types in detail, and pointing out possiblesecurity countermeasures.

The rest of paper is organized as follows: Section II presentsan overview of SDN architecture. Section III analyzes securityissues of SDN. Section IV discusses SDN security threats andcorresponding countermeasures in detail. Section V concludesthe paper and points out future research directions.

2 Overview of SDN architecture

SDN is a kind of emerging network architecture which decou-ples data forwarding from the control logic; currently, theseaspects are tightly integrated in traditional network equipment,such as switches and routers. The decoupling of dataforwarding and the control logic enables the network controland applications to be programmable [16]. Generally, SDNarchitecture can be divided into three layers, respectivelycalled the data forwarding layer, the control layer and theapplication layer from bottom to up, as illustrated in Fig. 1.

2.1 Data forwarding layer

The data forwarding layer consists of many SDN switches,which are physically connected by wired or wireless media.Each switch is a simple device in charge of forwarding net-work packets and has a forwarding table, named the FlowTable, which contains thousands of rules that are used to for-mulate forwarding decisions.

Each rule item in the Flow Table is made up of three fields:the action, the counter and a pattern. The pattern field defines theflow pattern, which is basically the set of header field values ofthe packet. When data packets are received, the switch willsearch its Flow Table to find a rule that matches the fields.

Once the switch finds such a rule, the counter of the ruleincreases, and the action corresponding to the particular rulewill be performed. Otherwise, the switch will notify the con-troller to request for help or simply discard the packet. It isworth noting that forwarding rule items are not generated bythe switch node itself, but are pushed down by the controllerfrom the control layer.

2.2 Control layer

As the SDN’s brain, the control layer manages and controlsthe entire network. We refer to the network node that imple-ments these functionalities as the SDN controller, and it is

Mobile Netw Appl

generally deployed as a separate physical device with specificsoftware. The SDN controller communicates with the switchthrough a standard south-bound API, e.g., OpenFlow, and hasa global view of the entire network topology at the dataforwarding layer, i.e., switches and links. Various routing pro-tocols, such as BGP and OSPF, run on the SDN controller sothat all the data forwarding taking place in the data layer isbased on instructions placed by the controller.

As the de facto standard of SDN, OpenFlow was initiallydesigned with a single controller for simplicity, which consti-tutes however a potential single point of failure. Therefore,almost all recent SDN architecture implementations, such asFloodlight [17], NOX [18] and OpenDaylight [19], supportmultiple distributed controllers, which improves the scalabil-ity and availability of network resources. In the multi-controller architecture, each individual controller is responsi-ble for controlling only a portion of the switches. In order tomaintain the consistency of the network’s status and workcollaboratively, an individual SDN controller can communi-cate with other controllers in the network through east–west-bound APIs, as discussed in [20].

2.3 Application layer

The application layer allows network operators to respondrapidly to the various business requirements. Innovative ap-plication software has been built to function on top of SDNcontrollers so that various application requirements are met

[21], such as network virtualization [22], topology discovery[23], traffic monitoring [24], security enhancement [25], loadbalancing [26], and others.

The application layer communicates with the controllayer through north-bound APIs, such as the REST API.The control layer provides an abstraction of the network’sphysical resources for the application layer, which meansthat network operators can change the data paths of packetsusing only software programming centrally on the SDNcontrollers, and not configure all the physical switches inthe data path one by one.

3 Security analysis of SDN architecture

Now, we will look into the SDN architecture’s characteristics’impact on security. Compared to traditional network architec-tures, security threats of SDN will be even more concentrated,as opposed to the dispersion seen in the network elements oftraditional networks. Therefore, because of its design nature,SDN has security advantages and security defects. Its advan-tages include:

a) Effective monitoring of abnormal traffic. Due to the factthat the SDN controller can perceive the entire networktraffic simultaneously, it is easier to notice abnormal be-havior in network traffic caused by an attacker.

Application layer

Control layer

Data forwarding layer

South-bound API

(e.g. OpenFlow )

North-bound API

e.g. REST)

Load

balancing

Topology

discovery

Traffic

monitoring

Security

enhancement

Network

virtualization

East-west API East-west API

SDN switch SDN controller

Fig. 1 The architecture of SDN

Mobile Netw Appl

b) Timely dealing with vulnerabilities. Another importantadvantage can be attributed to the nature of the program-mable network environment. Once a new threat has beendetected, operators can program new software to analyzeand deal with the vulnerability immediately, withoutspending time to wait for an update of the operating sys-tem or application software integrated in themanufacturer-proprietary devices. In addition, the SDNcontroller can achieve a security policy configurationcovering 2–7 layers of the Open Systems Interconnection(OSI) architecture, and provide more granular securitycontrol.

On the other hand, the natural security defects of SDNinclude:

a) Vulnerable controller. Most functions, such as networkinformation collection, network configuration, androuting calculation, are concentrated in the SDN control-ler. The architecture of SDN provides a more concentratedtarget for, and greatly reduces the difficulty of such at-tacks. At the same time, the development of cloud com-puting provides the attacker with very large-scale comput-ing abilities; with the support of cloud computing plat-forms, attackers can easily implement attacks. If the at-tackers successfully seize the controller of an SDN, theycan cause massive paralysis in network services and affectthe whole network covered by the controller.

b) Risks caused by open programmable interfaces. Due totheir open nature, SDN are more susceptible to securitythreats. First, it makes the software vulnerabilities of theSDN controller fully exposed to attackers, as the latterwill have enough information to formulate an attack strat-egy. Second, the SDN controller provides a large numberof programmable interfaces for the application layer andthis level of openness may lead to an abuse of the inter-face, such as embedding malicious code, such as a virus.Therefore, the open interfaces of SDN controllers need tobe carefully evaluated and scrutinized.

c) More attack points. As the SDN is divided into threelayers, the entities of each layer may be spread acrossdifferent locations of the network; communication be-tween these entities will be necessary and frequent.Hence, compared to traditional networks, SDN providemore possible attack points for attackers, as shown inFig. 2. In the figure, we point out six possible attack pointsin the SDN architecture using red stars, and we will de-scribe them in the order labeling shown.

& The SDN switch. A SDN switch is generally a sepa-rate device composed of related hardware and soft-ware, which vulnerable to attacks. An example vul-nerability is the size limitation of Flow Tables.

& The links between SDN switches. Almost data packetstransmitted between SDN switches are not encrypted,and may contain users’ sensitive information. Thesepackets can be intercepted by attackers easily, espe-cially when the links between switches are wirelessmedia.

& The SDN Controller. As stated previously, the con-troller is the most attractive target for attackers. Dueto the openness of programmability and complexityof its functionality, the controller’s software is inevi-tably vulnerable, and this can be exploited for mali-cious attacks.

& The links between the controller and the switches. Allforwarding rules are inserted into switches by the con-troller. The data packets that contain these rules can betampered with by attacker through eavesdropping onthe link between the controller and switch, which willresult in a spurious rule insertion or malicious rulemodification. Once fraudulent rules are installed inthe switch, the data packets will not be forwardedcorrectly.

& The links between controllers. In a multi-controllerenvironment, the communication between differentcontrollers is necessary for retaining the consistentstate of the whole network. The data packets in thelinks between controllers can be intercepted, whichcould provide possible clues to attackers forcompromising the controllers.

& The application software. The application software isbuilt on the controller directly and is generally locatedon the same physical device with controller. When theapplication software invokes the functions of the con-trollers through the north-bound APIs, malicious codemaybe embedded into the controller. Hence, the ap-plication software is considered the most convenientattack point for seizing the controllers.

4 Security threats to SDN and correspondingcountermeasures

With the advancement of research into SDN, the security is-sues of SDN attract more and more attention from manufac-turers and operators. In this section, we will describe in detailthe main security threats and countermeasures that have beenpresented. According to the above-presented SDN architec-ture and related security analysis, we divide the threats andcorresponding countermeasures into three categories based onwhich layer of the SDN architecture contains the

Mobile Netw Appl

corresponding attack target, i.e., the forwarding layer, the con-trol layer and the application layer.

4.1 Threats to the data forwarding layerand countermeasures

The data forwarding layer is located at the bottom of the SDNarchitecture, and contains thousands of switches that are inter-connected with each other. These switches are responsible forforwarding packets. If a switch is compromised, the packetsthat flow through it will not be forwarded correctly. In addi-tion, switches are the direct entry point of network access forend users, and attackers can attack a switch by simplyattaching a link to a port of the switch. Therefore, it is veryimportant to recognize security threats and find correspondingcountermeasures for SDN switches. We consider the architec-ture and working principles of SDN switches adhering to theOpenFlow specification, as shown in Fig. 3.

An OpenFlow switch generally contains three functionmodules, namely the OpenFlow client, the Flow Table andthe Flow Buffer. When the switch receives a packet from aninput port, it will place this packet in the Flow Buffer, andsearch the Flow Table to try to find a rule that matches themessage fields of this packet, such as a MAC/IP address and aTCP/UDP port. If an appropriate rule is found, the packet willbe removed from the Flow Buffer and be forwarded to anoutput port. Otherwise, the switch will send a Packet_In mes-sage through the OpenFlow client to the controller to requestinstructions. After receiving the new message, the controllerwould make a routing calculation and insert a new rule into theFlow Table. According to the above process, we can identifythree main security threats; they are a man-in-the-middle

attack between the switch and the controller, which targetsto tamper with rules, a DoS attack to overflow the Flow Table,and a DoS attack to overflow the Flow Buffer.

4.1.1 Man-in-middle attack between switch and controller

(1) Threat descriptionA man-in-the-middle attack is a classic network intru-

sion method, the main principle of which is to insert anagent node between the source and the destination node,and is used to intercept communication data and tamperwith them without being detected by either communicat-ing sides. Specific attack methods of man-in-the-middleattacks include session hijacking, DNS spoofing, port

Switch Controller

❶

❷

❹

❸❺❻

A�acker

Applicaon Soware

Possible a�ack point

Fig. 2 Possible attack points inthe SDN architecture

OpenFlow Client

FlowTable

Controller

Insert/delete

Flow Buffer

input ports output ports

Request/nofy

Man-in-middle a�ack to tamper with rules

DoS a�ack to overflow FlowTable

DoS a�ack to overflow flow cache

guidesearch

Fig. 3 Working principles and security threats of OpenFlow switches

Mobile Netw Appl

mirroring, and so on. A man-in-the-middle attack be-tween the controller and switches is an ideal choice forattacking an SDN, as it can be used to intercept andtamper with the forwarding rules issued to the switch inorder to gain control of network packet forwarding. Afterthis has been achieved, further attacks can be implement-ed by attackers, such as black-hole attacks. In addition,we know that the controller and the switches maybe notbe directly connected physically, i.e., a packet from aswitch to the controller may travel throughmultiple otherswitches. Therefore, all switches and the hosts connectedto them directly on the communication path are suscep-tible to be converted to agent nodes in a man-in-the-middle attack.

(2) CountermeasuresIn order to guard against man-in-the-middle attack,

much research work has been done both in academiaand in the industry. The most obvious approach is tocreate a secure channel between the controller andswitches. In OpenFlow specification v1.0, TransportLayer Security (TLS) [27] was used to secure thecontroller-switch communication. However, the config-uration of TLS is very complex, and many vendors donot provide support of TLS in their OpenFlow switches.Thus, later versions of the OpenFlow specification de-clare that the configuration of TLS is optional. Moreover,TLS cannot provide any TCP-level protection, whichmeans that the network is susceptible to TCP-level at-tacks. Since TLS is not enforced, our main security chal-lenge in this case is to distinguish between normal andforged flow rules, and to eliminate forged rules beforethey cause ill effects [28].

Some alternative countermeasures have been present-ed to this threat. FlowChecker [29] is a configurationvalidation tool able to recognize internal configurationerrors of switches effectively. Specifically, it first createsmodels of all the interconnected switches, and then exe-cutes end-to-end rapid analysis and verification for allswitch configurations through a binary decision diagramand mode l check ing techno logy, by whichmisconfigurations can be detected. As a software exten-sion module of the NOX controller, FortNOX [30] pro-vides a role-based authorization and authentication secu-rity enhancement strategy. Through its novel analysisalgorithm, it can detect collisions of various forwardingrules. The algorithm has good robustness and performsits functions correctly even in cases of malicious appli-cations’ attack. At the same time, before the applicationsmodify the forwarding rules, FortNOX will verify thelegitimacy of the modifications through digital signa-tures or security constraints. VeriFlow [31] acts as a mid-dle layer between a controller and the switches, and ismainly responsible for the dynamic verification of

network variables within the scope of the entire network,especially when a new forwarding rule is inserted. Ex-periments based on the Mininet, an OpenFlow simula-tion environment, have been conducted and results showthat, by tracking routing data, VeriFlow can finish thedetection of a new forwarding rule within a few hundredmilliseconds, which is very effective.

Due to the fact that controller connectivity is veryimportant for the proper operation of switches, redundantlinks or fast link recovery mechanisms are helpful tomitigate the effects of man-in-the-middle attacks be-tween the controller and the switches. The OpenFlowprotocol itself has connection stability testing mecha-nisms, whereby each switch sends activity preservingmessages to the controller periodically. If the master con-troller fails to respond, it can automatically instruct theswitch to connect to a backup controller. Controller rep-lication is similar to the mechanism that proposed in [32].That is to say, if the switch does not receive the responsefrom the controller during a certain period of time, theswitch thinks that the controller has failed, and it willquickly establish a connection with another controller,allowing the network to work continuously.

4.1.2 DoS attack to saturate the flow table and flow buffer

(1) Threat descriptionThe reactive rule design of OpenFlow renders the

switch vulnerable to Denial of Service (DoS) attacks.Since packets with an unknown destination address willcause a new rule to be inserted in the switch, an attackercan generate large amounts of packets destined to un-known network hosts in a short time, thus quickly fillingup a switch’s limited Flow Table storage capacity. Whenthe Flow Table is saturated by irregular traffic, legal traf-fic will not be forwarded correctly, as there will be nomore available capacity for inserting new rules.

Except for the Flow Table, another target of DoS at-tacks is the Flow Buffer. As described above, beforepackets are forwarded out, they are buffered in the FlowBuffer waiting for the results of the rule search or theinsertion of a new rule. Packets in the Flow Buffer willbe marked for deletion on a First In First Out (FIFO)basis to release the storage space. As in the case of theFlow Table, the storage capacity of the Flow Buffer isalso limited. Attackers can flood large packets belongingto a different flow than that encountered by the switchnormally; the switch has to buffer these large packets andthis leads to the saturation of the Flow Buffer. Whenlegitimate packets are received, the Flow Buffer willnot have enough space to store these packages, and thesenew packets will have to be dropped.

Mobile Netw Appl

(2) CountermeasuresWe will discuss some examples of related counter-

measures that can alleviate this kind of attack. FlowVisor[33] can enable network operators to differentiate net-work packets according to the header fields of packets.FlowVisor acts as an agent between switches and thecontroller; it accepts rules from controllers and re-writes them so the resulting rules only affect the portionof the network that a given controller is allowed to con-trol. For example, a controller may be allocated the net-work segment comprised of all traffic to and from anorganization’s web servers. This controller might thencreate a rule to drop all UDP traffic in response to aDoS attack. When FlowVisor receives this rule, it willrewrite it to drop all UDP traffic to and from the webservers, leaving the rest of the network unaffected.

Virtual source Address Validation Edge (VAVE) [34] isa preemptive protection scheme with OpenFlow/NOX ar-chitecture aiming to mitigate DoS attacks caused throughIP spoofing. A new packet that does not match any rule inthe Flow Table will be sent to the controller for sourceaddress validation, during which IP spoofing may be de-tected, in which case the controller creates a rule in theFlowTable to stop the specific flow from that source ad-dress. Moreover, address validation in VAVE is very flex-ible, while the packet process overhead and the requiredresources are greatly reduced compared to other relatedworks. R. Braga et al. proposed a kind of lightweight de-fense method against DDoS attack [35], which is based onthe characteristics of the traffic flow. This method showsgood performance in the analysis of attack detection.

The use of intrusion detection systems could help rec-ognize abnormal traffic flows caused by DoS attack. Suchsystems could be integrated with related mechanisms fordynamic access control of the switches’ behavior, such asrate bounds for control layer requests. Resonance [36] issuch a system that can strengthen dynamic access controlpolicy of the controller. The system issues dynamic secu-rity policies directly to the forwarding data layer in theSDN architecture based on real-time warnings and packetflow level information.

4.2 Threats to the control layer and countermeasures

In the SDN architecture, the control layer, i.e., the OpenFlowcontrollers, and its security have a direct impact on the dataforwarding layer [37]. If a controller is compromised, thewhole network, including a potentially large number ofswitches, may be affected. This is because if a switch cannotreceive forwarding rules from the controller, it will not knowhow to forward packets. Hence, due to its important role, thecontroller may become a key target for attackers. The main

security threats to and countermeasures of the control layer aredescribed below.

4.2.1 DoS/DDoS attacks on the controller

(1) Threat descriptionDoS/DDoS attacks attempt to make controller func-

tions unavailable to legitimate users by exhausting com-puting or memory resources, as shown in Fig. 4.

An attacker could produce enormous flooding trafficin a short time to an SDN-enabled network using theirown host or controlling other distributed zombie hosts.This traffic will be mixed together with normal traffic,and it will be difficult to distinguish between the twotypes. According to the OpenFlow specification, if aswitch does not know how to handle a new packet, it willfirst store this packet in its Flow Buffer and then send aPacket_In message to the controller to request for in-structions. Therefore, in the case of a DoS attack, thecontroller will have to deal with an enormous amountof Packet_In messages generated by the flooding trafficin a short time, which may lead to an exhaustion of re-sources for processing normal traffic. At the same time,the bandwidth between the controller and the switchesmay be fully occupied by the attacking traffic and thiswill seriously reduce the performance of the wholenetwork.

(2) CountermeasuresIn order to alleviate the threats of DoS / DDoS on the

controller, we can analyze the characteristics of trafficflows stored in the OpenFlow switches to detect this kindof attack. FloodGuard [38] is a SDN-oriented light-weight security framework, which is protocol indepen-dent. FloodGuard contains two software modules, theActive Flow Analyzer and Packet Migration, respective-ly. In order to guarantee the security of a SDN, the ActiveFlowAnalyzer conducts a dynamic analysis based on thereal-time running logic of controller, so that it can detecttraffic flows caused by DoS attacks. Packet Migration isresponsible for buffering the received packets and sub-mitting them to the controller for processing at a limitedrate through a rotation scheduling algorithm, which pre-vents the controller from consuming too much comput-ing resources. When the DoS attack is discovered, thePacket Migration module will redirect a table-miss mes-sage to the data forwarding layer. At the same time, theActive Flow Analyzer will monitor the current networkflow to determine a variety of sensitive parameters orvariables, by which the controller can generate forwardflow rules and install them to the switch proactively.

A DDoS is a more potent DoS attack, and its principleis that the attacker can hijack a large number of compro-mised hosts and control them to produce large-scale

Mobile Netw Appl

distributed attack traffic simultaneously to attack a target,such as the controller. In order to cope with DDoS at-tacks, researchers [39] proposed a DDoS Blocking Ap-plication (DBA). The DBA runs on the controller, anddistinguishes between normal traffic and attack trafficthrough a Locator/ID Separation Protocol (LISP) [40].When the position of a network node changes, theDBAwill notify the corresponding change to the control-ler by locator, which is the clue to discovering the attack.In addition, if the transmission rate of the traffic exceedsa certain value, the controller will consider it as attacktraffic and drop these packets directly.

A Content-Oriented Networking Architecture(CONA) [41] is a proxy node located between the clientand the content server, and can communicate with thecontroller. Content request messages from clients areintercepted, analyzed and filtered by CONA, in order tomitigate the harm of DDoS attacks. When the rate ofrequest messages arriving at the content server exceedsa certain value, a DDoS attack is considered to be inprogress. The controller will send a message to eachrelevant CONA agent in order to avoid spreading theattacking traffic and normal messages will be redirectedto a new server address.

From the above, we can see that the features of SDNare suitable for defending against DoS attacks, and futuresolutions for DoS protection may be developed on theapplication layer of SDN architecture.

4.2.2 Threats on distributed multi-controllers

(1) Threat descriptionIn order to alleviate the risk of having a single point

failure in the controller, SDNwere originally designed asa single controller architecture, which lacks scalability

and reliability. Therefore, the solution of distributed con-trol (controller clusters) has been proposed [42], in whicheach individual controller instance functions as the mas-ter of some switches and different controllers can com-municate with each other to collaboratively manage thewhole network. However, multiple physical controllersmanaging the network instead of a single one should betransparent to the data forwarding layer, which meansthat the controllers need to appear as a single controllerfor the entire network. In this situation, an applicationthat spans multiple network control domains will needto deal with several security problems, such as authenti-cation, authorization, and privacy issues during networkinformation transmission. In addition, with the distribut-ed collaboration of multiple controllers, the dynamicswitch-over of the master controller and the coexistenceof multiple controllers in a single network domain cancause configuration conflicts [43]. Therefore, in themulti-controller architecture, an inconsistent configura-tion is also a hidden security threat.

(2) CountermeasuresDISCO [44] provides control layer functions for dis-

tributed heterogeneous networks, and is implementedbased on Floodlight [45] with a special protocol, theAdvanced Messaging Queuing Protocol [46]. DISCOconsists of two modules, an inter-domain control moduleand an intra-domain control module. The inter-domaincontrol module is responsible for monitoring and man-aging the priority of data travelling between the domains,so that flow paths with different priorities can be calcu-lated and forwarded. Therefore, the inter-domain controlmodule can dynamically redirect or stop traffic flow todeal with attacks. The intra-domain control module isresponsible for managing the communication betweencontrollers, and includes a message transceiver as wellas a number of agents. The message transceiver is

Controller (exhausng resources)

Legimate usersA�acker

Packet_In messages (flooding traffic)

Waing for processing(normal traffic)

Fig. 4 DoS / DDoS attack oncontroller

Mobile Netw Appl

designed to find neighboring controllers and to provide acontrol channel regulating the communication betweencontrollers. Agents can exchange the entire network’sinformation using the communication channel providedby the message transceiver module. We can see that theDICSO can effectively deal with security threats facedby distributed controllers.

McNettle [47] is a scalable SDN controller supportingmulti-core CPUs, which demonstrates strong extensibil-ity features due to the fact that it allows the addition of allkinds of control algorithms. An operator can also extendMcNettle to make it become an advanced programminglanguage for managing the behavior of traffic flow, suchas monitoring state changes of each network node andobtaining a global view of the entire network’s data flowthat can be used to deal with all kinds of malicious at-tacks effectively. In addition, compared with the NOXcontroller, McNettle has better performance.

HyperFlow [48] is a scalable event-driven distributedcontroller platform, in which multiple controllers canoperate simultaneously and each controller has the abil-ity to make forwarding decisions locally. In this way,HyperFlow can greatly reduce the time of generatingand installing new flow rules, which will improve theperformance of the entire control layer.

Load balancing technology [49] can also be used toimprove scalability and provide the ability to dealwith security threats for SDN controllers. In addition,the total number of controllers and their logical place-ment will also affect the safety of the controller and itsscalability [50].

In [51], the placement of dynamic controllers isdiscussed and a framework for the dynamic deploy-ment of multiple controllers is proposed. In thisframework, the quantity and location of the control-lers can be adjusted dynamically according to the net-work’s parameters. The authors of [52] presents a con-troller optimization framework, which suggests that asingle controller should at least meet certain delayrequirements, including the communication delayfrom controller to the switch and between the control-lers, so as to effectively deal with related attacks.

4.2.3 Threats from applications

(1) Threat descriptionSince higher-layer applications can obtain network

information only by invoking the API provided by thecontroller, the latter not only needs to ensure the unin-hibited access of legitimate applications, but also preventmalicious or incorrect applications from causing securitythreats. Applications running on the controller will pose

serious security threats to the controller itself. Differentapplications have different functional requirements,which result in a need to customize a different securitypolicy for each of them. For example, load balancingapplications may need to have access to network packetstatistics, and intrusion detection applications (IDS) mayneed to check the header field of packets. Such customsecurity policies based on different application require-ments have not been designed yet.

(2) CountermeasuresGenerally, in order to deal with security threats from

higher-level applications, related solutions include ac-cess authentication of the application, isolation of theresources available to the application, auditing and track-ing. The Security-enhanced Floodlight controller (SE-Floodlight) [53], which is based on the original Flood-light controller, features additional security measures; forexample, it provides an audit subsystem that tracks allsecurity events so as to detect attacks effectively. SE-Floodlight provides a programmable north-bound APIto manage the permissions of applications, which func-tions as a mediator between applications and controller.SE-Floodlight not only contains an application authenti-cation module that used to verify the integrity of thesoftware modules, but also provides a role-based func-tion authorization module, which can assign differentprivileges according to the different roles of the applica-tions. FRESCO [54] is a security development frame-work for OpenFlow applications, which is designed toenable the rapid design and modular composition of soft-ware function modules. FRESCO provides many securi-ty software modules that implement various securityfunctions, such as attack deflectors, IDS logic, firewalls,scan detectors, and corresponding APIs to invoke thesemodules. Security applications based on FRESCO canbe deployed on any OpenFlow controller to detect andinhibit threats. The authors also demonstrated the utilityof FRESCO and its performance.

4.3 Threats to the application layer and countermeasures

In the application layer, attackers can tamper with the net-work configuration, steal network information, seize net-work resources and so on through inserting spyware ormalware computer programs to the application. In thismanner, they can interfere with the normal operation ofthe control layer and influence the reliability and availabil-ity of the network.

Although OpenFlow can deploy security detection algo-rithms for security applications, these security applications arenot mandatory [55]. The variety of applications developed bydifferent independent organizations using different

Mobile Netw Appl

programming languages could produce interoperability incon-sistency or security policy conflicts. Some of the security threatsto and countermeasures of the application layer are describedbelow.

4.3.1 Illegal access

(1) Threat descriptionAccording to the specification of OpenFlow, applica-

tions running on the controller are very flexible and ex-tensible and have privileges to access network resourcesand control network behavior. However, most of theseapplications are developed by third-party organizations,not controller vendors. Therefore, the lack of a standard-ized security mechanism for SDN applications causesserious security threats. Security vulnerabilities basedon threat vectors in SDN are presented in [56]. The au-thors opine that it is necessary to design mandatorymechanisms to create a trust relationship between thecontroller and applications running on it. Although therecurrently exist various techniques to certify devices in anetwork, there is no commonly accepted mechanism forverifying network applications.

(2) CountermeasuresPermOF [57] is a fine-grained permission system

that can provide privilege control to OpenFlow

controllers and applications running on top of it.PermOF summarizes a set of 18 permissions thatneeded to be enforced by the controller APIs, andalso proposes a customized isolation frameworkthat maintains various priorities for applicationsand isolates the control traffic from the data trafficto achieve comprehensive resource isolation andaccess control.

NICE [58] is a new solution for enforcing modelchecking with symbolic execution of event handlers,which can quickly explore the state space of unmod-ified controller programs written for the popular NOXplatform. NICE can also be used as a tool to automatethe testing of OpenFlow applications to verify theircorrectness. Verificare [59] is a tool for modeling dis-tributed systems using formal verification techniques.Authors demonstrated this tool by modeling anOpenFlow network iteratively to verify its correctnessand critical properties. VeriCon [60] is a verificationsystem which can confirm the correctness of the con-troller’s programs. VeriCon implements classicalFloydHoare-Dijkstra deductive verification throughfirst-order logic and desired network-wide invariants.Experimental results show that VeriCon is able to val-idate correctness and identify bugs rapidly for inlarge-scale SDN applications.

Table 1 Security threats and typical countermeasures in SDN architecture

Targeted level Threats type Caused by Typical countermeasures

Data forwardinglayer

Man-in-middle attack betweenswitch and controller

• The communication channel is notsecure without TLS support

• FlowChecker [29]• ForNOX [30]• VeriFlow [31]• Controller replication [32]

DoS attack to saturate FlowTable and Flow Buffer

• Limited storage capacity of FlowTable and Flow Buffer

• Enormous number of packets in a short time

• FlowVisor [33]• Virtual source Address Validation

Edge (VAVE) [34]• Resonance [35]

Control layer DoS/DDoS attack on thecontroller

• Attacking traffic can be mixed withnormal traffic and is hard to distinguish

• Limited computing and storageresources of the controller

• FloodGuard [38]• DDoS Blocking Application [39]• Content-Oriented Networking

Architecture (CONA) [40]

Threats based on distributedmulti-controllers

• Distribution of access control• Incorporation difficult for multi-tenant controllers• Inconsistent configuration of multiple controllers

• DISCO [44]• McNettle [47]• HyperFlow [48]

Threats from applications • Open programmatic interface• Malicious Applications

• SE-Floodlight [53]• FRESCO [54]

Applicationlayer

Illegal access • Bypassing of the authentication mechanism• Software vulnerabilities of the controller

• PermOF [57]• NICE [58]• Verificare [59]• VeriCon [60]

Security rules and configurationconflicts

• Variety for application software• Difference of access control and accountability

for various application software

• Flover [61]• Anteater [62]• NetPlumber [63]

Mobile Netw Appl

4.3.2 Security rules and configuration conflict

(1) Threats descriptionIn order to provide a wide range of network services,

the application layer needs to have security applicationsfor accessing the security interfaces of the controller.Along with the complexity of the applications, conflictsmay appear between security rules, resulting in a confu-sion of network services and management complexity.

(2) CountermeasuresFlover [61] is a model checking systemwhich verifies

flow policies using assertion sets. Flover is implementedbased on NOX using the Yices SMT solver and can pro-vide a formal validation of the functions of an OpenFlownetwork’s security behavior. In addition, Flover supportsa batch mode for obtaining responses from a controllerquickly.

Anteater [62] proposes a static analysis method fordebugging network configuration conflicts, which canoffer verification functionality for the data forwardinglayer. Generally, it has a short run time, and may detectproblems that have occurred rather than issues in real-time for blocking potential disruptions to the network.

NetPlumber [63] is a policy detection tool, which canmonitor network consistency caused by an incrementalchange in the network’s state in real-time. Header SpaceAnalysis (HSA) [64] is the theoretical basis for the tool,which is the same authors’ previous work and can quick-ly validate every network status update through incre-mental calculations based on the dependency sub-graph.

A conceivable scenario is that the firewall is bypassedand switch flow rules are rewritten. In [65], the authorapplied HSA on the SDN firewall and developed a con-flict detection and resolution algorithm, which can createand maintain a dynamic flow graph to detect the flowspace and the authorization space of the firewall. Con-flicting parts of the flow graph can be avoided byinserting flow-blocking rules or refusing to insert newrules, which will strengthen SDN network securitygreatly.

4.4 Summarization of security issues

For convenience, Table 1 presents a summary of the securitythreats that SDN networks are exposed to, along with possiblecountermeasures that are discussed in this section.

5 Conclusions

In this paper, we concisely reviewed the characteristics andarchitecture of SDN. We explained how SDN function and

analyzed their issues and countermeasures from a securityperspective, and gave SDN great security characteristics ofthe uniqueness and openness. Then, we discussed the stateof the art of SDN security and analyzed the security issuesfrom three aspects: the data forwarding layer, the control layerand the application layer. Several preventive and mitigationtechniques were also described to address some of those se-curity issues. In the future, network virtualization and middle-boxes based on cloud computing will be considered an impor-tant application for SDN, which will bring additional securitythreats. Therefore, the issue of security in these applications isexpected to draw increasing amounts of attention.

Acknowledgments This work was supported in part by the Fundamen-tal Research Funds for the Central Universities (No. 2015ZZ079), theNatural Science Foundation of Jiangxi Province, China (No.20151BAB207024), the Natural Science Foundation of Fujian Province,China (No. 2014J05045), the Natural Science Foundation of GuangdongProvince, China (No. 2015A030308002), and the National Natural Sci-ence Foundation of China (Nos. 61262013, 61572220, 41401458,61363011, and 51575194). Imran’s work is supported by the Deanshipof Scientific Research at King Saud University through Research groupNo. (RG # 1435-051).

References

1. Chen M, Zhang Y, Li Y, Mao S, Leung V (2015) EMC: emotion-aware mobile cloud computing in 5G. IEEE Netw 29(2):32–38

2. Wan J, Yan H, Suo H, Li F (2011) Advances in cyber-physicalsystems research. KSII Trans Internet Inf Syst 5(11):1891–1908

3. SuoH, Liu Z,Wan J, ZhouK (2013) Security and privacy inmobilecloud computing. In: Proceedings of the 9th IEEE InternationalWireless Communications and Mobile Computing Conference,Cagliari, Italy

4. Cisco Inc. (2013) Software-defined networking: why we like it andhow we are building on it. White Paper

5. McKeownN, Anderson T, Balakrishnan H, Parulkar G, Peterson L,Rexford J, Turner J (2008) OpenFlow: enabling innovation in cam-pus networks. ACM SIGCOMM Comput Commun Rev 38(2):69–74

6. Liu J, Li Y, Chen M, Dong W, Jin D (2015) Software-definedinternet of things for smart urban sensing. IEEE Commun Mag53(9):55–63

7. Hong CY, Kandula S, Mahajan R, Zhang M, Gill V, Nanduri M,Wattenhofer R (2013) Achieving high utilization with software-driven WAN. ACM SIGCOMM Comput Commun Rev 43(4):15–26

8. Google Inc. (2012) Inter-datacenter WAN with centralized TEusing SDN and OpenFlow. Open Network Submit

9. Jain S, Kumar A, Mandal S, Ong J, Poutievski L, Singh A, VenkataS, Wanderer J, Zhou J, ZhouM, Zolia J, Hölzle U, Stuart S, VahdatA (2013) B4: experience with a globally-deployed software definedWAN. In: Proceedings of the ACM SIGCOMM, pp 3–14

10. VMware NSX. [Online] http://www.vmware.com/products/nsx/11. Nuage Networks VSP. [Online] http://www.nuagenetworks.net/

products/virtualized-services-platform/12. Ahmad I, Namal S, Ylianttila M, Gurtov A (2015) Security in

software defined networks: a survey. IEEE Commun SurvTutorials 17(4):2317–2346

Mobile Netw Appl

13. Zhang H (2014) A vision for cloud security. Netw Secur 2014(2):12–15

14. Benton K, Camp L J, Small C (2013) Openflow vulnerability as-sessment. In: Proceedings of the second ACM SIGCOMM work-shop on Hot topics in software defined networking, pp 151–152

15. Scott-Hayward S, O’Callaghan G, Sezer S (2013) Sdn security: asurvey. In: IEEE SDN Future Networks and Services (SDN4FNS),pp 1–7

16. Pan P, Nadeau T (2011) Software driven networks problem state-ment. IETF Internet-Draft

17. Floodlight controller documentation for developers [Online].Available: http://www.projectfloodlight.org/floodlight/

18. Gude N, Koponen T, Pettit J, Pfaff B, Casado M, McKeown N,Shenker S (2008) NOX: towards an operating system for networks.ACM SIGCOMM Comput Commun Rev 38(3):105–110

19. OpenDaylight.[Online]. Available: http://www.opendaylight.org20. Kreutz D, Ramos FM, Esteves Verissimo P, Esteve Rothenberg C,

Azodolmolky S, Uhlig S (2015) Software-defined networking: acomprehensive survey. Proc IEEE 103(1):14–76

21. Lara A, Kolasani A, Ramamurthy B (2014) Network innovationusing openflow: a survey. IEEE Commun Surv Tutorials 16(1):493–512

22. Bernardo DV (2014) Software-defined networking and networkfunction virtualization security architecture. Internet EngineeringTask Force. [Online]. Available: https://tools.ietf.org/html/ draft-bernardo-sec-arch- sdnnvfarchitecture-00

23. Yang M, Li Y, Jin D, Zeng L, Wu X, Vasilakos A (2015) Software-defined and virtualized future mobile and wireless networks: a sur-vey. ACM/Springer Mob Netw Appl 20(1):4–18

24. Yuan W, Deng P, Taleb T, Wan J, Bi C (2015) An unlicensed taxiidentification model based on big data analysis. IEEE Trans IntellTransp Syst. doi:10.1109/TITS.2015.2498180

25. Jing Q, Vasilakos A, Wan J, Lu J, Qiu D (2014) Security of theinternet of things: perspectives and challenges. Wirel Netw 20(8):2481–2501

26. Namal S, Ahmad I, Gurtov A,YlianttilaM (2013) SDN based inter-technology load balancing leveraged by flow admission control. In:IEEE SDN for Future Networks and Services (SDN4FNS), pp 1–5

27. Dierks T (2008) The transport layer security (TLS) protocol version1.2 [Online]. Available: http://tools.ietf.org/html/rfc5246

28. Wasserman M, Hartman S (2013) Security analysis of the opennetworking foundation (ONF) OpenFlow switch specification.Internet Engineering Task Force. [Online]. Available: https://tools.ietf.org/html/ draft-mrw-SDNec-openflow-analysis-02

29. Al-Shaer E, Al-Haj S (2010) FlowChecker: configuration analysisand verification of federated OpenFlow infrastructures. In:Proceedings of the 3rd ACM Workshop on Assurable and UsableSecurity Configuration, pp 37–44

30. Porras P, Shin S, Yegneswaran V, Fong M, Tyson M, Gu G (2012)A security enforcement kernel for OpenFlow networks. In:Proceedings of the First Workshop on Hot Topics in SoftwareDefined Networks, pp 121–126

31. Khurshid A, Zhou W, Caesar M, Godfrey P (2012) Veriflow: ver-ifying network-wide invariants in real time. ACM SIGCOMMComput Commun Rev 42(4):467–472

32. Fonseca P, Bennesby R, Mota E, Passito A (2012) A replicationcomponent for resilient OpenFlow-based networking. In: IEEENetwork Operations and Management Symposium (NOMS), pp933–939

33. Sherwood R, Gibb G, Yap K K, Appenzeller G, Casado M,McKeown N, Parulkar G (2009) Flowvisor: a networkvirtualization layer. OpenFlow Switch Consortium, Tech. Rep

34. Yao G, Bi J, Xiao P (2011) Source address validation solution withOpenFlow/NOX architecture. In: 19th IEEE InternationalConference on Network Protocols (ICNP), pp 7–12

35. Braga R, Mota E, Passito A (2010) Lightweight DDoS floodingattack detection using NOX/OpenFlow. In: IEEE 35th Conferenceon Local Computer Networks (LCN), pp 408–415

36. Nayak A K, Reimers A, Feamster N, Clark R (2009). Resonance:dynamic access control for enterprise networks. In: Proceedings ofthe 1st ACMWorkshop on Research on Enterprise Networking, pp11–18

37. Shin S, Yegneswaran V, Porras P, Gu G (2013) Avant-guard: scal-able and vigilant switch flow management in software-defined net-works. In: Proceedings of the 2013 ACM SIGSAC Conference onComputer & Communications Security, pp 413–424

38. Wang H, Xu L, Gu G (2015) FloodGuard: a dos attack preventionextension in software-defined networks. In: 45th Annual IEEE/IFIPInternational Conference on Dependable Systems and Networks(DSN), pp 239–250

39. Lim S, Ha J I, Kim H, Kim Y, Yang S (2014) A SDN-orientedDDoS blocking scheme for botnet-based attacks. In: IEEE SixthInternational Conference on Ubiquitous and Future Networks(ICUFN), pp 63–68

40. IETF Locator/ID Separation Protocol (LISP) [Online]. Available:http://datatracker.ietf.org/wg/lisp/

41. Suh J, Choi H G, Yoon W, You T, Kwon T, Choi Y (2010)Implementation of a Content-Oriented Networking Architecture(CONA): a focus on DDoS Countermeasure. In: Proceedings ofEuropean NetFPGA Developers Workshop

42. Scott-Hayward S (2015) Design and deployment of secure, robust,and resilient SDNControllers. In: 1st IEEE Conference on NetworkSoftwarization (NetSoft), pp 1–5

43. Li H, Li P, Guo S, Nayak A (2014) Byzantine-resilient securesoftware-defined networks with multiple controllers in cloud.IEEE Trans Cloud Comput 2(4):436–447

44. Phemius K, Bouet M, Leguay J (2014) Disco: distributed multi-domain sdn controllers. In: IEEE Network Operations andManagement Symposium (NOMS), pp 1–4

45. Big Switch Inc. (2012) Developing floodlight modules. floodlightOpenFlow controller Tech. Rep.

46. Advanced message queuing protocol. [Online]. Available: http://www.amqp.org

47. Voellmy A, Wang J (2012) Scalable software defined network con-trollers. In: Proceedings of the ACM SIGCOMM 2012 Conferenceon Applications, Technologies, Architectures, and Protocols forComputer Communication, pp 289–290

48. TootoonchianA, Ganjali Y (2010) HyperFlow: a distributed controlplane for OpenFlow. In: Proceedings of the 2010 Internet NetworkManagement Conference on Research on Enterprise Networking.USENIX Association, pp 3–3

49. Liu J et al (2016) Leveraging software-defined networking for se-curity policy enforcement. Inf Sci 327:288–299

50. Heller B, Sherwood R, McKeown N (2012) The controller place-ment problem. In: Proceedings of the First Workshop onHot Topicsin Software Defined Networks, ACM, pp 7–12

51. Bari MF, Roy AR, Chowdhury SR, Zhang Q, ZhaniMF, Ahmed R,Boutaba R (2013) Dynamic controller provisioning in softwaredefined networks. In: 2013 9th IEEE International Conference onNetwork and Service Management (CNSM), pp 18–25

52. Hock D, Hartmann M, Gebert S, Jarschel M, Zinner T, Tran-Gia P(2013) Pareto-optimal resilient controller placement in SDN-basedcore networks. In: 25th IEEE International Conference onTeletraffic Congress (ITC), pp 1–9

53. Security-enhanced floodlight. [Online]. Available: http://www.sdncentral.com/education/toward-secure-sdn-controllayer/2013/10/

54. Shin S, Porras P, Yegneswaran V, Fong M, Gu G, Tyson M (2013)FRESCO: Modular Composable Security Services for Software-Defined Networks. In : Proceedings of Network and DistributedSecurity Symposium, pp 1-16

Mobile Netw Appl

55. Shin S, Porras P, Yegneswaran V, Gu G (2013) A framework forintegrating security services into software-defined networks. In:Proceedings of the 2013 Open Networking Summit (ResearchTrack poster paper)

56. Kreutz D, Ramos F, Verissimo P (2013) Towards secure and de-pendable software-defined networks. In: Proceedings of the SecondACM SIGCOMM Workshop on Hot Topics in Software DefinedNetworking, pp 55–60

57. Wen X, Chen Y, Hu C, Shi C, Wang Y (2013) Towards a securecontroller platform for openflow applications. In: Proceedings ofthe Second ACM SIGCOMM Workshop on Hot Topics inSoftware Defined Networking, pp 171–172

58. Canini M, Venzano D, Peresini P, Kostic D, Rexford J (2012) ANICEway to test OpenFlow applications. In: Proceedings of the 9thUSENIX Conference on Networked Systems Design andImplementation

59. Skowyra R, Lapets A, Bestavros A, Kfoury A (2013) Verifiably-safe software-defined networks for CPS. In: Proceedings of the 2ndACM International Conference on High Confidence NetworkedSystems, pp. 101–110

60. Ball T, Bjmer N, Gember A, Itzhaky S, Karbyshev A, Sagiv M,Valadarsky A (2014) Vericon: towards verifying controller

programs in software-defined networks. ACM SIGPLAN Not49(6):282–293

61. Son S, Shin S, Yegneswaran V, Porras P, Gu G (2013) Modelchecking invariant security properties in OpenFlow. In: 2013 I.E.International Conference on Communications (ICC), pp 1974–1979

62. Mai H, Khurshid A, Agarwal R, Caesar M, Godfrey P, King S(2011) Debugging the data plane with anteater. ACM SIGCOMMComput Commun Rev 41(4):290–301

63. Kazemian P, Chan M, Zeng H, Varghese G, McKeown N,Whyte S(2013) Real time network policy checking using header space anal-ysis. In: USENIX Symposium on Networked Systems Design andImplementation, pp 99–111

64. Kazemian P, VargheseG,McKeownN (2012) Header space analysis:static checking for networks. In: USENIXSymposium onNetworkedSystems Design and Implementation NSDI, pp 113–126

65. Wang J, Wang Y, Hu H, Sun Q, Shi H, Zeng L (2013) Towards asecurity-enhanced firewall application for openflow networks. In:Cyberspace Safety and Security, Springer International Publishing,pp. 92–103

Mobile Netw Appl