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.