Flow Rule Management & Conflict

Detection in SDN

Contents

Problem Definition .................................................................................................................................. 3

Submission .............................................................................................................................................. 3

Profile Setup ............................................................................................................................................ 3

Install dependences (on controller node) ............................................................................................. 4

Conducting the lab .................................................................................................................................. 7

Configuring the switch ......................................................................................................................... 7

Finding each host’s port number........................................................................................................ 10

Adding Flow Rules to the switch and identify conflicting rules ............................................................ 12

Resolve Flow Conflict ......................................................................................................................... 14

Problem Definition The controller is responsible for flow settings in switches such that all flow processing in the data-path is based on instructions from the controller. The controller then sets the flow rules in switch flow tables to either forward the flow packets to a particular port or drop packets coming from that particular source. The flow rules change depending on different network topologies, various user requests, and network protocols. Due to network complexity, a critical challenge is to reconcile potentially conflicting flow rules imposed by dynamic OpenFlow applications. This lab demonstrates how an user/attacker can modify flow rules using static flow pusher.

Submission Students should submit screenshots with captions for every step completed. Explain each screenshot in one or two sentences.

Profile Setup

The above image shows the topology for this lab. Host 1 and Host 2 are normal users. Host 3 is the attacker/malicious user. The three hosts are connected to each other through a single OpenFlow enabled switch which is connected to an SDN Controller. The controller used in this topology is the Floodlight SDN Controller. Note: You do not have to create new profile. Please use existing profile and instantiate a copy for yourself. Use default VM image. Keep the topology as it is for the profile. 1) Create the experiment specified in the figure above. For more information on setting up

profiles and creating experiments, please refer to Lab 1 Cloudlab Setup.

2) Click on Change Profile to search for the profile named FlowLab. After finding the profile, click Next button on the "Select a Profile" page above. On "Finalize" page, choose any available cluster (select Emulab cluster to avoid crash sessions) and click the Finish button to instantiate the topology.

Install dependences (on controller node) Once the profile is instantiated, the student(s) must install Floodlight on the Controller Node.

Note: you may proceed the step 3-12 to understand details, you may also perform these commands: Run ‘wget https://people.cs.clemson.edu/~hongdal/set_floodlight.sh .’ to download the script. Run ‘sudo /bin/sh set_floodlight.sh’ to build Floodlight. Run ‘sudo apt-get install curl’. Then proceed with step 13. 1) Open a new terminal 2) Run ’sudo apt-get update’ to update all your repositories 3) Run ‘sudo apt-get install software-properties-common python-software-properties’. This

command installs necessary software components we need for running files such as the json.tool.

4) Run ‘sudo add-apt-repository ppa:webupd8team/java’ to install the webupd8team

Personal Package Archive (PPA). The webupd8team PPA contains the Java 8 installations needed to run Floodlight.

5) Run ‘sudo apt-get update’ to update the repositories to include the Java 8 installers 6) Run ‘sudo apt-get install -y oracle-java8-installer’ to install Oracle Java 8 (JDK 8 and JRE 8)

7) Run ‘sudo apt-get install -y ant curl’ to install ant and curl. These pre-requisites need to be installed in order to build the floodlight.jar file and run floodlight.

8) Run ‘git clone git://github.com/floodlight/floodlight.git’ to clone the floodlight directory. 9) cd into the floodlight directory that was cloned. 10) Run ‘ant’ to build the floodlight and create the floodlight.jar file

11) Open a new terminal

12) Enter the floodlight directory

13) Run ‘java -jar target/floodlight.jar’

Upon initiating the Floodlight controller, students will notice Floodlight sending LLDP packets to discover the topology. Do not close the Floodlight Controller.

Conducting the lab Configuring the switch 1) Open a shell window for the switch node. 2) Run ‘sudo ovs-vsctl show’ to show the current switch configuration. Currently, there is no

configuration in the switch node.

3) Run ‘sudo ovs-vsctl add-br br0’ to add a bridge to the switch. A bridge directs traffic to the appropriate interface based on the MAC Address.

4) Run ‘ifconfig’ to check the configuration of the switch. There are 5 eth interfaces (reboot the host nodes if necessary)

Note: DO NOT change the eth0 interface. Doing so will have the user disconnected from their SSH session. Note: If all 5 interfaces are not visible, reload the affected host node(s). There will be 3 interfaces with the IP prefix of “10.10.*.*”. Each of these interfaces will be added to the bridge as a port. The IP addresses on each of these interfaces will be changed in the later steps. 5) The 3 interfaces with 10.10 subnet will be added to the bridge. To do that, the following

command will be run for all 3 interfaces:

Note: The order of which you add the 3 interfaces is essentially the numbering to the ports within the bridge. For example, if you add eth3 first, then this will be port 1. If you see eth3 has 10.10.2.2, eth4 has 10.10.3.3, eth1 has 10.10.4.1, then they are Host1, Host2, Host3 in this order. Add the interfaces in this order to ensure host number and port number matches. sudo ovs-vsctl add-port br0 <interface_to_be_added> Example: sudo ovs-vsctl add-port br0 eth4 6) Run ‘sudo ovs-vsctl show’ to show the configurations of the OVS

7) The switch now needs to be configured correctly so that the controller knows where the

