SDN Penetration Testing (PART2) : Setting up the attack scenario
4th December 2019 | by hilo21
Introduction :
In this article we used DELTA framework for SDN penetration testing. See Part1 on how to set it up.
One of the major benefits of SDN environnements is control logic
centralization and network programmability which create new threats that
did not exist before and give more chances to other attacks that were
hard to execute before, for instance DoS attacks that were stopped from
affecting the entire network in a distributed control plane
implementation.
In this document, we will introduce a detailed
explanation of DoS attack that targets data plane switches or/and SDN
controllers via OpenFlow message PACKET_IN.
Setting up the scenario
This document’s material is done in consideration of OpenFlow 1.3 specifications so we’re going to differentiate between some notions to specifically describe the circumstances for the execution of our attack scenario.
OpenFlow Communications:
OpenFlow
is an open and standardized protocol for southbound communications
between controllers and the switch fabric. So before jumping into
OpenFlow details we going to explain some of the basics of OpenFlow
communication types.
Physical connections to handle OpenFlow communication between switches and the controller can be setup in two ways, out-of-band and in-band.
Out-of-band communication implies that each switch has a dedicated
physical connection to the controller. In-band communication involves
control plane information being carried over existing data plane
connections between the switches. This document assumes that control
plane communication occurs out-of-band.
Out-of-Band (Left) In-Band (Right) communications
In
OpenFlow, a switch performs packet forwarding by consulting its flow
table and determining the output port on which to send the packet. Each
entry in the flow table (called a flow rule or flow entry) consists of
the packet header fields to match, the actions to apply on matched
packets and the corresponding counters to update. In the context of SDN,
a switch may operate at layer 2 or layer 3 of the networking stack.
When a switch receives a packet, which cannot be matched to any
installed flow rule, the switch typically first buffers the packet and
then requests a new flow rule from the controller with an OFPT PACKET IN
message. This message includes the data packet’s header fields. The
controller then responds with an OFPT FLOW MOD message, containing the
action to be performed on the data packet and the duration for which to
keep the flow rule in its flow table. This duration is called a timeout.
Each flow rule has two associated timeout values, an idle timeout value
(aka soft timeout), which is triggered when the flow remains inactive,
and a hard timeout, which is triggered at the timer expiry. When either
of these timers expires, the switch removes the corresponding flow entry
from its flow table and sends an OFPT FLOW REMOVED message to the
controller.
This mechanism of flow rule installation is “reactive” as rules are requested by the switch only upon receiving data packets. Controllers may also behave “proactively”
by installing rules to handle all expected data traffic when a switch
first establishes connection to the controller. Our demonstration does
not discuss the proactive strategy.
Reactive Mode rule installation
Denial-of-Service Attacks:
A Denial-of-Service (DoS) attack in OpenFlow SDN networks involves overwhelming computing or networking resources such that a switch is unable to forward packets as expected. A successful attack involves sending a large number of packets to the switch, possibly instantiating new flows. This section describes the two types of DoS attacks emulated in our project. The mechanism to execute both these attacks is essentially the same but the effects of these attacks vary. A description of the two attacks demonstrated in this report follows.
1. Attacking the control plane bandwidth:
when a switch first receives a packet belonging to a new flow, it buffers the packet before sending an OFPT PACKET IN message to the controller. This message includes a maximum of 128 bytes of the received packet header. However, if the switch does not have buffering capabilities or if the input buffer is full, the OpenFlow specification mandates the switch to send the entire packet to the controller encapsulated within the OFPT PACKET IN message. In this case, the controller responds with an OFPT PACKET OUT message which also includes the entire data packet. No flow rule is installed and the switch simply performs the associated action (which is typically to forward the packet out on the specified port). This scenario is depicted in the next figure.
Behavior when a switch cannot buffer packets
If
the switch receives a large number of new packet flows within a short
time period, its buffer fills up and it has to forward complete packets
to the controller. This leads to heavy consumption of control plane
bandwidth. Such an attack may increase the delay of installing new flow
table entries and, in worse cases, the switch may be unable to forward
traffic from new flows. Packet loss can occur in one of the following
ways:
- Switch output queue size is limited — If the link between the switch and the controller is congested, the switch’s output queue fills up and the OFPT PACKET IN message itself cannot be sent thereby resulting in packet loss.
- High latency — Congestion may introduce latency in the control channel. If the switch does not receive an OFPT FLOW MOD response within a certain time duration, it discards the corresponding buffered packet.
The impact of the attack discussed so far is local to the switch. However, if the attack succeeds in overwhelming the controller’s computing resources, all switches connected to the affected controller may feel the impact.
2. Attacking the switch’s flow table:
Switches have limited memory to store flow rules. For instance, as shown in the next table some OpenFlow-Enabled switches have low number of of storage capacity of flow rules in its flow table. The limited size of the flow table can be utilized for DoS attacks.
Context Capacity
Commercial switches : 2,000∼8,000
OpenvSwitch : 15,000∼20,000
NoviSwitch 2150: 16,384
NoviSwitch 2128, 2122, 1248 : 1,000,000
Let us assume that the switch’s flow table is full. Upon receiving an instruction to install a flow rule, the switch detects that its flow table is full. As the switch cannot install this rule it sends an OFPT ERROR message to the controller with error code OFPFMFC TABLE FULL. It then drops this packet. This scenario is depicted in the next figure. The switch cannot forward buffered packets until there is space in the flow table to install new flow rules. Packets that are not buffered are not affected as no flow rules need to be installed for them. The impact of this attack is local to the switch and it does not affect the entire network.
Behavior when switch’s flow table is full
Exploitation: Flow_Table_Flooding Attack
In this section we are going to demonstrate how exactly a switch flow table can be exploited by a DoS attack.
- Emulation environment :
- OS : Ubuntu 14.04, 6GB RAM
- Tool : DELTA Framework All-in-One VM
- Controller : ONOS 1.9
- OpenFlow : Version 1.3
This next figure shows the topology of our lab environment used by DELTA Framework All-in-One VM.
DELTA pen-testing environment
The next figure represents the topology of our experiment created by DELTA using Mininet.
Infrastructure TopologyAs we saw previously on how to install DELTA Framework, we launched the Flow Table Flooding Attack against ONOS 1.9, and, as we can see in the next image, it failed.
In the next and last part (part 3) we will see how the attack was executed and analyse the results captured with Wireshark.
Leave Your Comment