cross-domain privacy-preserving cooperative firewall optimization

IEEE/ACM TRANSACTIONS ON NETWORKING, VOL. 21, NO. 3, JUNE 2013 857

Cross-Domain Privacy-Preserving CooperativeFirewall Optimization

Fei Chen, Bezawada Bruhadeshwar, and Alex X. Liu

Abstract—Firewalls have been widely deployed on the Internetfor securing private networks. A firewall checks each incoming oroutgoing packet to decide whether to accept or discard the packetbased on its policy. Optimizing firewall policies is crucial for im-proving network performance. Prior work on firewall optimiza-tion focuses on either intrafirewall or interfirewall optimizationwithin one administrative domain where the privacy of firewallpolicies is not a concern. This paper explores interfirewall opti-mization across administrative domains for the first time. The keytechnical challenge is that firewall policies cannot be shared acrossdomains because a firewall policy contains confidential informa-tion and even potential security holes, which can be exploited byattackers. In this paper, we propose the first cross-domain pri-vacy-preserving cooperative firewall policy optimization protocol.Specifically, for any two adjacent firewalls belonging to two dif-ferent administrative domains, our protocol can identify in eachfirewall the rules that can be removed because of the other fire-wall. The optimization process involves cooperative computationbetween the two firewalls without any party disclosing its policy tothe other. We implemented our protocol and conducted extensiveexperiments. The results on real firewall policies show that our pro-tocol can remove as many as 49% of the rules in a firewall, whereasthe average is 19.4%. The communication cost is less than a fewhundred kilobytes. Our protocol incurs no extra online packet pro-cessing overhead, and the offline processing time is less than a fewhundred seconds.

Index Terms—Firewall optimization, privacy.

I. INTRODUCTION

A. Background and Motivation

F IREWALLS are critical in securing private networks ofbusinesses, institutions, and home networks. A firewall is

often placed at the entrance between a private network and theexternal network so that it can check each incoming or outgoing

Manuscript received May 27, 2011; revised December 23, 2011 and June21, 2012; accepted July 30, 2012; approved by IEEE/ACM TRANSACTIONS ONNETWORKING Editor I. Keslassy. Date of publication October 09, 2012; dateof current version June 12, 2013. This material is based in part upon work sup-ported by the National Science Foundation under Grant No. CNS-1017598. Thepreliminary version of this paper titled “A Cross-Domain Privacy-PreservingProtocol for Cooperative Firewall Optimization” was published in the Proceed-ings of the IEEE International Conference on Computer Communications (IN-FOCOM), Shanghai, China, April 10–15, 2011. (Corresponding author: A. X.Liu.)F. Chen was with the Department of Computer Science and Engineering,

Michigan State University, East Lansing, MI 48824 USA. He is now withVMware, Inc., Palo Alto, CA 94304 USA (e-mail: [email protected]).A. X. Liu is with the Department of Computer Science and Technology, Nan-

jing University, Nanjing 210093, China (e-mail: [email protected]).B. Bruhadeshwar is with the Center for Security, Theory, and Algorithmic Re-

search, International Institute of Information Technology, Hyderabad 500032,India (e-mail: [email protected]).Color versions of one or more of the figures in this paper are available online

at http://ieeexplore.ieee.org.Digital Object Identifier 10.1109/TNET.2012.2217985

Fig. 1. Effect of the number of rules on the throughput with frame size 128 Bin [1].

packet and decide whether to accept or discard the packet basedon its policy. A firewall policy is usually specified as a sequenceof rules, called Access Control List (ACL), and each rule has apredicate over multiple packet header fields (i.e., source IP, des-tination IP, source port, destination port, and protocol type) anda decision (i.e., accept and discard) for the packets that matchthe predicate. The rules in a firewall policy typically follow thefirst-match semantics, where the decision for a packet is the de-cision of the first rule that the packet matches in the policy.Each physical interface of a router/firewall is configured withtwo ACLs: one for filtering outgoing packets and the other onefor filtering incoming packets. In this paper, we use firewalls,firewall policies, and ACLs, interchangeably.The number of rules in a firewall significantly affects its

throughput. Fig. 1 shows the result of the performance testof iptables conducted by HiPAC [1]. It shows that increasingthe number of rules in a firewall policy dramatically reducesthe firewall throughput. Unfortunately, with the explosivegrowth of services deployed on the Internet, firewall policiesare growing rapidly in size. Thus, optimizing firewall policiesis crucial for improving network performance.

B. Limitation of Prior Work

Prior work on firewall optimization focuses on eitherintrafirewall optimization [7], [15]–[21] or interfirewall op-timization [3], [30] within one administrative domain wherethe privacy of firewall policies is not a concern. Intrafirewalloptimization means optimizing a single firewall. It is achievedby either removing redundant rules [15], [17] or rewritingrules [7], [16], [18]–[21]. Prior work on interfirewall opti-mization requires two firewall policies without any privacyprotection, and thus can only be used within one administrativedomain. However, in reality, it is common that two firewallsbelong to different administrative domains where firewallpolicies cannot be shared with each other. Keeping firewallpolicies confidential is important for two reasons. First, a

1063-6692/$31.00 © 2012 IEEE

858 IEEE/ACM TRANSACTIONS ON NETWORKING, VOL. 21, NO. 3, JUNE 2013

Fig. 2. Example interfirewall redundant rules.

firewall policy may have security holes that can be exploited byattackers. Quantitative studies have shown that most firewallsare misconfigured and have security holes [25]. Second, afirewall policy often contains private information, e.g., the IPaddresses of servers, which can be used by attackers to launchmore precise and targeted attacks.

C. Cross-Domain Interfirewall Optimization

To our best knowledge, no prior work focuses on cross-do-main privacy-preserving interfirewall optimization. This paperrepresents the first step in exploring this unknown space.Specifically, we focus on removing interfirewall policy redun-dancies in a privacy-preserving manner. Consider two adjacentfirewalls 1 and 2 belonging to different administrative domains

and . Let denote the policy on firewall 1’soutgoing interface to firewall 2 and denote the policy onfirewall 2’s incoming interface from firewall 1. For a rule in

, if all the packets that match but do not match any ruleabove in are discarded by , rule can be removedbecause such packets never come to . We call rule aninterfirewall redundant rule with respect to . Note that

