Software Defined Networks (SDN) & its Security

Software Defined Networks (SDN) & its Security Hussan Mehmood Butt Department of Computer Sciences, COMSATS institute of Information Technology Islamabad, Pakistan [email protected]

Abstract: For the advancement in networking industry researchers introduces the concept of Software Defined networking to bring revolution in IT industry. The architecture of Software Defined networks is highly adaptable, programmable, cost-effective & manageable which makes it suitable for current apps demanding high bandwidth. The approach used in SDN fashions the control independent of hardware to software defined applications named controller in SDN. The environment of SDN provide more flexibility to network operators to Design their networks or to shape the traffic flowing in the network without physically accessing to hardware by an integrated (centralized) control console. SDN follows open standard protocol, “Open Flow” providing the benefit of remote access to routing tables. Meanwhile when organizations are looking forward to adopt SDN an emerging paradigm the first question that arises is security i.e. how secure this environment is? This paper provides a comprehensive survey on SDN, its difference from traditional networking and its history, will also reveal SDN architecture along with some other information related to SDN including network applications, network programming languages, network OS, scalability and security challenges in SDN.

Keywords: SDN, Open Flow, Network Operating System, Scalability. I.

INTRODUCTION

Dr. Munam Ali Shah Department of Computer Science COMSATS institute of Information Technology Islamabad, Pakistan [email protected]

The installation and configuration of modern network required highly skillful network operator which is difficult to achieve in current devices having programming interfaces. In current era vendors using multiple networking technologies is increasing which brings insufficiency of trained human resource, Software defined networking an evolving paradigm in the field of networking which will overcome these problems. The distribution of data which is being sent in the form of digital packets uses network protocols which are configured inside the routers and switches that allow communication on the end devices, even though the implementation of traditional IP networks is worldwide but still it is difficult to manage because of their complexity issues. In order to implement desired network policies, each device would require to be individually configured by network operators in the network. Since in current IP networks the existence of automatic reconfiguration and the changes in the mechanism to provide network redundancy issue is virtually not present which may causes the dismissal of services provided by the network. Implementing innovative strategies in current system to enhance its performance will be challenging.[1] The architecture of current network is vertically integrated into control plane which handles the traffic and the data plane which in response to control plane handles the traffic forwarding are designed inside networking devices

which hurdles in the advancement of networking infrastructure by increasing complexities and reducing flexibility[2]. It has been more than a decade in advancement of ipv4 into ipv6 but still it is incomplete and there has been scarcely any update in its protocol. Inertia in current IP networks can cause the designing, evaluation, implementation and deployment of new routing protocol in five to ten years. However the appalling job here is to introduce new approach in architecture of networking which might not be practicable.[3] Software defined networking SDN provides optimization in the networking infrastructure by parting the vertical integration i.e. by separation of control logic which is “control plane” from switches and routers in “data plane” that accelerates the data traffic, with the splitting of control and data planes the switches just perform the task of forwarding in data plane while the control plane is controlled by logically centralized controller, which simplifies the task of implementation of network reconfiguration[4][5] as shown below.

Fig 1. “Simple SDN architecture in figure b is compared with traditional networking in figure a”.

The switches and SDN controllers are defined through application programming interface most often used API is OpenFlow, which separates the

data plane and control plane, OpenFlow provides the benefit of one or more flow table which performs certain action on data traffic like forwarding packets, dropping packets etc. and these handling rules are installed through network controllers application. In OpenFlow switch can perform different roles and tasks like traffic shaping, firewall, router etc. The concept of separation in SDN brings the required ideal flexibility and breaks the problems in network into identifiable fragments which causes ease in introducing new amendments in network management policies.[6] Recently vendors have been introducing the implementation of Open flow API in their switches because organization like Microsoft, Facebook, Verizon, ONF, Google & yahoo were enthused to adopt and promote it [7]. For the past three years Google has deployed SDN architecture to connect its data centers around the world which in response provides operational proficiency and significant cost reduction [8], another example is VMware and NSX which are fully deployed with SDN architecture which signify the status of SDN. This paper will provide comprehensive survey on SDN organized in the manner that at first main concept of SDN will be discussed and how it varies from traditional networking i.e. the STATUS QUO in networking which is present era of networking then detail study on SDN with its history, architecture and infrastructure including SDN controllers, north and south bound interfaces, Programming languages and Network applications than in the last implementation challenges in SDN which is comprise of switch designs, scalability and security.

