practical declarative network management - events - sigcomm
TRANSCRIPT
Practical Declarative Network Management
Timothy L. HinrichsUniversity of Chicago
Computer ScienceChicago, IL USA
Natasha S. GudeStanford UniversityComputer ScienceStanford, CA USA
Martin CasadoStanford UniversityComputer ScienceStanford, CA USA
John C. MitchellStanford UniversityComputer ScienceStanford, CA USA
Scott ShenkerU.C. Berkeley and ICSI
Electrical Engineering andComputer ScienceBerkeley, CA USA
ABSTRACTWe present Flow-based Management Language (FML), adeclarative policy language for managing the configurationof enterprise networks. FML was designed to replace themany disparate configuration mechanisms traditionally usedto enforce policies within the enterprise. These include ACLs,VLANs, NATs, policy-routing, and proprietary admissioncontrol systems. FML balances the desires to express poli-cies naturally and enforce policies efficiently. We have im-plemented FML and have used it to manage multiple oper-ational enterprise networks for over a year.
Categories and Subject DescriptorsD.4.6 [Software]: Security and Privacy Protection; D.1.6[Programming Techniques]: Logic Programming
General TermsDesign, Languages
KeywordsNetwork, Policy, Security, Performance
1. INTRODUCTIONIn recent years, high-level declarative management lan-
guages have gained traction in the commercial world. Exam-ples include XACML [16] for declaring access-controls overmiddleware and webservices, and P3P [8, 9] for declaringprivacy policies in web environments. In addition, many e-mail readers use declarative languages for message filtering.
Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.WREN’09, August 21, 2009, Barcelona, Spain.Copyright 2009 ACM 978-1-60558-443-0/09/08 ...$10.00.
These and other successes provide evidence for the utilityof declarative management techniques. However, the adop-tion of these languages has been almost entirely at the appli-cation layer and above. In contrast, enterprise networks con-tinue to be managed through a number of disparate low-levelmechanisms, including the use of VLANs and subnetting forisolation, ACLs for access control, NAT for client protection,and policy routing for source-based policies and the inte-gration of middleboxes. As has been frequently lamentedin the literature [7, 19, 14], these traditional approachesfor network configuration result in networks whose connec-tivity is dictated by thousands of lines of brittle, low-levelconfiguration code that grows stale as the network evolves.Thus, enterprise networks provide an ideal example of wheredeclarative management techniques could provide substan-tial benefits.
In this paper, we present Flow-based Management Lan-guage (FML), a high-level declarative language for express-ing network-wide policies about a variety of different man-agement tasks within a single, cohesive framework. Whilethere have been numerous authorization languages proposedin the literature (e.g., [1, 4, 6, 12, 15, 18] among manyothers), we believe FML has a unique position in the aca-demic design space as it was purpose-built to replace existingnetwork configuration practices, and has been extensivelytested in practice. More specifically, the contributions ofthis work are as follows:
• With FML we present a simple language that can beused to express many common configurations used innetworks today. We demonstrate its expressibility witha series of example applications and by presenting ourexperiences running FML in multiple operational net-works over the last year.
• FML was designed to admit efficient implementation,suitable for large enterprise networks. In particular, itsimplementation is polynomial time in general, and thefragment discussed in this paper requires linear time,thus supporting network-speed decisions. We presentperformance numbers from our operational implemen-tation that demonstrate its scaling properties.
1
In what follows, we describe FML and provide some ofthe logical foundations of the language. We then describehow FML can be used to express common network configura-tions. In the subsequent sections, we describe our implemen-tation of FML, and provide an analysis of its performance aswell as our experiences deploying it within two operationalnetworks. Finally we present related work and conclude.
2. FML
2.1 BackgroundThe granularity on which FML operates is a unidirec-
tional network flow (hereafter when referring to flows, werefer specifically to unidirectional flows). This means that aresulting policy decision applies equally to all packets withinthe same flow, and a policy may be constructed that treatseach flow differently (and thus the policy must be consultedat least once per flow).
We have designed and built FML as the underlying policylanguage for NOX [10], a network-wide control plane thatenforces policies on every flow in the network. Similar toits predecessor, Ethane [7], NOX checks the first packet ofevery flow against the network policy before admitting theflow onto the network. The result of the check may denyor otherwise dictate how the flow is to be handled by thenetwork.
In addition to performing per-flow policy checks, NOX au-thenticates all network principals including switches, users,and hosts. This is done via standard mechanisms such as802.1x. NOX then maintains name to address bindings of allauthenticated principals, and thus given a flow, it can mapthe flow to its sending and receiving host and user names.
For concreteness, the descriptions of FML in this paperare derived from our specific implementation environmentwithin NOX. However, we believe the principles general-ize to any flow-based network architecture. We assume thenetwork policy engine can derive the associated high-levelnames for all flows on the network. As shown in Table 1,these include the sending and receiving host name, the send-ing and receiving user, the sending and receiving accesspoints (physical ports), and the protocol. In addition, weassume that the policy engine is invoked for each flow on thenetwork and can determine whether the flow is a request ora response.
Property Descriptionus and ut Source and Target Usershs and ht Source and Target Hostsas and at Source and Target Access Pointsprot Protocolrequest Whether or not flow is a request.
Table 1: The properties characterizing a unidirec-tional flow.
2.2 OverviewFML is a language for specifying policies about flows.
FML is based on nonrecursive datalog with negation. AFML policy is a set of statements, each representing a simpleif-then relationship. The statements dictate that a specifiedconstraint should be applied to the matching flows.
For example, the following three statements say that todd
and michelle are superusers, and a superuser has no com-munication restrictions.
allow(Us, Hs, As, Ut, Ht, At, P rot,Req) ⇐superuser(Us)
superuser(todd)superuser(michelle)
The arguments to allow are all variables (denoted by sym-bols starting with a capital letter) and correspond to theeight fields of a flow. The remaining two rules make simpledeclarative statements. The constraints (such as allow) arenamed by keywords. Each application of FML can define itsown set of keywords.
Throughout this section, we use four keywords from theaccess control application discussed in Section 3: allow,deny, waypoint, and avoid. Intuitively, deny blocks a flow;waypoint requires a flow to pass through a particular node inthe network; and avoid forbids a flow from passing througha particular node in the network.
A basic FML policy consists of statements like those seenabove, and while such a language can easily represent a widevariety of information, sometimes not all the informationpertinent to a policy can or should be represented within asingle file. For example, user names and associated groupsare often maintained in an external authentication store(such as LDAP or AD), and maintaining a copy within apolicy file may be impractical. Consequently, FML policiescan include external references to, for example, SQL queriesover local or remote databases, hash tables, or arbitrary pro-cedural code.
One of the benefits of FML is that it natively supportsdistributed authorship, making it easy for disparate partiesto collaborate on policy decisions.
As with any network configuration language, FML mustassume the possibility of distributed authorship within asingle policy domain. This can lead to policies with con-flicts (simultaneously allowing and denying a uniflow); con-sequently, FML includes two conflict resolution mechanisms.One mechanism is under the control of application develop-ers and resolves conflicts at the level of keywords, while theother (a FML cascade) is under the control of policy writersand is built into the language itself. Below we formalize thedesign of our language. We leave a more detailed treatmentto [13].
2.3 Formal definitionThe formal syntax for FML rules and FML policies is
given below. We use standard terminology. A predicate is asymbol associated with a fixed number of arguments: its ar-ity. A term is a variable (starting with an upper-case letter)or an object constant (starting with a lower-case letter). Anatom is a predicate of arity n applied to n terms. A literalis an atom or its negation (indicated by ¬). An expressionis ground if it contains no variables.
Definition 1 (FML Rule). A FML rule in the con-text of external references G takes the following form.
h ⇐ [¬]b1 ∧ · · · ∧ [¬]bn
• h, the head, and every bi, collectively called the body,are atoms.
• Every variable in the body must appear in the head.
2
• When a keyword with more than eight arguments ap-pears in the head, the extra arguments are object con-stants.
• h does not contain any predicate g ∈ G.
It is worth noting that the second condition differs fromthe traditional safety1 restriction in datalog and signifi-cantly simplifies FML’s implementation. See Section 4 formore information. In addition, it guarantees polynomial-time evaluation. We include the proof in Appendix A.
A FML policy is simply a collection of FML rules that arenonrecursive: if predicate A’s definition depends on B, thenB’s definition does not depend on A.
Definition 2 (FML Policy). A FML policy is a setof FML rules ∆ that is nonrecursive. (See, for example, [17]for a formalization.)
The formal semantics of FML is straightforward and canbe defined using the usual stratified semantics [17] of logicprogramming or database theory. For the sake of brevitywe omit the definitions. It suffices to say that the obviousif-then intuition for each rule is exactly right, with the onlycomplication arising in the context of sets of statements inwhich a single flow can match multiple rules. In an FML pol-icy, the order of statements is irrelevant—reorder the state-ments in any policy, and the meaning of the policy is entirelyunchanged.
Order irrelevance in a policy language offers two benefitsover languages in which statement order matters, e.g., fire-wall configuration languages [20]. First, combining a set ofindependently authored policies is straightforward: collectall statements made in the policies. By contrast, it is notimmediately clear how to automatically combine policies inwhich statement order matters, thus requiring an algorithmthat will likely be unintuitive to the user. Second, large or-dered policies can be difficult to understand because a ruleonly applies to a flow if none of the previous rules apply.Conversely, every statement in an FML policy applies toevery flow; finding a single statement that allows a flowguarantees that one of the constraints on that flow is allow.
The practical consequence of order-irrelevance is that apolicy can impose multiple constraints on the same flow.For example, an access control policy can force a flow topass through two different intermediate waypoints while re-quiring it to avoid yet another waypoint. While this featuremakes expressing certain policies more natural, it also ad-mits policies that are unenforceable. For example, a policycould dictate that a flow should be both allowed and denied.No real system can simultaneously allow and deny an accesscontrol request; consequently, FML must support schemesfor resolving conflicts. Formally, conflict resolution acts asa layer of semantics that is defined on top of the core (strat-ified) semantics of FML.
2.4 Conflict ResolutionFML conflict resolution varies depending on the applica-
tion, a necessity because the keywords differ from applica-tion to application. In the access control example, the con-flict resolution scheme prioritizes the keywords: deny takesprecedence over everything; waypoint and avoid are of equalpriority and take precedence over allow. allow has the low-est priority. The resolution mechanism throws away all con-straints except those with the highest priority. For example,1All variables must occur in a positive literal in the body.
if a flow were allowed and denied, the resolution mechanismwould throw away the allow constraint.
One benefit of permitting conflicts is that administratorscan leverage the resolution scheme to write more concisepolicies. For example, in the access control setting, it iseasy to write an open authorization policy—one that allowseverything not explicitly denied.
allow(Us, Hs, As, Ut, Ht, At, P rot, Req)deny(Us, Hs, As, Ut, Ht, At, P rot,Req) ⇐
blacklist(Us)(1)
These two rules deny all communication initiated by a black-listed user and allow everything else. To further restrictaccess, an administrator need only include additional denyrules.
While open policies are easy to represent, closed policies(those where everything not explicitly allowed is denied) areproblematic. Adding allow statements does not affect a pol-icy where every flow is denied because deny takes precedenceover allow. Closed policies thus present a scenario in whichordered semantics would make declaration easier. Conse-quently, FML supports an ordering mechanism. Named forthe cascading style sheets used on the web, an FML cascadeis a prioritized series of FML policies, written P1 < · · · < Pn.Intuitively, any policy in the ordering overrides all of thepolicies less than it. A conflict between two policies is re-solved to what the higher priority policy dictates.
For example, to define a closed authorization policy, onecould construct a cascade with two policies: P1 < P2. P2
would describe all of the flows that should be allowed, andP1 would contain a single rule:
deny(Us, Hs, As, Ut, Ht, At, P rot,Req).
Definition 3 (FML Cascade). A FML cascade con-sists of a finite set of FML policies {P1, . . . , Pn} and a totalordering < over those policies. We denote a cascade withP1 < · · · < Pn.
In a cascade P1 < · · · < Pn, the highest ranked policythat says anything about a particular flow is the only policythat says anything about that flow. In other words, policyPi determines the constraints on a flow if Pi constrains theflow in any way and there is no other Pj that constrains thatflow where j > i. Formal definitions for this intuition canbe found in [13].
While conflict resolution could arguably serve to be asconfusing as ordered policy semantics, it provides the userwith a straightforward means to define how differing con-straints should be merged. Forced order significance pre-cludes this flexibility. Furthermore, any ordered set of FMLrules, declarable here using cascades, can be equivalentlyexpressed as an unordered set of FML rules in linear time,eliminating the need for conflict resolution in environmentsbetter-suited to ordered semantics. Appendix B details algo-rithms for eliminating both cascades and keyword conflictsfrom a policy.
3. EXAMPLESTo demonstrate how FML is used in practice, in the fol-
lowing section we apply it to several common network man-agement tasks: access control, quality of service, NAT ad-ministration, and admission control. Each FML applicationwill introduce a set of keywords, describe their meanings,
3
provide examples, discuss conflict resolution, and explainpolicy enforcement issues at a high-level.
To simplify the presentation of the example policy state-ments, rather than explicitly including the usual variablesfor the eight flow fields as shown below,
allow(Us, Hs, As, Ut, Ht, At, P rot,Req) ⇐ . . .
we will denote those eight variables with a single vectorvariable F low, and write rules as allow(F low) ⇐ . . . .
These applications assume that the network architectureis such that the policy engine can intercept every flow on thenetwork, and can dictate its path and properties (such asQoS parameters). FML could equally well be used to man-age each switch individually (assuming the switch is flow-based), in which case the application would be limited toswitch-local rather than network-wide functions.
3.1 Access ControlAs briefly discussed in Section 2, in the access control
application of FML, administrators dictate whether flowsare allowed on the network, and if so, whether there are anyconstraints on the routes. The keywords are described inTable 2.
Keyword Descriptionallow0 Allow flow.deny0 Deny flow.waypoint1 Route flow through network node.avoid1 Route flow to avoid network node.ratelimit1 Limit flow’s maximum Mb/s.
Table 2: Keywords for access control policies. Sub-scripts denote the number of arguments in additionto the eight flow fields.
For example, to force wireless guest users to send all re-quests through an IDS, one could write the following rules.Note that below, guest is externally defined.
waypoint(F low, ids) ⇐guest(Us) ∧ wireless(As)
wireless(wap1)wireless(wap2)
The keywords for this application admit a variety of con-flicts: deny and any other keyword, waypoint and avoid ifthey constrain a flow’s route to both include and excludethe same intermediate node, and any keyword together withallow.
To resolve conflicts, a most-restrictive scheme is sensiblegiven the desire for security. deny is more restrictive thanwaypoint, avoid, and allow. If a flow is both required to passthrough a node via waypoint and forbidden to pass throughthat same node via avoid, the flow is denied. Otherwise, thewaypoint and avoid constraints are enforced, and if there areno deny, waypoint, or avoid constraints imposed on a flow,it is allowed.
For a realistic example of an FML access control policy,see Appendix C.
3.2 Quality of ServiceFor quality of service, administrators dictate how resources
should be allocated to different flow classes by specifying the
relative importance of certain properties: latency, jitter, andbandwidth. The keywords are described in Table 3.
Keyword Descriptionlatency1 Set maximum packet delay.jitter1 Set maximum variance in packet delay.band1 Set minimum available kbits/s.
Table 3: Keywords for QoS policies. Subscripts de-note the number of arguments in addition to theeight flow fields.
For example, VOIP requires low latency and jitter, whilebandwidth is less important. Conversely, data backups re-quire high bandwidth, but jitter and latency are less im-portant. The following policy snippet uses protocol number1233 to signify a data-backup flow.
latency(F low, 100) ⇐ Prot = voipjitter(F low, 5) ⇐ Prot = voipband(F low, 3000) ⇐ Prot = 1233
Conflicts arise when a single flow is assigned two or morevalues for the same property, e.g., a latency of 100 and200. To resolve such conflicts, we use the most-demandingscheme, which given multiple values for a single propertychooses the one that is most difficult to enforce: the lowestlatency and jitter and the highest bandwidth.
Because all application statements follow the same logi-cal model, multiple applications can be used to manage thenetwork from the same policy file (provided a sane conflictresolution strategy exists). For example, if both QoS and ac-cess controls statements are included in a policy, the lookupcould be performed as follows. Each time a flow is initiated,the QoS and access control policies are queried to determinethe constraints on the flow. Max-flow algorithms could thenbe used to choose a route through the network that satisfiesthe access control constraints and is most likely to achievethe QoS requirements (assuming the policy controller has areasonably accurate snapshot of the network state).
3.3 NATNetwork address translation (NAT) maps between two
pools of IP addresses and is generally used to allow mul-tiple machines within a private IP range to share a single,public address. Implementing such a translation requires al-tering the IP and port number of each packet leaving andentering the private network. NAT thus differs from appli-cations previously discussed in that each packet in the flowmust be modified, therefore requiring the network switchesto support this functionality.
NAT also differs from the other applications by requiringthe maintenance of state between the request and responseflows of a connection. In particular, if a flow’s source IP andport number have been overwritten, the return flow mustbe modified to the original values for the originating hostto correctly receive the response. The mapping between thenew and old values can be stored in the same location as thepolicy engine, which will be consulted upon initiation of thereturn flow. The keywords for NAT are listed in Table 4.
For example, the following statements cause every packetfrom private IP address 10.0.0.1 connected at the wirelessaccess point patio to appear to the rest of the network as
4
Keyword DescriptionsrcNAT2 Set source IP and port.dstNAT2 Set destination IP and port.unSrcNAT0 Set destination to match original source.unDstNAT0 Set source to match original destination.noChange0 Do not change flow.
Table 4: Keywords for NAT administration policy.Subscripts denote the number of arguments in ad-dition to the eight flow fields.
though they are from the public address 170.70.70.1 with amodified port. The statements force switch sw to performthe address translation.
srcNAT (F low, 170.70.70.1, sw) ⇐As = patio ∧ IPs = 10.0.0.1
unSrcNAT (F low) ⇐Ad = sw ∧ IPd = 170.70.70.1
The sw argument corresponds to the NAT switch for theprivate network—the switch that partitions the private IPaddresses from the public IPs. Since many private subnet-works may exist within a network, the same private IP maybe used in different portions of the network, and the sw ar-gument serves to differentiate which private network eachrule applies to.
This example includes a rule conditioned on the sourceIP address of a flow, a field that was not included in thedefinition of a flow (Table 1); however, that definition wasintended to be instructive, not exhaustive. Our actual im-plementation includes several other flow properties not men-tioned in Table 1, e.g., source and target IP addresses.
In this application, conflicts arise between noChange andany other keyword, and when two changes require modi-fying the same field, e.g., assigning two different addressesto the same source IP. Our resolution mechanism takes themost conservative action by prioritizing undoing of NATactions over everything else, and otherwise performing notranslation if conflicts exist. In particular, unSrcNAT andunDstNAT take precedence over all other keywords, whilenoChange does so over srcNAT and dstNAT . Conflictsamong srcNATs or dstNATs resolve to noChange.
3.4 Admission ControlAdmission control allows the administrator to specify the
authentication requirements for hosts and users to gain ac-cess to the network. Admission control can be achievedthrough FML by using it to define what default connectivityis allowed (for unauthenticated hosts), and which authenti-cation mechanisms are to be used.
For example, we have recently deployed an admission con-trol policy at a large university in which all users with pri-vate addresses must authenticate via a captive web portalbefore being given access to the network. Therefore we haveto provide default access from hosts to the web-servers, andfrom the web-servers to the directory servers.
For example, the following policy cascade sets up defaultconnectivity for authentication, and redirects all unauthen-ticated users to a captive web portal. Here we have P3 >P2 > P1.
Policy P3
allow(F low) ⇐ Prot = arpallow(F low) ⇐ Prot = dhcpallow(F low) ⇐ Ht = auth server ∧ Prot = httpallow(F low) ⇐ Hs = auth server ∧ Prot = httpPolicy P2
httpRedirect(F low, 307, auth server) ⇐Us = unknown ∧ Prot = http
Policy P1
deny(F low) ⇐ Us = unknown
The only reserved constant in FML, unknown, is used forany flow field that has no known value. The policy aboveallows ARP and DHCP messages, as well as HTTP connec-tions to and from the authentication server. In addition, anHTTP flow with an unknown source user is redirected withthe status code 307 to the host auth server. Finally, allother flows are denied.
This example extends the access control application withthe keyword httpRedirect. For conflict resolution, denyoverrides everything, and httpRedirect overrides everythingexcept deny. Multiple httpRedirect target hosts causes amultiple target redirect (status code 300), and multiplehttpRedirect status codes are resolved to a temporary redi-rect (status code 307).
4. IMPLEMENTATIONIn this section we describe our implementation of FML.
All language features are supported with the exception thatpredicates (other than keywords) are restricted to one ar-gument and are strongly typed (apply to hosts, users, oraccess points). This restriction enables linear run-time eval-uation, an improvement over polynomial time for arbitraryFML. Speed critical operations (such as run-time policychecking) are implemented in C++, while compilation andvarious integration components are written in Python. Ourimplementation is roughly 10,000 lines.
We have implemented (and deployed) all of the applica-tions mentioned in the previous section except for QoS (in-cluding access controls, NAT, and admission controls). Wenow briefly describe our implementation and its environ-ment, our real-world experiences, and provide some perfor-mance results.
4.1 Implementation EnvironmentAs mentioned previously, we have implemented FML within
NOX, a general control platform on top of which network-wide control applications can be built. NOX provides appli-cations with a global view of the network topology (links,nodes, and hosts) and the ability to be notified on significantnetwork events (e.g., a new flow has entered the network, ora host has joined the network). In addition, through NOX,applications can control the behaviour of the network bysetting up flows in the network switches (as the result of apolicy decision, for example), and sending packets.
FML operates within NOX by intercepting all new flowson the network and checking them against the current policy.If a flow is permitted, FML uses the NOX routing library tocalculate a compliant route (which may include waypoints)and then adds the flow to the flow-table of each switch alongthe path.
5
NOX builds the policy namespace, containing name toaddress bindings, by handling the authentication of net-work principals. When a principal authenticates, its nameis bound to the source access point, source MAC address,and source IP address (if it exists), used during the authen-tication exchange. The names and user credentials are gen-erally retrieved from a remote authentication store (our im-plementation supports both LDAP and AD). On successfulauthentication, the names are cached by the policy engineand indexed by address for quick retrieval on each new flow.
4.2 Policy Lookup and EvaluationSince policy consultation occurs on every flow, the eval-
uation engine has been optimized for performance and iscomprised of two components: a decision tree intended tominimize the number of rules evaluated per flow, and an al-gorithm for evaluating a given set of rules. Given a flow’seight properties, the decision tree identifies the subset of theoriginal policy that needs to be evaluated, and the evalua-tion algorithm computes the set of constraints imposed bythe selected rules on the given flow. Since the evaluation al-gorithm is standard, we focus on the decision tree indexingstructure.
The tree partitions the rules by placing all rules that con-strain the eight flow fields the same way into the same par-tition. The result is a compact representation of the rule setin an eight-dimensional space. Negative literals are ignoredby the indexer and evaluated at runtime.
Each node in the decision tree has one child for each possi-ble matching value for the dimension that node represents,e.g., a node representing Us has one child for each valueassigned to Us in the subtree’s policy rules. In addition,because some of a subtree’s rules may not constrain the di-mension a node represents, e.g., Prot in the rule below, eachnode includes an ANY child for such rules to be placed in.Each node in the decision tree is implemented using a hashtable with chaining to ensure that each of its children canbe found in near constant time. The decision as to which ofthe eight attributes to branch on at any point in the tree ismade by finding the dimension that most widely segmentsa subtree’s rule set. In particular, we select the dimensionthat minimizes the average number of rules at each childnode plus the number of ANY rules in the subtree.
For example, the rule
allow(Us, Hs, As, Ut, Ht, At, P rot, Req) ⇐Us = alice ∧ Ut = bob
mentions the source user Us and the target user Ut. Thisrule would belong to the node in the decision tree whereUs is alice and Ut is bob. Figure 1 shows one possible tree(branch), where the rule above is located in the node markedwith an asterisk. (Our decision tree also handles rules thatrequire a uniflow field to be true of a user-defined predicate,but our simple example conveys the basic premise. See [13]for more details.)
Notice that the size of the tree is dependent only on thesize of the policy, not on the number of users or hosts inthe network. For example, the source user node only has asmany children as there are constants c where the constraintUs = c occurs in some rule body. Thus FML evaluation isdependent only on the size of the policy (assuming appro-priate indexing for external references).
The total cost of FML evaluation is the cost of finding the
Us
Ut*
alice
bob
...
Figure 1: Example decision tree
pertinent rules in the tree index plus the cost of evaluatingthose rules. Rule evaluation is performed in the usual way.Conflict resolution is handled by the system directly: actionsof all matching rules are collected, and the conflict resolu-tion scheme is applied. A FML cascade is implemented byevaluating rules in priority order; once a match is found,only the remaining rules of the same priority are evaluated.
4.3 DeploymentsFML is currently being used to manage two operational
networks. The first is a small business with roughly 70 hostsconnected through 4 switches. The second deployment isat a large medical university where FML is being used toenforce policy over a roughly 200 host network. We describeeach of these deployments in more detail below.
Within the small business network, FML is being usedto enforce both admission and access control policies. Theadmission policy requires users on workstations and lap-tops to authenticate via a captive web-portal (against anLDAP authentication store) before being permitted accessto the network. The access policy is roughly as follows. Ap-plication servers are allowed unrestricted access, while testservers are unable to connect to the Internet. Servers andprinters should only allow inbound connections (except foroutgoing SSH sessions on server), providing protection sim-ilar to a DMZ. Laptops and mobile devices (such as mobilephones supporting Wi-Fi) are not allowed inbound connec-tions (similar to NAT). We also have a few rules that allowmonitoring and diagnostic traffic between an administrativehost and all switches. The policy file for this network is justover 40 lines.
Like the small business network, the deployment at themedical university enforces basic admission and access poli-cies. However, it also makes use of NAT and waypointing.The policy dictates that all laptops must be NAT’d (pro-tecting them from inbound traffic). It also requires that allHTTP traffic traverse a proxy before leaving the campusnetwork.
Flow setup latencies (involving two permission checks,route calculations, and flow-entry setups) are generally un-der 20ms. In our deployments, there is not enough trafficto stress our implementation (we generally see less than 100new flow setups/s even in the larger network). Howeverin benchmarks using generated traffic, our implementationrunning with our internal policy file supports permissionchecks on over 30,000 flows/s, over three times that of anynetwork we have measured. We present more performancetests of the system under load below.
4.4 PerformanceWe tested the performance and memory overhead of our
implementation with policy files of increasing size (Table 5).
6
All policies (except those with 0 rules) forced a maximumdepth tree once constructed. For each incoming flow, onaverage log2(#rules) matched and had to be evaluated bythe system. Table 6 shows the same test using policies inwhich 10% of the rules contain ANY fields (the number offields containing ANYs is evenly distributed between 1 andthe maximum number of fields). In this case, the increasednumber of rules matching a given flow due to the numberof ANYs causes a performance degradation in larger policyfiles.
The goal of this analysis is not to provide an exhaustiveinvestigation of the performance of our implementation, butrather to gain some insight into its handling of load undervarious rule sets. As shown in [7], even large enterprise net-works of tens of thousands of hosts generally have less than10,000 flow requests per second, far below the performancecapabilities of our implementation for the rule sets tested.
flows/s Mbytes avg. matches0 rules 103,699 0 0100 rules 78,808 0 41,000 rules 75,414 2 710,000 rules 67,843 56 9
Table 5: Performance and memory overhead of ourFSL implementation over policies with increasingrule count. The rightmost column contains the av-erage number of matching rules per flow.
flows/s Mbytes avg. matches0 rules 103,699 0 0100 rules 100,942 1 21,000 rules 76,336 2 1010,000 rules 46,956 38 52
Table 6: Performance and memory overhead of ourFSL implementation over policies declared over 1000principals in which 10% of the rules contain ANYs.The rightmost column contains the average numberof matching rules per flow.
5. RELATED WORKDeclarative languages have been proposed for numerous
applications by the security and artificial intelligence com-munities. Here we summarize which language features FMLincludes; other features were left out most often becauseof the severe performance requirement (10−4 seconds perquery).
FML is based on a restricted form of datalog with nega-tion, e.g., [15], allows conflicts, e.g., [18], admits automateddetection of conflicts, e.g., [3], and adheres to a fixed conflictresolution scheme, e.g., [18, 15]. As is standard in databaseapplications, FML policies reference external sources, e.g.,[5]; it also employs a sequential semantics operator (called“overrides” in [5] and “exceptions” in [4]) via FML Cascades.For a more comprehensive treatment of related work, see[13].
The highest-level design decision was to base FML on dat-alog instead of, for example, first-order logic [12], modallogic [1], or linear logic [6]. Besides efficient implementa-tion, two features of datalog stand out. First, its similarityto traditional programming languages makes it accessible toour target audience: network operators (who may be logic
novices). Second, its semantics guarantees that true disjunc-tion is inexpressible. If true disjunction were expressible, aFML policy could deny one of two flows without specify-ing which. Such expressiveness has questionable utility andmakes enforcement especially problematic.
There have been a number of approaches proposed formaking firewall configuration more manageable. These in-clude the use of entity relationship modeling [2] and high-level language design (e.g., [11]). Our work has similar ob-jectives, yet we broaden the scope of the configuration be-yond filtering policies for firewalls to include other commonnetwork configurations such as QoS, route control, NAT,and broadcast isolation.
6. CONCLUSION AND FUTURE WORKIn this paper we described FML a new langauge for declar-
ing network connectivity policies as a set of ordered con-straints. FML allows succinct, structured, high-level spec-ification of various management tasks, freeing network ad-ministrators from the drudgery of configuring myriad routerACLs, firewalls, NATs and VLANs to achieve comprehensiveand conceptually straightforward network usage policies.
FML is a declarative policy language based on nonrecur-sive datalog with structured negation. The declarative na-ture of FML enables administrators to focus on policy deci-sions instead of implementation details. In addition, logic-based algorithms that detect and resolve conflicts in pre-dictable and reliable ways may be incorporated into policydevelopment environments. FML also supports prioritizedpolicy combination, which is a natural way to express manypolicies and enables incremental policy updates.
FML is not merely a paper design. We have used it inseveral operational networks, and have subjected it to addi-tional tests using much more demanding artificially gener-ated loads. This operational experience demonstrates thatour implementation has modest memory requirements andcan scale to very large networks while supporting policy filesof tens of thousands of rules.
In the future we plan to investigate how FML policiescan automatically be decomposed to support distributed en-forcement, thereby lessening the impact of a centralized con-troller. Such a scheme would enable centralized, authorita-tive policy authoring and analysis yet retain the robustnessof today’s networks. While our current infrastructure suf-fices to address small and medium networks, automatic de-composition could enlarge the applicability of FML to large,international networks as well.
We also plan to develop a tool suite for analyzing FMLpolicies. For example, FML supports both developer andadministrator supplied forms of conflict resolution, both ofwhich can make understanding large FML policies difficult.While the algorithms in Appendix B demonstrate that con-flicts can be removed automatically, the resulting policiesare far from user-friendly. A suite of sophisticated, user-friendly tools would help operators debug and feel confidentabout their FML policies.
Finally, FML relies heavily on developer-chosen keywordsthat encode all the possible constraints that may be imposedon a flow for a given application. To implement a new ap-plication, a developer must write custom software that im-plements each of the keywords, as well as conflict resolution.It would be preferable if FML allowed administrators to in-
7
vent new keywords by writing additional policy statementsaxiomatizing the meaning of those keywords, and the FMLimplementation would compile those statements to impera-tive code. This would enable administrators to impose con-straints on flows not anticipated by the NOX developers.
7. ACKNOWLEDGEMENTSWe would like to thank Michael Genesereth and Jad Naous
for their helpful feedback during the FML design process.We would also like to thank the Nox development team,particularly Dan Wendlandt and Teemu Koponen for sig-nificant contributions towards the implementation. Finally,we would like to thank the anonymous reviewers for theircomments.
8. REFERENCES[1] M. Abadi, M. Burrows, and B. Lampson. A calculus
for access control in distributed systems. ACMTransactions on Programming Languages andSystems, 15(4), 1993.
[2] Y. Bartal, A. Mayer, K. Nissim, and A. Wool.Firmato: A novel firewall management toolkit. ACMTrans. Comput. Syst., 22:381–420, 2004.
[3] A. Barth, J. C. Mitchell, and J. Rosenstein. Conflictand combination in privacy policy languages. In Proc.of the ACM Workshop on Privacy in the ElectronicSociety, 2004.
[4] E. Bertino, S. Jajodia, and P. Samarati. A flexibleauthorization mechanism for relational datamanagement systems. ACM Transactions onInformation Systems, 17(2), 1999.
[5] P. A. Bonatti, S. D. di Vimercati, and P. Samarati. Amodular approach to composing access controlpolicies. In In ACM CCS, 2000.
[6] K. D. Bowers, L. Bauer, D. Garg, F. Pfenning, andM. K. Reiter. Consumable credentials in logic-basedaccess-control systems. In Proc. of the NDSS, 2007.
[7] M. Casado, M. J. Freedman, J. Pettit, J. Luo,N. McKeown, and S. Shenker. Ethane: Taking controlof the enterprise. In Proc. ACM SIGCOMMConference, Kyoto, Japan, Aug. 2007.
[8] L. Cranor, M. Langheinrich, M. Marchiori,M. Presler-Marshall, and J. Reagle. The platform forprivacy preferences 1.0 (P3P1.0) specification, 2002.
[9] S. Egelman, L. F. Cranor, and A. Chowdhury. Ananalysis of p3p-enabled web sites among top-20 searchresults. In ICEC ’06: Proceedings of the 8thinternational conference on Electronic commerce, NewYork, NY, USA, 2006.
[10] N. Gude, T. Koponen, J. Pettit, B. Pfaff, M. Casado,N. McKeown, and S. Shenker. NOX: Towards andoperating system for networks. In ACM SIGCOMMComputer Communication Review, July 2008.
[11] J. D. Guttman. Filtering postures: Local enforcementfor global policies. In In Proceedings, 1997 IEEESymposium on Security and Privacy, pages 120–129.IEEE Computer Society Press, 1997.
[12] J. Y. Halpern and V. Weissman. Using first-order logicto reason about policies. In Proc. of the IEEEComputer Security Foundations Symposium, 2003.
[13] T. Hinrichs, N. Gude, M. Casado, J. Mitchell, andS. Shenker. Expressing and enforcing flow-basednetwork security policies. Technical report, Universityof Chicago, 2008.
[14] S. Ioannidis, A. D. Keromytis, S. M. Bellovin, andJ. M. Smith. Implementing a distributed firewall. InACM Conference on Computer and CommunicationsSecurity, 2000.
[15] S. Jajodia, P. Samarati, and V. S. Subrahmanian. Alogical language for expressing authorizations. In Proc.IEEE Symposium on Security and Privacy, 1997.
[16] B. Parducci, H. Lockhart, R. Levinson, J. B. Clark,and M. McRae. eXtensible Access Control MarkupLanguage (XACML) specification, 2005.
[17] J. Ullman. Principles of Database andKnowledge-Base Systems. 1989.
[18] D. Wijesekera and S. Jajodia. Policy algebras foraccess control - the predicate case. In Proc. ACMCCS, 2001.
[19] G. Xie, J. Zhan, D. A. Maltz, H. Zhang,A. Greenberg, and G. Hjalmtysson. Routing design inoperational networks: A look from the inside. In Proc.ACM SIGCOMM ’04, New York, NY, USA, 2004.
[20] L. Yuan and H. Chen. FIREMAN: A toolkit forfirewall modeling and analysis. In Proc. of the IEEESymposium on Security and Privacy, 2006.
APPENDIXA. PROOFS
Theorem 1 (FML languages are polynomial). Givena policy written in a FML language and a query of the formkey(t1, . . . , tn), evaluating the query takes polynomial time.
Proof. FML is a syntactic variant of nonrecursive dat-alog with negation where the variables in the body of everyrule must appear in the head. It is simple to see by induc-tion on the number of extension (backward-chaining) opera-tions needed to evaluate the query that the number of argu-ments to every predicate participating in that evaluation isno greater than n (the number of arguments to key). This isimportant because n is a constant (independent of the pol-icy), and a well-known result of datalog guarantees thatif all of the predicates take no more than a constant num-ber of arguments, evaluation is polynomial. Thus, evalua-tion of the query is polynomial because the fragment of thepolicy used during evaluation obeys the constant-argumentassumption.
Here we sketch a proof of the well-known result: if all ofthe predicates in the rule set take no more than c arguments,then evaluation is polynomial in the size of the rule set anddata. Consider any rule.
p(t̄) ⇐ [¬]b1(t1) ∧ · · · ∧ [¬]bm(tm)
The number of ground instances of this rule is at most |U |c,where U is the universe, because once every variable in thehead of the rule is bound, every variable in the body isbound also. Because c is a constant, |U |c is a polynomial;consequently, grounding a rule set takes polynomial time.To determine whether a ground set of rules entails a groundatom, one can use a variant of the context-free grammar(CFG) marking algorithm for determining whether a givengrammar is empty.
8
If negation does not occur in the rules, the CFG markingalgorithm is exactly the right algorithm to use. This algo-rithm runs in time polynomial in the size of the input, whichis polynomial in the size of the original sentences.
If negation does occur, the marking algorithm needs tobe altered so that it only marks negative literals once allthe positive consequences have been marked. The result isan algorithm that runs the CFG algorithm no more timesthan the number of the original sentences, which again is apolynomial algorithm.
B. ALGORITHMSThe algorithms presented in this section demonstrate that
both keyword and cascade conflicts can be removed auto-matically from FML. For the sake of brevity, the algorithmsare illustrated using just the keywords allow and deny; gen-eralizing to an arbitrary set of keywords is straightforward.The first section introduces a special form for FML poli-cies that simplifies the presentation of the subsequent algo-rithms. In the examples that follow, we use F low to repre-sent the usual sequence of variables:
Us, Hs, As, Ut, Ht, At, P rot, Req.
B.1 Inline Normal FormFor the upcoming algorithms, it is convenient if a FML
policy mentions no intermediate predicates. An intermedi-ate predicate is any predicate that is not an external refer-ence, a keyword, or =. We say that a policy where the onlypredicates are non-intermediaries is in Inline Normal Form(INF).
For example, the following policy uses the intermediatesymbols host and private.
allow(F low) ⇐ host(Hs)host(X) ⇐ private(X)host(X) ⇐ server(X)private(X) ⇐ desktop(X)private(X) ⇐ laptop(X)
An equivalent policy, written in INF is shown below.
allow(F low) ⇐ server(Hs)allow(F low) ⇐ desktop(Hs)allow(F low) ⇐ laptop(Hs)
(2)
Transforming a policy into INF is straightforward. Wesay that the definition for a predicate p is the disjunction ofall the rule bodies where p occurs in the head (after canoni-calizing the head of each rule). To compute INF, repeat thefollowing procedure until all of the intermediate predicatesin rule bodies have been removed: each time an intermediatepredicate occurs in the body of a rule, inline the definitionfor that predicate. Afterwards, every predicate in the bodyof a rule is an external reference or =.
In the above example, it takes two iterations of inliningbefore all of the intermediate predicates have been removed.Concentrating on just the allow rule, the result of replacinghost with its definition is
allow(F low) ⇐ (private(Hs) ∨ server(Hs))
The result of replacing private with its definition is:
allow(F low) ⇐ ((desktop(Hs) ∨ laptop(Hs)) ∨ server(Hs))
This procedure produces rules with arbitrary boolean for-mulae in the body. Such rules are sometimes convenient,even though they do not change the expressiveness of thelanguage. A set of rules where the bodies can include arbi-trary boolean formulae and the only predicates mentionedare the keywords, external group symbols, and =, is in Ex-tended Inline Normal Form (EINF).
To convert EINF rules into INF requires converting toconjunctive normal form (CNF) (without introducing inter-mediate predicates). The standard recursive-descent clausalform conversion algorithm does just this.
B.2 Flattening a FML CascadeFML was designed so that administrators could indepen-
dently author pieces of a security policy for a network andthen automatically combine those pieces. FML cascadesmake expressing and editing certain policies easier; conse-quently, we expect that sometimes administrators will ex-press their policies as cascades. Thus, despite the order-relevance of a cascade, we need algorithms that automati-cally combine them while preserving their semantics. Ourapproach transforms each FML cascade into an equivalentFML policy and then combines the resulting policies in theusual way.
To illustrate how a FML cascade can be flattened intoa single FML policy, consider a simple example with twopolicies, each with a single rule. Policy P1 says that wirelessusers cannot connect to the Human Resources (HR) server,and policy P2, which overrides P1, says that the CEO cando as he pleases. The ordering is P1 < P2.
P1 : deny(F low) ⇐ wireless(As) ∧ Ht = hrserverP2 : allow(F low) ⇐ Us = ceo
This cascade says that every wireless guest user except forthe CEO is denied from accesssing the HR server, and theCEO can access everything. To write this cascade as a singlepolicy, it is sufficient to negate the conditions under whichthe rule in P2 applies and add the result to the conditionsin the P1 rule.
deny(F low) ⇐ wireless(As) ∧ Ht = hrserver ∧ Us %= ceoallow(F low) ⇐ Us = ceo
In general, suppose the two policies are written in Ex-tended Inline Normal Form with exactly one rule for allowand one rule for deny. In policy P1, there are exactly tworules.
deny(F low) ⇐ φ1(F low)allow(F low) ⇐ ψ1(F low)
Likewise, policy P2 contains two rules, denoted by subscript-ing with a two instead of a one. In the cascade P1 < P2,a rule in P1 only applies if none of the rules in P2 apply.The rules in P2 apply when either φ2(F low) or ψ2(F low) istrue; the rules in P2 do not apply when neither of those sen-tences is true. Such a policy can be constructed by addingconstraints to each rule in P1, the result of which is shownbelow, while including the rules in P2 as they are.
deny(F low) ⇐ φ1(F low) ∧ ¬φ2(F low) ∧ ¬ψ2(F low)allow(F low) ⇐ ψ1(F low) ∧ ¬φ2(F low) ∧ ¬ψ2(F low)
Generalizing to n policies is straightforward, and it turns outthat by using intermediate predicates, there is an algorithmthat flattens a FML policy in linear time.
9
B.3 Conflict ConditionsOne of the features of FML, introduced to facilitate col-
laborative policy authoring, is the ability to express conflictsusing keywords. One administrator may want to deny a classof flows, and another administrator may want to allow thatclass. Algorithms for detecting conflicts are important be-cause people who contributed conflicting statements can bemade aware of their conflicting intentions.
Certain types of conflicts can always be detected at compile-time (static conflicts), but other types of conflicts can onlybe detected at run-time because they depend on the exter-nal references. In general, the best we can hope for are theconditions on the external references (expressed as logicalformulae) that characterize the conflicts.
Consider an example. The following rules rely on the ex-ternal references q and r.
allow(F low) ⇐ q(Us)deny(F low) ⇐ r(Us)
These rules conflict only when there is some user that be-longs to both the groups q and r. Since we do not knowat compile-time whether there is such a user, the best wecan do is state the conditions under which there is a conflictbetween these two rules: q(Us) ∧ r(Us).
To construct the conditions under which a policy is con-flicting, suppose the policy has been written in EINF withone rule for allow and one rule for deny.
deny(F low) ⇐ φ(F low)allow(F low) ⇐ ψ(F low)
The conditions under which a conflicts occurs is given bythe following expression.
φ(F low) ∧ ψ(F low)
Admittedly, such an expression needs to be simplified be-fore being presented to a real person, but conceptually, com-puting the conditions under which conflicts occur is straight-forward.
B.4 Conflict-free Normal FormThe fact that FML policies allow keyword conflicts is a
powerful property because it enables the system to under-stand more fully the users’ intentions; however, because areal system can only enforce a conflict-free policy, those con-flicts are resolved automatically. The downside to this ap-proach is that a person looking at the current policy mayhave a hard time understanding why the system constrains agiven flow the way it does. Finding a single rule that says aflow is allowed is insufficient for concluding that the systemwill allow that flow. There may be another rule that says todeny that flow, and the deny rule takes precedence.
The algorithm outlined next transforms a given policy Pinto a new policy P ′ such that P ′ is conflict free and Pand P ′ are equivalent when deny overrides allow. Whenexamining P ′, finding a rule that allows a flow is sufficientfor determining that policy as a whole allows that flow. Wesay that a policy without conflicts is in Conflict-free NormalForm (CFNF).
Suppose the policy has been written in Extended InlineNormal Form with exactly one rule for allow and for deny.
deny(F low) ⇐ φ(F low)allow(F low) ⇐ ψ(F low)
The conflict resolution policy says that deny overridesallow; thus, the allow rule only applies when the deny rulebody is false. The transformation to CFNF is accomplishedby conjoining the negation of the deny rule body to theallow rule body. The deny rule need not be altered.
allow(F low) ⇐ ψ(F low) ∧ ¬φ(F low)
C. EXAMPLE POLICYThe policy cascade shown in Figure 2 is the one used
for access control in our internal network. The policies areshown from highest to lowest priority: P1 < P2 < P3 < P4.
Policy P4
# allow ARP and DHCPallow(F low) ⇐ Prot = arpallow(F low) ⇐ Prot = dhcps ∧ Ht = gateway
# allow computers to ssh anywhereallow(F low) ⇐ Prot = ssh ∧ computer(Hs)
# allow internal monitoring flows:# proprietary protocols registered with the systemallow(F low) ⇐ Prot = 1616 ∧ Hs = badwaterallow(F low) ⇐ Prot = 1717 ∧ Hs = badwaterallow(F low) ⇐ Prot = 1818 ∧ Hs = badwaterallow(F low) ⇐ Prot = 1616 ∧ Ht = badwaterallow(F low) ⇐ Prot = 1717 ∧ Ht = badwaterallow(F low) ⇐ Prot = 1818 ∧ Ht = badwater
Policy P3
# dissallow external communications for# testing machinesdeny(F low) ⇐ testing(Hs)deny(F low) ⇐ testing(Ht)
# servers should be inbound-onlydeny(F low) ⇐ Req = true ∧ server(Hs)deny(F low) ⇐ Req = true ∧ printer(Hs)
# laptops and mobile devices# should be outbound-onlydeny(F low) ⇐ Req = true ∧ mobile(Ht)deny(F low) ⇐ Req = true ∧ laptop(Ht)
Policy P2
# allow known devices to communicate as long as# they abide by the previous rules.allow(F low) ⇐ all(Hs)
Policy P1
# default denydeny(F low)
Figure 2: Cascaded policy for internal network.
10