and only filter the traffic from to ;the traffic from firewall 2’s outgoing interface to firewall 1’sincoming interface is guarded by other two separate policies.For simplicity, we assume that and have no in-trafirewall redundancy as such redundancy can be removedusing the proposed solutions [15], [17].Fig. 2 illustrates interfirewall redundancy, where two adjacent

routers belong to different administrative domains CSE and EE.The physical interfaces connecting two routers are denoted asand , respectively. The rules of the two firewall policiesand , that are used to filter the traffic flowing from CSE toEE, are listed in two tables following the format used in CiscoAccess Control Lists. Note that SIP, DIP, SP, DP, PR, and Decdenote source IP, destination IP, source port, destination port,protocol type, and decision, respectively. Clearly, all the packetsthat match and in are discarded by in . Thus,and of are interfirewall redundant with respect to

in .

D. Technical Challenges and Our Approach

The key challenge is to design a protocol that allows twoadjacent firewalls to identify the interfirewall redundancywith respect to each other without knowing the policy ofthe other firewall. While intrafirewall redundancy removal iscomplex [15], [17], interfirewall redundancy removal with theprivacy-preserving requirement is even harder. To determinewhether a rule in is interfirewall redundant with respect

to , certainly needs some information about ;yet, cannot reveal from such information.A straightforward solution is to perform a privacy preserving

comparison between two rules from two adjacent firewalls. Par-ticularly, for each rule in , this solution checks whetherall possible packets that match rule in match a rulewith the discard decision in . If rule exists, is interfire-wall redundant with respect to in . However, becausefirewalls follow the first-match semantics and the rules in a fire-wall typically overlap, this solution is not only incorrect but alsoincomplete. Incorrect means that wrong redundant rules couldbe identified in . Suppose this solution identifies as a re-dundant rule in with respect to in . However, ifsome packets that match rule also match rule ( is above) with the accept decision in , these packets will pass

through , and then needs to filter them with . Inthis case, is actually not redundant. Incomplete means that aportion of redundant rules could be identified in . If allpossible packets that match rule in are discarded by notonly one rule but multiple rules in , is also redundant.However, the direct comparison solution cannot identify suchredundancies.Our basic idea is as follows. For each rule in , we

first compute a set of compact predicates representing the set ofpackets that match but do not match the rules above in .Then, for each predicate, we check whether all the packets thatmatch the predicate are discarded by . If this conditionholds for all the predicates computed from rule , then rule isredundant. To efficiently compute these predicates, we convertfirewalls to firewall decision diagrams [17]. To allow the twofirewalls to detect the redundant rules in in a privacy-preserving manner, we develop a protocol so that two firewallscan detect such redundant rules without disclosing their policiesto each other.Our protocol applies to both stateful and stateless firewalls.

The main difference between stateful and stateless firewallsis that stateful firewalls maintain a connection table. Uponreceiving a packet, if it belongs to an established connection,it is automatically accepted without checking against the rules.Having the connection table or not does not affect our protocol.

E. Key Contributions

We make two key contributions. First, we propose a novelprivacy-preserving protocol for detecting interfirewall redun-dant rules in one firewall with respect to another firewall. Thispaper represents the first effort along this unexplored direction.Second, we implemented our protocol and conducted extensiveexperiments on both real and synthetic firewall policies. The re-sults on real firewall policies show that our protocol can removeas many as 49% of the rules in a firewall whereas the averageis 19.4%. The communication cost is less than a few hundredkilobytes. Our protocol incurs no extra online packet processingoverhead, and the offline processing time is less than a few hun-dred seconds.We organize the paper as follows. We first review related

work in Section II. Then, we introduce our system model andthreat model in Section III. In Section IV, we present our pri-vacy-preserving protocol for detecting interfirewall redundantrules. In Section V, we discuss remaining issues. In Section VI,we give security analysis results of our protocol. In Section VII,

CHEN et al.: CROSS-DOMAIN PRIVACY-PRESERVING COOPERATIVE FIREWALL OPTIMIZATION 859

we present our experimental results. Finally, we conclude inSection VIII.

II. RELATED WORK

A. Firewall Redundancy Removal

Prior work on intrafirewall redundancy removal aims to de-tect redundant rules within a single firewall [12], [15], [17].Gupta identified backward and forward redundant rules in a fire-wall [12]. Later, Liu et al. pointed out that the redundant rulesidentified by Gupta are incomplete and proposed two methodsfor detecting all redundant rules [15], [17]. Prior work on in-terfirewall redundancy removal requires the knowledge of twofirewall policies and therefore is only applicable within one ad-ministrative domain [3], [30].

B. Collaborative Firewall Enforcement in Virtual PrivateNetworks (VPNs)

Prior work on collaborative firewall enforcement in VPNsenforces firewall policies over encrypted VPN tunnels withoutleaking the privacy of the remote network’s policy [6], [13]. Theproblems of collaborative firewall enforcement in VPNs andprivacy-preserving interfirewall optimization are fundamentallydifferent. First, their purposes are different. The former focuseson enforcing a firewall policy over VPN tunnels in a privacy-preserving manner, whereas the latter focuses on removing in-terfirewall redundant rules without disclosing their policies toeach other. Second, their requirements are different. The formerpreserves the privacy of the remote network’s policy, whereasthe latter preserves the privacy of both policies.

III. SYSTEM AND THREAT MODELS

A. System Model

A firewall is an ordered list of rules. Each rule has apredicate over fields and a decision for the packetsthat match the predicate. Firewalls usually check five fields:source IP, destination IP, source port, destination port, and pro-tocol type. The length of these fields are 32, 32, 16, 16, and8 bits, respectively. A predicate defines a set of packets overthe fields and is specified as ,where each is a subset of ’s domain . A packet overthe fields is a -tuple where each

is an element of . A packetmatches a rule if andonly if the condition holds. Typicalfirewall decisions include accept, discard, accept with logging,and discard with logging. Without loss of generality, we onlyconsider accept and discard in this paper. We call a rule withthe accept decision an accepting rule and a rule with the dis-card decision a discarding rule. In a firewall policy, a packetmay match multiple rules whose decisions are different. To re-solve these conflicts, firewalls typically employ a first-matchsemantics where the decision for a packet is the decision ofthe first rule that matches. A matching set of , , isthe set of all possible packets that match the rule [15]. A re-solving set of , , is the set of packets that match butdo not match any rule above , and is equalto [15].Based on the above concepts, we define interfirewall redun-

