Middlebox Models in Network Verification Research Julius Michaelis Advisor: Cornelius Diekmann Seminar Innovative Internettechnologien WS2015 Chair for Network Architectures and Services Fakultät für Informatik, Technische Universität München Email: [email protected] ABSTRACT by proposing a central, programmable controller. This con- To address the challenges arising from the development of troller is connected to all network devices and can configure computer network management over the past decades, re- them. The devices can notify the controller when they re- searchers have developed a number of tools to assist the op- ceive a certain type of packet, e.g., packets belonging to a eration of networks and help administrators avoid mistakes. new connection. The controller hands these notifications to These tools often follow the approach to verify an exist- a program written by the user. This program can then con- ing network configuration. This poses the problem that the figure the devices accordingly, e.g., create a path for the new behavior of a lot of potentially complex networking device connection. SDN allows to manage nearly all configuration configration has to be supported. The usual approach to in a single language and logically on a single host.1 This this is to develop simple models that only reflect the aspects greatly simplifies the operators tasks and can simplify the of the system that the tool can understand. We survey the verification of the configuration by automated tools. related literature for the use of this type of model. The crucial steps when attempting to verify a configura- tion are defining a model of how the configuration is going Keywords to be understood, and how to translate real configuration Computer Networks, Formal Models, Network Verification into a representation in the model. This holds various chal- lenges, some of them are intrinsic to modeling: if the model 1. INTRODUCTION is too simple, it may not be able to represent reality. If it is Over the past decades, computer networks have grown con- too complex, it may lose its purpose, as reasoning about it siderably in size and complexity. Attempts to fulfil the re- becomes as complicated as reasoning about the original ob- sulting complicated service requirements has given rise to jects. Other challenges are specific to the problem at hand: more and more complicated middleboxes (switches, routers, no tool can possibly understand all the different configura- firewalls, etc. ). Configuring these middlboxes poses an tion languages. Typical tools, such as Anteater [18], Has- enormous challenge to network operators, who have to be sel [16], VeriCon [5], or Exodus [23] are able to understand able to understand numerous configuration languages and subsets of a few configuration languages, such as Cisco IOS manage interoperating distributed configuration. While this or Juniper configurations. This is usually accompanied by earned network operators the title“masters of complexity”[24], the claim that other configuration languages can be easily it is generally seen as problematic. translated in the same manner, without giving further con- siderations to the subtleties of such a translation. Computer networks researchers have recognized that other fields, e.g., programming languages, have developed high In this paper, we survey the related work for the use of mod- level approaches to mitigate complexity and present users els. We focus on the analysis of how systems are modelled. with simple ways of detecting and avoiding errors. In the past decade, research transferring these approaches to net- The rest of this paper is organized into two parts: Section 2 working has gained traction. A number of tools have been contains the survey of the different models and what aspects developed that can be invoked to analyze an existing net- they model. We have grouped the models into subsections work configuration. The usual approach of these tools is to by the type of the device that is modelled. Section 3 con- have the user collect the configuration of his network on a tains a short overview of what purpose the models serve and single machine. This configuration is complex and can thus whether they could be repurposed. not be directly and likely not fully understood. A tool will parse the configuration and translate it into a representa- tion it can reason about: a model. Depending on the type 2. BOX MODELS We continue with the different box models. Section 2.1 sur- of the tool, different reasoning is possible; a very common veys link layer switches, Section 2.2 routers, Section 2.3 SDN application is to find all possible routing loops — or, if none switches, and Section 2.4 Firewalls. Section 2.5 looks at are found, to prove the absence. However, the development models of devices that do not only provide a single function. of such tools holds the same challenges that network man- Additionally, Section 2.6 shows the big switch model. agement holds: a lot of diverse configuration languages and devices has to be supported. Software Defined Network- 1Note that this reflects the understanding of SDN from the ing (SDN) attempts to alleviate this burden for operators view of OpenFlow [20], variants exist. Seminars FI / IITM WS 15/16, 47 doi: 10.2313/NET-2016-07-1_07 Network Architectures and Services, July 2016 Packet Arrives LocalSwitching Fwd Pass PolicyRouting Fwd Route Pass Fwd Packet Departs Fwd StaticRouting Route NetworkSwitching Pass Route Fwd DefaultPolicyRouting Figure 6: Internal flow of packets within a router. Edges are labeled with decisions rendered by the policies at the Figure 1: Margrave’s router model, taken from [22]. 2.1 Link Layer Switches A more abstract model of routing is presented by Xie et When considering only the basic switching functionality, Link al. [25].2 They model a network of routers to be an an- layer switches become relatively simple devices. They nei- notated graph (V, E, ) where the nodes V represent the F ther offer many opportunities for modeling, nor are they very routers, E contains two directed edges for each physical interesting as a target for verification, since most switches link, and the edge labels Fu,v express which packets ∈ F simply have no configuration to verify. Accordingly, there is are allowed to flow over an edge u, v. The routing process not much material in the related literature. is modelled using : a flow over an edge u, v will only be F permitted by Fu,v if the router u has a route to v for that There is one problem that arises when verifying networks specific flow. that contain switches among other devices. Switches are stateful devices, while some verification systems do not sup- To summarize, the Margrave’s model [22] describes the rout- port state. A simple modeling solution for that is presented ing process while the model in [25] abstracts it away to be in Header Space Analysis [16]: a property of a graph. When we generated box transfer functions, we 2.3 SDN Switches chose not to include learned MAC address of end This section surveys selected works on switches in software hosts. This allowed us to unearth problems that defined networking (SDN). Various approaches to SDN exist. can be masked by learned MAC addresses but This section focuses on OpenFlow [20] since it is currently may surface when learned entries expire. the most actively researched variant. We assume that the reader is familiar with its basics. While it could be said that the OpenFlow switch specification [3] itself is based on While this modelling decision has consequences for the mod- a model of a generic networking device, we are not going els of a variety of devices, it implies that switches are always to explore this and instead examine models of OpenFlow in their learning phase, i.e. are effectively replaced by broad- switches. We will continue to denote OpenFlow switches as cast devices. switches in this section for succinctness. The term datapath element would be more accurate since the switches can take 2.2 Routers arbitrary functions. For this section, we will focus solely on layer 3 forwarding. Guha et al. [14] present a fully machine-verified implemen- While Margrave [22] is originally a tool for the analysis of tation of a compiler for the NetCore controller programming firewalls, it also has a detailed understanding of the packet language. For this purpose, they give a detailed model of an forwarding process in Cisco IOS to be able to accurately OpenFlow switch that adheres closely to version 1.0 of the perform its tasks. The model that Margrave uses is shown OpenFlow switch specification [2], including packet process- in Figure 1. The process of forwarding is described as fol- ing and switch-controller interaction. We will examine the lows. First, packets destined to locally attached subnets are most important details and begin with the flow table evalu- filtered out and directly forwarded. All other packets are ation semantics: Guha et al. dedicate significant attention subjected to routing. The second step is thus to handle to how a packet is matched against a flow table entry. Their policy routing — packets with special routing rules that do main concern there is related to behavior that was only made not only depend on the destination address but e.g., on the explicit in later versions of the specification, e.g. [3, 7.2.3.6]: source address, too. The third step is to consider statically § configured routes. All remaining packets are processed using 2The Anteater tool [18] mentioned in Section 1 is based on the default policy. this work. Seminars FI / IITM WS 15/16, 48 doi: 10.2313/NET-2016-07-1_07 Network Architectures and Services, July 2016 K (n, pat, pt1 ptn ) FT .