Changes between Version 6 and Version 7 of GENIEducation/SampleAssignments/OpenFlowFirewallAssignment/onepage

08/12/13 15:08:00 (7 years ago)



  • GENIEducation/SampleAssignments/OpenFlowFirewallAssignment/onepage

    v6 v7  
     43 The final topology will match the image at the start of this handout. The specific host names allocated for your experiment will be different, but the topology will be isomorphic. The host labeled ''left'' in the figure is “behind” the firewall, implemented by the Open vSwitch host labeled ''switch''. The host labeled ''router'' handles IP routing for the firewalled network, and every host on the other side of this router (the host labeled ''right'' being the only example here) are “outside” of the firewall.
     46  You can test that the network configured correctly by running ping right from the host allocated for left or vice-versa. Since the fallback switch configuration will act like a normal learning switch, the ping packets should go through. [[BR]]
    4349'''helpful tips'''
    6773 This indicates that any TCP segment with source IP in the 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.
     75You can use 'Trema' to run your switch. 'Trema'' is installed in ''/opt/trema-trema-8e97343.'' Once you have implemented your switch, you can simply use this ''Trema'' install to run it and the Open vSwitch will obey its configuration.
    6977 - '''2.3 Unix utilities'''[[BR]]
    8391 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 your controller. 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.
     95  '''Firewall Configuration''' [[BR]]
     96  The firewall configuration language is very simple. All flows not specified in the configuration are assumed to be forbidden, and the default packet processing policy on the OpenFlow device you are managing should be to drop packets. The configuration language will specify, one flow to a line, the TCP flows that should be permitted to pass the firewall. The syntax is:
     97  {{{
     98  <ip>[/<netmask>] <port> <ip>[/<netmask>] <port>
     99  }}}
     100  Items in angle brackets (<>) represent variable values and items in square brackets ([]) represent optional syntax. The first subnet (IP address plus mask length) and port number are the subnet and port number of the host initiating the connection (that is, sending the first bare SYN), and the second subnet and port number are those of the host accepting the connection. IP addresses are specified as dotted quads (e.g., and netmasks as bit lengths (e.g., 24). If a netmask is omitted it is equivalent to /32. Port numbers are integers. Either or both of the IP address or port numbers may be replaced by the word any, equivalent to in the case of IP address, or to any port number, in the case of port numbers. [[BR]]
     103  A sample configuration that implements a firewall permitting inbound connections to a web server at IP address on port 80, and any outbound connections initiated by hosts inside the firewall (protecting is as follows:
     104  {{{
     105  any any 80
     106 any any any
     107  }}}
     108  All whitespace will be a single ASCII space character, all newlines will be a single ASCII newline character (0x0a) Empty lines (two newlines back-to-back) are permitted.
     111  A connection is allowable if it matches any rule. A connection matches a rule if all four elements of the four-tuple match. Subnet matching uses standard rules, expressed in this pseudocode:
     114boolean subnet_match(IP subnet, int bits, IP addr) {
     115    int32 bitmask =  ̃((1 << 32 - bits) - 1);
     116    IP addrnet = addr & bitmask;
     117    return addrnet ˆ subnet == 0;
     121  Note that rules are not bidirectional; the presence of the first rule in this set does not imply the second:
     123192.168.1.0/24 any any any
     124any any any
     127  The name of a firewall configuration file will be provided on the controller command line. To provide an argument to your controller application (in this case we are using 'Trema' as our controller application), it must be included with the controller file name. For example, to configure your firewall found in ''firewall.rb'' to load ''fw.conf'', you would invoke:
     129trema run ’firewall.rb fw.conf’
     131  You will then find [’firewall.rb’, ’fw.conf’] in ARGV when your controller’s start method is invoked. [[BR]]
     133  '''Firewall Semantics''' [[BR]]
     135  When an OpenFlow device connects to your controller (that is, you receive a switch_ready controller event), your controller should send it instructions to:
     136 -
     137  - 
     138   - Pass all packets matching allowed connections to your controller
     139   * Drop all other packets [[BR]]
     141  Priorities are going to be critical to the correct operation of your controller, so set them carefully. Higher priority rules match before lower priority rules, and the first matching rule is followed. See Section 3.4 of the [ OpenFlow specification] for more details on flow matching. [[BR]]
     143  Upon receiving a packet from the OpenFlow device (via a ''OFPT_PACKET_IN'' message), your controller should:
     144 -
     145  -
     146   - Ensure that the packet matches a rule in the configuration
     147   - Insert a flow match in the OpenFlow device for the complete four-tuple matching the incoming packet
     148   - Insert a flow match in the OpenFlow device for the complete four-tuple matching the opposite direction of the same connection
     149   - Instruct the OpenFlow device to forward the incoming packet normally (using ''OFPP_NORMAL'')
     150  Packets which do not match a rule on the controller should be denied. Because your initial device configuration eliminates most of these packets outright, your controller should not see a large number of these packets. [[BR]]
     151  Because this firewall implementation cannot track the actual state of the TCP connections it is managing, removing accepted connections from the forwarding tables on the OpenFlow device must be handled by timers. OpenFlow rules can be removed by an idle timer as well as expired a fixed period after insertion. For this firewall, use an idle timer of 300 seconds. [[BR]]
     153  '''Limitations of this Approach''' [[BR]]
     154  Note that this approach to implementing a firewall has drawbacks. Because the OpenFlow controller does not, and can not efficiently, track the precise state of the TCP flow it is forwarding, the rules are a little bit sloppy. In particular, connections “in progress” when the firewall comes online are not differentiated from new connections created after the firewall is initialized, and connection closings can not be detected by the controller. The former can be managed by inspecting the packet headers included in the ''OFPT_PACKET_IN'' message when a connection is opened, but the latter cannot easily be mitigated. This means that connections with long idle times (and 300 s is not particularly unusual, in the long tail of TCP connection statistics!) will be disconnected unnecessarily, and new connections reusing recent four-tuples may be passed through the firewall without examination by the controller. [[BR]]
     156'''Exercises and Questions for 3.1'''
     158  1. '''Exercise 1:''' fill up the blanks in function `switch_ready` to insert rules into the openflow switch that allow ICMP and ARP packets to go through
     159  2. '''Exercise 2:''' fill up the blanks in function `packet_in` to insert a flow match in the OpenFlow device that allows the packets (as well as those in the reverse path) that match rules in the fw.conf to pass
     160  3. '''Exercise 3:''' fill up the blanks in function `packet_in` to insert rules that drops all other packets that does not match the rules specified in fw.conf
     162  To verify your implementation, run the following on the switch:
     164 /opt/trema-trema-8e97343/trema run 'firewall.rb fw.conf'
     166  Then try to ping from left to right. Ping should go through since you allowed ICMP packets and ARP packets to pass.
     168  If you are using the fw.conf we provided, try to run a TCP session from left to right using iperf using port 5001, 5002, 5003.
     170  Since in the fw.conf file we provided, we specifically allow TCP to go through port 5001 and 5002, but not port 5003, you should be able to see that iperf gives back throughput results for port 5001 and 5002 but not 5003.
     172  Try play with the code as well as the fw.conf file to setup more rules, then verify your setting via iperf or telnet.
     174 You can check the flow table on the OpenFlow Switch via:
     176sudo /opt/openvswitch-1.6.1-F15/bin/ovs-ofctl dump-flows tcp:
     178 A sample output should be something like the following:
     180NXST_FLOW reply (xid=0x4):
     181 cookie=0x1, duration=165.561s, table=0, n_packets=6, n_bytes=360, idle_age=17,priority=65535,arp actions=NORMAL
     182 cookie=0xa, duration=43.24s, table=0, n_packets=3, n_bytes=222, idle_timeout=300,idle_age=22,priority=65535,tcp,in_port=1,vlan_tci=0x0000,dl_src=00:02:b3:65:d1:2b,dl_dst=00:03:47:94:c7:fd,nw_src=,nw_dst=,nw_tos=0,tp_src=46361,tp_dst=5003 actions=drop
     183 cookie=0x5, duration=147.156s, table=0, n_packets=18289, n_bytes=27682198, idle_timeout=300,idle_age=137,priority=65535,tcp,in_port=1,vlan_tci=0x0000,dl_src=00:02:b3:65:d1:2b,dl_dst=00:03:47:94:c7:fd,nw_src=,nw_dst=,nw_tos=0,tp_src=33385,tp_dst=5001 actions=NORMAL
     184 cookie=0x9, duration=105.294s, table=0, n_packets=4, n_bytes=296, idle_timeout=300,idle_age=60,priority=65535,tcp,in_port=1,vlan_tci=0x0000,dl_src=00:02:b3:65:d1:2b,dl_dst=00:03:47:94:c7:fd,nw_src=,nw_dst=,nw_tos=0,tp_src=46360,tp_dst=5003 actions=drop
     185 cookie=0x7, duration=124.764s, table=0, n_packets=17902, n_bytes=27095256, idle_timeout=300,idle_age=114,priority=65535,tcp,in_port=1,vlan_tci=0x0000,dl_src=00:02:b3:65:d1:2b,dl_dst=00:03:47:94:c7:fd,nw_src=,nw_dst=,nw_tos=0,tp_src=57908,tp_dst=5002 actions=NORMAL
     186 cookie=0x3, duration=165.561s, table=0, n_packets=1, n_bytes=74, idle_timeout=300,idle_age=124,priority=65535,tcp,nw_src=,nw_dst=,tp_dst=5002 actions=CONTROLLER:65535
     187 cookie=0x4, duration=165.561s, table=0, n_packets=1, n_bytes=74, idle_timeout=300,idle_age=147,priority=65535,tcp,nw_src=,nw_dst=,tp_dst=5001 actions=CONTROLLER:65535
     188 cookie=0x2, duration=165.561s, table=0, n_packets=0, n_bytes=0, idle_age=165,priority=65535,icmp actions=NORMAL
     189 cookie=0x6, duration=147.156s, table=0, n_packets=9387, n_bytes=624254, idle_timeout=300,idle_age=137,priority=65535,tcp,nw_src=,nw_dst=,tp_src=5001,tp_dst=33385 actions=NORMAL
     190 cookie=0x8, duration=124.764s, table=0, n_packets=9257, n_bytes=617666, idle_timeout=300,idle_age=114,priority=65535,tcp,nw_src=,nw_dst=,tp_src=5002,tp_dst=57908 actions=NORMAL