Unified Security Plugin for Opendaylight Controller

ABSTRACTFor the last two years, there is a definite buzz around SDN which is complemented by NFV. The strong focus on SDN is vindicated by the fact that by 2016, there is a prediction that more than 10,000 enterprises will deploy SDN in their networks, which is almost a ten-fold increase from the data in 2014 [1]. Also, according to a survey done by Juniper in 2014, out of 400 U.S. Businesses, around 52.5 percent of the companies plan to adopt SDN in the future. 27 percent out of these companies have stated that they are ready or almost ready to adopt SDN [2].

SDN architecture is proposed to be widely deployed for branch networks. Opendaylight (ODL) as an open source SDN controller has gained prominence from contributions across the industry and promises to become the most widely used open source controller.

This White Paper discusses the implementation of a security plugin that provides a single pane of glass for providing information about controller security.

The controller is well accepted as the single most vulnerable element in the network from a security point of view. It may be threatened in multiple ways like denial of service attacks or maliciously crafted data to force the controller to misbehave. The threat to the controller arises from the north-bound, south-bound and east-west interfaces in a myriad of ways.

If messages from north-bound applications are allowed to communicate with the controller unchecked, then there is possibility of message exchange with unauthenticated sources. There is also a risk of the north-bound messages being modified in transit by intermediate nodes and yet going undetected at the controller unless message integrity verification is done. The same concern exists for the other interfaces like the east-west communication with peer controller and south-bound interface as well. Possibility of a data flood from north-bound or south-bound entities trying to bring down the controller is also probable.

If any of the above mentioned methods to over-whelm the controller is successful, the ramifications of such attacks are huge and has the potential to affect the entire network. Hence, it is highly recommended that the security for the controller should be granular and robust to be successfully able to be thwart attacks from the network and hold back the attacker till the mitigation system can detect the attack and block the source.

The paper starts off discussing the problems associated with security in SDN in general and then covers the Opendaylight specific issues in particular.

1. INTRODUCTION

1.1 Why SDN?SDN is a term coined to exhibit the concept in networking where the control plane is decoupled from the physical infrastructure and is instead moved out into a separate entity called the controller. The controller provides networking services that help to manage the network and also determine how the data plane flows are configured. Since the controller runs as a separate software to manage the entire network, hence its termed as ‘Software Defined Networking’ aka SDN. The switches (physical infrastructure), that handle the traffic flow, may be made available from multiple vendors as long as they are compatible with the protocol of communication between the controller and the switch. This reduces dependency on any particular equipment manufacturer and the service provider has the flexibility to use switches of their choice that gives them the cost and operational advantage. According to a survey by Spirent in 2014 covering service providers that control 51% of global telecom capex, the main driver for SDN adoption is revenue generation through cloud services aided by SDN [3].

1.2 What is the Challenge with SDN Security?A recollection of the native network topology exhibits a network that is a mix of routers and switches (combinedly referred to as the network elements in future course of this paper) interconnecting the LANs and the WANs to the end-points. The network elements have the control plane and the data plane that reside inside individual boxes and is responsible for session establishment as well as data forwarding.

In a private network, security is deployed at the network gateway and the De-Militarized Zones inside the network. A mix of network (FW / Proxy Servers / IPS / IDS etc) and host based (end-point FW / IDS etc.) security devices are used to protect such networks.

With the advent of SDN, the network security has a whole new network node to secure. That new network node is the SDN Controller. While the controller provides a bird’s eye view of the network and therefore acts as an enabler to program the underlying network and also enhance its security, but, at the same time it opens up a host of security issues due to its own existence. The controller is susceptible to attacks from the users and applications, the peer controller with which it talks to and

Copyright 2015 Page 1 of 7

also from the underlying network elements that it controls. Therefore, the SDN architecture has a new challenge on its hands to protect the controller that forms the backbone of the network.

While the network and transport protocol level vulnerabilities needs to be addressed by the Operating System on which the controller runs, there are other application layer security issues that have to be handled at the controller.

We will discuss some of the application layer security issues in the subsequent sections from the Opendaylight (ODL) controller perspective.

The following figure is a diagrammatic representation of the ODL controller vulnerabilities from the different interfaces.

Fig1. ODL Controller vulnerability from different interfaces

Apart than the controller, there are vulnerabilities exposed in the SDN network under the purview of the ODL controller as well. Discussions on the network vulnerabilities is outside the scope of this paper.

