1. VeriFlow: Verifying Network-Wide Invariants in Real Time
Ahmed Khurshid, Wenxuan Zhou, Matthew Caesar, P. Brighten Godfrey
University of Illinois
Presented by Ofri Ziv
November 2013

2. Outline
Motivation
Design
Evaluation
Example
Conclusion

3. Motivation Networks are complex SDN increases software complexity
Ensure network’s correctness and security
SDN increases software complexity
Multiple applications program the physical network simultaneously
Check network-wide invariants as network evolves
Prevent bugs as they arise
It is very hard to test all its components and protocols to find misconfiguration
Bugs will continue to exist
May result in conflicting rules that alter the intended behavior of one or more applications
Provide immediate warning
Block dangerous changes

4. Bugs Effect
Allow unauthorized packets to enter a secured zone in a network
Make services and the infrastructure prone to attacks
Make critical services unavailable
Affect network performance

5. Configuration Verification (Offline)
Control-plane
Data-plane state
Network behavior
Configuration Verification (Offline)
Problems:
Prediction is difficult
Various configuration languages
Dynamic distributed protocols
Miss control-plane implementation bugs
Input
Predict

6. VeriFlow approach: Data-plane Verification
Configuration
Control-plane
Data-plane state
Network behavior
VeriFlow approach: Data-plane Verification
Advantages:
Less prediction
Closer to actual network behavior
Unified analysis for multiple control-plane protocols
Catch control-plane implementation bugs
Input
Predict

7. Challenges Obtaining real time view of the network Verification speed
Interpose between controller and network elements
Utilize the centralized data-plane view available in an SDN (Software-Defined Network)
Verification speed
Monitor all flows
- Achieve extremely low latency during checks, so that network performance won’t be affected

8. The Tool: VeriFlow
Checks network-wide invariants in real time using data-plane state
Absence of routing loops, black holes, access control violations, etc.
Functions by
Monitoring dynamic changes in the network
Constructing a model of the network behavior
Using custom algorithms to automatically derive whether the network contains errors

9. VeriFlow Overview Report: network invariant violation
Controller
VeriFlow
Generate Equivalence Classes
Generate Forwarding Graphs
Run Queries
Paint the update from the controller
Good rules are sent to the network elements
Rules violating network invariants are diagnosed (invariant violated, affected set of packets)
“Good Rule”
“Bad Rule”
Report:
network invariant violation
Affected set of packets

10. Limit the search space
Generate Equivalence Classes
Generate Forwarding Graphs
Run Queries
Equivalence class: Packets experiencing the same forwarding actions throughout the network
Fw Rules:
Eq. classes:
Find only equivalence classes affected by the update using a trie-based data-structure
Trie data-structure holds the entire network’s forwarding rules.
The leaves of the trie store the actual rules (pairs of (device, rule)), which are represented by the path that leads to them.
For each new rule we traverse the trie until we get a set of overlapping rules. /1 /3

11. Computing Equivalence Classes
A = (Match =0.1, Action, device) B = (Match =0.*, Action, device) Eq. Classes – {0.0}, {0.1} A B * 1 * * * 1 1 1

12. Represent Forwarding Rules
Generate Equivalence Classes
Generate Forwarding Graphs
Run Queries
Forwarding graphs:
Nodes representing network devices
Edges representing forwarding rules
All the information to answer queries
Eq. Class 1
Eq. Class 2

13. Check Invariants Queries: Black holes Routing loops VLANs Isolation
Generate Equivalence Classes
Generate Forwarding Graphs
Run Queries
Queries:
Black holes
Routing loops
VLANs Isolation
Access control policies
Response:
Good Rules  Send flow to network element
Bad Rules  Report: invariant violated, affected set of packets

14. Evaluation #1 – Microbenchmarking VeriFlow run time
Goal: Observe VeriFlow’s different phases contribution to the overall run time
Simulated an IP network
172 routers
Replayed BGP traces
5 million RIB entries
90K BGP updates

15. Evaluation #2 – Effect on TCP connection setup latency
Experiment #2 – Impact of VeriFlow on TCP connection setup latency
Mininet OpenFlow network
10 switches arranged in chain-like topology
A host connected to every switch
NOX controller running “learning switch” app
TCP connections between random pairs of hosts
Overhead imposed by the proxy
Overhead imposed by the verification
Most of the overhead caused by veriFlow is the proxy (only 7% out of 69% is the verification)

16. Future Work Handling packet transformations
Deciding when to check (transactions)
Handling queries other than reachability
Dealing with multiple controllers
Generating additional equivalence classes and their corresponding forwarding graphs, to address the changes in packet header due to the transformations.
VeriFlow may report a violation while processing set of rules one-by-one.
For example: Ensure certain flows don’t use the same link, limit the number of flows on a link.
VeriFlow assumes it has a complete view of the network. In multi-controller scenario this task is challenging.

17. Demo application
hosts = {<ip: (device, port)>} switches = {(sw1, sw2): port} def packet_in(pkt, in_port, device): if (GARP == pkt.proto): if (hosts.has_key(pkt.src_ip)): (d,i) = hosts[pkt.src_ip] delete_flow(match=pkt.src_ip, d) hosts[pkt.src_ip] = (device, in_port) install_flow(match=pkt.src_ip, out=in_port, device) else if (hosts.has_key(pkt.dst_ip)): (d,i) = hosts[pkt.dst_ip] install_flow(match=pkt.dst_ip, out=switches[(device,d)], device) send_packet(pkt, switches[(device,d)], device)

18. Conclusion VeriFlow achieves real-time verification:
A layer between SDN controller & network elements
Find faulty flows issued by SDN applications
Verify network-wide invariants as each flow is inserted
Can prevent a flow from reaching the network
- Rigorous checking of network-wide invariants within hundreds of microseconds as each flow is inserted.