Eugene Chemeritskiy Victor Altukhov An automatic correctness and safety checker for network-wide forwarding policies VERMÓNT – VERifying MONiTor A watchdog for your network Vladislav Podymov Vladimir Zakharov Applied Research Center for Computer Networks Lomonosov Moscow State University

Packet Forwarding Policy What is the intended behavior of a network? • No external flow reaches office mail server • Outgoing flows have to pass a DPI server • Any pair of hosts in office is connected • Departments are isolated from each other • Each route includes at most five hops • No packet loops (reaches its original state) • Host A is unable to connect host B until host B has tried to connect host A before How to ensure your network is configured to operate in compliance with your expectations?

VERMONT core operation principles Specification parser Network model builder V erification engine Policy A holds Topology FlowTables Abstract Syntax Tree BDD relations Formal policy specifications Policy B violated by packet set P Network infrastructure R equirements to network behavior

Mathematical model of SDN

A formal model of SDN {Data Plane abstraction} A B State 1: Header h1 Port #1 Switch #1 State 2: Header h2 Port #1 Switch #2 State 3: Header h3 Port #1 Switch #3 State 4: Header h4 Port #2 Switch #3 h1 h2 h3 h4

Example of PFP specification: prevent packet state cycles aux: lead_to_cycle( x) := In(x) and Exist[y: R_tc( x, y) and Exist[z: R_tc(y,z) and y == z ] ]; main: no_state_cycles() := Foral l [ x: not lead_to_cycle( x) ] ; x y z

90 Mb router configuration files Fat Tree topology with 16 routers 757000 rules 48 tables Stanford University Backbone Network

Activity Verdict Time spend (ms) Initial model constructi on - 3043.687 Packet cycles YES 166.191 Blac k hole s NO 174.845 Routes <= 3 hops NO 293.522 Routes <= 4 hops YES 736.015 Rule insertion seq. / paral. - 100 / 0.3* Rule removal seq. / paral. - 70 / 1* Stanford network verification

controller commands OpenFlow Switches Proxy Server SDN controller Feeder V erifier n PFP specificatio switch messages controller commands switch messages Is command safe? Verifier verdict: PFP violated - block the command PFP holds - apply it to the network Initial network state VERMONT anticipates loading of the switches after a certain command of the controller is applied and blocks it, if it results into violation of the given PFP specifications VERMONT deployment

VERMÓNT – VERifying MONiTor VERMONT checks the compliance of network configurations resulted by the application of a given sequence of commands to an arbitrary set of packet forwarding policies Checking network configuration in dynamic Express your intentions to the behavior of a certain network with our PFP specification language Single-time work Deploy VERMONT in your software-defined network Launch a couple of programs • Prevent network to violate any policies of network safety • Reveal the problems in your configuration • Detect problems in application compatibility Prerequisites Benefit s

A place of VERMONT Currently there are several ways to ensure correct and safe operation of SDN: 3. Verify the application during its operation and detect policy violations in dynamic 2. Write controller application in a specialized language that finds all the mistakes during the compilation phase 1. Apply formal method to controller application in the same manner it is applied to programs

Run-Time network verification tools Tool Model constructi ng time (ms) Model modificatio n time (ms) Policy specificati on language OpenFlo w support VERMONT 2013 3100 100 - 600 FO[TC] full NetPlumber Stanford University 2013 37000 2 - 1000 CTL partial VeriFlow University of Illinois 2013 >4000 68 - 100 A fixed set of properties minimal AP Verifier University of Texas 2013 1000 0.1 A fixed set of properties minimal Anteater University of Illinois 2011 400000 ??? A fixed set of properties none FlowChecker University of North Carolina 2010 1200000 350 - 67000 CTL full

• Fast constructing of an initial model (1÷10 s) • Fast model modification (1÷10 ms) • Fast checking of the policy compliance (1÷10 ms) VERMÓNT – VERifying MONiTor Our nearest goals and current results • Expressive language to specify policies (FO[TC]) • A possibility to localize the violation • Sensible information about the problem • Deeper integration with a controller • Monitoring the operation of the controller applications • Interpreting commands and preventing temporal violations • Application advising and synthesizing safe commands

h1 h2 h3 h4 s1 VERMONT demonstration Static network disjoint Switch s1 connects hosts h1 and h3 only

Forwarding policy for static disjoint / / connect sw i t ch ports f or h1 and h3 aux: f orward( in) : = in[p] == 0x10 and !Exist[out: R(in,out) and out[p] != 0x30]; aux: backward(in) := in[p] == 0x30 and !Exist[out: R(in,out) and out[p] != 0x10]; / / no other connections exist aux: isolated(in) := !Exist[out: R(in, out)]; main: static_disjoint_flows() := Forall[in: forward(in) or backward(in) or isolated(in)]; Switch s1 connects hosts h1 and h3 only

Starting Vermont INIT THERE

Static network disjoint Ping h1 there rules h1 there • Rules to connect hosts h1 and h3 are correct • VERMONT sends commands to switches

Static network disjoint Ping h2 there rules s1 there • Rules to connect hosts h2 and h4 violate forwarding policy • VERMONT blocks spurious commands of the controller • Pings received because the controller tends to delivers packets directly • Technically, we can block them

Static network disjoint Upon error detection: • Proxy server notifies administrator with “command blocked” messages • Proxy server notifies controller with an appropriate error message

VERMONT demonstration h1 h2 h3 h4 s1 Dynamic network disjoint Switch s1 can be used only by one pair of hosts at a time

Dynamic network disjoint Ping h1 there rules h1 there Due to the policy VERMONT always allows the first flow

Dynamic network disjoint Ping h2 there rules s1 there • Rules to connect hosts h2 and h4 violate forwarding policy • VERMONT blocks spurious commands of the controller • Pings received because the controller tends to delivers packets directly • Technically, we can block them

Dynamic network disjoint Ping h2 there rules s1 there • Rules have expiry timeout • When the rules are not used long enough they are extinct from forwarding table • After h1 stops ping h3 • Rule (h1<->h3) is removed • Rule (h2<->h4) becomes valid

THANK YOU FOR YOUR ATTENTION! Eugene Chemeritskiy [email protected] Victor Altukhov [email protected]