Software Dataplane Verification 1 Plan of lectures so

Software Dataplane Verification 1

Plan of lectures so far • • • Lecture 1 -2 : Motivation, IP review Lectures 3 -9: Data Plane Verification Lecture 10: cellular control plane testing Lectures 11 -12: Test review and test Lecture 13: Data Plane Testing Lecture 14: Verification within a router/really testing 2

Creative Process: Don’t be afraid its all been done before • (Tharp): Honey, its all been done before. Get over it. • That said, one can often apply old ideas in new ways • Example 1: Virtualization. Used by IBM brought back by VMWare 3

Research ideas? via exemplars from PL and Hardware Verification Earlier Exemplar Ternary Simulation, Symbolic Execution (Dill 01, Hardware) Network Verification Header Space Analysis (Kazemian 2003) Certified Development of an OS Sel 4 [Klein 09] Certified Development of a Controller [Guha 13] Specification Mining for HW [Li 10] Mining for Enterprise Policy (Benson ) Exploit Symmetry in Model Checking [Sistla] Exploit Symmetry in Data Center Verification (Plotkin 15)

But scale by Exploiting Domain Structure Technique Structure exploited Header Space (HSA) Limited negation, no loops, small equivalence classes Net Plumber Network Graph, rule dependencies structure ATPG (Testing) Network graph limits size of state space compared to KLEE Symmetry Exploiting Known symmetries because of design (vs on logical structures) Scope for Interdisciplinary work between PL, Hardware CAD, Verification Community and Networking Researchers

. . . What is going on Software Dataplane Verification. 6

Analysis Options Network Analysis: analyze Network wide reachability bugs Router Analysis: analyze bugs Within a router (this paper)

But how can we do this? • Don’t have access to Cisco/Juniper Router Internals. • Also, that would be hardware verification. • But Dobrescu worked on route bricks, a software based router based on Click • Made a case it was scalable and flexible 8

By contrast fixed-Function (e. g. , Cisco) Routers today L 3 L 2 Sta ge 9 IPv 4 St age IPv 6 Sta ge ACL Stag e Packet Parser Packet L 2 • Can’t add new functions or headers (+29 headers) • Can’t move resources between functions • Open Flow allows only entries to be reprogrammed

Spine • Use domain specific symbolic testing to verify software pipelines by finessing three big problems: state space explosion, loops and data structures 10

Software Data Plane Verification [Dobrescu 14] • Verifies actual code of Click software router. • Checks for new physical bugs (e. g. , crash freedom, loops) using symbolic testing. • No path explosion: since router is a pipeline only compose potentially buggy path fragments • Use verified data structures (no pointers). Tradeoff verification ease with runtime cost. • Found bugs: e. g. , IP option + fragmentation.

Avoiding Path explosion and pointer analysis Trie IP Forwarding ACL Qo. S Safe Table IP Forwarding ACL m 3 paths O(m) suspect paths Qo. S

(Modified from) Software Dataplane Verification Mihai Dobrescu and Katerina Argyraki EPFL, Switzerland Awarded Best Paper @ NSDI, 2014 Presented by YH

Motivation: Emergence of Software Dataplanes • Software dataplanes o Network devices that perform packet processing functionalities via software (e. g. , in general-purpose machines) • Flexible compared to traditional hardware switches/routers o o o Easily upgrade obsolete software Quickly add patch to fix bugs, security vulnerabilities Add new functionalities (e. g. , traffic monitoring, sampling, etc. ) 14

Motivation 2: Frequent Reprogramming = Bugs! • Add more “cool” functionalities into software dataplanes Code becomes more complex bugs, bugs! ALL YOUR BUGS BELONG Application Intrusion o Crash, infinite loop, performance degradation, IP Forwarding TO ME! Packet Acceleration Detection etc. o How do we guarantee that new software is bug-free? 15

Software Dataplane Verification • Check whether software satisfies a target property Developer Software Dataplane Verification IDS Source Code Administrator I trust you since it is verified Switch/Router Target Property P P satisfied ! Software Dataplane Verification 16

New Target Properties • 17

Domain-specific Verification • Classifier Check IP Header Check IP Option IP Lookup … 18

Pipeline Decomposition • Identify “suspect segments” from independent elements o Suspect segment = e 3 • Assemble elements and determine target violation o o o Suspect segments = p 1, p 4 Paths are never executed Crash-freedom 19

Loops • IP Option #1 IP Option #2 IP Option #3 … IP Option #m 20

Loop Decomposition Condition • Any shared mutable state is part of packet metadata • Move local variables into packet metadata index: location of next IP option to read index is now symbolic and unconstrained start of IP option may start from anywhere on IP header o • Modification from existing code o Click IP-options: 26 Lo. C (16%) 21

Data Structures • out_port = table[dest_prefix] out_port = table. read(dest_prefix) Table Implementation 22

Data Structures Conditions • Data structures should expose well-known interfaces Our method: key-value store API: read, write, membership test, expiration o • Elements should only use verified data structures Our method: pre-allocated arrays (no dynamic) hash table, longest prefix match o • Tradeoff o o Rewrite existing code (Click IP lookup: 20%, Click NAT: 100%) Consume more memory for pre-allocated arrays 23

Spine: extra idea • Modify code to make it verifiable! Maybe to Click • But at very least can consider it a testing idea to find bugs in rest of code 24

Evaluation • Test on pipelines created with Click o o o Can we perform complete and sound verification of software dataplanes? How does verification time increase with pipeline length? Can we use our tool to uncover bugs, useful performance characteristics, or unintended dataplane behavior? 25

Feasibility • Verified packet-processing elements o Crash-freedom, bounded-execution 26

Scalability • IP router with forwarding table o o o core: 100, 000 entries, edge: 10 entries core fails with large forwarding table edge fails with IP options • Network gateway o o Traffic monitor: loop NAT: data structure Eth. Encap: mutable private state generic fails with loop & data structure 27

Microbenchmark • Pipeline microbenchmark o o o Sequence of simple filtering Add filtering elements generic fails with increasing paths • Loop microbenchmark o o o Simple IP options processing loop Add loop iterations generic fails with exponential increase of execution paths 28

Usefulness • Found number of bugs in Click elements 29

Bugs found in Click • IP fragmentation + Options Infinite Loop • Click NAT element which receives a packet sent and addressed to itself will crash • Some paths are very long • Certain implementations of Loose Source Routing can bypass firewalls 30