Cross-Domain Privacy-Preserving Cooperative Firewall Optimization

IEEE/ACM TRANSACTIONS ON NETWORKING, VOL. 21, NO. 3, JUNE 2013 857
Cross-Domain Privacy-Preserving Cooperative
Firewall Optimization
Fei Chen, Bezawada Bruhadeshwar, and Alex X. Liu
Abstract—Firewalls have been widely deployed on the Internet
for securing private networks. A firewall checks each incoming or
outgoing packet to decide whether to accept or discard the packet
based 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 optimization
within one administrative domain where the privacy of firewall
policies is not a concern. This paper explores interfirewall opti-
mization across administrative domains for the first time. The key
technical challenge is that firewall policies cannot be shared across
domains because a firewall policy contains confidential informa-
tion and even potential security holes, which can be exploited by
attackers. 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 each
firewall the rules that can be removed because of the other fire-
wall. The optimization process involves cooperative computation
between the two firewalls without any party disclosing its policy to
the other. We implemented our protocol and conducted extensive
experiments. The results on real firewall policies show that our pro-
tocol can remove as many as 49% of the rules in a firewall, whereas
the average is 19.4%. The communication cost is less than a few
hundred kilobytes. Our protocol incurs no extra online packet pro-
cessing overhead, and the offline processing time is less than a few
hundred seconds.
Index Terms—Firewall optimization, privacy.
I. INTRODUCTION
A. Background and Motivation
F IREWALLS are critical in securing private networks of
businesses, institutions, and home networks. A firewall is
often placed at the entrance between a private network and the
external network so that it can check each incoming or outgoing
Manuscript received May 27, 2011; revised December 23, 2011 and June
21, 2012; accepted July 30, 2012; approved by IEEE/ACM TRANSACTIONS ON
NETWORKING Editor I. Keslassy. Date of publication October 09, 2012; date
of 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. The
preliminary version of this paper titled “A Cross-Domain Privacy-Preserving
Protocol 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 with
VMware, Inc., Palo Alto, CA 94304 USA (e-mail: feichen@cse.msu.edu).
A. X. Liu is with the Department of Computer Science and Technology, Nan-
jing University, Nanjing 210093, China (e-mail: alexliu@cse.msu.edu).
B. Bruhadeshwar is with the Center for Security, Theory, and Algorithmic Re-
search, International Institute of Information Technology, Hyderabad 500032,
India (e-mail: bezawada@iiit.ac.in).
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 B
in [1].
packet and decide whether to accept or discard the packet based
on its policy. A firewall policy is usually specified as a sequence
of rules, called Access Control List (ACL), and each rule has a
predicate over multiple packet header fields (i.e., source IP, des-
tination IP, source port, destination port, and protocol type) and
a decision (i.e., accept and discard) for the packets that match
the predicate. The rules in a firewall policy typically follow the
first-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 with
two ACLs: one for filtering outgoing packets and the other one
for 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 test
of iptables conducted by HiPAC [1]. It shows that increasing
the number of rules in a firewall policy dramatically reduces
the firewall throughput. Unfortunately, with the explosive
growth of services deployed on the Internet, firewall policies
are growing rapidly in size. Thus, optimizing firewall policies
is crucial for improving network performance.
B. Limitation of Prior Work
Prior work on firewall optimization focuses on either
intrafirewall optimization [7], [15]–[21] or interfirewall op-
timization [3], [30] within one administrative domain where
the privacy of firewall policies is not a concern. Intrafirewall
optimization means optimizing a single firewall. It is achieved
by either removing redundant rules [15], [17] or rewriting
rules [7], [16], [18]–[21]. Prior work on interfirewall opti-
mization requires two firewall policies without any privacy
protection, and thus can only be used within one administrative
domain. However, in reality, it is common that two firewalls
belong to different administrative domains where firewall
policies cannot be shared with each other. Keeping firewall
policies 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 by
attackers. Quantitative studies have shown that most firewalls
are misconfigured and have security holes [25]. Second, a
firewall policy often contains private information, e.g., the IP
addresses of servers, which can be used by attackers to launch
more 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 paper
represents the first step in exploring this unknown space.
Specifically, we focus on removing interfirewall policy redun-
dancies in a privacy-preserving manner. Consider two adjacent
firewalls 1 and 2 belonging to different administrative domains
and . Let denote the policy on firewall 1’s
outgoing interface to firewall 2 and denote the policy on
firewall 2’s incoming interface from firewall 1. For a rule in
, if all the packets that match but do not match any rule
above in are discarded by , rule can be removed
because such packets never come to . We call rule an
interfirewall 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’s
incoming interface is guarded by other two separate policies.
For simplicity, we assume that and have no in-
trafirewall redundancy as such redundancy can be removed
using 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 as
and , respectively. The rules of the two firewall policies
and , that are used to filter the traffic flowing from CSE to
EE, are listed in two tables following the format used in Cisco
Access Control Lists. Note that SIP, DIP, SP, DP, PR, and Dec
denote source IP, destination IP, source port, destination port,
protocol type, and decision, respectively. Clearly, all the packets
that 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 two
adjacent firewalls to identify the interfirewall redundancy
with respect to each other without knowing the policy of
the other firewall. While intrafirewall redundancy removal is
complex [15], [17], interfirewall redundancy removal with the
privacy-preserving requirement is even harder. To determine
whether 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 whether
all possible packets that match rule in match a rule
with the discard decision in . If rule exists, is interfire-
wall redundant with respect to in . However, because
firewalls follow the first-match semantics and the rules in a fire-
wall typically overlap, this solution is not only incorrect but also
incomplete. Incorrect means that wrong redundant rules could
be identified in . Suppose this solution identifies as a re-
dundant rule in with respect to in . However, if
some 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 . In
this case, is actually not redundant. Incomplete means that a
portion of redundant rules could be identified in . If all
possible packets that match rule in are discarded by not
only one rule but multiple rules in , is also redundant.
However, the direct comparison solution cannot identify such
redundancies.
Our basic idea is as follows. For each rule in , we
first compute a set of compact predicates representing the set of
packets that match but do not match the rules above in .
Then, for each predicate, we check whether all the packets that
match the predicate are discarded by . If this condition
holds for all the predicates computed from rule , then rule is
redundant. To efficiently compute these predicates, we convert
firewalls to firewall decision diagrams [17]. To allow the two
firewalls to detect the redundant rules in in a privacy-
preserving manner, we develop a protocol so that two firewalls
can detect such redundant rules without disclosing their policies
to each other.
Our protocol applies to both stateful and stateless firewalls.
The main difference between stateful and stateless firewalls
is that stateful firewalls maintain a connection table. Upon
receiving 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 novel
privacy-preserving protocol for detecting interfirewall redun-
dant rules in one firewall with respect to another firewall. This
paper represents the first effort along this unexplored direction.
Second, we implemented our protocol and conducted extensive
experiments on both real and synthetic firewall policies. The re-
sults on real firewall policies show that our protocol can remove
as many as 49% of the rules in a firewall whereas the average
is 19.4%. The communication cost is less than a few hundred
kilobytes. Our protocol incurs no extra online packet processing
overhead, 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 and
threat model in Section III. In Section IV, we present our pri-
vacy-preserving protocol for detecting interfirewall redundant
rules. 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 in
Section 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 rules
identified by Gupta are incomplete and proposed two methods
for detecting all redundant rules [15], [17]. Prior work on in-
terfirewall redundancy removal requires the knowledge of two
firewall policies and therefore is only applicable within one ad-
ministrative domain [3], [30].
B. Collaborative Firewall Enforcement in Virtual Private
Networks (VPNs)
Prior work on collaborative firewall enforcement in VPNs
enforces firewall policies over encrypted VPN tunnels without
leaking the privacy of the remote network’s policy [6], [13]. The
problems of collaborative firewall enforcement in VPNs and
privacy-preserving interfirewall optimization are fundamentally
different. First, their purposes are different. The former focuses
on 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 to
each other. Second, their requirements are different. The former
preserves the privacy of the remote network’s policy, whereas
the 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 a
predicate over fields and a decision for the packets
that 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, and
8 bits, respectively. A predicate defines a set of packets over
the fields and is specified as ,
where each is a subset of ’s domain . A packet over
the fields is a -tuple where each
is an element of . A packet
matches a rule if and
only if the condition holds. Typical
firewall decisions include accept, discard, accept with logging,
and discard with logging. Without loss of generality, we only
consider accept and discard in this paper. We call a rule with
the accept decision an accepting rule and a rule with the dis-
card decision a discarding rule. In a firewall policy, a packet
may match multiple rules whose decisions are different. To re-
solve these conflicts, firewalls typically employ a first-match
semantics where the decision for a packet is the decision of
the first rule that matches. A matching set of , , is
the set of all possible packets that match the rule [15]. A re-
solving set of , , is the set of packets that match but
do not match any rule above , and is equal
to [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 the
packets 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 firewall
follows our protocol correctly, but each firewall may try to re-
veal the policy of the other firewall. The semi-honest model is
realistic and well adopted [4], [26]. For example, this model is
appropriate for large organizations that have many independent
branches as well as for loosely connected alliances composed
by multiple parties. While we are confident that all administra-
tive domains follow mandate protocols, we may not guarantee
that no corrupted employees are trying to reveal the private fire-
wall policies of other parties. Also, it may be possible for one
party to issue a sequence of inputs to try and reveal the other
party’s policy. For this attack to be successful, several assump-
tions have to be satisfied, one of them being that one firewall’s
policy remain constant. Another requirement is that the number
of times the protocol needs to be executed to reveal a significant
amount of rules is computationally expensive.1 Such malicious
activitiy may be identified by the other party using anomaly de-
tection approaches [27]–[29]. However, in our threat model, the
inputs to the protocol are honest, and crafting inputs to reveal the
firewall policies is beyond our threat model. We leave investi-
gation of privacy-preserving firewall optimization in the model
with malicious participants to future work.
IV. PRIVACY-PRESERVING INTERFIREWALL REDUNDANCY
REMOVAL
In this section, we present our privacy-preserving protocol for
detecting interfirewall redundant rules in with respect to
. To do this, we first convert each firewall to an equivalent
sequence of nonoverlapping rules. Because for any nonoverlap-
ping rule , the matching set of is equal to the resolving set
of , i.e., , we only need to compare nonover-
lapping rules generated from the two firewalls for detecting
interfirewall redundancy. Second, we divide this problem into
two subproblems, single-rule coverage redundancy detection
and multirule coverage redundancy detection, and then propose
our privacy-preserving protocol for solving each subproblem. A
rule is covered by one or multiple rules
if and only if . The first
subproblem checks whether a nonoverlapping rule in
is covered by a nonoverlapping discarding rule in , i.e.,
. The second subproblem checks whether a
nonoverlapping rule in is covered by multiple nonover-
lapping discarding rules in , i.e.,
. Finally, after redundant
nonoverlapping rules generated from are identified, we
map them back to original rules in and then identify the
redundant ones.
The problem of checking whether boils
down to the problem of checking whether one range in
is 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, the
complexity is updates for a single rule whereby such high communication
activity can be detected by anomaly detection approaches.

and . Thus, we first describe the privacy-preserving
protocol for comparing a number and a range.
A. Privacy-Preserving Range Comparison
To check whether a number from is in a range
from , we use a method similar to the prefix membership
verification scheme in [13]. The basic idea is to convert the
problem of checking whether to the problem of
checking whether two sets converted from and have
a 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 prefixes
that contain including itself. This set of prefixes is called
the prefix family of , denoted as . Let be the bit length
of . The prefix family consists of prefixes where
the th prefix is obtained by replacing the last bits of by
. For example, as the binary representation of 12 is 1100, we
have . It is not difficult
to 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 can
encrypt them in the next step. We use the prefix numericaliza-
tion scheme in [5]. Given a prefix of bits, we
first 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 to
11001.
4) Comparison: It checks whether by checking
whether , which boils down to checking
whether 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 , a
commutative encryption is a function that satisfies the property
, i.e., encryption with key first
and then is equivalent to encryption with key first and
then . Example commutative encryption algorithms are
the Pohlig–Hellman Exponentiation Cipher [22] and Secure
RPC Authentication (SRA) [23]. In our scheme, each domain
chooses a private key. Let be the private keys chosen
by and , respectively. To check whether number
from 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 whether
by checking whether . Note that
if and only if . If ,
neither party can learn anything about the numbers being
compared. Fig. 3 illustrates the process of checking whether 12
from 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 acyclic
and 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 terminal
node, then is a decision.
c) Each edge , , is labeled with a nonempty set of in-
tegers, denoted , where is a subset of the domain
of ’s label (i.e., ).
d) The set of all outgoing edges of a node , denoted ,
satisfies two conditions.
i) Consistency: for any two distinct
edges and in .
ii) Completeness: .
e) A directed path from the root to a terminal node is called
a decision path. No two nodes on a decision path have
the same label. Each path in the FDD corresponds to a
nonoverlapping rule. A full-length ordered FDD is an
FDD where in each decision path all fields appear exactly
once and in the same order. For ease of presentation, we
use 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 nodes
have more than one edge between them. Two nodes and in
an FDD are isomorphic if and only if and satisfy one of the
following two conditions: a) both and are terminal nodes
with identical labels; b) both and are nonterminal nodes
and there is a one-to-one correspondence between the outgoing
edges 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 FDD
in Fig. 4(b).
3) extracts nonoverlapping discarding rules.
does not extract nonoverlapping accepting rules because the
packets accepted by are passed to . Note that a
nonoverlapping rule from that is covered by these dis-
carding rules from is redundant. Fig. 4(d) shows the
discarding nonoverlapping rules extracted from the reduced
FDD 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 the
resulting list does not include duplicate prefixes. The benefits
are twofold. In terms of efficiency, it avoids encrypting and
sending duplicate prefixes for both parties and, hence, signifi-
cantly reduces computation and communication costs. In terms
of security, cannot reconstruct the nonoverlapping rules
from because does not know which prefix belongs
to 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 which
prefix belongs to which field of which rule.
9) For each reconstructed nonoverlapping rule, assigns
a distinct random index to it. These indices are used for
to identify the redundant nonoverlapping rules from . For
example, in Fig. 4(j), assigns its three rules with three
random indices: 27, 13, and 45. The detailed discussion is in
Section IV-D.
C. Processing Firewall
In order to compare two firewalls in a privacy-preserving
manner, and convert firewall to sets of
double encrypted numbers, where is the number of fields. The
conversion 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 set
of rule sequence numbers, whereas in an FDD, each terminal
node is labeled with a decision. For rule , we call
the sequence number of . The set of rule sequence numbers
labeled on a terminal node consists of the sequence numbers of
all the rules that overlaps with the decision path ending with this
terminal node. Given a decision path , ,
the matching set of is defined as the set of all packets that
satisfy . We use
to denote the matching set of . More formally, in an all-match
FDD, 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 not
only represents a firewall in a nonoverlapping fashion, but also
represents the overlapping relationship among rules. The reason
of converting to an all-match FDD is that later needs
the rule sequence numbers to identify interfirewall redundant
rules in .
2) extracts all nonoverlapping rules from the all-match
FDD. Fig. 5(c) shows the nonoverlapping rules extracted from
Fig. 5(b). For each range of a nonoverlapping rule,