dant rules. Given two adjacent firewalls and , where

the traffic flow is from to , a rule in is in-terfirewall redundant with respect to if and only if all thepackets in ’s resolving set are discarded by .

B. Threat Model

We adopt the semi-honest model in [9]. For two adjacent fire-walls, we assume that they are semi-honest, i.e., each firewallfollows our protocol correctly, but each firewall may try to re-veal the policy of the other firewall. The semi-honest model isrealistic and well adopted [4], [26]. For example, this model isappropriate for large organizations that have many independentbranches as well as for loosely connected alliances composedby multiple parties. While we are confident that all administra-tive domains follow mandate protocols, we may not guaranteethat no corrupted employees are trying to reveal the private fire-wall policies of other parties. Also, it may be possible for oneparty to issue a sequence of inputs to try and reveal the otherparty’s policy. For this attack to be successful, several assump-tions have to be satisfied, one of them being that one firewall’spolicy remain constant. Another requirement is that the numberof times the protocol needs to be executed to reveal a significantamount of rules is computationally expensive.1 Such maliciousactivitiy may be identified by the other party using anomaly de-tection approaches [27]–[29]. However, in our threat model, theinputs to the protocol are honest, and crafting inputs to reveal thefirewall policies is beyond our threat model. We leave investi-gation of privacy-preserving firewall optimization in the modelwith malicious participants to future work.

IV. PRIVACY-PRESERVING INTERFIREWALL REDUNDANCYREMOVAL

In this section, we present our privacy-preserving protocol fordetecting interfirewall redundant rules in with respect to

. To do this, we first convert each firewall to an equivalentsequence of nonoverlapping rules. Because for any nonoverlap-ping rule , the matching set of is equal to the resolving setof , i.e., , we only need to compare nonover-lapping rules generated from the two firewalls for detectinginterfirewall redundancy. Second, we divide this problem intotwo subproblems, single-rule coverage redundancy detectionand multirule coverage redundancy detection, and then proposeour privacy-preserving protocol for solving each subproblem. Arule is covered by one or multiple rulesif and only if . The firstsubproblem checks whether a nonoverlapping rule inis covered by a nonoverlapping discarding rule in , i.e.,

. The second subproblem checks whether anonoverlapping rule in is covered bymultiple nonover-lapping discarding rules in , i.e.,

. Finally, after redundantnonoverlapping rules generated from are identified, wemap them back to original rules in and then identify theredundant ones.The problem of checking whether boils

down to the problem of checking whether one range inis contained by another range in , which further

boils down to the problem of checking whether

1It requires log updates to reveal -bit field. Given that rule has fields, thecomplexity is updates for a single rule whereby such high communicationactivity can be detected by anomaly detection approaches.


and . Thus, we first describe the privacy-preservingprotocol for comparing a number and a range.

A. Privacy-Preserving Range Comparison

To check whether a number from is in a rangefrom , we use a method similar to the prefix membershipverification scheme in [13]. The basic idea is to convert theproblem of checking whether to the problem ofchecking whether two sets converted from and havea common element. Our method consists of four steps.1) Prefix Conversion: It converts to a minimum

number of prefixes, denoted as , whose union is. For example, .

2) Prefix Family Construction: It generates all the prefixesthat contain including itself. This set of prefixes is calledthe prefix family of , denoted as . Let be the bit lengthof . The prefix family consists of prefixes wherethe th prefix is obtained by replacing the last bits of by. For example, as the binary representation of 12 is 1100, wehave . It is not difficultto prove that if and only if .3) Prefix Numericalization: It converts the prefixes gener-

ated in the previous steps to concrete numbers such that we canencrypt them in the next step. We use the prefix numericaliza-tion scheme in [5]. Given a prefix of bits, wefirst insert 1 after . The bit 1 represents a separator between

and . Then, we replace every by 0. For ex-ample, 11 is converted to 11100. If the prefix does not contain’s, we place 1 at the end. For example, 1100 is converted to11001.4) Comparison: It checks whether by checking

whether , which boils down to checkingwhether two numbers are equal. We use commutative en-cryption to do this checking in a privacy-preserving manner.Given a number and two encryption keys and , acommutative encryption is a function that satisfies the property

, i.e., encryption with key firstand then is equivalent to encryption with key first andthen . Example commutative encryption algorithms arethe Pohlig–Hellman Exponentiation Cipher [22] and SecureRPC Authentication (SRA) [23]. In our scheme, each domainchooses a private key. Let be the private keys chosenby and , respectively. To check whether numberfrom is equal to number from without dis-closing the value of each number to the other party,can first encrypt using key and sends to ;similarly, can first encrypt using key and sends

to . Then, each party checks whetherby checking whether . Note that

if and only if . If ,neither party can learn anything about the numbers beingcompared. Fig. 3 illustrates the process of checking whether 12from is in the range [11, 15] from .

B. Processing Firewall

To detect the redundant rules in , converts its fire-wall to a set of nonoverlapping rules. To preserve the pri-vacy of , first converts each range of a nonoverlap-ping discarding rules from to a set of prefixes. Second,

Fig. 3. Prefix membership verification.

and encrypt these prefixes using commutative en-cryption. The conversion of includes nine steps.1) first converts to an equivalent firewall decision

diagram (FDD) [10], [11]. An FDD for a firewall of a se-quence of rules over fields is an acyclicand directed graph that has five properties.a) There is exactly one node that has no incoming edges.This node is called the root. The nodes that have no out-going edge are called terminal nodes.

b) Each node has a label, denoted . If is a nonter-minal node, then . If is a terminalnode, then is a decision.

c) Each edge , , is labeled with a nonempty set of in-tegers, denoted , where is a subset of the domainof ’s label (i.e., ).

d) The set of all outgoing edges of a node , denoted ,satisfies two conditions.i) Consistency: for any two distinctedges and in .

ii) Completeness: .e) A directed path from the root to a terminal node is calleda decision path. No two nodes on a decision path havethe same label. Each path in the FDD corresponds to anonoverlapping rule. A full-length ordered FDD is anFDD where in each decision path all fields appear exactlyonce and in the same order. For ease of presentation, weuse the term “FDD” to denote “full-length ordered FDD.”An FDD construction algorithm, which converts a fire-wall policy to an equivalent FDD, is presented in [14].Fig. 4(b) shows the FDD constructed from Fig. 4(a).