2. THE GAPS IN ODL CONTROLLER SECURITY:This section delves briefly on the security solutions that have already been implemented to protect the ODL controller and the areas of vulnerability that still exist till date.

2.1 Controller defense already in place:2.1.1 AAA project:For a controller platform that supervises and manages the network, it is important to have restrictive and role based access for the users that log into it. This is essential to maintain the identity of the users and provide security from controller access falling into the wrong hands.

The AAA project is key to the authentication and authorization of the users and applications that log on to the controller. This ensures that the north-bound entities do not gain access to the controller without their identities being verified and therefore, protects the controller from rouge applications/users. It also defines the services that users/applications can access based on their role based access.

2.1.2 SSL/TLS based protection to the interfaces:The HTTPS support for the Restconf interface brings in the added security provided by the Secure Socket Layer. This adds to the integrity check verification and encryption of the message contents that are sent to the controller by the application.

Similarly, TLS based protection to the Openflow messages from the network provides the necessary authentication, confidentiality and integrity verification that is necessary to protect the network nodes from a rouge controller and also for the controller itself to verify identity of the network elements before exchanging data.

2.1.3 Service Function Chaining: Service Function Chain which provides an ordered list of network services provides a platform to program message flows through chain of devices to aid in the network and controller security. The chaining of the DPI / FW / IPS / IDS / Load Balancers help secure the message flows and provides depth to the perimeter security as per requirements of the network tenant.

2.1.4 Openflow Plugin Overload Protection:The Openflow Plugin protection adds to the plugin protection from a flurry of Packet-In messages from the network. It maintains queues for each network switch with which it interacts and ensures that the number of packets punted to the controller at any point of time is limited by the size of the queue. The number of packets in the queue is dependent on the rate of packets punted from the network as well as the rate at which the packets are de-queued for processing. If the queue gets full, then there are resulting tail drops due to queue congestion.

2.2 The existing Controller Vulnerabilities:Despite the closure of security gaps discussed in Sec-2.1 to secure the ODL Controller, there are certain vulnerabilities that still remain to be addressed. The following sections highlights the vulnerabilities (which are not claimed to be an exhaustive list) and sets the scope of this paper to discuss some of them in detail along with their mitigation strategies and introduce the concept of the Unified Security Plugin.

2.2.1 Controller security from packet-in attacks:We have already discussed in the previous section that the Openflow Plugin is protected from Packet-In messages via a defense mechanism of Overload-Protection. However, this mechanism of defense only helps to thwart off an immediate attack on the plugin. It does not address the root of the issue since it makes no attempt of identify the source of the attack. Also, congestion of the queue does not necessarily identify an attack. It is possible that the issue might be linked to a delay in the de-queuing and processing of the packets thereby leading to a build of congestion in queue.

Copyright 2015 Page 2 of 7

However, on the contrary, if the queue is getting congested due to heavy inflow of packets from the network, then measures need to be adopted to identify the source of the packet influx and block them. In order to do so, it is imperative that there needs to be some application that can program the controller accordingly.

We will discuss more about the mitigation mechanism in a subsequent section.

2.2.2 BGP Link-State connectivity and secured exchange of SDNi messages:The BGP plugin provides BGP Link-state Distribution as a source of L3 topology information. The BGP Plugin sets up a TCP connection with the peer before it starts exchanging the link-state messages. However, the TCP connection is not a secure one and is susceptible to MITM attack and DoS attacks. Also, there is no authentication of the peer before a BGP session is established. This is risky in particular if the SDNi application is run in conjunction with BGP.

SDNi is an application that runs on top of the ODL controller to establish east-west communication between peer controllers and exchange various network information elements like topology, policy, QoS details etc. with peer controller. This is particularly useful to help identify the best path for packet delivery to the destination node(s) in a CDN via multiple networks controlled by separate ODL controllers.

The reason for the alarm with SDNi is because of the fact that it leverages the BGP plugin to share important information with peer controller(s). This exposes it to various risks like interaction with rogue controllers or modification of data by intermediate network elements which may go undetected. The impacts of such attacks can be very disruptive. If any network element gets access to the network sensitive data in the transit, it feeds the attacker with extensive information to launch specific attacks on the controller or its network and overwhelm them. Also, the rogue controller may make it appear as if data path via its network offers best bandwidth availability, thereby, forcing the network data to be steered to its network for easy interception.

