A Collaborative Firewall for Wireless Ad-Hoc Social Networks
Leonardo Maccari
DISI, University of Trento, Povo, Italy
Keywords:
Collaborative Firewall, Wireless Ad-Hoc Networks, Security, Privacy.
Abstract:
A collaborative firewall can be realized in a multi-hop distributed wireless network when all or some of the
nodes in the network agree on a filtering policy and enforce it when routing a packet. Cooperative firewalling
introduces many challenges, how to distribute the rules, how to enforce them, how to reduce the global rule-set
in order to limit the impact on the network performance. This paper studies the performance of a collabora-
tive firewall when only a subset of the nodes of the ad-hoc network filter the packets. In order to achieve
higher performances the integration with OLSR protocol is proposed. Simulations on realistic scenarios are
performed and the source code of the simulator is released.
1 INTRODUCTION
A firewall is a bastion host that divides two segments
of a network with different trust levels. Packet fil-
tering may be applied at network layer or at higher
layers (i.e. application firewalls) in order to enforce
finer policies for security and performance reasons.
In a multi-hop wireless network the concept of bas-
tion host and network segments fade. The network
may access the Internet across a gateway which can be
used to filter part of the contents, but there is no stan-
dard mean of applying network-wide filtering policies
inside the multi-hop network.
This paper focuses on the integration of routing
and packet filtering in order to implement a collabora-
tive firewall, that is, a best effort network-wide filter-
ing function in which nodes will participate in order
to filter out as much of the unwanted traffic as possi-
ble. The three main contributions of this paper are:
tests are performed on real devices to justify the
need for optimization with large rule-sets. Our
tests show that rule-set size has a serious impact
on the average round trip time even with rule-sets
smaller than the ones considered in literature.
The integration with OLSR routing is proposed to
limit the collaborative filtering to a subset of the
MPR nodes.
Simulations are performed on realistic mobility
and path-loss models. The source code of the sim-
ulator is released to the public in order to stimulate
the interest in this research topic.
2 COLLABORATIVE
FIREWALLING
A collaborative firewall can be implemented in an ad-
hoc network if the nodes of the network distribute
their rule-sets, i.e. the rules that they want to be ap-
plied to the traffic directed to them, or generated by
them. Each node in the network will collect the rule-
sets of all the other nodes and build a global rule-set
made of the union of the single rule-sets that will be
used to filter the packets before forwarding them.
A collaborative firewall is useful in a wireless ad-
hoc network for mainly three reasons: performance,
security and privacy. From a performance point of
view it avoids the waste of network resources. If node
N
1
tries to connect to node N
2
on a service N
2
does
not support, the TCP packets sent to N
2
are wasting
resources along all the path from N
1
to N
2
. If node N
2
acts as a gateway it may want to limit the services or
the nodes that can access the Internet. A collaborative
firewall can be used in all the situations in which it is
necessary to limit the impact of unwanted traffic. For
instance nodes may agree to filter file-sharing appli-
cations or other resource greedy applications. From a
security point of view it can be a valuable instrument
to limit the impact of attacks against the network. Port
scans, floods, password brute force on open services
can be stopped using specific rules. Note that a node
may locally filter the traffic directed to himself, but
this has only a limited effect against a flooding attack
that can saturate the whole path from the attacker to
the victim. Under a privacy point of view an user may
290
Maccari L..
A Collaborative Firewall for Wireless Ad-Hoc Social Networks.
DOI: 10.5220/0004071802900295
In Proceedings of the International Conference on Security and Cryptography (SECRYPT-2012), pages 290-295
ISBN: 978-989-8565-24-2
Copyright
c
2012 SCITEPRESS (Science and Technology Publications, Lda.)
want to limit the scope of the communicationsthat are
generated by himself. For instance, the user may wish
to send broadcast chat messages only to the nodes that
are inside a certain geographical area (assuming the
nodes support some localization protocol). Another
example is to limit his visibility to a certain distance
(in terms of hops) from his position in the topology.
One way to achieve this is to modify the routing mes-
sages with firewall actions, removingthereferences to
the node outside a certain range (consider that routing
messages are not generated only by the user’s node).
Some of these functions could be achieved with
other means, for instance, group communications can
be achieved with group-based cryptography and ser-
vice discovery protocols can avoid opening unwanted
connections. Some other instead are typical of fire-
walls, like application layer filtering and reactive fil-
tering. A collaborative firewall is a valuable instru-
ment not only because it will achieve the second set
of goals but also because it will help solving the oth-
ers without increased complexity, since firewalling is
supported in many operative systems.
A distributed firewall can be imagined as an in-
strument made of three building blocks:
1. A rule-set generation tool. This can be completely
user generated, derived by high-level policies or
even generated in a reactive way.
2. A rule-set distribution protocol, which can be em-
bedded in the routing protocol used.
3. A rule-set enforcement policy that will try to limit
the number of effectively enforced rules per node
in order to save energy and limit the search time.
The most common organization for rule-sets is
the linear list. The price to pay for simplicity is the
time of the search that is linear with the size of the
rules. Many approaches exist to improve the look-
up time of the search on large rule-sets using com-
plex data structures. Most of these techniques are
imagined for rule-sets where only network and trans-
port layer fields are matched, so the regularity of
the patterns to be matched can be used to organize
the rule-sets. This is impossible with application-
layer filtering, that is needed for many useful traf-
fic filtering functions. Moreover, most of those tech-
niques are aimed at slowly varying rule-sets since they
move the complexity from the search operation to the
data structure organization. In a mobile ad-hoc net-
work nodes often enter and exit the network and may
change their rule-set, so that the cost of keeping the
data structure updated may be higher than the cost of
a linear search. A review of the difficulties of using
standard packet classification techniques in wireless
distributed network can be found in (Fantacci et al.,
2008).
In a wired network the most common firewall con-
figuration is to set the default rule to drop all the pack-
ets and to explicitly permit the allowed services. This
approach is hard to implement in ad-hoc networks,
since the changes in topology and in rule-sets take
some time to propagate in the network. At any time
the global rule-set calculated by a node may be out-
dated and the firewall may take wrong decisions. It is
tolerable to have false negatives (i.e. packets that are
forwarded by a node even if a rule exists that would
drop them) but not to drop valid packets. For this rea-
son the default rule must be set to allow the pack-
ets and each rule will produce a drop. As a conse-
quence, for each valid packet the whole rule-set must
be scanned.
Cooperative firewalling is a known subject in liter-
ature, an initial model has been proposed by Bellovin
et al. in (Ioannidis et al., 2000) where the fire-
wall is moved from a bastion host to the endpoints
of a still traditional centralized network. Recently,
the subject has received more attention, Bellovin
proposed a distributed policy enforcement platform
(Zhao et al., 2008a; Zhao and Bellovin, 2009; Zhao
and Bellovin, 2010; Zhao et al., 2011), as well as
other authors (Alicherry et al., 2008). Other works
focus on the application of hash functions to speed-
up rule-matching (Fantacci et al., 2008; Neira et al.,
2008) or on rule-set reduction techniques (Taghizadeh
et al., 2011). Similarly, if higher security is required
deny-by-default networks filter the communications
between two nodes if a previous security handshake
has been not performed (Zhang et al., 2008; Alicherry
et al., 2009). This paper explores an alternative ap-
proach,the possibility of limiting the number of nodes
that filter the packets in the network introducing inte-
gration with OLSR routing protocol to achieve more
efficiency.
3 CONSIDERED SCENARIO
The network model that is the focus of this paper is a
mobile ad-hoc social network where a group of peo-
ple create a multi-hop network to support the typi-
cal applications of social networking, similarly to the
model presented in (Li et al., 2012). The fragmen-
tation of mobile software platforms and the lack of
common protocols have slowed the penetration of ad-
hoc networks out of academia but recently there is a
concentrationof available operative systems and peer-
to-peer networking standards are emerging ( such as
Wi-Fi Direct, IEEE 802.11s). In general there seems
to be more interest in this topic from market players
ACollaborativeFirewallforWirelessAd-HocSocialNetworks
291
(for instance Qualcomm and Nokia
1
).
Such a network may be composed by a large num-
ber of nodes with pedestrian mobility that generate
the typical traffic of social networks, such as chat or
lightweight file-sharing (photo sharing, profile shar-
ing, vCard sharing...). For this paper, the chosen
routing protocol is OLSR since it better fits a situa-
tion in which the nodes need to know who is on-line.
Rule-sets have been piggybacked to OLSR HELLO
and TC messages. Instead of moving whole rule-sets
only a numeric ID is used. The assumption is that the
rule-sets are known in advance on the devices since
the applications come with a set of pre-defined rule-
sets. The users will choose one and sponsor just the
ID in HELLO messages, that in turn will be included
in TC messages. Alternatively, the users may periodi-
cally sponsor the whole rule-set at large intervals and
just the ID on OLSR messages. OLSR can be hard-
ened with cryptographic credentials in order to avoid
well-known attacks against routing, as in (Zhao et al.,
2008b). This will assure that the rule-set can not be
spoofed or altered by some malicious users.
How big a rule-set can be? client hosts are nor-
mally equipped with few rules while border routers
can be equipped with tens of thousands of rules.
Application layer rules are a powerful instrument to
avoid the spread of worms and spam, as well to shape
the access to services. They can be used on clients
in order to have a high security level irrespective of
the security of the applications that run on the device.
Empirically, a rule-set size between 10 and 50 rules
can be considered realistic, but the more services the
network offers, the more it can grow, especially for
application layer rules. In the simulation scenarios of
next section each node randomly chooses a 20 rules
rule-set out of a set of ten. With a realistic network
size (up to 100 nodes), the global rule-set that is the
union of all the rule-sets can grow up to thousands.
For simplicity only network and transport layers are
used as matching parameters in the simulations.
The mobility model is the one introduced in (Mu-
solesi and Mascolo, 2006). It describes communities
of people and shows statistical properties close to the
ones measured on real traces. The path-loss model
is a dual-slope model enriched with a ray-tracing al-
gorithm (Sommer et al., 2011). A realistic mobil-
ity model and the presence of obstacles will generate
topologies close to real ones.
To limit the overhead due to firewalling (for in-
stance, in terms of delay introduced) rule-sets can be
reduced as in (Taghizadeh et al., 2011), or the number
of nodes that act as firewalls can be limited. In both
cases false negatives will be generated. To evaluate
1
http://pervacy.eu/?p=171
the performance of the firewall two metrics are used:
M1: counts the false positives hop-by-hop, that is, each
time a packet is forwarded from the sender to the
destination IP (or to the point when it is dropped).
M2: counts the false positives end-to-end, that is, it
counts the packets that arrive to the destination IP.
M1 measures the inefficiency of the firewall as a mean
to reduce the traffic overhead for the whole network.
M2 measures the inefficiency in filtering traffic di-
rected against a certain host.
4 OLSR-BASED
COLLABORATIVE
FIREWALLING
To test the impact of large rule-sets on real devices the
delay introduced by the firewall in mobile devices was
measured. The tests were performed on two smart-
phones equipped with 400MHz and 600MHz ARM
processors and a dedicated GPU. Even if the market
offers faster CPUs for high-end devices, the proces-
sors used for the tests can be correctly considered as
representing an average processor that can be found
on smartphones, e-book readers, tablets.
The tests were performed using a PC connected
over a wired USB connection with the mobile device
in order to avoid the fluctuations of the Wi-Fi media.
This does not influence the test since the aim is to
havea measure of the delay due to the processing time
of the CPU. The mobile device was equipped with a
Linux kernel 2.6 and configured with rule-sets of in-
creasing size. The PC sent 300 UDP ECHO request,
the mobile devices answered with ECHO replies af-
ter having checked all the rules in the rule-set. For
each test the average round trip time (RTT) was cal-
culated and subtracted by the value measured with-
out any rule-set present. The rule-sets were composed
for 25% of layer 4 rules and for 75% of layer 7 rules
(string matching on the first 50 bytes of the packet).
Figure 1 reports the results. It can be noticed that,
as expected, the delay increases linearly with rule-
set size and that the delay introduced is relevant even
for few hundreds rules. In a network made of one
hundred nodes with rule-sets made of 30 rules the
global rule-setwill be made of 3000 rules which intro-
duces an average delay of 16 ms per hop. In the net-
work used for the simulations an average path length
of 3.2 hops has been measured, with standard devi-
ation around 1.5, that accounts for an average RTT
increment oscillating between 54ms and 150ms, to be
added to the delay introduced by the other layers. In
SECRYPT2012-InternationalConferenceonSecurityandCryptography
292
0
0.001
0.002
0.003
0.004
0.005
0.006
0.007
0.008
0.009
0.01
0.011
0.012
0.013
0.014
0.015
0.016
0.017
0.018
0.019
0.02
0.021
0.022
0 500 1000 1500 2000 2500 3000
Average increment in packet processing time
Ruleset size
Average processing time with mixed layer3/7 rules
400MHz processor
600MHz processor
Average
Figure 1: The delay introduced (seconds) changing rule-set
sizes.
works like (Taghizadeh et al., 2011) very large rule-
sets have been used (up to 10000). This test shows
that actually the impact on network performance is
present even with smaller sizes and that increased
CPU load can discourage nodes to to participate in
the collaborative firewall.
4.1 OLSR and Firewall Integration
The focus of this section is on a situation in which
not all the nodes are willing to participate to the dis-
tributed firewall, in particular when only a subset of
the nodes are computationally able to handle large
rule-sets. In this situation the collaborative firewall
is realized with a set of firewall nodes that is a subset
of the total (from now on those nodes will be simply
called the firewalls).
The firewalls will have a larger impact on the net-
work if the routing protocol is modified in order to
make them forward more traffic. In OLSR this can
be accomplished using a higher willingness parame-
ter. The willingness parameter determines how much
a node is willing to be elected MPR. Once elected
MPR the node will generate TC messages, forward
the broadcast traffic and will be preferentially selected
as a next hop to any other destination in the network
(as suggested in section 10, step 3.2 of RFC 3626).
MPRs play a fundamental role in OLSR but since
they generate control messages their number should
be kept as low as possible. The willingness is ex-
pressed with a value that ranges from 0 to 7. With a 0
value the node will never be chosen as an MPR, while
with 7 the node will always be chosen. For other val-
ues, when a node has two neighbors that can indiffer-
ently be elected MPR, the one with highest willing-
ness will be preferred. The value default is 3.
In figures 2(a) and 2(b) are reported metrics M1
and M2 for a network of 60 nodes in which only an
increasing fraction of randomly chosen nodes is a fire-
wall. Details of the simulations are reported in table
Table 1: Simulation parameters.
Dimension 600m x 600m, 60 nodes
Speed uniform in [0.5, 2] mps
Rule-set size 20/1200 (single/global)
Total open ports 25
Obstacles 2 obstacles, 70m x 80m
Duration 2000 seconds
Traffic avg. of 4800 UDP ECHO per
run, random destination
1. Two curves are present in each figure, one refers
to the overall performance of the distributed firewall
when willingness in set to 3 for every node (the curve
marked as “Willingness off”), the second refers to the
case of choosing 7 for nodes that are active firewall
and 2 for nodes that are not firewalls. All the metrics
are shown as a fraction of the unwanted packets that
get delivered when there is no active firewall.
As a first remark it can be noted that the M2 met-
ric decreases quite sharply even when only 20% of
the nodes are firewalls, then it slows down for higher
percentages. This is expected since the probability
of reaching a random destination follows a binomial
distribution with parameter p chosen as the fraction of
firewalls against the total number of nodes. When the
number of firewalls increases, only packets that travel
along short routes will not be filtered. As a conse-
quence, also M1 has the same trend since for each
packet that is filtered, in average, a number of hops
equal to half of the average route length is saved (if
the firewalls are chosen at random).
As a second remark it can be noted that chang-
ing the willingness parameter produces a significant
improvement. Even when only 10% of the nodes are
firewalls, around 40% of the packets are dropped be-
fore destination (metric M2), which makes a generic
communication very hard to complete. When 20%
of the nodes are firewalls a denial of service attack
against a node can be mitigated for the 65% of its ef-
fect against the target (metric M2) and 45% against
the whole network (metric M1).
Figure 2(c) reports the distribution of the MPR se-
lector set sizes for 4 runs with different parameters.
The selector set size is the size of the set of nodes that
elected the same node as MPR. This graph is shown
in order to verify the impact on the choice of MPR
nodes in the network. It can be seen that the impact
on the network is minimal and mostly positive. In av-
erage there are 30.58 MPR when 30% of the nodes
are firewalls against 34.16 when the willingness pa-
rameter is not changed. The distribution of the MPR
selector set is more polarized, meaning that there are
less nodes that have few selectors.
This result can be counter-intuitive, since more
ACollaborativeFirewallforWirelessAd-HocSocialNetworks
293
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9
Fraction of packets not filtered
Fraction of firewall nodes
M1 metric
Willingness on
Willingness off
(a)
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9
Fraction of packets not filtered
Fraction of firewall nodes
M2 metric
Willingness on
Willingness off
(b)
0
1
2
3
4
5
6
7
8
0 2 4 6 8 10 12 14
Number of MPRs
MPR selector set size
MPR selector set size distribution
Willingness off
Willingness on, 10%
Willingness on, 20%
Willingness on, 30%
(c)
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
2 4 6 8 10
Fraction of packets not filtered
MPR selector set size threshold
M1 and M2 metric
M1
M2
(d)
0
1
2
3
4
5
6
7
8
0 2 4 6 8 10 12 14
Number of MPRs
MPR selector set size
MPR selector set size distribution
Simple configuration
Realistic configuration
(e)
0.05
0.1
0.15
0.2
0.25
0.3
0.35
0.4
0.45
1 2 3 4 5 6 7 8 9
Fraction of packets not filtered
MPR selector set size threshold
M1 metric
Simple configuration
Realistic configuration
(f)
Figure 2: Metrics M1 (a) and M2 (b) increasing the fraction of firewall nodes. MPR selector set size distribution (c). M1 and
M2 against the MPR selector set size threshold (d). Comparison between simple and realistic scenarios (e,f).
nodes are forced to be MPR than with standard
OLSR. Actually, with OLSR the MPR choice is per-
formed independently by each node which means that
even if each node minimizes its own set, the inter-
section of all the MPR sets is not minimized. Hav-
ing some nodes with higher willingness polarizes the
choice thus reducing the intersection.
4.2 MPR-based Filtering
In this section another configuration is considered in
which all the nodes have equivalent resources. In or-
der to reduce the overhead introduced in the RTT it is
necessary to limit the set of firewalls trying to identify
the nodes that are more central in the topology.
Centrality is a known concept in networking (Kat-
saros et al., 2010) that can be estimated with a few
metrics. For the purpose of filtering the shortest-path
betweenness seems the wisest choice, since it rep-
resents the fraction of shortest multi-hop routes that
pass through a node. OLSR gives an approximated
global knowledge of the full topology. It is theoret-
ically possible for each node to calculate and keep
up-to-date its betweenness but in practice it is com-
putationally very costly. Betweenness can be approx-
imated limiting the scope of the calculation to only
the 2-hop neighbors. An MPR node is, by design, a
node that maximizes the betweenness between the se-
lector and its 2-hop neighborhood. Being an MPR is
a local esteem of centrality, thus, the chosen strategy
consists in ranking the MPRs using the size of their
selector set and then implementing the firewall only
in the nodes that have a rank over a certain threshold.
In figure 2(d) M2 and M1 metrics are reported
when the threshold is varied from the 11 to 1 (the x
axis is inverted in order to make the graph visually
comparable with the ones in figure 2(a) and 2(b)). It
is interesting to note that for a value of 9 and 7, which
roughly corresponds to the x-value of 10% and 20%
in figure 2(b) M2 is about half of the case when nodes
are selected randomly, meaning that the choice of the
MPR selector set size is an useful approximation of a
centrality measure. Note that the overall distribution
of the MPR selector sets size is known to any node
(every TC carries the selector set of an MPR). Given
this distribution some topological properties of the
network may be derived. The possibility of dynam-
ically choosing the MPR threshold to obtain a wanted
value for M1 or M2 is considered as a future work.
4.3 Impact of Simulation Scenario
In order to stress the importance of using correct mod-
els, some simulations have been repeated with a ran-
dom way-point mobility without obstacles. We re-
fer to this configuration as simple configuration and
to the model with obstacles, shadowing and Musolesi
mobility as the realistic configuration. While the two
configurations are functionally comparable (the aver-
age size of the routing table differs for 1.5 destina-
SECRYPT2012-InternationalConferenceonSecurityandCryptography
294
tions) the simple configuration generates shorter av-
erage paths (2.7 hops versus 3.2) and there is a big
difference is in the distribution of the MPR selector
set sizes as reported in figure 2(e) (for a total of 36
against 47). In figure 2(e) metric M1 is compared, the
curves seem very close but the difference in the MPR
selector set sizes makes the same threshold value cor-
respond to a different number of firewalls in the net-
work. If instead of comparing the MPR threshold the
two curves are compared using the number of fire-
walls per simulation (roughly this can be done shift-
ing the curve for the simple scenario two units left),
then an average 10% difference can be measured. In
conclusion this comparison suggests that the MPR se-
lector size threshold used as an approximation of cen-
trality seems to be independent from the topology at
this network size and that the simple scenario overes-
timates the firewall performance compared to a real-
istic one due to the shorter average path.
5 CONCLUSIONS
Cooperative firewalls can positively impact the per-
formances of ad-hoc and mesh networks. They play
a useful role in the enforcement of security policies,
for reactive security when the network is under attack,
to perform traffic shaping or to limit the diffusion of
traffic without relying on the support of applications.
Nevertheless, large rule-sets are hard to be handled
by the limited computation power of common mo-
bile devices. In this paper the impact of the com-
putational overhead has been measured showing that
thousands of rules introduce a large delay in RTT. It
has been shown that limiting the number of firewalls
in the network still allows to filter a high percentage
of unwanted traffic and that without adding complex-
ity, the performances can be improved using the in-
formation produced by OLSR. Since the behavior of
a routing protocol is very scenario-dependent a net-
work simulator with realistic mobility and path-loss
models has been realized on top of Omnet++ plat-
form. The source code is available on the project site:
www.pervacy.eu.
ACKNOWLEDGEMENTS
Financed by Provincia di Trento under The Trentino
programme of research, training and mobility of
post-doctoral researchers, incoming Post-docs 2010
CALL 1, PCOFUND-GA-2008-226070
REFERENCES
Alicherry, M., Keromytis, A., and Stavrou, A. (2008).
Distributed firewall for manets. Technical report,
Columbia University.
Alicherry, M., Keromytis, A. D., and Stavrou, A. (2009).
Evaluating a collaborative defense architecture for
manets. In Conference on Internet multimedia ser-
vices architecture and applications, IMSAA.
Fantacci, R., Maccari, L., Ayuso, P., and Gasca, R. (2008).
Efficient packet filtering in wireless ad hoc networks.
Communications Magazine, IEEE, 46(2):104 –110.
Ioannidis, S., Keromytis, A. D., Bellovin, S. M., and Smith,
J. M. (2000). Implementing a distributed firewall. In
ACM Conference on Computer and Communications
Security, Athens, Greece.
Katsaros, D., Dimokas, N., and Tassiulas, L. (2010). Social
network analysis concepts in the design of wireless ad
hoc network protocols. Network, IEEE, 24(6):23 –29.
Li, J., Wang, H., and Khan, S. U. (2012). A semantics-
based approach to large-scale mobile social network-
ing. ACM/Springer Mobile Networks and Applica-
tions, 17.
Musolesi, M. and Mascolo, C. (2006). A community based
mobility model for ad hoc network research. In In-
ternational workshop on Multi-hop ad hoc networks:
from theory to reality, REALMAN ’06.
Neira, P., Gasca, R., Maccari, L., and Lefevre, L. (2008).
Stateful rewalling for wireless mesh networks. In
New Technologies, Mobility and Security, NTMS ’08.
Sommer, C., Eckhoff, D., German, R., and Dressler, F.
(2011). A Computationally Inexpensive Empirical
Model of IEEE 802.11p Radio Shadowing in Urban
Environments. In 8th Conference on Wireless On de-
mand Network Systems and Services (WONS 2011).
Taghizadeh, M., Khakpour, A., Liu, A., and Biswas, S.
(2011). Collaborative firewalling in wireless net-
works. In Joint Conference of the IEEE Computer and
Communications Societies, INFOCOM 2011.
Zhang, H., DeCleene, B., Kurose, J., and Towsley, D.
(2008). Bootstrapping deny-by-default access control
for mobile ad-hoc networks. In Military Communica-
tions Conference, 2008. MILCOM 2008. IEEE.
Zhao, H. and Bellovin, S. M. (2009). Source prefix filtering
in ROFL. Technical Report CUCS-033-09, Depart-
ment of Computer Science, Columbia University.
Zhao, H. and Bellovin, S. M. (2010). High performance
firewalls in MANETs. In International Conference on
Mobile Ad-hoc and Sensor Networks.
Zhao, H., Chau, C.-K., and Bellovin, S. M. (2008a).
ROFL: Routing as the firewall layer. In New Security
Paradigms Workshop.
Zhao, H., Lobo, J., Roy, A., and Bellovin, S. M. (2011).
Policy refinement of network services for MANETs.
In The 12th IFIP/IEEE International Symposium on
Integrated Network Management (IM 2011).
Zhao, S., Aggarwal, A., Liu, S., and Wu, H. (2008b). A
secure routing protocol in proactive security approach
for mobile ad-hoc networks. In Wireless Communica-
tions and Networking Conference, WCNC 2008.
ACollaborativeFirewallforWirelessAd-HocSocialNetworks
295