Table Overflow

The opportunity for Table Overflow attacks has been explored as one of the major shortcomings of SDN in the previous chapter. Each flow of traffic in an SDN network requires a matching rule in the switches it encounters in order to traverse the net- work. TCAM memory, which SDN switch Flow Tables are built on, is typically very expensive, leading manufacturers to restrict the typical Flow Table size to several thousand rules. This makes the Flow Table a limited resource and these relatively small Flow Tables can easily become filled to capacity with flow rules. Once this occurs, no new flow rules can be added to the switch which restricts any new traffic from being routed through the switch until the flows expire or are explicitly removed by the controller.

As of OpenFlow 1.3, the latest widely deployed version of the OpenFlow protocol, the only way to immediately rectify a Table Overflow is to have the controller actively remove flow rules from the Flow Table before inserting new rules into the table. In such a situation, the following procedure may take place:

• The controller issues a Flow Mod command to add a new flow rule

• The switch informs the controller the table is at capacity with a “Table Full” error

• The controller requests a list of flow rules currently occupying the Flow Tables

• The switch responds with a list of the flow rules currently occupying the Flow Table

• The controller selects one to remove and issues the flow removal command

In this worst case scenario, the process adds an extra 5 steps to add the flow rule placing additional stress on the controller, which is already a potential bottleneck in the SDN architecture. Such a method is wholly inefficient as it increases the work the controller must do as well as the number of messages which must be sent between the controller and the switch.

3.1.2

Switch Based Flow Rule Eviction

Openflow 1.4 introduced Switch Based Flow Rule Eviction. This configuration en- ables the switch itself to remove a flow rule in the event of an incoming Flow Add command from the controller in the presence a full Flow Table. In doing so, while the switch Flow Table is still a limited resource, the network is better able to ap- portion this resources to cater for demand and provide better service.

Autonomous flow rule eviction in the switch increases switch intelligence and in doing so presents several benefits to the SDN network.

1. By enabling the switch to make a decision and perform an action, it reduces its dependency on the controller for operation.

2. There is also less delay between the moment the action is needed and the moment it is performed. By allowing the switch to perform the 5 extra steps itself, the deletion of a flow rule for space and insertion of the incoming flow rule occur almost immediately. This reduces the number of packets dropped in the interim.

3. Along the same lines, it reduces the number of messages between the switch and the controller. In a system in which the bandwidth between the controller and the switch can be a precious resource, a 6x increase in the number of messages between the switch and the controller is a wholly inefficient situation. By enabling the switch to perform its own evictions, there is no need to send these messages, freeing the switch-controller communication channel to handle more critical messages.

4. Finally, it also reduces controller load. The controller no longer needs to process the responses sent by the switch, determine which flow rule would be best to remove and issue additional commands. It instead can focus on

more controller specific tasks such as determining routes for flows through the network and maintaining flow policies.

In some respects, Switch Based Flow Rule Eviction can be presented as a solution to Table Overflow DoS attacks. Flow rules can now be forcibly removed without excessive overhead and therefore attackers can no longer hold the Flow Table hostage preventing traffic from being routed. In this way, Switch Based Flow Rule Eviction represents a change in direction of the SDN paradigm by increasing intelligence of the traditionally “dumb forwarding device”. Given the range of benefits achieved by moving this one action out of the controller and into the switch, it strengthens the argument that smarter switches can provide untold benefits for the SDN network.

3.1.3

“First Packet” Delays

Forwarding in SDN can be realised in two forms, known as Proactive and Reactive. In Proactive SDN flow rules are installed in the switch in anticipation of the traffic which will arrive at the switch. This method reduces the load on the controller and ensures that traffic proceeds through the network unhindered by the controller interaction intrinsic to Reactive SDN. However, Proactive SDN can be restrictive in that any traffic without a pre-installed rule is unable to traverse the network. In Reactive SDN, flow rules are installed in response to the traffic demands. It is this form of the paradigm on which we focus in this thesis.

In Reactive SDN, a switch Flow Table does not contain rules for flows before the flow arrives at the switch. Thus, the first packet of a flow arriving at a switch has no matching flow rule to instruct the switch on how to forward it, and so triggers a “Table-Miss”. As a result of this table-miss, the switch forwards the packet to the controller for instructions on how to route similar packets. The controller determines the best route for the packet and others of the same flow through the switch and inserts a flow rule into the switch to handle further packets of the same flow. In being diverted to the controller for instruction instead of passing directly through the switch, the packet causing the table-miss registers a significant delay in arriving to its target. Depending on the controller, the CPU power and the distance between the switch and the controller, this “first packet delay” can cause the packet’s latency to grow significantly. Under normal circumstances, it is only the first packet of the flow that registers this delay (of the order of ms) [137] with the remaining packets

of the same flow being processed at line rate.