Inside Defense

Flow Control

One of the most popular controllers is OpenDaylight [7]. It communicates via different protocols, including the OpenFlow protocol, with the managed devices. For the user, the controller provides a RESTful API that supports device configuration. RESTful interfaces reflect the object that the user is editing in the URL, whereas the HTTP method maps the applicable actions.

At a logical level this means, figuratively, that the call

DELETE http://<server/auto/door/frontleft/> <window>

removes the window in the left front door. When transmitting data in the above example, you describe a door, and the REST API passes in the parameters of the object in JSON notation or as XML.

The API that administrators use to manage flows in OpenDaylight resides below a node. A node is nothing more than a (virtual) switch in the OpenFlow context of OpenDaylight. OpenDaylight distinguishes two prefixes: one is used to manipulate objects, the other to query the database for existing objects. Typically, the controller listens on port 8181. The URL prefix for changing objects and for reading are

http://<server>:8181/restconf/config
http://<server>:8181/restfonf/operational

respectively. To navigate the functional tree of the controller, you extend the URLs accordingly. A URL path to create a flow can look like:

http://<server>:8181/resconf/config/opendaylight-inventory:nodes/node/openflow:12345/table/0/flow/2

where opendaylight-inventory:nodes is the entry point for all objects of type node. Specifically, the node type is openflow and has an ID of 12345. To add more protocol entries to this table, you could replace the openflow prefix before the node ID.

The switch has a name, followed by the term table, and then the index of the table. You should keep in mind that OpenFlow as of version 1.3 manages several tables with flows; thus, the flow can jump to another table and continue there. At the end of the URL the flow entry has a unique ID.

The River Flows

To create a new flow, you use the PUT method in JSON or XML format that defines what the flow filters and what action it should take on success. The OpenFlow implementation limits the filter options on the executing machine. Depending on the version of OpenFlow, you can filter for all sorts of things, from the Ethernet level to flags in the TCP header.

If you are looking to fend off a DDoS attack, you need to filter for both IPv4 and IPv6 addresses, the IP protocol, and the destination port. With OpenFlow, you not only can drop packets, but change addresses and virtual local area networks (VLANs) and set the output port – and these are just some of the many options.

Rate limiting is interesting for DDoS defense and is one of the meters mentioned earlier. Unfortunately Open vSwitch does not support it; in this case only the DROP action remains. In the logic of OpenFlow, dropping a packet is a filter without an action. The JSON syntax for doing this is shown in the example in Listing 1.

01 {
02   "flow": {
03     "id": "5", "match": {
04       "ethernet-match": {
05         "ethernet-type": {
06           "type": "0x0800"
07         }
08       }, "ip-match": {
09         "ip-protocol": 17
10       }, "ipv4-destination": "10.1.1.2/32", "udp-destination-port": 1234
11     }, "table_id": 0, "priority": 10
12   }
13 }

This flow definition has the same effect as the example shown earlier with ovs-ofctl; however, note that to classify IP packets, the definition must contain the appropriate Ethernet type (e.g., for IPv6, this would be 0x86dd). To describe UDP packets, you need to state the IP protocol. It would make sense for the controller to make useful assumptions when you type in the port definition, but unfortunately this is not the case.

Flow managers must also state the IP address with a mask of /32 if it is a single address. The id and table_id fields are another special case. They match the path in the URL; otherwise, the controller will accept the flow without protest but will not create it. In other words, this flow for OpenFlow node 1 works exclusively on the following URL:

http://<server>:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/0/flow/5

A final important field is priority, on the basis of which OpenFlow-enabled switches are sorted. The higher it is, the more important the flow. Usually admins pass a flow to the Open vSwitch switches with a NORMAL action, which means: "Behave like a priority 1 switch." If filters need to override this behavior, they need a higher priority.

Out!

Several routes are open for uploading this definition, including a program in your favorite programming language. Because of the simple structure, you do not even need a REST library, simply one with HTTP support. A REST client browser plugin is useful for testing individual requests. Postman is a very powerful candidate (Figure 4) for Chrome [8], and Curl is suitable for uploading data (Listing 2). This call will succeed if the JSON definition of the flow exists in the drop.json file (line 5).

01 curl -u admin:admin
02         -H "Accept: application/xml"
03         -H "Content-Type: application/json"
04         -X PUT
05         -d @drop.json http://ODL:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/0/flow/5

Figure 4: Chrome Postman needs a configuration file.

Thanks to the -d option, Curl either accepts a string with data, or it reads the data from the file after the @. The -X parameter is passed to the HTTP method, and -u <username>:<password> handles authorization. The -H "Content-Type: application/json" option tells the server you want to transfer the data in JSON format.