Download to read offline
More Related Content
Similar to SNAPL Network Verification
SNAPL Network Verification
- 1. New Directions for NetworkVerification Aurojit Panda, Katerina Argyraki, Mooly Sagiv, Michael Schapira, Scott Shenker
- 2. Brief Summary ofThis Talk• Context: • Proliferation of network verification tools. • Build on assumption that the network state is immutable. • Immutable = Data packets do not change behavior of network • My point: • Many network elements have mutable state • Verifying mutable networks requires new techniques • Two technical challenges: Modeling and Scaling
- 3. Outline • Background onnetworks. • Background on network verification. • Verifying mutable networks.
- 4. Classical Networking Switch Switch Switch • Networksprovide end-to-end connectivity. • Just contain host and switches. • All interesting processing at the hosts. Alice Bob TrentMallory Ted Stevens was right
- 5. Real Networks have Middleboxes! Firewall ProxyCacheSwitch Switch Switch Alice Bob TrentMallory • Security (firewalls, IDSs,…). • Performance (caches, load balancers,…). • New functionality (proxies,…).
- 6. Outline • Background onnetworks. • Background on network verification. • Verifying mutable networks.
- 7. Reachability Invariants • Focuson reachability invariants • Most important in practice, simple to state but already hard Balancer Firewall FirewallMallory S1 S2 Can S2 receive packets of type T from Mallory?Can S2 receive “infected” packets from Mallory?Can S2 receive packets from Mallory without a connection?
- 8. Abstractions for Invariants •Operators want to specify packet types using abstractions: • “infected” • from “authenticated user” • from a given application • How these types are determined in a network varies • Invariants should not depend on these details
- 9. Network Verification Today • Switches:Forwarding rules in switches. HSA, Veriflow, NetKAT, etc. • SDN Controller: Code generating these rules. Vericon, FlowLog, etc. • Firewalls: Verify firewall configuration. Fang, Margrave, etc.
- 10. Existing Assumptions/Limitations Switches • Limited computationalmodel (rule-based forwarding). • Immutable, functionality only changes with new rules. • Limited set of invariants enforced by networks. Controllers • All state and actions are centralized. (Globally ordered) • Data plane itself is immutable. Firewalls • Treated as if they contain Immutable state. • Assume a particular (simple) computational model.
- 11. Outline • Background onnetworks. • Background on network verification. • Verifying mutable networks.
- 12. Verification of Mutable Networks •Naive approach • Verify a program equivalent to the entire network. • Feasibility is not clear • Large, proprietary code bases (Bro ~102K lines of code). • Scalability is crucial • Networks contain several 1000 middleboxes or more.
- 13. Modeling Middleboxes Classify Packet UpdateState Update Packet Forward Packet Determines what application sent a packet, etc. Complex, proprietary processing. Could be simple (remember packets) or complex (update many hash tables). Updating payload is complex (compression, etc.) Updating header is simple (fixed format). Always simple: forward or drop packets. Oracle: Specify data dependencies and outputs Forwarding Model: Specify Completely
- 14. Example Classify Packet Update State UpdatePacket Forward Packet Oracle: Specify data dependencies and outputs Forwarding Model: Specify Completely Outputs Is packet infected. Dependencies See all packets in connection (flow). if (packet.flow not in infected_connections) { forward (packet); } if (infected) { infected_connections.add(packet.flow) }
- 15. Scaling Verification • Middleboxes are“flow-parallel” • State is partitioned between “flows.” • This enables “compositional verification” • 30,000 middlebox networks verified in 5 minutes
- 16. Compositional Verification mbox mbox mbox mbox mbox mbox mbox mbox mbox mbox mbox mbox • Invariantstalk about pairs of hosts. • When flow-parallel, need-only verify path.
- 17. Conclusion • Real networks: •Contain mutable middleboxes. • Used to enforce rich connectivity invariants. • Network verification needs to evolve to handle this. • Several challenges • Right level of abstraction for specifying middleboxes. • Scalability, by leveraging compositional verification. • Future: Tractability of verification. Some pictures taken from the Noun Project
- 18.
- 19. Does State Mutation Matter Firewall •Do we even need to look at state evolution? • Check invariant for all possible states. • Approach used in tools like Margrave. • # of states is small (just whether connection established). • False positives, some states may never occur. Firewall a b Connection started by a to b. Requires a to send packet to b, and b to respond Can a packet from 'a' reach 'b'?
Editor's Notes
- #3 Before we start brief summary so you don’t get bored Context: Lots of network verification tools, but assume networks are immutable. Motivation for this talk: really we are seeing mutable things, net. verification should move on.
- #5 Traditional view of networks: series of tubes Contain hosts and switches; all interesting things happen at hosts. Cherished design principle for networking: End to End principle.
- #6 Networks don’t just have hosts and switches, also have middleboxes. Add middleboxes to enhance functionality. Security, performance, new functions.
- #7 Next, let us look at what has been happening in network verification. Lots of projects, looking at particular parts of the network.
- #8 Reachability is important: networks connect computers. Specified as can some type of packet get between nodes. Some examples.
- #9 Operators buy middleboxes so they can specify types at a high-level. Examples: infected, ... Hard to define (infected depends on the vendor), and don’t want operator to specify this exactly.
- #10 Switches: build on fact that switches have simple computational model. SDN Controllers: popular in networking right now, don’t worry if you don’t know what this is. Firewalls: Popular earlier than the others, organizational policy focused there.
- #11 All of these based on immutability. Even SDN controllers, the idea is that state is centralized and data plane is immutable. Problem: Does not hold for middleboxes, which are increasingly important from a networking perspective.
- #12 Finally, challenges. All of the challenges traditionally associated with verification still hold. Here we look at more network oriented challenges.
- #15 Need to model middleboxes so that We can verify reachability invariants Verification is tractable No false positives. Classification is hard and proprietary. Also how to verify classification identifies all X. Describe others Here is a division we came up with that seems to work for us.
- #16 - An example of what something fits into this.
- #17 Example of middlebox after this.
- #18 Networks are large, much larger than is reasonable to verify in time. Accounting for mutation makes it even worse. Need to scale: we notice that state is already partitioned: allows for compositional verification.