Therefore, there needs to be a mechanism in place to perform authentication of the peer followed by adding confidentiality and integrity checks in the message exchange procedure to make the system more secure. The details of the mitigation solution towards this end will be discussed in detail in a subsequent section.

2.2.3 Protection of other South Bound plugins:Other than the Openflow and BGP plugin, there are other southbound plugins in Opendaylight controller like NETCONF, SNMP, OVSDB etc. that can also open up vulnerabilities for the controller. While some of the protocol based plugins operate over a secured interface to protect against eavesdropping, they however may not be protected from DoS attacks from the underlying network elements.

Mitigation of the security issues that are opened up by these South Bound plugins other than Openflow Plugin and BGP is not discussed in this paper.

2.2.4 Secured exchange of data between clustered controllers:Controller clustering is important from the High-Availability point of view especially since the controller is the programmer of the underlying network. This not only adds redundancy to the architecture but also increases the scalability of the model

 Current ODL controller clustering is built on top of Infinispan distributed-caching/data-grid platform. Infinispan uses Jgroups as a reliable messaging layer for the cluster. Jgroups authorization and encryption features need to be enabled to ensure the security of the message exchange between the clusters.

Clustered controller security is outside the purview of this paper.

3. THE UNIFIED SECURITY PLUGIN:While security has been operating mostly in silos in the native networks, the SDN architecture provides a cost effective and unique scope to unify the collation of information that can aid in enhancing the security of the controller in particular and the network in general. The plugin is being developed as part of the ODL Beryllium Release [4].This is because the SDN controller has a complete view of the network and can therefore tap into the packet contents flowing in the network for better visibility.

The Unified Security Plugin (USecPlugin) is developed for ODL controller as an infrastructure that provides a single pane of visibility related to controller security. The plugin collates the security related information from various interfaces and is made available to the ODL northbound APIs for external parties to retrieve the information. The security information could be handy in identifying attacks on ports exposed by the SB plugins, suspected controller intrusions or information about trusted controllers in the network. Information collected at the plugin may also be used to configure Firewalls and create IP Blacklists for the network. The USecPlugin is designed to provide ‘security service function’ for the Opendaylight controller.

The utility of the USecPlugin is better understood from the perspective of the use cases described in the following sections 4 and 5. However, the USecPlugin may be further enhanced to cover use cases related to controller security beyond what we have described here.

4. CASE1 - THE PACKET-IN ATTACK AND ITS MITIGATION:4.1 Explaining Packet-In Attack and SimulationIn an SDN architecture supporting Openflow switches, the switches are flow programmed by the controller to determine the path for the packet to its destination. When a packet arrives at an Openflow switch, the packet header and metadata is matched against the flow tables in the switch and instructions are executed as per the flow table. If a matching flow table entry is not found, then the packet might either be dropped or sent to the controller based on the configuration of the table-miss flow entry. Moreover, packets are sent to the controller if an explicit action is present in the switch to handle incoming packets with

Copyright 2015 Page 3 of 7

an action=CONTROLLER or a data packet arrives with an invalid TTL. If the packet is sent to the controller over the control channel, it is sent as a Packet-In message.

The structure of the Openflow message with Packet-In is represented in the figure below:

Fig2. Openflow Message Structure with Packet-In

The Packet-In field of the Openflow message has the payload containing information of the IPv4/ IPv6 address source and destination for which the Packet-In message is crafted.

Once a connection has been established between the controller and the switch, multiple packet-in messages from the switch can force large scale consumption of CPU and memory utilization at the controller. This can be exploited as a vulnerability by an attacker that can force the Openflow plugin to be overwhelmed.

In order to empirically prove the point, we carried out a Packet-In attack on the controller running Opendaylight Helium SR3 release. The network simulation of the attack was done using Mininet. Sustained Packet-In messages from Network were created by configuring switch with default flow to ODL controller in case of a table-miss entry. Packets were sent to the controller at the rate of 20K PPS.

A diagrammatic representation of the problem is shown in the figure below:

Fig3. Packet-In Attack

As a consequence of the attack, Controller CPU utilization shoots up to ~150% (On dual-core x86 processor). Approximately 35% Memory utilization is observed with system having 4GB RAM.

Additionally we could also observe the following statistics with packet tail drops happening:

• Total Packets sent from the switch: 9600645 Packets.

