A General Framework for Compositional Network Modeling

Ryan Beckett Ratul Mahajan

Microsoft Research University of Washington, Intentionet

ABSTRACT HSA Custom Ternary Custom

We advocate for an approach to network modeling and analysis Stateless forwarding model simulation solver
based on a common intermediate language. Unlike today, where Batfish Custom Concrete BDDs,
each tool builds a custom model and analysis engine for its target Distributed routing model simulation custom
network functionality, we argue that network functionality should
Minesweeper Custom Stable path SMT
be expressed in a common language. This approach makes it eas- Distributed routing model constraints solver
ier to expand formal analysis to new functionality and analyze
interactions between dependent functionalities (e.g., routing and Figure 1: Network verification today. Each tool has its own
packet filtering). We demonstrate the feasibility of this approach by model of target functionality and its own analysis approach.
developing an intermediate language called Zen and three different
analyses for programs in that language. For representative data
plane and control plane functionalities, we find that Zen reduces Stateless Ternary
BDDs
forwarding simulation
the modeling effort by an order of magnitude, while providing
Encapsulation Concrete SMT
analysis performance that matches custom tools. Modeling simulation solver
Middleboxes language
Stable path
CCS CONCEPTS Distributed (Zen) constraints
…
routing
• Networks → Network reliability; • Theory of computation → Model
Datalog
Program verification; • Software and its engineering → Model Virtual Networks checking
checking; Functional languages.
Figure 2: Network verification with model composition.
KEYWORDS
network verification, intermediate verification language
However, as shown in Figure 1, each such tool today is a mono-
ACM Reference Format:
Ryan Beckett and Ratul Mahajan. 2020. A General Framework for Composi- lith, with its own model of the target functionality and its own
tional Network Modeling. In Proceedings of the 19th ACM Workshop on Hot analysis engine. The engine typically includes a front end that en-
Topics in Networks (HotNets ’20), November 4–6, 2020, Virtual Event, USA. codes the domain and a back-end solver that may be custom or
ACM, New York, NY, USA, 8 pages. https://doi.org/10.1145/3422604.3425930 standard solvers such as an SMT solver or BDDs (binary decision
diagram). Any sharing between tools that exists is surface-level.
1 INTRODUCTION For instance, Minesweeper [3] and ARC [12] use Batfish [11] to
As more devices and services connect to the Internet, computer obtain a structured representation of network configuration files,
networks continue to increase in scale and complexity. Formal but then build their own models and their own analysis engines. If
modeling and analysis of network behavior has emerged as a key Batfish is later extended to new functionality, these tools will not
approach to managing such complexity, by finding problems before support that functionality unless they are updated as well.
they cause an outage. This state of affairs makes it hard to expand verification to new
Researchers have developed systems and models to verify a range network functionality because that expansion requires developing
of network functionalities such as packet filtering (access control the full pipeline from scratch, a significant endeavor. Consequently,
lists) [31], packet forwarding [22], routing [11], network address there is a substantial amount of network functionality that is not
translation, and other types of packet transformations [42]. This covered by any tool today, from the link layer (e.g., multiple access
development is also not limited to academia. Large cloud providers, protocols) to the network layer (e.g., EIGRP routing protocol) to the
such as Alibaba [36], Amazon [2], and Microsoft [20], are developing application layer (e.g., HTTP firewalls and URL-based forwarding).
and deploying network verification systems. The extent of unverified network functionality will only increase
as cloud network providers continue to roll out new features and as
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed engineers rapidly innovate atop programmable NICs and switches.
for profit or commercial advantage and that copies bear this notice and the full citation Making matters worse, it is not enough to have some tool to
on the first page. Copyrights for components of this work owned by others than ACM verify each piece of network functionality in isolation because the
must be honored. Abstracting with credit is permitted. To copy otherwise, or republish,
to post on servers or to redistribute to lists, requires prior specific permission and/or a ultimate network behavior depends on the interactions of these
fee. Request permissions from permissions@acm.org. pieces. When an individual piece is verified, it assumes that the
HotNets ’20, November 4–6, 2020, Virtual Event, USA pieces it depends upon are correct. If tools use disparate models,
© 2020 Association for Computing Machinery.
ACM ISBN 978-1-4503-8145-1/20/11. . . $15.00 such assumptions can go unchecked, and bugs can lurk at the
https://doi . org/10 . 1145/3422604 . 3425930 boundary of independently verified pieces.
 We call for a compositional approach to network modeling and payload Va→Vb Va Vb payload Va→Vb
