SDN Penetration Testing (PART 3) : Flow-Rule Flooding Attack Using DELTA

Introduction:

The key concept of SDN lies in the decoupling of the data plane and the control plane. In SDN, the switches are free from rigid routing computation and can be focused on packet forwarding. The centralized controller now is in charge of the routing rule computation and assignment. Since the switches become highly primitive, the assigned routing rules from the controller are expected to be precise. Currently, OpenFlow is the most widely used control link protocol owing to its fine-grained routing rules (i.e. flow entries) and abundant flow statistics. To support OpenFlow protocol better, the switches have to use ternary content addressable memory (TCAM) to store flow entries.

TCAMs are associate caching memories where data can be accessed by performing a query for the content itself and the memory retrieves the address. They are different from the CAM memories in performance capabilities since the TCAM can search the entire content in a single clock-cycle.

However, considering the high cost and high-power consumption, the current OpenFlow-enabled switches usually have limited flow table, which supports a few thousand flow entries. For example, without the external TCAM, the NoviSwitch 2150 can only store 16,384 flow entries.

Flow Table Flooding is a Table-Overflow Attack that targets the switch storage memory of Flow Rules and causes an increase in network latency and it can push the switch even further over its limits and causes a disconnection.

Connection establishment:

We started the attack using DELTA Framework and launched Wireshark from withing the Mininet virtual machine (VM3) since the Vms are using SSH to communicate between one another. So we used an xTerm terminal and logged in vagrant@10.100.100.13 using SSH password “vagrant” using the -X option to be able to start the Wireshark GUI. You might need to install Wireshark before doing this, as VM3 doesn't come equiped with it.

 Loging to Host Vm

After logging in VM3 we started Wireshark by typing:

$ wireshark &

and we chose the eth1 to start capturing packets.

Start Wireshark

Using DELTA WebGUI, we started the Flow Table Flooding :

Start the attack

• Connection Setup:

The switch initiates a standard TCP (or TLS) connection to the controller. When an OpenFlow connection is established, each entity must send an OFPT_HELLO message with the protocol version set to the highest OpenFlow protocol version supported by the sender (1.3 in our case).

Hello Message Capture

 OpenFlow Capture Version

• Feature Request – Reply:

After successfully establishing a session, the controller sends an OFPT_FEATURES_REQUEST message. This message only contains an OpenFlow header and does not contain a body.

 Feature Request Capture

The switch responds with an OFPT_FEATURES_REPLY message that contains Data path ID and the switch capabilities.

 Feature Reply Capture

Feature Reply Parameters

• Set/Get Configuration:

The Switch Configuration messages consist of a unidirectional configuration message and two
request-reply message pairs. The unidirectional message, SET_CONFIG, is used by the controller to set configuration parameters in the switch.
The GET_CONFIG message pair is used to retrieve a switch’s configuration settings.

Set & Get Configuration capture

• Controller Role

The switch may establish communication with a single controller, or may establishcommunication with multiple controllers.

When OpenFlow operation is initiated, the switch must connect to all controllers it is configured with, and try to maintain connectivity with all of them concurrently. Many controllers may send controller- to-switch commands to the switch, the reply or error messages related to those commands must only be sent on the controller connection associated with that command.

The default role of a controller is OFPCR_ROLE_EQUAL. In this role, the controller
has full access to the switch and is equal to other controllers in the same role.

A controller can request its role to be changed to OFPCR_ROLE_SLAVE. In this role, the controller has read-only access to the switch. By default, the controller does not receive switch asynchronous messages, apart from Port-status messages. The controller is denied ability to execute controller-to-switch commands that modify the state of the switch, OFPT_PACKET_OUT, OFPT_FLOW_MOD, OFPT_GROUP_MOD, OFPT_PORT_MOD and OFPT_TABLE_MOD. If the controller sends one of those commands, the switch must reply with an OFPT_ERROR message with a type field OFPET_BAD_REQUEST, a code field of OFPBRC_IS_SLAVE.

Controller Role Request

A controller can request its role to be changed to OFPCR_ROLE_MASTER. This role is similar to OFPCR_ROLE_EQUAL and has full access to the switch, the difference is that the switch ensures it is the only controller in this role.

OFPRCR_ROLE_Master

• Multipart Request – Reply

