www.elsevier.com/locate/comcom

Computer Communications 30 (2007) 1487–1497

Crosslayer firewall interaction as a means to provide effectiveand efficient protection at mobile devices

Peter Langendoerfer a,*, Krzysztof Piotrowski a, Steffen Peter a, Martin Lehmann b

a IHP, Im Technologiepark 25, 15236 Frankfurt (Oder), Germanyb DFS Deutsche Flugsicherung GmbH, Langen, SH/IR, Am DFS-Campus 2, 63225 Langen, Germany

Available online 16 February 2007

Abstract

In this paper, we discuss packet filtering firewalls and an application level gateway approach used to secure handheld devices. Wepropose a firewall management plane as a means for crosslayer interaction. In our approach the application level gateway updatesthe firewall rules based on its knowledge about whether or not a certain source is sending malicious packets. Hereby, we pursue a policyof removing malicious packets as close as possible to the network interface. We show that in case of secure web service such a crosslayerinteraction can significantly decrease the CPU load in case of attacks, i.e., if many malicious packets arrive at the handheld device. Ourmeasurement results show that our crosslayer approach can reduce the CPU load caused by the application layer gateway by about 10–30%. Finally, we propose an integrated firewall processing approach that promises further improvements. It integrates the applicationcontrolled firewall before the MAC and provides crosslayer mechanisms to reduce the performance issues of traditional firewallapproaches.� 2007 Elsevier B.V. All rights reserved.

Keywords: Firewall management plane; Crosslayer interaction; XML; MAC firewall; Mobile devices

1. Introduction

Motivation. Mobile devices are becoming more andmore powerful, e.g., current HP iPAQs are equipped with400 MHz Xscale processors and 128 MB memory. In addi-tion wireless modems are integrated into these devices.With theses increasing capabilities it becomes feasible tointegrate mobile devices into e-commerce architectures,e.g., in business-to-consumer and in business-to-employeeapplications, too. As a result of this development theamount of sensitive data that is stored on mobile deviceswill increase tremendously. So, mobile devices will attractan increasing number of attackers, and since their integra-tion will be done in an ‘all-IP’ approach, they are exposedto all typical Internet attacks. From our point of view

0140-3664/$ - see front matter � 2007 Elsevier B.V. All rights reserved.

doi:10.1016/j.comcom.2007.01.019

* Corresponding author. Tel.: +49 335 56 25 350; fax: +49 335 56 25671.

E-mail address: langendoerfer@ihp-microelectromics.com (P.Langendoerfer).

mobile devices are tempting target due to the followingfacts:

1. The medium (air) can easily be accessed by anyone.2. Mobile devices are not protected by additional hardware

or software such as firewalls, which are normallydeployed at the border of a company network.

3. Compared to a fully equipped PC or laptop, the mobiledevices such as PDAs and mobile smart-phones stillhave very limited resources (calculation and batterypower). Strong and exhaustive use of security meansdrains down the battery of the mobile device quite fastleading to inconvenient up times.

Thus, mobile devices are normally not as protected asmore powerful devices are. The first two points cause thedevice to be immediately exposed to the attacker and thethird one limits the ways to defend it. Our approach useslayer interaction in order to reduce the computational bur-den, caused by security mechanisms. This also leads to the

1488 P. Langendoerfer et al. / Computer Communications 30 (2007) 1487–1497

fact that the mobile device is protected against maliciouscommunication partners at the lowest possible layer, whichin turn increases the security level of the mobile device.

Contribution and structure of this paper. In this paper, wediscuss the performance of firewall approaches running atMAC, IP and application layer on a mobile device, i.e., astate of the art PDA. The MAC and the IP layer personalfirewalls do simple packet filtering, whereas the applicationlevel gateway that does content inspection in order tosecure Web Services. Our measurements clearly indicatethat simple packet filtering firewalls can be used withouta significant degradation of the performance and up timeof the mobile device. The Web Service Security approach[8] results in a much higher computational burden for themobile device, which is due to its intensive use of crypto-graphic means.

In order to decrease the effort spent per malicious packetwe realized a crosslayer interaction between the IP netfilterand the Web Service security gateway. The latter updatesthe IP packet filter tables with new IP addresses as soonas it identifies a certain source as malicious. Our measure-ments show that this approach reduces the computationalburden of the mobile device by 75% in case of applica-tion-layer attacks. We also investigated the potential bene-fit of extending our crosslayer approach down to the MAClayer. Here our performance comparison of IP netfilter andEBtables clearly indicated that the major effort is not dueto firewall processing but to base band and physical layerprocessing. In order to reduce computational load alsoon these lower layers we propose a protocol architecturethat integrates MAC and IP functionality with filtering ofmalicious packets, and that supports interaction with thebase band processing.

