1. Copyright 2015 Page 1 of 7
Addressing Security in SDN Environment: A Perspective
Saikat Chaudhuri
Tata Consultancy Services,
Bangalore
+91-8884742237
chaudhuri.saikat@tcs.com
Subash Adigal
Tata Consultancy Services,
Delhi
+91-9643330517
subash.adigal@tcs.com
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].
However, along with the future prospect of SDN, there are
numerous concerns surrounding the security aspect associated
with it. Despite the concerns, organizations are keen to adopt
SDN due to its numerous benefits amongst which analytics,
reporting and resulting automation are some of the key elements.
The White Paper discusses a possible solution towards addressing
the security concern by automating the security in SDN
environment. The solution deploys an application that
continuously monitors the alerts generated by IDS, analyses the
reports and automates action to block flows from hosts based on
the alerts raised by the IDS. The paper also discusses the
implementation of sFlow based monitoring of the network. This is
based on packet sampling which is utilized to analyze the traffic
trend and determine if there is a possible flooding attack which
may have gone undetected in the network.
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice. To copy otherwise, or republish, to post on servers or to
redistribute to lists, requires prior specific permission and/or a fee.
TACTiCS – TCS Technical Architects’ Conference 2012
1. INTRODUCTION
1.1 SDN and NFV
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
application 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/or
operational advantage.
NFV complements the concept of SDN by providing the
additional flexibility of dynamically providing network functions
on VMs. This enhances the levels of utilization of the physical
hardware and also bring in cost benefits where number of VMs
can be scaled up or down dynamically as per the requirement. The
VMs may be spawned on top of physical hosts such as high
volume servers, storage, switches or security devices like
Firewalls, Load Balancers and IDS. The SDN controller is
agnostic to the virtualized network elements and can manage or
control the nodes transparently.
1.2 Concepts of Security in SDN and Defence-
in-Depth
With SDN and virtualization of the network, there are various
elements of the network that requires protection. This includes
providing protection to the controller, protecting the physical and
virtual nodes in the network and protecting the inter VM traffic on
the same host from malicious flows. Security of the system also
requires that the controller allows only access to valid users
whose identity is verified and allows trusted application to gain
access to the controller.