II.

STATUS QUO NETWORKING The functionality of computer networks are divided into three planes, the management plane, control plane & the data plane each performing their role, the data plane forward data packet to and from end devices, the control plane then originates the forwarding tables for these packets & the network plane determine the network policy which is imposed in control plane and executed in data plane consequently. In early days the necessary goal of networking was to ensure the network flexibility which was then achieved by tightly coupled architecture of traditional IP networks i.e. the control and data plane are integrated in same networking device providing a decentralized structure resulting in complex and static architecture which is the central cause of complicated management and control of traditional networking[9]. In current networking protocols/schemes misconfiguration and related errors occur so frequently, in BGP routers 1000 misconfiguration errors were observed, a single misconfiguration could lead or cause the freeze in network communications for hours[10] [11]. From time to time vendors have been providing different recovery solutions and corresponding human resources to network operators for management operation causing increase in the cost of building and maintaining network infrastructure, even though these proprietary solutions (intrusion detection, firewall & packet inspection) installed in special components and middleboxes in current networks are providing service in in-path functionalities but generating complications in network policy/design and its operations, a survey was performed recently on 57 enterprises networks indicating the integration of these solutions with routers in existing networks. Figure 1 clearly mention the differences between traditional way of networking and

SDN[11]. In traditional networking control and data planes are combined as illustrated by “fig 2a” whereas in “fig 2b” vertical integration is apart. In traditional networking once the routing tables are populated than any amendment is obtained via reconfiguration of networking devices which is challenging but in SDN the control is shifted to SDN controllers which can exploit and alter the complete knowledge of network for optimization and to provide flexibility and scalability[1]. III. DETAIL STUDY ON SDN SDN architecture can be defined having following four pillars.  By removing vertical integration i.e. separation of data and control plane from network devices which simply perform the task of forwarding packets.  Instead of acting as destination base forwarding decision are based on flow characteristic of SDN, where flow is an arrangement of packets receiving identical service polices from management plane between source and destination in the context of SDN/OpenFlow architecture[12].  The control is shifted to SDN controller or NOS which is software platform providing services to forwarding devices and these services are familiar to traditional operating systems.  The important feature of SDN is to provide programmable network through software applications running on top of SDN controllers by interacting with underlying data plane devices[13]. The tight coupling of data & control plane is the main cause of preventing the further progress in traditional networking as mentioned before i.e. it’s difficult to include new features in current networks, to achieve this goal some modification of control plane on network devices might be required by upgrading software & hardware like SDN but in current networking the goal of adding new features is achieved by adding

components (firewalls, IDSs, load balancer etc.) Which are expensive, difficult in configuration and installation and result in adding more complexities in network functionalities whereas SDN decouples the vertical integration of traditional networking making control plane an entirely separate module from network devices like SDN controllers or NOS providing following benefits.  





Programing application is easy. Since the network programing language can be shared provided by control platform, same information can be shared amongst application leading to more consistent and effective network policies. No need to create new policy/scheme about the arrangement of new module since from any location of network application can take actions like reconfigure a device. The Assimilation of applications is easier than in traditional networks[14].

1) History of SDN The adventure of SDN is classified in the following table Table 1. Summarized overview history of Programmable network Classification

Pre-SDN initiative

Data plane and programmability

ANTS, High performance routers, calvert, switchware

Control and data plane decoupling

Tempest, ForCES, RCP, PCE

Network Operating Systems Technology pull initiative

Cisco IOS, JUNOS, ExtremeXOS Open signaling

Recent advent in SDN ForCES , OpenFlow, POF OpenFlow, NOX,P OF NOX, Onix, ONOS ONF