This paper is structured as follows. Section 2 provides ashort state of the art. In Section 3, we discuss the idea oflayer interaction that provides efficient but lightweightsecurity architecture for mobile devices. In Section 4, wepresent our measurement results. Then we present the ideato filter the packets before the MAC layer and its evalua-tion. The paper concludes with a short summary and anoutlook on further research.

2. Related work

Crosslayer interaction is an important research issue inthe recent year. The basic idea of this approach is to reducethe computational load of mobile devices by exchanginglayer specific information, so that more sophisticated deci-sions can be taken at a higher or lower layer [18–21]. Theseapproaches are concentrating on the protocol layers two tofour, i.e., they are agnostic with respect to the applicationrunning. There are some specialized approaches, whichgain additional benefit from knowing the application.[22,23] are discussing this for multi media applications.

Security of mobile devices and related protocols such as802.11b have attracted significant research effort. So, manyproposals have been made to protect data during transmis-

sion, etc. But to the best of our knowledge, protectionmeans against network based attacks that attempt to hijackthe mobile device, to render it useless or to steal informa-tion out of its memory have not been researched. Thereare several solutions which provide firewall protection onthe IP layer. For mobile devices running under Linux,packet filters, such as netfilter [1] or nf-HiPAC [2], can beused. For PDAs running under MS Windows the first com-mercial packet filters by Bluefire [5] and Trust Digital [6,7]are available.

But since Web Services [4] are becoming more and morewidespread and commonly used, these mechanisms are nolonger sufficient to protect mobile devices against attacksdue to the fact that the related SOAP calls are tunnellingthe IP packet filters. Potential attacks are SQL code injec-tion to get access to confidential data and recursive payloadof XML messages [3] which consume the whole memorywhile being processed and thus render the mobile deviceuseless [16]. While the first may not be very probable inthe near future the latter is already feasible. A proper appli-cation of Web service security features as given in the WS-Security framework [8,9], and Security Assertion MarkupLanguage (SAML) [14] helps to protect the mobile deviceagainst those attacks. But up to now there is no Web Ser-vice firewall solution for handheld devices available. Reac-tivity [10] and Forumsystems [11] are providing suchsolutions for server class systems.

In this paper, we are focusing on crosslayer interaction,and we are taking advantage of the fact that we are usingthe layer interaction for a specific application, i.e., firewallfunctionality for mobile devices. In contrast to most otherapproaches, we are introducing a specialized component,which is responsible to deduce the next step based on thedata provided by individual layers.

3. Crosslayer interaction to reduce firewall effort

3.1. Basic idea

In order to protect computers within company’s net-work several specialized routers/computers are deployed.In such a network configuration, a router does the IPpacket filtering and on a separate computer, i.e., on a bas-tion, TCP- and application level gateways are executed.With such architecture, it is possible to separate the exter-nal and internal world physically as well as logically. Incontrast to this, the mobile device is exposed directly toattackers. Thus, it has to execute all protection mechanismsitself.

Providing a significant level of security enforces the useof packet filtering, application level gateways or similarapproaches – and exhaustive use of cryptographic means.Due to the still limited resources of mobile devices, all thesemeans have to be applied as efficient as possible.

From a security point of view as well as from efficiencypoint of view it is highly desirable to establish a defense lineas close as possible to the network interface. This means

Fig. 1. Current implementation of a Firewall Management Plane,displaying used software modules and crosslayer interaction.

P. Langendoerfer et al. / Computer Communications 30 (2007) 1487–1497 1489

that malicious packets should be identified and blocked atthe lowest possible layer. This has the following benefits:

• All higher layers are protected from malicious packets.• The mobile device does not spent battery and calcula-

tion power to process malicious packets at higher layers.

But packet filtering firewalls cannot detect whether anincoming packet is malicious or not, they just can checkif the packet belongs to an existing connection and if thesource address is already blocked, etc. For example httppackets usually tunnel IP firewalls. Thus, application levelgateways that do content inspection are needed to securemobile devices. This task is very time consuming andshould be done only if it is really necessary. In other words,it should be avoided whenever possible.

So in order to reduce processing effort at the applicationlayer, i.e., avoiding content inspection of malicious pack-ets, we propose to enable application layer gateways toupdate packet filters at lower layers. If the application layergateway detects a malicious packet its source address isadded to IP layer filtering rules. In order to verify the fea-sibility and the potential performance benefit of this idea,we implemented an application layer gateway on a PDAand realized the application to IP layer communication.The implementation details are given in the next subsection.

1 Due to space limitations, we do not provide results measured whileUSB was used. In addition we do not discuss the impact of thecomputational load of the PDA on usable bandwidth.

3.2. Implementation

In order to evaluate the potential gain of our crosslayerapproach we realized an architecture running an IP layerfirewall and an application layer gateway. We enabled theapplication layer gateway to extend the IP filtering tablewith new IP addresses, after detecting malicious packets.

