Cooperation in Multi-hop Cellular Networks withExtended Security Analysis1 ∗

Naouel Ben Salem†, Levente Buttyan‡, Jean-Pierre Hubaux†, Markus Jakobsson§

July 11, 2003

Abstract

In multi-hop cellular networks, the existence of a communication link betweenthe mobile station and the base station is not required: a mobile station that has nodirect connection with a base station can use other mobile stations as relays. Com-pared with conventional (single-hop) cellular networks, this new generation can leadto a better usage of the available spectrum and to a reduction of infrastructure costs.However, these benefits would vanish if the mobile nodes did not properly cooperateand forward packets for other nodes. In this paper, we propose a charging and reward-ing scheme to encourage the most fundamental operation, namely packet forwarding.We analyse the robustness of our protocols against rational and malicious attacks. Weshow that our protocols thwart rational attacks and detect malicious attacks. We alsoshow that our solution makes collaboration rational for selfish nodes.

Keywords: Cooperation, Multi-hop Cellular Networks, Hybrid Cellular Networks, Ad HocNetworks, Packet Forwarding, Security, Pricing, Charging, Billing

∗1The work presented in this paper was supported (in part) by the National Competence Center in Re-search on Mobile Information and Communication Systems (NCCR-MICS), a center supported by the SwissNational Science Foundation under grant number 5005-67322

†Laboratory of Computer Communications and Applications (LCA), Swiss Federal Institute of Technol-ogy – Lausanne (EPFL), Switzerland ({naouel.bensalem, jean-pierre.hubaux}@epfl.ch)

‡Budapest University of Technology and Economics, Department of Telecommunications, Hungary(buttyan@hit.bme.hu)

§RSA Laboratories, 174 Middlesex Turnpike, Bedford, MA 01730, USA (mjakobsson@rsasecurity.com)

1

1 Introduction

The geographic area covered by a conventional cellular network is populated withbase stations that are connected to each other via a backbone. A mobile node can use thenetwork when it has a direct (single-hop) connection to a base station, but as soon as itis beyond the reach of the base stations coverage, the mobile node is disconnected fromthe cellular network. For the operator, the usual solution to this problem is to increase thecoverage of the network by adding antennas, and for the user to move until he reaches acovered region. An alternative solution would be to allow multi-hop communications inthe cellular network, which makes it possible for the isolated node to ask other nodes torelay its traffic to or from a base station.

The resulting network [1, 35, 13, 2, 33], frequently calledmulti-hop cellular network,presents several benefits [25, 14, 26, 23]. First of all, the coverage of the network is in-creased while the number of fixed antennas is kept relatively small. Second, the energyconsumption of the nodes can be reduced because the signal has to cover a smaller dis-tance. And finally, as the radiated energy is reduced, the interference with other nodesdiminishes as well.

Given the advantages listed above, multi-hop cellular networks represent a new andpromising paradigm. However, the proper operation of this new family of networks re-quires the mobile nodes to collaborate with each other. This collaboration is not guaranteedin a civilian network, where each node represents a single authority. Indeed, forwardingpackets is energy-consuming and a selfish user can tamper with his mobile device to re-move the relaying functionalities or simply shut down the device when he is not usingit. A systematic denial of the packet forwarding service would remove all the benefitsintroduced by the multi-hop aspect of the communications.

In this paper, we propose a technique to foster cooperation for the packet forwardingservice in multi-hop cellular networks. This solution is based on a charging and rewardingsystem.

This paper extends and completes our previous treatment of the same problem [3].This work is part of the Terminodes Project [20, 5, 16]. The rest of the paper is organizedas follows. We introduce the system, including the adversarial model, in Section 2 and de-scribe our proposed protocols in Section 3. In Section 4, we analyse the robustness of oursolution against rational and malicious attacks and we show that the charging and reward-ing scheme indeed encourages cooperation in multi-hop cellular networks. In Section 5,we present an estimate of the communication and computation overhead of our protocols.Finally, we describe the related work in Section 6 and we present our conclusions andfuture work in Section 7.

2

2 System model

The essence of our proposal is a set of protocols that encourages the nodes to cooperatein multi-hop cellular networks.

2.1 Assumptions

The system consists of a set ofbase stationsconnected to a high speed backbone and aset ofmobile nodes. The mobile nodes use the base stations and, if necessary, the backboneto communicate with each other. Communication between the mobile nodes and the basestations is based on wireless technology. We assume that all communication is packet-based and that the links are symmetric (i.e., the nodes and the base stations have the samepower range). We also assume that all the base stations and the backbone are operated by asingle operatorthat is fully trusted by all mobile nodes, be it for charging, for route setup,or for packet forwarding.

We call acell [25] the geographical area under the control of a given base station.The power range of the base station is smaller than the radius of the cell, meaning thatsome nodes should rely onmulti-hop relayingto communicate with the base station. Weconsider an ad hoc model in which mobile nodes move. However, we assume that theroutes are stable enough to allow for the sending of a substantial number of packets andthus to amortize the cost of running a (reactive or proactive) routing protocol. We alsoassume that all links are bidirectional.

We assume each nodei to be registered with the operator and to share a long-termsymmetric keyKi with it. Ki is the only long-term cryptographic material stored ini. Thesecret keys of all the nodes in the network are maintained at the operator.

2.2 Rationale of the solution

When a mobile nodeA (the initiator) wants to communicate with another mobile nodeB (the correspondent), it first establishes anend-to-end sessionwith B (as we will see indetail, in Subsection 3.2, a session is a route on which all nodes are authenticated). Thisis done by establishing aninitiator sessionbetweenA and the base station of the initiatorBSA and acorrespondent sessionbetween the base station of the correspondentBSB andB. These sessions are used to exchange packets betweenA andB, in both directions.

3

For each packet, we callS its source (which isA or B) andD its destination (thereforeB or A, respectively). The base stations ofS andD are denoted byBSS andBSD , respec-tively. The packet is then sent by the sourceS to BSS , if necessary in multiple hops. IfDresides in a different cell, then the packet is forwarded byBSS to BSD via the backbone.Finally, the packet is sent toD possibly in multiple hops again1. If one of the routes isbroken, then a new session is established using an alternative route.

Note that the system model described above is similar to that of [25] with the differencethat we requireall communication to pass through a base station. Although this may leadto suboptimal routes, our model has the advantage of significantly reducing the complexityof routing from the nodes’ point of view, since they only have to maintain a single route(to the closest2 base station) instead of one route per potential correspondent. Of course,the base station has to maintain a route to every node in its cell.

In order to motivate the intermediate nodes to forward the traffic, we propose to chargethe initiatorA for the traffic in both directions and reward the forwarding nodes (the op-erator is rewarded as well). We take advantage of the presence of the trusted operatorand assume that it maintains a billing account for every node in the system; our remunera-tion scheme (see Subsection 3.4.1) is implemented by manipulating the appropriate billingaccounts.

Our protocols are based entirely on symmetric key cryptography. Although asymmet-ric cryptographic primitives may seem to be more suitable for implementing some of thefunctions of our scheme, they have a high computational overhead (compared to sym-metric key primitives), which prevents their application in resource constrained mobiledevices.

2.3 Adversarial model

Attacker model: An attackerA is rational if it misbehaves only when this is beneficialin terms of remuneration, service provision or ressource saving. Otherwise,A is malicious(i.e., it misbehaves even if it loses money, energy, . . . by doing so). The users are selfish andthus, each node in the network is potentially an attacker. We assume that several attackerscan collude and share information to perform more sophisticated attacks. We also assumethat an attacker is occasionally able to compromise “good” nodes by retrieving their secretkeys.

1Clearly, the communication ends are not necessarily both wireless. However, in this paper, we assumethat to be the case as this corresponds to the most complete scenario.

2The distance from a given node to the base station can be expressed in termes of number of hops, timeor cost

4

