This document discusses the implementation of a unified security plugin for the Opendaylight SDN controller. It begins by describing how SDN architectures introduce new security challenges by making the controller a single point of failure. It then outlines some existing security measures in Opendaylight but notes remaining vulnerabilities, such as from packet-in flooding attacks. The document proposes a unified security plugin that would monitor the controller's interfaces and APIs to identify attacks and share security-related information for mitigation. It provides an example of how the plugin could help detect and block a packet-in flooding attack aimed at overwhelming the controller.

1. Unified Security Plugin for Opendaylight Controller
ABSTRACT
For 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
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.
Copyright 2015 Page 1 of 7

2. 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.
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.
Copyright 2015 Page 2 of 7

3. 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
Simulation
In 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 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.
Copyright 2015 Page 3 of 7

4. 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
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 (Nlw), over and above the historical
average for a configured period of time (t1).
Copyright 2015 Page 4 of 7

5. 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-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.
Copyright 2015 Page 5 of 7

6. 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
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. ONCLUSION
The 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
Copyright 2015 Page 6 of 7

7. 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. ABBREVIATIONS
AAA – 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:Contro
ller_Shield
Copyright 2015 Page 7 of 7