FINGERPRINTING OF
SOFTWARE-DEFINED NETWORKS
Introduction
Software-defined networking (SDN) is an
umbrella term encompassing several kinds of networktechnology aimed
at making the network as agile and flexible as the virtualized server
and storage infrastructure of the modern data center.
The Software-defined
networking (SDN) eases network management by centralizing the control plane and
separating it from the data plane.
The separation of planes in SDN, however,
introduces new vulnerabilities in SDN networks, since the difference in
processing packets at each plane allows an adversary to fingerprint the
network’s packet-forwarding logic.
In this paper, we study the feasibility of
fingerprinting the controller-switch interactions by a remote adversary, whose
aim is to acquire knowledge about specific flow rules that are installed at the
switches.
Network devices can also notify the
controller about network events (e.g., the reception of certain packets) and
device’s state changes.
For example, a number of advanced reactive control
plane logic implementations configure network devices to send notification to
the controller according to some installed policy (e.g., when a received packet
does not match any of the installed flow rules).
This notification triggers the
controller to perform a series of operations, such as installing the
appropriate forwarding rules at the switches, reserve network resources on a
given network’s path, etc.
Problem Facing
SDN separates the control and data
planes by defining a switch’s programming interface and a protocol to access
such interface, i.e., the Open Flow protocol .
The controller leverages the Open
Flow protocol to access the switch’s programming interface and configure the
forwarding behavior of the switch’s data plane.
The communication between the
controller and switches is established using an out-of-band control channel.
Statements of problem
The main objective of our work is to
study the ability of a remote adversary to identify whether an interaction
between the controller and the switches (and a subsequent rule installation)
has been triggered by a given packet.
The absence of a controller-switch
interaction typically provides evidence that the flow rules that handle the
received packet are already installed at the switches.
Otherwise, if a
communication between the controller and the switches is triggered, then this
suggests that the received packet requires further examination by the
controller, e.g., since it does not have any matching entry stored at the
switch’s flow table, or because the controller requires additional information
before installing a forwarding decision at the switches.
In contrast, a passive adversary cannot
inject packets in the network but only monitors the exchanged traffic between
the server and the client. Notice that passive adversaries are hard to detect
by standard intrusion detection systems since they do not generate any extra
network traffic.
Setup for experiment
The controller is configured to minimise
the processing delay for an incoming packet-in event, i.e., we only require the
controller to perform a table lookup and retrieve pre-computed forwarding rules
in response to packet-in events.
Furthermore, the controller always performs
bi-directional flow installation; that is, the handling of a packet-in event
triggers the installation of a pair of rules, one per flow direction, at each
involved switch.
We ensure that the controller’s CPU is not overloaded during
our measurements. We deploy a cross-traffic generator on an AMD dual core
processor running at 2.5 GHz to emulate realistic WAN traffic load on the
switches’ ports that were used in our study.
The generated cross traffic
follows a Pareto distribution with 20 ms mean and 4 ms variance [7]. To analyze
the effect of the data link bandwidth on the fingerprinting accuracy, we bridge
our SDN network to the Internet using 100 Mbps and 1 Gaps links (respectively),
by means of a firewall running on an AMD Athlon dual core processor 3800+
machine.
For the purpose of our experiments, we collect measurement traces
between an Intel Xeon E3-1230 3.20 GHz CPU server with 16 GB RAM and 20 remote
clients deployed across the globe. Table I details the specifications and
locations of the clients used in our experiments.
In our testbed, the server
and the software switch were co-located on the same machine. Note that, by
reducing the time required for rule installation to a minimum, our tested
emulates a scenario that is particularly hard for fingerprinting.
Collection of Data
To collect timing information based on
our features, we deployed 20 remote clients across the globe that
exchange UDP-based probe packet trains with the local server.
Notice that we
rely on UDP for transmitting packets since Internet gateways may filter TCP SYN
or ICMP packets. Each probe train consists of:
• A CLEAR packet signaling the
start of the measurements. Upon reception of this packet, the controller
deletes all the entries stored within the flow tables of the OpenFlow switches
in Pcs. • After one second2 since the transmission of the CLEAR packet, the
client transmits four MTU-sized packet pairs. Here, different packet pairs are
sent with an additional second of separation.
• After one second since the
transmission of the last packet pair, another CLEAR packet is sent to clear all
flow tables.
• Two packets separated by one second finally close the probe
train. We point out that all of our probe packets belong to the same network
flow,
i.e., they are crafted with the same packet header. For each received
packet of every train, the local server issues a short reply (e.g., 64 bytes).
We maintain a detailed log of the timing information relevant to the sending
and reception of the exchanged probe packets.
When measuring dispersion, we
account for out-of-order packets; this explains negative dispersion values. For
each of our 20 clients, we exchange 450 probe trains on the paths Pcs and Psc
to the server.
Half of these probe trains are exchanged before noon, while the
remaining half is exchanged in the evening. In our measurements, we vary the
number of Open Flow switches that need to be configured in
Reaction to the exchanged probe packets.
Namely, we consider the following four cases where a probe packets triggers the
reconfiguration of some of the Open Flow switches:
(1) one hardware switch,
(2)
two hardware switches,
(3) three hardware switches, and
(4) the software
switch.
We remark that the choice of the configured hardware switches in our
test bed (cf. Figure 1) has no impact on the measured features since we ensure
that the remaining hardware switches have already matching rules installed.
Furthermore, we remark that packets of a probe train only traverse the software
switch in case (4), i.e., when it is configured. In total, our data collection
phase lapsed from April 27, 2015 until October 27, 2015, in which 869,201 probe
packets were exchanged with our local server using all clients/configurations,
amounting to almost 0.66 GB of data.