We are using two kinds of IP packet filters namely nf-HiPAC and Netfilter (IPtables) in order to measure theperformance of IP layer packet filtering. Here we investi-gated how the number of rules influences the performanceof the packet filtering. This is important since due to ourpropagation strategy the number of filtering rules willincrease constantly. As application level gateway we areusing Xerces-c [12] to validate incoming XML packets,here SOAP calls or answers, and XML security for dataintegrity check, authentication, etc. The cryptographicmeans as well as a rigorous verification of the SOAP pack-ets against a strictly defined XML schema provides reason-able first step towards application level firewallfunctionality.

We developed our example Web Service using thegSOAP framework [15] that provides access to sockets alsoon application level. Thus, we did not include the addressresolution in our first implementation. But compared topotential gain and the quite high effort to detect maliciouspackets on the application level, the additional effort foraddress resolution can be neglected. Fig. 1 shows the

current realization of the system, running on an HP iPAQh5550.

4. Measurements

Measurement set-up. Fig. 2 shows the network we usedto run the measurements. As mobile device we used anHP iPAQ Pocket PC h5550 with a 400 MHz Xscale Proces-sor, 128 MB SDRAM, 48 Mbyte flash ROM and an inte-grated 802.11b modem. The iPAQ is running theFamiliar Linux distribution version 0.8 [13]. As communi-cation partner we used an Acer 290 notebook, runningSUSE Linux version 9.1. The wireless connection was setup using a D-Link DI-624 router providing an 802.11gwireless access point and four 100Mbit Ethernet interfaces.The wired connection was realized with USB1.1 cableattached to the notebook and to the iPAQ. We used theUSB connection for the following reasons: first, it ensuresthat the computational load on the PDA is not limitedby the available bandwidth and second, it is used to guar-antee reproducible measurement results, due to the factthat no network errors occur in a wired connection.1

On top of our sample network, we realized a verysimple Web Service client that does nothing else thanaccepting incoming ‘‘answers’’ from a Web service pro-vider. In addition, we realized a simple Web service pro-vider, which accepts a request and sends back an answerthat has a size of 1 KB. Thus, the execution of the WebService does not influence the measurement results. OurWeb service client and our Web service provider havebeen realized using the gSOAP framework [15], and both

Fig. 2. Measurement set-up.

1490 P. Langendoerfer et al. / Computer Communications 30 (2007) 1487–1497

can be executed on the PDA. In Section 4.2, we presentmeasurements done with the Web Service client runningon the PDA. In this case, we present measurements fordifferent packet sizes, which may result from differentrequests to the service provider side. In Section 4.3, wepresent measurements of the Web service provider run-ning on the PDA. Here, the size of the incoming packetsis no longer of interest since we assume that normallythe size of request is quite small, but a lot of requestis sent to the service provider which will cause the majorpart of the effort at the provider side.

4.1. IP layer packet filtering

Filtering of packets at the IP layer is the first step tosecure a handheld device. This is why we first measuredthe performance of IP packet filter approaches as a firstsimple step towards securing a handheld device againstmalicious communication partners. We altered the sourceaddress of the incoming packets on a per packet basis inorder to ensure that all rules had to be checked before anincoming packet was recognized as malicious, i.e., our mea-surements presented later show the performance in a worstcase scenario. In these experiments all IP packets had themaximal size but were not fragmented.

Our measurement results show that the additional CPUload is about 10% as long as the number of rules sets2

applied is less than 200, see Fig. 3. Please note that theCPU load is about 20% even without running any securityfunction when a wireless connection is used, so additional10% of CPU usage seems to be an acceptable price forincreasing the security of the mobile device. The situationchanges when the number of rule sets is growing. But eventhen, more than 1000 rule sets have to be applied before theCPU load is about 50%. So, as long as no really exhaustiveuse of rule sets is made packet filtering can be applied with-out turning the mobile device useless. If nf-HiPAC is used

2 Each rule set contains 2 outgoing (stateless + stateful) rules and 2incoming rules.

the additional effort for filtering is even less than 5%, inde-pendent of the size of the rule set.3

Our measurement results clearly indicate that IP layerfiltering has some impact on the performance of the mobiledevice. But with a reasonable number of rule sets, it is fea-sible to use IP packet filtering.

4.2. Web service gateway

As second experiment, we measured the performance ofan application level gateway that is securing a web service.Here, we investigated the performance of several XMLsecurity issues such as encryption and digital signatures.In this experiment, we used Web Service request with a sizeof 1, 10, 100, and 1000 KB.

In order to ensure secure operation at the applicationlayer a lot of different techniques have to be applied. First,a certain packet containing SOAP requests has to be vali-dated against the XML scheme of the correspondingWeb Service. In addition, the XML security features suchas en-/decryption and digital signatures have to be takeninto account. The measurements discussed in this subsec-tion present the client side of our simple Web service andhave been measured on an iPAQ H5550.

