Keyword(s): Abstract:

©

End-to-End Network Access Analysis

Sruthi Bandhakavi, Sandeep Bhatt, Cat Okita, Prasad Rao

HP LaboratoriesHPL-2008-28R1

No keywords available.

Network security administrators cannot always accurately tell which end-to-end accesses are permittedwithin their network, and which ones are not. The problem is that every access is determined by theconfigurations of multiple, separately administered, components along a path. Furthermore, configurationsevolve over time, and a small change in one configuration file can have widespread impact on theend-to-end accesses. Short of exhaustive testing, which is prohibitively time consuming and impractical,there are no good solutions to analyze end-to-end flows from network configurations. This paper presents atechnique to analyze all the end-to-end accesses from the configuration files of network routers andfirewalls. The contributions of this paper are to engineer solutions for real network instances that are basedon (i) generic templates for network components and (ii) a more general treatment of firewalls, includingways to deal with certain state-dependent filter rules, and (iii) efficient generation of firewall access controlrules to meet desired end-to-end flow requirements. Our goal is to help network security engineers andoperators quickly determine configuration errors that may cause unexpected access behavior.

External Posting Date: November 21, 2008 [Fulltext] Approved for External PublicationInternal Posting Date: November 21, 2008 [Fulltext]

Copyright 2008 Hewlett-Packard Development Company, L.P.

End-to-end Network Access Analysis

Sruthi Bandhakavi∗, Sandeep Bhatt, Cat Okita†, Prasad Rao

Hewlett-Packard Laboratories

5 Vaughn Drive Princeton, NJ 08540

Abstract

Network security administrators cannot always accurately tell which end-to-end accesses are permit-

ted within their network, and which ones are not. The problem is that every access is determined by

the con�gurations of multiple, separately administered, components along its path. Furthermore, con-

�gurations are constantly evolving, and a small change in one con�guration �le can have widespread

impact on the end-to-end accesses. Short of exhaustive testing, which is prohibitively time consuming

and impractical, there are no good solutions to analyze end-to-end �ows from network con�gurations.

This paper presents a technique to analyze all the end-to-end accesses from the con�guration �les

of network routers, switches and �rewalls. Our goal is to help network security engineers and operators

quickly determine con�guration errors that may cause unexpected behavior such as unwanted accesses

or unreachable services. Our technique can be also be used as part of the change management process,

to help prevent network miscon�guration.

We build upon the work in [6], which presented an abstract formulation of the problem. The contri-

butions of this paper are to engineer solutions for real network instances that are based on (i) generic

templates for network components and (ii) a more general treatment of �rewalls, including ways to deal

with certain state-dependent �lter rules, and (iii) e�cient generation of �rewall access control rules to

meet desired end-to-end �ow requirements.

1 Introduction

This paper focuses on the problem of determining all possible end-to-end accesses in a network from thestatic con�gurations of network routers and �rewalls. We illustrate the problem by describing a typicalenvironment, with three related examples that, extrapolated to enterprise scale networks, are di�cult andcostly to diagnose and correct.

Figure 1 shows a common network con�guration for a managed service provider to provide data cen-ter space and management services for enterprise customers. The network is broken into three parts - thecustomer compartment, an access compartment, which is shared between multiple customers, and the man-agement and monitoring compartment. The network was designed to be highly available, with multiplepotential paths through each compartment, depending on the status of the various devices.

The core of the customer installation is a pair of layer 3 switches ( Cust_Switch-1 and Cust_Switch-2) in a failover con�guration. The switches were connected to the management and monitoring infrastructureof the service provider via a pair of �rewalls in an active/passive failover con�guration.

∗Current address: Department of Computer Science, University of Illinois at Urbana-Champaign. This work was done as asummer intern at HP Laboratories.†HP Services Global Delivery ITO

1

Figure 1: A Single�Site Managed Service Provider Network

Our �rst issue was straightforward - monitoring tra�c from the Management and Monitoring zone didnot reach the customer servers. This issue is most often due to missing or miscon�gured access control lists(ACLs) or routes.

A check at the Customer �rewall, showed that no tra�c was being received from the monitoring hosts.When the Access Firewall was examined, it was immediately apparently that there were no ACLs in placeto permit tra�c to pass from the Management and Monitoring compartment to the customer.

Shortly after the initial monitoring issue had been resolved, the customer requested that their existingsite be duplicated at a remote location, to provide redundancy and disaster recovery capabilities.

As shown in Figure 2, the compartments were essentially duplicated between the two sites, Boston andAtlanta. The customer provisioned a primary and backup �ber link between the sites to extend their networkand moved half of their existing servers to the new site. The Management and Monitoring VLAN was alsoextended between the two sites.

Since the Atlanta site was designed to be fully redundant, the expectation was that monitoring tra�cfor devices in Atlanta would be routed through Atlanta, and monitoring tra�c for Boston would be routedthrough Boston.

While installing the Atlanta site, a number of issues preventing management and monitoring of the new

2

Figure 2: A Dual�Site Managed Service Provider Network, Boston on the left and Atlanta on the right.

servers were discovered. Ultimately, each issue was caused by one or more con�guration errors, but theprocess of identifying and resolving (if possible) each issue provided signi�cant challenges.