Attack Model: We do not attempt to ensure secrecy or anonymity of communicationand thus, we do not studypassiveattacks (where the attacker records and analyzes theexchanged data without altering them). Instead, we are interested inactiveattacks, wherethe attacker modifies, deletes or injects data in the network. We consider exclusively theattacks performed against the different phases of the proposed protocols and we identifythe following active attacks:

• Packet dropping: A drops a packet it is asked to forward.

• Replay: A replays a valid packet from an expired or still existing session.

• Filtering: A modifies a packet it is asked to forward.

• Emulation: A uses the secret key of a node it compromised to perform actions in itsname.

Secure routing protocol: Securing the routing protocol is beyond the scope of thispaper; several solutions to secure routing in ad hoc networks have been proposed [18, 19,30, 31, 7, 36, 17] and can be used as an underlying routing mechanism in our protocol.Therefore, we will not consider attacks such as abnormally long routes, routing loops,black or gray holes, wormhole attack etc.

Encouraging cooperation:We will show in Subsection 4.1.1 that the packet droppingattack is not rational. This means that cooperation is the best choice for a rational selfishnode.

3 Proposed solution

In this section, we will provide a detailed description of our solution. In particular, wewill describe the protocols of the different phases sketched in Subsection 2.2.

3.1 Building blocks and notation

Our protocols use two cryptographic building blocks: a MAC (Message Authentica-tion Code3) function and a stream cipher [28]. However, our use of these cryptographicprimitives is unconventional:

3Throughout this paper, MAC will stand for Message Authentication Code and not for Medium AccessControl.

5

• During the session setup phase (see Subsection 3.2), we need all the nodes in the pathto authenticate the request message and, instead of appending one MAC computedby each of the nodes to the message, we use an iterative “MAC layering” technique.The principle of this technique is explained in Subsection 3.2. Our solution achievesa similar effect to that of the classical MAC appending technique while keepingthe size of the request constant. Therefore, our technique is more efficient in termsof bandwidth usage. To the best of our knowledge, such a scheme has not beenproposed yet for ad hoc networks.

• During the packet sending phase (see Subsection 3.3), we apply an iterative streamcipher encryption mechanism that can be considered as an “implicit” authenticationmechanism because it allows the operator to verify that the packet took the routeit was supposed to take. At the same time, it thwarts the free-riding attack (seeSubsection 4.1.3).

Notation: We denote the concatenation operator by| and the XOR operator by⊕.

3.2 Session setup

As explained in Section 2, when an initiatorA wants to communicate with a corre-spondentB, it first has to set up anend-to-end session. The goal of the session setupis (i) to test theinitiator route (route betweenA andBSA, containinga relays) and thecorrespondentroute (route betweenBSB andB, containingb relays), obtained from theunderlying secure routing protocol; (ii) to authenticate all nodes belonging to these routes;and (iii) to inform these nodes about the traffic that will follow. A node can decide notto join the session, in which case the session setup fails and a new session is establishedusing an alternative secure route. Successful completion of the session setup phase is aconfirmation that both the initiator and correspondent routes are operational and that allthe intermediate nodes on both routes accept to forward the traffic.

Figure 1: The session setup phase

6

In order to set up a session,A generates an initiator session setup request messageAReq0 that contains a fresh request identifierAReqID (e.g., generated in sequence), thesecureinitiator routeARoute, and some informationTrafficInfo about the traffic to besent4. In addition, the request has a fieldoldASID to carry the session ID of the brokeninitiator session, in case the request is sent to re-establish a broken session. This field is setto zero in case of a new session establishment. Finally,AReq0 contains a MAC computedby A using its secret keyKA:

AReq0 = [ AReqID | oldASID | ARoute | TrafficInfo |MAC KA

(AReqID | oldASID | ARoute | TrafficInfo) ]

Each forwarding nodei (1 ≤ i ≤ a) on the initiator route checks the traffic informationTrafficInfo. If i decides to participate in the forwarding, then it computes a MAC on thewhole message using its own keyKi, replaces the MAC in the request with the newlycomputed MAC, and forwards the requestAReq i to the next hop (or toBSA) where:

AReq i = [ AReqID | oldASID | ARoute | TrafficInfo | MAC Ki(AReq i−1) ]

Thus, when the request arrives toBSA, it contains a single “layered” MAC that wascomputed byA and all the nodes on the initiator route in an iterative manner.BSA thenrepeats all the MAC computations and checks the result against the MAC in the receivedrequest. It also verifies that the request ID is fresh (i.e., the message is not a duplicate)and if the request is sent to re-establish a broken initiator session, it verifies thatoldASIDcorresponds to a valid session identifier previously initiated byA. If one of these verifi-cations is not successful, thenBSA drops the request, otherwise, it sends the request, viathe backbone, to the base stationBSB . BSB generates and sends a correspondent sessionsetup requestBReq0 towardsB:

BReq0 = [ BReqID | oldBSID | BRoute | TrafficInfo ]

whereBReqID is a fresh request identifier generated by the base stationBSB , oldBSIDis the session ID of the broken correspondent session, in case the request is sent to re-establish a broken session andBRoute is the secure correspondent route.

Each forwarding nodej (1 ≤ j ≤ b) on the correspondent route computes and sendsBReq j in the same way as the forwarding nodes in the initiator route did:

BReq j = [ BReqID | oldBSID | BRoute | TrafficInfo | MAC Kj(BReq j−1) ]

4The initiatorA may have no precise information about the trafficB will generate.TrafficInfo is thus anestimate for the expected traffic in both directions. IfA underestimates the traffic, the relaying nodes mightinterrupt the packet forwarding because the amount of data to forward is much larger than expected.

7

WhenB receives the requestBReqb, it returns toBSB a correspondent session setupreply BRep that contains the correspondent request IDBReqID and a MAC that is com-puted over the received requestBReqb (including the MAC therein) using the keyKB ofB:

BRep = [ BReqID | MAC KB(BReqb) ]

The reply is relayed back without any modifications toBSB on the reverse route of therequest.BSB checks the “layered” MAC and if it verifies correctly,BSB informsBSA thatthe session is valid. ThenBSA (respectively,BSB ) sends an initiator (respectively, a cor-respondent) session setup confirmation message towardsA (respectivelyB). The initiatorsession setup confirmation messageAConf contains the initiator request IDAReqID andtwo freshly generated random numbersAUSID andADSID representing the initiator ses-sion IDs to be used for packets sent fromA to BSA and fromBSA to A, respectively. Italso contains a series of MACs where each MAC is intended for one of the nodes on theinitiator route (includingA):

AConf = [ AReqID | AUSID | ADSID | AMAC A | AMAC 1 | . . . | AMAC a ]

AMAC i = MAC Ki(AReqID | AUSID | ADSID | oldASID | ARoute | TrafficInfo)

The correspondent session setup confirmationBConf has a similar structure:

BConf = [ BReqID | BUSID | BDSID | BMAC 1 | . . . | BMAC b | BMAC B ]

BMAC j = MAC Kj(BReqID | BUSID | BDSID | oldBSID | BRoute | TrafficInfo)

Each node on the initiator and correspondent routes (including A and B) verifies itsown AMAC or BMAC and stores the two initiator or correspondent session IDs, respec-tively. The state information related to the established sessions (including session IDs,routes and cryptographic parameters) is stored in the operator’s database. Then, using itssecret keyKi and the session identifier, each nodei involved in the communication gener-ates a session keyK ′

i (e.g.,K ′i = hKi

(SID)) that it will use during the packet sending andthe payment redemption phases. The base stationsBSA andBSB also compute the sessionkeys of all the nodes involved in the communication and save them locally.

The session becomes active for the base stations when they send the confirmation mes-sages and for the nodes when they receive a valid confirmation message. Nodei starts atimer ti when it receives the request message;ti is restarted each timei receives a validmessage or packet that belongs to the session. Nodei closes the session ifti expires; Clos-ing a session means that the node will discard all messages or packets of the session. The

8