2) reduces the FDD’s size by merging isomorphic sub-graphs. An FDD is reduced if and only if it satisfies two con-ditions: a) no two nodes in are isomorphic; b) no two nodeshave more than one edge between them. Two nodes and inan FDD are isomorphic if and only if and satisfy one of thefollowing two conditions: a) both and are terminal nodeswith identical labels; b) both and are nonterminal nodesand there is a one-to-one correspondence between the outgoingedges of and the outgoing edges of such that every two cor-responding edges have identical labels and they both point to


Fig. 4. Conversion of .

the same node. Fig. 4(c) shows the FDD reduced from the FDDin Fig. 4(b).3) extracts nonoverlapping discarding rules.

does not extract nonoverlapping accepting rules because thepackets accepted by are passed to . Note that anonoverlapping rule from that is covered by these dis-carding rules from is redundant. Fig. 4(d) shows thediscarding nonoverlapping rules extracted from the reducedFDD in Fig. 4(c).

4) converts each range to a set of prefixes. Fig. 4(e)shows the prefixes generated from Fig. 4(d).5) unions all these prefix sets and then permutes the

prefixes. Fig. 4(f) shows the resulting prefix list. Note that theresulting list does not include duplicate prefixes. The benefitsare twofold. In terms of efficiency, it avoids encrypting andsending duplicate prefixes for both parties and, hence, signifi-cantly reduces computation and communication costs. In termsof security, cannot reconstruct the nonoverlapping rulesfrom because does not know which prefix belongsto which field of which rule. However, knows such infor-mation, and it can reconstruct these nonoverlapping rules.6) numericalizes and encrypts each prefix using ,

and then sends to . Fig. 4(g) and (h) shows the numerical-ized and encrypted prefixes, respectively.7) further encrypts these prefixes with and sends

them back to as shown in Fig. 4(i).8) reconstructs its nonoverlapping discarding rules

from the double encrypted prefixes because knows whichprefix belongs to which field of which rule.9) For each reconstructed nonoverlapping rule, assigns

a distinct random index to it. These indices are used forto identify the redundant nonoverlapping rules from . Forexample, in Fig. 4(j), assigns its three rules with threerandom indices: 27, 13, and 45. The detailed discussion is inSection IV-D.

C. Processing Firewall

In order to compare two firewalls in a privacy-preservingmanner, and convert firewall to sets ofdouble encrypted numbers, where is the number of fields. Theconversion of includes five steps.1) converts to an equivalent all-match FDD. All-

match FDDs differ from FDDs on terminal nodes. In an all-match FDD, each terminal node is labeled with a nonempty setof rule sequence numbers, whereas in an FDD, each terminalnode is labeled with a decision. For rule , we callthe sequence number of . The set of rule sequence numberslabeled on a terminal node consists of the sequence numbers ofall the rules that overlaps with the decision path ending with thisterminal node. Given a decision path , ,the matching set of is defined as the set of all packets thatsatisfy . We useto denote the matching set of . More formally, in an all-matchFDD, for any decision path : , if

, then and . Fig. 4(b)shows the all-match FDD generated from Fig. 4(a). Consid-ering the terminal node of the fourth path in Fig. 4(b), its label{2, 4} means that , ,

, and . An all-match FDD notonly represents a firewall in a nonoverlapping fashion, but alsorepresents the overlapping relationship among rules. The reasonof converting to an all-match FDD is that later needsthe rule sequence numbers to identify interfirewall redundantrules in .2) extracts all nonoverlapping rules from the all-match

FDD. Fig. 5(c) shows the nonoverlapping rules extracted fromFig. 5(b). For each range of a nonoverlapping rule,


Fig. 5. Conversion of .

generates two prefix families and . Fig. 5(d) showsthe result from Fig. 5(c).3) For every field , unions all prefix families of all

the nonoverlapping rules into one prefix set and permutes theprefixes. Considering the first field in Fig. 5(d), unions

, , , , , and to obtain the firstprefix set in Fig. 5(e). The benefits of this step are similar tothose of Step (5) in ’s conversion. In terms of efficiency,

it avoids encrypting and sending the duplicate prefixes for eachfield and, hence, significantly reduces the computation and com-munication costs. In terms of security, cannot reconstructthe nonoverlapping rules of because does not knowwhich prefix belongs to which rule in . However,knows such information, which will be used to identify redun-dant nonoverlapping rules later. Note that the ordering of thefields cannot be permuted because needs to perform com-parison of the prefixes with only those prefixes from the corre-sponding fields.4) numericalizes and encrypts the prefixes using its pri-

vate and sends them to . Fig. 5(f) shows the prefixes.5) further encrypts these prefixes using key .

D. Single-Rule Coverage Redundancy Detection

After processing the two firewalls, has a sequence ofdouble encrypted nonoverlapping rules obtained from andsets of double encrypted numbers obtained from . Let

denote a doubleencrypted rule, where is a set of double encrypted numbers.Let denote the sets of double encrypted numbersfrom . Fig. 6(a) shows the double encrypted nonoverlap-ping rules generated from Fig. 4, and Fig. 6(b) shows the doubleencrypted numbers generated from Fig. 5. For each field

and for each number in , checks whetherthere exists a double encrypted rule

such that . If rule satisfies this condi-tion, then associates the rule index with . As there maybe multiple rules that satisfy this condition, eventually as-sociates a set of rule indices with . If no rule satisfies this con-dition, associates an empty set with . Considering thenumber , only the rule with index 13 contains itbecause ; thus, asso-ciates with {13}. Finally, replaces eachnumber in with its corresponding set of rule indicesand sends them to .Upon receiving the sets from , for each prefix family,finds the index of the rule that overlaps with the prefix

family. For a nonoverlapping rule from , if all its prefixfamilies overlap with the same discarding rule from ,is covered by and, hence, is redundant. For example,

in Fig. 6(d), is redundant because , , , andoverlap with rule 27 from . Similarly, is redun-

dant. Note that denotes that overlapswith nonoverlapping rules from .

E. Multirule Coverage Redundancy Detection

To detect multirule coverage redundancy, our basic ideais to combine all the nonoverlapping discarding rules from

to a set of new rules so that for any arbitrary rule from, if it is covered by multiple nonoverlapping discarding