Early effort of designing new network architecture was based on data plane programmability, the main concept of this idea was that each network node works independently and can compute computations ,alter the contents of packets if needed and was named Active network. ForCES[15], OpenFlow[16] and POF[17] are recent techniques/practices to provide programmable data plane devices which can be dynamically configured and can modify flow tables by performing some operations. The concept of separating control and data plane signaling was first introduced in between 1980s-1990s by AT&T for the improvement in their telephonic communications, this concept was adopted widespread for its advantage of providing network efficiency early initiatives were Tempest, ForCES[15] and RCP[18] later OpenFlow, NOX[12] and POF introduce the decoupling of control and data plane for Ethernet Networks and these recent initiatives can be easily implemented in traditional networking without performing any major modifications in the network. In early 90’s the concept of network operating systems NOSs were emerged and at that time the mostly used and deployed NOSs was Cisco IOS later its importance was decreased but with the introduction of OpenFlow based NOSs this concept was reborn. NOX, Onix[19], ONOS[20] are recently developed NOSs. NOSs hide the peculiarities of underlying hardware infrastructure to network operators to provide ease in maintaining the network, finally one of the main invention that leads to motivation for SDN began in 1990s was open signaling, the idea behind open signaling was to separate control and data signaling by programmable interfaces, OpenFlow with its increasing importance lead to movement “Open Networking Foundation ONF”[7] that plays vital role in promoting technologies/policies and open standards hence encouraging in

competition, interoperability revolutions in networking industry.

and

2). Architecture and Infrastructure A) Infrastructure (Data plane – Forwarding device) The main difference between SDN and traditional networking lies in separation of control and data plane, in traditional networking devices were installed with programs to take independent decisions while with the moving of control from data plan into centralized control system in SDN these devices act as simple forwarding machines with no embedded softwares to take independent decisions. The approach used in the design of these networks works on open standard interface like OpenFlow to provide interoperability and configuration compatibility among data and control device resulting in dynamic programing of unfamiliar forwarding devices and was challenging to achieve this in traditional networking[6].

network. OpenFlow supported forwarding device are based on the concept which is pipeline of flow table consisting three parts for each entry of flow table.  Matching rules for packet.  On matching packets particular actions are performed.  Counter to keep information of similar packets. This concept is one of the mostly used in existing SDN data plane devices. Other models which are also being followed are NDMs negotiable datapath model and POF. Packet handling in OpenFlow devices is followed by the arrangement of flow tables, on the arrival of new packet, flow tables are explored in a sequence that could either terminate with a match or incase when no rule is found for the packet it misses i.e. if no default rule is present then packet is simply discarded to avoid this default rules can be installed in switches to forward those packets to controllers. Actions on packet are enlisted below and illustrated in fig 4.  Forward packets to ports.  Forward packet to controller after encapsulation.  Discard packet.  Forward packet to normal processing pipeline. In recent and updated OpenFlow Protocol packets are send to next flow tables or special tables.

Figure 3. “3a” defines plane view, “3b” define layer approach & “3c” shows system architecture[6].

The two important components of SDN are Forwarding devices & Controllers, fig 3 illustrates that data plane device are dedicated in forwarding packets whereas the controllers act as the operating system for a specific hardware in a specific

Fig 4. “OpenFlow enabled device”[6]

New fields are introduced with each version & update of OpenFlow protocol nevertheless there are some essential matching fields that are necessary to be considered[6]. OpenFlow devices: There are frequent devices available as commercial and open source in the market that support OpenFlow, among the other instruments/tool switches and router are more frequent and available in the market to be deployed. Switches that are currently available vary in their ternary contentaddressable memory (TCAM) sizes starting with 8000 entries in switch and for business purposes the addressable memory range starts from 32000 to 64000 entries both in layer2 and layer3 known as Gigabit Ethernet (GbE). 10GBe switches are being used for enterprise class which provide 80000 entries on layer2. Optimized TCAM are used for devices that require high performance support flow entries ranging from 125000 to 1000000 [21] [22]. B) Southbound Interfaces The linkage between control and forwarding devices is due to Southbound APIs and is the main reason for the separation of control and data plane functionality thus being the important component of SDN and is the possible obstacle for the launch of new network technology which consequently lead to OpenFlow. OpenFlow is one of the most acknowledged and deployed Southbound API, as it delivers common specification for the communication between data and control plane and to implement OpenFlow enabled devices, it also delivers three information channels to provide necessary flow level information for NOSs, at first if any port or link change is prompted an event based message is sent from forwarding devices to controller, second, forwarding devices generates flow statistics collected by controllers to update flow tables, in the last when the forwarding devices are unaware of

