Content uploaded by Dylan Smyth
Author content
All content in this area was uploaded by Dylan Smyth on Sep 25, 2017
Content may be subject to copyright.
Detecting Link Fabrication Attacks
in Software-Defined Networks
Dylan Smyth, Sean McSweeney, Donna O’Shea, Victor Cionca
Nimbus Centre, Cork Institute of Technology
{1}@mycit.ie
{2, 3, 4}@cit.ie
Abstract—The Link Fabrication Attack (LFA) in Software-
Defined Networking (SDN) involves an attacker forging a new
link in the network, providing them with control over traffic
which traverses the new malicious link. One method to perform
this attack is through the relaying of topology discovery traffic,
for which no comprehensive defense exists. This paper proposes
to detect this attack using statistical analysis of link latencies. A
novel solution has been designed requiring a new link to undergo
a vetting period during which its latency is evaluated. This is
subsequently compared against a baseline model for benign links.
This solution is assessed against several implementations of the
relay-type LFA. The trade-off between the length of the vetting
period and the accuracy of the attack detection is analyzed. The
results show how user-space relaying causes a sizable increase in
latency which can be detected with a low number of samples,
while relaying using kernel-space forwarding requires larger
samples sets in order to be discovered.
Index Terms—SDN, SDN Security, Link Fabrication.
I. INTRODUCTION
Software-Defined Networking (SDN) is a promising ad-
vance in networking technology which involves the decoupling
of the control and data planes of networking devices [1].
Forwarding devices enforce decisions made by a controller
which has a centralized view and understanding of the network
state. Although SDN has the potential to solve many problems
faced in modern networks, its robustness to attack must be
properly investigated.
Among the threats faced by SDNs, the Link Fabrication
Attack (LFA) [2] is one which involves poisoning the con-
troller’s perception of the network topology by forging a new
network link, leaving traffic which traverses this link exposed
to interception and manipulation. This is done by the attacker
either generating, replaying, or relaying topology discovery
traffic and sending it to a network switch. A fabricated link
will result in one of two scenarios; either the new link is a
’black hole’ and traffic forwarded over the link stops at the
attackers machine, or the attacker creates a tunnel between two
SDN switches allowing traffic to be successfully forwarded
over the malicious link. This paper will focus on the latter
scenario.
This paper is the first to detect relay-type LFAs in SDN
through statistical testing of link latency distributions. The use
of a vetting period for new links is proposed, during which the
link is not available for traffic forwarding. When a link is being
vetted, latency samples are collected using the controller’s
link discovery mechanism. The statistical distribution of the
gathered latency samples is then compared against a baseline
distribution for benign links. To assess this solution, the
delay introduced by various forms of the relay-type LFA is
first examined. The proposed detection method is then tested
through simulations using latency values collected from a
testbed. The effect of vetting period length and acceptance
threshold on attack detection rate are explored. Counter-attacks
which could be used to overcome a latency based detection
method and how these could be mitigated are also explored.
The sections of the paper are as follows. First, an overview
and practical implementations of the relay-type LFA are
presented, including the proposed detection method. The
latency of fabricated links for several attack scenarios is
then analyzed and the proposed solution is tested using
data gathered from this analysis. Finally, results, discussion,
related work, and conclusions are given.
II. TH E LINK FABRICATION ATTACK
In this section, the relay-type LFA is described. Several
practical attack scenarios are presented which make use of
kernel-space and user-space forwarding for traffic relaying.
A. Attack Description
The Link Fabrication Attack aims to deceive the SDN
controller into believing a direct inter-switch link exists when
it does not. Many SDN controllers learn connections between
switches by having them flood Link Layer Discovery Protocol
(LLDP) frames out all ports [2]. Neighboring switches will
observe flooded LLDP traffic and send it to the controller,
allowing it to understand that a link exists between them.
This link discovery process allows the network topology and
link latencies to be discovered automatically reducing the
configuration burden on administrators, and making it attrac-
tive for SDN deployments. Contemporary controllers such as
OpenDayLight 1, Floodlight 2, ONOS 3, and HP VAN 4make
use of this link discovery technique.
An attacker can abuse this method of link discovery by
generating, replaying, or relaying LLDP frames [2]. However,
1https://www.opendaylight.org
2http://projectfloodlight.org/floodlight
3http://onosproject.org
4https://www.hpe.com/us/en/networking/sdn.html
Fig. 1: Attack scenarios considered in this paper
LLDP frame authentication and the use of single-use tokens
can prevent generation and replay attacks [2], [3]. This paper
focuses on detecting the relay-type attack. An attacker with
a connection to multiple SDN switches can observe flooded
LLDP frames and relay the frame from one switch to another.
Once this relaying occurs, the controller will believe that a
direct link exists between both switches.
The danger of this attack is that any traffic forwarded over
the fabricated link can be intercepted and manipulated by the
attacker, providing man in the middle (MitM) capabilities for
which there currently is no comprehensive countermeasure [4].
The result of these attacks could be maximized by fabricating a
link which could be considered an attractive route (e.g. during
the attack a route exists through the network with a lower hop
count than the genuine route). This could be done by targeting
switches in different parts of the network, or fabricating a
direct link between the network gateway and a network switch
adjacent to a target host or server. The risk of this attack is
further discussed in section V-C.
An attacker can mount an LFA with as little as one
malicious host. Directly connected to two switches, the host
could transparently forward traffic by bridging the two network
interfaces (Scenario 1 in Fig. 1). However, physical restric-
tions, such as distance, apply to having direct connections to
two switches. By using two malicious hosts that communicate
through an out-of-band wireless channel, the attacker can avoid
some of these physical restrictions and fabricate links between
SDN switches which are a greater distance apart. The wireless
channel can either be a direct ad-hoc link (Scenario 2 in Fig. 1)
or using an infrastructure through, for example, wireless access
points or routers (Scenario 3 in Fig. 1). The latter can cover
more distance and can therefore be used to fabricate links
on switches in different parts of a building or campus. The
forwarding of layer 2 SDN traffic over the out-of-band wireless
channel requires a General Routing Encapsulation (GRE)
tunnel [5].
Depending on the goals of the attack, the relayed traffic
can be transparently forwarded or filtered using user-space
processing (e.g. using the Python Scapy library 5). User-space
traffic processing allows for more functionality (fine-grained
traffic filtering and alteration), but also increases the latency,
as will be shown in Section III.
B. Proposed Detection Method
In this section we detail our proposed defense against link
fabrication in SDN.
1) Opportunities: The relay-type LFA requires an attacker
to forward traffic over at least one layer 2 hop. The hop count,
as well as the traffic relaying method, will increase the latency
for the relayed traffic. This latency will depend entirely on the
relay channel and relay method for the attack.
The topology discovery mechanism, LLDP, used by SDN
controllers is capable of discovering network link latency by
observing the time taken for an LLDP frame to be returned
from the network after it has been flooded. By leveraging this
central view of network metrics, it is possible for the controller
to observe variations in network link latencies. Fabricated
links could then be detected by gathering link latencies for
links and applying statistical tests using the collected values
to determine whether or not a link fits the profile of a benign
network link. This collection and analysis can be implemented
as an extension to the controller’s internal link discovery
mechanism, or as an external network application. Moreover,
using link latencies as a means of detecting fabricated links
would require no extension to the LLDP protocol and no
additional configuration of network switches.
2) Challenges: As with many security mechanisms, false
positives and negatives need to be considered. In this case,
false positives are benign links detected as malicious links
and false negatives are fabricated links detected as benign. In
the proposed defense, the false positive and negative rates will
depend on the benign link latency distribution, the tested link
distribution, and the number of observed samples (n).
The detection method considered in this paper uses statis-
tical analysis to verify if a new link fits the distribution of a
benign link. This requires that latency samples from known
benign links are stored as a reference set. Collection of this
reference set could either be achieved dynamically, where a
baseline is continuously updated from a set of known and
trusted links, or by maintaining a static reference sample set.
Challenges arise for both of these methods in relation to
ensuring that the reference set is accurate, as discussed below.
A dynamic baseline could be subject to manipulation. The
population mean and standard deviation of the link latencies is
subject to influence from the network traffic level. Congestion
increases the population mean of the latency, and can thus
increase the rate of false negative classifications for a given
number of samples (n). An attacker could leverage this to
manipulate a dynamic baseline reference set and prevent detec-
tion of their fabricated link. This congestion could be caused
by a Denial of Service (DoS) attack such as the Phantom
Storm [6]. This problem can be avoided by using a static
5http://www.secdev.org/projects/scapy/
Fig. 2: Flow of vetting and testing of a new link
baseline reference set, which can be collected in advance,
at network initialization, using a set of known benign links.
However, to achieve an accurate result when testing against
this baseline reference set the latencies collected for new and
benign links must also be free of influence from network
traffic. Furthermore, testing a new link while allowing traffic
to traverse it would place the network under risk of attack for
a duration equal to the testing period.
3) Solution: An overview of the solution is shown in Fig. 2.
To ensure the latency measurements for a new link are unaf-
fected by traffic, new links are subjected to a vetting period
before being considered for use by the network controller.
During this vetting period only link discovery traffic may
traverse the link. Latency samples are collected, and the vetting
period ends once a number of samples have been captured.
The number of latency samples which must be collected
defines the length of the vetting period. The population mean
of the collected samples is then compared to the baseline
reference set, resulting in a p-value (between 0 and 1) which
indicates the probability that the new link is a benign link.
If this p-value is lower than a threshold percentage, we can
infer that the new link is a fabricated link and reject it.
This vetting period ensures that collected latency samples are
uninfluenced by network traffic. Moreover, it functions as an
isolation mechanism, making sure that a fabricated link does
not have the opportunity to affect the network. The vetting
period imposes a delay before a new link becomes available,
determined by the vetting period length and the frequency
of sample collection. This leads to a trade-off between the
accuracy of attack detection and the network usability, that
will be explored in section IV.
III. ATTACK ANALYS IS
The LFA variants described in Section II-A are implemented
on a testbed and the impact of the attacks on the latency of
the resulting fabricated links is measured. In this section these
values are compared visually to the measured latency of benign
links. The collected data is then used in the next section for
statistical detection of the attack.
A. Testbed Design
The testbed used to perform analysis consisted of a Flood-
light controller running on an Odroid U3 and two Open-
VSwitch (OVS) switches running on Alix 2d3 computers.
A Raspberry Pi (RPi) Model B is used for each attacking
host. For the single-host attacks, an RPi is connected to two
switches using cables. A second Ethernet port is provided
for the RPi using an Ethernet to USB adapter. For attacks
using user-space processing, Python with the Scapy library is
used to create a traffic relaying script. While faster user-space
packet processing techniques are available, Python Scapy is
selected as an example due to it’s sophisticated and powerful
networking capability [7]. Future work will investigate other
user-space forwarding options, as outlined in section V-E. For
Multi-host attacks Wi-Pi WiFi adapters are used to create the
relay channel between the RPis. For these attacks, the best-
case scenario is considered where wireless components are
placed within optimal range of each other, and thus latency
is minimized. To capture the latencies, the LinkDiscovery-
Manager class in Floodlight was modified to log the observed
link latencies in milliseconds (ms). 2500 latency samples were
collected from benign network links to create a benign baseline
reference set. Each attack method was implemented and 2500
latency samples were also collected for the resulting fabricated
links in each case.
B. Attack latency measurements
Upon reviewing the comparisons in network latency for a
benign and fabricated link, some attack methods are shown to
result in a significantly different link latency while others do
not. Fig. 3 compares the latency distribution measured over
a single-host wired bridge with the benign link, showing no
significant observable difference since the same networking
technique is used in OVS to relay traffic. Fig. 4 and 5 show
significant delay caused by the overhead of Python Scapy
when used for traffic relaying, with Fig. 5 showing increased
latency due to the wireless relay channel. Fig. 6 and 7 show
the latency when a tunneled wireless relay channel is used
during the attack. The wireless link reduces the available data
rate and the wireless router introduced in the attack in Fig. 7
1.0 1.5 2.0 2.5 3.0
Latency (ms)
0
200
400
600
800
1000
1200
Frequency
Ben. Link µ
Fabr. Link µ
Ben. Link
Fabr. Link
Fig. 3: Single-host cable bridging latency.
0 20 40 60 80 100
Latency (ms)
0
500
1000
1500
2000
2500
Frequency
Ben. Link µ
Fabr. Link µ
Ben. Link
Fabr. Link
Fig. 4: Single-host Python relay latency.
requires relayed traffic to traverse an additional hop, increasing
the link latency.
What can be determined from these latency measurements is
that the proposed detection method will be capable of detecting
fabricated links which require user-space traffic forwarding.
Relay methods using wireless bridging and tunneling appear
as though they would be more difficult to detect. However, by
increasing the number of samples used to form the benign link
baseline, a more accurate baseline could be defined, potentially
resulting in a more obvious difference between the latency
of the baseline and fabricated link. The single-host wired
interface bridge scenario shows that no meaningful difference
in network latency exists, which would make it problematic
to detect using statistical methods.
IV. DET EC TI NG T HE ATTAC K
In this section the proposed defense is evaluated using
simulations and results are provided.
A. Methodology
In this section, the benign link baseline distribution is
denoted as βand the new link latency distribution is denoted
as α. The detection technique proposed in this paper is based
on statistical hypothesis testing, requiring a p-value to be
calculated which is used to classify a new link as benign or
fabricated. To calculate this p-value, the mean of αis first
computed. This mean can then be tested against βto get a
z-score. A z-score indicates the number of standard deviations
0 20 40 60 80 100 120 140 160
Latency (ms)
0
500
1000
1500
2000
2500
Frequency
Ben. Link µ
Fabr. Link µ
Ben. Link
Fabr. Link
Fig. 5: Multi-host Python relay via ad-hoc latency.
0 2 4 6 8 10 12
Latency (ms)
0
200
400
600
800
1000
1200
Frequency
Ben. Link µ
Fabr. Link µ
Ben. Link
Fabr. Link
Fig. 6: Multi-host wireless tunnel via ad-hoc latency.
a value is away from the mean of a distribution. In terms of
this paper, the z-score will show the number of β’s standard
deviations α’s mean is from β’s mean, showing the magnitude
of the difference between the benign link and the tested link.
The p-value can be obtained using this z-score by referencing
az-table. If the p-value is lower than a threshold percentage
then it can be said that the new link was fabricated.
The Apache Common Math library 6was used to calcu-
late the required p-value during the evaluation. The cumula-
tiveProbability function from this library was used to get this
p-value. To find the p-value for values tested in the right tail
of β, it was necessary to calculate 1−p.
The goal of the evaluation was to test the proposed de-
tection method while varying the vetting period length (n)
and threshold values to determine the effect of each on
successful detection of attack. To do this, a False Positive
Rate (FPR) and False Negative Rate (FNR) was determined
through simulations. The latency values collected during the
attack analysis (Section III) were used as sample pools from
which smaller sample sets could be assembled to simulate
latencies collected for a new link. The entire set of benign
link samples (2500 latency values) was used as the baseline
reference set. Four p-value thresholds were tested; 5%, 10%,
15%, and 20%. 1000 simulations were performed for each
threshold. In each simulation, vetting period lengths from 2 to
6http://commons.apache.org/proper/commons-math/
1 2 3 4 5 6 7 8 9
Latency (ms)
0
200
400
600
800
1000
1200
Frequency
Ben. Link µ
Fabr. Link µ
Ben. Link
Fabr. Link
Fig. 7: Multi-host wireless tunnel via Infra. latency.
500 samples were tested. For each vetting period length, the
fabricated links from each attack scenario were simulated by
randomly selecting a number of samples, equal to the length
of the vetting period, from the sample pool associated with
that attack scenario. For each attack scenario, 1000 fabricated
link latency sample sets were generated for each vetting
period length. Each set was tested against the benign baseline,
resulting in an FNR for the entire set of 1000 links. A mean
FNR could then be tallied for each vetting period length over
the total number of simulations. This evaluation is outlined in
Algorithm 1. To calculate an FPR, links were simulated using
latency values from the benign link sample pool. Threshold
values greater than 20% were not tested because at 20% the
FPR became significant. The vetting period length was limited
to 500 samples. A greater number of samples would, even
at a representative sampling frequency of 1/s, result in an
impractical delay to perform the vetting process.
Algorithm 1: Calculating FNR to evaluate the solution
Let bbe the benign baseline sample set;
foreach threshold value tdo
for 1..total simulations do
foreach vetting period vdo
foreach attack scenario ado
for 1..1000 do
Let sbe a set of vsamples randomly
selected from a;
Calculate p-value by testing sagainst
baseline set b;
if p-value > t then
Increment false negative count for
this test;
end
end
Store false negative count for this vetting
period length and attack scenario;
end
end
end
Calculate the mean FNR for each vetting period
length associated with each attack scenario across
the total number of simulations;
end
B. Results
Fig. 8 to 11 and Tables I and II summarize the results. As
the threshold for the p-value increases, the FNR of each attack
scenario decreases. However, by increasing the threshold, the
FPR is increased. The tables show the number of samples
required for accurate detection at each threshold value. Fig.
9 illustrates the issue a single host with bridged interfaces
poses for our proposed detection method. Detection of this
attack method appears to only be possible when a short vetting
period is used. However, it can be seen by observing both
Fig. 8 and Fig. 9 that the vetting periods which produce false
2 4 6 8 10 12 14 16 18 20
Sample Size
0
5
10
15
20
25
30
False Pos. Rate (%)
5%
10%
15%
20%
Fig. 8: FPR for each threshold.
negative detections are those which produce false positives
for a benign link. Moreover, the FPR in Fig. 8 can be seen to
tend towards 0% during the same vetting period lengths (n)
where the FNR in Fig. 9 tends towards 100%. This trend,
along with the similarities between the relevant link latencies
shown in Fig. 3 provides strong evidence that the LFA using
the bridging technique does have latency values too similar
to the baseline, making detection Not Possible (NP) with a
practical number of samples.
The attacks using Python Scapy for user-space relaying were
detected in every test. An FNR, below the detection range
for the number of latency samples analyzed (n) was achieved
consistently for both of these attacks. This result (not included
in the figures) is expected from observations of Fig. 4 and
5, as it can be seen that there is an observable difference in
latency distributions.
Fig. 10 shows the FNR when detecting a fabricated link
formed through two hosts using a wireless ad-hoc relay
channel. Detection of this attack method is improved as the
threshold increases, at the cost of a greater FPR. Fig. 11
shows how an additional hop in the attacker’s wireless relay
channel can improve the detection rate when using vetting
periods with lower sample sets. The more hops used by the
attacker in their wireless relay channel, the more detectable the
attack becomes. Moreover, other factors such as interference
and physical environment would impede the wireless signal,
resulting in suboptimal conditions and thus higher latencies
and a better detection rate.
2 4 6 8 10 12 14 16 18 20
Sample Size
60
65
70
75
80
85
90
95
100
False Neg. Rate (%)
5%
10%
15%
20%
Fig. 9: FNR for single-host bridging at each threshold.
100 200 300 400 500
Sample Size
0
10
20
30
40
50
60
70
False Neg. Rate (%)
5%
10%
15%
20%
Fig. 10: FNR for wireless via ad-hoc at each threshold.
TABLE I: No. of sample where the FNR is reduced to <5%.
Relay Type Threshold
5% 10% 15% 20%
Single Host Bridge NP NP NP NP
Single Host Python Scapy 2 2 2 2
Wireless Tunnel Ad-Hoc >500 190 51 25
Wireless Tunnel Infra. 6 4 3 2
Multi-Host Python Scapy 2 2 2 2
TABLE II: No. of samples needed to reduce the FPR.
FPR achieved Threshold
5% 10% 15% 20%
<1% 2 3 5 8
<5% 2 2 2 5
V. DISCUSSION
A. Evaluation results
The results support the proposed detection method for
several considered attack cases. One attack which is capable of
eluding detection is the use of an interface bridge in the single-
host scenario. This cannot be detected due to the attack using
the same networking techniques (i.e. interface bridge) as used
in the OVS switches in the testbed. The detection method is
strongly influenced by the communication technologies used
for the benign and fabricated links, and motivated attackers
can use the same, if not faster links, than the target network.
An attack case which demonstrated a clear difference in
link latency was the attack case using Python to perform
2 4 6 8 10 12 14 16 18 20
Sample Size
0
5
10
15
20
False Neg. Rate (%)
5%
10%
15%
20%
Fig. 11: FNR for wireless via an Infra. at each threshold.
user-space traffic forwarding. The high latency introduced
during the attack can be explained by the requirement of
user-space processing coupled with the performance of the
Python programming language. Although programming lan-
guages exist which would be expected to perform better than
Python, the goal of this paper was not to perform an exhaustive
analysis of implementations of the LFA but to demonstrate the
effectiveness of the detection method.
The vetting period proposed as part of the solution in this
paper simplifies the analysis of link latencies which must be
performed. The collected latencies are unaffected by network
traffic and can therefore be compared to a static baseline
latency set without needing to take factors such as network
congestion into account. Moreover, it provides a method of
isolating new network links until they can be verified through
latency analysis. A short vetting period where a small number
of samples are collected would be ideal as it would reduce the
delay of a new link becoming available. However, as seen in
the results, as the number of samples used for vetting (n)
is reduced the FNR increases for a given attack scenario.
There is an optimal balance between link setup delay and
detection of malicious activity that will vary between networks
as requirements differ. This echoes the challenge of balancing
security and usability found in most computer systems. The
alternative to this approach is to perform online analysis using
a dynamic baseline. This method would increase the complex-
ity of the latency analysis due to the effects of network traffic
and congestion on the dynamic baseline, as well as introduce
potential counter-attacks, as discussed in section V-B.
B. Potential counter-attacks
Modifying the LLDP frame timestamp could be used to
deceive our detection method in controllers which use the
timestamp to determine link latency. This could be solved
by deploying our defense alongside a defense which verifies
LLDP frame integrity, such as the work in [3], ensuring
timestamp tampering does not undermine the statistical checks.
The SDN itself could be used as a relay channel to achieve a
fabricated link. This method of attack could be prevented using
switch port classification as used in Topoguard [2]. This would
be possible due to host traffic originating at a switch port
during the attack. However, an attacker could extend the attack
by having two connections from each host into each switch.
One connection would then be used for tunneling traffic,
while the other is used to create the fabricated link. Using
a GRE tunnel, traffic can be tunneled through the SDN, and
by bridging the interfaces on the attacking hosts the relaying
can occur. Whether or not our latency based detection method
could detect this attack scenario would depend on the baseline
reference set and the latency associated with the number of
hops between the attacking hosts.
C. The risk of attack
Modern data center networks which are largely made up of
virtual machines may segment the virtual network in such a
way where hosts have limited exposure to network devices
and traffic. In such a network, an attacker may not have
direct access to a network switch or LLDP traffic, reducing
the ability for the LFA to be carried out. An attacker could
however leverage a vulnerability, such as the OpenVSwitch
vulnerability discovered by Thimmaraju et al. [8], to compro-
mise trusted systems and gain the access needed to perform
the attack. Other types of networks such as office or campus
networks may employ physical security to limit access to
network switches, limiting an attacker’s ability to carry out
the attack. Nevertheless, if a controller is vulnerable to the
LFA, the attack remains a valid threat against the network.
D. Deploying the solution in complex networks
The solution proposed in this paper relies on data in the form
of link latencies. So long as the latency data is collected from
links which use the same network medium and equipment
they should share similar statistical properties. This property
is core to the proposed solution and is what allows fabricated
links to be detected. In complex, heterogeneous networks,
mediums and equipment may vary to the point that the several
correct latency baselines exist in the network. The proposed
solution could be extended to account for these types of
networks by maintaining several benign baseline reference
sets. Latency samples collected for a new link would then
be tested against each of these benign baselines. Rather than
applying the hypothesis testing used in this paper, a density
based outlier detection method could be used, such as Local
Outlier Factor [9].
In regards to network scale, because the proposed solution
relies on collected data and a static baseline reference set the
size of the network in terms of nodes and links will not hinder
the statistical tests. In fact, more benign links in the network
would actually allow a more accurate baseline reference set to
be created, potentially improving the detection rate.
E. Future work
The solution proposed in this paper uses hypothesis testing
to perform the statistical tests upon link latencies. Many other
methods of outlier detection exist which could be used in it’s
place. Future work on this topic will explore the detection
performance of a selection of these methods when applied
within the proposed solution. In order to further evaluate the
effectiveness of the proposed solution, the latencies and de-
tection rates associated with alternative user-space and kernel-
space traffic relaying methods will also be investigated.
VI. RE LATE D WORK
In this section previous work in detecting and defending
against the LFA in SDN is identified. Work on relay attacks
in other technologies is also described.
Hong et al. [2] introduce the concept of the LFA and design
Topoguard as a solution to this and other SDN poisoning
attacks. Topoguard uses both port classification and LLDP
authentication to prevent the LFA. This work also identifies
that an attacker can filter traffic exiting their host to avoid
port classification, and LLDP authentication does not protect
against relay attacks. Alharbi et al. [3] look further at LLDP
frame authentication and proposed the use of a Message Au-
thentication Code (MAC) in LLDP frames to prevent genera-
tion and replaying of LLDP traffic. This work does not provide
a solution to the relay-type LFA. Bui et al. [10] detailed a
series of LFAs through the use of malicious SDN switches.
This work discusses the possibility of end-to-end delay as
a means of detecting a fabricated link, however this is not
explored nor discussed in terms of hosts being used to perform
the relay attack. Wang et al. [4] explore the use of LLDP
transfer time to detect fabricated links and MitM attacks. This
work only considers observing the LLDP timestamp during
an LFA which uses tunneling, without considering counter-
attacks, network traffic influence, other attack scenarios, or
developing a practical solution based off their results.
Relay attacks are present in other communication tech-
nologies, such as Radio-Frequency Identification (RFID) and
wireless networks. In RFID technology, proximity between
card and reader is assumed. The relay attack can break this
assumption and has been successfully demonstrated [11].In
RFID, propagation and processing delay is considered low
[12], with attacks incurring significantly larger delays. This has
lead to the development of cryptographic distance bounding
protocols [13]. Nevertheless, Francillon et al. [11] studied the
variation in processing delays for different systems, noticing a
wide distribution that can therefore be exploited by attackers.
In wireless networks the wormhole attack is very similar to
the LFA. Hu et al. [14] proposed to bound the transmission
time, under the assumption of a deterministic radio channel,
using Time Division Multiple Access (TDMA) protocols. This,
however, does not consider the unpredictable delay introduced
by external radio interference. Gorlatova et al. [15] study
relay attacks in mobile ad-hoc networks by analyzing the
distribution of link latencies. While their technique is similar
to ours, their claims are only based on visual analysis of data.
Several papers analyze the timing of message transmissions
in order to detect relay or wormhole attacks. Most of them
employ threshold-based analysis of the round-trip-time (RTT)
between neighbors, where the relay is assumed to be slower
than the direct paths. In [16], [17], [18] a tunneled relay
is considered, where the RTT will be the sum of the links
in the tunnel and therefore a significant increase in RTT is
to be expected. Threshold schemes are easier to implement,
however, since the threshold needs to be predefined, they
do not react well to changing network conditions such as
increased traffic. Statistical analysis of message timings to
detect anomalies in 802.11i is employed in [19].
The LFA detection technique employed in this paper is
a type of supervised classification, where a model of the
normal process (benign link latencies) is built initially, and
new elements (new links) are classified as benign or ma-
licious by comparing with the model. The disadvantage of
supervised classification is, as highlighted in the paper, the
data required to build the model and to vet new links, which
introduce overheads that might hinder network performance.
Furthermore, if the system is already under attack during
the training phase, malicious links will not be discovered.
There are network anomaly detection techniques that use
unsupervised classification, where there is no initial labeling
of the data and both normal and anomalous data are expected
to be mixed in the same pool. Eskin [20] proposes building a
probabilistic model of the data and computing the likelihood
for every element. Portnoy et al. [21] use distance-based
clustering algorithms. Both of these works assume that the
anomalous data has fewer occurrences than normal data. If this
is not the case the algorithms will suffer from low detection
rates and high false positives.
Attacks exist against conventional networks at both layers
2 and 3 which aim to achieve a similar goal to the LFA in
SDN. Spanning-Tree Protocol (STP) is vulnerable to an attack
which allows the attacker to become a bridge between layer
2 network segments and obtain a MitM position over traffic
moving between segments [22]. Cisco have developed two
proprietary countermeasures to this attack; BPDU guard and
Root guard [22]. Although these solutions work, both require
configuration of switch-ports. Border Gateway Protocol (BGP)
suffers from a hijacking attack where an attacker advertises
false routes between Autonomous Systems (AS) and can then
control traffic which traverses the false route [23]. Work such
as Secure-BGP (sBGP) and Secure Origin BGP (soBGP) have
aimed to secure the BGP protocol by using cryptographic tech-
niques to verify and authenticate BGP update messages [23],
[24]. Hu et al. [25] propose Secure Path Vector (SPV) as
a means of verifying path integrity. Subramanian et al. [26]
propose the Whisper protocol with similar path verification
goals in mind. These solutions to BGP security issues focus
on preventing attacks where the attacker generates or replays
an advertisement, without taking relay attacks into account.
VII. CONCLUSION
In this paper, a detection method for relay-type LFAs in
SDN was presented. The proposed defense involved statisti-
cally testing the latency of new links against a baseline benign
link latency distribution. Latency values for new links are
collected during a vetting period, and are then tested against
the benign link baseline using statistical tests. This solution
was evaluated by first implementing the relay-type LFA in
several practical scenarios and collecting the latency from
the resulting links. The accuracy of the solution was then
measured by applying the solution in simulations using the
latency values collected from the testbed. A trade-off between
the accuracy of the detection method and vetting period length
was presented. The proposed solution was shown to detect
some methods of attack accurately with low numbers of
samples while other attack methods required higher numbers
of samples to be detected. Future work will examine the
effectiveness of detection method against other relay methods,
as well as the detection performance of alternative statistical
testing methods.
VIII. ACKN OWLEDGEMENTS
This work is funded by the CIT Risam scholarship scheme.
REFERENCES
[1] N. McKeown, “Software-defined networking,” INFOCOM keynote talk,
vol. 17, no. 2, 2009.
[2] S. Hong, L. Xu, H. Wang, and G. Gu, “Poisoning network visibility
in software-defined networks: New attacks and countermeasures.,” in
NDSS, 2015.
[3] T. Alharbi, M. Portmann, and F. Pakzad, “The (in) security of topology
discovery in software defined networks,” in Proc. of the 40th Conference
on Local Computer Networks (LCN), 2015.
[4] X. Wang, N. Gao, L. Zhang, Z. Liu, and L. Wang, “Novel mitm attacks
on security protocols in sdn: A feasibility study,” in Information and
Communications Security, Springer, 2016.
[5] D. Farinacci, P. Traina, S. Hanks, and T. Li, “Generic routing encapsu-
lation (gre),” 1994.
[6] D. Smyth, V. Cionca, S. McSweeney, and D. O’Shea, “Exploiting pitfalls
in software-defined networking implementation,” in Proc. of the Int.
Conf. On Cyber Security And Protection Of Digital Services (Cyber
Security), 2016.
[7] P. BIONDI, “Packet generation and network based attacks with scapy,”
CanSecWest/core05, 2005.
[8] K. Thimmaraju, B. Shastry, T. Fiebig, F. Hetzelt, J.-P. Seifert, A. Feld-
mann, and S. Schmid, “Reigns to the cloud: Compromising cloud
systems via the data plane,” arXiv preprint arXiv:1610.08717, 2016.
[9] M. M. Breunig, H.-P. Kriegel, R. T. Ng, and J. Sander, “Lof: Identifying
density-based local outliers,” SIGMOD Rec., vol. 29, May 2000.
[10] T. Thanh Bui, “Analysis of topology poisoning attacks in software-
defined networking,” Master’s thesis, KTH, School of Information and
Communication Technology (ICT), 2015.
[11] A. Francillon, B. Danev, and S. Capkun, “Relay attacks on passive
keyless entry and start systems in modern cars.,” in NDSS, 2011.
[12] G. P. Hancke, “Practical attacks on proximity identification systems,” in
Symposium on Security and Privacy (S&P’06), 2006.
[13] J. Reid, J. M. G. Nieto, T. Tang, and B. Senadji, “Detecting relay attacks
with timing-based protocols,” in Proc. of the 2nd ACM Symposium on
Information, Computer and Communications Security, 2007.
[14] Y.-C. Hu, A. Perrig, and D. B. Johnson, “Wormhole attacks in wireless
networks,” IEEE journal on selected areas in communications, vol. 24,
no. 2, 2006.
[15] M. A. Gorlatova, P. C. Mason, M. Wang, L. Lamont, and R. Liscano,
“Detecting wormhole attacks in mobile ad hoc networks through proto-
col breaking and packet timing analysis,” in MILCOM 2006-2006 IEEE
Military Communications conference, IEEE, 2006.
[16] P. Van Tran, Y.-K. L. Le Xuan Hung, S. Lee, and H. Lee, “Ttm:
An efficient mechanism to detect wormhole attacks in wireless ad-hoc
networks,” in Consumer Communications and Networking Conference,
2007. CCNC 2007. 4th IEEE, IEEE, 2007.
[17] J. Zhen and S. Srinivas, “Preventing replay attacks for secure routing
in ad hoc networks,” in International Conference on Ad-Hoc Networks
and Wireless, Springer, 2003.
[18] H. S. Chiu and K.-S. Lui, “Delphi: wormhole detection mechanism for
ad hoc wireless networks,” in 2006 1st International Symposium on
Wireless Pervasive Computing, Jan 2006.
[19] E. Sithirasenan and V. Muthukkumarasamy, “Detecting security threats
in wireless lans using timing and behavioral anomalies,” in 2007 15th
IEEE International Conference on Networks, Nov 2007.
[20] E. Eskin, “Anomaly detection over noisy data using learned probability
distributions,” in In Proceedings of the International Conference on
Machine Learning, Morgan Kaufmann, 2000.
[21] L. Portnoy, E. Eskin, and S. Stolfo, “Intrusion detection with unlabeled
data using clustering,” in In Proceedings of ACM CSS Workshop on Data
Mining Applied to Security (DMSA-2001, 2001.
[22] E. Vyncke and C. Paggen, Lan switch security: what hackers know about
your switches. Cisco Press, 2007.
[23] S. Kent, C. Lynn, and K. Seo, “Secure border gateway protocol (s-bgp),”
IEEE Journal on Selected areas in Communications, vol. 18, no. 4, 2000.
[24] J. Ng et al., “Extensions to bgp to support secure origin bgp (sobgp),”
tech. rep., Internet Draft, Apr, 2004.
[25] Y.-C. Hu, A. Perrig, and M. Sirbu, “Spv: Secure path vector routing for
securing bgp,” in ACM SIGCOMM Computer Communication Review,
vol. 34, ACM, 2004.
[26] L. Subramanian, V. Roth, I. Stoica, S. Shenker, and R. Katz, “Listen
and whisper: Security mechanisms for bgp,” in Proc. First Symposium
on Networked Systems Design and Implementation (NSDI), 2004.