analysis. Illustrated in Figure 2, here, network functionality is mod-
Encapsulation U1 U2 U3 Decapsulation
eled in a common language, and analysis engines target the lan-
guage instead of a specific network functionality. This approach payload Va→Vb U1→U3 payload Va→Vb U1→U3
enables rapid expansion of verification to new functionality by sep- Underlay traversal
arating concerns. Users need only encode domain-specific function-
ality in the modeling language, while authors of analysis engines
Figure 3: An example virtualized network with an illustra-
need only target the modeling language and not a particular do-
tion of how packets flow across it.
main. It also enables holistic analysis across functional pieces. One
can combine the models of multiple pieces to obtain a model of the
joint behavior that can then help uncover bugs at the boundaries.
These capabilities will put us on the path to fully verified networks,
where all critical functionalities and interactions can be verified. There are many ways to virtualize a network, but independent
Our approach is inspired by the software analysis domain. There of the technique used, overlay packets tend to be tunneled. So, as
is a vibrant ecosystem around intermediate languages such as shown in the figure, when Va sends a packet to Vb , this packet is en-
LLVM [25] and Boogie [27] that can encode the semantics of pro- capsulated by U1 within another header with U3 as the destination.
grams in multiple other source languages. A variety of analysis and Then, the packet reaches U3 via the underlay, and it is decapsulated
optimization tools are available for these languages, which benefit and passed to Vb . The overlay and underlay have their own control
all source languages. Boogie also became the basis for writing prov- and data plane systems. That is, the overlay has its own routing,
ably correct programs [26] and full-system verification [18] where forwarding, and packet filtering rules, and the underlay has its own
each instruction was formally verified. Our intent is to similarly version, though the underlay processing may be based on overlay
accelerate innovation for network modeling and analysis. headers as well. The two systems may be completely different, e.g.,
The success of our proposal depends on designing the right the overlay may use an SDN-style control plane and the underlay
intermediate modeling language. It must be expressive enough may use distributed routing protocols.
to encode diverse and complex network functionality, restricted When verifying a virtualized network, it is desirable to verify the
enough to permit efficient automated analysis, and simple enough combined impact of overlay and underlay processing. Using today’s
to reduce the burden of implementing analyses. approach, of building monolithic analysis tools that do not decouple
We present the preliminary design of such an expressive yet com- network behavior modeling from solvers, a virtualized network may
pact modeling language called Zen. At its core, Zen is an expression- be verified using one of two ways. The first is to separately verify the
oriented language with basic types including booleans, integers, overlay and the underlay, using tools appropriate for each network
tuples, objects/structs, lists, and maps. To make it easier to both type. Here, overlay verification must assume that the underlay
encode network functionality and author analysis tools, we embed provides perfect connectivity, and the underlay verification will be
Zen in the C# language. Users write functions that process Zen agnostic to overlays that run atop it. The second method is to build
objects as they would write any C# code. We then use reflection and validate the a combined model of the overlay and underlay.
to automatically analyze and translate objects into logic or a novel Both methods are problematic. The first cannot find problems
state set abstraction that we have developed. that manifest when the two networks interact. For instance, the
We built several analysis engines for Zen including a simulator, underlay may have a buggy packet filter that drops some types
bounded model checker, unbounded model checker, and test input of overlay packets. This bug will not be found if we verify the
generator. We further encoded the functionality of a number of underlay and the overlay separately. The second method has high
network components such as route policies, IP GRE tunnels, and engineering complexity, as it will have to model multiple types of
ACLs, and compare their expressiveness and performance with overlay and underlay combinations.
state-of-the-art tools. We find that Zen can often implement com- Both methods are also hard to evolve because the solvers are
plex functionality in an order of magnitude less code and that its intimately tied to the network model. Assume that a user intro-
analysis is efficient. duces new functionality into the overlay (which is easy because
developers can roll their own using a software update) or the un-
2 MOTIVATION derlay (which is also easy given the advent of programmable NICs,
switches, and P4). Now, we will have to painstakingly update the
To realize our vision of rapid development of network analyses, models as well as the solvers.
we need an intermediate verification language (IVL) that is: (1) Contrast the current approach with a compositional modeling
compositional, and (2) general. approach. Here, the overlay and the underlay will be modeled
Objective #1: Compositional. Consider a setting where multiple separately. Once that is done, a range of solvers become available to
virtual networks, called overlays, run atop a shared physical net- verify the underlay and the overlay. It will also enable the creation
work, called the underlay. Such virtualized networks are the norm of different types of combined models, which can then be verified
in modern data centers because they provide isolation and easy using any available solver.
migration for overlays. Figure 3 shows one such network. Va and Our approach will find bugs at the intersection of the overlay
Vb (virtual machines or containers) are overlay endpoints with a and the underlay and will find overlay-only and underlay-only
(virtual) link between them, and the underlay has three nodes. bugs faster. It will also be easier to evolve. Supporting new overlay
 Analysis Rosette Kaplan Boogie NV Zen 1 public class Header {
HSA [22] ✗ ✗ ✗ ✓ ✓ 2 public Ip DstIp;
AP [41, 42] ✗ ✗ ✗ ✗ ✓ 3 public Ip SrcIp;
Anteater [29] ✓ ✓ ✓ ✗ ✓ 4 ....
Minesweeper [3] ✓ ✓ ✓ ✓ ✓ 5 }
Bonsai [4] ✗ ✗ ✗ ✗ ✓ 6
Shapeshifter [5] ✗ ✗ ✗ ✓ ✓ 7 public class Packet {
8 public Header OverlayHeader;
Table 1: Whether different intermediate verification lan-
9 public Option<Header> UnderlayHeader;
guages (IVLs) can express example network analyses.
10 }
11
12 Zen<byte> Forward(FwdTbl t, Zen<Header> h, int i) {
13 if (i >= t.Rules.Length)
functionality only requires changing the overlay model, and the 14 return 0; // null interface
rest of the system stays as is. 15 var r = t.Rules[i];
While we considered virtualized networks above, the essential 16 return If(Matches(r, h), r.Port, Forward(h, i+1));
characteristics we discussed are universal. The full network be- 17 }
havior is a result of the interaction between multiple pieces (e.g., 18
BGP plus OSPF plus access control lists), different networks have 19 Zen<bool> Matches(FwdRule r, Zen<Header> h) {
different combinations of these pieces, and existing pieces evolve 20 var mask = 0xFFFFFFFF << (32 - r.Prefix.Length);
and new pieces appear constantly. 21 return (h.GetDstIp() & mask) == r.Prefix.Address;
Objective #2: General. Our IVL must be able to express a wide 22 }
range of network analyses. This is where other IVLs for general- Figure 4: Encoding packet forwarding in Zen
purpose software such as Kaplan, Boogie, and Rosette [24, 27, 37]
fall short. They cannot express many verification analyses that
have been highly effective for networks. A key reason is that net- the wrapper type Zen<T> represents a value of type T that is handled
work verification analyses often manipulate sets of objects (e.g., by the Zen library and can be either symbolic or concrete. The third
packets) whereas these IVLs work via compilation to logical con- parameter is the line number to start matching from.
straints (which help find a counter example). There is a recent IVL The function evaluates the header against the forwarding table
for networks, called NV [13]. It too cannot express a wide range of and returns a Zen<byte> representing the output port. It first checks
analyses. Instead, NV bundles a few types of analyses, and modifi- if the line number is beyond the last rule in the forwarding table.
cations are needed to support more types. Table 1 shows examples If so, no rule applied to the header so it returns 0 (null interface).
of network analyses and whether different IVLs can support them. Otherwise, it gets the current rule and makes a call through Zen to
Zen achieves generality via i) a new state set abstraction for rea- either return the rule’s port number if the rule matches the header,
soning about sets of objects; and ii) its embedding as a library in a otherwise to continue on to rule i + 1. Note that the recursive call
general purpose language, which allows users to express analyses takes place through C# and not the Zen library.
by manipulating sets of objects using arbitrarily complex code. Matching the header against the rule is similarly implemented
as a simple function that checks if the header’s destination IP is
3 MODELING NETWORKS WITH ZEN matched by the forwarding rule prefix. The library overloads oper-
We now describe how to model networks in Zen using the virtual ators such as == and & to work seamlessly over Zen values. We can
network example above and then demonstrate how to analyze such encode ACLs in a similar manner as forwarding tables since they
models in the next section. too are a list of prioritized rules.
Encoding a domain. Assume that we want to build a data plane A final step is to encode the semantics of tunneling, whose imple-
model for a network with longest-prefix match based forwarding mentation is shown in Figure 5. There are two additional functions
and access control (ACLs) in both the overlay and underlay, and IP to define the effect of encapsulating and decapsulating a packet
GRE [17] for tunneling. This task can be split into two parts. We first given a GRE tunnel. The first function Encap adds an underlay
create ordinary classes in the host language (C#) that model objects header using the tunnel’s source and destination IP addresses while
such as packets, forwarding tables, and GRE tunnels. Figure 4 shows copying over all other fields. The second function Decap simply
examples for IPv4 packets (line 1) and for packets with two headers, strips off the top header by replacing it with Null<Header>().
an overlay header and an optional underlay header (line 9). Composing network models. Composing models of network el-
After defining the objects to model, we encode the domain seman- ements with Zen is as simple as writing new functions that call
tics by writing functions that process these objects. For example, to functions defined in earlier models. Suppose we want to model com-
encode packet forwarding, one might write the Forward function bined (overlay and underlay) treatment of packets at a switch, ac-
(line 12) that takes three parameters. The first is the forwarding counting for forwarding, ACLs, and tunneling. We might write the
table in which the entries are in descending order of prefix length. functions in Figure 6. The two functions take a packet as input along
The second is a Zen<Header>, which is an IP header. More generally, with an interface, and return a value of type Zen<Option<Packet>>
23 Zen<Packet> Encap(GreTunnel t, Zen<Packet> pkt) { 51 Zen<Option<Packet>> Fwd(Intf[] path, Zen<Packet> p) {
24 if (t == null) return pkt; 52 Zen<Option<Packet>> x = Some(p);
25 var oheader = pkt.OverlayHeader; 53 for (int i = 0; i < path.Length; i++) {
26 var uheader = Create<Header>( 54 var intfIn = path[i];
27 Create<Ip>(t.SrcIp), Create<Ip>(t.DstIp), 55 var intfOut = path[i + 1];
28 oheader.GetDstPort(), oheader.GetSrcPort(), 56 x = If(x.HasValue, FwdIn(intfIn, x.Value), x);
29 oheader.GetProtocol()); 57 x = If(x.HasValue, FwdOut(intfOut, x.Value), x);
30 return Create<Packet>(oheader, Some(uheader)); 58 }
31 } 59 }
32
Figure 7: Modeling forwarding along a given path.
33 Zen<Packet> Decap(GreTunnel t, Zen<Packet> pkt) {
34 if (t == null) return pkt;
35 return Create<Packet>( 60 IEnumerable<PathSet>
36 pkt.OverlayHeader, Null<Header>()); 61 HSA(Intf i, StateSet<Packet> set) {
37 } 62 var q = new Queue<PathSet>();
63 q.Enqueue(new PathSet(i, set));
Figure 5: Encoding IP GRE tunnels in Zen
64 while (!q.IsEmpty()) {
65 var path = q.Dequeue();
66 var intfIn = path.Current; // last interface
38 Zen<Option<Packet>> FwdIn(Intf i, Zen<Packet> p) {
67 var tin = InboundTransformer(intfIn);
39 var allow = Allow(i.AclIn, p);
68 var inSet = tin.TransformForward(path.Set);
40 var decap = Decap(i.GreEnd, p);
69 var forwarded = false;
41 return If(allow, decap, Null<Packet>())
70 foreach (var intfOut in intfIn.Device.Nbrs) {
42 }
71 var tout = OutboundTransformer(intfOut);
43
72 var outSet = tout.TransformForward(inSet);
44 Zen<Option<Packet>> FwdOut(Intf i, Zen<Packet> p) {
73 if (outSet.IsEmpty()) continue;
45 var port = Forward(i.Device, p, 0);
74 forwarded = true;
46 var allow = Allow(i.AclOut, p);
75 q.Enqueue(path.Extend(intfOut, outSet));
47 var encap = Encap(i.GreStart, p);
76 }
48 var pktOut = If(allow, encap, Null<Packet>());
77 if (!forwarded) yield return path;
49 return If(port == i.Id, pktOut, Null<Packet>());
78 } }
50 }
Figure 8: Implementing HSA using Transformers.
Figure 6: Modeling the combined (overlay and underlay)
treatment of packets being processed at a device.
function such as the one in Figure 7 to capture how a flow traverses
a path through the network. Zen can then reason about it:
as output, which is either null if the packet is dropped, or otherwise 79 var f = Function(pkt => Fwd(path, pkt));
a new (possibly modified) packet. The first function applies any 80 f.Find((pkt, result) => result.HasValue);
inbound policy including the ACL and decapsulation, while the
second applies outbound policy, including the forwarding table, The first line creates a ZenFunction that the library can manipulate,
outbound acl, and any encapsulation. and the second line asks for a packet that is delivered along the
path. Packet delivery is indicated by checking that the result of f
4 ANALYZING MODELS WITH ZEN should have a value. Under the covers, Zen can leverage various
forms of symbolic reasoning to find an example (if any) input.
Zen provides a number of ways to analyze network models. To find if a packet can reach node A to B, along any path, we
Simulation. Since Zen models are executable–they are simply C# can iterate over all possible paths between those two nodes. If
code–simulations performed by tools like Batfish [11] are straight- the execution of Find uses SMT-based reasoning, we would have
forward. In particular Zen allows users to pass concrete values of implemented a verifier akin to Anteater [29], though Zen is not
type T to arguments expecting a value of type Zen<T>. For example, limited to just that reasoning method alone.
to simulate what happens to a given packet entering the network at Computing with sets. Many network analyses reason about sets
a given interface, starting with that packet and interface as concrete of objects [4, 5, 22, 41] instead of finding examples. Zen enables
inputs, we will repeatedly call FwdIn and FwdOut functions until the such reasoning via transformers that can manipulate large sets of
packet is dropped or exits the network (along all paths). objects. For example, we can construct a transformer for the FwdOut
Finding (counter) example inputs. Many verification tasks are function for an interface i:
based on finding an input that leads to an undesirable behavior. Zen 81 var f = Function(pkt => FwdOut(i, pkt).HasValue);
enables this primitive using its Find method. Suppose we wanted 82 StateSetTransformer<Packet,bool> t = f.Transformer();
to know if a flow will be delivered along a path. We can write a
 e ::= c | e1 < e2 | e1 + e2 | e1 - e2 | e1 * e2 | e1 & e2 | (e1 | e2 ) | Variable ordering heuristics. For the BDD backend, Zen uses a
not e | e1 or e2 | e1 and e2 | create[τ ](e, . . . ,e) | custom analysis, similar to alias analyses in traditional program-
e.f | e1 [f:=e2 ] | if e1 then e2 else e3 | [] | e1 ::e2 | ming languages, to find a strategy for ordering variables. BDDs can
case e1 of e2 e3 | adapt[τ1 , τ2 ](e) often perform very well but are highly sensitive to the order of their
τ ::= bool | byte | short | ushort | int | uint | long | ulong variables [33]. For example, when two variables are compared for
(τ1 , τ2 ) | {f=τ1 , . . . , f=τn } | List[τ ] | Option[τ ] (in)equality, Zen ensures their orderings will be interleaved, as any
Figure 9: Zen abstract language syntax. other ordering will result in an exponential memory blowup [1].
For instance, in the following function:
83 Function<(int,int),int,bool>((x,y) => x.Item2 == y)
Once a user creates a transformer, Zen can automatically compute
the second component for x must be interleaved with y.
the TransformForward set that represents the set of output objects
If Zen detects that different transformers have different variable
that correspond to the given input objects and TransformReverse
ordering requirements, it performs a second optimization whereby
set that represents the set of input objects that correspond to the
it allocates a new set of unique variables for the second transformer
given output objects. These capabilities enable users to build effi-
rather than reusing those for the first. Instead, it converts between
cient analyses without worrying about the implementation.
the sets of variables dynamically at runtime using a BDD substitu-
Figure 8 shows an implementation of HSA [22], which computes
tion operation. When possible to efficiently order the variables, it
sets of reachable packets from an interface along all paths. It uses
avoids this runtime conversion. Moving this translation to runtime
the inbound and outbound transformers for network interfaces
in many cases allows for implementing transformers that would
(built using FwdIn and FwdOut functions respectively; not shown in
otherwise be impossible due to state space explosion.
the figure) and pushes packet sets through the network to explore
all paths. TransformForward computes the packet sets at each step. Composite data structures. To implement complex data struc-
tures like lists, Zen uses a variable to represent the list length and
5 LANGUAGE another collection of variables to represent the list elements for
The Zen language is designed to be as simple as possible without different sized lengths. It then employs a type-driven merging op-
a priori limiting what users can encode. At its core it is a simple eration similar to that employed by Rosette [38]. The maximum list
expression language, whose abstract syntax (e) is shown in Figure 9. length is controlled via an optional parameter to the Find function.
It supports most logical, arithmetic, and bitwise operations, as
well as ways to create objects, get and update their fields (e.f,
7 PRELIMINARY EVALUATION
e1 [f:=e2 ]), perform conditional logic (if), and add to (e1 ::e2 ) We present results from preliminary experiments that show the
and match on lists (case). The types supported by Zen are given by feasibility and promise of our language-based approach. They show
τ . These include primitive types such as an unsigned 32-bit integer that expressing a range of network functionality is easy and the
(uint) as well as composite types such as tuples, objects, and lists. performance overhead of a general solver that is not functionality
To make Zen extensible, we include a special expression type: specific is acceptable.
adapt[τ1, τ2 ](e) that allows for implementing operations over Expressiveness. To demonstrate Zen’s expressiveness, we write
new types by converting them to types that Zen knows how to implementations for several networking components such as router
handle. For instance, Zen currently implements dictionaries by ACLs and longest-prefix-based forwarding, as well as control plane
representing them as lists of tuples with the most recent elements route policies offered from commercial vendors and more. For each
at the head of the list, and it implements options by representing implementation, we report on the number of lines of code required
them as a class with flag and value fields. to model the component using Zen. Table 2 shows the results. In
general, we find that the implementations are straightforward and
6 IMPLEMENTATION easy to express. Moreover, they compare favorably with existing
The Zen framework is implemented in over 15K lines of C# code and implementations. For example, Minesweeper [3] implements a sim-
available as open source software1 . Zen currently supports several ilar conversion of route-maps to SMT using 1K lines of code, and
backends. One is for bounded model checking that can use either Bonsai [4] implements a similar conversion with BDDs using over
an SMT (via Z3 [8]) solver or a high-performance binary decision 1K lines. We do note that our implementation is not 1:1 feature
diagram (BDD) solver. For the SMT backend, Zen encodes all primi- compatible with Minesweeper: we implement certain features such
tive operations using the theory of bitvectors before bitblasting [16] as the full AS path, which Minesweeper does not, and do not imple-
the formulas to SAT. Another backend uses the transformer API to ment certain features such as OSPF areas that Minesweeper does.
perform unbounded model checking and also leverages the BDD However, the Zen encoding gives both a BDD and SMT backend in
backend. Transform operations such as TransformForward are the same 75 lines of code.
implemented using standard pre/post image computation via exis- Performance. We evaluate Zen’s performance on two verification
tential quantification [7]. All the backends in Zen use the reflection tasks. The first is the time to verify an ACL (a data plane analysis),
capabilities of C# to introspect the types of objects at runtime, and and the second is the time to verify a route map (a control plane
thus build efficient symbolic representations. analysis). In both cases, the verifier’s task is to find inputs (data
packets or routing messages) that match the last line, which requires
1 https://github . com/microsoft/zen analyzing the complete ACL or route map. We generated ACLs and
 Network Component Zen Lines Existing systems implementation processes each packet as expected. This model-