In order to verify the computational load caused by thedifferent security functions we have measured the followingconfigurations:

• Os: Original set-up (mini-httpd and http) without anysecurity functions used as benchmark and to calculatethe overhead resulting from the security function usedin other configurations.

• Bc: Basic configuration XML packets are parsed andoptionally serialized.

• BcV: Like Bc including the following addition: validation

of incoming packets against corresponding XML scheme.

3 The independence of nf-HiPAC of the size of the applied rule set wasalready measured for PCs and presented in [17].

0.00

0.10

0.20

0.30

0.40

0.50

0.60

0.70

0.80

0.90

0 250 500 1000 1500 2000

rule sets

CP

U %

CPU iptablesCPU nf-HiPAC

100

Fig. 3. CPU usage in percent vs. size of the applied rules set for IP layer packet filtering using of IP tables and nf-HiPAC; measurements done on HPIPAQ h5550; using a wireless connection via 802.11b.

P. Langendoerfer et al. / Computer Communications 30 (2007) 1487–1497 1491

• BcS: Like Bc including the following additions: signa-ture generation and verification (signXML at server,verifyXML at client).

• BcE: Like Bc including the following additions: En-/decryption of XML packets (encryptXML at server,decryptXML at client).

• BcES: like BcE including the following additions: signa-ture generation/verification.

Fig. 4 shows the percentage of CPU usage for the appli-cation level gateway configurations explained above. Foreach configuration we measured requests with the size of1, 10, 100, and 1000 KB.

The measurements depicted in Fig. 4 show clearly thatthe additional security functions lead to a significantlyincreased CPU load. It is even increased significantly ifthe incoming packets are only parsed and validated.Fig. 5 shows the load distribution in jiffies4 per scenarioand size of requests in more detail. Comparison of Figs.4 and 5 shows that despite the CPU load in per cent is moreor less equivalent for all sizes of requests, the absolute CPUload in scenarios with small packet sizes is relatively low. Inaddition, it can be seen that especially the XML securityfunctions en-/decryption and the application of digital sig-natures increase the CPU load. The peak load in the BcSconfiguration results from the effort inhibited by the needto bring the request/answer packets in the canonical for-

4 Jiffies denote the number of hardware clock ticks that were counted ina certain time interval; the number of jiffies and the CPU usage are storedat /proc/uptime and /proc/stat by the Linux system, whenever running.Thus, we did not need to include measurement or profiling instruction, sothat our measurements are not influenced by any measurement procedure.

mat, which is required to ensure proper signature verifica-tion at the receiver side. The effort for this operation isdramatically reduced if the packet is encrypted (see Fig. 5BcES scenario) since the encrypted data is in canonicalform already, which ensures that less tokens have to beevaluated.

Depending on the Web Service and its configuration, atleast parsing and validating have to be done in order toensure proper operation of the running Web service clientor service. Thus, the additional overhead caused by theapplication level gateway is quite low, i.e., the differenceof the CPU load between the configuration BcV and BcSis less than 20%. The performance penalty caused by thesecurity functions can be minimized if the application levelgateway passes the reference to the parsed tree and theresult of the validation to the Web Service. So, these func-tions have to be executed only once.

4.3. Crosslayer interaction

The effort to secure a handheld device is significant, asalready shown earlier in this section. In order to reducethe total effort, we propose to realize a vertical crosslayerinteraction between application level gateways doing con-tent inspection and firewall solutions on lower layers. Inorder to evaluate the potential performance gain of ourapproach we measured the following scenarios:

• Original. No malicious packets.• Original2. All packets are malicious, and the detection is

done at the application level.• Original3. Like Original2 but only 50% of the packets

are malicious.

20.00

30.00

40.00

50.00

60.00

70.00

80.00

90.00

100.00

Os Bc BcV BcS BcE BcES

CP

U %

1k

5k

100k

1MB

Fig. 4. CPU load of an iPAQ running our Web service client with diverse security settings applied for incoming Web service answers.

1.00

10.00

100.00

1.000.00

10.000.00

100.000.00

Os Bc BcV BcS BcE BcES

Jiff

ies

1k5k100k1MB

Fig. 5. CPU load in jiffies for diverse settings of our application levelgateway running on an iPAQ h5550; measurements displayed for thefollowing packet sizes: 1000, 100, 5, and 1 KB requests.

1492 P. Langendoerfer et al. / Computer Communications 30 (2007) 1487–1497

• IPtables1. 50% of the packets are malicious; the firstmalicious packet of a certain source is detected at theapplication level, then the IP netfilter is updated andall following malicious packets from the same sourceare detected and dropped at the IP layer.

• IPables2. Like IPtables1, but all packets are malicious.