• Total Packets count processed by Openflow Plugin in Controller: 9001148

• ~ 6% packet drops on controller.

In order to plug this vulnerability, queue based handling of Packet-In messages is already designed and implemented in ODL, thereby providing the first level of defense to the controller against such attacks.

A snapshot of the resource utilization on the system running the controller is displayed in the figure below:

Fig4. Resource utilization of system during Packet-In Attack

From the snapshot, it is visible that the CPU utilization is significantly higher due to the packet-in attack. Also, the figures shared earlier shows an approximate 6% packet drop due to the attack. This implies that if there is an attack happening with fast punting of packets to the controller from any port in the switch, then packets coming through other ports in the same switch and sent as packet-in message to the controller will start getting impacted as well due to the packet drops.

So, while the queue based packet handling at the controller is able to fend off the packet-in attack, it is having collateral impact on the resource utilization and packet handling.

4.2 Attack Mitigation from Packet-In Messages:Considering the collateral impacts of a Packet-In attack as discussed in Sec-3.1, it is imperative that we look at means to mitigate such attacks rather than just thwarting them. Also, a deep-dive into the details of the source of packet-in attack is necessary to be able to build an information base to protect the system from such future attacks.

In order to build a solution to mitigate the problem, details of the rate of packet influx for Packet-In messages from Openflow plugin is required. This information is used to design a system for detecting an impending attack. The details of the design is discussed below.

4.2.1 Designing the Mitigation System:In order to have a mitigation system in place, four key factors need to be kept in mind:

a) There needs to be a fair estimate of the rate of packet influx to be able to figure out an impending and/or actual attack on the system.

b) The source of the packet-in messages needs to be identified.

c) Design a notification mechanism to send notifications to interested parties when an attack is impending or detected.

d) Have a persistent database to record the source of high Packet-In messages for current or any future reference.

The design factors are discussed in detail below:

The estimation of the packet influx in the system can be calculated by registering the USecPlugin for notification of

Copyright 2015 Page 4 of 7

Packet-In messages from the Openflow plugin. Once registered, plugin starts receiving continuous notification from the Openflow plugin whenever a Packet-In message is received from the network. The Packet-In message notification is received with the ‘Data-Path Id’ of the switch and the node-connector information to identify the port (in the switch). This information is collated over a period of time continuously (when there is no attack from the network) to calculate the average rate of packet influx (Sav) on per switch basis.

Collecting of the above mentioned information for extended period of time provides us with the historical levels of average packet-influx for a switch at peace-time levels. USecPlugin screens samples of Packet-In message payload contents at regular intervals of time to get the source address of legal packets at peace-time and stores the same in a persistent database. These source addresses will be maintained in a White-List of addresses for future reference. With the peace-time level packet influx rate already calculated, next the USecPlugin compares the packet influx rate on a continuous basis and raise the first alarm (Alarm1) for a switch if the present influx rate on the switch (Sp) is a certain percentage value (which is configurable) – referred to as the Low Water mark (N lw), over and above the historical average for a configured period of time (t1).

Calculation -

Alarm1: if ‘Sp > ((100 + Nlw ) * Sav ) / 100’ for time ‘t1’

Nlw is the ‘Low Water’ mark percentage value.

‘t1’ is the time for which the Low Water mark breach should happen to raise Alarm1.

[Both Nlw and ‘t1’ are configurable values]

Once Alarm1 is raised, USecPlugin screens the payload of Packet-In messages on the affected switch to get the source address for the messages. This information is crucial to identify particular source address or group of source addresses for the high influx Packet-In messages. All source addresses recorded for the Packet-In messages for switch are stored in a temporary data-store along with the influx packet rate, dp-id and node-connector value.

If the high influx of packet-in messages is a result of a sudden spike and Sp eventually goes below the Low Water mark (and stays below the mark) for t2 seconds, then Alarm1 is cleared off. [t2 is a configurable value and may be of value greater than or equal to t1 ]. Along with clearing off the alarm, the source addresses, influx packet rate, dp-id and node-connector values written to the temporary data-sore since Alarm1 are also cleared off. This event is classified as a ‘Temporary Spike’.

On the contrary, if Sp persistently stays above the Low Water mark and eventually hits the High Water mark (which is determined by a certain percentage value Nhw over and above the historical average), then the second alarm (Alarm2) is raised for the switch.

