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


Ignore:
Timestamp:
08/14/13 14:57:52 (6 years ago)
Author:
epittore@bbn.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • 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]]
    155155
    156 '''Exercises and Questions for 3.1'''
     156'''Exercises for 3.1'''
    157157
    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.
     202
     203
     204 - '''3.2 Extending the Firewall'''
     205
     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.
     207
     208  '''Extended Firewall Configuration'''
     209
     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:
     211{{{
     212<ip>/<netmask> <port> <ip>/<netmask> <port> <limit>
     213}}}
     214
     215  '''Connection Limiting Semantics'''
     216
     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]]
     218
     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!
     220
     221
     222'''Exercises for 3.2'''
     223
     224  1. '''Exercise 1:''' Extend the firewall.rb to take the new firewall configuration file and accept the additional parameter
     225
     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.