Fig. 6 shows the CPU load for all scenarios. Comparingthe scenarios Original2 and IPtables1 clearly indicates thatupdating the IP netfilter rule sets helps to reduce the CPUload significantly. In our example, the CPU load is reducedby about 10%, in case that 50% of the incoming packets aremalicious. If the number of malicious requests is increasedthe benefit resulting from our approach increases too. Inaddition to the reduced CPU load our approach enablesthe Web service to serve more requests within the sametime interval. The scenarios Original3 and IPtables1 havebeen executed under the same conditions, i.e., half of the

incoming requests have been malicious. Due to the applica-tion of our crosslayer approach about 300 additionalrequests more have been processed in the latter scenario.Please note that the benefit resulting form our approachis due to the fact that all incoming packets in scenario IPta-bles2 are malicious, which means they are processed onlyonce by the application level gateway, and afterwards theyare blocked by the IP layer firewall.

5. Extending crosslayer interaction to lower layers

Our measurements clearly indicate that pushing firewalleffort to lower layer is beneficial. It reduces the CPU usageand helps to increase throughput of other connections andbattery lifetime. So, the next step is to verify whether wecan increase the performance gain by pushing the firewalleffort further down the protocol stack, i.e., down to theMAC layer, or more correct before the MAC layer.

In order to evaluate the improvement caused by theMAC firewall, we compared the performance of it againstan IP firewall. Concretely, we measured throughput andCPU usage of the IPtables firewall as it is described inthe previous section against a firewall that is based onthe EBtables tool. EBtables [24] is a tool that is meantfor bridging packets on the Ethernet layer. Configured asbridging router (brouter) it allows to filter the packetsbefore entering the actual network stack. The brouter deci-des, following a list of rules, whether an incoming packet isdirectly put in the network stack or should enter the bridge.We configured the actual bridge so that it ultimately dropsevery packet. The scheme is shown in Fig. 7. In this config-uration, it is an adequate MAC layer firewall.

The source code of EBtables bases mainly on code ofIPtables. For our tests, this is very beneficial, since it prom-

3079

1617

2164

3290 1617

2164

7101

40.02%41.14% 40.94%

30.90%

8.73%

0

1000

2000

3000

4000

5000

6000

7000

8000

Original Original2 Original3 iptables1 iptables2

Req

ues

ts

0.00

0.05

0.10

0.15

0.20

0.25

0.30

0.35

0.40

0.45

CP

U in

%

faulty Requests

clean Requests

CPU in %

Fig. 6. CPU load caused by Web service provider with and without using crosslayer interaction in scenarios with different percentage of malicious request;measurements done on an iPAQ h5550.

EBtables

brouterFILTER

rules

good packets

Incoming packets

Bridge = DROPbad

packets

IP

EBtablesfirewall

MAC

Fig. 7. The idea of the MAC firewall.

0

100

200

300

400

500

600

700

800

900

0 200 400# o

thro

ug

hp

ut

[pac

kets

/s]

small packets/ebtables

small packets/iptables

big packets/ebtables

big packets/iptables

Fig. 8. The throughput of the firewall solution dep

P. Langendoerfer et al. / Computer Communications 30 (2007) 1487–1497 1493

ises very comparable results. In order to isolate the mea-surements on the pure network processing and to suppressprotocol overhead we used UDP instead of TCP packets,in these tests. We performed the tests with small UDPpackets (50 bytes) and large UDP packets (1460 bytes) sentvia WLAN on firewall configurations with 100, 500, and1000 firewall rules. Every packet has to pass each rulebefore it finally is accepted or dropped. The large packetscorrespond to the usual TCP data transfer packets, whilethe small packets are kind of worst case test for firewalls.

Fig. 8 shows the throughput measured in packets persecond. The throughput for big packets is not affected bythe firewall rules. This is because for such big packets thebottleneck is not the header processing but transmittingand copying the packet with the payload. The small packetthroughput is much more affected by the header processing

600 800 1000f rules

ending on the number of rules and packet size.

Table 1The CPU utilization while packed dropped depending on the layer

Packet droppedat

EBtables MAC layer IPtables IP layer

Reason Policy Bad MACaddress

Policy Bad IPaddress

CPU utilization(%)

39.5 40.0 42.5 43.0

1494 P. Langendoerfer et al. / Computer Communications 30 (2007) 1487–1497

and thus by the number of firewall rules. The 1000 rulestest processes 60% less packets with EBtables than withoutfirewall. For IPtables, the decrease is still about 40%.

The CPU utilization that is presented in Fig. 9 shows thereason for the throughput data. The throughput for the bigpackets does not go down because the corresponding CPUusage is always less than 100%. However, the usage riseswith increasing number of rules. The tests with small pack-ets and many rules are clipping at the 100% CPU utiliza-tion. This is the reason why the packet throughputdecreases. The CPU usage for the EBtables tests is signifi-cantly higher than the corresponding IPtables tests. This iswhy the EBtables throughput decreases faster than the oneof IPtables.