Initial tests of monitoring and management for the new site revealed that there was no monitoringconnectivity between the Management and Monitoring compartment to the customer servers at the new site.

Initial debugging focused on the Atlanta �rewalls, and an immediate issue was discovered - the �rewallsdid not have a route to the monitoring servers.

Once a route to the Management and Monitoring compartment in Atlanta had been added to the Atlantacustomer �rewalls, the nature of the problem shifted. As shown in Figure 3, when monitoring connectionswere attempted from the Management and Monitoring zone to the Atlanta Customer Server VLAN, ICMPmonitoring for up/down status was usually successful, but SNMP monitoring and SSH tra�c failed.

Since the previous issue had been the result of a �rewall miscon�guration, and ICMP connections weresuccessful, the debugging process continued to focus on the Atlanta customer �rewalls.

It soon became evident that the monitoring tra�c destined for the Atlanta customer servers was notarriving via the Atlanta �rewalls. A check of the Boston �rewalls determined that the monitoring tra�cdestined for the Atlanta servers was being routed incorrectly, via Boston, and arriving in Atlanta via thecustomers' internal network.

3

Figure 3: Miscon�gured routes and �rewalls denied monitoring services

Like most modern �rewalls, the �rewalls used the keep state feature; using this feature the �rewallstrack TCP and UDP connections that have been started, and drop any tra�c for which they do not havea starting record. ICMP is not considered to be stateful. Thus, while the Boston �rewalls recorded thestart of inbound connections from the Monitoring host to the Server VLAN in Atlanta (that were incorrectlyrouted through Boston), returning tra�c was correctly sent via the Atlanta �rewalls, which did not have arecord of the inbound tra�c, resulting in the tra�c being dropped. On the other hand, since ICMP is notstateful, returning ICMP was permitted to exit the Atlanta �rewalls, and ultimately returned successfullyto the Management and Monitoring compartment.

Due to time pressures, the initial solution to the monitoring issue was to modify the customer routing,to return all monitoring tra�c through Boston. This created a single point of failure, as a failure in Bostonwould result in the loss of management and monitoring of the Atlanta servers.

Unfortunately, while the monitoring issues appeared to have been resolved, every time the layer-3 switchesin Atlanta were rebooted, monitoring for all hosts in Atlanta would fail again. The problem was that onthe Cisco router the �oating static routes (which generally have lower precedence than the dynamic routes)come up �rst during a reboot and get precedence over the dynamic routes [3]. This is a classic example of alatent failure which can be caught by con�guration analysis.

4

In all examples above, the end-to-end failures resulted from unintended interactions between the miscon-�gurations of the router and the �rewall access control rules. In a large enterprise network that is managedby geographically distributed teams of operations engineers, problems such as these can take anything fromhours to weeks to diagnose and �x. Moreover, with hundreds or thousands of routers and �rewalls, the po-tential interactions between con�gurations are numerous and the cost of manually determining all end-to-end�ows is prohibitive.

The techniques developed in this paper will help discover issues such as those raised in the examplesabove. For example, given the set of router and �rewall con�gurations, our techniques would discover thepossibility of asymmetric routes interacting with �rewall rules to block SNMP and SSH connections betweenthe management and monitoring compartment and the Atlanta customer servers. A tool based on ourtechniques, capable of statically analyzing network con�gurations, would be useful both in the design ofnetwork con�gurations and in troubleshooting networks when they misbehave.

1.1 Problem Statement

This paper investigates the problem of determining all end-to-end conectivities in a network, given the setof all router and �rewall con�guration �les in the network. The con�guration data includes �rewall accesscontrol rules, router connectivity and route advertisement policies.

While the behavior of a network at any given point in time depends on the state of the routing tables,the behavior can change as the dynamic routing tables change. It is quite possible, therefore, for a networkto behave correctly at one instant, but behave in an unintended and incorrect manner at a later point intime.

In this paper we are not concerned with the analysis of a network at any given instant in time. We donot examine the state of routing tables. Instead, we consider the set of all potential paths from a sourceto a destination, over all possible states of the network routing tables. We can analyze all potential source-destination paths by examining the static route advertisement policies and the connectivity of networkelements.

Now, certain packet types (speci�ed by port and protocol) between the source and destination may beblocked by �rewall rules along some (or all) of these paths. For any packet, there are three outcomes: (i) allpaths from source to destination are blocked, (ii) no path is blocked, or (iii) some paths are blocked whileothers are not.

1.1.1 End-to-end Requirements

An end-to-end requirement speci�es, for a given source-destination pair which packet types must �ow throughand which must be denied. Such a requirement implies that either every possible path must allow the packetto go through, or else no path must allow the packet to go through. In other words, satisfying an end-to-endrequirement means that the third option (some paths permit the packet while others block it) must be ruledout by the static con�guration settings. This type of deterministic behavior in networks is critical to thelong term security and stability of the environment.

As we saw in the previous section, the routing policies may, perhaps unexpectedly, allow asymmetricroutes � the route from source to destination may be di�erent from the path back from the destinationto the source. Asymmetric routes can be hard to detect manually, and even harder to debug. If we canexamine all the possible round-trip paths between a source and destination, we will implicitly be �nding allthe possible routing asymmetries, and can make the administrator aware of them.

