[[PageOutline]] = TCP Experiment = {{{ #!html

Overview:

In this experiment you will learn how to set up a firewall using OpenFlow. We will use the following network topology for this experiment:
Openflow firewall topology

Prerequisites:

This tutorial expects that you have completed lab 0 and know how to create a new sliver with an existing rspec. If you have not completed lab 0 please do so now.

Tools:

All tools will already be installed at your nodes. This experiment uses OpenFlow and Open vSwitch.

Where to get help:

For any questions or problem with the tutorial ask your TA or Professor for help. If a GENI tool is not working correctly please email help@geni.net
}}} [[Image(design.png, left)]] = Set up = Download the RSPEC from http://www.gpolab.bbn.com/experiment-support/OpenFlowExampleExperiment/openflow-firewall-pc.rspec Using Omni, Portal, or Flack, create a new sliver using this rspec on either ProtoGENI or InstaGENI. For ProtoGENI, use the Utah aggregate manager. On omni, this will need the command {{{ -a pg-utah }}} '''helpful tips''' This section contains a few tips that may help you out if you are using the Open vSwitch implementation provided with this tutorial. If you are using a hardware OpenFlow switch, your instructor can help you find equivalent commands.[[BR]] The Open vSwitch installation provided by the RSpec included in this tutorial is located in ''/opt/openvswitch-1.6.1-F15''. You will find Open vSwitch commands in ''/opt/openvswitch-1.6.1-F15/bin'' and ''/opt/openvswitch-1.6.1-F15/sbin''. If you add these paths to your shell’s ''$PATH'', you will be able to access their manual pages with man. '''Note that ''$PATH'' will not affect sudo, so you will still have to provide the absolute path to sudo; the absolute path is omitted from the following examples for clarity and formatting.''' - '''2.1 ovs-vsctl'''[[BR]] Open vSwitch switches are primarily configured using the ''ovs-vsctl'' command. You may find the ''ovs-vsctl show'' command useful, as it dumps the status of all virtual switches on the local Open vSwitch instance. Once you have some information on the local switch configurations, ''ovs-vsctl'' provides a broad range of capabilities to expand your network setup to more complex configurations for testing and verification. In particular, the subcommands ''add-br'', ''add-port'', and ''set-controller'' may be of interest. - '''2.2 ovs-ofctl''' [[BR]] The switch host configured by the given rspec listens for incoming OpenFlow connections on localhost port 6634. You can use this to query the switch state using the ''ovs-ofctl'' command. In particular, you may find the ''dump-tables'' and ''dump-flows'' subcommands useful. For example, {{{sudo ovs-ofctl dump-flows tcp:127.0.0.1:6634}}} will output lines that look like this: {{{ cookie=0x4, duration=6112.717s, table=0, n packets=1, n bytes=74, idle age=78,priority=5,tcp, nw src=10.10.10.0/24 actions=CONTROLLER:65535 }}} This indicates that any TCP segment with source IP in the 10.10.10.0/24 subnet should be sent to the OpenFlow controller for processing, that it has been 78 seconds since such a segment was last seen, that one such segment has been seen so far, and the total number of bytes in packets matching this rule is 74. - '''2.3 Unix utilities'''[[BR]] The standard ping and ''/usr/sbin/arping'' tools are useful for debugging connectivity (but make sure your controller passes ''ICMP ECHO REQUEST'' and ''REPLY'' packets and ''ARP'' traffic, respectively!), and the command ''netstat -an'' will show all active network connections on a Unix host; the TCP connections of interest in this exercise will be at the top of the listing. The format of netstat output is out of the scope of this tutorial, but information is available online and in the manual pages. [[Image(execute.png,left)]] = Exercises = - '''3.1 Building a Firewall with OpenFlow''' To get started you can download partially complete versions of the necessary configuration files: [http://www.gpolab.bbn.com/experiment-support/OpenFlowExampleExperiment/firewall.rb firewall.rb], [http://www.gpolab.bbn.com/experiment-support/OpenFlowExampleExperiment/fw.conf fw.conf] A firewall observes the packets that pass through it, and uses a set of rules to determine whether any given packet should be allowed to pass. A stateless firewall does this using only the rules and the current packet. A stateful firewall keeps track of the packets it has seen in the past, and uses information about them, along with the rules, to make its determinations. [[BR]] In this exercise, you will build a stateful firewall controller for TCP connections in OpenFlow. The first packet of each connection will be handled by the controller, but all other connection packets will be handled by the OpenFlow-enabled router or switch without contacting your controller. This design will allow you to write powerful firewall rule sets without unduly impacting packet forwarding speeds. Your controller will parse a simple configuration file to load its rules. Complete stateful firewalls often handle multiple TCP/IP protocols (generally at least both TCP and UDP), track transport protocol operational states, and often understand some application protocols, particularly those utilizing multiple transport streams (such as FTP, SIP, and DHCP). The firewall you will implement for this exercise, however, needs handle only TCP, and will not directly process packet headers or data. [[BR]] [[BR]]