ControllerSEPA: A Security-Enhancing SDN Controller Plug-in for OpenFlow Applications

Transcription

1 th International Conference on Parallel and Distributed Computing, Applications and Technologies ControllerSEPA: A Security-Enhancing SDN Controller Plug-in for OpenFlow Applications Yuchia Tseng Paris Descartes University yuchia.tseng@outlook.com Zonghua Zhang Institute Mines-Télécom Lille/TELECOM Lille CNRS UMR 5157 SAMOVAR Lab zonghua.zhang@telecom-lille.fr Farid Naït-Abdesselam Paris Descartes University naf@parisdescartes.fr Abstract Software-defined networking (SDN), as a new network paradigm, has the advantage of centralizing control and global visibility over a network. However, security issues remain a major concern and prevent SDN from being widely adopted. One of the challenges is the prevention of malicious OpenFlow application (OF app) access to the SDN controller as it opens a programmable northbound interface for third party applications. In this paper, we address app-to-control security issues with focus on five main attack vectors: unauthorized access, illegal function calling, malicious rules injection, resources exhausting and manin-the-middle attack. Based on the identified threat models, we develop a light-weight plug-in, which is called ControllerSEPA, by using RESTful API to defend SDN controller against malicious OF apps. Specifically, ControllerSEPA can provide the services including OF app-based AAA control (unlike OpenDaylight and ONOS which offer user-based or role-based AAA control), rule conflict resolution, OF app isolation, fine-grained access control and encryption. Furthermore, we study the feasibility of deploying ControllerSEPA on five open source SDN controllers: OpenDaylight, ONOS, Floodlight, Ryu and POX. Results show that the deployment operates with very low complexity, and most of time the modification of source codes is unnecessary. In our implementations, the repacked services in ControllerSEPA create negligible latency (0.1% to 0.3%) and can provide more rich services to OF apps. I. INTRODUCTION Software-defined networking (SDN), as a new network paradigm, decouples the control plane from the data plane. The control plane, or the so-called SDN controller, acts as the network brain to provide the functionalities for centralized control and network visibility. However, the security concern with respect to SDN controllers is the main obstacle that prevents SDN from being widely adopted. Notably the question of securing the SDN controller from the malicious behaviors of OF app remains a constant issue. For example, references [1] [2] [3] [4] [5] show the importance of limiting the access of OF app to controller resources. The tasks of modifying all controller source codes or even scanning all the related functions for modifying and enhancing its security are unfeasible. [6] [7] [8] [9] show the risk of flow rule conflict introduced by the OF app. However, it is challenging to find a way of resolve these issues due to the coexistence of OF apps. In this paper, we present a controller-independent plugin to delegate the services provided by SDN controller and to expose them to OF apps after hardening them. II. RELATED WORK PermOF [3] presents 18 permissions to control OF app without actual implementation. [1] and [2] implement their permission control by modifying the source codes of the controller. However, it is infeasible to secure the controller s functions by modifying every function in the source code. In the worst scenario, it would need to scan all the functions (methods). For example, in order to control the topology information, OperationCheckpoint would need to modify the codes of the two methods: getallswitchmap and getlinks in two different classes Controller.java and LinkDiscoverManager.java, respectively, since both of them provide the information about network topology in Floodlight. In some SDN controllers, like OpenDaylight and ONOS, it s quite hard to scan and find out all these relatedmethods and harden them. In contrast, ControllerSEPA reduce the deployment complexity. Reference [10] also decouples the external OF app by RESTful API and encrypts the communication with TLS, but it does not provide accounting services as in ControllerSEPA. [10] implements only in Floodlight and our work provides a wider study on five SDN controllers, which shows this approach is feasible and readily applied on the current mainstream SDN controllers. In our work, we also studied further possible functions that can be deployed by this RESTlike system. Rosemary secures the controller by separating OF apps from the controller via IPC to exchange information between the controller and the OF apps [11]. We use RPC, i.e., RESTful APIs, to decouple the OF app. Our approach can be implemented on existing controllers. SE-Floodlight extends from FortNOX to detect the flow rule conflicts in controller; however, it is not suitable for big networks as it will produce tremendous latency when the controller verifies every flow rule in the kernel [7]. ControllerSEPA can detect rule conflicts outside of controller, even remotely, to keep controller s performance. III. ATTACK MODELS AND EXISTING COUNTERMEASURES A. App-to-control attacks SDN enables networking functionalities to be written in software, called OF applications (OF apps), by using open APIs to facilitate development and accelerate network innovations. Unfortunately, problems arise when an OF app contains flaws, vulnerabilities, or malicious logic that may interfere with control layer operations. In worse scenarios, the attack from app- to-control can be caused not only by the non-authenticated /16 $ IEEE DOI /PDCAT