5

Formally, an end-to-end access requirement is represented as

< source, destination, service, permission, priority >

where source and destination correspond to sets of IP_addresses, service contains the source and destinationports, and protocol, permission is either �allow� or �deny,� and priority is a unique rank assigned to therequirement. A set of requirements is thus rank-ordered.

The main problem we address in this paper is: given a set of end-to-end access requirements, and aset of router and �rewall con�guration settings, do the con�gurations implement the end-to-end accessrequirements? For requirements that are not satis�ed, �nd paths that violate the requirement.

Furthermore, if any requirements are not satis�ed, give an algorithm to compute new �rewall rules, ifthey exist, to satisfy all the end-to-end access requirements. In this paper we discuss how to generate newrules. Our intent is not to automatically manage �rewall rule sets, which involves subtle and complex issues,but rather to propose new rules to be vetted by an expert. We do not consider the problem of automaticallyrecon�guring local routing policies to satisfy end-to-end requirements.

1.2 Solution Approach

Our approach to analyzing end-to-end network reachability is to determine all possible end-to-end accessesfrom the static con�gurations. This is similar to the approach taken in [6] which presents an abstractframework to address the problem. As mentioned in [6], the dynamic behavior of a network depends onfactors beyond static con�gurations, for example, the actual route traversed depends on the dynamic stateof the routing tables, and is not determined simply by the static con�guration settings. However, staticanalysis does accurately capture reachability properties that the network is required to uphold in everypossible dynamic state of the routing tables.

We de�ne generic model templates for router and �rewall con�gurations. For a given network, an instanceof the model is created for each device, and the template is populated with data drawn from the devicecon�guration �les. From the con�guration parameters in the model instances we construct route graphsfor the network. These graphs encode all possible paths between any two end points, taking into accountrouting policies and �rewall rule sets. Once the route graphs are constructed, we determine the set of allend-to-end accesses, and check these against the set of end-to-end requirements.

In summary, our solution to check the end-to-end access requirements proceeds in the following stages:

1. Model Instantiation. For each router and �rewall, create a model instance by populating the modeltemplate with parameters from the con�guration �les.

2. Route Calculation. From the model instances, create a route advertisement graph. Each node of thegraph represents a routing process. Edges in this graph are used to propagate the route advertisemententries between routers. The routes are consolidated into one Routing Information Base in each routermodel instance.

3. Route Analysis. Create Route graphs, one per destination. The nodes of each graph are routers,�rewalls and subnets, and each destination route graph captures all possible paths to the destinationfrom all sources. Use the route graphs to calculate all the end-to-end connectivities.

4. End-to-end validation. Check the set of all end-to-end accesses against the set of end-to-end re-quirements to �nd any violations, and suggest �xes wherever possible.

6

1.3 Outline of this paper

The remainder of this paper is organized as follows. Section 2 gives an overview of the generic modelsfor routers and �rewalls. Section 3 describes how the con�guration �les are parsed and the results used topopulate the model instances. Section 4 de�nes the route advertisement graph, the calculation of the routinginformation base for each router, and de�nes the route graphs which are used in Section 5 to calculate allthe possible end-to-end accesses. Section 6 describes previous related work, and Section 7 concludes with alist of issues for further exploration.

2 De�ning and Populating Models

This section presents our models for routers and �rewalls. The models are generic and intended to supportdi�erent vendor products and versions. Furthermore, each con�guration model represents the minimuminformation required to generate the required reachability information; thus, we only de�ne attributes thatcapture the routing policies and access control rules that concern us. In the next section we show how toderive the information required by this generic model from real con�gurations.

For ease of exposition, our model separates routing and �rewall functions; router and switch ACLs areconsidered as a separate ��rewall� associated with the router or switch in question.

2.1 Router Model

The model shown in 4 allows us to describe, and later capture the vendor-independent information about therouting device required for our purposes. In our model, a router or layer 3 switch1 consists of an identi�erassociated with a set of routing methods, which are then combined with the associated physical and virtualinterfaces.

Any given router will typically have a combination of directly connected networks, static routes anddynamically learned routes, such as routes learned via dynamic routing protocols such as RIP, OSPF orBGP.

We present the salient features of the model to give a general idea of the structure of a router. For clarity,we defer some details to SectionA.1 which describes, with an example, how the model is populated as well.

2.1.1 Routes and Route Models

We describe routes as a 3-tuple �destination network, next hop, weight�, where destination network is thedesired destination, next hop is the address to which packets must be sent in order to reach that network,and weight is a number which can be used to indicate route preference. This de�nition is common to allrouting methods.

2.1.2 Directly Connected Routing and Route Models

Each router is a member of multiple networks to which its interfaces are connected. Each of these networksis used to populate the �eld labeled �directly connected routes.�

1For simplicity, we will use the term 'router' from this point onwards to refer to either a router or a layer 3 switch.

7

RouterBGP

Route *

AS: identifier

Router ID

Initial RIB: RIB*

Neighbors: AS:identifier*

Inbound Policy

Area ID*

Policy

Route*

RouterID

RouterInfo

Directly Connected