Access Control Lists 28 >500 [11] based testing approach has been successfully used before [30, 39].
LPM-based Forwarding 18 >900 [22] Zen enables a more modular and systematic way to expand such
Route Map Filters 75 >1000 [3, 4] testing to a broad set of network functionalities.
IP GRE tunnels 21 Synthesizing implementations. Zen models are executable, al-
Table 2: Lines of code to express common network function- lowing us to directly generate implementations from them. We
alities in Zen. The third column shows lines of code for en- can compile any Zen function to a real implementation by simply
coding similar functionality in current tools. writing: f.Compile(). This instructs Zen to generate C# IL instruc-
tions, using the System.Reflection.Emit API, which will then
be just-in-time compiled to assembly at runtime. The resulting im-
plementation runs efficiently. An implementation extracted in this
2500 Zen BDD
1500 Zen BDD manner will be in sync with the verified model. This property then
Zen SMT Zen SMT
2000 1250 becomes the foundation for networks whose implementations are
Time (ms)

Time (ms)

Batfish

1500
1000 provably correct (modulo compiler bugs).
750
1000
500
500 250
9 RELATED WORK
0 0 Zen builds on two prior threads of research:
0 5000 10000 15000 20 40 60 80 100
Number of ACL lines Number of route map lines Network verification. There has been a long line of research
on network verification. These works differ in terms of verifi-
Figure 10: Zen microbenchmarks for random ACLs and
cation algorithms used as well as the network functionality tar-
route maps with line tracking and different solvers.
geted: stateless dataplanes [19, 21–23, 29, 40, 41], stateful dataplanes
(e.g., middleboxes) [32, 43], programmable dataplanes (e.g., Click,
route maps of different sizes randomly, and we ran both BDD and P4) [9, 28, 35], distributed routing protocols (e.g., BGP, OSPF) [3–
SMT backends. For the ACL analysis, we also ran Batfish, which 5, 10–12], and centralized control planes [6, 15]. While different
performs the same analysis using a hand-optimized, BDD-based domains come with their own challenges, they commonly employ
encoding. Batfish currently does not support verification of route translations to standard verification technologies. Zen aims to ab-
maps. All experiments were performed on a 8-core Intel i7 machine stract away this translation. Even tools that use non-standard or
with 16GB of RAM, and each data point in the graphs is the mean domain-optimized solvers (e.g., HSA [22]) can incorporate such
value across 100 runs. solvers as new backends in Zen, allowing for many models to reap
Figure 10 shows the results. For the ACL analysis, we see that their benefits. Beyond simplifying tool development, Zen also al-
Zen’s BDD backend is more efficient than the SMT backend. We also lows for easy composition of network models which is challenging
see that this backend performs comparably to the hand-optimized or impossible when different tools are implemented using disparate
Batfish implementation despite having its encoding generated au- technologies and APIs.
tomatically. Thus, general solvers have the potential to match the Intermediate verification languages. Zen draws on prior work
performance of custom ones. on IVLs [24, 27, 34, 37] that aim to simplify verification tasks. It
For the route map analysis, unlike ACL analysis, we see that the shares many common technologies with these languages. For exam-
SMT backend performs better than the BDD backend. In general, ple, its bounded model checker uses a type-aware merging strategy
we have found the SMT backend better for reasoning about data pioneered by Rosette [37]. However, as shown in Table 1, prior IVLs
structures such as lists. These results show the value of having cannot express many common network analyses. To address this
access to multiple backends, so users can pick the one that is best limitation, Zen introduces a new state set abstraction that allows
for their domain and network. This goal would be almost impossible for directly manipulating sets of values in user code.
to achieve with custom encodings as one would have to develop Zen shares the linguistic modeling approach of NV [13]. While
multiple different backends for each functionality. NV provides high level abstractions for encoding certain network
functionalities (e.g., distributed routing) and analyses, Zen’s abstrac-
8 BEYOND MODEL ANALYSIS tions are lower-level and more general. Consequently, it can be used
While our initial focus with Zen is analyzing network models, it has to model a wide range of network functionalities and analyses.
other important use cases. We briefly discuss two such use cases
which we have already prototyped. 10 CONCLUSION
Testing implementations. Zen models can become the basis for Verification tools today are implemented as monoliths, mixing to-
testing the implementations that they model. Given a Zen function gether domain semantics, analysis engines and solver technologies.
f, f.GenerateInputs() produces test inputs with a high-degree of We argue for a compositional approach to network modeling and
coverage based on symbolic execution [14]. We can test that these analysis based on a common intermediate language for expressing
inputs are handled by the implementation as expected. For instance, domain functionality. This approach can enable rapid construction,
if we have a model for an ACL, we can generate test packets that composition, and verification of domain-specific models for new
match on every single rule in the ACL, and then validate that the network functionality and pave the way for fully-verified networks.
REFERENCES [22] P. Kazemian, G. Varghese, and N. McKeown. Header space analysis: Static
[1] A. Aziz, S. Taşiran, and R. K. Brayton. Bdd variable ordering for interacting finite checking for networks. In Proceedings of the 9th USENIX Conference on Networked
state machines. In Proceedings of the 31st Annual Design Automation Conference, Systems Design and Implementation, NSDI’12, pages 9–9, Berkeley, CA, USA, 2012.
DAC ’94, page 283–288, New York, NY, USA, 1994. Association for Computing USENIX Association.
Machinery. [23] A. Khurshid, X. Zou, W. Zhou, M. Caesar, and P. B. Godfrey. Veriflow: Verifying
[2] J. Backes, S. Bayless, B. Cook, C. Dodge, A. Gacek, A. J. Hu, T. Kahsai, B. Ko- network-wide invariants in real time. In Presented as part of the 10th USENIX
cik, E. Kotelnikov, J. Kukovec, S. McLaughlin, J. Reed, N. Rungta, J. Sizemore, Symposium on Networked Systems Design and Implementation (NSDI 13), pages
M. Stalzer, P. Srinivasan, P. Subotić, C. Varming, and B. Whaley. Reachability 15–27, Lombard, IL, 2013. USENIX.
analysis for aws-based networks. In I. Dillig and S. Tasiran, editors, Computer [24] A. S. Köksal, V. Kuncak, and P. Suter. Constraints as control. In Proceedings of the
Aided Verification, pages 231–241, Cham, 2019. Springer International Publishing. 39th Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming
[3] R. Beckett, A. Gupta, R. Mahajan, and D. Walker. A general approach to network Languages, POPL ’12, page 151–164, New York, NY, USA, 2012. Association for
configuration verification. In Proceedings of the Conference of the ACM Special Computing Machinery.
Interest Group on Data Communication, SIGCOMM ’17, pages 155–168, New York, [25] C. Lattner and V. Adve. Llvm: A compilation framework for lifelong program
NY, USA, 2017. ACM. analysis and transformation. In Proceedings of the International Symposium on
[4] R. Beckett, A. Gupta, R. Mahajan, and D. Walker. Control plane compression. In Code Generation and Optimization: Feedback-Directed and Runtime Optimization,
Proceedings of the 2018 Conference of the ACM Special Interest Group on Data Com- CGO ’04, page 75, USA, 2004. IEEE Computer Society.
munication, SIGCOMM ’18, page 476–489, New York, NY, USA, 2018. Association [26] K. R. M. Leino. Dafny: An automatic program verifier for functional correctness.
for Computing Machinery. In Proceedings of the 16th International Conference on Logic for Programming,
[5] R. Beckett, A. Gupta, R. Mahajan, and D. Walker. Abstract interpretation of dis- Artificial Intelligence, and Reasoning, LPAR’10, page 348–370, Berlin, Heidelberg,
tributed network control planes. Proc. ACM Program. Lang., 4(POPL), December 2010. Springer-Verlag.
2019. [27] K. R. M. Leino and P. Rümmer. A polymorphic intermediate verification language:
[6] M. Canini, D. Venzano, P. Perešíni, D. Kostić, and J. Rexford. A NICE way to Design and logical encoding. In J. Esparza and R. Majumdar, editors, Tools and
test openflow applications. In Presented as part of the 9th USENIX Symposium Algorithms for the Construction and Analysis of Systems, pages 312–327, Berlin,
on Networked Systems Design and Implementation (NSDI 12), pages 127–140, San Heidelberg, 2010. Springer Berlin Heidelberg.
Jose, CA, 2012. USENIX. [28] J. Liu, W. Hallahan, C. Schlesinger, M. Sharif, J. Lee, R. Soulé, H. Wang, C. Caşcaval,
[7] E. M. Clarke, T. A. Henzinger, H. Veith, and R. Bloem. Handbook of Model Checking. N. McKeown, and N. Foster. P4v: Practical verification for programmable data
Springer Publishing Company, Incorporated, 1st edition, 2018. planes. In Proceedings of the 2018 Conference of the ACM Special Interest Group on
[8] L. De Moura and N. Bjørner. Z3: An efficient smt solver. In Proceedings of Data Communication, SIGCOMM ’18, pages 490–503, New York, NY, USA, 2018.
the Theory and Practice of Software, 14th International Conference on Tools and ACM.
Algorithms for the Construction and Analysis of Systems, TACAS’08/ETAPS’08, [29] H. Mai, A. Khurshid, R. Agarwal, M. Caesar, P. B. Godfrey, and S. T. King. De-
page 337–340, Berlin, Heidelberg, 2008. Springer-Verlag. bugging the data plane with anteater. In Proceedings of the ACM SIGCOMM 2011
[9] M. Dobrescu and K. Argyraki. Software dataplane verification. In 11th USENIX Conference, SIGCOMM ’11, pages 290–301, New York, NY, USA, 2011. ACM.
Symposium on Networked Systems Design and Implementation (NSDI 14), pages [30] K. L. McMillan and L. D. Zuck. Formal specification and testing of quic. In Proceed-
101–114, Seattle, WA, 2014. USENIX Association. ings of the ACM Special Interest Group on Data Communication, SIGCOMM ’19,
[10] S. K. Fayaz, T. Sharma, A. Fogel, R. Mahajan, T. Millstein, V. Sekar, and G. Varghese. page 227–240, New York, NY, USA, 2019. Association for Computing Machinery.
Efficient network reachability analysis using a succinct control plane representa- [31] T. Nelson, C. Barratt, D. J. Dougherty, K. Fisler, and S. Krishnamurthi. The
tion. In 12th USENIX Symposium on Operating Systems Design and Implementation margrave tool for firewall analysis. In Proceedings of the 24th International
(OSDI 16), pages 217–232, Savannah, GA, November 2016. USENIX Association. Conference on Large Installation System Administration, LISA’10, page 1–8, USA,
[11] A. Fogel, S. Fung, L. Pedrosa, M. Walraed-Sullivan, R. Govindan, R. Mahajan, 2010. USENIX Association.
and T. Millstein. A general approach to network configuration analysis. In 12th [32] A. Panda, O. Lahav, K. Argyraki, M. Sagiv, and S. Shenker. Verifying reachability in
USENIX Symposium on Networked Systems Design and Implementation (NSDI 15), networks with mutable datapaths. In Proceedings of the 14th USENIX Conference on
pages 469–483, Oakland, CA, May 2015. USENIX Association. Networked Systems Design and Implementation, NSDI’17, pages 699–718, Berkeley,
[12] A. Gember-Jacobson, R. Viswanathan, A. Akella, and R. Mahajan. Fast control CA, USA, 2017. USENIX Association.
plane analysis using an abstract representation. In Proceedings of the 2016 ACM [33] R. Rudell. Dynamic variable ordering for ordered binary decision diagrams. In
SIGCOMM Conference, SIGCOMM ’16, pages 300–313, New York, NY, USA, 2016. Proceedings of the 1993 IEEE/ACM International Conference on Computer-Aided
ACM. Design, ICCAD ’93, page 42–47, Washington, DC, USA, 1993. IEEE Computer
[13] N. Giannarakis, D. Loehr, R. Beckett, and D. Walker. Nv: An intermediate language Society Press.
for verification of network control planes. In Proceedings of the 41st ACM SIGPLAN [34] S. F. Siegel, M. Zheng, Z. Luo, T. K. Zirkel, A. V. Marianiello, J. G. Edenhofner,
Conference on Programming Language Design and Implementation, PLDI 2020, M. B. Dwyer, and M. S. Rogers. Civl: the concurrency intermediate verifica-
page 958–973, New York, NY, USA, 2020. Association for Computing Machinery. tion language. In SC ’15: Proceedings of the International Conference for High
[14] P. Godefroid, N. Klarlund, and K. Sen. Dart: Directed automated random testing. Performance Computing, Networking, Storage and Analysis, pages 1–12, 2015.
PLDI ’05, page 213–223, New York, NY, USA, 2005. Association for Computing [35] R. Stoenescu, D. Dumitrescu, M. Popovici, L. Negreanu, and C. Raiciu. Debugging
Machinery. p4 programs with vera. In Proceedings of the 2018 Conference of the ACM Special
[15] A. B. M. Gomes, F. A. M. Alves, R. S. Ferreira, and J. A. M. Nacif. Vericonn: a tool Interest Group on Data Communication, SIGCOMM ’18, pages 518–532, New York,
to generate efficient interconnection networks for post-silicon debug. In 2015 NY, USA, 2018. ACM.
16th Latin-American Test Symposium (LATS), pages 1–6, March 2015. [36] B. Tian, X. Zhang, E. Zhai, H. H. Liu, Q. Ye, C. Wang, X. Wu, Z. Ji, Y. Sang,
[16] L. Hadarean, K. Bansal, D. Jovanović, C. Barrett, and C. Tinelli. A tale of two M. Zhang, D. Yu, C. Tian, H. Zheng, and B. Y. Zhao. Safely and automatically
solvers: Eager and lazy approaches to bit-vectors. pages 680–695, 07 2014. updating in-network acl configurations with intent language. In Proceedings of
[17] S. Hanks, T. Li, D. Farinacci, and P. Traina. Generic Routing Encapsulation over the ACM Special Interest Group on Data Communication, SIGCOMM ’19, page
IPv4 networks, 1994 (accessed June, 2020). 214–226, New York, NY, USA, 2019. Association for Computing Machinery.
[18] C. Hawblitzel, J. Howell, M. Kapritsos, J. R. Lorch, B. Parno, M. L. Roberts, S. Setty, [37] E. Torlak and R. Bodik. Growing solver-aided languages with rosette. In Proceed-
and B. Zill. Ironfleet: Proving practical distributed systems correct. In Proceedings ings of the 2013 ACM International Symposium on New Ideas, New Paradigms, and
of the 25th Symposium on Operating Systems Principles, SOSP ’15, page 1–17, New Reflections on Programming & Software, Onward! 2013, page 135–152, New York,
York, NY, USA, 2015. Association for Computing Machinery. NY, USA, 2013. Association for Computing Machinery.
[19] A. Horn, A. Kheradmand, and M. Prasad. Delta-net: Real-time network verifi- [38] E. Torlak and R. Bodik. A lightweight symbolic virtual machine for solver-
cation using atoms. In 14th USENIX Symposium on Networked Systems Design aided host languages. In Proceedings of the 35th ACM SIGPLAN Conference on
and Implementation (NSDI 17), pages 735–749, Boston, MA, March 2017. USENIX Programming Language Design and Implementation, PLDI ’14, page 530–541, New
Association. York, NY, USA, 2014. Association for Computing Machinery.
[20] K. Jayaraman, N. Bjørner, J. Padhye, A. Agrawal, A. Bhargava, P.-A. C. Bisson- [39] M. Utting and B. Legeard. Practical Model-Based Testing: A Tools Approach. Morgan
nette, S. Foster, A. Helwer, M. Kasten, I. Lee, A. Namdhari, H. Niaz, A. Parkhi, Kaufmann Publishers Inc., San Francisco, CA, USA, 2006.
H. Pinnamraju, A. Power, N. M. Raje, and P. Sharma. Validating datacenters [40] G. G. Xie, Jibin Zhan, D. A. Maltz, Hui Zhang, A. Greenberg, G. Hjalmtysson, and
at scale. In Proceedings of the ACM Special Interest Group on Data Communica- J. Rexford. On static reachability analysis of ip networks. In Proceedings IEEE
tion, SIGCOMM ’19, page 200–213, New York, NY, USA, 2019. Association for 24th Annual Joint Conference of the IEEE Computer and Communications Societies.,
Computing Machinery. volume 3, pages 2170–2183 vol. 3, March 2005.
[21] P. Kazemian, M. Chang, H. Zeng, G. Varghese, N. McKeown, and S. Whyte. Real [41] H. Yang and S. S. Lam. Real-time verification of network properties using atomic
time network policy checking using header space analysis. In Presented as part predicates. IEEE/ACM Trans. Netw., 24(2):887–900, April 2016.
of the 10th USENIX Symposium on Networked Systems Design and Implementation [42] H. Yang and S. S. Lam. Scalable verification of networks with packet transformers
(NSDI 13), pages 99–111, Lombard, IL, 2013. USENIX. using atomic predicates. IEEE/ACM Transactions on Networking, 25(5):2900–2915,
 2017. Networked Systems Design and Implementation (NSDI 20), pages 181–200, Santa
[43] Y. Yuan, S.-J. Moon, S. Uppal, L. Jia, and V. Sekar. Netsmc: A custom symbolic Clara, CA, February 2020. USENIX Association.
model checker for stateful network verification. In 17th USENIX Symposium on