OpenFlow A Protocol for Programmable Networks

The OpenFlow protocol provides a description of the requirements of an SDN Switch and specifications for communication between SDN switches and controllers. Since its conception, OpenFlow has had several versions, each upgrading its functionality and improving on previous versions. OpenFlow 1.0 was the first official version implemented in switches however, several previous (unused) drafts of the protocol were proposed.

2.4.2.1 OpenFlow 1.0

OpenFlow compatible switches were required to have at least two elements: A Flow Table and a secure channel to the controller. The first version of OpenFlow [40] defines a single flow table within the switch which held instructions for all the flows passing through the switch. Any packet arriving at the switch has their header fields compared with the flow rules in this flow table. If the packet matches a rule, the

instructions associated with the rule are applied to it. Any packet not matching a rule in the switch is either dropped or forwarded to the controller for instructions.

As mentioned in Section 2.4.1.3, OpenFlow 1.0 introduced Flow rules or Flow Entries in the switch Flow Table which consist of three elements: Header Fields, Counters, and Actions. The Header Fields are used to match incoming packets to a rule. They include attributes such as Source and Destination IP addresses, Incoming port and Protocol Type. Counters keep track of various flow statistics such as the number of packets and bytes that have used that entry. Actions provide instructions to the switch on how to handle packets matching a given flow. Actions include For- ward, Drop, and Modify-Field which allows the switch to modify the header fields of packets. OpenFlow 1.0 lists a set of actions, a subset of which are “Required” which a switch must include to be considered “OpenFlow Compatible”.

The protocol additionally enables a set of well defined messages between the switch and the controller. These messages firstly enable the switch to connect to the controller and register itself to the network. The protocol also includes messages to allow the controller to add, modify and remove flows from the flow table, request switch features or the status of the flow table from the switch, and for the switch to notify the controller of an unmatched packet, a flow that has been removed or a port state change. Messages can be Symmetric or Asynchronous.

2.4.2.2 OpenFlow 1.3

Because OpenFlow was hardwired into switches hardware, updating the protocol between versions was not as easy as updating software on a computer. Vendors therefore complained that versions were being released faster than was practical to deploy and for the most part, did not widely implement versions between 1.0 and 1.3. Nevertheless, the subsequent versions continued to build on each other, each adding functionality not previously seen. For brief examples, Group Tables and Group processing were added in OpenFlow 1.1 [45] which allowed for multiple ac- tions to be performed on packets. Openflow 1.2 [46] further built on this by adding IPv6 support and support for extensible matches.

OpenFlow 1.3 [47] was the second version of OpenFlow to be widely adopted by vendors. Unless otherwise specified, this is the version of OpenFlow to which

we refer in this chapter. By OpenFlow 1.3 several significant improvements had been made to OpenFlow 1.0. One major addition was the support for multiple flow tables (while 1.0 had only one) [48]. Multiple flow table brought several benefits to the network. For one, network admins were able to perform packet matching using different header field sets. Additionally, OpenFlow 1.3 made MAC Address Learning and Reverse Path Forwarding Checks significantly easier. These carried many implications for security solutions arising from SDN. It carried support for IPv6, tunneling and gave more fine grained statistics for the flows in the switch.

An upgrade in the protocol also meant the controllers which interacted with the new switches needed to be updated as well. Many developers used this opportu- nity to create entirely new controllers such as RYU [36]- a single threaded python controller realeased in 2012, and the OpenDaylight project [37] which released its first version in 2013. Despite their late release (with respect to the existence of OpenFlow), these controllers included backward compatibility for previous Open- Flow versions. Others such as Beacon [49] upgraded their functionality to support the new protocols. One of the original controllers that was present at the advent of SDN, NOX [35] recently received a complete revamp.

2.4.2.3 OpenFlow 1.4

One of the most notable additions to the OpenFlow protocol at version 1.4 is the slight increase in switch intelligence [50]. OpenFlow 1.0 touted the switch as a dumb forwarding device, whereas OpenFlow 1.4 imbued it with the ability to decide to actively evict flows without the direct intervention of the controller.

The issue of Flow Table Overloading has been highlighted as an attack on the network in several works and indeed can become an issue even during benign cir- cumstances [51]. In previous versions of OpenFlow, when the table becomes full and the controller attempts to add another flow, the switch would respond with a Table Full error message. The controller would have to directly issue a flow removal command (which may also involve a Flow Table query to determine what flows are in the switch and which to remove) before attempting to insert the flow again. Alternatively, the controller would have to wait until a flow expired before it can add another flow. Both of these options incur significant delays and dropped packets.

OpenFlow 1.4 attempts to mitigate this issue by giving the switch the ability to remove the oldest flow in its flow table before adding the new flow. This reduces the number of messages that need to be sent between the controller and the switch and the minimises computational resources on the controller in the exchange. We focus on this particular aspect of the OpenFlow protocol in this thesis as we highlight the effects of DoS attacks and propose potential solutions.

We note that Pica8 [52], a prominent SDN switch vendor has already imple- mented support for OpenFlow 1.4 in its switches but it is yet to receive widespread adoption. However, we can assume that future versions of the protocol will include the eviction aspect for the foreseeable future and as vendors implement upgraded versions, their switches will also have this capability1_.