nodes and the base stations keep state information in the memory until the acknowledge-ment and (if needed) packet receipts are sent to the operator (see Subsection 3.4).

Note that in case of initiator (respectively, correspondent) session re-establishment, itis not necessary to also re-establish the correspondent (respectively, the initiator) sessionif the latter is still valid. The broken session is re-established using an alternative routeand it is linked to the other (still valid) session in the operator’s database.

3.3 Packet sending

Once the session has been set up,S (which isA or B) starts sending packets toD.

Figure 2: The packet sending phase

The `-th packetSPkt0,` sent byS contains the session IDSSID (which isAUSID ifS = A andBUSID if S = B), the sequence number`, and the payloadPayload `. Italso contains the receiptSRcpt0,` that can be used by the intermediate nodes, if needed,to provide the operator with a proof that they correctly received the packet (details aboutthe computation and the use of the receipts are given in Subsections 3.4.4 and 3.4.1). Inaddition,S computes a MAC on the packet using the session keyK ′

S and encrypts thebody of the packet (including the MAC) by XORing it with the padPADS,`:

SPkt0,` = [ SSID | SRcpt0,` | ` | Body0,` ]

where SRcpt0,` = MAC K′S(SSID | `)

and Body0,` = PADS,` ⊕ [ Payload ` | MAC K′S(SSID | ` | Payload `) ]

The padsPAD i,` are generated by nodei (i = S for the source) as follows (see Figure3): the session IDSSID (DSID for the down-stream nodes) andK ′

i are used as a seedto initialize the key stream generator of the stream cipher. Then,PAD i,` is chosen as the`-th block of lengthMaxLength of the generated key stream, whereMaxLength denotesthe maximum allowed length of packets in bytes. If the lengthL` of the packet to beencrypted is smaller thanMaxLength, then only the lastL` bytes ofPAD i,` are used, therest ofPAD i,` is thrown away.

9

Figure 3: Encryption of the packets

The nodei in the up-stream route (route betweenS andBSS ) verifies that the packetis not a duplicate, updates (and stores) the receiptSRcpt i,` and encrypts the body of thepacket using the padPAD i,`:

SPkt i,` = [ SSID | SRcpt i,` | ` | Body i,` ]

where SRcpt i,` = MAC K′i(SSID | SRcpt i−1,`)

and Body i,` = PAD i,` ⊕ Body i−1,`

WhenBSS receives the packet, it retrieves the session keys of the nodes on the up-stream route, recomputes the pads and removes all encryptions from the packet. Then, itchecks the MAC and checks that the packet is not a duplicate. If one of these verificationsis not successful, then it drops the packet. Otherwise, it forwards it5 to the base station ofthe destinationBSD . BSD changes the up-stream session ID to the corresponding down-stream session IDDSID (which isBDSID if S = A andADSID if S = B), computesa new MAC forD, computes the padPAD j,` for each nodej on the down-stream route(route betweenBSD andD), includingD, and encrypts the packet (including the MAC)by iteratively XORing it with all these pads. The result is:

DPkt0,` = [ DSID | ` | Body0,` ] where

Body0,` = PAD1,` . . .⊕ PADd,` ⊕⊕PADD,` ⊕ [ Payload ` | MAC K′D(DSID | ` | Payload `) ]

BSD storesMAC K′D(DSID | ` | Payload `) of every packet it sends together with the

sequence number` in order to be able to verify future destination acknowledgements andpacket receipts. Note that for the down-stream, we do not need to add a field dedicatedto the receipt. Upon reception ofDPkt j−1,`, each nodej computes and stores the receipt

5The packet is forwarded only if it is a data packet. The treatment of up-stream acknowledgement packetsis presented in Subsection 3.4.2.

10

DRcpt j,` for the packet (as explained in Subsection 3.4.4), decrypts the body ofDPkt j−1,`

by XORing it with the padPAD j,`, and forwards the resultDPkt j,` to the next hop where:

DPkt j,` = [ DSID | ` | Body j,` ]

where Body j,` = PAD j,` ⊕ Body j−1,`