rules from , it is covered by a rule from these new rules.More formally, let denote the nonoverlappingdiscarding rules from and denote the setof new rules generated from . For any rulefrom , if a nonoverlapping rule from is multirulecoverage redundant, i.e.,where from , there is a rule

that covers , i.e., . Thus, aftercomputes the set of new rules from , we reduce


Fig. 6. Comparison of two firewalls.

the problem of multirule coverage redundancy detection tosingle-rule coverage redundancy detection. Then, two parties

and can cooperatively run our protocol proposedin this section to identify the nonoverlapping single-rule andmultirule coverage redundant rules from at the sametime. However, the key question is how to compute the set ofnew rules .A straightforward method is to compute all possible rules that

are covered by a single or multiple nonoverlapping discardingrules among . All these rules form the set of newrules . However, this method incurs two major draw-backs. First, the time and space complexities of this method canbe significant because the number of all these rules could behuge. Second, due to the huge number of these rules, the com-munication and computation costs increase significantly. Therelationship between these costs and the number of rules is dis-cussed in Section IV-B.Our solution is to compute only the largest rules that are

covered by a single or multiple nonoverlapping discardingrules among . The term largest can be explainedas follows. Without considering the decision, a firewall rulewith fields can be denoted as a hyperrectangle over a-dimensional space. Then, nonoverlapping discarding rules

are hyperrectangles over a -dimensional space.The new rules are also the hyperrectangles. Theterm largest means that if a hyperrectangle contains thehyperrectangle but is larger than , has some parts thatare not covered by all the hyperrectangles . Forexample, the nonoverlapping discarding rules inFig. 4(d) can be illustrated as three filled rectangles in Fig. 7.Fig. 7 also shows three new rules generated from

, where , , and are illustrated as differentdashed rectangles. Note that is the same as , and isthe same as . Note that the values of two fields and

Fig. 7. Three largest rules generated from Fig. 4(d).

are integers. Thus, we can combine three ranges [0, 4], [5, 7],[8, 15] to a range [0, 15] for the field of .More formally, we can define a largest rule

as follows.1) .2) For any rule that ,

.Given the set of all largest rules generated from

, for any rule , if is covered by one ormultiple rules in , there exists a largest rule

that covers . We have the following theorem.Theorem 4.1: Given the set of all largest rules

generated from , for any rule , if, there exists a largest rule

that satisfies the condition .Proof: If is a largest rule, it is included in .

If is not a largest rule, we prove it by contradiction. Ifthere exists no largest rule among that covers , wecan generate all possible rules that satisfy two conditions: 1) the


matching set of each of these rules is the superset of ; 2)each of these rules is covered by . Among all thesegenerated rules, there exists at least a largest rule, otherwisethe number of these rules is infinite. However,

is a finite domain.Next, we discuss how to compute the set of all the largest

rules from the nonoverlapping discardingrules . Our idea is to first compute the largest rulesfor every two rules among . Repeat computing thelargest rules for every two rules in the previous step until theresulting rules do not change. Finally, the resulting rules arethe set of all the largest rules . Note that it is trivialto compute the largest rules from two rules. This algorithm isshown in Algorithm 1.

Algorithm 1: Computation of the set of largest rules

Input: nonoverlapping rules .Output: The set of all the largest rules

1 Initialize , ;2 while has been changed do3 for every two rules , in do4 compute the largest rules from and ;5 add the largest rules to ;6 for each rule in do7 if there is a rule in such that

then8 remove from ;9 ;10 ;11 return ;

For example, to identify the single-rule andmultiple-rule cov-erage redundancy simultaneously, only needs to performone more step between Fig. 4(d) and (e). computes allthe largest rules from the nonoverlapping discarding rules inFig. 4(d), which are

Finally, can identify thatis redundant because is covered the by the

rule .

F. Identification and Removal of Redundant Rulesw

After single-rule and multirule coverage redundancy detec-tion, identifies the redundant nonoverlapping rules in

. Next, needs to identify which original rules areinterfirewall redundant. As each path in the all-match FDDof corresponds to a nonoverlapping rule, we call thepaths that correspond to the redundant nonoverlapping rulesredundant paths and the remaining paths effective paths. Forexample, in Fig. 8, the dashed paths are the redundant pathsthat correspond to , , and in Fig. 5(c), respectively.Finally, identifies redundant rules based on Theorem 4.2.Theorem 4.2: Given firewall with no

intrafirewall redundancy and its all-match FDD, rule is

Fig. 8. Identification of redundant rules in .

interfirewall redundant with respect to if and only if twoconditions hold: 1) there is a redundant path whose terminalnode contains sequence number ; 2) there is no effective pathwhose terminal node contains as the smallest element.

Proof: Let denote all paths in ’s all-match FDD. According to the theorems in [15] and [17], theresolving set of each rule in firewall satis-fies the condition , where

are all the paths whose terminal nodes contain asthe smallest element. Based on the definition of interfirewall re-dundant rules in Section III-A, rule is interfirewall redundantif and only if all the packets in are discarded by

. Thus, each path is a redundant path.In other words, all the paths whose terminal nodescontain as the smallest element are redundant paths.Considering redundant paths in Fig. 8, identifies that

and are interfirewall redundant with respect to .Theorem 4.3: The privacy-preserving interfirewall redun-

dancy removal protocol is a complete interfirewall redundancyremoval scheme.

Proof: Suppose that our proposed protocol is not a com-plete scheme, and hence it cannot detect all interfirewall re-dundant rules in . Assume that rule is interfirewall re-dundant in , but it is not detected by our protocol. Ac-cording to Theorem 4.2,and are redundant paths in ’s all-match FDD.Thus, some paths in cannot be identified as re-dundant paths by our protocol. This conclusion violates the factthat our protocol can identify all the redundant paths in ’sall-match FDD.

V. FIREWALL UPDATE AFTER OPTIMIZATION

If or changes after interfirewall optimization, theinterfirewall redundant rules identified by the optimization maynot be interfirewall redundant anymore. In this section, we dis-cuss our solution to address firewall update. There are five pos-sible cases under this scenario.1) changes the decisions of some rules in . In thiscase, neither party needs to take actions because the inter-firewall redundancy detection does not consider the deci-sions of the rules in .

2) changes the decisions of some rules from discard toaccept in . In this case, needs to notifywhich nonoverlapping rules (indices of these rules) from

are changed. Using this information, checksif there were any rules in that were removed due tothese rules, and then adds the affected rules back into .

