a runtime verification system for software defined networks
DESCRIPTION
Victor Altukhov, Eugene Chemeritskiy, Vladislav Podymov and Vladimir Zakharov, Lomonosov Moscow State University, MoscowTRANSCRIPT
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
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() :=
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
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]