Fig. 5. Conversion of .
generates two prefix families and . Fig. 5(d) shows
the result from Fig. 5(c).
3) For every field , unions all prefix families of all
the nonoverlapping rules into one prefix set and permutes the
prefixes. Considering the first field in Fig. 5(d), unions
, , , , , and to obtain the first
prefix set in Fig. 5(e). The benefits of this step are similar to
those of Step (5) in ’s conversion. In terms of efficiency,
it avoids encrypting and sending the duplicate prefixes for each
field and, hence, significantly reduces the computation and com-
munication costs. In terms of security, cannot reconstruct
the nonoverlapping rules of because does not know
which 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 the
fields 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 of
double encrypted nonoverlapping rules obtained from and
sets of double encrypted numbers obtained from . Let
denote a double
encrypted rule, where is a set of double encrypted numbers.
Let denote the sets of double encrypted numbers
from . Fig. 6(a) shows the double encrypted nonoverlap-
ping rules generated from Fig. 4, and Fig. 6(b) shows the double
encrypted numbers generated from Fig. 5. For each field
and for each number in , checks whether
there exists a double encrypted rule
such that . If rule satisfies this condi-
tion, then associates the rule index with . As there may
be 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 the
number , only the rule with index 13 contains it
because ; thus, asso-
ciates with {13}. Finally, replaces each
number in with its corresponding set of rule indices
and 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 prefix
families overlap with the same discarding rule from ,
is covered by and, hence, is redundant. For example,
in Fig. 6(d), is redundant because , , , and
overlap with rule 27 from . Similarly, is redun-
dant. Note that denotes that overlaps
with nonoverlapping rules from .
E. Multirule Coverage Redundancy Detection
To detect multirule coverage redundancy, our basic idea
is 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 nonoverlapping
discarding rules from and denote the set
of new rules generated from . For any rule
from , if a nonoverlapping rule from is multirule
coverage redundant, i.e.,
where from , there is a rule
that covers , i.e., . Thus, after
computes the set of new rules from , we reduce