Route *

Static

Route *

Outgoing Policy

OSPF

IGP

Initial RIB: RIB*

Route

Destination Network

Next Hop Address

Interface Group

Weight Interface*

Interface

Id

IP address

VLAN_NO

MAC address

Figure 4: Router Model

8

2.1.3 Static Routing and Route Models

Static routes are �xed paths de�ned on the router, rather than learned via a routing protocol. Since �xedroutes are fragile in the face of network failure, static routes are typically used as a route of last resort, or topoint to a shared virtual address in HSRP and VRRP con�gurations. The static route model simply consistsof a set of �xed routing rules which specify the next hop to which a packet will be routed.

2.1.4 Dynamic Routing and Route Models

Dynamic (or adaptive) routing protocols update the available network paths inside of an autonomous system(AS, loosely described as a group of routers sharing the same administrative policies) and between ASes inrealtime (or near real time) based on changes that occur in the routing environment.

Routing protocols used inside of an AS are described as Interior gateway protocols (IGP). Functionallythere is only one Inter-AS protocol in use � BGP.

Brie�y, there are three general types of algorithm used in dynamic routing:

1. Distance Vector (RIP, IGRP, EIGRP)

2. Link State

3. Path Vector

In the Appendix we describe models for intra-AS routing using OSPF and inter-AS routing with BGP.

2.1.5 Access Control List Models

A router can also specify access-control lists to control incoming and outgoing packets, represented byRouter.Incoming Policy and Router.Outgoing Policy. In this paper we assume, for sake of simplicity, thatall �ltering is done at �rewalls. For routers with �lters we will represent it as a combination of a router anda set of �rewalls, one connected to each interface.

2.2 Firewall Model

The model shown in Figure 5 allows us to describe and later capture the vendor-independent informationabout �rewalls and ACLs required by our algorithms. In our model, a �rewall consists of a set of interfaces,to which network address translations and policies to permit or deny access may be applied. We describethe salient features here.

2.2.1 Interfaces

The �rewall interfaces are a set of all of the interface ids and IP addresses of the subnets physically connectedto various interfaces of the �rewall.

2.3 Order of Operations

While the set of operations (route, translate, apply policy) performed by any type of �rewall is fairlyconsistent, the order in which these operations are performed varies. The �rewall which we will be using as anexample, OpenBSD pf, uses �Translate, Apply Policy, Route�. Cisco IOS ACLs use �Apply Policy, Route,Translate� for tra�c coming from the �inside� interface to the �outside� � but �Apply Policy, Translate,Route� for tra�c coming from the �outside� interface to the �inside�.

9

Firewall

Interface*

InterfaceId

InterfaceAddress

Input:Packet

Output:Packet

Incoming Policy:<Src,Dest,Service,KeepState,Permission>*

Outgoing Policy:<Src,Dest,Service,KeepState,Permission>*

FirewallId

Order of Operations [ Translate, Policy | Policy, Translate ]

Route*

Policy

Translate

Figure 5: Firewall Model

10

2.4 Routes and RIB

This is the set of static routes and directly connected routes known to the �rewall. For �rewalls with dynamicrouting, we represent the �rewall as a combination of a �rewall and a set of routers, one connected to eachinterface.

2.4.1 Policy

Policy is what determines if a packet will be accepted or denied, and depending on the type of �rewall oraccess list, may be applied to packets as they are incoming, outgoing, or both.

1. IncomingPolicy consists of a set of all of the policies that are applied to tra�c inbound througha particular interface. Each entry consists of the 4-tuple <Src,Dest,Port,Protocol>, and a booleanKeep State attribute (which is true if this rule was created as a result of an implicit �keep state� ruleand it is false if the packet �lter rule does not have keep state).

2. OutgoingPolicy consists of a set of all of the policies that are applied to tra�c outgoing througha particular interface. Each entry consists of the 4-tuple <Src,Dest,Port,Protocol>, and a booleanKeep State attribute (which is true if this rule was created as a result of an implicit �keep state� ruleand it is false if the packet �lter rule does not have keep state).

Some types of �rewall have implicit rules such as "packets are allowed to travel from higher securityinterfaces to lower security interfaces, but not vice versa", which means that the policy may need to beinterpolated.

2.4.2 Translation

Translation is an general description for mechanisms that modify the source, destination or ports describedby �rewall policies. Translation includes network address translation (NAT), port address translation (PAT)and redirection (RDR), which are brie�y described here.

1. Network Address Translation consists of a set of translation rules which are applied as packets transita given interface. NAT works as a function which takes certain source or destination addresses andconverts them into other addresses.

2. Port Address Translation consists of a set of translation rules which take certain source or destinationports, and convert them into other ports.

3. Redirect (RDR) consists of a set of translation rules for destination addresses and/or ports.

3 From Con�gurations to Models

The models in the previous section are represented using java beans as classes with getter and setter methods.These models have:

1. A java constructor to create model nodes by invoking new with the classname.

2. Setter methods to assign values to �elds in model nodes � object.setField(value). Values are eithermodel nodes or scalar items such as integers and strings.

11

The con�guration of a device is a language that is subject to syntactic and semantic rules, contained ina grammar.

