| 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. |