2. Copyright 2015 Page 2 of 7
Also a network design usually has several network segments. It is
important to protect the various network segments from both
internal and external attacks.
An external attack is one that is orchestrated from a source outside
the network. The external attacker may try to attack a network by
various means like inducing malware or take the network down
using a DDoS mechanism. A network can be protected against
external attacks using Firewalls and/or Proxy servers that can
protect the internal network by restricting access for potentially
dangerous external IP addresses and also forcing all traffic to and
from the external world to pass through the proxy server. This
masks the internal nodes from getting exposed to the outside
world and helps protect them from being targets of any DDoS or
DoS attack.
However, there is possibility that attacks may take place from
unknown sources. If there is no previous knowledge of the source
of the malicious attacker, a Firewall cannot restrict access to the
same. In such a situation, the intrusion detection and prevention
devices prove useful. The intrusion detection devices are designed
to detect attacks based on signatures of the packets and thus
complement the other security devices used to secure the network.
These devices may be placed at the gateway to the network to
detect attacks at the network perimeter.
So Firewall, Proxy Servers, Intrusion Detection and Prevention
Services together secure the perimeter of the network.
Apart from attacks originating from external networks, there is
also a possibility of attacks originating from nodes inside the
network. Hence, we need to secure our internal network as well.
This may be done by using early signs of detection of anomalous
behavior in the network or use signature based detection of
attacks in the network. Intrusion detection devices may also be
placed at the entry point of different network segments within the
network for protection from internal attacks. This adds multiple
layers of security and is known as the concept of defence-in-depth
to secure the network from all possible sources.
2. THE PROBLEM STATEMENT AND
IMPLEMENTATION PERSPECTIVE
As outlined in the previous section, the SDN controller is the new
nerve center of the network. The controller abstracts the network
and manages the network from a centralized node. It offers
various networking service, orchestration and management
functions to control the network.
With the controller offering centralized control, it’s pertinent to
utilize the controller as a central monitoring function to manage
the security of the network as well. This provides a definite
opportunity to correlate the network security events at the
controller and managing the network flows to protect the network
from malicious traffic. Since the controller has access to the entire
network, hence, it can influence the protection of the network
from both internal as well as external attacks.
The paper explores the perspective of leveraging this concept to
provide a comprehensive security to the network from all sources
(external or internal to the network). The implementation may be
further enhanced to add security analytics to collect, analyze and
correlate the information from the network, making it operational
as a natural substitute of a SIEM tool. The implementation also
mimics a SOC by taking automating the steps to protect the
network based on the alert based events generated during the
attacks.
3. IDS/IPS SECURITY IN NATIVE
NETWORKS
In this section, we briefly discuss how an Intrusion Detection and
Prevention operates in native networks. This is a precursor to the
security implementation approach that is discussed in later
sections.
An Intrusion Prevention System operates in non-promiscuous
mode. This implies that the device is placed in-line in the network
to listen to packets entering or leaving the network. An IPS works
on the basis of signature based attack detection. In the event of
attack identification, it prevents the packet from passing through
it, thereby protecting the network.
Conversely, an IDS works in promiscuous mode where it listens
to packets mirrored from the network. Based on the rules
configuration, an IDS validates the packets against the signatures
of the packets to identify any attack. In case an attack is identified,
the IDS raises an alert which is fed as input to a SIEM tool. A
SOC is setup where security professionals go through the alerts in
real-time, correlate the information with the help of SIEM tool
and take the required steps towards threat mitigation.
The security professionals also keep a close look out for any
topology changes in the network to identify new nodes which
could be at risk or identify unprotected network segments.
The advantage of IPS is that it can prevent single packet attacks.
If IPS finds a match between the packet contents and the IPS
signatures configured, it is then successfully able to ward off the
attack on the network. However, since IPS has to scan each
packet, match its contents with the rule based signatures and
trigger an alert, therefore, IPS processing impacts the throughput
of the network. Also, if an IPS goes down, it immediately impacts
the network connectivity.
On the other hand, an IDS protects the network re-actively. Once
IDS alert events are generated, the events are correlated at the
SOC and the threat mitigation is initiated. This helps protect
against the action on false-positives thrown up by the IDS as the
alerts are vetted by the security professionals. Also, there is no
impact on the network traffic if an IDS goes down for any reason
since it operates in promiscuous mode.
4. SEPARATION OF SECURITY
PROCESSING FROM PHYSICAL SWITCH
In native networks, there are several IPS/IDS solutions available
that are integrated with the OEM switches for protecting the
network. An example is the Cisco ASA switches integrated with
FirePOWER services (from Sourcefire) and is referred to as Next
Generation IPS that protects the network from various
vulnerabilities. However, with the advent of SDN and NFV
architecture, there is a definite intent to disassociate the data
forwarding plane from the control plane and other security
services provided by the physical infrastructure. This