The controller may request state from the datapath using the OFPT_MULTIPART_REQUEST message. The message types handled by this message include various statistics (FLOW/TABLE/PORT/QUEUE/METER etc) or description features (METER_CONFIG/TABLE_FEATURES/PORT_DESC etc).

In this document, the analysis we conducted will be focused on the OFPMP_TABLE and OFPMP_FLOW Multipart requests, since they provide detailed information about the flow tables.

As we are interested in the Flow Table Flooding attack, the next image shows a capture of our traffic that illustrates requests for Table State via the OFPMP_TABLE Multipart request message.

 Multipart Request-Reply Capture

According to the specification of OpenFlow 1.3, the reply for this must contain the table stats for each table:
• Table ID,
• Pad,
• the number of active entries,
• number of packets looked up in table
• number of packets that hit table.

Table States Capture

The controller also requests the Flow Stats by sending a Multipart request OFPMP_FLOW. The switches reply with Multipart reply OFPMP_FLOW message containing the requested information:

Length: 64
Table ID: 0
Pad: 00
Duration sec: 0
Duration nsec: 242000000
Priority: 0
Idle timeout: 0
Hard timeout: 0
Flags: 0x0000
    .... .... .... ...0 = Send flow removed: False
    .... .... .... ..0. = Check overlap: False
    .... .... .... .0.. = Reset counts: False
    .... .... .... 0... = Don't count packets: False
    .... .... ...0 .... = Don't count bytes: False
Pad: 00000000
Cookie: 0x0000000000000000
Packet count: 0
Byte count: 0

Summary:

This section represented an overview of the messages exchanged during the connection establishment between the switch and the controller. A first analysis of the key messages that our attack is going to exploit is required in order to discover the mechanisms used between the controller and the switch to prevent this kind of attacks. We noticed that the first major step that a controller makes using the messages we explained above are in order to execute a network discovery of all the switches connected to it. So, we were looking for some mechanisms that both parties use to protect the switch from a Table-Overflow attack. In the next section we gonna continue our packet analysis for the next messages exchanged so that we can understand together how the attack affect the switch and if there is messages used by the controller to protect the switch from it.


What actually happens:

In the previous section we discussed the connection establishment between the switch and the controller and we concluded that the messages exchanged helps the controller make a topology discovery where it gathers the switch flow table's states.

In this section we going to discover how the Flow Rule Flooding attack affect the targeted switch. The next figure shows simplified Flow_Rule_Flooding attack targeting an OpenvSwitch connected to ONOS 1.9 Controller.

Flow Rule Flooding Attack Pattern

From the compromised host, the attacker triggers the switch to send PACKET_IN messages to the controller by sending him a continuum of table miss packets, which push the switch to request new flow rules from the controller. In this case, the controller starts doing its job and replies the PACKET_IN messages with PACKET_OUT packets which include an action-list. This action-list will generally contain an output action, which will specify a port number. When the controller has a data packet to forward out through the switch, it uses the OpenFlow PACKET_OUT message, such a data packet coming from the controller may take two different paths through the OpenFlow logic, whether it specifies directly the output port and the packet is passed to that port, or the controller indicates that it wishes to defer the forwarding decision to the packet matching logic. the controller dictates this by stipulating the virtual port TABLE as the output port.

Adding to this, the controller also sends FLOW_MOD packets as a reaction to PACKET_IN messages to perform a flow table modification using the following types: OFPFC_ADD, OFPFC_DELETE, OFPFC_DELETE_STRICT, OFPFC_MODIFY, OFPFC_MODIFY_STRICT.

Flow_Mod Capture

As represented in the figure above, the controller is the one doing the work for the attacker now
by flooding the switch's flow table with new rules until its full.

TCP Zero Window

 TCP Transmission window is full

We can see in the previous figures the execution of the TCP Zero Window mechanism which is performed when the Window size in a machine remains at zero for a specified amount of time. This means that a client is not able to receive further information at the moment, and the TCP transmission is halted until it can process the information in its receive buffer .

 DELTA APP Agent Logs

Conclusion:

In the DELTA Framework's logs, we can notice that the attack succeeded and increased latency of the communication between the switch and the controller from 0.098ms before
to 46.054ms after.

This type of attacks pointed our view to the capabilities of SDN-enabled switches and the importance of enhancing them in order to resist against Table-Overflow attacks by implementing intelligence into switches and developing better mechanisms to mitigate these types of attacks. Also, the necessity of enhanced messages between the controller to be able to protect the switch and itself from a Table-Overflow attack.