3) changes the decisions of some rules from accept todiscard in . In this case, can run our cooperative


optimization protocol again to possibly identify more inter-firewall redundant rules in .

4) adds or removes some rules in . In this case,since the resolving sets of some rules in maychange, a rule in that used to be interfirewall redun-dant maybe not redundant anymore. It is important for

to run our optimization protocol again.5) adds or removes some rules in . Similar to thefourth case, since the resolving sets of some rules inmay change, it is important for to run our protocolagain.

VI. SECURITY AND COMPLEXITY ANALYSIS

A. Security Analysis

To analyze the security of our protocol, we first describe thecommutative encryption and its properties. Let denote a setof private keys and denote a finite domain. A commutativeencryption is a computable functionthat satisfies the following four properties.1) Secrecy: For any and key , given , it is computa-tionally infeasible to compute .

2) Commutativity: For any , , and , we have.

3) For any , , and , if , we have .4) The distribution of is indistinguishable from the dis-tribution of .

Note that, for ease of presentation, in the rest of this section, any, , or is an element of ; any , , or is an elementof ; and denotes .In the conversion of , for each nonoverlapping rule

from , let denote the prefix set for the field ,e.g. in Fig. 4(e), denotes {00 , 0100}. In the con-version of , let denote the prefix set for the fieldafter removing duplicate prefixes, e.g. in Fig. 5(e), denotesthe first prefix set. Our cooperative optimization protocol es-sentially compares and in a privacy-preservingmanner. We have the following theorem.Theorem 6.1: If both parties and are semi-honest,

after comparing two sets and using our protocol,learns only the size and the intersection

, and learns only the size and the intersec-tion .

Proof: According to the theorems in multiparty securecomputation [2], [8], if we can prove that the distribution ofthe ’s view of our protocol cannot be distinguished from asimulation that uses only , , and ,then cannot learn anything else exceptand . Note that ’s view of our protocol is the infor-mation that gains from .Without loss of generality, we only prove that learns

only the size and the intersection . Thesimulator for uses key to create a set fromand as follows:

where are random values generated by the sim-ulator and they are uniformly distributed in the finite domain

. According to the theorems in [2], cannot distin-guish the distribution of ’s elements from that in

The ’s view of our protocol corresponds to . Therefore,the distribution of the ’s view of our protocol cannot bedistinguished from this simulation.Next, we analyze the information learned by and .

After implementing our protocol, knows the convertedfirewalls of and , e.g. Figs. 4(j) and 5(g), andknows the comparison result, e.g. Fig. 6(d). On side, foreach field , it knows only and

, and it cannot reveal the rules of for two reasons. First,in , a numericalized prefix can be generated frommany different numbers. For example, a prefix of IP addresses(32 bits) can be generated from dif-ferent IP addresses. Second, even if finds the number fora prefix in , does not know which rule in

contains that number. On side, it only knows thatthe prefix in belongs to which nonoverlapping rules in

. However, such information is not enough to reveal therules in .

B. Complexity Analysis

Let and be the number of rules in two adjacent firewallsand , respectively, and be the number of fields

in both firewalls. For simplicity, we assume that the numbersin different fields have the same length, say bits. We firstanalyze the computation, space, and communication costs forthe conversion of . Based on the theorem in [14], the max-imum number of nonoverlapping rules generated from the FDDis . Each nonoverlapping rule consists of -bitintervals, and each interval can be converted to at mostprefixes. Thus, the maximum number of prefixes generatedfrom these nonoverlapping rules is . Notethat the total number of prefixes cannot exceed because

puts all prefixes into one set. Thus, the computation costof encryption by is .Therefore, for the conversion of , the computation cost of

is , the space cost of is, the communication cost is ,

and the computation cost of is .Similarly, for the conversion of , the computationcost of is , the spacecost of is , the communication cost is

, and the computation cost of is.

The computation and communication costs of firewall updatedepend on the different cases in Section V. There is no cost forCase 1 in Section V. Case 2 only incurs the computation andcommunication costs of firewall comparison. For Cases 3–5, thecomputation and communication costs of firewall update are theoverall costs of our protocol because we need to rerun our pro-tocol for these three cases. Note that if a firewall is updated fre-quently, our protocol may not be applicable for this scenario due


to significant computation and communication costs of runningour protocol many times.

VII. EXPERIMENTAL RESULTS

We evaluate the effectiveness of our protocol on real firewallsand evaluate the efficiency of our protocol on both real and syn-thetic firewalls. We implemented our protocol using Java 1.6.0.Our experiments were carried out on a PC running Linux withtwo Intel Xeon cores and 16 GB of memory.

A. Evaluation Setup

We conducted experiments over five groups of two realadjacent firewalls. Each firewall examines five fields, sourceIP, destination IP, source port, destination port, and pro-tocol. The number of rules ranges from dozens to thousands.In implementing the commutative encryption, we used thePohlig–Hellman algorithm [22] with a 1024-bit prime modulusand 160-bit encryption keys. To evaluate the effectiveness, weconducted our experiments over these five groups of adjacentfirewalls. To evaluate the efficiency, for two firewalls in eachgroup, we measured the processing time, the comparison time,and the communication cost of both parties.Due to security concerns, it is difficult to obtain a large

number of real adjacent firewalls. To further evaluate theefficiency, we generated a large number of synthetic firewallsbased on Singh et al.’s method [24]. The synthetic firewallsalso examine the same five fields as real firewalls. The numberof rules in the synthetic firewalls ranges from 200 to 2000,and for each number, we generated 10 synthetic firewalls.To measure the efficiency, we first processed each syntheticfirewall as and then measured the processing time andcommunication cost of two parties. Second, we processed eachsynthetic firewall as and measured the processing timeand communication cost. Third, we measured the comparisontime for every two synthetic firewalls. We did not evaluate theeffectiveness of our protocol on synthetic firewalls because theyare generated randomly and independently without consideringwhether two firewalls are adjacent or not.

B. Methodology

In this section, we define the metrics to measure the ef-fectiveness of our protocol. Given our firewall optimizationalgorithm , and two adjacent firewalls and , weuse to denote a set of interfirewall redundantrules in . Let denote the number of rules in and

denote the number of interfirewall redundantrules in . To evaluate the effectiveness, we define a redun-dancy ratio .This ratio measures what percentage ofrules are interfirewall redundant in .

C. Effectiveness and Efficiency on Real Policies