3. Copyright 2015 Page 3 of 7
disassociation helps maintain the concept of operational and cost
flexibility that forms the core of SDN-NFV solutions.
5. THE IDPS MONITOR AND
CONTROLLER FOR SDN
As outlined in Sec-3 above, there are definite advantages and
disadvantages of IPS and IDS. The white paper discusses a
solution implementation with IDPS monitor and controller
application that aims to derive the advantages of both worlds as
much as possible. An IDS listens to the packets mirrored from the
network. An application (henceforth referred to as ‘App’)
proactively protects the network from attacks by monitoring the
alerts generated by the IDS in real time. It controls the network by
creating flows to isolate the network from the node that is
identified as the attacker.
Additionally, the solution also aims to protect against flooding
attacks initiated within the network that is not protected by the
IDS. This is achieved by random sampling of the packets flowing
through the network and reporting of the flow and counter
information to the App. This utilizes the sFlow technology that
samples packets on the routers and switches. The App correlates
the information to make intelligent judgments regarding the traffic
flow to detect the flooding attacks. Attacks once identified are
mitigated by blocking the flows originating from the attacker.
Based on the network analysis, the App also aims to tune the IDS
continuously to prevent generation of False positives and keep the
configuration up to date.
Since the App doubles up as a monitor and controller of the
network and aids in threat mitigation, therefore, the App
automates the processes carried out by a SOC. This opens up the
possibility of providing cost advantages by either replacing the
SOC or reducing the resources required to monitor a SOC.
6. IMPLEMENTATION APPROACH
For our concept implementation, the Open Daylight controller is
used along with mininet topology to simulate a network scenario.
Once we bring up the mininet switches and hosts and attach the
mininet switches to the ODL, we configure an interface on the
gateway switch as the ‘Span’ port that mirrors the packets passing
through that switch.
For the purpose of IDS, we install SNORT. Before SNORT IDS is
started, we have to configure the snort.conf file for the host
network that requires to be protected. Additionally, if there are
specific WEB servers or SMTP servers etc, their IP address needs
to be populated as well so that they can be specifically identified
during alert generation. The RULE_PATH along with the set of
rules that requires to be enabled needs to be identified. We also
need to select the output mode for the alert. For our purpose, we
have used text based log and alert generation.
To implement our solution, we have designed an App that resides
within the controller as an OSGi bundle. The App monitors the
alerts from the IDS. The design is flexible to add APIs that are
exposed for any external application or web based request can be
sent to re-program the bundle as required.
In addition to the App, we also have an IDS agent whose role is to
read the details of the snort configuration and send details of the
same to the App as and when requested. Additionally, if there is
any request from the App to reconfigure the IDS, the agent will
have the rights to make the requisite modifications.
For flow sampling, sFlow is configured in the OVS. When traffic
flows, samples are generated from the OVS and the App acts the
collector which receives the samples.
Figure-1 below gives a good overview of the concept
implementation.
Figure 1: Solution Representation
The diagram highlights the IDPS Monitor & Controller residing
inside the ODL controller as an OSGi bundle. The App polls the
text file in which the alerts generated by the IDS are written to in
real-time. The sFlow packet samples from the switch are sent to
the App which processes the information further.
6.1 SNORT Execution and Alert Generation
Once we have the setup in place, we create alerts by carrying out
certain deliberate attacks on the system.
One common form of reconnaissance as a prelude to an attack is
port scanning on the hosts in the system. We can use the nmap
tool to do port scanning of a range of ports in a host system to
identify open ports and the services running on them. This helps
in exposing the possible weaknesses of the system and offer
information platform to launch an attack.
An example of one such nmap scan is shown in Figure-2 below
where a host is scanning for open ports in the 10.0.0.1 machine.

4. Copyright 2015 Page 4 of 7
Figure 2: Nmap port scan of a network node
The results of the scan show there are no open ports in the host
10.0.0.1 but the very fact that a scan has happened should be good
enough to trigger an alert from the IDS that there is a possible
source address which is trying to do a reconnaissance activity.
If the ‘scan.rules’ is enabled in the configuration file and the right
IP address of HOME_NET address is populated, then SNORT
should throw up an alert as in Figure-3 below:
Figure 3: SNORT Alert
As per the alert generated, it is clear that SNORT has been able to
identify a nmap port scan trying to attempt an Information leak
from the host. The alert clearly identifies the source of the
reconnaissance and the victim machine. Based on the
configuration, the alert is identified as a ‘Priority 2’ alert.
The alert notification is parsed by the App and based on the alert
priority, it is used to determine the threat mitigation action to be
taken.
The App gives an option to configure the blocking period
corresponding to different priority alerts (with higher blocking
period for higher priority alerts) for traffic emanating from the
source address that is found to be generating the attack. Since
addresses can be spoofed, hence it makes sense not to block a
particular IP permanently. However, if the same source IP is
found to be present in the alerts more than ‘n’ times (where ‘n’ is
configurable), then the fraudulent IP is put in the blacklist. An
address once placed in the blacklist would mean that all flows
initiated from the fraudulent source would be permanently
blocked till there is separate administrative action to remove it
from the blacklist.
Figure-4 below shows a flow that is blocked for a period of 120
seconds corresponding to a Priority 1 alert. Post the timeout
period, the flow will be automatically removed and normal traffic
flow can resume.
Figure 4: New Flow based on SNORT Alert
The above example was an illustration of how alerts are generated
and corresponding action is taken by the App in response to the
alerts generated. Similar alerts will be generated when any other
attack is detected and the alert file generation will be similar to the
one shown above.
6.2 Maintaining a White List / Blacklist of IP
Address (es)
In any network, port scanning activity or sending ICMP echo
messages are part of the regular management messages in the
network. However, attacks may actually be disguised in garb of
such regular management messages. In this implementation, the
App takes it upon itself to distinguish between genuine
management messages from the fraudulent activities initiated by
attackers in the network. To this end, its necessary that the App
maintains a White List of IP addresses which are recognized as
genuine IP addresses and activities matching the alert
notifications from such IP addresses are not classified as harmful.
The White List of IP addresses is populated in a file that it read by
the App when it starts up.
The App also exposes an API that can be used to dynamically
add/modify/remove IP addresses from the White List as required.
Just as a White List, we also have a Black list of IP addresses that
are identified to be fraudulent IPs. This Blacklisted IP addresses
are read by the App during initialization. If there are any
addition/modification/deletion to the list at run time, this can be
communicated via an API exposed from the App to do the re-
configuration.
The App, therefore, makes sure that the controller blocks any
flows emanating from such fraudulent, black-listed IP address
upfront.
6.3 Detecting Topology Changes in the
Network
If a new network segment is created, then that should be
automatically detected and probed whether the newly added
network is protected by IDS or not.
The solution has an agent associated with IDS that can share the
Host IP subnets that are monitored and the list of IDS rules
enabled.
The App keeps monitoring the network topology for any additions
/ modifications to the network via the topology manager and host
tracker services in ODL.
If any of the subnets added to the network under the purview of
the controller is not protected, then intimation is sent to intimate
the administrator for corrective measures.
The network Admin can spawn a new VM and run IDS that can
scan the new network segment for possible threats. The alerts