When the packet reachesD, it removes the remaining encryption pad by XORing thepacket withPADD,`. D can then verify the validity of the MAC generated byBSD andstore the MAC and for the generation of the acknowledgement (see Subsection 3.4.2).

3.4 Payment Redemption

3.4.1 Charging

As we have already mentioned in Subsection 2.2, charging and remuneration are per-formed by the network operator, by manipulating the accounts of the nodes. WhenBSS

receives the packetPkt` of lengthL` sent by the sourceS, the initiatorA is charged agiven amountn(L`) (depending on the packet size) and the up-stream forwarding nodesare creditedα(L`). The down-stream forwarding nodes are credited whenPkt` is ac-knowledged byD (see Subsection 3.4.2) because the operator may have no other reliableinformation about the delivery of the packet. The only motivation forD for not sendingthe acknowledgement is to save resources. In order to discourage this misbehavior,Dis charged a small amountε whenBSD injectsPkt` in the down-stream route and reim-bursed whenPkt` is acknowledged. Note that, as the operator cannot distinguish betweena packet loss and the case whereD does not want to send the acknowledgment, it cashesthe chargeε if no acknowledgement arrives for the packetPkt`.

If the packet is dropped or lost in the up-stream route, the nodes that relayed it canpresent the receipt for this packet (see Subsection 3.4.4) to the operator. The operatoridentifies the last nodek (1 ≤ k ≤ u) in the path who sent a valid receipt for the packet andgives it a rewardβ(Lmin) whereas the nodes that are beforek in the path receive a rewardα(Lmin), whereLmin denotes the minimum length of a packet6. A is chargedn′(Lmin) =(k − 1).α(Lmin) + β(Lmin). Receivingβ(Lmin) can be perceived byk as its reward forinforming the operator that the nodes1 to k − 1 in the path behaved properly. Theβ-reward should be sufficiently large to strongly counterbalance the costc of forwarding the

6The packet did not reach the base station, so the operator has no idea about its real length. We chooseto give a reward equivalent to the one a node gets when it forwards the shortest possible packet in order toavoid that a forwarding node drops short packets it is asked to forward in order to get higher reward.

11

packet and the costc′ of maintaining and sending the receipt (β � c andβ � c′). Notethatα should be substantially larger thanβ to prevent nodes from systematically droppingpackets (α � β).

If the packet is dropped or lost in the down-stream route, the nodes that relayed it arerewarded in a similar way as for the up-stream forwarding nodes, except forα(Lmin) andβ(Lmin) that are replaced byα(L`) andβ(L`), respectively, because the operator receivedthe packet and knows its real lengthL`. The initiatorA is fully chargedn(L`).

Note that the charges and rewards depend only on the packet size and not on the numberof forwarding nodes in the path. The operator will then take a loss for long routes but willmake a profit from short routes. The charges and rewards should thus be set so that –relative to the average path length – the operator makes the desired profit on average.

3.4.2 Destination acknowledgement

The destinationD must acknowledge every packet it correctly receives. However, inorder to save resources, it does not send acknowledgements on a per packet basis. Instead,the session is subdivided into “time periods7” and the packets received during each periodare acknowledged in a single batch. The acknowledgmentDAck t of the t-th time periodof the session is formatted as the payload of a regular packet8 and sent byD via the down-stream route toBSD, some time during thet+1-th time period (e.g., at a randomly chosenmoment). The body of the acknowledgment packet is:

DAck t = [ DBatcht | DFirstPkt t | DLastPkt t | DLostPkts t |MAC K′

D(DBatcht | DFirstPkt t | DLastPkt t | DLostPkts t) ]

whereDFirstPkt t andDLastPkt t are the sequence numbers of, respectively, the first andthe last received packets during thet-th time period,DLostPkts t is the list of sequencenumbers of the missing packets betweenDFirstPkt t andDLastPkt t and

DBatcht =⊕

DFirstPktt≤`≤DLastPktt; ` 6∈DLostPktst

MAC K′D(DSID | ` | Payload `)

whereMAC K′D(DSID | ` | Payload `) is the MAC received in the packetPkt `.

The packet is forwarded as a regular packet of the session. WhenBSD receives it,the packet is decrypted and identified as being an acknowledgement. Then,BSD verifies

7We suppose that the nodes are at least loosely synchronized with their base station.8It is necessary to be able to differentiate between a data packet and an acknowledgement (e.g., by using

a flag bit)

12

the MAC and checksDBatcht by XORing all the MACs of the packets fromDFirstPkt t

to DLastPkt t, excluding those inDLostPkts t and comparing the result with the receivedvalue. If the verification fails, thenBSD ignores the acknowledgement. IfBSD does notreceiveDAck t during thet + 1-th time period or if the throughput is not satisfactory (i.e.,too many lost packets), an alternative route is used to establish a new session.

3.4.3 Up-stream acknowledgment

To attenuate the effect of several malicious attacks (see Section 4), the base stationBSS sends a single acknowledgmentUAck t to S for all the packets it received during thet-th time period of the session.UAck t is sent in a regular packet and its format is similarto the format ofDAck t, except that the base station does not have to provide aBatch-likeproof to the source:

UAck t = [ UFirstPkt t | ULastPkt t | ULostPkts t |MAC K′

S(UFirstPkt t | ULastPkt t | UDLostPkts t) ]

WhenS receivesUAck t, it identifies it as being an acknowledgement and checks itsvalidity by verifying its MAC. S can choose to re-establish the session toBSS using analternative route if no acknowledgement arrives for a given time period or if the throughputis unsatisfactory.

3.4.4 Packet receipts

The concept of receipt we use in this paper is similar to the one used in [37]. It does notrepresent a proof that the node forwarded the packet but rather that it received it correctly.As we will see in Subsection 4.1.1, the use of the receipts helps to make packet forwardingrational.

For an up-stream forwarding nodei, the receiptSRcpt i,` for the packetPkt` is senttogether with the payload and it is computed as explained in Subsection 3.3. We need afield dedicated to the receipt in the up-stream part of the communication, because if a partof the packet is used to compute the receipt,BSS has no way to verify it in case of packetloss, which is the very purpose of the receipts.

For a down-stream forwarding nodej, the receiptDRcpt j,` is computed as follows:

DRcpt j,` = MAC K′j(DSID | Mj,`)

13

whereMj,` represents the MAC part of the packetDPkt j,` (i.e., if the MAC is encodedon 16 bytes, thenMj,` represents the last 16 bytes of the packetDPkt j,`). It is possiblefor the operator to verify the receipts because it stores the MACs of the packets (they arealso used to compute/verify the destination acknowledgements) and because we use thelast bytes of the padsPAD j,` to encrypt and decrypt the packets.

In order to save memory space, both up- and down-stream forwarding nodes do notstore the receipts for each packet but rather for a whole session; the forwarding nodeistores abatchfor each session it is involved in as a forwarding node:

BatchSID,i =⊕

`≤LastPkt ; ` 6∈LostPkts

Rcpt i,`

whereLastPkt is the sequence number of the last packet received so far andLostPkts isthe set of the sequence numbers of missing packets precedingLastPkt .

Note that for a node in the initiator route,AUSID andADSID correspond to twodistinct sessions. When a given session is closed and the last destination acknowledgementis sent, the operator informs the forwarding nodes involved in the communication aboutthe rewards they received (typically when the node is within the power range of a basestation). If a nodei forwarded a packetPkt` and was not paid for it,i sends the receipt tothe operator. If the receipt is valid, the node is rewarded as explained in Subsection 3.4.1.A node can ask for remuneration (by sending the receipt) even if it did not provide theservice. Note that a single receipt is sent to ask remuneration for several packets.

The format of the packet receipt sent to the operator is the following:

RcptSID,i = [ SID | BatchSID,i | LastPkt | LostPkts |MAC K′

i(SID | BatchSID,i | LastPkt | LostPkts) ]

Upon reception of this message, the operator verifies the MAC and if the verification ispositive, it remunerates the node according to the charging scheme (see Subsection 3.4.1).

4 Security Analysis

In this Section, we study the robustness of our protocols against the attacks identifiedin Subsection 2.3. In Subsection 4.1, We consider the detection of these attacks and weshow that none of them is rational. Then, in Subsection 4.2, we describe how to identifythe malicious attacker. Finally, in Subsection 4.3, we present and analyse some hybridattacks.

14

Note that we do not consider attacks against the routing protocol or denial of service(DoS) attacks based, for example, on jamming.

4.1 Detection of the attacks

4.1.1 Packet dropping

In this attack, an attackerA that is part of the end-to-end route betweenS and Ddecides to drop a packet it is asked to forward. In this paragraph, we consider the effectof the attack on the different phases of our protocols and we show that this attack is notrational. This result is interesting, particularly for the packet sending phase, because itproves that our solution fosters cooperation.

Session setup phase:A can drop one or several of the following messages:

• The request message: the sender of the request (which isA or BSB) would notreceive the confirmation or the reply message, respectively. It would then establisha new session to the target (BSA andB, respectively) using an alternative route.Note that dropping the request message is not necessarily an attack because theforwarding nodes can decide not to participate in a given session.

• The reply message:BSB would never receive the reply and the correspondent ses-sion setup would fail.BSB would then use another route to establish the correspon-dent session.

• The confirmation message: some of the nodes involved in the communication wouldnot be aware of the establishment of the session. If the initiatorA is the source ofthe first packet to be sent during the session, we can have two cases: (i)A is in theinitiator route, thereforeA would not receive the confirmation message and wouldconsider that the session setup failed; It would then establish a new session usinganother route. (ii)A is in the correspondent route; The session would be active forall the nodes, except for those that are afterA in the correspondent route (includingB); These nodes would thus discard all the packets sent byA during the session.The destination (which isB in this case) would not be able to send the periodicacknowledgment toBSB and the session would be re-established.

The problem is totally symmetric ifB is the source of the first packet of the session.In both cases, this attack is not rational and can be detected rapidly by the operator.

15

Packet sending phase:In this paragraph, we show that denying to forward packets isnot rational; cooperation is thus the best choice for a selfish, rational node.

Proposition 1 If a nodei received a packetPkt` to forward and if, later on,Pkt` wasnot acknowledged by the target (BSS for the up-stream andD for the down-stream), thenit is rational for i, once the session is closed, to send a receipt forPkt` to the networkoperator.

Proof: As explained in Subsection 3.4.2, after a given session is closed, the operatorinforms the forwarding nodes involved in that session about the rewards they received. Ifa nodei correctly forwarded (or simply received) a packetPkt` and was not paid for it,ican send a receipt for it.

Sending a receiptRcpt of lengthLRcpt (see Section 5 for numerical values) representsa cost ofc′/NumPkts per packet, whereNumPkts denotes the number of packets receivedby i during the session andc′ denotes the cost of sendingRcpt . Given the assumption ofroute stability (see Subsection 2.1), it is possible to neglectc′/NumPkts in comparisonwith c (and thus in comparison withα andβ) becauseNumPkts is large.

If i decides not to send a receipt forPkt` or if it sends an invalid receipt, then its payoffis:

• 0 if i droppedPkt` during the packet sending phase,

• −c if it forwardedPkt` but none of the following nodes sent a valid receipt for it,

• α − c if it forwarded the packet and at least one of the following nodes in the pathsent a valid receipt for the packet.

If i sends a valid receipt forPkt`, then its payoff is:

• β if i droppedPkt` during the packet sending phase,

• β− c if it forwardedPkt` but none of the following nodes sent a valid receipt for it,

• α − c if it forwarded the packet and at least one of the following nodes in the pathsent a valid receipt for the packet.

Given that (i) a forwarding node cannot know if the receipt is valid or not beforesending it to the operator, (ii) the cost of sending the receipt is negligible and (iii)α �β � c, we can state that sending the receipt is rational.2

16

Proposition 2 If all the nodes involved in the communication are rational, then forward-ing the packetPkt` is rational for nodei.

Proof: As we will show in Subsection 4.1.3, the filtering attack is malicious. Thenodes involved in the communication being rational, they will not perform this attack onthe packets they are asked to forward and thus the receipts produced by the intermediatenodes would be correct.

If node i decides to defect and drops a packetPkt` it is asked to forward,i will stillsend a receipt forPkt` since, according to Proposition 1, this is the rational behavior. Thepayoff of i would then beβ.

If i decides to cooperate, then:

• if Pkt` reaches its target, then the payoff ofi would beα− c,

• if on the contraryPkt` does not reach its target, then at least one nodej (j > i)would send a receipt for it (according to Proposition 1) and the payoff ofi wouldalso beα− c.

As we haveα � β � c, cooperation is rational for nodei. 2

Proposition 3 If the route contains an attacker that repeatedly drops the packetPkt`,then the network operator can identify it.

Proof: As long asPkt` is relayed by rational nodes, the packet is computed and cor-rectly forwarded until it reaches the malicious nodeA that drops it. The rational nodesthat are beforeA in the path will then send valid receipts forPkt` (according to Proposi-tion 1). The operator would identify the last nodek in the path that sent a valid receipt,which isA or the rational node that is before it on the route (becauseA is also able togenerate a valid receipt for the packet). The operator would then suspect bothk andk + 1of misbehavior. By crosschecking the information about different sessions and identifyingthe nodes that are suspected significantly more than average, the operator can identify theattacker and punish it in consequence. Note that ifA performs this attack only few times,then the detection would be slower but the attack would be less harmful.2

Proposition 4 Forwarding the packetPkt` is rational for nodei even if an attackerAwill drop it later on.

17

Proof: Node i has no information about whether the nodes after it in the path arerational or not. If it expects all of them to be rational, then the best choice fori is tocooperate (according to Proposition 2). If it expects nodei+1 to be rational, then the bestchoice fori is to cooperate (its payoff would beα− c because according to Proposition 1,i + 1 would send a receipt for the packet). Finally, if it expects nodei + 1 to be maliciousand drop the packet, then the best choice fori is also to cooperate because otherwise theoperator would eventually believe it is malicious (according to Proposition 3) and wouldpunish it.2

Payment redemption phase:The acknowledgement is encapsulated in a regular packetand the body is encrypted by all the nodes in the path, including the generator of the ac-knowledgement. An attackerA has thus no way to distinguish a packet containing anacknowledgement from a data packet9. A brute force attack would be forA, in order tospecifically drop thet-th acknowledgement, to drop all the packets sent during thet+1-thtime period. The consequence of this attack would be the re-establishment of the sessionusing another route.

4.1.2 Replay attack

We will consider that a replay attack performed by an attackerA is successful if thereplayed message or packet is considered as valid byall the parties involved in the com-munication (including the operator). Note thatA is not necessarily part of the network.

Session setup phase:The operator maintains the information about all the sessionsestablished so far. The replayed message (request, reply or confirmation) would thus bedetected by the first base station that receives it.

However, a detection at the nodes is also possible. Indeed, when a nodei receives areplayed request message, it can identify it as a duplicate (and discard it) if:

• i is not part of the route in the request

• or the session to be established is already active or it is closed but still in memory10

• or i is supposed to be the initiator of the communication

9It is possible for the attacker to identify the acknowledgement packet if it has a fixed and predefinedlength. If we want to remedy this, the generator of the acknowledgement should insert some padding.

10The mobile nodes do not keep trace of all the messages and packets they received. Rather, they maintaina short-term history (i.e., on-going sessions and session that are not acknowledged yet).

18

Packet sending phase:As for the session setup phase, the duplicate is detected by thefirst base station that receives it. But here, the intermediate nodes are also able to detectit. Indeed, each forwarding node maintains the list of all packets it has received so far (forthe computation of the receipt, see Subsection 3.4.4). The sequence number of the packetto forward would then correspond to the identifier of an already handled packet and theduplicate would be discarded.

Payment redemption phase:The operator maintains the list of all acknowledgementsand receipts it receives and can thus detect (and discard) a replayed message. Further-more, as explained in Subsection 4.1.1, it is difficult to identify the packets containing theacknowledgements and thus to replay them specifically.

4.1.3 Filtering attack

An attackerA that performs a filtering attack modifies one or several fields of thepacket it is asked to forward. In this Subsection, we will analyse the effect of this attackon our protocols. We also consider thefree-ridingattack where two colludersA1 andA2

on the end-to-end route attempt to piggyback data (using appending or substitution) on theexchanged packets, with the goal of not having to pay for the communication.

Session setup phase:A can tamper with:

• The request or the reply messages: the verification of the “layered” MAC will failand the base station (BSA or BSB) will discard the message. A new session willthen be established using an alternative route.

• The confirmation message: the first node that will receive the tampered messagewill discard it because the verification of the MAC will fail. IfA tampers with one(or more) MAC(s) in the message, the first node whose MAC was modified and thatwill receive the message will discard it. This attack has the same effect as droppingthe confirmation message (see Subsection 4.1.1) and is detected in the same way.

The fields of the session setup messages are not encrypted. It is then possible for twocolludersA1 andA2 to piggyback information. However, the size of fields is small enoughto make the sending of useful data very long and fastidious.

Packet sending phase:A can tamper with the different fields of the packetPkt `.

• Modifying SID , ` or Body i,` would be detected by the target of the packet (BSS

for the up-stream andD for the down-stream) because the “layered” MAC does notverify correctly.

19

• We hereafter define theearly duplicateattack, a malicious attack whereA createsa fake packet with a sequence number` that it expects to be used by the legitimatesource in the (near) future. This packet is handled as valid by the intermediate nodes(because they cannot verify it) but it is discarded at the target because the MAC isnot correct. However, when the source sends the “real”`-th packet, the forwardingnodes would consider it as a duplicate and thus would discard it.

Our protocols, as presented so far, are vulnerable to theearly duplicateattack. If theoperator wants to attenuate the effect of this subtle attack, it can do so (at the cost ofa small overhead) by making use of hash chains11. The details of the solution are inAppendix A

• The free-riding attack is not rational during the packet sending phase. Indeed, thedata sent byA1 cannot be interpreted byA2 because it was encrypted at least by oneintermediate node12. If this attack is performed anyway, it is detected as a “regular”filtering or packet dropping attack (depending whetherA2 forwarded the tamperedpacket or not).

• Modifying only the receipt in the up-stream packets (there is no field dedicated toreceipts in the down-stream packets) is a malicious attack. If the base stationBSS

detects such an attack (the packet is correct but the receipt is not), then it should re-establish the session (ifS = B) or ask the initiator to do it (ifS = A). Such a radicalsolution is needed because, as explained in Subsection 3.4.4, the nodes maintain onebatch per session by XORing all the receipts of the packets they handled. If one ofthese receipts is incorrect, then the batch is incorrect and the receipt will not verifycorrectly at the operator.

• The attackerA can tamper with the packet it is asked to forward but without alteringthe fields used by the intermediate nodes to generate the receipts. The followingnodes in the route would forward the modified packet. When the target (BSS or D)receives it, it detects the attack and re-establishes the session.

Payment redemption phase:The same analysis as for the packet dropping attackduring the payment redemption phase holds.

11A hash chain is a chain ofN hash values wherewN−i = h(wN−i+1)(0 < i ≤ N ) andh is an unkeyedone-way hash function.

12Having two colluding nodes that are neighbors and that perform the free-riding attack makes no sensebecause they can communicate directly with each other.

20

4.1.4 Emulation attack

This attack is equivalent to the cloning of a SIM card in a GSM network. It is detectedin the same way.

4.2 Identification of the attackers

In this paragraph, we give an idea about how the operator can identify an attackerAthat performed one of the four attacks analyzed in Subsection 4.1.

Packet dropping attack

• Session setup phase: As explained in Subsection 4.1.1, dropping the request mes-sage is not considered as an attack, so there is no need for the operator to identifythe “misbehaving” node. The same reasoning can be applied to the dropping of thereply message because the operator cannot distinguish it from the dropping of therequest message. If the attackerA drops the confirmation message, it can be identi-fied in the same way as for the dropping of a packet during the packet sending phase(see the proof of the Proposition 3). Note that the effect of this last attack lasts fortwo time periods at most.

• Packet sending phase: If A repeatedly drops packets it is asked to forward, it can beidentified as explained in the proof of Proposition 3.

• Payment redemption phase: As explained in Subsection 4.1.1, this attack is ineffi-cient and thus there is no need to identify the attacker.

Replay attacks

As explained in Subsection 4.1.2, this attack is inefficient.

Filtering attack

• Session setup phase: As for the packet dropping attack, an attackerA that tam-pers with the request message or the reply message causes the re-establishment ofthe session using an alternative route. However, the operator may want to iden-tify A because, contrarily to the packet dropping attack that is part of the decisionmaking of the nodes, tampering with one of these messages before forwarding itis purely malicious. Details about the statistical identification of the attacker are inAppendix B. Tampering with the confirmation message is equivalent to the packetdropping attack andA can be identified in the same way.

21

• Packet sending phase: If A tampers with a packetPkt `, we can have one of thefollowing cases:

– A tampers with one of the fields used by the intermediate nodes to generatethe receipts (SSID or ` for the up-stream andDSID , ` or Body j,` for the downstream). The attackerA can be identified as explained in Appendix C.

– Theearly duplicateattack can be performed by an attacker that is not even partof the network. However, if the solution proposed in Appendix A is applied,the attack becomes inefficient.

– In Subsection 4.1.3, we proved that thefree-ridingattack is malicious. How-ever, if two colludersA1 andA2 decide to perform it anyway,A1 can be iden-tified as explained in Appendix C (the case where the packet is dropped byA2

is presented in Subsection 4.3).

– An attackerA that modifies only the receipt field in an up-stream packet canbe identified by the operator as explained in Appendix C.

– An attackerA that modifies a packet without altering the information used togenerate the receipts can be statistically identified by the operator as explainedin Appendix B.

• Payment redemption phase: As explained in Subsection 4.1.3, this attack is ineffi-cient.

Emulation attack

The emulation attack can be detected by the operator if the compromised node seamsto be in two different locations at the same time (e.g., in two non-adjacent cells). Note herethat the operator does not identify the attacker but the compromised node. As the operatorcannot distinguish between the emulation attack and the case where colluders exchangedtheir secret information, it is reasonable to assume that the operator will give the nodethe benefit of the doubt and change its secret key. However, if the same problem happensagain, the legitimate subscriber becomes suspect and the operator can decide to terminateits contract and to exclude it definitely from the network.

4.3 Hybrid attacks

So far, we analyzed the effect of each of the four active attacks we identified in Sub-section 2.3. However, more sophisticated attacks can combine two or more of the attacks

22

described so far. We cannot list all the possible cases, so we will focus on one particularcombination of attacks: the filtering and the packet dropping attacks.

A basic example of this kind of attacks is the following: two colludersA1 andA2

are on the same route and perform the filtering attack and the packet dropping attack,respectively.

• If the filtering attack does not modify the information needed by the intermediatenodes to compute the receipts, the operator would detect a “regular” packet droppingattack and would identifyA2 as being the attacker (see the proof of Proposition 3).

• If, on the contrary, the nodes that are betweenA1 andA2 are not able to generatevalid receipts, thenA1 will be identified by the operator as an attacker that performeda filtering attack (see Subsection 4.2).

The same reasoning can be applied to the case where we have more than two colluders.

5 Overhead

In this section, we will estimate the communication and computation overheads of thesolution we have described. Reasonable values of the size of the different fields appearingin our protocol are provided in Table 1.NbFwdrsis the number of forwarding nodes on theroute (up-stream or down-stream),` is the sequence number of the packet andNbLostPktsis the number of packets lost during the session or the time period.

Field Name ReqID SID Route TrafficInfo MAC ` Receipt LostPktsSize (bytes) 4 4 NbFwdrs*16 16 16 2 1 NbLostPkts*2

Table 1: Size of the fields used in our protocol (for both up and down streams)

The request ID and the session IDs are encoded on 4 bytes each to reduce the riskof using the same identifier for two different requests or sessions. The fieldRouteis theconcatenation of the 16 byte identifiers (assuming e.g. an IPv6 format) of the nodes. TheTrafficInfofield is used to inform the forwarding nodes about the traffic to be generated;using 16 bytes to encode it seems to be reasonable. Finally, we encode` on 2 bytes tosupport long sessions andReceipton only 1 byte because its computation and storageshould be lightweight.

23

5.1 Communication overhead

Session Setup Phase:According to Table 1, establishing an end-to-end session withNbFwdrs forwarding nodes (in each of the routes) represents an overhead of156 +NbFwdrs ∗ 64 bytes.

The session setup overhead is directly related to the lifetime of the sessions, which, inturn, very much depends on the stability of the routes.

In order to estimate this overhead, we conducted a set of 100 simulations with a net-work of 100 nodes and one base station. The nodes are randomly laid out on a 500x500 m2

single cell13 and the base station is situated in the center of the cell. We fix the power rangeof the nodes and the base station to 100 m.

We use the random waypoint mobility model [22] and we discard the first 1000 secondsof simulation time to remove the initial transient phase [10]. The speed is uniformlychosen between 3 and 23 m/s [34], which corresponds to an average speed of 10.56 m/s att = 1000 s. The pause time is 0 s.

In our simulations we are interested in the average lifetime of a route (AvrLT) andthe average number of forwarding nodes (NbFwdrs). After the initial transient phase ofeach simulation, we randomly choose a node that has a route to the local base stationand we observe the lifetime of this route. The simulation ends when the route is broken(i.e., at least one link is broken).AvrLT represents the average value of all these lifetimevalues over the 100 simulations. Note that we consider the route on only one side ofthe communication (the initiator or the correspondent route) and not the end-to-end route.NbFwdrs is computed for the node we consider for theAvrLT. We do not expect thisnumber to be large for multi-hop cellular networks.

The results are the following: the route remains stable for an average ofAvrLT = 6.58 s(±1.66 s with 95% confidence interval), with an average number of forwarding nodes ofNbFwdrs= 1.36. In order to estimate the amount of information that a node can sendduring this period of time, we consider the case where the nodes are running aVoice overIP application using a G.711 Codec (Rate = 64 kbit/s) with a frame size (including theheaders) of 200 bytes [12]. It is possible during 6.58 s to send 52.64 kbytes of data.

Using the numbers of Table 1, we estimate the overhead of the end-to-end sessionsetup, with the protocol proposed here, to be around 243 bytes,which represents less than0.5% of the payload. Moreover, as explained in Subsection 3.2, it is possible to re-establishonly the broken initiator or correspondent session, which reduces this overhead.

13The shape of the simulated cell is therefore a square; in fact, the specific shape does not significantlyaffect the results of the presented simulations.

24

The presence of one (or more) active malicious attackers in the end-to-end route canalso lead to a session re-establishment (see Section 4). However, if the attacks are repeatedoften, the operator can collect information about the problematic sessions, identify thesuspected nodes and statistically identify the attacker(s) (details about the detection are in[4]). Identifying and punishing the attackers can represent a disincentive to cheat.

Packet Sending Phase:Considering the field sizes of Table 1, we can see that thepacket sending phase represents an overhead of 23 bytes for up-stream packets and 22 bytesfor down-stream packets. If the packet size is 200 bytes (considering again the VoIP exam-ple), the overhead represents at most 11.5% of the packet size. This overhead is reduced ifwe use larger packets. An additional (and substantial) reduction of the overhead consistsin combining the protocol we propose here with the routing protocol.

Sending the Acknowledgment:The destination acknowledgement and the up-streamacknowledgement are generated each time period and their sizes are 36+2*NbLostPkts t bytesand 20+2*NbLostPkts t bytes, respectively. The receiptRcptSID,i is a 23+2*NbLostPkts bytesmessage that the nodei sends directly (i.e., without relaying) to the operator once per ses-sion. We expect the number of packets lost to be small in both cases (i.e., acknowledge-ment and receipt) otherwise, as explained in 3.4.2 and 3.4.3, the session is re-establishedbecause the throughput is not satisfactory.

5.2 Computation overhead

In this subsection, we consider the computation overhead for the mobile nodes. Theoverhead is expressed in terms of battery consumption and number of computations. How-ever, as shown in [32], we can consider the battery consumption due to cryptographiccomputations as negligible compared to the energy needed for data transmission.

Session Setup Phase:This operation requires all the nodes to perform 1 MAC com-putation and 1 MAC verification each.

Packet Sending Phase:The main overhead in this phase is represented by the usage ofstream cipher encryption (performed by the source and all the forwarders), which ensuresthe authentication of the nodes involved in the communication and prevents the free ridingattack. But stream ciphers are very fast, and some operate at a speed comparable to that of32 bit CRC computation [15]. Moreover, for each packet, the source has to perform oneMAC computation and the destination has to perform one MAC verification.

Acknowledgment computation: For the destination acknowledgement,D performsone MAC computation/time period and one XOR operation/packet. For the up-stream ac-knowledgement,S performs one MAC verification/time period. Finally, for the receipts,

25

each forwarding node performs one MAC computation/time period and one XOR opera-tion/packet.

Numerical example: As an example, a Celeron 850 MHz processor under Windows2000 SP can perform a MAC computation (and verification) with HMAC/MD5 algorithmat 99.863 Mbytes/s and a stream cipher encryption (and decryption) using Panama Cipher(little endian) algorithm at 120.301 Mbytes/s [15]. These speeds are to exemplify therange; if slower (or faster) processors are used, it would of course scale correspondingly.

6 Related work

In this section, we discuss some research efforts related to the issues of the cooperation ofnodes in (pure) ad hoc networks and in multi-hop cellular networks.

Cooperation in multi-hop cellular networks: In [24], Lamparter et al. propose acharging scheme to encourage cooperation in hybrid networks (i.e., mobile ad hoc net-works with access to the Internet, which they call “stub ad hoc networks”). They assumethe existence of an Internet Service Provider that authenticates the nodes involved in agiven communication and takes care of charging or rewarding them. However, [24] andour current approach present two main differences. First of all, in [24], the authors analysethe robustness of their solution only against rational attacks, whereas in our proposal weconsider malicious attacks as well. The second difference is that the cryptographic func-tions used in [24] are based on public-key cryptography, whereas our solution is basedentirely on symmetric key cryptography, which is more suitable for resource constrainedmobile devices.

In [21], we have proposed a micro-payment scheme for multi-hop cellular networksthat encourages collaboration in packet forwarding. However, our current proposal signif-icantly differs from [21] in many aspects. First of all, in [21], we assume an asymmetriccommunication model, where the up-stream communication is potentially multi-hop andthe down-stream communication isalwayssingle-hop, whereas in this paper, both the up-stream and the down-stream communications are potentially multi-hop. Second, in [21],the nodes report a fraction of their packet forwarding actions (on a probabilistic basis) toan accounting center that determines how the nodes are remunerated. The approach wepropose does not rely on reports; instead, we use the concept of session during whicheach forwarding node authenticates itself to the base station by altering the packet to beforwarded in a specific way. Finally, the protocol proposed in [21] includes routing deci-sions, whereas the protocols that we propose in this paper are independent of routing.

26

Cooperation in ad hoc networks: Several research groups have considered the prob-lem of selfishness and the stimulation of cooperation in mobile ad hoc networks. In [27],Marti et al. consider the case where a node agrees to cooperate but fails to do so. Their so-lution uses a “watchdog” mechanism to identify the misbehaving nodes and a “pathrater”mechanism to construct routes that avoid those nodes. Both the CONFIDANT [6] and theCORE [29] approaches propose a reputation based solution to identify and punish misbe-having nodes. In [37], Zhong et al. rely on a central authority that collects receipts fromthe forwarding nodes and charges/rewards the nodes based on these receipts. In [8, 9],Buttyan and Hubaux use a virtual currency (nuglets) to charge/reward the packet forward-ing service provision in ad hoc networks.

7 Conclusion

In this paper, we proposed a set of protocols that fosters cooperation for the packetforwarding service in multi-hop cellular networks. Our solution is based on the chargingand rewarding of the nodes and relies exclusively on symmetric cryptography techniquesto comply with the limited resources of most mobile stations. We have used the conceptof sessions which takes advantage of the relative stability of routes and we have shownthat our scheme stimulates cooperation in multi-hop cellular networks. Finally, we haveanalyzed the robustness of our protocols against rational and malicious attacks and haveshown that our solution thwarts rational attacks and detects malicious attacks.

As future work, we intend to extend our protocols to include routing misbehavior. Wewill consider techniques that aim at the calibration of the relevant parameters, and studythe reaction of the network to sophisticated attacks (e.g., by means of simulations). Wewill also explore further the statistical detection, at the operator, of malicious attacks andwe will study the case where several operators exist in the network.

References

[1] G. N. Aggelou and R. Tafazolli. On the Relaying Capacity of Next-Generation GSMCellular Networks.IEEE Personal Communications, February 2001.

[2] Y. Bejerano. Efficient Integration of Multi-Hop Wireless and Wired Networks withQoS Constraints. InProceedings of Mobicom, pages 215–226. ACM Press, Septem-ber 2002.

27

[3] N. Ben Salem, L. Buttyan, J.-P. Hubaux, and M. Jakobsson. A Charging and Reward-ing Scheme for Packet Forwarding in Multi-hop Cellular Networks. InProceedingsof MobiHOC, Annapolis, USA, 2003.

[4] N. Ben Salem, L. Buttyan, J.-P. Hubaux, and M. Jakobsson. Cooperation in Multi-hop Cellular Networks with Extended Security Analysis. Technical report, EPFL-CI-LCA, July 2003.

[5] L. Blazevic, L. Buttyan, S. Capkun, S. Giordano, J.-P. Hubaux, and J.-Y. Le Boudec.Self-Organization in Mobile Ad-Hoc Networks: the Approach of Terminodes.IEEECommunications Magazine, 39(6), June 2001.

[6] S. Buchegger and J.-Y. Le Boudec. Performance Analysis of the CONFIDANT Pro-tocol: Cooperation Of Nodes - Fairness In Distributed Ad Hoc NeTworks. InPro-ceedings of MobiHOC, Lausanne, CH, June 2002.

[7] L. Buttyan and J.-P. H. (Eds). Report on a Working Session on Security in WirelessAd Hoc Networks.ACM Mobile Computing and Communications Review (MC2R),October 2002.

[8] L. Buttyan and J.-P. Hubaux. Enforcing Service Availability in Mobile Ad HocWANs. In Proceedings of MobiHOC, Boston, MA, USA, August 2000.

[9] L. Buttyan and J.-P. Hubaux. Stimulating Cooperation in Self-Organizing MobileAd Hoc Networks.ACM/Kluwer Mobile Networks and Applications (MONET), 8(5),October 2003.

[10] T. Camp, J. Boleng, and V. Davies. A Survey of Mobility Models for Ad Hoc Net-work Research.Wireless Communication and Mobile Computing (WCMC): Specialissue on Mobile Ad Hoc Networking: Research, Trends and Applications, 2(5):483–502, 2002.

[11] D. Coppersmith and M. Jakobsson. Almost Optimal Hash Sequence Traversal. InProceedings of Financial Cryptography, 2002.

[12] B. Goode. Voice Over Internet Protocol (VoIP).Proceedings of the IEEE, 90:1495–1517, September 2002.

[13] H. Holma and A. Toskala.WCDMA for UMTS: Radio Access for Third GenerationMobile Communications. Wiley, 2002.

28

[14] H.-Y. Hsieh and R. Sivakumar. Towards a Hybrid Network Model for Wireless PacketData Networks. InProceedings of ISCC. IEEE, 2002.

[15] http://www.eskimo.com/˜ weidai/benchmarks.html.

[16] http://www.terminodes.org.

[17] Y.-C. Hu, D. B. Johnson, and A. Perrig. SEAD: Secure Efficient Distance VectorRouting for Mobile Wireless Ad Hoc Networks. InProceedings of WMCSA 2002,Portorosz, Slovenia, June 2002.

[18] Y.-C. Hu, A. Perrig, and D. B. Johnson. Ariadne: A Secure On-Demand RoutingProtocol for Ad Hoc Networks. InProceedings of Mobicom. ACM Press, September2002.

[19] Y.-C. Hu, A. Perrig, and D. B. Johnson. Packet Leashes: A Defense against Worm-hole Attacks in Wireless Ad Hoc Networks. InProceedings of INFOCOM. IEEE,2003.

[20] J.-P. Hubaux, T. Gross, J.-Y. Le Boudec, and M. Vetterli. Towards Self-OrganizingMobile Ad-Hoc Networks: the Terminodes Project.IEEE Communications Maga-zine, 39(1):118 –124, January 2001.

[21] M. Jakobsson, J.-P. Hubaux, and L. Buttyan. A Micro-Payment Scheme Encour-aging Collaboration in Multi-Hop Cellular Networks. InProceedings of FinancialCryptography, 2003.

[22] D. B. Johnson and D. A. Maltz. Dynamic Source Routing in Ad Hoc Wireless Net-works. In Imielinski and Korth, editors,Mobile Computing, chapter 5, page 153181.Kluwer Academic Publishers, 1996.

[23] M. Kubisch, S. Mengesha, D. Hollos, H. Karl, and A. Wolisz. Applying Ad-hocRelaying to Improve Capacity, Energy Efficiency, and Immission in Infrastructure-based WLANs. InProceedings of Kommunikation in Verteilten Systemen (KiVS2003), Leipzig, Germany, February 2003.

[24] B. Lamparter, K. Paul, and D. Westhoff. Charging Support for Ad Hoc Stub Net-works. Journal of Computer Communication, Special Issue on Internet Pricingand Charging: Algorithms, Technology and Applications, Elsevier Science, Summer2003.

29

[25] Y.-D. Lin and Y.-C. Hsu. Multihop Cellular: A New Architecture for Wireless Com-munications. InProceedings of INFOCOM, 2000.

[26] O. C. Mantel, N. Scully, and A. Mawira. Radio Aspects of Hybrid Wireless Ad HocNetworks. InProceedings of VTC. IEEE, 2001.

[27] S. Marti, T. Giuli, K. Lai, and M. Baker. Mitigating Routing Misbehavior in MobileAd Hoc Networks. InProceedings of Mobicom, 2000.

[28] A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone.Handbook of Applied Cryp-tography. CRC Press, 1997.

[29] P. Michiardi and R.Molva. Core: A Collaborative Reputation Mechanism To EnforceNode Cooperation In Mobile AD HOC Networks. InProceedings of The 6th IFIPCommunications and Multimedia Security Conference, Portorosz, Slovenia, Septem-ber 2002.

[30] P. Papadimitratos and Z. J. Haas. Secure Routing for Mobile Ad Hoc Networks. InProceedings of CNDS, January 2002.

[31] K. Paul and D. Westhoff. Context Aware Inferencing to Rate a Selfish Node in DSRbased Ad-hoc Network. InProceedings of GLOBECOM, November 2002.

[32] A. Perrig, R. Szewczyk, V. Wen, D. Culler, and J. D. Tygar. SPINS: Security Proto-cols for Sensor Networks. InProceedings of Mobicom, Rome, Italy, July 2001.

[33] H. Wu, C. Qios, S. De, and O. Tonguz. Integrated Cellular and Ad Hoc Relaying Sys-tems: iCAR. IEEE Journal on Selected Areas in Communications, 19(10), October2001.

[34] J. Yoon, M. Liu, and B. Noble. Random Waypoint Considered Harmful. InProceed-ings of INFOCOM. IEEE, 2003.

[35] A. N. Zadeh, B. Jabbari, R. Pickholtz, and B. Vojcic. Self-Organizing Packet RadioAd Hoc Networks with Overlay (SOPRANO).IEEE Communications Magazine,June 2002.

[36] M. G. Zapata and N. Asokan. Securing Ad-Hoc Routing Protocols. InProceedingsof WiSe 2002, Portorosz, Slovenia, September 2002.

[37] S. Zhong, Y. R. Yang, and J. Chen. Sprite: A Simple, Cheat-Proof, Credit-BasedSystem for Mobile Ad Hoc Networks. InProceedings of INFOCOM. IEEE, 2003.

30

A A solution to the early duplicate attack

Let us first consider the solution, for theearly duplicateattack, for the initiator session.During the session setup phase, the base stationBSA sends the first hash valuesAUw 0

andADw 0 of two sufficiently long hash chains, in the initiator confirmation message tothe nodes in the initiator route (includingA). BSA also sends the hash valueAUwm

encrypted with the secret key ofA in the confirmation.A can thus retrieve the elements0 to m of the hash chain and send the hash valueAUw ` (1 ≤ ` ≤ m) with the `-thpacket it generates14. BSA sends the hash valueADw ` with the`-th packet it sends towardA. The intermediate nodes can verify the validity of the hash values by checking15 thatw0 = h`(w`) (w = AUw or ADw ). The packets containing invalid hash values wouldbe discarded. The solution is totally symmetric for the correspondent session. Note herethat givenw`, one can retrieve the hash values of all the previous packets in the session.This means that packets out of order should be discarded. But this constraint is logical inour case because we use the notion of sessions. All the packets are then expected to gothrough the same route and to arrive in order, the contrary is thus suspicious.

The use of the hash values can also solve the case where the attacker tampers onlywith w`; the attack would be detected at the first node that will receive the modified packetbecause the checking of the hash value will fail.

Modifying bothw` and` is an even more subtle malicious attack. Let us assume that aforwarding node receives the packetsPkt `−1 andPkt ` to forward. It discardsPkt `−1 andreplaces the sequence number and the hash value inPkt ` by `− 1 andw`−1, respectively.The sequence number and the hash value will be considered as valid by the followingforwarding nodes. Of course, the packet will be discarded at the target because the MACwill not be verified correctly. The attack is possible if the attacker is part of the route andthus all the nodes on the route would be suspected by the operator. The first direct effectof this attack is for the source to cancel the session, because the throughput is too bad;the second effect is that the operator would eventually, by crosschecking the informationabout the suspected nodes, identify the attacker.

14When the base station notices thatA is about to run out of hash values, it provides it with a hash valueAUwm+n, which allowsA to computen new valid hash values and use them to send its packets. Thesending of the hash value can be done in the same way the up-stream acknowledgment is sent.

15The verification of the hash value can be optimized if we use mechanisms such as [11] for example.

31

B Statistical identification of an attacker

As the operator has no clue about the identity of the attackerA, it will suspect allthe nodes in the route. The operator keeps the information about the suspected nodesand identifies the nodes that are suspected significantly more than average.A will thuseventually be identified as being an attacker and probably punished. Note here that theidentification ofA is not possible if the attack is not repeated a sufficient number of times,but, at the same time, the attack is less harmful if performed only few times.

C Identification of an attacker using the receipts

The nodes that are before the attackerA in the route are able to provide the operatorwith valid receipts for the packet, whereas the nodes that are afterA will provide theoperator with invalid receipts.A and the node after it in the route are thus suspected bythe operator and ifA repeats the attack a subsequent number of times, the operator willidentify it as a malicious node.

32