Table I shows the redundancy ratios for five real firewallgroups. Column 1 shows the names of five real firewall groups.Columns 2 and 3 show the names of firewalls and

, respectively. Column 4 shows the number of rules infirewall . Fig. 9 shows the processing time and commu-nication cost of two parties and when processing

; Fig. 10 shows the processing time and communicationcost of the two parties when processing . Fig. 11 shows

Fig. 9. Processing on real firewalls. (a) Processing time. (b) Communi-cation cost.

Fig. 10. Processing on real firewalls. (a) Processing time. (b) Commu-nication cost.

Fig. 11. Comparing two real firewalls.

TABLE IREDUNDANCY RATIOS FOR FIVE REAL FIREWALL GROUPS

the comparison time of each group. Fig. 12 shows the overallprocessing time and communication cost of implementing ourprotocol on real firewalls. Note that the processing time inFig. 12 does not include the communication time between twoparties.Our protocol achieves significant redundancy ratio on four

real firewall groups. For five real firewall groups, our protocolachieves an average redundancy ratio of 19.4%. Particularly,for the firewall group Host, our protocol achieves 49.6% redun-dancy ratio, which implies that almost half of rules in Host2 areinterfirewall redundant rules. For firewall groups Econ, Ath, andComp, our protocol achieves 14.4%–17.1% redundancy ratios,which implies that about 15% of rules in are redundantin these three groups. Only for one firewall group, Wan, our


Fig. 12. Total processing time and communication cost on real firewalls.(a) Processing time. (b) Communication cost.

Fig. 13. Processing on synthetic firewalls. (a) Average processing time.(b) Average communication cost.

protocol achieves 1.0% redundancy ratio. From these results,we observed that most adjacent real firewalls have many inter-firewall redundant rules. Thus, our protocol could effectivelyremove interfirewall redundant rules and significantly improvethe network performance.Our protocol is efficient for processing and comparing two

real firewalls. When processing in the five real firewallgroups, the processing time of is less than 2 s and the pro-cessing time of is less than 1 s. When processing inthose real firewall groups, the processing time of is lessthan 4 s and the processing time of is less than 10 s. Thecomparison time of two firewalls is less than 0.07 s. The totalprocessing time of two parties is less than 14 s, which demon-strates the efficiency of our protocol.Our protocol is efficient for the communication cost between

two parties. When processing firewall in the five real fire-wall groups, the communication cost from to andthat from to are less than 60 kB. Note that the com-munication cost from to and that from toare the same because and encrypt the same numberof values and the encrypted values have the same length, i.e.1024 bits in our experiments. When processing in thosereal firewall groups, the communication cost from tois less than 300 kB. The total communication cost between twoparties is less than 350 kB, which can be sent through the cur-rent network (e.g. DSL network) around 10 s.

D. Efficiency on Synthetic Policies

For the synthetic firewalls, Figs. 13 and 14 show the av-erage processing time and communication cost of two parties

and for processing and , respectively.Fig. 15 shows the average comparison time for every two syn-thetic firewalls. Fig. 16 shows the overall processing time andcommunication cost of implementing our protocol on syntheticfirewalls. The processing time in Fig. 16 does not include the

Fig. 14. Processing on synthetic firewalls. (a) Average processing time.(b) Average communication cost.

Fig. 15. Comparing two synthetic firewalls.

Fig. 16. Total processing time and communication cost on Synthetic firewalls.(a) Processing time. (b) Communication cost.

communication time between two parties. Note that the verticalaxes of Figs. 13(a), 14(a), and 16(a) are in a logarithmic scale.Our protocol is efficient for processing and comparing two

synthetic firewalls. When processing the synthetic firewalls as, the processing time of is less than 300 s and the

processing time of is less than 5 s. When processing thesynthetic firewalls as , the processing time of is lessthan 400 s and the processing time of is less than 20 s. Thecomparison time of two synthetic firewalls is less than 4 s.Our protocol is efficient for the communication cost between

two synthetic firewalls. When processing the synthetic firewallsas , the communication cost from to and thatfrom to grow linearly with the number of rules in

, and both costs are less than 420 kB. Similarly, whenprocessing synthetic firewalls as , the communication costfrom to grows linearly with the number of rules in

, and the communication cost from to is lessthan 1600 kB.

VIII. CONCLUSION AND FUTURE WORK

In this paper, we identified an important problem, cross-do-main privacy-preserving interfirewall redundancy detection.We


propose a novel privacy-preserving protocol for detecting suchredundancy. We implemented our protocol in Java and con-ducted extensive evaluation. The results on real firewall policiesshow that our protocol can remove as many as 49% of the rulesin a firewall whereas the average is 19.4%.Our protocol is applicable for identifying the interfirewall

redundancy of firewalls with a few thousands of rules, e.g.2000 rules. However, it is still expensive to compare two fire-walls with many thousands of rules, e.g. 5000 rules. Reducingthe complexity of our protocol needs to be further studied.In our work, we have demonstrated rule optimization, from

to , and we note that a similar rule optimization ispossible in the opposite direction, i.e., to . In thefirst scenario, to , it is that is improving theperformance load of , and in return is improving theperformance of in a vice-versa manner. All this is beingachieved the without or revealing each other’spolicies thus allowing for a proper administrative separation.Our protocol is most beneficial if both parties are willing tobenefit from it and can collaborate in a mutual manner. Thereare many special cases that could be explored based on ourcurrent protocol. For example, there may be hosts or NetworkAddress Translation (NAT) devices between two adjacentfirewalls. Our current protocol cannot be directly applied tosuch cases. Extending our protocol to these cases could be aninteresting topic and requires further investigation.

REFERENCES

[1] nf-HiPAC, “Firewall throughput test,” 2012 [Online]. Available: http://www.hipac.org/performance_tests/results.html

[2] R. Agrawal, A. Evfimievski, and R. Srikant, “Information sharingacross private databases,” in Proc. ACM SIGMOD, 2003, pp. 86–97.

[3] E. Al-Shaer and H. Hamed, “Discovery of policy anomalies in dis-tributed firewalls,” in Proc. IEEE INFOCOM, 2004, pp. 2605–2616.

[4] J. Brickell and V. Shmatikov, “Privacy-preserving graph algorithms inthe semi-honest model,” in Proc. ASIACRYPT, 2010, pp. 236–252.