5. Copyright 2015 Page 5 of 7
generated from the new IDS needs to be sent to the App for future
threat mitigation.
6.4 Dynamic Tuning of the IDS -
Add/Mod/Del IDS Rules
IDS tuning is an absolute necessity for minimizing generation of
False positives. The tuning is a tedious task since it has to be
tuned according to the network configuration. The tuning of the
IDS is a continuous activity if the network configuration changes
dynamically over a period of time.
The App takes the help of the IDS agent to check whether the
snort.conf has configured for the Host Network ($HOME_NET)
to ‘any’. The network subnet to be protected against needs to be
assigned to the Host Network variable to generate definitive
information as per requirement.
The App interacts with an IDS agent to create new customized
rules, as required by the network. The agent interacts with the IDS
to gather information and provides the same back to the App
controlling the threat mitigation. The new rule addition may be a
requirement apart from the rules that come pre-configured with
Snort.
The IDS agent is also instrumental in enabling or disabling rules
in the snort configuration as per the network settings. The
configuration file, may need to dynamically enable or disable
rules based on the traffic pattern in the network. If correct set of
rules are not enabled, the attack detection will not happen.
Conversely, if unnecessary rules are added, it increases the
processing time of the IDS. Hence, rule optimization is necessary
for efficient processing of the IDS.
Additionally, the App applies a hook on the controller to check
for the type of traffic packets exchanged in the network. If any
traffic is generated which does not conform to the protocol types
allowed, then the App introduces flows to block traffic from the
source matching the protocol - so that the traffic flow with that
protocol is blocked immediately. If the protocol is to be later
allowed, then the flow matching the protocol type needs to be
removed by the App.
Conversely, we may have rules pre-configured to prevent traffic
for a particular protocol. But if any such traffic is generated as per
genuine network requirement, then the source IP address for such
traffic should be placed in the ‘White List’ to notify the App that
such type of traffic should be allowed and legal. The App will
then detect such traffic and will desist from introducing a
blocking flow for the source IP even though it matches a blocked
protocol. Hence, the hosts whose IP address is included in the
white listed IP address, have the liberty to carry any activity
which may be blocked for other hosts.
6.5 sFlow Based Detection of Flood Attacks in
Internal Network
We have briefly discussed the sFlow integration in earlier
sections. In this section, we give a detailed outline of sFlow
integration with our application and the logic around it.
sFlow is sampled flow [3]. It used for random sampling of packets
in high speed networks. sFlow has two components - one is the
sFlow agent and the other is the sFlow collector. There are several
device manufacturers that support sFlow which also includes the
Open VSwitch (which is used in mininet setup). The sFlow agent
is inbuilt in the device and needs to be configured when bringing
up the switch. However, there needs to be a separate ‘collector’
which listens to the sFlow sample packets and utilizes the sample
flow to make some intelligent judgment regarding the traffic flow
in the network.
In the concept implementation, we have configured for sFlow in
the switches which cater to traffic internal to the network. This is
to track the traffic that does not flow through the gateway switch.
Hence, any violations by traffic packets in the internal network
will not be detected by the security devices at the perimeter. This
leaves the internal network open to attacks. It’s precisely for this
reason that we configure sFlow and monitor the network.
A flow in the sFlow context is defined as traffic from the Data
Source to the Data destination. For example, traffic flow from
Data Source - say IP_1 to Data Destination - say IP_2, is treated
as one flow while traffic from another Data Source - say IP_3 to
IP_2, is treated as a separate flow. A flow sample contains the
details of the Layer-2 to Layer-4 details of the packet exchanged
along with the size of the packet that is exchanged.
In our solution, the App which is running as an OSGi bundle
within the controller, acts as the collector of the sFlow packets. It
listens to the port ‘::6343’ for packets and their information
sampled by sFlow is sent to the collector.
The sFlow sampling logic is based on the concept of probability
based sampling. If there is large number of packets sampled, the
packets from different flows in the network gives a deterministic
representation of the actual packet count corresponding to each
flow.
If there are a total number of packets, N, and a total number of
samples, n, of which a certain number belong to a particular flow,
f, then the number of frames in the flow, Nf, can be estimated
using the equation: Nf = (f/n) * N [3].
According to statistical calculations, the percentage error
corresponding to a flow is depicted as:
%error ≤ K * √(1/f) (where K is a constant) [3]
Hence, as ‘f’ increases, the error possibility corresponding to a
flow goes down exponentially.
While configuring for sFlow, there needs to be sampling rate and
polling frequency mentioned. The sampling rate determines how
frequently the flows are sampled. For example, if the sampling
rate is configured as 10, then it implies that one out of 10 flow
packets will be sampled and sent to the collector. Based on the
traffic rate flowing through a switch, the sFlow sampling needs to
be configured accordingly. This should ensure that sufficiently
large number of packets is sampled and calculations based on
such flows mirrors the actual packet flows in the switch.
Figure-5 below shows a flow sample collected and its contents in
the Raw packet header:

6. Copyright 2015 Page 6 of 7
Figure 5: Raw packet header from Flow sample
On the other hand, the counter samples are used to obtain the
number of input and output packets that have been exchanged on
an interface over a period of time.
The Figure-6 below shows a counter sample collection:
Figure 6: Counter Sample contents
The sFlow configuration on the switch needs to ensure that a large
number of samples is collected so that it is reflective of the actual
traffic flow in the network. The logic applied in the App
(collector) is to average the data packet sample information over a
period of time (with continuously changing reference window) so
that we are able to deduce the average bandwidth utilization over
different interfaces.
The bandwidth utilization in each interface is calculated and
compared against the threshold bandwidth utilization levels for
each interface. If the bandwidth utilization by a flow is found to
be exceeding the threshold value, then the source address of the
flow is blocked. Exceeding the threshold bandwidth is assumed to
be a case of flooding the destination host interface. The period of
blocking of the interface is made configurable for the network
admin to decide. Also, the period of calculation of the average
bandwidth utilization on an interface can be configured by the
administrator user.
The App also takes care to calculate the average bandwidth
utilization levels over a period of time to ensure that sudden
spikes in usage even out and does not cause unnecessary blockage
of the source.
7. SOLUTION DIFFERENTIATORS
Having outlined the implementation strategy, its important to
highlight the solution differentiators and the Capex and Opex
benefits associated with it.
7.1 Pro-active Mitigation with Zero Impact on
Traffic
One of the major drawbacks of deploying an in-band security
appliance in the network is that it affects the traffic throughput of
the interface to which it is attached, thereby becoming a
bottleneck for the network that is protected. Conversely, there is
an obvious advantage as well since in-band devices (usually
placed at the gateway of a network) can match the packet
signature of the incoming packets on the wire before it can intrude
the network. Security devices deployed in-band and having threat
mitigation capability (eg. IPS), offer a pro-active mechanism of
protecting the network whereas out-of-band devices (eg. IDS)
offer re-active security.
In the IDPS solution implementation, the SDN controller controls
the entire network. Hence, the intrusion prevention role is played
out by the controller although threat detection is made by IDS
which operates in promiscuous mode. So not only is our security
mechanism robust in terms of providing pro-active mitigation but
additionally provides non-intrusive threat detection capability as
well. This is the uniqueness of the solution that is sought to be
highlighted in this paper.
7.2 Low cost offering for ODL (CAPEX
Saving)
With software based IDS, no proprietary hardware and
automation of security configuration, the implemented solution
provides a low cost offering with ease of Deployment in SDN.
Presently there is only an offering by Radware which is named
‘Defense4all’ to secure SDN networks[4]. However, the solution
requires use of a proprietary “Attack Mitigation System” which
does the scrubbing of the packets that are identified to be possible
perpetrators of an attack. Additionally, it needs to be mentioned
that ‘Defense4all’ is a DoS mitigation solution only.
The IDPS application, in conjunction with IDS, offers protection
against reconnaissance attempts, malware detection, DDoS attacks
and many more. Also the system offers ease of deployment with
automation of the IDS tuning based on network traffic patterns.
Logs and alert information thrown by IDS coupled with statistical
information collection at the controller provides for actionable
security intelligence to reduce time for collating and correlating
threat information. With automated threat analysis, this low cost
solution is a replacement for Security Information and Event
Management tool, thereby providing huge potential for CAPEX
savings.

