# Lab 3: Dive into SDN Security
### Part I: Testing the Waters

###### Name: Priyanka Abhang (pabhang)

To begin, we worked on a smaller network consisting of a router and two PCs connected to the router (see figure below) to gain a basic understanding of how OpenFlow and OpenVSwitch work. Our goal is to use OVS to convert this router to a virtual switch using an internal virtual bridge, for which the script has already been provided. Once this is completed, an interface for the switch is created, allowing it to be connected to a controller, through which all communication will take place.
The `ovs-init.sh` script is used to initialize the switch and configure it to run as expected.
We run a simple application on the controller to learn how everything works behind the scenes.
`ryu-manager --verbose ryu.app.simple_switch_13`


SDN, as we understand it, consists of a controller and other network elements such as routers, machines, and so on. In our lab, the controller uses OpenFlow to control these network elements. This controller is in charge of managing and routing traffic through itself. The network topology we will be working with in this lab is given in the figure below. The basic idea is that if `pc0` wants to send something to `pc7`, it will first go to `sw0`, and then we must specify which path will be used to reach `pc7`. The defined path in our code is via `sw2`. So, normally, the packet takes two hops to reach `pc7`, but with the controller in the picture, every request, reply, or even a simple query is sent to the controller.


However, as shown in the diagram below, a virtual switch is capable of resolving ARP requests from machines in its subnet. The command below allows us to view the flow tables of a specific OVS.
`ovs-ofctl dump-flows br`


The goal of this lab is to configure a given topology with four subnets so that TCP traffic can pass through a controller and across subnets. To complete the task, we modified the provided `init_learn_rules.py` application. Also, to create firewall rules that allow or deny specific traffic from passing through the routes.

The first changes that needed to be made were mapping port numbers to the MAC and IP addresses of the connected devices, as shown in the screenshot below.


The `ovs-init.sh` script was set to block all routes, implying that the bridge that was built would not allow anything to pass through. The first task was to make ICMP ping work across subnets, for which we were supposed to create a routing table that included the `dpid` which is unique to each virtual switch, source subnet, ICMP subnet (destination subnet), and the port on which the communication was to take place. This will now assist us in determining the destination MAC and output port for formulating responses such as ICMP and ARP and also respond to TCP SYN made by the switch to the controller.


We are supposed to run our python application code on the server named `ctrl` using the command `ryu-manager —verbose init learn rules.py` (after going into the correct directory where the python file is located). To better understand the logs, we use the verbose flag.
Then, on each router, we run the command (wrt my PC) to configure it as a virtual switch.
`/home/ubuntupri/netsec/lab3p1/ovs-init.sh -c eth3 10.0.8.10`

We use the data structure we created for accessing the MAC and IP addresses from port and dpid to see if the ICMP ping command works across the subnet. By specifying the correct values, we can see from the screenshot below that the ICMP ping command was successful.

1. Open terminal on `pc0` and type `ping 10.0.3.20 -c 5`
2. Open temrinal on `pc4` and type `ping 10.0.3.20 -c 1`


The primary objective was to figure out how to make these routes known to the switches and controller so that traffic could be routed to the correct machine. It took a long time to figure out this logic. Following this, the task of forwarding TCP packets was a little difficult because I couldn't figure out how to add the payload to the TCP packet. To forward the TCP packet to the desired location, the following code was used. The idea for formulating this was the same as the function provided for ICMP, which I reused to achieve the task's goal.


To see if the goal was met, I set up a netcat listener on one of the PCs and a server on another. To ensure that this is working, we must first ping each switch from the machines in its subnet, which is one of the ryu controller's requirements. After that, proceed with the following steps:
1. Open terminal on `pc2` type the command `nc 10.0.2.20 9090`
2. Open terminal on `pc4` type the command `nc -l 9090`
3. Start typing messages from the terminal window of `pc2`

On the server side, you should be able to see the message sent by the client, as shown in the screenshot below.


Wireshark snippets for the first figure below will aid in our understanding. The `PSH, ACK` indicates that the data sent has been received by the host and can be seen in the packet bytes. To demonstrate the occurrence of the various TCP flags, both the server and the client were killed abruptly.





The lab concludes with the creation of a firewall on each switch, which entails defining rules to allow and deny traffic from and to nodes. The code snippet below shows us how to configure the firewall rules.
1. Default deny
2. Allow TCP traffic to flow from `10.0.0.20` to `10.0.2.20`
3. Allow TCP traffic to flow from `10.0.1.21` to `10.0.3.20`


The screenshot below demonstrates #2. Since the connection is being blocked by the firewall, if you type messages from `pc6`, you will not be able to see the message on the server. The steps to take are as follows:
1. Open terminal on `pc3` type the command `nc -l 5645`
2. Open terminal on `pc6` type the command `nc 10.0.0.20 5645`