Lab 3: Simple Firewall using OpenFlow
This lab builds on the knowledge acquired through Lab 1 where you were first introduced to the Mininet environment. It will also help you prepare for the class project. In Lab 1, you were introduced to some basic functionality of Mininet. In this lab, we will take that one step further by introducing you to Software-Defined Networking (SDN) and the OpenFlow protocol.
Software-Defined Networking & OpenFlow:
Software-Defined Networking (SDN) is a recently proposed networking paradigm in which the data and the control planes are decoupled from one another. One can think of the control plane as being the networks brain, i.e., it is responsible for making all decisions, for example, how to forward data, while the data plane is what actually moves the data. In traditional networks, both the control- and data planes are tightly integrated and implemented in the forwarding devices that comprise a network.
The SDN control plane is implemented by the controller and the data plane by switches. The controller acts as the brain of the network, and sends commands (a.k.a. rules) to the switches on how to handle traffic. OpenFlow has emerged as the de facto SDN standard and specifies how the controller and the switches communicate as well as the rules controllers install on switches.
Mininet and OpenFlow:
In Lab 1, we experimented with Mininet using its internal controller. In this lab (and the final project), we will instead be using our own controller to send commands to the switches. We will be using the POX controller, which is written in Python.
OpenFlow 1.3 Overview:
OpenFlow 1.3 is the version of the OpenFlow protocol supported within the Mininet environment. The following diagram explains the operation of OpenFlow switches.
Note that when the packet comes into an OpenFlow switch, the switch will reference a table containing rules and actions. This flow table contains the following fields:
The figure below shows the flow of execution that follows. If an ofp_packet_in does not match any of the flow entries and the flow table does not have a table-miss flow entry, the packet will be dropped. If the packet matches the table-miss flow entry, it will be forwarded to the controller. If there is a match-entry for the packet, the switch will execute the action stored in the instruction field of the corresponding flow table.
All of the figures and information in this section are from the OpenFlow 1.3 specification, which you can reference if you would like additional information
Assignment:
The python files are available in a zip file here.
For this assignment you will create a simple firewall using OpenFlow-enabled switches. The term firewall is derived from building construction: a firewall is a wall you place in buildings to stop a fire from spreading. In the case of networking, it is the act of providing security by not letting specified traffic pass through the firewall. This feature is good for minimizing attack vectors and limiting the network surface exposed to attackers.
In this Lab, we will provide you with the Mininet configuration, lab3.py, to setup your network which assumes a remote controller listening on the default IP address and port number 127.0.0.1:6633. You do not need to (and should not) modify this file.
In this Lab, we will also provide you with a skeleton POX controller: lab3controller.py.
This file will be where you will make your modifications to create the firewall.
Running the Code:
To run the controller, place lab3controller.py in the ~/pox/pox/misc directory. You can then launch the controller with the command sudo ~/pox/pox.py misc.lab3controller
To run the mininet file, place it in ~ and run the command sudo python ~/lab3.py
To do this assignment, you will need to be running both files at the same time (in 2 different terminal windows).
The topology that will be created will look as follows:
Rules:
The rules that you will need to implement in OpenFlow for this assignment are:
src ip | dst ip | protocol | action |
any ipv4 | any ipv4 | tcp | accept |
any | any | arp | accept |
any ipv4 | any ipv4 | drop |
Basically, your Firewall should allow all ARP and TCP traffic to pass. However, any other type of traffic should be dropped. It as acceptable to flood the allowable traffic out all ports.
Be careful! Flow tables match the rule with highest priority first, where priority is established based on the order rules are placed in the table.
When you create a rule in the POX controller, you need to also have POX install the rule in the switch. This makes it so the switch remembers what to do for a few seconds. You will be downgraded if your switch simply asks the controller what to do for every packet it receives.
Hint: To do this, look up ofp_flow_mod.
Useful Resources:
http://intronetworks.cs.luc.edu/auxiliary_files/mininet/poxwiki.pdf Inside your VM, the pox/forwarding/l2_learning.py example file.
Reviews
There are no reviews yet.