1. OpenFlow Switch as a low-impact Firewall
Philip Papadopoulos, Ph.D
University of California, San Diego
San Diego Supercomputer Center
Qualcomm Institute

2. Linux Host-based firewalls today
Per packet inspection
Every single network packet must flow through the firewall
“Every packet that enters networking system (incoming or outgoing) will trigger these (netfilter) hooks as it progresses through the stack)”
User-level programs like iptables, nftables, ufw and others all manipulate the kernel’s netfilter configuration
 The identical “yes” decision is made for every single packet of a flow
Matching must be fast (for efficiency)
Rules are defined around
Fields in network packet
State of connection (e.g. existing vs. new)

3. What can’t be done (easily)
Cannot make decisions based on other “meta” data
Is the IP address part of a “logical” network that is trusted
e.g. something from “sequence labs at UCSD”
IP address is on owned by Institution on the PRP and from one of the DMZ networks.
Many “meta” decisions can be devolved to
Is the IP address of interest part of a (long) and dynamically- changing “acceptable” list
Rule: if IP “on the list” accept, else drop.
Can we put in place an efficient mechanism the easily supports “arbitrary” lists?
Note: iptables supports chains where it is straightforward to have lists of IP subnetworks.

4. Basic Idea – Filter flows, not packets
External
Network
Controller Filters Flows instead of packets
Decision (e.g. TCP) can be made on the SYN and responding ACK
Accept  insert flow rule with specific src/dst [IP,socket]
“List” is interpreted by a Python program
Can be “slow”
OpenFlow Controller
Rules List
HostA
HostB
HostN

5. Pros and Cons of this approach
Arbitrary List of IP address, logical networks, regular expressions, …
+/- decision made once at flow startup. Overhead paid once
Hosts still retain their own netfilters, but these can be much simpler
Can aggregate rules for multiple hosts
local decision
Cons
Once flow is enabled, controller doesn’t see any more traffic … loss of observability
Limited flow-table space in switch (~2K entries)
 not really appropriate for web servers are host groups with 1000s of simultaneous
What happens if controller goes “offline”?

6. Proof of Concept: two groups
Two Groups – Lists of hostnames and IP addresses
-sg (source group), -dg (destination group) not part of standard IP tables
Allow bi-directional ping (lines 1 & 2)
Allow ssh between Groups (lines 3 & 4)
Servers allowed on ports in Group2 (e.g. iperf) (line 5)
Group2 Servers allowed to send from (line 6)
Implement in the RYU Framework
1: iptables -A INPUT -p icmp -sg Group1 -dg Group2 -j ACCEPT
2: iptables -A INPUT -p icmp -sg Group2 -dg Group1 -j ACCEPT
3: iptables -A INPUT -p tcp -dport 22 -sg Group1 -dg Group2 -j ACCEPT
4: iptables -A INPUT -p tcp -dport 22 -sg Group2 -dg Group1 -j ACCEPT
5: iptables -A INPUT -p tcp -dport 5000:5010 -sg Group1 -dg Group2 -j ACCEPT
6: iptables -A INPUT -p tcp -sport 5000:5010 -sg Group2 -dg Group1 -j ACCEPT

7. OpenFlow controller in RYU Framework
Started by a grad student (Kaiyue Yang) for a master’s project
Basic IPtables-styled rule processing.
Learning switch.
Taken up by an undergrad (Brian Greenberg) as an ongoing development project
IPTables-styled rules
Group syntax
Network performance as expected (full rate from the host viewpoint)
Working on regular expression-based matching
Requires reverse DNS and/or local IP->Name mapping

8. How slow can the controller be?
“Sleep (x secs)” inserted between between: Decision made  flow inserted
Delays up to 1.5 seconds saw now discernable changes in iperf
Decision Delay of 0.5s:
iperf -i 2 -t 20 -c
Client connecting to , TCP port 5001
TCP window size: 92.6 KByte (default)
[ 3] local port connected with port 5001
[ ID] Interval Transfer Bandwidth
[ 3] sec GBytes Gbits/sec
[ 3] sec GBytes Gbits/sec
[ 3] sec GBytes Gbits/sec
[ 3] sec GBytes Gbits/sec
[ 3] sec GBytes Gbits/sec
[ 3] sec GBytes Gbits/sec
[ 3] sec GBytes Gbits/sec
[ 3] sec GBytes Gbits/sec
[ 3] sec GBytes Gbits/sec
[ 3] sec GBytes Gbits/sec

9. Decision delay of 2.5 seconds …
[ 3] local port connected with port 5001
[ ID] Interval Transfer Bandwidth
[ 3] sec MBytes Gbits/sec
[ 3] sec Bytes bits/sec
[ 3] sec Bytes bits/sec
[ 3] sec Bytes bits/sec
[ 3] sec Bytes bits/sec
[ 3] sec Bytes bits/sec
[ 3] sec GBytes Gbits/sec
[ 3] sec GBytes Gbits/sec
[ 3] sec GBytes Gbits/sec
[ 3] sec GBytes Gbits/sec
Unhappy behavior seen for longer delays
Packets being dropped by controller. Or other switch – controller interaction
Decision delay looks just like a network outage to the end program. – “Application” Responds as expected
5 seconds decision delay  network “down”

10. IPv6? Other Possibilities
Haven’t started the experiments, yet. In theory should work just as IPv4 – Controller needs to be v6 address aware.
OpenFlow 1.2/1.3/1.4 have evolving support for v6.
Could provide a “registration” service that the controller could consult to allow “roaming” users.
Could base accept/deny decisions on things like “in which AS is the src/dest” …