[5] Y.-K. Chang, “Fast binary and multiway prefix searches for packet for-warding,” Comput. Netw., vol. 51, no. 3, pp. 588–605, 2007.

[6] J. Cheng, H. Yang, S. H.Wong, and S. Lu, “Design and implementationof cross-domain cooperative firewall,” in Proc. IEEE ICNP, 2007, pp.284–293.

[7] Q. Dong, S. Banerjee, J. Wang, D. Agrawal, and A. Shukla, “Packetclassifiers in ternary CAMs can be smaller,” in Proc. ACM SIGMET-RICS, 2006, pp. 311–322.

[8] O. Goldreich, “Secure multi-party computations,” Working draft, Ver.1.4, 2002.

[9] O. Goldreich, Foundations of Cryptography: Volume II (Basic Appli-cations). Cambridge, U.K.: Cambridge Univ. Press, 2004.

[10] M. G. Gouda and A. X. Liu, “Firewall design: Consistency, complete-ness and compactness,” in Proc. IEEE ICDCS, 2004, pp. 320–327.

[11] M. G. Gouda and A. X. Liu, “Structured firewall design,” Comput.Netw., vol. 51, no. 4, pp. 1106–1120, 2007.

[12] P. Gupta, “Algorithms for routing lookups and packet classification,”Ph.D. dissertation, Stanford Univ., Stanford, CA, 2000.

[13] A. X. Liu and F. Chen, “Collaborative enforcement of firewall policiesin virtual private networks,” in Proc. ACM PODC, 2008, pp. 95–104.

[14] A. X. Liu and M. G. Gouda, “Diverse firewall design,” IEEE Trans.Parallel Distrib. Syst., vol. 19, no. 8, pp. 1237–1251, Sep. 2008.

[15] A. X. Liu andM. G. Gouda, “Complete redundancy removal for packetclassifiers in TCAMs,” IEEE Trans. Parallel Distrib. Syst., vol. 21, no.4, pp. 424–437, Apr. 2010.

[16] A. X. Liu, C. R. Meiners, and E. Torng, “TCAM Razor: A system-atic approach towards minimizing packet classifiers in TCAMs,”IEEE/ACM Trans. Netw., vol. 18, no. 2, pp. 490–500, Apr. 2010.

[17] A. X. Liu, C. R. Meiners, and Y. Zhou, “All-match based completeredundancy removal for packet classifiers in TCAMs,” in Proc. IEEEINFOCOM, 2008, pp. 574–582.

[18] A. X. Liu, E. Torng, and C. Meiners, “Firewall compressor: An al-gorithm for minimizing firewall policies,” in Proc. IEEE INFOCOM,2008.

[19] C. R. Meiners, A. X. Liu, and E. Torng, “TCAM Razor: A systematicapproach towards minimizing packet classifiers in TCAMs,” in Proc.IEEE ICNP, 2007, pp. 266–275.

[20] C. R. Meiners, A. X. Liu, and E. Torng, “Bit weaving: A non-prefixapproach to compressing packet classifiers in TCAMs,” in Proc. IEEEICNP, 2009, pp. 93–102.

[21] C. R. Meiners, A. X. Liu, and E. Torng, “Topological transformationapproaches to optimizing TCAM-based packet processing systems,” inProc. ACM SIGMETRICS, 2009, pp. 73–84.

[22] S. C. Pohlig and M. E. Hellman, “An improved algorithm for com-puting logarithms over GF(p) and its cryptographic significance,” IEEETrans. Inf. Theory, vol. IT-24, no. 1, pp. 106–110, Jan. 1978.

[23] D. K. H. D. R. Safford and D. L. Schales, “Secure RPC authentication(SRA) for TELNET and FTP,” Tech. Rep., 1993.

[24] S. Singh, F. Baboescu, G. Varghese, and J.Wang, “Packet classificationusing multidimensional cutting,” in Proc. ACM SIGCOMM, 2003, pp.213–224.

[25] A. Wool, “A quantitative study of firewall configuration errors,” Com-puter, vol. 37, no. 6, pp. 62–67, Jun. 2004.

[26] Z. Yang, S. Zhong, and R. N.Wright, “Privacy-preserving classificationof customer data without loss of accuracy,” in Proc. SIAM SDM, 2005,pp. 21–23.

[27] W. Lee and D. Xiang, “Information-theoretic measures for anomalydetection,” in Proc. IEEE S&P, 2001, pp. 130–143.

[28] R. Sekar, A. Gupta, J. Frullo, T. Shanbhag, A. Tiwari, H. Yang, andS. Zhou, “Specification-based anomaly detection: A new approach fordetecting network intrusions,” in Proc. ACM CCS, 2002, pp. 265–274.

[29] C. Kruegel, T. Toth, and E. Kirda, “Service specific anomaly detec-tion for network intrusion detection,” in Proc. ACM SAC, 2002, pp.201–208.

[30] L. Yuan, H. Chen, J. Mai, C.-N. Chuah, Z. Su, and P. Mohapatra,“Fireman: A toolkit for firewall modeling and analysis,” in Proc. IEEES&P, 2006, pp. 199–213.

Fei Chen received the B.S. and M.S. degrees inautomation from Tsinghua University, Beijing,China, and the Ph.D. degree in computer sciencefrom Michigan State University, East Lansing, in2011.He is currently a Performance Engineer with

VMware, Inc., Palo Alto, CA.

Bezawada Bruhadeshwar received the B.E. degreefrom Osmania University, Hyderabad, India, in1998, and the M.S. degree in electrical and computerengineering and Ph.D. in computer science andengineering from Michigan State University, EastLansing, in 2000 and 2005, respectively.He is currently working as an Assistant Professor

with the International Institute of Information Tech-nology, Hyderabad (IIIT-H), India. His research in-terests are in security, networking, and dependablesystems.

Alex X. Liu received the Ph.D. degree in computerscience from the University of Texas at Austin in2006.His research interests focus on networking, secu-

rity, and dependable systems.Dr. Liu received the IEEE & IFIP William C.

Carter Award in 2004, an NSF CAREER Award in2009, and the Withrow Distinguished Scholar Awardin 2011 at Michigan State University.

cross-domain privacy-preserving cooperative firewall optimization

Engineering

privacy of rewall policies

real rewall policies

rewall optimiza tion

interrewall optimization

crossdomain privacy

optimization process

department of computer

cooperative computation