the actions on packets that are not matched with any rule in flow tables are sent to controllers [23]. There are other southbound interfaces available for SDN such as Open vSwitch Database (OVSDB) OpFlex, POF, OpenState, Revised OpenFlow library (ROFL), Programmable abstraction of data path (PAD) and ForCES. ForCES proposes a more flexible approach to i.e. without changing the current architecture of traditional networking software defined environment SDE can be achieved without the need of centralized external controller, control and data planes are kept in same network element after being separated. However a third party firmware can be installed to update the control part of network element [24]. OVSDB is complementary protocol to OpenFlow for Open vSwitch and is designed to deliver innovative managing abilities for Open vSwitches. Services provided by OVSDB are creation of multiple virtual switch instances, configuration of tunnel interfaces on OpenFlow data paths, QoS policies can be set on interface, collection of statistics and manage queues [25]. POF is one of the early Contender of OpenFlow, its core idea is to optimize the forwarding plane of SDN. In OpenFlow switches have to extract the headers information to be matched with flow tables and this parsing leads to be a burden over data plane devices & backward compatibility may arise each time when a new header field is included or excluded from protocol. To avoid this POF introduces flow instruction set (FIS) to make forwarding plane protocol oblivious because forwarding device doesn’t need to know packet information in advance. Packet parsing is completely under the control of SDN controller [26] [27]. C) Network Operating Systems Traditional operating systems provide abstractions (e.g., high-level programming

APIs) for accessing lower level devices, manage the concurrent access to the underlying resources (e.g., hard drive, network adapter, CPU, memory), and provide security protection mechanisms. These functionalities and resources are key enablers for increased productivity, making the life of system and application developers easier. Their widespread use has significantly contributed to the evolution of various ecosystems (e.g., programming languages) and the development of a myriad of applications. In contrast, networks have so far been managed and configured using lower level, device-specific instruction sets and mostly closed proprietary NOSs (e.g., Cisco IOS and Juniper JunOS). Moreover, the idea of operating systems abstracting devicespecific characteristics and providing, in a transparent way, common functionalities is still mostly absent in networks. For instance, today designers of routing protocols need to deal with complicated distributed algorithms when solving networking problems. Network practitioners have therefore been solving the same problems over and over again. SDN is promised to facilitate network management and ease the burden of solving networking problems by means of the logically centralized control offered by a NOS [28]. As with traditional operating systems, the crucial value of a NOS is to provide abstractions, essential services, and common APIs to developers. Generic functionality as network state and network topology information, device discovery, and distribution of network configuration can be provided as services of the NOS. With NOSs, to define network policies a developer no longer needs to care about the low-level details of data distribution among routing elements, for instance. Such systems can arguably create a new environment capable of fostering innovation at a faster pace by reducing the inherent complexity of creating new

network protocols and network applications. A NOS (or a controller) is a critical element in an SDN architecture as it is the key supporting piece for the control logic (applications) to generate the network configuration based on the policies defined by the network operator. Similar to a traditional operating system, the control platform abstracts the lower level details of connecting and interacting with forwarding devices. D) Programming languages Programming languages have been proliferating for decades. Both academia and industry have evolved from low-level hardware-specific machine languages, such as assembly for x86 architectures, to highlevel and powerful programming languages such as Java and Python. The advancements toward more portable and reusable code have driven a significant shift on the computer industry. High-level programming languages can be powerful tools as a mean for implementing and providing abstractions for different important properties and functions of SDN such as network-wide structures, distributed updates, modular composition, virtualization, and formal verification [29].Low-level instruction sets suffer from several problems. To address some of these challenges, higher level programming languages have been proposed, with diverse goals, such as:  Avoiding low-level and device-specific configurations and dependencies spread across the network, as happens in traditional network configuration approaches.  Providing abstractions that allow different management tasks to be accomplished through easy to understand and maintain network policies.  Decoupling of multiple tasks (e.g., routing, access control, traffic engineering).

 

    

Implementing higher level programming interfaces to avoid lowlevel instruction sets. Solving forwarding rules problems, e.g., conflicting or incomplete rules that can prevent a switch event to be triggered, in an automated way. Addressing different race condition issues which are inherent to distributed systems. Enhancing conflict-resolution techniques on environments with distributed decision makers. Providing native fault-tolerance capabilities on data plane path setup. Reducing the latency in the processing of new flows. Easing the creation of state-ful applications (e.g., state-ful firewall). IV.

