Firewall

Author: Amer Tahir amertahir@gmail.com
Edited by: KC Wang kc.wang@bigswitch.com
Edited by: Ryan Izard ryan.izard@bigswitch.com

Introduction

The Firewall application has been implemented as a Floodlight Module that enforces ACL rules (Access Control List) on OpenFlow enabled switches in the network using flows and by monitoring packet-in behavior. ACL rules here are just sets of conditions that permit or allow or deny a traffic flow at its ingress switch.

Each packet-in triggered by the first packet(s) of a traffic flow is matched against the set of existing firewall rules. Firewall rules are sorted based on assigned priorities and are matched against the PacketIn's header fields as defined in OFMatch (as of OpenFlow Standard 1.0). The highest priority matching firewall rule determines the action (allow/deny) of the flow. Wildcards can be used as defined in OFMatch. 

Firewall Strategy

The firewall operates in a reactive manner. Firewall rules are sorted by priority at the time they are created (via its REST API). Each incoming packet-in will be compared against the list from the highest priority until either a match is found or the list is exhausted. If a match is found, the rule's action (ALLOW or DENY) is stored in a IRoutingDecision object to be passed on to the rest of the packet-in processing pipeline. This decision eventually reaches Forwarding or any other chosen packet forwarding application (e.g., LearningSwitch). Forwarding pushes a regular forwarding flow entry if the decision is ALLOW, or a drop flow entry if the decision is DENY. In either case, the flow entry sent to the switch must exactly reflect the matching firewall rule's match attributes (including wildcards).

The firewall thus implemented allows rules to have partially overlapping flow space, arbitrated by their priority.  In the simplified example below, all traffic to 192.168.1.0/24 subnet is denied except inbound HTTP (TCP port 80) traffic.

* lower number indicates higher priority

Special care is taken to handle the wildcard in this case. If a flow does not match the first (higher priority) flow but matches the second (lower priority) flow, the flow entry sent by Forwarding to the switch cannot and will not wildcard the destination port; instead, the specific port of that flow is specified in the flow entry, so that future packets of port 80 will not be dropped by the switch without sending a packet-in to the controller.

REST Interface

The Firewall Module exposes REST interface implemented as RestletRoutable using Rest API Service. Please refer to the REST API and Firewall REST API documentation for REST commands and examples.

Limitations

1. The firewall module's DELETE REST API call doesn't delete flow entries on the switch. The rule is only deleted from the controller storage while the flow entry on switch is expected to time out itself per standard timeout behavior. This means the effect of deleting a rule is effective after a certain time, and an existing flow can persist for as long as it has continuous traffic through the switches.
2. In the initial proposal, TCP/UDP port ranges were proposed to be supported by the firewall rules. However, as OpenFlow flow matching mechanism doesn't allow specifying port ranges, this feature was not implemented.