Fig. 6. Comparison of two firewalls.
the problem of multirule coverage redundancy detection to
single-rule coverage redundancy detection. Then, two parties
and can cooperatively run our protocol proposed
in this section to identify the nonoverlapping single-rule and
multirule coverage redundant rules from at the same
time. However, the key question is how to compute the set of
new rules .
A straightforward method is to compute all possible rules that
are covered by a single or multiple nonoverlapping discarding
rules among . All these rules form the set of new
rules . However, this method incurs two major draw-
backs. First, the time and space complexities of this method can
be significant because the number of all these rules could be
huge. Second, due to the huge number of these rules, the com-
munication and computation costs increase significantly. The
relationship 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 discarding
rules among . The term largest can be explained
as follows. Without considering the decision, a firewall rule
with 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. The
term largest means that if a hyperrectangle contains the
hyperrectangle but is larger than , has some parts that
are not covered by all the hyperrectangles . For
example, the nonoverlapping discarding rules in
Fig. 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 different
dashed rectangles. Note that is the same as , and is
the 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 or
multiple 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. If
there exists no largest rule among that covers , we
can 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 these
generated rules, there exists at least a largest rule, otherwise
the 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 discarding
rules . Our idea is to first compute the largest rules
for every two rules among . Repeat computing the
largest rules for every two rules in the previous step until the
resulting rules do not change. Finally, the resulting rules are
the set of all the largest rules . Note that it is trivial
to compute the largest rules from two rules. This algorithm is
shown 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 do
3 for every two rules , in do
4 compute the largest rules from and ;
5 add the largest rules to ;
6 for each rule in do
7 if there is a rule in such that
then
8 remove from ;
9 ;
10 ;
11 return ;
For example, to identify the single-rule and multiple-rule cov-
erage redundancy simultaneously, only needs to perform
one more step between Fig. 4(d) and (e). computes all
the largest rules from the nonoverlapping discarding rules in
Fig. 4(d), which are
Finally, can identify that
is 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 are
interfirewall redundant. As each path in the all-match FDD
of corresponds to a nonoverlapping rule, we call the
paths that correspond to the redundant nonoverlapping rules
redundant paths and the remaining paths effective paths. For
example, in Fig. 8, the dashed paths are the redundant paths
that 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 two
conditions hold: 1) there is a redundant path whose terminal
node contains sequence number ; 2) there is no effective path
whose 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], the
resolving set of each rule in firewall satis-
fies the condition , where
are all the paths whose terminal nodes contain as
the smallest element. Based on the definition of interfirewall re-
dundant rules in Section III-A, rule is interfirewall redundant
if 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 nodes
contain 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 redundancy
removal 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 fact
that our protocol can identify all the redundant paths in ’s
all-match FDD.
V. FIREWALL UPDATE AFTER OPTIMIZATION
If or changes after interfirewall optimization, the
interfirewall redundant rules identified by the optimization may
not 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 this
case, 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 to
accept in . In this case, needs to notify
which nonoverlapping rules (indices of these rules) from
are changed. Using this information, checks
if there were any rules in that were removed due to
these rules, and then adds the affected rules back into .
3) changes the decisions of some rules from accept to
discard 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 may
change, 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 the
fourth case, since the resolving sets of some rules in
may change, it is important for to run our protocol
again.
VI. SECURITY AND COMPLEXITY ANALYSIS
A. Security Analysis
To analyze the security of our protocol, we first describe the
commutative encryption and its properties. Let denote a set
of private keys and denote a finite domain. A commutative
encryption is a computable function
that 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 element
of ; 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 field
after removing duplicate prefixes, e.g. in Fig. 5(e), denotes
the first prefix set. Our cooperative optimization protocol es-
sentially compares and in a privacy-preserving
manner. 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 secure
computation [2], [8], if we can prove that the distribution of
the ’s view of our protocol cannot be distinguished from a
simulation that uses only , , and ,
then cannot learn anything else except
and . 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 . The
simulator for uses key to create a set from
and 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 be
distinguished from this simulation.
Next, we analyze the information learned by and .
After implementing our protocol, knows the converted
firewalls of and , e.g. Figs. 4(j) and 5(g), and
knows the comparison result, e.g. Fig. 6(d). On side, for
each field , it knows only and
, and it cannot reveal the rules of for two reasons. First,
in , a numericalized prefix can be generated from
many 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 for
a prefix in , does not know which rule in
contains that number. On side, it only knows that
the prefix in belongs to which nonoverlapping rules in
. However, such information is not enough to reveal the
rules in .
B. Complexity Analysis
Let and be the number of rules in two adjacent firewalls
and , respectively, and be the number of fields
in both firewalls. For simplicity, we assume that the numbers
in different fields have the same length, say bits. We first
analyze the computation, space, and communication costs for
the conversion of . Based on the theorem in [14], the max-
imum number of nonoverlapping rules generated from the FDD
is . Each nonoverlapping rule consists of -bit
intervals, and each interval can be converted to at most
prefixes. Thus, the maximum number of prefixes generated
from these nonoverlapping rules is . Note
that the total number of prefixes cannot exceed because
puts all prefixes into one set. Thus, the computation cost
of 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 computation
cost of is , the space
cost of is , the communication cost is
, and the computation cost of is
.
The computation and communication costs of firewall update
depend on the different cases in Section V. There is no cost for
Case 1 in Section V. Case 2 only incurs the computation and
communication costs of firewall comparison. For Cases 3–5, the
computation and communication costs of firewall update are the
overall 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 running
our protocol many times.
VII. EXPERIMENTAL RESULTS
We evaluate the effectiveness of our protocol on real firewalls
and 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 with
two Intel Xeon cores and 16 GB of memory.
A. Evaluation Setup
We conducted experiments over five groups of two real
adjacent firewalls. Each firewall examines five fields, source
IP, 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 the
Pohlig–Hellman algorithm [22] with a 1024-bit prime modulus
and 160-bit encryption keys. To evaluate the effectiveness, we
conducted our experiments over these five groups of adjacent
firewalls. To evaluate the efficiency, for two firewalls in each
group, 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 the
efficiency, we generated a large number of synthetic firewalls
based on Singh et al.’s method [24]. The synthetic firewalls
also examine the same five fields as real firewalls. The number
of 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 synthetic
firewall as and then measured the processing time and
communication cost of two parties. Second, we processed each
synthetic firewall as and measured the processing time
and communication cost. Third, we measured the comparison
time for every two synthetic firewalls. We did not evaluate the
effectiveness of our protocol on synthetic firewalls because they
are generated randomly and independently without considering
whether 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 optimization
algorithm , and two adjacent firewalls and , we
use to denote a set of interfirewall redundant
rules in . Let denote the number of rules in and
denote the number of interfirewall redundant
rules in . To evaluate the effectiveness, we define a redun-
dancy ratio .
This ratio measures what percentage of
rules are interfirewall redundant in .
C. Effectiveness and Efficiency on Real Policies
Table I shows the redundancy ratios for five real firewall
groups. 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 in
firewall . Fig. 9 shows the processing time and commu-
nication cost of two parties and when processing
; Fig. 10 shows the processing time and communication
cost 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 I
REDUNDANCY RATIOS FOR FIVE REAL FIREWALL GROUPS
the comparison time of each group. Fig. 12 shows the overall
processing time and communication cost of implementing our
protocol on real firewalls. Note that the processing time in
Fig. 12 does not include the communication time between two
parties.
Our protocol achieves significant redundancy ratio on four
real firewall groups. For five real firewall groups, our protocol
achieves 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 are
interfirewall redundant rules. For firewall groups Econ, Ath, and
Comp, our protocol achieves 14.4%–17.1% redundancy ratios,
which implies that about 15% of rules in are redundant
in 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 effectively
remove interfirewall redundant rules and significantly improve
the network performance.
Our protocol is efficient for processing and comparing two
real firewalls. When processing in the five real firewall
groups, the processing time of is less than 2 s and the pro-
cessing time of is less than 1 s. When processing in
those real firewall groups, the processing time of is less
than 4 s and the processing time of is less than 10 s. The
comparison time of two firewalls is less than 0.07 s. The total
processing 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 and
that from to are less than 60 kB. Note that the com-
munication cost from to and that from to
are the same because and encrypt the same number
of values and the encrypted values have the same length, i.e.
1024 bits in our experiments. When processing in those
real firewall groups, the communication cost from to
is less than 300 kB. The total communication cost between two
parties 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 and
communication cost of implementing our protocol on synthetic
firewalls. 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 vertical
axes 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 the
synthetic firewalls as , the processing time of is less
than 400 s and the processing time of is less than 20 s. The
comparison 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 firewalls
as , the communication cost from to and that
from to grow linearly with the number of rules in
, and both costs are less than 420 kB. Similarly, when
processing synthetic firewalls as , the communication cost
from to grows linearly with the number of rules in
, and the communication cost from to is less
than 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 such
redundancy. We implemented our protocol in Java and con-
ducted extensive evaluation. The results on real firewall policies
show that our protocol can remove as many as 49% of the rules
in 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. Reducing
the 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 is
possible in the opposite direction, i.e., to . In the
first scenario, to , it is that is improving the
performance load of , and in return is improving the
performance of in a vice-versa manner. All this is being
achieved the without or revealing each other’s
policies thus allowing for a proper administrative separation.
Our protocol is most beneficial if both parties are willing to
benefit from it and can collaborate in a mutual manner. There
are many special cases that could be explored based on our
current protocol. For example, there may be hosts or Network
Address Translation (NAT) devices between two adjacent
firewalls. Our current protocol cannot be directly applied to
such cases. Extending our protocol to these cases could be an
interesting 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 sharing
across 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 in
the 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 implementation
of cross-domain cooperative firewall,” in Proc. IEEE ICNP, 2007, pp.
284–293.
[7] Q. Dong, S. Banerjee, J. Wang, D. Agrawal, and A. Shukla, “Packet
classifiers 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 policies
in 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 and M. G. Gouda, “Complete redundancy removal for packet
classifiers 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 complete
redundancy removal for packet classifiers in TCAMs,” in Proc. IEEE
INFOCOM, 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 systematic
approach 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-prefix
approach to compressing packet classifiers in TCAMs,” in Proc. IEEE
ICNP, 2009, pp. 93–102.
[21] C. R. Meiners, A. X. Liu, and E. Torng, “Topological transformation
approaches to optimizing TCAM-based packet processing systems,” in
Proc. 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,” IEEE
Trans. 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 classification
using 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 classification
of customer data without loss of accuracy,” in Proc. SIAM SDM, 2005,
pp. 21–23.
[27] W. Lee and D. Xiang, “Information-theoretic measures for anomaly
detection,” in Proc. IEEE S&P, 2001, pp. 130–143.
[28] R. Sekar, A. Gupta, J. Frullo, T. Shanbhag, A. Tiwari, H. Yang, and
S. Zhou, “Specification-based anomaly detection: A new approach for
detecting 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. IEEE
S&P, 2006, pp. 199–213.
Fei Chen received the B.S. and M.S. degrees in
automation from Tsinghua University, Beijing,
China, and the Ph.D. degree in computer science
from Michigan State University, East Lansing, in
2011.
He is currently a Performance Engineer with
VMware, Inc., Palo Alto, CA.
Bezawada Bruhadeshwar received the B.E. degree
from Osmania University, Hyderabad, India, in
1998, and the M.S. degree in electrical and computer
engineering and Ph.D. in computer science and
engineering from Michigan State University, East
Lansing, 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 dependable
systems.
Alex X. Liu received the Ph.D. degree in computer
science from the University of Texas at Austin in
2006.
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 in
2009, and the Withrow Distinguished Scholar Award
in 2011 at Michigan State University.

Cross-Domain Privacy-Preserving Cooperative Firewall Optimization

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Cross-Domain Privacy-Preserving Cooperative Firewall Optimization

Similar to Cross-Domain Privacy-Preserving Cooperative Firewall Optimization (20)

Recently uploaded

Recently uploaded (20)

Cross-Domain Privacy-Preserving Cooperative Firewall Optimization