We use this grammar to parse the con�guration �le into a parse tree. This parse tree maps rules of thegrammar to the contents of the con�guration �le. The leaves of the parse tree together are the contents ofthe con�guration �le. The interior nodes of the parse tree are instantiated versions of grammar rules.

We populate the models by traversing the parse tree in preorder. On encountering an interior node weexecute the actions speci�ed in the body of the rules. At the completion of this traversal we will have acompletely populated model of the device, provided we started o� with a valid con�guration �le, and acorrect grammar for the device.

3.1 A Brief Example

We represent a routing rule in Figure 4 using the java class

class NextHopInfo{

IpAddress nextHopInfo;

Vector<Inferface> interfaceGroup;

}

class Route{

IpAddress DestinationNetwork;

NextHopInfo NextHop;

float weight;

}

We have to populate instances of the above model fragment using the grammar rules2 :

RouteSpec→ NetworkSpec NextHopInfo Weight;NextHopInfo→ NextHopAddress InterfaceGroup;

We annotate the rules above with actions to populate �elds in the models using setter methods.

RouteSpec→$$ = new Route();

NetworkSpec{ $$.setNetworkSpec($1); }

NextHopInfo{ $$.setNextHopInfo($2); }

Weight{ $$.setWeight($3); }

;NextHopInfo→{ $$ = new NextHopInfo(); }

NextHopAddress{ $$.setNextHopAddress($1); }

InterfaceGroup;{ $$.setInterfaceGroup($2); }

2In Appendix A.1 we show the population of models intuitively without resorting to lex and yacc conventions. In this section,however, we use lex/yacc conventions for convenience.

12

The action new Route(); creates a Route model instance, when the grammar rule for NetworkSpec istriggered. Then the destinationNetwork, nextHop and the weight �elds are �lled by calling the settermethods setNetworkSpec, setNextHopInfo and setWeight on this instance. The arguments for thesemethods are obtained by the recursive traversal of the parse tree.

4 Computing Route Graphs from Populated Models

In this section we �rst show how to construct the route advertisement graph (RAG) from a set of populatedrouter and �rewall models. We use the RAG to calculate the consolidated route information base (RIB) foreach node in the RAG. Using the RIBs we then construct route graphs from which the end-to-end accesseswill be calculated.

4.1 Route Advertisement Graph(RAG)

We �rst de�ne the route advertisement graph. The RAG, G(V,E) contains a node for each routing process(Ri.BGP , Ri.OSPF ) and for the static route set Ri.Static in a router. The edge set E consists of all edgesx.px → y.py if x's routing process px advertises to y's routing process py.

We can determine whether a routing process advertises routes to another based on the populated modelsof the two processes. For instance, one of the conditions under which the BGP process of a router x advertisesroutes to the BGP process of another router y (using names taken from Section 2):

• if y.BGP ∈ x.BGP.neighbors and

• (x.BGP.AS 6= y.BGP.AS) and

• ∃I ∈ x.Interfaces, I ′ ∈ y.Interfaces : I.V LAN_NO = I ′.V LAN_NO.

4.2 Propagating the Routing Information Base

Once the RAG has been created, we use it to compute the set of routes available to each host. As describednext, this involves propagating the information in each RIB throughout the network, and updating everyRIB as it receives new route information. As this process is iterated, each RIB eventually converges to a�xed point; this �nal state determines all the network addresses to which the router can route tra�c.

A standalone router can calculate its reachability information by looking at the local RIBs and the RIBsof all the routing processes. If there is a directed edge from routing process x.proto1 to y.proto2, where xand y are routers, then in the absence of any access control policies, 3 x.proto1 sends the list of destinationsit can reach to y.proto2. This means that y.proto2 inherits routes to all the destinations reachable fromx.proto1.

The outgoing policy of x.proto1 and the incoming policy of y.proto2 determine exactly which routes ofx.proto1 can be propagated to y.proto2. Therefore, using the static information from the router's con�gura-tion, we can update the set of destinations that can be reached from a particular router interface or throughwhich the router can send a packet to a particular destination.

We use the algorithm in Figure 1 to compute the �xed point values of the RIBs. Upon reaching the�xed point, each router's consolidated RIB (R.RIB)is calculated as the union of RIBs of all the individual

3The reader should note that routing policy restrictions are clearly separate from the �rewall access controls. The formercontrols routing advertisments, whereas the latter are used to control network access.

13

Algorithm 1 Route Propagation Algorithm

1: procedure RIBPropogate(RIBGraph)2: repeat

3: for all (R1.proto1, R2.proto2) ∈ RIBGraph.Edge do4: for all routes ∈ R1.proto1.RIB do

5: if Policy allows advertising route then

6: R2.proto2.RIB.add(route)7: end if

8: end for

9: end for

10: until RIB FixedPoint is reached11: end procedure

routing processes and the local RIB which also contains the static routes. At this point, each consolidatedRIB contains the following information:

• All the destinations reachable from the router, and

• For each reachable destination IP in the RIB, the list of next-hop interfaces.

4.3 Route Graphs

From the RIBs computed as the �xed point of the propagation algorithm, we next de�ne a set of route graphs.These route graphs will be used in the next section to verify whether or not the network con�gurations satisfythe end-to-end access requirements.