Implementation Challenges in SDN 1) Switch Design In order to achieve a fully SDN supported switch following are the five main ingredients to be found in any switch on SDN platform. A) Flow table capacity [30] B) Evolving switch design and hardware enhancement [31] C) Performance [32] D) Native SDN switch design [33] E) Heterogeneous implementations [34] 2) Scalability Scalability in SDN is one of the most discusses problem having limited solutions, this issue is split into controller scalability and network node scalability and the main focus is on controller scalability in which three particular challenges are discussed, the first is latency when there is exchange of information between multiple nodes and single controller, the second is how using eastbound and westbound APIs SDN controller communicate with other

controller and the last challenge is the size and operation of controller backed data base.[35] To minimize the first issue a distributed or peer to peer controller infrastructure can be deployed to share the communication and other load of the controller. To eliminate second challenge, an overall network view is required, since the traditional packets lend themselves to scalable solutions because they do not need general state to be held between system units. Routing protocols are designed considering Network node requires only limited knowledge of its neighbor node and is kept autonomous to control the traffic. In order to create an effective and resistant networks, network redundancy is required like alternative paths and secondary equipment to backup in case of any failure to provide uninterrupted services. In traditional networking this goal was achieved by using or installing some external firmware or software but SDN environment can provide this service to wider number of forwarding nodes thus allowing a system wide view of network [6]. A specific solution to network scalability is HyperFlow a system application which resides in NOX controller and works with an event propagation system. HyperFlow explicitly publishes the event that changes the state of system while other controllers repeat all the published events to recreate the state to provide the shared consistent network wide view. The last but not the least is network programmability to achieve full scalability. For example no of queries can be resolved in CPU node in hybrid architecture to reduce database size and simultaneously reduce communication between the controller and its nodes. As a result several efforts have been made to meet scalability challenges, some of these efforts are related to Onix, HyperFlow, Maestro, DIFANE, SDCs,

NOX-MT addresses and focus on designing and deploying high performance controllers to increase the performance of control plane. Table 2 provide list of solutions concerning to scalability, the given table is characterized by their application domain (control or data plain), their main purpose [6]. Table 2. Characterization of scalability proposals for SDNs

Google, Microsoft and Yahoo! are conducting some research and experiment on SDNs and experts believe that security issues are still needed to be addressed. There are different threat vectors that have already be identified in SDN and some along with several issues and weaknesses in OpenFlow based SDNs. Some of these threat vectors are common to existing networks while others are related to SDN like attacks on logically centralized

Solutio n DevFlo w DIFAN E Maestr o NOXMT Onix

Domain

Main purpose

Resorts to

Data plane

Reduce the control traffic

SDCs

Data plane

Reduce the control plane overhead Improve data plane performance Create clusters of controllers Improve controller performance Robust and scalable platform Reduce the control plane overhead

Control and Data plane Control plane Control plane Control plane

It can be observed in table that the maximum no of solutions are based on control plane which helps in increasing scalability by using distributed and multicore architectures. 3) Security There has been limited discussion and research on issues related to security in SDNs because of the cyber-attacks against government unit, financial institutions, energy facilities and research institutions. These attacks are capable of damaging nationwide infrastructure and the common means of launching these attacks is either from internet or LAN, high capacity networks can be used to launch large scale of attacks even it attacker is using low latency network [36]. Due to current nature of threats and attacks, security has become the top priority in SDN while some commercial organization like

Maintain flow in the data plane Coordination frame work to create high performance cluster of controller High performance flow processing capabilities Provide a programmable & flexible distributed NIB for app programmers Improve programmability by removing counters. controllers and control plane communications. SDN architecture have at least seven identified threats vector. The first one is composed of Fake and forged traffic flows in data plane use to attack controllers or forwarding devices. Second allows an attacker to exploits vulnerabilities of forwarding devices and consequently weak havoc with the network. Vectors three four and five are the dangerous one because the can compromise the network operation, by attacking control plane, controllers and applications can easily allow an attacker the control of network if the attack is successful. Sixth threat vector is related to attacks and vulnerabilities in administrative section. Last vector represent the lack of trusted resources for forensics and remediations which can resist in backing up the network in safe and operational state [37][38].