Alarm2: if ‘Sp > ((100 + Nhw ) * Sav ) / 100’

[Nhw is a configurable value]

Alarm2 is classified as a ‘Permanent Spike’.

Along with the raising of the Alarm2, the temporary data in the data-store is removed and written to a persistent database. This

is intended to help mitigate the Packet-In attack and correlating the source address for similar attacks in future. The source of attack is populated in a Black List of IP addresses with a count of the number of times it has triggered an attack. If the same source figures in the list of White Listed IP Address, then it is removed from that list. The same source addresses can be used for deriving correlation if any other forms of attack are detected and reported to the USecPlugin in future.

While we previously talked about the logic for generation of alarms based on calculation of the historical peace time packet influx rates of a switch, the implementation also provides an alternative option to the controller user to configure specific values of packet rates for low and high water marks on the basis of which alarms need be raised instead of relying on peace time readings. This option offers additional flexibility to the user for tweaking the alarm generation system as per choice and requirement of the network.

The alarms that are generated are meant for consumption by third-party external applications that may want to utilize the information for mitigation of the Packet-In attack. Depending on the different alarms that are registered for by the applications, the USecPlugin will notify the same back to the applications. Also, the USecPlugin provides Restconf interfaces to the applications to fetch the details of the source address(es), influx packet rate(s), dp-id(‘s) and node-connector information that may be involved in the Packet-In attack. This is a polling mechanism in addition to the notification mechanism mentioned earlier.

The methodology adopted by the application to correlate the information from the USecPlugin and formulate strategy for attack mitigation is left to the third-party application logic and outside the purview of this paper.

5. CASE2 - SECURED EXCHANGE OF SDNI MESSAGES:5.1 Preview to BGP and SDNi concepts:As discussed earlier in Sec-2.2.2, the BGP link state protocol serves to exchange the network topology with peer networks for optimized routing. The SDNi project in Opendaylight is designed to establish communication between multiple SDN controllers. The data shared is control plane parameters like Topology, Quality of Service (QoS), policy etc. Since SDNi uses BGP session to exchange information with peer controller(s), therefore, the steps to initiate exchange messages is as follows:

1. First establish a TCP connection between two controllers to exchange BGP information.

2. Establish a BGP connection between the BGP speakers in the controller.

3. Start sending and receiving the NLRI updates between the controllers, containing the QoS and other updates depending on the use cases designed with SDNi.

5.2 Security Concerns with SDNi:Since SDNi depends on the Topology, QoS. Policy and other info shared by peer controllers for conceptualizing Bandwidth-

Copyright 2015 Page 5 of 7

On-Demand or servicing CDN, it is important to ensure the following:

1. Authenticity of the peer controller(s).

2. Data Integrity verification check for the information shared by inter-subnet controllers.

3. Encryption of data exchanged to protect the network details from being exposed to the external entities in the network.

If the peer controller remains unauthenticated, it raises the spectre of a MITM attack resulting in bogus session establishment with rogue peer controller.

A diagrammatic representation of the problem is shown in the figure below:

Fig5. MITM Attack (Bogus Session)

Authenticity of the controller is essential to ensure that the peers that interact with each other verify that none of the controllers are masquerading.

5.3 MITM Attack Mitigation:The implementation in its present form in the ODL Controller Lithium Release verifies the authenticity of the peer using TCP MD5 authentication mechanism as detailed in RFC 2385 (Protection of BGP Sessions via the TCP MD5 Signature Option).

The implementation of the TCP MD5 authentication is optional configuration in ODL controller considering that it needs support for the same on the peer controller before it can be deployed. If the peer controller does not support the authentication mechanism, then there is presently no other way in which the peer controller may be authenticated before a BGP Session establishment. However, keeping in mind that authentication is an important aspect before SDNi sessions are established, therefore, there needs to be a mechanism for determining whether the peer is authenticated. Only if the peer controller is authenticated should an SDNi session be ideally established to prevent MITM attacks.

Considering that the TCP MD5 authentication is based on the shared password used for creation of the MD5 digest, the authentication mechanism is not a full proof one. Also, maintaining the same password forever is not suggested from security perspective lest it may get leaked to the attacker at some point of time. However, changing the password and sharing the same with the peer is also a challenge and leaves the possibility of a security breach.