7. Copyright 2015 Page 7 of 7
7.3 Ease of Deployment (OPEX Saving)
The IDPS application is developed as a plugin that can be easily
installed within the ODL framework as an OSGi bundle. The
application is agnostic to the security device used in the network.
It can be integrated with any security appliance with
customization of the module that reads the alert file for processing
of the threats from the network. Additionally, the automated IDS
tuning capability provided by the IDS agent also aids in the
deployment process of the IDS that helps to keep it in sync with
the network traffic pattern and weeds out unnecessary processing
of signatures that are not required. This helps in speeding up the
processing of the signature based attack detection at the IDS.
With an obvious ease of deployment, actionable intelligence and
most importantly, proactive threat mitigation, the solution helps in
replicating a security operations center which brings in the
opportunity of huge OPEX savings.
8. CONCLUSION
The implementation approach tries to encompass the security in
SDN based networks. We have already discussed in depth about
the rationale of using an IDS vis-à-vis an IPS for building our
solution and the benefits to be reaped out of it.
However, it must be mentioned that the system still lacks the
defense against single packet attacks that will have already
impacted the network before its detected. These attacks might be
protected against by using a Host IDS or any end-point security
that is deemed suitable. Also, there is a bound to be a time lag
between generation of the alerts and their processing since the
alerts need to be polled by the application before they are
processed. However, this time lag is not significant to be a cause
of concern since the polling of the alert information is frequent
and ensures that the packet is picked up for processing almost
immediately as the alert is generated. Also, it must be kept in
mind that reasonably well tuned IDS will not throw up an awful
lot of alerts. Hence, the system is not much worse off in terms of
attack response but significantly better off in terms of removing
the network bottleneck that is brought about by an IPS.
With the future of networking bending towards SDN and
virtualization, it’s important to have a multi-pronged approach to
solve the challenges thrown by the new architecture. This
implementation has been an attempt towards that end to combine
the features of traditional IDS with an application to convert a re-
active design to a proactive one through automation and also
bring in the flavor of sampling based analytics to aid in protecting
the network.
The solution is by no means touted as a comprehensive solution
for SDN networks. As already mentioned earlier, securing SDN
networks has a wide range of challenges which include (but not
limiting to) securing of the North and South Bound interfaces of
the controller, securing the controller itself from external attacks,
securing the VNFs, establishing trust between the elements of the
SDN network and many more. The paper wishes to draw the
attention of the reader towards a prospective seeded solution that
could be handy towards building a holistic security design for
SDN networks. The proposed solution is intended to be the initial
spade work towards a larger goal of a fool-proof security of the
entire SDN eco-system.
9. ABBREVIATIONS
API – Application Programming Interface
DDoS – Distributed Denial of Service
DoS – Denial of Service
IDS - Intrusion Detection System
IDPS – Intrusion Detection and Prevention System
IPS - Intrusion Prevention System
NFV - Network Function Virtualisation
OVS – Open VSwtch
ODL - Open Day Light
OSGi - Open Service Gateway initiative
SDN - Software Defined Networking
SIEM - Security Information and Event Management
SOC - Security Operations Center
VM - Virtual Machine
10. 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] http://www.sFlow.org/sFlow_version_5.txt.
http://www.sFlow.org/packetSamplingBasics
[4] https://wiki.opendaylight.org/view/Defense4All:Tutorial