2 TABLE I. APP-TO-CONTROL ATTACKS AND CORRESPONDING COUNTERMEASURES OF app authentication OF app authorization Operation accounting OF app isolation Rules resolution OF app monitoring Unauthorized access " " Illegal functions calling " " " Malicious rules injection " " " " Exhausting resources " " " Man-in-the-middle attack Communication encryption " OF app but also by the authenticated one such as in the flow rule conflict [7] [8]. 1) Unauthorized access: Once the malicious app can access the controller s data storage or internal memory, the abuse of such trust could lead to various types of attacks impacting the entire network. For example, the packet in count value is kept in the controller s internal storage for the usage of DoS detector or traffic monitoring. However, a malicious app can clear packet in count in the internal storage to confuse the DoS detector app. The controller also contains the network link information and flow rules in data storage, if the OF app can modify these values, the topology and flow rules will be tampered [2] [11]. 2) Illegal functions calling: SDN controllers always contain built-in functions; however, once these functions are used maliciously, it will cause the controller to crash. For example, a malicious OF app can terminate the controllers by calling the function exit() in Floodlight, OpenDayLight and POX (sys.exit(0)) [11]. The IOFMessage Listener service in Floodlight could be used to change OF app order to process packet in message, as a result, the malicious OF app can interrupt the communication for packet in messages among with other OF apps by modifying the order via this service [5]. 3) Malicious flow rules injection: In SDN, forwarding decisions are flow-based, which is defined by a set of packet field values acting as a match (filter) criterion, with fields such as actions (instructions), priority, counter and timeout etc. However, a malicious OF app can insert a flow rules to reach the unexpected destination, to block another legitimate service or to confuse the service provided by other OF apps coexisting on the same SDN controller such as the action set and priority in flow rule [6] [7] [12]. 4) Exhausting resources: A malicious OF app can create multiple memory objects, large number of threads, infinite loops or non-stop growing linked lists to deplete the resources of the controller s host. Controllers such as NOX, Beacon, Floodlight and OpenDaylight do not limit memory allocations to its applications, which can ultimately result in the controller crashing with an out-of-memory error [2] [11]. 5) Man-in-the-middle attack: OF app exchanges data with SDN controller via northbound interface. One of the most popular northbound interfaces is RESTful API, which is adapted by controllers such as OpenDaylight, ONOS, Ryu, Floodlight,etc. The shortage of supporting SSL, i.e. HTTPS for OF app, makes communication in the northbound interface at risk of being tampered or eavesdropped. Controllers like Floodlight, ONOS and OpenDaylight support HTTPS. Ryu does not and OpenMUL does so only partially [13] [14] [15] [16] [17]. B. Countermeasures 1) Authentication: To prevent the controller from malicious OF app, the basic protection is to authenticate the OF app. For example, SE-Floodlight and Rosemary use digital signatures to authenticate the OF app [7] [11]. Reference [10] also adopts key pairs to authenticate the OF app. 2) Authorization: [1], [2], [3], and [10] show the OF app-based access control. PermOF proposes the use of 18 permission sets under four distinct categories without experimental evaluation of the access control system proposed. OperationCheckpoint adopts the part of the permission set of PermOF in constraining the northbound interface access and implements the permission set in SDN controller Floodlight, but this permission set does not enable OF app users to distinguish malicious applications from benign ones [1]. Moreover, this permission set is not controller-independent, i.e. it should modify the source codes on every controller that attempts to apply this system. [10] proposes a controllerindependent solution for securing the integration of external OF app via RESTful API. However, it is not able to find the malicious OF app. Inspired by Android permission control, [2] is a permission system based on OF messages states and the actions. 3) Accounting: The audit log record is useful for network troubleshooting as well as a data source for security monitoring as an OF app modifies flow tables or sends a packet out message etc [1] [10] [7] [4]. For instance, SE-Floodlight [7] introduces an audit subsystem that traces all security-related events occurring in the control layer. With this auditing record, the controller can report to the network administrator the event time, the message type, and the full message content, etc 4) Flow rules verification: There are several different approaches to mitigate the security issues caused by malicious or misconfigured flow rules. The FlowChecker[18] system encodes OpenFlow flow tables into Binary Decision Diagrams (BDD) and uses model checking to verify security properties. Veriflow [19] is a real-time system that slices flow rules into equivalence classes to efficiently check for invariant property violations. However, the evaluation of FlowChecker and Veriflow do not consider the handling of set action commands as in FortNOX and SE-Floodlight [6] [7]. On top of VeriFlow, [20] provides a library to verify correctness properties for OF apps on several controller platforms. FlowGuard extends HSA [21] for rule-conflict resolution in the context of firewalls in order to build more robust firewalls in SDN environments. FLOVER [22], a model checking system based on the Yices SMT solver existing on the SDN App plane, verifies the instantiated flow rules which does not violate the network s predefined security 269