We start with a set of destination graphs, Gd, one for each destination node d in the network. Thedestination graph Gd contains a node for each router, �rewall, subnet and VLAN. There is a directed edgefrom node x to node y if a packet destined for node d can possibly traverse the link from x to y.

Next, we shrink Gd as follows:

1. First, remove all �rewall nodes from Gd. This splits the graph into a number of disconnected subgraphs.

2. Within each subgraph, identify every strongly connected component and replace it with a single �su-pernode,� while maintaining the external incoming or outgoing edges for the component.

3. Finally, insert the �rewalls back in, making connections to the appropriate nodes/supernodes. We callthis residual graph the route graph Rd.

Note that each route graph Rd contains within it all the possible paths along which a packet destined ford can travel from any source.

Figure 6 shows route graphs for the two nodes Cust_Server-D and Mgmt_Host-A from the example ofSection 1. The solid edges belong to the route graph for Cust_Server-D, and the dotted edges belong to theroute graph for Mgmt_Host-A.

Although global enterprises have large networks, with tens of thousands of elements, the number of�rewalls is typically in the low hundreds for the largest networks and in the low tens for typical networks.The route graphs de�ned above are considerably smaller than the original networks; this �exibility allows usthe �exibility to search over all possible source-destination paths in the next section.

14

Figure 6: Illustration of route graphs

5 Reachability

Given the route graphs Rd for each destination, we next compute all the end-to-end accesses in the networkthat are consistent with the router setup, route �lters, and �rewall access control policies.

A high-level overview of the algorithm is presented in Figure 2. We omit details that, while important,would detract from clarity.

The algorithm takes as input a set of directed route graphs, one graph for each destination. Each �rewallnode is labeled with an associated rule set (subset of the original rule set containing only rules that matchthe destination node d).

For every source and destination pair (s, d) the algorithm classi�es all services (port, protocol)) accordingto whether (a) every path from s to d is open (not blocked by a �rewall), (b) every path from s to d isblocked, or if (c) some s to d paths are open while others are blocked.

One detail that we have ignored is that while nodes in our graph correspond to aggregates such as VLANsand subnets, �rewall rules may apply at a �ner level of granularity, perhaps even to individual IP addresses.While we do not go into details in this paper, such issues can be handled in a straightforward manner; for

15

Algorithm 2 Classifying services between source and destination

1. Input: The route graph Rd and a source node s.

2. Output: Label each service (port, protocol) according to whether all s to d paths are (i) blocked, (ii)open, or (iii) some paths are blocked while others are open.

3. Maintain two sets Open and Blocked at node d. The set Open contains services for which some pathfrom s was open, while Blocked contains services for which some path was blocked. Initially both setsare empty.

4. Begin a search at the source s that exhaustively searches every path from s to d. We maintain a listL (initially empty) of the services that are blocked along the path P (initially containing the source s)currently being explored.

(a) When the path encounters a �rewall, add the list of services that are blocked for d to list L.

(b) When the path reaches d, insert the elements of L into the list Blocked maintained at node d.Similarly, the services not in L are inserted into the list Open.

5. When all s-to-d paths are exhausted, label each service according to whether it appears in only one ofthe lists Open or Blocked, or in both lists.

example, by re�ning each node into smaller subnodes depending on applicable rules across all �rewalls.Note that the running time is proportional to the number of source�destination paths, plus the time for

bookkeeping operations to maintain the sets. There are several improvements to the algorithm that we haveomitted in order to keep the presentation clear and simple.

Although, in the worst case, the number of paths can be exponential in the size of the route graph,usually the route graph is substantially smaller than the original graph. Furthermore, production networksare structured so that the number of �rewalls along any path, as well as the number of source�destinationpaths is severely limited. In practice, we expect the algorithm will scale well for large enterprise networks.

We note that there are other ways to solve the problem that do not su�er from this exponential worstcase behavior. For example, by examining services (port, protocol pairs) one at a time, each iteration takestime linear in the size of the route graph, and the worst case time is proportional to the product of thegraph size (number of nodes and edges), and the number services (ports, protocols pairs). In practice, thelast two factors in the product make the running time on typical networks much worse than the algorithmgiven above.

Finally, having computed all the end-to-end accesses, it is a straightforward matter to verify if these arecompliant with respect to a given set of end-to-end requirements.

5.1 Round trip �ows and Keep State Rules

The above discussion considered only one-way �ows and stateless �rewalls. For round-trip �ows (tcp, http,ftp, etc.) the situation is complicated by the presence of stateful �rewall rules, in particular �keep state� rules.In conjunction with asymmetric routes that are created unintentionally as a result of a miscon�guration,stateful rules make network problems di�cult to debug.

Our approach to analyzing round-trip �ows proceeds as follows: start with the route graphs Rd and Rs,

16

and merge/concatenate the two graphs by identifying node d in the two graphs. In the concatenated graph,a path from s to d can be concatenated with a return path from d to s. We can use the previous algorithmto �nd all the round-trip �ows from s to d and back.