It is a bit surprising that the performance of EBtables isso much worse than IPtables. But taking a look in the net-work stack can explain it. The MAC firewall gets thepacket, extracts MAC header, the network protocol andif necessary the IP header. Then the filtering is performed.If the packet is accepted it will be forwarded to the networkstack where again the headers are read and evaluated.Beside the multiply executed header processing other rea-sons are responsible for the worse performance:

• A MAC firewall has to access and extract more data.While IPtables only has to evaluate the IP related con-tent only, EBtables need to handle the whole packet.This means that at least the MAC addresses and net-work protocol must be evaluated additionally.

• In the IPtables implementation the IP addresses andports are checked very early in a fast path. It can bedone because IPtables knows it gets IP packets only.In EBtables the check for IP parameter is part of a spe-cial module that must be explicitly called.

0

10

20

30

40

50

60

70

80

90

100

0 100 200 300 400 5

# of

cpu

uti

lizat

ion

[%

]

Fig. 9. The CPU utilization depending on

• The MAC firewall has to process more packets than theIP based one, because the IP packets are just a subset ofall packets that pass the MAC firewall. Additionally itprocesses packets for other hosts before their destinationis checked in the MAC layer.

In order evaluate filtering overhead per module weperformed another simple test: The firewalls were con-figured with no rules but the policy to accept or dropthe packets. A packet must pass all preceding layers,i.e., when it is dropped by the IP layer it was acceptedby both firewalls and MAC layer. Indeed, it is no apractical setup, but it shows the filtering overhead.We sent small UDP packets as fast as possible i.e.,with 780 Pk/s. The measured CPU utilizations areshown in Table 1.

The results presented in Table 1 strongly indicate thatthe filtering effort is relatively low compared the protocolprocessing effort in the base ban and physical layer. There-fore, we propose an interleaving of firewall and protocolprocessing at the border of the MAC layer in the nextsection.

00 600 700 800 900 1000

rules

small packets/ebtables

small packets/iptables

big packets/ebtables

big packets/iptables

the number of rules and packet size.

P. Langendoerfer et al. / Computer Communications 30 (2007) 1487–1497 1495

5.1. Crosslayer communication

We propose to use an extended version of the firewallmanagement plane (FMP). The FMP gathers data aboutmalicious or at least suspicious packets. As soon as the sus-picion is proven, it updates the filtering rules available onlower layers. Whether a packet flow is considered to bemalicious depends on the policy deployed at the mobiledevice. A single packet which is, e.g., not well formed orwhich could not be validated may probably not be consid-ered as an attack. But it should be recorded that such apacket was received together with its source address. If asequence of suspicious packets coming from the samesource is detected, it might still be caused by network errorsnot detected at lower layers, but it may also be a kind ofattack. Thus, the source address should be marked asmalicious and the firewall entries of the lower layers haveto be updated. The maximal number of suspicious packetsthat are tolerated from a certain source, before this sourceis marked as suspicious or malicious, is also specified inthe policy file. So, the policy file reflects how cautious theuser is.

If a malicious source is detected, both IP and MACaddress are stored in the table of suspicious packetstogether with the destination IP port and the rank of thesuspicion taken from the policy file. If a similar packetappears again, the total rank is increased and if it reachesthe threshold all new packets from the source will bedropped by the firewall. Indeed, the blocking of MACaddresses must be done very carefully to avoid the casewhere the firewall drops all packets from a gateway or anaccess point that only routes them. If the packets are rou-ted, the filtering must be applied over IP data. However, in

Fig. 10. Schematic view of the proposed crosslayer architecture for a firewall

mobile environments, in particular in adhoc networks, thedevices are much more often directly connected to new orunknown peers, so that the filtering of MAC addresses isvery reasonable.

In order to propagate information about malicioussources from higher layers to lower layers the FMP needsto resolve, e.g., URLs in order to get the correspondingIP address. This can be done using the already availablemechanisms. Fig. 10 shows the overall architecture andthe interaction between the Firewall Management Planeand the firewall solutions on different protocol layers.

5.2. Integrated layer firewall processing

In order to improve the benefits resulting from early fil-tering of malicious packets we propose to allow interactionbetween the filtering firewalls and the base band process-ing, and the firewalls and the network protocol stack.

Fig. 11 shows the envisioned architecture. Here, theheader processing functionality of the MAC and the IPlayer is separated from the remaining functionality andexecuted immediately after the base band has completelyprocessed the MAC header. In the first step, the MACheader is inspected. If the packet is malicious or has a dif-ferent MAC address as destination address a STOP signalis sent to the base band process and the processing of thepayload is aborted.

Given the fact that for short UDP packet nearly 40% ofthe processing power is consumed before the MAC pro-cessing is started, this interweaving of lower layer with fil-tering approaches can lead to a significant reduction of theCPU usage. The actual benefit depends strongly on the sit-uation; if no attack is running nothing will be saved.