3 Fig. 1. High-level overview of ControllerSEPA architecture policy. SRV checks the priority-bypassing attack by binding topology to check flow rules [12]; FortNOX and SE-Floodlight use the Alias Set Reduce(ASR) method to detect the rule conflict [6] [7]. 5) OF app isolation: One of the primary reasons behind the fragility of the controllers is their tight coupling with applications. YANC adopts UNIX-like permission to separate OF apps from exposing the network configuration and stating it as a file system [23]. [11] and [24] propose to separate OF app from SDN controller even by processes. Rosemary [11] separates OF app from the controller by invoking each new OF app in Rosemary as a new process. Rosemary s OF app connects to the SDN controller process through the IPC (inter- process communication). The basic network services in the Rosemary kernel communicate with each other through an IPC channel, and the implication is that if a service crashes, other services are unaffected. 6) OF app monitoring: An application that keeps allocating memory can consume all of the available memory in a host, thereby affecting other applications. Limiting resources that the OF app uses and incorporating resource monitoring services that track and recognize the resource utilization of OF app could be the complementary protection of app isolation to mitigate this effect [4] [11]. 7) Communication encryption: To protect the controller from man-in-the-middle attack, encryption is one of the popular solutions to secure the northbound interface for RESTful API. We summarize this section in Table I. IV. DESIGN PRINCIPLE OF CONTROLLERSEPA Based on the threat models in Section III, we find that it is insufficient to limit OF app behaviors with only authentication and gross-grained authorization or to merely adopt a role-based authorization. We need to control OF app with AAA, i.e., authenticating OF app, authorizing OF app, and accounting or monitoring OF apps operations [1] [3] [6] [7] [11] [25]. Detecting the rule conflict protects controller from malicious rule injection and separating the OF app from controller can avoid the crash of controller due to resource exhausting. Hence, we continue the work [10] to provide a wider and deeper study on how to use the REST-like system to protect SDN controller from malicious OF app. Firstly, we explore more functions that can possibly be deployed via the REST-like system, called ControllerSEPA. Secondly, we study the feasibility of applying this framework to five open-source controllers, which include OpenDaylight, ONOS, Floodlight, Ryu and POX. A. ControllerSEPA: Design objectives In this section, we discuss what functions can be deployed via the REST-like system, which is a plug-in called ControllerSEPA (SEPA: Security-Enhancing Plug-in for OF App), in order to delegate and repack the services of the SDN controller. The high-level architecture of ControllerSEPA is depicted in Figure 1. 1) Controller-independent: The ControllerSEPA can set up the connection with the SDN controller and the controller delegates operation permission to ControllerSEPA. The OF app only communicates with the services provided by ControllerSEPA. Hence, it is controller-independent, i.e. it can reduce the deployment complexity for the application to current SDN controllers [10]. 2) Information disclosure: ControllerSEPA repacks all the services provided by SDN controller, including RESTful APIs (OpenDaylight, ONOS and Floodlight), OSGI bundles(opendaylight and ONOS) or Python API (POX) into new standard APIs and exposes them to the OF apps. As OF app can only communicate with ControllerSEPA instead of the SDN controller, OF app does not know the details concerning the SDN controller or which version is providing the services, i.e., the controller is protected from malicious scanning. 3) Authentication: ControllerSEPA can verify the digital signature through key pairs as [10] proposes. The App credential management in SE-Floodlight and Rosemary also use this way to authenticate OF app via northbound interface [7] [11]. 270