Now, some of the �rewalls may contain �keep state� rules which work as follows. Suppose that, on thereturn path from d to s, a �rewall is encountered and the rule triggered permits the return packet, butis marked keep-state. Then, the packet is allowed through only if the forward path from s to d transitedthrough the same �rewall; if not, the return packet is dropped. Generalizing this observation, it is easy tosee that in order to satisfy an �allow� end-to-end requirement on a round-trip service, every forward pathmust pass through a �rewall with a keep-state rule if even one return path passes through that �rewall.

To account for the keep state rules, we thus modify our search procedure accordingly. Speci�cally, whileexploring a round-trip path, if a �keep state� �rewall rule is encountered on the return path, then we checkto see if that �rewall was on the forward portion (from s to d) of the current path. If not, the service isblocked along that path. We leave the details of the algorithm to the interested reader.

5.2 Recon�guring �rewall rules

Suppose that we are given a set of end-to-end access requirements of the form

(s, d, port, protocol, permission),

where permission is either allow or deny, and our reachability analysis reveals that some of these require-ments are not always satis�ed. In such cases, we would like to identify which devices require con�gurationchanges, and what changes need to be implemented.

A naive approach is to compute the �xes as we run the search procedure. In particular, for an allowrequirement, we need to ensure that all �rewalls along every s − d path will permit the packet through.During the search, we simply add the appropriate rule along every �rewall encountered. Similarly, for adeny requirement, we need to ensure that every s− d path blocks the packet; for example, we could chooseto block �rewalls that form an s−d cut set computed by a breadth-�rst search of the paths from s to d, andinsert deny rules for the packet appropriately.

In general, we do not recommend that changes to �rewall rule sets be made automatically. Rather, therules generated above could be a starting point for an administrator responsible for re�ning the rule set.One weakness of the naive approach is that by adding rules for indivdual packets, we could create very large,and therefore perhaps ine�cient, rule sets. While there are promising approaches to aggregating rule sets,these are beyond the scope of this paper.

6 Related Work

The paper by Xie et.al. [6] presented an abstract framework to study the static reachability problem. Theframework is based on the use of dynamic programming to compute all possible accesses, aggregated overall possible states. They consider rules that are limited to �ltering on outgoing destinations only, and noton packet sources. Moreover, their algorithm does not address the issue of composing the e�ects of �rewallrule sets along source-destination paths.

We have built on their ideas to engineer solutions for real network instances by developing (i) genericmodels for network components (ii) a more general treatment of �rewalls, including ways to deal with state-dependent �lter rules, and (iii) e�cient generation of �rewall access control rules to meet desired end-to-endaccess requirements.

17

Guttman and Herzog [2] present a formal framework for analyzing security properties of networks fromdevice con�gurations. They study properties beyond end-to-end access; however, their treatment is limitedto a single snapshot of the network state � they pull in data from the routing tables, but do not considerpolicies on route advertisement. The paper acknowledges the di�culty of gathering a consistent snapshot ofa large network, as well as the limitations of studying properties of single snapshots.

Several papers have studied the problem of verifying end-to-end reachability in networks with distributed�rewalls [1, 4, 5]. These papers do not, however, consider the e�ect of routing policies on end-to-end access.The algorithm given in [1] for computing end-to-end accesses is similar in spirit to the algorithm in Section 5.

7 Next Steps

Our work reveals a number of avenues for further research. One of the parameters that we have not consideredare the weights assigned to links in the con�guration of routing policies. For example, these weights canbe used to estimate the likelihood of particular end-to-end paths, and to distinguish primary paths fromsecondary, backup paths.

One can also expand the notion of end-to-end access requirements beyond a simple boolean choice, toinclude, for example, path contraints. Since we explicitly traverse all source-destination paths, we couldinclude more general path properties in our policy. In the example of Section 1, a reasonable end-to-endpolicy might be that primary paths from the management and monitoring nodes to the customer servers mustnot traverse the customer-provisioned link. An understanding of the trade-o�s between the expressivenessof policy languages versus the complexity of checking compliance against policies is needed to achieve thecorrect balance in this trade-o�.

Along a di�erent line, further work is needed to understand how complete or extensible the generic routerand �rewall models are in capturing the relevant parameters for multiple vendor products.

References

[1] Elisha Ziskind Alain Mayer, Avishai Wool. O�ine Firewall Analysis. International Journal of Information

Security, Volume 5(3):125�144, July 2006.

[2] J. D. Guttman and A. L. Herzog. Rigorous Automated Network Security Management. International

Journal of Information Security, 4(1�2):24�98, February 2005.

[3] IBM. http://www.redbooks.ibm.com/pubs/pdfs/redbooks/gg243376.pdf.

[4] P. Rao S. Bhatt, S. Rajagopalan. Automatic Management of Network Security Policy. In MILCOM

2003.

[5] Pavan Verma and Atul Prakash. FACE: A �rewall analysis and con�guration engine. In SAINT, pages74�81. IEEE Computer Society, 2005.

[6] Geo�rey G. Xie, Jibin Zhan, David A. Maltz, Hui Zhang, Albert G. Greenberg, Gísli Hjálmtýsson, andJennifer Rexford. On static reachability analysis of IP networks. In INFOCOM, pages 2170�2183. IEEE,2005.

18

A Appendix: Converting con�gurations into models

