A runtime verification system for Software Defined Networks

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

• 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

What is the intended behavior of a network?

How to ensure your network is configured to operate in compliance with your expectations?

VERMONT core operation principles

Specification parser

Network model builder

Verification engine

Policy A holds

Topology

FlowTables

Abstract Syntax

Tree BDD relations

Formal policy

specifications

Policy B violated by packet set P

Network infrastructure

Requirements 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




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() :=

Forall[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 construction

- 3043.687

Packet cycles

YES 166.191

Black holes

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

SDN controller

Proxy Server

Feeder

Verifier

PFP specification

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

Deploy VERMONT in your software-defined network

Single-time work

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

Pre

req

uis

ite

s B

en

efit

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

constructing time (ms)

Model modification

time (ms)

Policy specification

language

OpenFlow 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

VERMONT demonstration

h1

h2 h3

h4

s1

Static network disjoint

Switch s1 connects hosts h1 and h3 only

Forwarding policy for static disjoint

// connect switch ports for h1 and h3 aux: forward(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


Ping h1 there

rules h1 there

• Rules to connect hosts h1 and h3 are correct

• VERMONT sends commands to switches


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


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


Ping h1 there

rules h1 there

Due to the policy VERMONT always allows the first flow


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


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]

A runtime verification system for Software Defined Networks

Science

Transcript of A runtime verification system for Software Defined Networks