Table 3. SDN specific VS Nonspecific Threats [6] Threat Specific Consequences in vectors to SDN? SDNs Open door for Vector No DDoS attack 1 Potential attack Vector No inflation 2 Exploiting Vector Yes logically 3 centralized controllers Compromised Vector Yes controller may 4 compromise the entire network Development and Vector Yes deployment of 5 malicious applications on controllers Potential attack Vector No inflation 6 Negative impact Vector No on fast recovery 7 and fault diagnosis Table 3 shows that the decoupling of control and data plane will originate threat vectors 3 to 5 while the other vectors are already been mentioned in traditional networks. Across SDN platform there are several potential security vulnerabilities that exist, questions have been arising at controller application level to provide authorization and authentication mechanisms to access network resources along with protection a security model must be place to isolate applications and support protection of network. To attack in SDN architecture open to unauthorized access, the attractive target for attack are controllers. It is possible for an attacker to carry out malicious activities and

masquerade as a controller in the absence of secure and robust controller platform. FortNox is a role bases authorization solution and is proposed to provide solution when two different application send flow rules to controller. In order to minimize attacks on controller, transport layer security TLS with mutual authentication between controller and their switches is useful. OpenFlow uses TLS which is optional since the rules for TLS in OpenFlow are not standardized so to protect the data transmitted across OpenFlow security specification must be defined to secure controller-switch interface. Single controller having control of multiple network node con implement authentication easily using TLS but when multiple controllers having control of multiple or single network node will provide complexity in the implementation of authorization hence the probability for unauthorized access is increased []. The door is thrown open to attackers with the introduction of open interfaces in SDN and known protocols to simplify network programing by any application provider, the attacker can easily and quickly subvert the network operations according to his requirements with the full knowledge and access of how to control the controller. Even at lower level user or host node can be attacked or manipulated to get desired network performance. These issues must be enlighten and minimized in order to deploy SDN globally. Along with its loophole SDN also comes up with some plus points like highly reactive security monitoring, analysis and response system. A. Network Forensics Reprograming to optimize from network experience, updating policy and adaptive threat identification and management through a cycle of harvesting intelligence from the network.

B. Security policy alteration Security policy can be defined and forwarded to all element in the network helping in reducing the frequency of misconfiguration and conflicting polices across the infrastructure. C. Security service insertion Applications like firewalls and intrusion detection system can be applied to specified traffic. Conclusion The vertical integration of control and data plane in traditional networks makes it complex and difficult to control, each device has its own particular configuration and managing interfaces resulting in transforming a barrier for new innovations or any upgrade whereas SDN provides a platform to overcome these barriers. Some of the main concepts of SDNs is the decoupling of control and data plane, the introduction of dynamic programmability in forwarding devices using Southbound APIs and the global view of the network logical centralization of network brain the controller, in regard to logical centralization the data plane become dumb but highly effective and programmable packet forwarding devices, new policies are straightforward to be enforced and deployed in the development and evolution of the network. This survey presents a pervasive and comprehensive overview of the main concepts, building block and ongoing research and challenges to SDN using a layered approach to differentiate between different concepts and components of SDN. This paper provides a inclusive survey on SDN organized in the manner that at first main concept of SDN are discussed, how SDN varies from traditional networking then detail study on SDN with its history, architecture and infrastructure including SDN controllers, north and south bound interfaces, Programming languages and

Network applications than in the last implementation challenges in SDN which is comprise of switch designs, scalability and security. SDN successfully managed to initiate the way towards the evolution of networking paradigm by producing innovative development and research environment, and advancement in several areas like switch and controller platform design, scalability, performance and promoting security leading toward next generation networking REFERENCES: [1]

S. Sezer, S. Scott-Hayward, P. Chouhan, B. Fraser, D. Lake, J. Finnegan, N. Viljoen, M. Miller, and N. Rao, “Are we ready for SDN? Implementation challenges for software-defined networks,” IEEE Commun. Mag., vol. 51, no. 7, pp. 36–43, 2013.

[2]

