Changes between Version 3 and Version 4 of GENIEducation/SampleAssignments/OpenFlowAssignment/ExerciseLayout/Execute


Ignore:
Timestamp:
05/20/13 11:02:01 (11 years ago)
Author:
shuang@bbn.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GENIEducation/SampleAssignments/OpenFlowAssignment/ExerciseLayout/Execute

    v3 v4  
    4040
    4141= Exercises =
    42  - 3.1 Building a Firewall with OpenFlow [[BR]]
     42 - '''3.1 Building a Firewall with OpenFlow [[BR]]'''
    4343 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]]
    44  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]]
     44 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]]
     45
    4546  '''Network Setup''' [[BR]]
    4647  [[Image(OpenFlowAssignment1.png, 30%, nolink)]]
     
    4849  The provided RSpec and the files it installs on the hosts it allocates will configure a complete, working network with an Open vSwitch running on the host labeled ''switch''. The Open vSwitch switch is configured to connect to a controller on localhost (that is, the switch host), but no controller is started; until a controller is started on localhost, the Open vSwitch will act like a normal learning switch, forwarding all packets to the appropriate interface based on MAC address. ''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. [[BR]]
    4950  You can test that the network configured correctly by waiting a few moments after Flack or Omni (or whatever GENI tool you are using) suggests that the sliver is ready, and 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]]
    50   '''Firewall Configuration'''
     51
     52  '''Firewall Configuration''' [[BR]]
    5153  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:
    5254  {{{
     
    7981}}}
    8082  You will then find [’firewall.rb’, ’fw.conf’] in ARGV when your controller’s start method is invoked. [[BR]]
     83 
     84  '''Firewall Semantics''' [[BR]]
     85  When an OpenFlow device connects to your controller (that is, you receive a switch_ready controller event), your controller should send it instructions to:
     86   - Pass all packets matching allowed connections to your controller
     87   - Drop all other packets [[BR]]
     88  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 [http://www.openflow.org/documents/openflow-spec-v1.1.0.pdf OpenFlow specification] for more details on flow matching. [[BR]]
     89  Upon receiving a packet from the OpenFlow device (via a ''OFPT_PACKET_IN'' message), your controller should:
     90   - Ensure that the packet matches a rule in the configuration
     91   - Insert a flow match in the OpenFlow device for the complete four-tuple matching the incoming packet
     92   - Insert a flow match in the OpenFlow device for the complete four-tuple matching the opposite direction of the same connection
     93   - Instruct the OpenFlow device to forward the incoming packet normally (using ''OFPP_NORMAL'')
     94  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]]
     95  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]]
     96
     97  '''Limitations of this Approach''' [[BR]]
     98  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]]
     99
     100  '''Hints''' [[BR]]
     101  The following list of hints may help you design and debug your implementation more rapidly.
     102   - Remember that OpenFlow switches are an Ethernet switch first and foremost, and that not all packets on an Ethernet are IP. In particular, your hosts will require ARP in order to pass IP traffic through the switch!
     103   - You may pass ICMP packets without limitation, to make debugging easier.
     104   - The Trema ''Match'' class has a ''compare()'' method that accepts a ''Match'' argument and may be useful to you — consider the ''ExactMatch#from()'' method in conjunction.
     105
     106   '''Extra Credit''' [[BR]]
     107  For extra credit (if permitted by your instructor), generate TCP reset segment at the firewall to reset rejected connections.
     108
     109 - '''3.2 Extending the Firewall''' [[BR]]
     110 OpenFlow controllers can also make complex flow decisions based on arbitrary state. This is one benefit to removing the controller from the network device — the controller is free to perform any computation required over whatever data is available when making decisions, rather than being constrained to the limited computing power and storage of the network device. For this exercise, you will extend the firewall described in Section 3.1 to include rudimentary denial of service prevention using this capability. [[BR]]
     111
     112  '''Extended Firewall Configuration'''[[BR]]
     113  You will extend the firewall configuration language to accept an additional final parameter, an integer representing the number of allowable connections matching a given rule at any point in time. As before, the keyword any will be used to indicate that no limiting is to be performed on the rule. The new firewall configuration syntax is:
     114{{{
     115<ip>/<netmask> <port> <ip>/<netmask> <port> <limit>
     116}}}
     117
     118  '''Connection Limiting Semantics''' [[BR]]
     119  The extended firewall will perform flow matching as before, with one added check: if the number of existing flows allowed by a given rule exceeds the limit specified in the configuration, a new flow matching that rule will be denied. The number of existing flows matching a given rule is computed as the number of currently active flow matches in the OpenFlow device for that rule. You may wish to look into the ''OFPT_FLOW_REMOVED'' message for help in implementing this. If a connection rule specifies any as the flow limit, no limiting will be performed by the controller. [[BR]]
     120  Note that the timeout-based nature of flow removal dictates that small connection limits will be quite limiting. Keep this in mind when testing your firewall!
    81121
    82122
     123 '''3.3 Load Balancing''' [[BR]]
    83124
    84125= [wiki:GENIEducation/SampleAssignments/OpenFlowAssignment/ExerciseLayout/Finish Next: Teardown Experiment] =