new directions for network verification
play

New Directions for Network Verification Aurojit Panda, Katerina - PowerPoint PPT Presentation

New Directions for Network Verification Aurojit Panda, Katerina Argyraki, Mooly Sagiv, Michael Schapira, Scott Shenker Brief Summary of This Talk Context : Proliferation of network verification tools. Build on assumption that the


  1. New Directions for Network Verification Aurojit Panda, Katerina Argyraki, Mooly Sagiv, Michael Schapira, Scott Shenker

  2. Brief Summary of This 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

  3. Brief Summary of This 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

  4. Outline • Background on networks. • Background on network verification. • Verifying mutable networks.

  5. Classical Networking Ted Stevens was right Alice Bob Switch Switch Switch Mallory Trent • Networks provide end-to-end connectivity. • Just contain host and switches. • All interesting processing at the hosts.

  6. Real Networks have Middleboxes! Alice Bob Switch Switch Switch Trent Mallory

  7. Real Networks have Middleboxes! Alice Bob Firewall Switch Switch Switch Trent Mallory • Security (firewalls, IDSs,…).

  8. Real Networks have Middleboxes! Alice Bob Firewall Switch Switch Switch Cache Trent Mallory • Security (firewalls, IDSs,…). • Performance (caches, load balancers,…).

  9. Real Networks have Middleboxes! Alice Bob Firewall Switch Switch Switch Proxy Cache Trent Mallory • Security (firewalls, IDSs,…). • Performance (caches, load balancers,…). • New functionality (proxies,…).

  10. Outline • Background on networks. • Background on network verification. • Verifying mutable networks.

  11. Reachability Invariants • Focus on reachability invariants • Most important in practice, simple to state but already hard Firewall S1 Balancer Firewall Mallory S2

  12. Reachability Invariants • Focus on reachability invariants • Most important in practice, simple to state but already hard Firewall S1 Balancer Firewall Mallory S2 Can S2 receive packets of type T from Mallory?

  13. Reachability Invariants • Focus on reachability invariants • Most important in practice, simple to state but already hard Firewall S1 Balancer Firewall Mallory S2 Can S2 receive “infected” packets from Mallory?

  14. Reachability Invariants • Focus on reachability invariants • Most important in practice, simple to state but already hard Firewall S1 Balancer Firewall Mallory S2 Can S2 receive packets from Mallory without a connection?

  15. Abstractions for Invariants • Operators want to specify packet types using abstractions:

  16. Abstractions for Invariants • Operators want to specify packet types using abstractions: • “infected”

  17. Abstractions for Invariants • Operators want to specify packet types using abstractions: • “infected” • from “authenticated user”

  18. Abstractions for Invariants • Operators want to specify packet types using abstractions: • “infected” • from “authenticated user” • from a given application

  19. 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

  20. 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

  21. Network Verification Today • Switches: Forwarding rules in switches. HSA, Veriflow, NetKAT, etc.

  22. Network Verification Today • Switches: Forwarding rules in switches. HSA, Veriflow, NetKAT, etc. • SDN Controller: Code generating these rules. Vericon, FlowLog, etc.

  23. 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.

  24. Existing Assumptions/Limitations Switches • Limited computational model (rule-based forwarding). • Immutable , functionality only changes with new rules. • Limited set of invariants enforced by networks.

  25. Existing Assumptions/Limitations Switches • Limited computational model (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 .

  26. Existing Assumptions/Limitations Switches • Limited computational model (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.

  27. Existing Assumptions/Limitations Violated by many middleboxes Switches • Limited computational model (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.

  28. Outline • Background on networks. • Background on network verification. • Verifying mutable networks.

  29. Verification of Mutable Networks • Naive approach • Verify a program equivalent to the entire network.

  30. 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).

  31. 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.

  32. Modeling Middleboxes

  33. Modeling Middleboxes Determines what application sent a packet, etc. Classify Packet Complex, proprietary processing.

  34. Modeling Middleboxes Determines what application sent a packet, etc. Classify Packet Complex, proprietary processing. Updating payload is complex (compression, etc.) Update Packet Updating header is simple (fixed format).

  35. Modeling Middleboxes Determines what application sent a packet, etc. Classify Packet Complex, proprietary processing. Updating payload is complex (compression, etc.) Update Packet Updating header is simple (fixed format). Could be simple (remember packets) Update State or complex (update many hash tables).

  36. Modeling Middleboxes Determines what application sent a packet, etc. Classify Packet Complex, proprietary processing. Updating payload is complex (compression, etc.) Update Packet Updating header is simple (fixed format). Could be simple (remember packets) Update State or Forward Packet Always simple: forward or drop packets.

  37. Modeling Middleboxes Oracle: Specify data dependencies and outputs Determines what application sent a packet, etc. Classify Packet Complex, proprietary processing. Updating payload is complex (compression, etc.) Update Packet Updating header is simple (fixed format). Could be simple (remember packets) Update State or Forward Packet Always simple: forward or drop packets.

  38. Modeling Middleboxes Oracle: Specify data dependencies and outputs Determines what application sent a packet, etc. Classify Packet Complex, proprietary processing. Updating payload is complex (compression, etc.) Update Packet Updating header is simple (fixed format). Could be simple (remember packets) Update State or Forward Packet Always simple: forward or drop packets. Forwarding Model: Specify Completely

  39. Example Oracle: Specify data dependencies and outputs Classify Packet Update Packet Update State Forward Packet Forwarding Model: Specify Completely

  40. Example Oracle: Specify data dependencies and outputs Dependencies Classify Packet See all packets in connection (flow). Outputs Update Packet Is packet infected . Update State Forward Packet Forwarding Model: Specify Completely

  41. Example Oracle: Specify data dependencies and outputs Dependencies Classify Packet See all packets in connection (flow). Outputs Update Packet Is packet infected . if ( infected ) { infected_connections.add(packet.flow) Update State } Forward Packet Forwarding Model: Specify Completely

  42. Example Oracle: Specify data dependencies and outputs Dependencies Classify Packet See all packets in connection (flow). Outputs Update Packet Is packet infected . if ( infected ) { infected_connections.add(packet.flow) Update State } if ( packet.flow not in infected_connections ) { Forward Packet forward (packet); } Forwarding Model: Specify Completely

  43. Scaling Verification

  44. Scaling Verification • Middleboxes are “flow-parallel”

Recommend


More recommend