ACL (Access Control List) (Dev)

Owned by Ryan Izard
Last updated: Mar 17, 2015 by Alex Lu
3 min read

Introduction

Floodlight contains a firewall application that enforces ACL in a reactive way. In a reactive way, the controller enforces ACL rules by monitoring Packet-in messages and then pushing relevant flow entries, which increases the forwarding delay. However in a proactive way, the controller enforces ACL rules without being requested by the switch, thus to avoid additional delays. The firewall application also has a defect that it can't remove the flow entries that it pushes in time, it means that after removing an ACL rule from Floodlight's storage, the flow entries relevant to that rule still remain in switches and will not expire until after an idle timeout, which can leading to unpredictable network delay or error.

Compared with the firewall application in Floodlight, the ACL application works in a proactive way and can manage the ACL flow entries in time so as to prevent network error. In more details, the application parses user's REST request for ACL updating and enforces that by static flow entries in a proactive way without monitoring Packet-in messages. It can also remove ACL flow entry timely when related ACL rule is removed.

Service Dependencies

  • IFloodlightProviderService

  • IDeviceService

  • IStorageSourceService

  • IRestApiService

How It Works

The application maps new added ACL rule to ACL flow entries and pushes them into switches. Each ACL flow entry will not expire unless its relevant ACL rule is removed. By pushing ACL flow entries exactly reflect the ACL rule into ingress or egress switches, the application filters IP packets at the switch where packet enters or exits the network.

The application takes advantage of IDeviceService in Floodlight to monitor deviceAdded event so as to store the Accessing Pair [dpid, IP] in a set, an Accessing Pair represents a switch with that dpid connects to a host with that IP, that is to say, given a host IP in the network, the application can search the Accessing Pair Set to find the switch connected to it. e.g. If user requests to add a new ACL rule like "deny flow with src-ip 10.0.0.0/24", the application will insert a static flow entry like "src-ip:10.0.0.0/24, action=deny" into every switch connected to the host with a IP address in subnet 10.0.0.0/24, a single flow entry masked for the entire subnet is inserted into every possible relevant switch, rather than insert a flow entry for every flow with a IP address in the subnet defined in a ACL rule, like the present Floodlight firewall does.

In the application, earlier adding ACL rule always has higher priority because it enforces ACL rules at the time they are added, so the order to add ACL rules is critical. Note that when users request to add a new ACL rule through REST API, the application will firstly check whether the new ACL's match range is covered by existing ACL rules. e.g. If there is a ACL rule like "deny flow with src-ip 10.0.0.0/24", a new ACL rule like "deny flow with src-ip 10.0.0.1/32" is not allowed, and a error message will be returned.

The application is able to enforce a new ACL rule whose src-ip attribute has a wildcard value, which means the rule works on all source IP addresses in the network. In such situation, it is appropriate to push ACL flow entries into the egress switches relevant to the rule's dst-ip attribute rather than all the ingress switches in the network.

The application allows all flows by default, the ACL rule with "ALLOW" action is just used to subtract the allowing flow from the denying flow which has a larger match range, e.g. "allow flow with src-ip 10.0.0.1/32 but deny all other flows with src-ip 10.0.0.0/24". 

Issues and Limitations

The ACL application has the potential to increase the size of flow table needlessly if packets for the rules never actually arrive. As a result, it could in theory slow down the lookup process when any packet is received on the switch.

There are pros and cons to both approaches and there is no perfect solution. The solution of choice should depend on the requirements of a given application/scenario. The ACL application would provide an alternative implementation with different performance implications and having multiple choices is always a good thing!