Content uploaded by Dylan Smyth
Author content
All content in this area was uploaded by Dylan Smyth on Sep 12, 2017
Content may be subject to copyright.
Exploiting Pitfalls in
Software-Defined Networking Implementation
Dylan Smyth∗, Victor Cionca∗, Sean McSweeney†, Donna O’Shea∗
∗Nimbus Centre, Cork Institute of Technology
{1}@mycit.ie
†Cork Institute of Technology
{2, 3, 4}@cit.ie
Abstract—The centralised control provided by Software-
Defined Networking allows an increase in network security as all
traffic can be vetted before leaving the attachment switch. Never-
theless, as in any complex system, there are implementation and
policy compromises which lead to security vulnerabilities. This
paper exploits such vulnerabilities to implement a suite of attacks,
consisting of Address Resolution Protocol (ARP) cache poisoning,
Man in the Middle, a firewall and access control bypassing port
scan called a Phantom Host Scan, and a Distributed Denial
of Service attack called a Phantom Storm which induces the
participation of legitimate hosts. These attacks were successfully
implemented in a Floodlight controlled network.
I. INTRODUCTION
Software-Defined Networking (SDN) [1] separates the data
and control planes of a network. This separation means that
the control logic is no longer embedded in the network device
itself but rather migrated to a logically centralised controller.
Using this approach, SDN, and its implementation Open-
Flow [2] aims to simplify network management in the face
of evolving network requirements providing greater flexibility
and control.
The SDN architecture by its design introduces security
opportunities and threats. SDN allows the customisation of
security mechanisms facilitating intelligent response on a per
flow basis. On the other hand, the SDN architecture through
its separation of planes, itself brings with it a host of new
security threats and challenges. These new threat vectors target
specific planes of the SDN architecture i.e. the application,
control, and data planes, and the interfaces between them and
have the potential to limit the impact of SDN enabled security
by threatening the confidentiality, integrity and consistency of
the network. As SDN gains prominence, the ability to identify
and deal with these threats will prove a fundamental factor in
ensuring its mainstream adoption.
In this paper, using an offensive approach, we identify new
threats by exploiting vulnerabilities in the control plane of
the SDN architecture. These vulnerabilities include the con-
troller’s necessity to flood packets with unknown destination
attachment points, or having to use wild-card, lenient, flow
rules in order to stay within the confines of the Ternary
Content Accessible Memory (TCAM) of forwarding devices.
The compromises analysed create vulnerabilities which can be
exploited. This paper proposes a suite of attacks, starting with
a novel method of performing Address Resolution Protocol
(ARP) cache poisoning, which is used to implement a Man
in the Middle (MITM) attack as well as a novel attack
called ’Phantom Host Scan’ which is able to bypass firewall
and access control rules. The Phantom Host attack is then
developed into a Distributed Denial of Service (DDoS) attack
called ’Phantom Storm’, where the attacker coerces innocent
hosts into performing the attack. Compared to the state of
the art, these attacks are designed to be undetectable by
the controller. The attacks were successfully implemented
in a network managed by Floodlight [3], an open-source,
enterprise-class SDN controller.
Based on the above the layout of the paper is as follows.
A state of art is presented highlighting the relevant works
in the area of security and SDN. Following this, a general
overview of SDN and its architecture is provided. Based on
this overview, we then present a number of vulnerabilities
introduced by the implementation of SDN. A number of
attacks are then presented and tested against the Floodlight
controller. Finally, results and conclusions are provided.
II. RE LATE D WORK
In this section we outline previous work in the areas of SDN
security analysis, Denial of Service (DoS) and poisoning. To
date a number of contributions in the area of SDN security
have focused on identifying potential vulnerabilities and threat
vectors in SDN.
Benton et al. [4] identified a number of potential vulnera-
bilities in OpenFlow driven SDN networks, whereas [5]–[8]
analysed at a high level the security issues and threat vectors
specific to SDN. Scott-Hayward et al. [9] also presented
a survey on SDN security with a particular focus on both
research and industry contributions to the area. In addition,
the STRIDE [10] method of security analysis has been applied
to SDN and OpenFlow to evaluate the potential risks to an
OpenFlow driven network [7], [11].
In the works discussed above a number of attacks against
the controller plane were identified which include DoS and
topology poisoning. These two attacks are relevant to the
context of this paper and so are discussed in detail below.
With regard to DoS attacks, Shin et al. [12], created a
scanning tool called SDN Scanner to identify SDN networks.
Using this tool, the attacker could determine if the target
network is an SDN network and using this information conduct
a DoS through controller resource consumption. Similarly,
Avant-Guard [13] discusses exploiting the same vulnerability
of control plane saturation through extensive requests from the
data to control planes of the SDN architecture. Wang et al.
designed FloodGuard [14] to provide an efficient and scalable
solution against the data-to-control plane saturation attacks.
Similarly, Lineswitch [15] extended OpenFlow with the aim
of mitigating against the same attack, whereas Sphinx [16]
uses the idea of flow graphs to verify network updates and
detect suspicious behaviour in the network, including possible
DoS attacks. All the works presented above consider one host
in the data plane saturating the control plane of an SDN
network. This paper on the other hand introduces a new DoS
attack, called phantom storm which extends existing DoS
attacks by influencing multiple victim hosts in the data plane
to participate in the attack, resulting in a DDoS attack.
While the DoS attacks target the controller and switch
resource capacities, poisoning attacks such as ARP Spoof-
ing [17] on the other hand, poison the controller’s view of
the network topology by targeting information related to the
attachment point of a host and the links between switches.
Hong et al. [18] explored poisoning in SDN and developed
the host hijacking and link fabrication attacks. Bui et al. [19]
explored similar attacks and defined the two-switch tunnel,
extended two-switch tunnel, and single-switch tunnel attacks.
These attacks all exploit the controller’s host and link discov-
ery mechanisms. A number of solutions have been proposed
to deal with the issue of topology poisoning. Solomon [20]
proposed shifting the responsibility for host management to
the data plane switches to prevent ARP spoofing. Hong et al.
introduced a defence known as TopoGuard to prevent both the
host hijacking attack and the link fabrication attacks. Alharbi et
al. [21] focused on a solution for link fabrication using Hash-
Based Message Authentication Code (HMAC) authentication,
whereas Masoud et al. [22] designed a solution that leverages
the design of SDN itself. Solutions built on the control or
application planes rely on observing the poisoning taking
place. Our attack however, does not allow the controller or
applications to observe the attack, preventing these defence
mechanisms from stopping the attack.
III. SOF TWAR E-DE FIN ED NETWORKING ARCHITECTURE
A. Logical Architecture
SDN defines two main interfaces: southbound and north-
bound. The northbound interface of the SDN architecture
provides a set of Application Programming Interfaces (APIs)
that can be used to facilitate innovation, orchestration and
automation of the network based on the requirements of
the overlying applications. Currently, there is no de facto
implementation of this interface, with the Open Networking
Foundation (ONF) Northbound Working Group actively trying
to address this issue.
Currently, the de facto implementation of SDNs southbound
interface is OpenFlow. Using OpenFlow the data and control
planes of a network are separated, creating a vendor agnos-
tic forwarding abstraction through the definition of general
”match + actions” that the switch understands. These ”match
+ actions”, along with other components such as timeout
definitions, are installed as flow-entries in flow-tables and are
stored to TCAM on the device. If a packet arrives to the
switch and no flow entry matches it, a ’table miss’ occurs
which results in a packet in message being forwarded to the
controller. On receipt of this message, the controller uses
information from the application plane and its central network
topology view to determine the best path through the network
and install a flow entry in each switch along that path. This
path is known as a ’flow’.
B. Topology Discovery
In order to build a centralised view of the network topology,
the controller must learn about links between switches in the
network. The exact mechanism for this will vary between
controllers; however, a common approach is to use Link
Layer Discovery Protocol (LLDP). The controller instructs
the switches in its network to flood LLDP packets out all
ports. When a switch receives an LLDP packet, it will send
the packet to the controller as a packet in message. When
the controller receives these packets it can then identify links
between the switches in the network.
C. Host Discovery
The Attachment Point (AP) of a host in the network is the
switch and switch port into which the host is connected. A
host’s AP must be known before the controller can perform
forwarding to that host. The AP can be learned passively or
actively. Passive learning is done by the controller observing
network traffic. One example of active learning of a host’s AP
is to flood a packet to all the switch ports except the ingress
port, with the expectation that the correct host will respond to
the packet and the attachment point will be learned [23]–[26].
D. Access Control and Firewalling
In SDN, rule based security mechanisms such as firewalls
and Access Control Lists (ACLs) can operate in two ways:
reactively or proactively, with the rules enforced in the network
by means of flow entries in the switches.
Centralised control over security rules allows them to be
modified at any time, resulting in an immediate impact on
new network communication. This allows additional systems
to be put in place to enhance the security system, such
as how IntelFlow [27] uses an external Threat Intelligence
Management System (TIMS). A TIMS is a system which
gathers threat data (such as IP addresses linked to malware)
from external sources and implements rules to prevent such
threats from impacting the hosts on the network.
Proactive Rules: Proactive rules are installed on the switches
in the network as persistent flow entries. These then allow
a switch to perform security operations without having to
consult the controller. The advantages of proactive rules are
that they can reduce the control traffic required in the network;
and take effect immediately once installed on the switch.
Reactive Rules: Reactive rules are installed on switches as
flow entries reactively. This response is triggered when a
packet in message violates rules defined in the centralised
security mechanism. The installed flow entry will stop further
rule violating traffic related to the packet in message at the
ingress switch.
IV. VULNERABILITIES IN THE IMPLEMENTATION
A. Packet Flooding for Unknown Attachment Points
Flooding packets for hosts with an unknown attachment
point can allow an attacker to perform passive reconnaissance.
An attacker could gather information such as the hosts in
the network and the communication between hosts. A packet
indicating communication could also contain other useful
information (e.g. Domain names specified in Domain Name
Service (DNS) queries). Discovery of services running on
hosts is also possible. For example, a flooded packet for
host 192.0.2.1 connecting to host 192.0.2.4 on port 3306
would indicate that host 192.0.2.4 may be running a MySQL
Database server.
This flooding could also potentially be used to subvert ACL
and/or Firewall rules. For example, take a network with two
hosts A and B. A layer 3 access control rule may specify that
all traffic with the source IP of host A and destination IP of
host B and vice-versa should be dropped. If host A sends a
packet to a host the controller doesn’t know about, the packet
would be flooded. This packet would then reach host B, as
the source and destination IP addresses would not match the
addresses specified in the access control rule.
B. Flow Entry Design
Flow entries should include a number of match fields to
ensure that matching is fine grained and correct. The imple-
mentation of lenient flow entries: can introduce vulnerabilities
which can be abused by an attacker; and can cause inaccu-
rate flow statistics being monitored and reported. These flow
statistics are the basis for many applications in SDN such as
load balancing and traffic engineering. The ability to tamper
with the statistics could provide an attacker with some control
of the traffic in the network.
Attackers can piggyback traffic on existing flows by ex-
ploiting the generality of installed rules, and can send traffic
through the network without being detected by the controller.
For example, an attacker can use a flow defined by source and
destination addresses by simply spoofing the source address.
Although it may be easy for an attacker to send packets this
way, receiving a response is more difficult.
Even well designed flow entries can still be vulnerable to
attack. The ’Freeloading’ attack [28] uses existing flow entries
designed for a host to transport traffic for a different host. This
attack requires a neighbour’s communication to be sniffed by
the attacker. The attacker then uses information gathered from
sniffing to craft packets which then piggyback on existing flow
entries. This type of attack enables an attacker to use existing
flow entries, even when specific matching criteria is used.
C. Access Control and Firewalling
Proactive: Dynamic network conditions may introduce issues
if the placement of proactive security flow entries is based on
host attachment points. Networks with frequently changing at-
tachment points (e.g. a Wireless Local Area Network (WLAN)
in a campus setting) would cause proactive flow entries to
change location as the host moves. Rule violating traffic could
occur during the delay between learning the new attachment
point and installing the flow entry.
Reactive: A strictly reactive security mechanism requires
information to react to. A centralised reactive system can-
not assess if network traffic violates rules unless it receives
samples associated with that traffic (i.e. packet in messages).
In an environment where malware is a constant risk, rules
created by a TIMS would be vital in protecting systems from
the latest threat. However, the ability of this system could be
undermined if traffic samples were not provided to a reactive
security mechanism.
Consider an SDN which has a reactive firewall in place. This
firewall has a rule-set which is updated frequently by a TIMS,
which receives data from both public and private sources. In
this network, a host becomes infected with malware. The aim
of this malware is to allow remote access to the host. Once
the malware has infected the host, it will phone home to a
Command and Control (C&C) server. In this scenario, the ideal
situation is that the TIMS has learned of this malware before
the host contacts the C&C server, allowing the firewall to
deploy flow entries in response to the first packet in message
to prevent communication with the C&C server.
However, if the infected host was to connect to the C&C
server before the TIMS learns about the malware, and was
to maintain that connection, the firewall would not have an
opportunity to deploy the defensive flow entries. As long as
that flow remains in place, the firewall would not observe any
traffic samples, and could therefore not prevent the infected
host from communicating with the C&C server.
V. EXPLOITING TH E VULNERABILITIES
In this section, several of the vulnerabilities presented in
section IV are exploited to implement an ARP cache poisoning
and a MITM attack in an SDN. The ARP cache poisoning
attack is extended to formulate two new attacks, the phantom
host scan and the phantom storm, which take advantage of the
SDN implementation.
A. Data Plane ARP Cache Poisoning
Goal: The goal of the attack is to poison the ARP cache of a
host in the data plane, without poisoning the controller’s view
of the topology.
Assumptions: That the controller installs flows which can
handle ARP traffic, and that these flows enable piggybacking.
Description: A host’s ARP cache maintains an IP to MAC
address mapping which the host then uses to communicate
with other hosts. ARP cache poisoning results in an IP address
in a host’s ARP cache being mapped to a MAC address for
a different host. By implementing this attack in the proposed
Fig. 1. Data plane ARP cache poisoning.
way, any ARP cache poisoning prevention mechanisms (such
as those discussed in section II) existing on the control plane
will not prevent the attack.
The stages of the attack (shown in Fig. 1) are as follows:
1-6) The attacker first sends a legitimate gratuitous ARP to
a host. The controller implements a flow to allow this
message to traverse the network to the target host.
7) The attacker now creates a new gratuitous ARP packet.
This packet maintains details needed to traverse the flow
which now exists in the network, but also contains a
modified ARP header. The source IP and hardware source
address are changed in order to poison the recipient’s
ARP cache. The attacker sends this packet to the target.
8-9) The crafted packet piggybacks on the existing flow, which
conceals the traffic from the controller. The packet then
reaches the host and poisons its ARP cache with the
details in the modified ARP header.
An attacker could perform this attack to install an entry in
a target’s ARP cache for a completely new host. To do this,
the attacker would first have to send a packet to a target with
a spoofed IP address. By doing this with an IP address the
target has not encountered before, an incomplete ARP cache
entry will be created for that new IP address. The attacker can
now carry out the ARP cache poisoning attack to complete
that entry with a MAC address. This would result in a brand
new host existing in the target’s ARP cache.
B. Man in the Middle
Goal: The aim of this attack is to have two hosts on the
network communicate with each other via an attacker.
Assumptions: That the data plane ARP cache poisoning attack
is possible, and the controller’s forwarding is performed at
layer 2 only.
Description: Once an ARP cache poisoning attack can be
performed, a Man in the Middle (MITM) attack is also
possible. A MITM attack is a well-known attack where an
attacker aims to act as a connection between two network
nodes. When performing this attack, an attacker may view,
modify, or stop any traffic between the nodes. This introduces
Fig. 2. Perceived and actual connection during MITM attack.
the possibility to perform additional attacks such as SSL
stripping [29] and session hijacking [30].
Consider a network with three hosts: host A, B, and the
attacker. The attacker must perform the data plane ARP cache
poisoning attack against both host A and B. Using the attack,
the attacker maps their MAC address to host A’s IP address in
host B’s ARP cache, and vice-versa. Once this has been done,
when host A attempts to contact host B, the traffic will instead
be forwarded to the attacker. The attacker can then relay all
traffic between host A and B to hide their presence. Host A
and host B will then believe that they have a direct connection
to one another. This perceived connection is shown in Fig. 2.
The controller will observe a connection between host A and
the attacker, and host B and the attacker. However, because this
attack remains on the data plane, there should be no suspicion
that a MITM attack is taking place.
C. Phantom Host Scan
Goal: The phantom host scan aims to perform port scanning
of a host in the network, even if certain ACL or firewall rules
are in place.
Assumptions: That the data plane ARP cache poisoning attack
is possible, layer 2 forwarding is performed, and that the
controller floods packets for destination hosts with an unknown
attachment point.
Description: The phantom host scan will use a Transport
Control Protocol (TCP) SYN scan [31] to perform the port
scanning. In this type of port scan, the attacker sends a TCP
SYN to a target port on a host. The target host will respond to
this SYN with a SYN ACK if the port is open, and a TCP RST
if the port is closed. By observing this response, the attacker
can learn whether or not the port is open.
To perform the attack, the attacker must insert a new host in
a target’s ARP cache. This host (the phantom host) should use
an IP and MAC address which are not in use in the network.
By doing this, traffic generated for the phantom host should
not match any existing security application rules, and the
controller should flood any packets destined for the phantom
host, due to the phantom host having no attachment point on
Fig. 3. Phantom host scan after initial ARP cache poisoning.
the network. The port scan is outlined in Fig. 3. The following
details the steps of this scan:
1) The attacker has already inserted the phantom host into
the targets ARP cache by performing the ARP cache
poisoning attack. The attacker sends a crafted TCP SYN
packet to the target for a specific port. The source IP of
this packet being the IP address of the phantom host.
2-5) The controller receives the packet in message associated
with the attacker’s packet. It will use the destination MAC
address to create a flow in the network to allow the TCP
SYN to reach the target.
6-7) The target receives the SYN and replies with a SYN ACK
or RST depending on whether or not the port is open. The
attacker’s SYN had the source IP of the phantom host, so
the target will respond using this IP and the associated
MAC address in its ARP cache.
8-10) The controller receives the target’s response. The con-
troller will not know the attachment point for the phantom
host, as the host does not exist in the network, and will
instruct the switches in the network to flood the packet
out all ports except the ingress port.
11) The attacker receives the response by observing traffic on
the relevant network interface.
This attack has the potential to bypass IP based access
control and firewall rules due to the IP spoofing which occurs
during the attack. However, the attacker must still send some
traffic directly to the target using their own MAC address, so
firewall rules which specify the attacker’s MAC address may
thwart the attack.
A slight variation on this attack is that the attacker enters
their own MAC address as the MAC for the Phantom Host.
This would prevent the flooding of the packets from occurring,
while still allowing circumvention of IP based ACL and
firewall rules. However, this is at the expense of adding
additional exposure of the source of the scan.
D. Phantom Storm
Goal: In this attack, an attacker aims to cause the controller to
flood the network with packets by having all the other hosts in
the network send traffic to a host which doesn’t exist, resulting
in a DDoS attack.
Assumptions: That the data plane ARP cache poisoning attack
is possible, layer 2 forwarding is performed, and that the
controller floods packets for hosts with an unknown attachment
point.
Description: The novelty of this attack is not the denial of
service caused to network components, but the ability for a
single attacker to force other hosts in the network to participate
in a DDoS attack. The steps of the attack are as follows:
1) The attacker first uses the data plane ARP cache poi-
soning attack to introduce a phantom host into the ARP
cache of every other host on the network.
2) The attacker then sends a crafted packet to each victim
host in order to induce a response destined for the
phantom host. The attacker does this by spoofing the
source IP in the crafted packet as the IP address of the
phantom.
3) When each victim host sends a response to the phan-
tom host, the controller will receive these responses as
packet in messages. The controller will not know the
attachment point for the phantom host and will flood each
packet throughout the network.
4) The attacker continues to send crafted packets to each
host on the network, resulting in the controller continuing
to flood packets throughout the network.
This DoS attack has a number of potential points of impact:
•Switch Packet Buffer: When a switch receives a new
packet with no matching flow rules, it will forward the
packet to the controller. When this packet in message is
sent to the controller, the switch will store the packet in a
buffer until it receives instructions as to what to do with
it. A large number of packets sent by an attacker could
therefore lead to a buffer saturation attack [15].
•Control Plane: Each packet in message received by the
controller must be processed. An attacker can perform
a control plane resource consumption attack [12] by
causing a large number of these messages to be sent to
a controller over a short period of time.
•Network Bandwidth: By causing a packet to be flooded
throughout the network, a portion of network bandwidth
will be consumed. The more packets which are flooded,
the greater the consumption of that bandwidth.
•Hosts: By performing this attack using TCP and directing
it towards open ports on the victim hosts, a TCP SYN
flood [32] could be possible if the victim is susceptible
to it. The attacker would send TCP SYN packets to the
victim hosts in the network, who would respond with
SYN ACKs. The response would be directed towards the
phantom host and would therefore never be responded to.
Using TCP, an attacker could leverage TCP’s retransmission
system to increase the number of packets sent from the
victim hosts. On receipt of a TCP SYN on an open port, the
victim host would send a TCP SYN ACK and follow it up
with retransmissions after a period of time if no response
is received [33]. The number of retransmissions (R) and
time between them is operating system dependent. When an
attacker sends a packet to a closed port, each packet sent by
the attacker will result in a single packet being sent to the
controller from the victim. However, if an open port is used,
a single packet from an attacker will result in 1+R packet in
messages (the initial response plus the retransmissions) being
sent to the controller. Therefore, 1+R packets will be flooded
by each switch in the network. The total number of packet in
messages to reach the controller and thus be flooded through
the network would be H*(1+R) where His the number of
victim hosts being used by the attacker, with the attacker
sending a single packet to each, resulting in H*1 packets sent
by the attacker. As long as the TCP source port is changed
for each packet sent by the attacker, new retransmissions will
occur.
VI. ATTACK ING THE FLOODLIGHT IMPLEMENTATION
In this section the attacks are mounted against the Floodlight
controller (version 1.1). The attacks are performed on the
default build of Floodlight which uses a basic forwarding
application which responds in a reactive fashion and performs
layer 2 forwarding of packets. A reactive stateless firewall is
available by default along with a proactive IP based ACL.
Two networks are used when testing the attacks. One
network consists of five Virtual Machines (VMs); a con-
troller running Floodlight, two OpenVSwitch switches, and
two hosts. The second network uses Mininet [34] with the
Floodlight controller.
A. Data Plane ARP Cache Poisoning
Floodlight installs a flow in the network to allow ARP
replies, including gratuitous ARP messages, to traverse the
network. The flow entries installed will match a packet which
contains an ARP header and which has source and destination
MAC addresses equal to those specified in the entry. This
allows an attacker to send a gratuitous ARP message with
modified source IP and hardware addresses.
First, a legitimate gratuitous ARP is sent for the attacking
host to the target host. This causes Floodlight to implement
a flow allowing the ARP message to be forwarded. Once this
flow is in place, a gratuitous ARP packet is crafted using the
scapy python library [35]. This packet contains the necessary
address modifications.
By piggybacking this malicious gratuitous ARP upon the
existing flow, the host discovery mechanism in Floodlight does
not observe it. This allows the poisoning to occur in a stealthy
fashion. Floodlight’s REST interface is used to periodically
check the known devices in the network to confirm this.
B. Man in the Middle
The data plane ARP cache poisoning attack is used against
two hosts in the network. The hardware source address in the
ARP header is modified to be the attacker’s MAC address. The
source IP is set depending on which host is being targeted.
Host A’s IP is used when targeting host B and vice-versa. IP
forwarding is enabled on the attacking host, which then relays
traffic between the two victim hosts. This allowed the attacker
access to all traffic travelling between the hosts.
C. Phantom Host Scan
This attack is implemented based on the steps outlined for
this attack in the previous section. The data plane ARP cache
poisoning attack is performed with the additional step to allow
a completely new IP and MAC address to be inserted into the
target’s ARP cache. This attack was performed successfully
without the Floodlight controller detecting the phantom host
as an additional device on the network.
To test the attack’s ability to circumvent Floodlight’s
access control feature, two rules are implemented. ACL
rules are supplied to Floodlight in JavaScript Object
Notation (JSON) [36] format via the Northbound
interface. The first rule, {”src-ip”:”192.0.2.3/32”,”dst-
ip”:”192.0.2.0/24”,”action”:”deny”}, prevents IP communi-
cation from host 192.0.2.3 to any host on the 192.0.2.0/24
network. The second rule, {”src-ip”:”192.0.2.1/32”,”dst-
ip”:”192.0.2.3/32”,”action”:”deny”}, prevents host 192.0.2.1
from communicating with host 192.0.2.3. Due to the
IP spoofing during the attack, both of these rules were
successfully circumvented. The circumvention is possible
because the layer 3 ACL does not prevent ARP traffic, the
TCP SYN used to probe the port has a spoofed source IP
address, and the result of the probe is destined to the phantom
host’s address, which will match neither of those rules.
D. Phantom Storm
The phantom storm attack was implemented against a
Floodlight controlled Mininet network.
Test Environment: To gain an initial understanding of the
impact of this attack, tests were performed using Mininet in
a virtual machine. The Virtual Machine (VM) used Ubuntu
14.04.03 with 4GB of Ram and a single core CPU. The CPU
on the host system is an Intel i5-5300U @ 2.30GHz with
two cores and four threads. The Mininet network consisted of
a number of hosts which grew with each test, connected by
two interconnected switches. Both switches were connected
to the Floodlight controller. When building the network, the
hosts were evenly distributed between the switches (i.e. For 20
hosts, 10 hosts were connected to each switch). The attacker
was then added to the first switch as an additional host.
To measure the impact of the attack both the Ping utility
and IPerf were used. Using IPerf, the throughput between
two points in the network was measured. Using Ping, the
Round Trip Time (RTT) of traffic in the network was observed,
with and without the controller’s response time taken into
consideration. To gain an understanding of the controller’s
response time, a delay was applied when using the Ping utility
to ensure that each new packet will result in a table miss.
After initially collating the results of the attack it was hy-
pothesised that as both Mininet and Floodlight were executed
on the same VM they were competing for resources. This
would impact the ability for both Mininet and Floodlight to
10 20 30 40 50
Hosts
0
5
10
15
20
25
Throughput (Gbits/sec)
Network throughput over single switch
Benchmark
During attack
Fig. 4. Throughput between two hosts over one switch.
handle traffic and thus cause the effects of the phantom storm
attack to appear more severe than would be the case with
greater available processing capability.
To maximize the performance of Mininet and Floodlight, a
second series of tests with a modified test environment were
performed. In this environment, the VM upon which Mininet
was running was given an additional CPU core to match the
host machine. Floodlight was placed on a second VM.
Results: Figures 4 and 5 show the impact of the attack on the
network throughput, over one and two switches respectively.
The results are consistent as the flooding should be equal
on both switches. They show that as the number of coerced
hosts increases the amount of flooded packets increases too,
occupying more bandwidth and reducing the throughput. The
data describing the network throughput under attack was fitted
using exponential regression and produced the predictions
C1= 25.0244e−0.03485N(1)
C2= 19.253e−0.025456N(2)
with sample adjusted coefficient of determination 0.98 and
0.997 respectively, where Nis the number of hosts and eis
Euler’s constant.
10 20 30 40 50
Hosts
0
5
10
15
20
25
Throughput (Gbits/sec)
Network throughput over two switches
Benchmark
During attack
Fig. 5. Throughput between two hosts over two switches.
10 20 30 40 50
Hosts
−0.4
−0.2
0.0
0.2
0.4
0.6
0.8
Mean RTT
RTT for traffic traversing existing flows (First to last host)
Benchmark
During attack
Fig. 6. RTT for traffic traversing an existing flow.
Fig. 6 shows the RTT measured for traffic traversing an
existing flow in the network. It can be observed that the mean
values of the RTT with and without the attack are roughly the
same. However, while the standard deviation without the attack
is constant, the attack causes it to increase with the number of
hosts. The standard deviation in the RTT value represents the
jitter. The results can be explained by the increased congestion
caused by the attack, which decreases the link quality and
therefore increases the jitter. The variation in RTT in seconds,
V, with a sample adjusted coefficient of determination of
0.974, may be given by
V= 0.12867e0.024979N(3)
However this cannot be extrapolated for N→ ∞ as the RTT
jitter is bounded but is sufficient for the values of Nanalysed
in this work. The impact of the attack on the setup time for
a new flow is shown in Fig. 7 by the RTT, T, for packets
in seconds which caused a table miss on the switch. This
increases during the attack according to
T= 2.1629e0.02843N(4)
with a sample adjusted coefficient of determination of 0.998,
as the controller’s performance is affected by the large number
10 20 30 40 50
Hosts
−30
−20
−10
0
10
20
30
40
Mean RTT
RTT for initial packets (First to last host)
Benchmark
During attack
Fig. 7. RTT for packets with no flow.
of packets arriving from each victim host in the network.
Equation (1), (2), (3) and (4) predict the 1 switch throughput,
2 switch throughput, RTT jitter and RTT to be 2.38 Gbps, 5.39
Gbps, 0.4486 seconds and 8.962 seconds respectively. These
values are in agreement with the measured values.
VII. ACKN OWLEDGEMENTS
This work is funded by the Cork Institute of Technology
Risam scholarship scheme.
VIII. CONCLUSION
In this work, vulnerabilities introduced by the implementa-
tion of SDN controller functions were outlined. By exploiting
several of these vulnerabilities, a new method to perform ARP
cache poisoning and Man in the Middle attacks in SDN have
been presented. Two new attacks utilising this method of ARP
spoofing have been demonstrated and analysed. These attacks
have been successfully executed against a contemporary con-
trol platform validating them as a threat to SDN networks.
From the regressive fitting functions applied to the data
generated in implementing the phantom storm in a constrained
topology it can be predicted to increase in severity as the
number of hosts is increased. Future developments in this
work will included the verification of the DDoS attack against
a physical topology, and implementation of this attack on a
larger network topology, quantifying the effect of this attack
when more switches exist in the network, and developing a
function that predicts the severity of the attack for a given
topology.
REFERENCES
[1] N. McKeown, “Software-defined networking,” INFOCOM keynote talk,
vol. 17, no. 2, pp. 30–32, 2009.
[2] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson,
J. Rexford, S. Shenker, and J. Turner, “OpenFlow: enabling innovation
in campus networks,” SIGCOMM Computer Communication Review,
vol. 38, no. 2, pp. 69–74, 2008.
[3] Project Floodlight. Floodlight open SDN controller. [Accessed:
09-03-2016]. [Online]. Available: http://projectfloodlight.org/floodlight/
[4] K. Benton, L. J. Camp, and C. Small, “OpenFlow vulnerability assess-
ment,” in Proc.of the second SIGCOMM workshop on Hot topics in
software defined networking. ACM, 2013, pp. 151–152.
[5] A. Akhunzada, E. Ahmed, A. Gani, M. Khan, M. Imran, and S. Guizani,
“Securing software defined networks: taxonomy, requirements, and open
issues,” IEEE Communications Magazine, vol. 53, no. 4, pp. 36–44,
2015.
[6] S. Scott-Hayward, G. O’Callaghan, and S. Sezer, “SDN security: A
survey,” in SDN For Future Networks and Services (SDN4FNS). IEEE,
2013, pp. 1–7.
[7] I. Ahmad, S. Namal, M. Ylianttila, and A. Gurtov, “Security in software
defined networks: a survey,” IEEE Communications Surveys & Tutorials,
vol. 17, no. 4, pp. 2317–2346, 2015.
[8] D. Kreutz, F. Ramos, and P. Verissimo, “Towards secure and dependable
software-defined networks,” in Proc. of the second SIGCOMM workshop
on Hot topics in software defined networking. ACM, 2013, pp. 55–60.
[9] S. Scott-Hayward, S. Natarajan, and S. Sezer, “A survey of security in
software defined networks,” 2015.
[10] A. Shostack, “Experiences threat modeling at microsoft,” in Modeling
Security Workshop. Dept. of Computing, Lancaster University, UK,
2008.
[11] R. Kloti, V. Kotronis, and P. Smith, “OpenFlow: A security analysis,”
in 21st International Conference on Network Protocols (ICNP). IEEE,
2013, pp. 1–6.
[12] S. Shin and G. Gu, “Attacking software-defined networks: A first
feasibility study,” in Proc. of the second SIGCOMM workshop on Hot
topics in software defined networking. ACM, 2013, pp. 165–166.
[13] S. Shin, V. Yegneswaran, P. Porras, and G. Gu, “Avant-guard: Scalable
and vigilant switch flow management in software-defined networks,” in
Proc. of the 2013 SIGSAC conference on Computer & communications
security. ACM, 2013, pp. 413–424.
[14] H. Wang, L. Xu, and G. Gu, “FloodGuard: a dos attack prevention
extension in software-defined networks,” in 45th Annual IEEE/IFIP
International Conference on Dependable Systems and Networks (DSN).
IEEE, 2015, pp. 239–250.
[15] M. Ambrosin, M. Conti, F. De Gaspari, and R. Poovendran, “Lineswitch:
Efficiently managing switch flow in software-defined networking while
effectively tackling dos attacks,” in Proc. of the 10th Symposium on
Information, Computer and Communications Security. ACM, 2015,
pp. 639–644.
[16] M. Dhawan, R. Poddar, K. Mahajan, and V. Mann, “SPHINX: Detecting
Security Attacks in Software-Defined Networks.” in NDSS, 2015.
[17] S. Whalen. (2001, April) An introduction to arp spoofing. [Accessed:
10-02-2016]. [Online]. Available: online
[18] S. Hong, L. Xu, H. Wang, and G. Gu, “Poisoning Network Visibility
in Software-Defined Networks: New Attacks and Countermeasures.” in
NDSS, 2015.
[19] T. T. Bui, M. Hidell, and T. Aura, “Analysis of Topology Poisoning
Attacks in Software-Defined Networking,” Master’s thesis, KTH Royal
Institute of Technology, 2015.
[20] N. Solomon, “Mitigating Layer 2 Attacks: Re-Thinking the Division of
Labor,” Master’s thesis, School of Computer Science, The Interdisci-
plinary Center, Herzliya, 2015.
[21] T. Alharbi, M. Portmann, and F. Pakzad, “The (In) Security of Topology
Discovery in Software Defined Networks,” in 40th Conference on Local
Computer Networks (LCN). IEEE, 2015, pp. 502–505.
[22] M. Z. Masoud, Y. Jaradat, and I. Jannoud, “On preventing ARP
poisoning attack utilizing Software Defined Network (SDN) paradigm,”
in Jordan Conference on Applied Electrical Engineering and Computing
Technologies (AEECT). IEEE, 2015, pp. 1–5.
[23] OpenDayLight Project. OpenDayLight Layer 2 Switch Documentation.
[Accessed: 18-02-2016]. [Online]. Available: online
[24] Project Floodlight. (2015) Floodlight Forwarding Application
Documentation. [Accessed: 17-02-2016]. [Online]. Available: online
[25] NoxRepo. Pox Layer 2 Learning Switch. [Accessed: 16-02-2016].
[Online]. Available: online
[26] HP. (2015) HP VAN SDN Controller Software. [Accessed: 18-02-2016].
[Online]. Available: online
[27] J. Ancieta and C. Rothenberg, “IntelFlow: Towards adding Cyber Threat
Intelligence to Software Defined Networks,” 2015.
[28] Y. Park, S. Y. Chang, and L. M. Krishnamurthy, “Watermarking for
detecting freeloader misbehavior in software-defined networks,” in 2016
International Conference on Computing, Networking and Communica-
tions (ICNC), Feb 2016, pp. 1–6.
[29] M. Marlinspike, “New Tricks For Defeating SSL In Practice,” Blackhat,
2009.
[30] S. Kapoor. (2006) Session Hijacking Exploiting TCP, UDP and HTTP
Sessions. [Accessed: 18-02-2016]. [Online]. Available: online
[31] G. Lyon, “The Art of Port Scanning,” vol. 7, no. 51, 1997.
[32] daemon9, route, and infinity, “Project Neptune,” vol. 7, no. 48, July
1996.
[33] J. Postel, “DoD standard transmission control protocol,” 1980.
[34] B. Lantz, B. Heller, and N. McKeown, “A network in a laptop:
rapid prototyping for software-defined networks,” in Proc. of the 9th
SIGCOMM Workshop on Hot Topics in Networks. ACM, 2010, p. 19.
[35] Scapy. [Accessed: 18-02-2016]. [Online]. Available:
http://secdev.org/projects/scapy/
[36] D. Crockford, “The application/json media type for javascript object
notation (JSON),” 2006.