B. Raghavan, M. Casado, T. Koponen, S. Ratnasamy, A. Ghodsi, and S. Shenker, “Software-defined internet architecture,” Proc. 11th ACM Work. Hot Top. Networks HotNets-XI, pp. 43–48, 2012.

[3]

A. Ghodsi, T. Koponen, B. Raghavan, S. Shenker, A. Singla, and J. Wilcox, “Intelligent Design Enables Architectural Evolution,” Proc. 10th ACM Work. Hot Top. Networks - HotNets-X, 2011.

[4]

S. Scott-Hayward, G. O’Callaghan, and S. Sezer, “SDN security: A survey,” SDN4FNS 2013 - 2013 Work. Softw. Defin. Networks Futur. Networks Serv., 2013.

[5]

H. Kim and N. Feamster, “Improving network management with software defined networking,” IEEE Commun. Mag., vol. 51, no. 2, pp. 114–119, 2013.

[6]

D. Kreutz, C. E. Rothenberg, M. Ieee, S. Azodolmolky, S. M. Ieee, S. Uhlig, and M. Ieee, “Software-Defined Networking : A Comprehensive Survey,” vol. 103, no. 1, 2015.

[7]

“Open Networking Foundation (ONF),” 2014. [Online]. Available: https://www.opennetworking.org/.

[8]

S. Jain, A. Kumar, S. Mandal, J. Ong, L. Poutievski, A. Singh, S. Venkata, J. Wanderer, J. Zhou, M. Zhu, J. Zolla, U. Hölzle, S. Stuart, and A. Vahdat, “B4 : Experience with a Globally-Deployed Software Defined WAN,” pp. 3–14.

[9]

[10]

J. Pan, S. Paul, and R. Jain, “A survey of the research on future internet architectures,” Commun. Mag. IEEE, vol. 49, no. 7, pp. 26–36, 2011. N. Feamster, N. Feamster, H. Balakrishnan, and H. Balakrishnan, “Detecting BGP configuration faults with static analysis,” Proc. Networked Syst. Des. Implement., pp. 49–56, 2005.

[11]

K. Butler, T. R. Farley, P. McDaniel, and J. Rexford, “A survey of BGP security issues and solutions,” Proc. IEEE, vol. 98, no. 1, pp. 100–122, 2010.

[12]

N. Gude, T. Koponen, J. Pettit, B. Pfaff, M. Casado, N. McKeown, and S. Shenker, “NOX: towards an operating system for networks,” SIGCOMM Comput. Commun. Rev., vol. 38, no. 3, pp. 105–110, 2008.

[13]

H. Jamjoom, D. Williams, and U. Sharma, “Don’t call them middleboxes, call them middlepipes,” Proc. third Work. Hot Top. Softw. Defin. Netw. - HotSDN ’14, pp. 19– 24, 2014.

[14]

B. Y. M. Casado, N. Foster, and A. Guha, “Abstractions for Software- Defined Networks,” Cacm.

[15]

A. D. et Al, “No Title,” 2010. [Online]. Available: http://www.hjp.at/doc/rfc/rfc5810.html.

[16]

N. Mckeown, T. Anderson, H. Balakrishnan, G. M. Parulkar, L. L. Peterson, J. Rexford, S. Shenker, J. S. Turner, and S. Louis, “OpenFlow: enabling innovation in campus networks,” Comput. Commun. Rev., vol. 38, no. 2, pp. 69–74, 2008.

[17]

H. Song and S. Clara, “Protocol-oblivious forwarding: unleash the power of SDN through a future-proof forwarding plane,” HotSDN ’13, pp. 127–132, 2013.

[18]

M. Caesar, D. Caldwell, N. Feamster, J. Rexford, A. Shaikh, and J. van der Merwe, “Design and implementation of a routing control platform,” 2nd Conf. Symp. Networked Syst. Des. Implement., pp. 15– 28, 2005.

[19]

T. Koponen, M. Casado, N. Gude, J. Stribling, L. Poutievski, M. Zhu, R. Ramanathan, Y. Iwata, H. Inoue, T. Hama, Others, and S. Shenker, “Onix: A distributed control platform for large-scale production networks,” OSDI, Oct, pp. 1–6, 2010.

[20]