4 TABLE II. 8MEANS THIS API IS OFFICIALLY SUPPORTED IN THE SDN CONTROLLER, CONTROLLERSEPA CAN USE IT DIRECTLY AND REPACK WITHOUT TOUCHING THE CONTROLLER S SOURCE CODES; 'MEANS SDN COMMUNITY HAS RELEASED THE CONTRIBUTIONS FOR THIS API Category Permission Description ControllerSEPA API ODL ONOS FL Ryu POX Read host.read Read all or specific host(s) info /get/device/<all> or <hostid> ' Read switch.read Read all or specific switch(s) info /get/switch/<all> or <switchid> ' Read link.read Read all or specific link(s) info /get/link/<all> or <linkid> ' Read port.read Read all or specific ports(es) info /get/port/<all> or <portid> ' Read flowmod.read Read all or specific flow entry(ies) info /get/flowmod/<switchid>/<all>or<entryid> ' Read group.read Read all or specific group info /get/flowmod/<switchid>/<all>or<entryid> ' Read vlan.read Read vlan info in a flow entry /get/vlan/<switchid>/<all>or<entryid> Read statistics.read Read statistics /get/statistics 8 8 Read application.read Read other OF app info /get/app/<all>or<appid> 8 8 Read controller.read Read controller info (listen IP, port) /get/controllerinfo 8 ' Write port.write Update port status /post/port/<switchid>/<entryid> 8 Write flowmod.write Add a flow entry with any action /put/flowmod/<switchid> Write flowmod.write Update/remove a flow entry with any action /post or remove/flowmod/<switchid>/<entryid> Write vlan.write Add a vlan tag in a flow entry /put/vlan/<switchid>/<entryid> Write vlan.write Update/remove vlan tag in a flow entry /post or delete/vlan/<switchid>/<entryid> Write group.write Add a group entry /put/group/<switchid> 8 8 Write group.write Update/remove a group entry /post or delete/group/<switchid>/<groupid> 8 8 4) Authorization: Once the OF app is authenticated successfully, it should deliver its operation permissions on SDN controller to the ControllerSEPA. Every time the OF app requires services on the controller, ControllerSEPA will deliver an authentication token, which contains the information about the OF app such as id, permission, and priority, etc. ControllerSEPA will check its permission by this token. 5) Accounting: All operations of OF app will be kept on ControllerSEPA s data base, including the date, time, application ID, called API, and return code(successful, refused or sever error), in the form date, time, appid, api, and code. 6) Rule conflict resolution: : ControllerSEPA not only can keep the records about the OF apps operation history; moreover, it can keep the inserted flow rules from OF apps, and uses the flow rule verification system to check the rule conflicts with various detection algorithms, such as SRV or ASR, etc [6] [12]. This detection system can work with cluster computing API which connects with this database and analyzes the malicious flow rules. 7) Isolation: As ControllerSEPA adopts RESTful API to communicate with OF app, the OF app can be decoupled and run on any host remotely. This can secure a controller from an exhausting resources attack from malicious OF app and prevent the controller from crashing. As we repack the service into RESTful APIs, OF app can call these services via the network and run the services in a machine isolated from the controller. This is a more secure way than decoupling OF app from the controller by process or file system [11] [23]. 8) Fine-grained control: As ControllerSEPA repacks the services of the controller, it can control them in a more finegrained way. app has permission to access the database, it will have full permission to obtain any resources without limitation. But with this plug-in, the OF app will be constrained by the permission as to which resources they can get. ControllerSEPA can even limit their scope in the same resources. For example, if both of the OF apps have permission to insert a flow rule, one of them may have full permission to insert a rule for any network with any priority while the other is constrained by the fact that it only has permission to insert the rule for /24 to /24 with priority between 100 and 200. In doing so, we can control the OF app in a more refined way. 9) Encryption service: The plug-in is able to encrypt the communication between OF app and controller by using TLS, i.e., HTTPS for RESTful API, even if the SDN controller doesn t secure the northbound interface natively. 10)More rich services for OF apps: The efforts such as described in [1] [3] and [10] show that the ability to notify events proactively (such as flow mod or port status updated messages) is useful for OF app development. Unfortunately, few SDN controllers support this function. ControllerSEPA can create this service by incorporating with the frameworks such as SSE (Server Sent Events) or Websockets etc. B. ControllerSEPA: Details implementations In this section, We extend the permission set proposed in [10], as well as referred to the permissions in PermOF and OperationCheckpoint in [1] [3]. The permission set used in ControllerSEPA is as shown in Table II. For example, the APIs for reading packet in, packet out, feature reply, and flow mod events can be used in SPHINX to form the flow graph and detect the malicious flow in data plane [26]. The APIs used to read port status (/get/port/*) can be used in TopoGuard to detect the malicious host migration [27]. We provide a nonexclusive list of the possible APIs because the APIs are demand-driven, i.e., we should know the needs of OF app and then offer the necessary APIs; hence, we can only list the basic APIs. More features such as queue, meter, group, MPLS tags and priority-setting etc will be discussed in our future work. 1) OpenDaylight case: OpenDaylight uses Java API or RESTCONF to communicate with data storage. Hence, we benefit from RESTCONF protocol, which is implemented as an OF app in OpenDaylight (restconf module). OpenDaylight provides a rich RESTful API support and we repack these services into ControllerSEPA as standard RESTful API opening to OF app. For example, we repack the addresses in /openflow:n/node-connector/openflow:n:m 1 1 API root: opendaylight-inventory:nodes/node 271

5 TABLE III. SERVICES CALLING TIME COMPARISON (MILLISECOND) BETWEEN OPENDAYLIGHT AND THE REPACKED SERVICES IN CONTROLLERSEPA. API 1: GET DEVICES INFO; API 2: GET LINKS INFO; API 3: GET FLOW ENTRIES; API 4: INSERT A FLOW ENTRY; API 5: UPDATE AFLOWENTRY; API 6: REMOVE A FLOW ENTRY API 1 API 2 API 3 API 4 API 5 API 6 OpenDaylight ControllerSEPA Percent(%) Fig. 2. Repacking service provided by ControllerSEPA: (a) ControllerSEPA repacks the API /network-topology:network-topology provided by OpenDaylight RESTCONF module to /get/device/all; (b) Repacking the API /wm/device in Floodlight to /get/device/all. For example, both of them repack the information about host with IP and MAC 00:00:00:00:00:01 into the same form of response. to /get/device/* for obtaining the host s information such as MAC and IPs and /openflow: n/table/0/ to /get/flowmod/<switchid>/* to get the flow entries in switch n. OpenDaylight supports only role-based control, not app-based, that means, once a OF app has the permission to use restconf module in OpenDaylight, it will have the full permission to operate the data storage. Therefore, ControllerSEPA can be a security-enhancing module to provide app-based AAA control for OpenDaylight with low deployment complexity [13]. 2) ONOS case: Similar to OpenDaylight, ONOS also adopts Java API as well as implements RESTCONF protocol as an OF app ( org.onosproject.drivers), we repack the services in ONOS by merging, for example, /v1/devices and /v1/links into /get/switches/all in ControllerSEPA to get the complete information about switches and their connection status. The ONOS strict mode also uses role-based control like OpenDaylight. This means that it can also benefit from the app-based AAA control provided by ControllerSEPA [14]. 3) Floodlight case: Floodlight supports RESTful APIs natively, such as /wm/device/ for showing the details of the hosts connections, and /wm/staticflowpusher/list/<switch>/json for reading the proactive flow rules in switch. The shortage of authenticating the use of OF app can be supplemented in ControllerSEPA, which can provide the digital signature service to authenticate OF app without touching the source code in Floodlight. Evidently, it can also benefit from the app authorization and accounting services in ControllerSEPA [15]. 4) Ryu case: Ryu is a component-based SDN controller, which provides complete northbound interface for OF app development. However, Ryu (version 3.5) does not yet support the TLS for northbound interface, i.e., no HTTPS for securing the communication between OF app and SDN controller. Hence, ControllerSEPA can be used as the security-enhancing module to improve the problem of shortage of northbound interface encryption as well as provide app-based AAA control for Ryu [16]. 5) POX case: POX, an early SDN controller, does not use RESTful API, but Python API, as the official northbound interface. That means we should implement manually the RESTful API server in POX, such as Flask, for transferring data in POX via RESTful API. Fortunately, we can find contributions in community for the RESTful API support in POX such as pox-jsonrest on GitHub [28]. C. Discussion Obviously, the actual implementations of SDN controllers are different from each other; however, SDN controller works as a network operating system, which includes the basic components such as internal data storage, built-in functions, core network services, and programmable interfaces [5] [13] [15] [16] [28] [29] [30] [31]. We agree with the proposition of the Rosemary controller [11] that a secure SDN controller should run only the essential network service for keeping its reliability; other network services should be decoupled from SDN controller if possible. Hence, for securing the SDN controller from malicious OF app, the SDN community should clarify as soon as possible the core network services provided by SDN controller, such as OF messages processing, network topology providing, flow entry management as well as which network services can be provided by third party applications. V. PROTOTYPE AND EXPERIMENTAL VALIDATION In our implementation, we tested how ControllerSEPA secures OpenDaylight (version Beryllium-SR2), which runs on a Ubuntu-based(16.04) machine with CPU Intel i7, 8 cores, and 16G DDR2 RAMS. Controller connects with a linear topology with 20 OF switches and 20 hosts on each (total 400 hosts) simulated by mininet. Figure 2 shows that ControllerSEPA repacks the two APIs provided by different SDN controllers, OpenDaylight and Floodlight(1.2) respectively. After the repackage, both of them become /get/device/all and show the same responses to OF apps. By doing so, we hide the sensitive information about controller from OF apps. Similarly, we also successfully deployed one app can only insert flow entry with action output to a specific port while the other OF app can do more actions such as output to controller and flood the packet for testing the fine-grained control on OF app. In these implementations, we did not modify any source code of OpenDaylight and provided a more secure and fine-grained control on OF app. In Table III, we find the average latency of 20 times tests after ControllerSEPA repacks the services provided by OpenDaylight. We use Java spark framework as RESTful API server and JS as client to call the APIs. The repackage in ControllerSEPA produces negligible latency, from less than 0.1% to 0.3%. The same design principle can be applied in other SDN controllers as shown in Table II. For API 3 to get the flow entries, which contains the flow entries to allow ICMP packets between all hosts, it closes to ms after the seventh run from ms at the first run. 272

6 VI. CONCLUSION The main concern, which prevents SDN from being widely adopted, is security. Specifically, the SDN controller opens a programmable interface to the third party when accessed by the malicious OF app. We propose ControllerSEPA to protect the SDN controller in a flexible and efficient way. ControllerSEPA works well with OpenDaylight, ONOS, Floodlight, Ryu and POX with low deployment complexity. No modification of their source codes is required in their implementation while the overall security of the SDN controller is enhanced with negligible latency from less than 0.1% to 0.3% for repacking the services. Furthermore, ControllerSEPA can provide rich services such as AAA control on OF apps, information disclosure, rule conflict resolution, OF app isolation, and fine-grained control on OF apps. Our main purpose in this work is not only to present a new approach but also to define a clear separation between core network services provided by SDN controller and network services that can be provided by a third party OF app in facilitating the security of the SDN controller for OF apps. ACKNOWLEDGMENT This work was partially supported by the National Natural Science Foundation of China grant REFERENCES [1] S. Scott-Hayward, C. Kane, and S. Sezer, Operationcheckpoint: Sdn application control, in Proceedings of the 2014 IEEE 22Nd International Conference on Network Protocols, ser. ICNP 14, 2014, pp [2] J. Noh, S. Lee, J. Park, S. Shin, and B. B. Kang, Vulnerabilities of network os and mitigation with state-based permission system, Security and Communication Networks. [3] X. Wen, Y. Chen, C. Hu, C. Shi, and Y. Wang, Towards a secure controller platform for openflow applications, in Proceedings of the Second ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking, ser. HotSDN 13, 2013, pp [4] B. Chandrasekaran and T. Benson, Tolerating sdn application failures with legosdn, in Proceedings of the 13th ACM Workshop on Hot Topics in Networks, ser. HotNets-XIII, [5] S. Lee, C. Yoon, and S. Shin, The smaller, the shrewder: A simple malicious application can kill an entire sdn environment, in Proceedings of the 2016 ACM International Workshop on Security in Software Defined Networks; Network Function Virtualization, ser. SDN-NFV Security 16, [6] P. Porras, S. Shin, V. Yegneswaran, M. Fong, M. Tyson, and G. Gu, A security enforcement kernel for openflow networks, in Proceedings of the First Workshop on Hot Topics in Software Defined Networks, ser. HotSDN 12, 2012, pp [7] P. Porras, S. Cheung, M. Fong, K. Skinner, and V. Yegneswaran, Securing the Software-Defined Network Control Layer, in Proceedings of the 2015 Network and Distributed System Security Symposium (NDSS), February [8] S. K. Fayazbakhsh, L. Chiang, V. Sekar, M. Yu, and J. C. Mogul, Enforcing network-wide policies in the presence of dynamic middlebox actions using flowtags, in 11th USENIX Symposium on Networked Systems Design and Implementation (NSDI 14), Seattle, WA, Apr. 2014, pp [9] H. Hu, W. Han, G.-J. Ahn, and Z. Zhao, Flowguard: Building robust firewalls for software-defined networks, in Proceedings of the Third Workshop on Hot Topics in Software Defined Networking, ser. HotSDN 14, 2014, pp [10] C. Banse and S. Rangarajan, A secure northbound interface for sdn applications, in Trustcom/BigDataSE/ISPA, 2015 IEEE, vol. 1, Aug 2015, pp [11] S. Shin, Y. Song, T. Lee, S. Lee, J. Chung, P. Porras, V. Yegneswaran, J. Noh, and B. B. Kang, Rosemary: A robust, secure, and highperformance network operating system, in Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security, ser. CCS 14. New York, NY, USA: ACM, 2014, pp [Online]. Available: [12] Y. Tseng, Z. Zhang, and F. Naït-Abdesselam, Srv: Switch-based rules verification in software defined networking, in 2016 IEEE NetSoft Conference and Workshops (NetSoft), June 2016, pp [13] OpenDaylight: A Linux Foundation Collaborative Project, , online available. [14] ONOS, , online available. [15] Floodlight, , online available. [16] Ryu, , online available. [17] OpenMUL, , online available. [18] E. Al-Shaer and S. Al-Haj, Flowchecker: Configuration analysis and verification of federated openflow infrastructures, in Proceedings of the 3rd ACM Workshop on Assurable and Usable Security Configuration, ser. SafeConfig 10. New York, NY, USA: ACM, 2010, pp [Online]. Available: [19] A. Khurshid, X. Zou, W. Zhou, M. Caesar, and P. B. Godfrey, Veriflow: Verifying network-wide invariants in real time, in Proceedings of the 10th USENIX Conference on Networked Systems Design and Implementation, ser. nsdi 13. Berkeley, CA, USA: USENIX Association, 2013, pp [Online]. Available: http: //dl.acm.org/citation.cfm?id= [20] R. Beckett, X. K. Zou, S. Zhang, S. Malik, J. Rexford, and D. Walker, An assertion language for debugging sdn applications, in Proceedings of the Third Workshop on Hot Topics in Software Defined Networking, ser. HotSDN 14. New York, NY, USA: ACM, 2014, pp [Online]. Available: [21] P. Kazemian, M. Chang, H. Zeng, G. Varghese, N. McKeown, and S. Whyte, Real time network policy checking using header space analysis, in Presented as part of the 10th USENIX Symposium on Networked Systems Design and Implementation (NSDI 13). Lombard, IL: USENIX, 2013, pp [Online]. Available: usenix.org/conference/nsdi13/technical-sessions/presentation/kazemian [22] S. Son, S. Shin, V. Yegneswaran, P. A. Porras, and G. Gu, Model checking invariant security properties in openflow. in ICC. IEEE, 2013, pp [Online]. Available: http: //dblp.uni-trier.de/db/conf/icc/icc2013.html#sonsypg13 [23] M. Monaco, O. Michel, and E. Keller, Applying operating system principles to sdn controller design, in Proceedings of the Twelfth ACM Workshop on Hot Topics in Networks, ser. HotNets-XII. New York, NY, USA: ACM, 2013, pp. 2:1 2:7. [Online]. Available: [24] D. E. A. Takayuki Sasaki and A. Perrig, Control-plane isolation and recovery for a secure sdn architecture, [25] A. Wundsam, D. Levin, S. Seetharaman, and A. Feldmann, Ofrewind: Enabling record and replay troubleshooting for networks, in Proceedings of the 2011 USENIX Conference on USENIX Annual Technical Conference, ser. USENIXATC 11, [26] M. Dhawan, R. Poddar, K. Mahajan, and V. Mann, Sphinx: Detecting security attacks in software-defined networks. in NDSS. The Internet Society, [Online]. Available: ndss2015.html#dhawanpmm15 [27] S. Hong, L. Xu, H. Wang, and G. Gu, Poisoning network visibility in software-defined networks: New attacks and countermeasures, in Proceedings of 2015 Annual Network and Distributed System Security Symposium (NDSS 15), February [28] POX, , online available. [29] NOX, , online available. [30] Opencontrail, , online available. [31] P. Berde, M. Gerola, J. Hart, Y. Higuchi, M. Kobayashi, T. Koide, B. Lantz, B. O Connor, P. Radoslavov, W. Snow, and G. Parulkar, Onos: Towards an open, distributed sdn os, in Proceedings of the Third Workshop on Hot Topics in Software Defined Networking, ser. HotSDN 14,