switch is located. Run ‘sudo ovs-vsctl set-controller br0 tcp:192.168.1.2:6653’ to set the switch to communicate with the controller.

Note: Make sure you see is_connected to be true. If it’s not showing, that means you’ve failed to connect the switch to the controller.

8) Ensure that each host can communicate with each other. Run ‘ping 10.0.0.2’ and ‘ping

10.0.0.3’ on Host 1. If there is no communication from Host 1 to any of the other specified hosts, please redo any steps that may have been missed.

9) On Host 2 and Host 3, open a new terminal and run ‘sudo tcpdump -i eth1 -eenn’ on both

terminals.

tcpdump is a tool that lets user(s) see the packets going through a specified interface. The '-eenn' tells it to give more information and not to attempt to determine the names of the devices that it sees. 10) Run ‘ping 10.0.0.2’ on Host 1. There should be visible network traffic on Host 2.

11) Use Host 1 to ping Host 3, Host 2 to ping Host 1, Host 3 to ping Host 1. Finding each host’s port number Each host machine will have an unique port number as an identifier. Method 1: On switch node, run ‘ovs-ofctl show <bridge_name>’. Port numbers are displayed on left side. Method 2: On controller node, after you finished pinging of each machine, Run ‘curl http://localhost:8080/wm/device/ | python -m json.tool’ on a new terminal of the SDN controller node. The output of this command will give a list of devices that Floodlight has learned. Note: The output of this command may vary between user(s); dependent on the order you added the interfaces to the bridge.

Enter the following command on the switch node to see existing flows in the network:

‘sudo su’ ‘ovs-ofctl dump-flows br0’

Adding Flow Rules to the switch and identify conflicting rules For SDN, flow rules determine how packets are treated within the network. The following are the fields that we may use to craft our flow rules: in_port: This will be the port that the packet comes in on the switch. This is the port that Host 1 will be connected to (hence input port for the packet being sent). table: If we don’t put any table number, by default it is set to table=0. eth_src: This will be the Ethernet MAC address of Host 1 eth_dst: This will be the Ethernet MAC address of destination host machine. eth_type: Since we’re sending an IPv4 packet, we will use “0x0800” as the ethernet type nw_src: This will be the IP address of Host 1 nw_dst: This will be the IP address of destination host machine. Now stop each host from pinging each other. After gathering the necessary information for our flow-entry, we need to fill in the command to send to the controller for the controller to install the flow-entry. We perform the following steps on the Switch node. 1) Run ‘sudo su’ to enter root user mode.

2) Run ‘ovs-ofctl dump-flows <BRIDGE_NAME>’ for checking current flow rules. Should only have one that’s default for forwarding unmatched flows to controller.

3) Run ‘sudo:ovs-ofctl add-flow <BRIDGE_NAME>’ in_port=<PORT_NUM_OF_HOST1>,ip,priority=5,actions=output:<PORT_NUM_OF_HOST2>

2) Run ‘sudo tcpdump -i eth1 -eenn’ on Host 2 and Host 3 after inserting the flow-rule in the previous step.

3) Ping Host 3 from Host 1 by running ‘ping 10.0.0.3’. You should see the following on Host 3.

Host 3 should not capture anything from Host 1.

4) On Host 2, we should see this:

4) On the switch node, let’s check the flow rules again with: ‘ovs-ofctl dump-flows br0’ You should see the first rule added.

5) Now add the second rule: 1. ovs-ofctl add-flow <BRIDGE_NAME> in_port=<PORT_NUM_OF_HOST1>,ip,priority=5,actions=output:<PORT_NUM_OF_HOST3> 2. The first rule indicates packets from Host 1 will be forwarded to Host 2. The second rule indicates packets from Host 1 will be forwarded to Host 3. Obviously, those two rules conflict with each other.

6) Use Host 1 to ping Host 2. Host 2 should no longer receive any ICMP packets from. Host 3 would see all the ICMP echo requests.

7) On the switch node, let’s check the flow rules again with: ‘ovs-ofctl dump-flows br0’ You should only see the second rule, as it overwrites the first rule due to conflict.

Resolve Flow Conflict

We want to resolve the conflict by ensuring any ip packets from Host 1 will be forwarded to Host 2 only. We will resolve this by assigning a higher priority to the rule so it won’t be replaced by lower priority rules. Priority ranges from 0 to 65535. Therefore we apply the following command on the switch node:

1) On the switch node, add this flow rule: ‘ovs-ofctl add-flow <BRDIGE_NAME> in_port=<PORT_NUM_OF_HOST1>,ip,priority=1000,actions=output:<PORT_NUM_OF_HOST3>’

2) Check the flow rules to view all flows within the established network:

‘ovs-ofctl dump-flows br0’ The following screenshot shows the flow rules being added and not conflicting since they coexist. However, we still need to verify.

3) Run ‘sudo tcpdump -i eth1 -eenn’ on Host 2 and Host 3 to continue listen on the packets.

Then ping Host 2 from Host 1.

This can been on Host 2:

But Host 3 no longer receives any from Host 1:

Host 1 pings Host 3:

Host 3 no longer sees anything from Host 1:

This can been seen on Host 2:

Provide screenshots and short explanation of each process.