Changes between Version 8 and Version 9 of GENIEducation/SampleAssignments/OpenFlowFirewallAssignment/onepage

08/14/13 14:57:52 (7 years ago)



  • GENIEducation/SampleAssignments/OpenFlowFirewallAssignment/onepage

    v8 v9  
    154154  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'''
     156'''Exercises for 3.1'''
    158158  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
    200200  '''Extra Credit''' [[BR]]
    201201  For extra credit (if permitted by your instructor), generate TCP reset segment at the firewall to reset rejected connections.
     204 - '''3.2 Extending the Firewall'''
     206 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.
     208  '''Extended Firewall Configuration'''
     210  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:
     212<ip>/<netmask> <port> <ip>/<netmask> <port> <limit>
     215  '''Connection Limiting Semantics'''
     217  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]]
     219  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!
     222'''Exercises for 3.2'''
     224  1. '''Exercise 1:''' Extend the firewall.rb to take the new firewall configuration file and accept the additional parameter
     226  '''Hints'''
     227 -
     228  -
     229   - You probably want to change the `rule` structure defined in function `add_rule` to add two members: `limit` and `count` to store the maximum number of active flows allowed and the current number of active flows.
     230   - You should also over-ride the function `flow_removed` to subtract `count` when-ever a flow rule expired.
     231   - You might also set the idle_timeout to a smaller number (e.g., 30) so that you do not need to wait for too long before they get removed
     232   - To verify your implementation, use `-P` option in iperf to add TCP flows.