P. Berde, M. Gerola, J. Hart, Y. Higuchi, M. Kobayashi, T. Koide, B. Lantz, W. Snow, G. Parulkar, B. O’Connor, and P. Radoslavov, “Onos,” Proc. third Work. Hot Top. Softw. Defin. Netw. - HotSDN ’14, pp. 1–6, 2014. U. Pf, “NEC Univerge PF5820 At a Glance.”

[22]

O. S. Software and S. D. Networking, “NoviSwitch TM 1248 High Performance OpenFlow Switch,” pp. 2013–2014, 2013.

[23]

T. Kato et al., ‘‘Case study of applying SPLE to development of network switch products,’’ in Proc. 17th Int. Softw. Product Line Conf., 2013, pp. 198–207.

[24]

A. Doria et al., ‘‘Forwarding and control element separation (ForCES) protocol specification,’’ Internet Engineering Task Force, Mar. 2010. [Online]. Available: http://www.ietf.org/rfc/rfc5810.txt

[25]

B. Pfaff and B. Davie, ‘‘The Open vSwitch database management protocol,’’ Internet Engineering Task Force, RFC 7047 (Informational), Dec. 2013. [Online]. Available: http://www.ietf.org/rfc/rfc7047.txt.

[26]

H. Song, ‘‘Protocol-oblivious forwarding: Unleash the power of SDN through a futureproof forwarding plane,’’ in Proc. 2nd ACM SIGCOMM Workshop Hot Topics Softw. Defined Netw., 2013, pp. 127–132.

[27]

H. Song, J. Gong, J. Song, and J. Yu, ‘‘Protocol oblivious forwarding (POF),’’ 2013. [Online]. Available: http://www.poforwarding.org/

[28]

N. Gude et al., ‘‘NOX: Towards an operating system for networks,’’ Comput. Commun.Rev., vol. 38, no. 3, pp. 105–110, 2008.

[29]

M. Casado, N. Foster, and A. Guha, ‘‘Abstractions for software-defined networks,’’ CM Commun., vol. 57, no. 10, pp. 86–95, Sep. 2014.

[30]

M. Appelman and M. D. Boer, ‘‘Performance analysis of open-flow hardware,’’ Univ. Amsterdam, Amsterdam, The Netherlands, Tech. Rep., Feb. 2012.

[31]

G. Memon et al., ‘‘FlashFlow: A GPU-based fully programmable OpenFlow switch,’’Univ. Oregon, Eugene, OR, USA, Tech. Rep.,2013.

[32]

M. Kobayashi et al., ‘‘Maturing of OpenFlow and software-defined networking through deployments,’’ Comput. Netw., vol. 61, Special Issue on Future Internet TestbedsVPart I, pp. 151–175, 2014.

[33]

P. Bosshart et al., ‘‘Forwarding metamorphosis: Fast programmable matchaction processing in hardware for SDN,’’ in Proc. ACM SIGCOMM Conf., 2013, pp. 99–110.

[34]

C. Rotsos, N. Sarrar, S. Uhlig, R. Sherwood, and A. W. Moore, ‘‘OFLOPS: An open framework for OpenFlow switch evaluation,’’ in Proc. 13th Int. Conf. Passive Active Meas.,2012, pp. 85–95

[35]

S. Sezer, S. Scott-Hayward, P. Chouhan, B. Fraser, D. Lake, J. Finnegan, N. Viljoen, M. Miller, and N. Rao, “Are we ready for SDN? Implementation challenges for softwaredefined networks,” IEEE Commun. Mag., vol. 51, no. 7, pp. 36–43, 2013.

[36]

C. Tankard, ‘‘Advanced persistent threats and how to monitor and deter them,’’ Netw.Security, vol. 2011, no. 8, pp. 16–19, 2011

[37]

D. Kreutz, F. M. Ramos, and P. Verissimo, ‘‘Towards secure and dependable softwaredefined networks,’’ in Proc. 2nd ACM SIGCOMM Workshop Hot Topics Softw. Defined Netw., 2013, pp. 55–60.

[38]

S. Shin et al., ‘‘Rosemary: A robust, secure, high-performance network operating system,’’ in Proc. 21st ACM Conf. Comput. Commun. Security, Scottsdale, AZ, USA, Nov. 2014, pp. 78–89.