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. However in a proactive way, the controller enforces ACL rules without being requested by the switch, thus to avoid additional delays.
This ACL 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 it generated timely when related ACL rule is removed.
Issues
There are some issues you should know before using the ACL application:
- In the application, earlier added ACL rule always has higher priority because the application enforces ACL rules at the time they are added, so the order to add ACL rules is critical. The application handles the priority carefully so that earlier generated ACL flow entry in the same switch always has higher priority(max to 30000), so as to ensure the priority definition in ACL rules.
- All the ACL flow entries the application generated are static flow entries named like: "ACLRule_[Rule Id]_[Switch_DPID]", which can be operated by the Static Flow Pusher API.
- The application is used for filtering IP packets between different hosts, so the user has to specific either src-ip or dst. The application enforces a new ACL rule by its src-ip attribute by default, that is to say, pushes ACL flow entries into the ingress switches connecting to the host with the source IP address defined in src-ip. The application is also able to enforce a new ACL rule without src-ip attribute value, which means the rule works on all source IP addresses in the network. In such situation, it pushes 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". An ACL rule with "ALLOW" action will be mapped into ACL flow entries with "Output to controller" action so as to let the controller determine how to forward that flow.
ACL REST Interface
Add an ACL rule:
curl -X POST -d '{"src-ip":"10.0.0.1/32","dst-ip":"10.0.0.2/32","action":"deny"}' http://<controller_ip>:8080/wm/acl/rules/json |
The application will generate an distinct id for every new added rule.
Properties of an ACL rule:
| Key | Value | Notes |
|---|
| nw-proto | string | "TCP" or "UDP" or "ICMP" (ignoring case) |
| src-ip | IPv4 address[/mask] | Either src-ip or dst-ip must be specified. |
| dst-ip | IPv4 address[/mask] | Either src-ip or dst-ip must be specified. |
| tp-dst | number | Valid when nw-proto == "TCP" or "UDP". |
| action | string | "DENY" or "ALLOW" (ignoring case), set to "DENY" if not specified. |
Listing all ACL rules:
curl http://<controller_ip>:8080/wm/acl/rules/json | python -mjson.tool |
Remove an ACL rule:
curl -X DELETE -d '{"ruleid":"1" }' http://<controller_ip>:8080/wm/acl/rules/json |
Remove all ACL rules:
curl http://<controller_ip>:8080/wm/acl/clear/json |