management plane including content inspection on the application layer.

Shared memory

MACHeader

EB Tables IP Header processing

IP Tables

MAC HDR IP HDR

MAC processing \ {header processing}

IP processing \ {header processing}

BB/PHY Processing

malicious malicious STOP

write write

read

read

ok ok

Fig. 11. The architecture of the proposed Integrated Layer firewall solution.

1496 P. Langendoerfer et al. / Computer Communications 30 (2007) 1487–1497

We currently have no own measurements to proof thebenefit of our idea. But in [18] the authors propose earlyMAC address recognition and stated that the MAC headeris just 5–10% of the complete MAC packet. Depending onthe current situation (number of mobile devices within thesame hot spot) the potential benefit varies between 0 (noother device) and 75%. With our idea the probability tosave energy Is increased due to the fact that in additionto packets with different MAC address, malicious packetsthat in the approach of [18] would be processed aredropped before the processing really starts.

The interaction of the firewall and the network pro-cessing layers reduces the effort for accepted packets.In the standard approach, the firewall evaluates theheader of the packet, but the only information that isforwarded to the network stack is that the packet wasdropped or accepted. The header processing must be per-formed again by MAC and IP layer. We propose that incase the packet is correct the already processed MACheader is stored in a memory area, which can also beaccessed by the remaining MAC procedures. The IPheader is processed in the same way. This architectureshould reduce the performance penalty observed in theEBtables tests substantially.

6. Conclusions and outlook

In this paper, we have investigated the performance ofIP layer firewalls as well as the performance of applicationlevel gateways for Web Services on handheld devices. Ourmeasurements indicate that it is feasible to use firewalls onmobile devices. The CPU load caused by IP layer filteringis less than 10%, even if about 200 rule sets are applied. Wehave proposed to use a crosslayer interaction to reduce theperformance penalty that results from the use of applica-tion level gateways on handheld devices. Our experimentsshow that layer interaction can reduce the CPU load byabout 30%. The actual CPU load reduction depends onthe number of malicious packets as well as on the securitymeans applied.

Pursuing a policy of removing malicious packets as closeas possible to the network interface we moved the firewallto the MAC layer. These experiments could not show anyfurther performance improvements. This is caused byimplementation issues but also by the fact that the packetheaders that already have been evaluated by the firewallare processed again on higher layers. In order to eliminatethis processing overhead we proposed an integrated layerfirewall processing. Data and conclusions that have beenmade by the firewall are shared with the actual networkprocessing layers. Thus, the extraction and evaluation ofIP or TCP data even before entering MAC layer can bebeneficial. A further improvement could be the proposedcontrol of the base band processing by the firewalls. Afterprocessing the header of a malicious packet, the firewallcan send a signal to the base band that stops the receptionof the packet’s payload.

The latter approach has not been implemented and pro-ven yet. It will be one of our next research steps to do itand to measure the resulting performance implications. Fur-thermore, we will evaluate the power consumption thatstems from the security functions running on a handhelddevice. We will also evaluate the impact of hardware acceler-ators for cipher mechanisms on the performance relations.

Acknowledgement

This work was partially funded by the German Ministryof Education and Research under Grant 01AK060B.

References

[1] Netfilter/IPtables Project Homepage. Available from: <www.netfilter.org>.

[2] nf-HiPAC: High Performance Firewall for Linux Netfilter. Availablefrom: <http://www.hipac.org>.

[3] Extensible Markup Language (XML) 1.0, 3rd ed. Available from:<http://www.w3.org/TR/2004/REC-xml-20040204>.

[4] E. Cerami, Web Services Essentials. O’Reilly & Associates, Inc, 2002.[5] Wireless Security Software for Handheld Mobile Devices from

Bluefire Security Technologies. Available from: <http://www.bluefiresecurity.com/>.

P. Langendoerfer et al. / Computer Communications 30 (2007) 1487–1497 1497

[6] Trust Digital – Solutions – TRUST Mobile Device Applications.Available from: <http://www.trustdigital.com>.

[7] Security Basics for PDAs and Handheld PCs. Available from:<http://www.smallbusinesscomputing.com/webmaster/article.php/10732_3400641_2>.

[8] Web Services Security (WS-Security). Available from: <http://www-106.ibm.com/developerworks/webservices/library/ws-secure/>.

[9] XML Encryption Syntax and Processing. Available from: <http://www.w3.org/TR/xmlenc-core/>.

[10] Reactivity: The Secure Web Services Deployment System. Availablefrom: <http://www.reactivity.com/>.

[11] Forum Systems, Inc. – The Leader In Web Services Security.Available from: <http://www.forumsystems.com>.

[12] XML-Security-C. Available from: <http://xml-security-c.sourceforge.net>.

[13] Handhelds.org – Open Source Operating Systems for HandheldDevices. Available from: <www.handhelds.org>.