In order to make communication more secure, the TCP connection for BGP Link-State protocol should be secured with a SSL/TLS security to encrypt the data and ensure data integrity verification. Again, the SSL/TLS security is dependent on whether the peer controller also supports the same for added security. The SDNi session establishment may optionally want to establish session with peer controllers that have the SSL/TLS security layer on top of the TCP connection.

Keeping the above security mechanisms in mind, the information about the authentication or encryption on the interface connection to the peer controller is updated in the USecPlugin. Whenever SDNi wants to establish a new session with peer controller, it should check the USecPlugin for the security related information before it decides on the session establishment.

However, for providing Authentication, Integrity Check and Encryption, it is advisable to add SSL/TLS security on a TCP connection before establishing a BGP session.

6. USecPlugin Architecture:Having detailed out the use cases for the USecPlugin in sections 4 and 5, this section gives an overview of the architecture for the plugin.

Fig6: Unified Security Plugin architecture

The above figure shows the architecture of the USecPlugin which provides Security Service function for the ODL Controller. The USecPlugin registers for the Packet-Notifications in MD-SAL. These notifications are received from the Openflow Plugin for detecting Packet-In Attack. The Openflow plugin also writes the contents of the Packet-In messages to the OF Data Store. The USecPlugin needs to access the OF Data Store to access the Packet-In message metadata.

The USecPlugin has its own data store in MD Sal to temporarily store the Packet-In message metadata as detailed in Sec 4.2.1

Copyright 2015 Page 6 of 7

above. The temporarily stored metadata is written to the persistent database when the attack is confirmed.

Similarly, for protection of the SDNi application, the authentication of peer controller and interface security details of the inter-SDN connection is updated to the USecPlugin and stored in a persistent database. USecPlugin exposes a NB API for the SDNi application to fetch information related to east-west interface security before exchanging the network updates.

The USecPlugin is developed in a modular manner leaving scope to extend for other security related events in the controller that may require to be store in a central repository.

7. ONCLUSIONThe USecPlugin is a novel design to provide a centralized database of all security related information for the ODL controller. Though the plugin has been conceptualized for the ODL controller, the same can be implemented for other SDN controllers as well to add visibility to security related information for controllers. As discussed above, the utility of the plugin is not restricted to the use cases discussed above and can be extended to cover other types of controller vulnerabilities exposed by the application protocols that are running in the controller.

The collation of security related information by the USecPlugin allows for running analytics based engine to detect anomalous behavior which could point to an impending attack. This makes handling of security in controller much more intelligent and adaptable for user to configure threshold parameters as per network fluctuations.

The USecPlugin is not designed to add layers of security within the controller since that is not the objective of the controller. There are separate security appliances that can run separately outside the controller to protect the network nodes including the controller. The USecPlugin just acts as an enabler to add visibility to any security risks arising out of the events handled within the controller. This helps to make security more granular and program the network to mitigate risks by integrating with third party external application.

8. ABBREVIATIONSAAA – Authentication Authorization Accounting

API – Application Programming Interface

BGP – Border Gateway Protocol

CDN – Content Delivery Network

DoS – Denial of Service

DPI – Deep Packet Inspection

FW - Firewall

HTTPS – Hyper Text Transport Protocol Secure

IDS – Intrusion Detection System

IPS – Intrusion Prevention System

MD5 – Message Digest 5

MITM – Man In The Middle

NETCONF – Network Configuration Protocol

NFV - Network Function Virtualization

NLRI - Network Layer Reachability Information

OF – Open Flow

ODL - Opendaylight

OVSDB – Open vSwitch Database Management Protocol

PPS – Packets Per Second

RFC – Request For Comments

QoS – Quality of Service

SDN - Software Defined Network

SDNi – Inter-Software Defined Network

SNMP – Simple Network Management Protocol

SSL – Security Socket Layer

TCP – Transport Control Protocol

TLS – Transport Layer Security

TTL – Time To Live

9. REFERENCES[1] http://blogs.gartner.com/andrew-lerner/2014/12/08/

predicting-sdn-adoption/

[2] http://newsroom.juniper.net/press-releases/new-juniper- networks-study-finds-u-s-companies-sp-nyse-jnpr-1134411

[3] Infonetics Research: SDN and NFV Strategies: Global Service Provider Survey, March 2014 (51% of world telecom capex)

[4] https://wiki.opendaylight.org/view/ Project_Proposals:Controller_Shield

Copyright 2015 Page 7 of 7