A.1 Con�guration Grammars

As explained in Section 3 we use generic grammars for routers and �rewalls as a starting point in the processof populating model instances. Here we present the generic grammars for describing router and �rewallcon�gurations.

Figure 7 is the generic router grammar, while Figure 8 is the generic �rewall grammar. Each rule in agrammar has a left hand side and a right hand side separated by a →. Symbols in the typewriter fontappear literally in the con�guration �le; we call these symbols keywords. Symbols that appear on the lefthand side of a grammar are nonterminals. Others such as number are terminals. Throughout this section,this style of text is used to indicate a fragment of the actual con�guration.

Figure 8 presents the generic �rewall grammar.

A.2 Populating Model Instances

To capture a particular kind of router or �rewall, we �rst construct a speci�c grammar for the device. Thenwe will use a tool such as yacc or ANTLR to create an executable parser from this grammar. Figure 9shows the stages of our process. We start by tailoring the generic grammar to create device grammars forspeci�c device types; next a parser goes over the device con�guration �le, and applies device grammar rulesappropriately to produce fragments of the populated model instance. Rather than describe the details ofthis process, we present the approach, as applied to Cisco IOS �les, in Figure 9.

19

1. router → RouterID RouterInfo

2. routerID → string

3. routerInfo → connectedRoutingInfo staticRoutingInfo IGPRoutingInfo bgpRoutingInfo

4. connectedRoutingInfo → routeSpec* connected

5. routeSpec → networkSpec nextHopInfo weight

6. networkSpec → networkAddress wildcard-mask

7. nextHopInfo → nextHopAdddress interface-group

8. nextHopAddress → IP address

9. interface-group → interface*

10. interface → interfaceID

11. interfaceID → string

12. staticRoutingInfo → routeSpec* static

13. IGPRoutingInfo → [ ospfRoutingInfo | IS-IS | ... ]

14. ospfRoutingInfo → ospfInitialRib

15. ospfInitialRib → ospfRibEntry*

16. ospfRibEntry → ospf-areas

17. ospf-areas → ospf-area*

18. ospf-area → routeSpec* ospf-areaID

19. bgpRoutingInfo → bgpInitialRib bgpAS-ID

20. bgpAS-ID → ASnumber bgpRouterID bgpRouterDescription

21. bgpInitialRib → bgpRibEntry*

22. bgpRibEntry → bgpNeighbors

23. bgpNeighbors → bgpNeighbor*

24. bgpNeighbor → routeSpec* bgpNeighborAS-ID

25. bgpNeighborAS-ID → bgpAS-ID

Figure 7: Generic Router Grammar

20

1. �rewall → �rewallID �rewallInfo

2. �rewallID → string

3. �rewallInfo → operationInfo routeInfo translationInfo policyInfo

4. operationInfo → ( translate,policy | policy,translate )

5. routeInfo → connectedRoutingInfo staticRoutingInfo

6. connectedRoutingInfo → routeSpec* connected

7. routeSpec → networkSpec nextHopInfo weight

8. networkSpec → networkAddress wildcard-mask

9. nextHopInfo → nextHopAdddress interface-group

10. interface-group → interface*

11. interface → interfaceID

12. interfaceID → string

13. staticRoutingInfo → routeSpec* static

14. translationInfo → translationType translateFrom translateTo

15. translationType → ( nat | rdr | ... )

16. translateFrom → ruleObject

17. translateTo → ruleObject

18. policyInfo → permission direction sourceInfo destinationInfo

19. permission → ( permit | deny )

20. sourceInfo → ruleObject*

21. destinationInfo → ruleObject*

22. ruleObject → networkSpec portSpec protoSpec

23. portSpect → port-range

24. port-range → ports

25. ports → port*

26. port → number

27. protoSpec → ( tcp | udp | ip | number)

Figure 8: Generic Firewall Grammar

21

GenericGrammar

DeviceSpeci�cGrammar

Con�gurationFile

Value

router→

RouterID

RouterInfo

routerID→

string

routerID→

hostnamestring

hostname

SITEA_SW0

routerID→

SITEA_SW0

routerInfo

→connectedRoutingInfo

staticR

outingInfo

IGPRoutingInfo

bgpRoutingInfo

connectedRoutingInfo

→routeSpec*

connected

connected

connected

routeSpec→

networkSpec

nextH

opInfo

weight

networkSpec→

networkAddress

wildcard-

mask

networkSpec→

ip

addressIPad-

dress

wildcard-m

ask

ip

address

192.168.200.2

255.255.255.0

networkSpec

→192.168.200.0/24

nextH

opInfo

→nextH

opAdddress

interface-group

nextH

opAddress→

IPaddress

nextH

opAddress→

ip

address

IPaddress

ip

address

192.168.200.2

255.255.255.0

nextH

opAddress

→192.168.200.2

interface-group→

interface*

interface→

interfaceID

interfaceID→

string

interfaceID→

interfacestring

interface

Vlan1300

interfaceID→

Vlan1300

connectedRoutingInfo

→192.168.200.0/24

192.168.200.2

Vlan1300

connected

Figure

9:Exampleofprogressionfrom

genericgrammarto

Cisco

IOS-speci�cgrammar

22