[14] OASIS, Security Assertion Markup Language (SAML) V2.0. Avail-able from: <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security#samlv20>.

[15] Robert van Engelen, gSOAP 2.7.2 User Guide. Available from:<http://gsoap2.sourceforge>.

[16] Forum Systems: Anatomy of a Web Services Attack: A Guide toThreats and Preventive Countermeasures, 2004. Available from:<http://forumsystems.com/papers/Anatomy_of_Attack_wp.pdf>.

[17] Michael Bellovin: nf-HiPAC High Performance Packet ClassificationHigh Performance Packet Classification for Linux Netfilter, 2005.Available from: <http://www.hipac.org/documentation/nf-hipac-nfws2005.pdf>.

[18] M. Methfessel, H. Frankenfeldt, K.F. Dombrowski, R. Kraemer,Optimizing the downlink for mobile wireless devices, in: N.C.Beaulieu, L. Hesselink (Eds.), Proceeding of Wireless and OpticalCommunications (WOC), 2002.

[19] M. Methfessel et al., Vertical optimization of data transmission formobile wireless terminals, IEEE Wireless Communications (2002).

[20] P. Langendorfer et al., Shielding TCP from wireless link errors:retransmission effort and fragmentation, The Journal of Supercom-puting 23 (3) (2002) 245–260.

[21] Gustavo Carneiro et al., Cross layer design in 4G Wireless terminals,IEEE Wireless Communications 11(2) 2004 Island, May 2003.

[22] Radu Cornea, Shivajit Mohapatra, Nikil Dutt, Alex Nicolau, NaliniVenkatasubramanian, Interactive managing cross-layer constraintsfor mobile multimedia, in: IEEE Workshop on Constraint-AwareEmbedded Software (RTSS-2003), Cancun, Mexico, December, 2003.

[23] W. Yuan, K. Nahrstedt, S. Adve, D. Jones, R. Kravets, Design andevaluation of a cross-layer adaptation framework for mobile multi-media systems, in: Proceedings of SPIE/ACM Multimedia Comput-ing and Networking Conference (MMCN’03), Santa Clara, CA,January, 2003.

[24] EBTables project homepage: Available from: <http://ebtables.sourceforge.net>.

Peter Langendoerfer received his diploma incomputer science from the Technical Universityof Braunschweig in 1995 and his doctoral degreefrom the Brandenburg University of Technologyat Cottbus (BTU) in 2001. From 1995 until 2000,he worked as scientific assistant in the Depart-ment of Computer Science of the BTU. Since2000, he is with the IHP in Frankfurt (Oder).There, he is leading the mobile middleware group.He has published more than 50 refereed technicalarticles, filed five patents in the security/privacy

area and worked as guest editor for the Journal of Super Computing(Kluwer), Computer Communications (Elsevier), Wireless Communica-tions and Mobile Computing (Wiley) and ACM Transactions on InternetTechnology. He was general chair of the International Conference onInternet Computing, and technical program chair of the InternationalConference on Wired/Wireless Internet Communications. He is/was aTPC member of Globecom, VTC, ICC, WWIC and Wirelesscom andmany more conferences. His research interests include mobile communi-cation (especially privacy and security issues), protocol engineering, andautomated protocol implementation.

Krzysztof Piotrowski received his master of com-puter science degree in 2004 from the Universityof Zielona Gora, Poland. His master thesis wasdone as a part of the Mobile Business Engineproject at the IHP in Frankfurt Oder. The subjectof the thesis was a electronic payment scheme formobile devices called MONETA. After receivingthe degree he joined the IHP. He is currently amember of the mobile middleware group workingon solutions for security issues of wireless sensornetworks. He has published about 15 refereed

technical articles. His research interests include security and privacy issuesin wireless networks especially in resource constrained environments as

well as cryptographic and cryptanalytic methods for developing andevaluating payment systems.

Steffen Peter received his diploma in computerscience from the Brandenburg University ofTechnology at Cottbus (BTU) in 2006.After some preliminary work as student he joinedthe IHP in Frankfurt (Oder) in 2006. He workedin the Wireless Internet project developing ahardware TCP accelerator. In his diploma thesis,he was involved in the development of hardwarecryptography accelerators. In this area, he hasfiled three patents and has authored two technicalpapers.

He is currently member of the mobile middleware group where he isworking in the research of solutions for security issues of wireless sensor

networks.His research interests include security and privacy in mobile environmentswith emphasis on efficient hardware implementation for this purpose.

Martin Lehmann received his B.S. and M.S incomputer and media science from the Branden-burg University of Technology at Cottbus (BTU)in 2003 and 2005, respectively. From 2003 to2005, he worked in the IHP in Frankfurt (Oder).There he was with the Wireless Internet teamimplementing network protocols. Since 2005, hehas been working for the Deutsche FlugsicherungGmbH in Langen. There he is member of theLinux competency team.