Embed Size (px)
Citation preview
An Overlay Approach to Data Security in Ad-Hoc Networks
Jorg Liebeherr Guangyu DongDepartment of Computer Science
University of VirginiaCharlottesville, Virginia 22904
Abstract— Recently, application-layer overlay protocols havebeen considered for enhancing delivery services in mobile ad-hocnetworks. This paper shows that overlay networks can provideforward and backward secrecy for application data in an ad-hoc network. We present a key management and encryptionscheme, called neighborhood key method, where each node sharesa secret with authenticated neighbors in the ad-hoc network.The neighborhood key method avoids expensive global re-keyingoperations when the membership in the network changes or whenthe network is partitioned. The method is evaluated in a newlydeveloped application-layer ad-hoc routing protocol. Both the ad-hoc routing protocol and the security scheme are implemented ina software system for application-layer overlay networks. Exten-sive indoor and outdoor measurement experiments with handheldwireless devices evaluate the effectiveness of the neighborhoodkey method and the performance of application-layer ad-hocnetworks.
I. I NTRODUCTION
A common characteristic of mobile ad-hoc networks andapplication-layer overlay networks is that they do not makea distinction between endsystems and relay systems (routers),that is, endsystems relay traffic for which they are neither thesender nor the receiver. In addition, both types of networksmust be able to cope with frequent changes of the networktopology and the set of nodes attached to the network. Thesesimilarities have stimulated interest in leveraging solutionsgained in one type of network to the other. Notably, severalstudies recently applied application-layer overlay protocolsolutions in a mobile ad-hoc context to run ad-hoc routingprotocols at the application layer [10], [24] or to realize amulticast service in an ad-hoc network [4], [8], [9], [27].
An advantage of building ad-hoc networks at the applicationlayer is that they are easy to deploy, since there is no needfor compatible mesh radios or operating systems. Further,application layer solutions make it easy to add or customizenetwork services, such as multicast, streaming, or security. Themain drawbacks of ad-hoc routing at the application layer is anexpected loss of performance and a reduced ability to interactwith lower layers of the protocol stack.
This paper shows how application-layer overlay networkscan effectively ensure backward secrecy (a new member ofthe network cannot access data transmitted before the memberjoined) and forward secrecy (a member cannot access datathat is transmitted after the member left) in a mobile network.We present a key management and encryption method, calledneighborhood key method, where each node shares a secretkey with authenticated neighbors in the ad-hoc network. Theneighborhood key method avoids network wide re-keying
operations, without requiring that payload data be re-encryptedat each hop.
In addition to the novel security scheme, we are the firstto present empirical measurement data that show the perfor-mance of application-layer ad-hoc networking on commer-cially available portable wireless devices (PDAs).1 The paperalso presents a new spanning tree routing protocol for ad-hocnetworks which supports unicast and multicast transmissions,and evaluates its performance with the proposed securityscheme.
In Section II we discuss an overlay software system thatis the basis for the protocol implementation presented in thispaper. In Section III we present the neighborhood key methodand in Section IV we present a tree-based ad-hoc routingprotocol. Each section includes a performance evaluation. InSection V we present experiments with mobile nodes that mea-sure the performance of the routing protocol from Section IVcombined with the security mechanisms of Section III. Weprovide brief conclusions in Section VI.
II. OVERLAY PERFORMANCE INAD-HOC NETWORKS
In this section we evaluate the delay and throughput per-formance of application-layer overlay networks in an ad-hocenvironment. The implementation and experimentation of theprotocols presented in this paper are realized in a softwaresystem for application-layer overlay networks [16], calledHyperCast, which is described in detail in [2].
A. The Overlay Software System
The HyperCast software uses the concept of an overlaysocket as an endpoint of communication in an overlay network.An overlay network is viewed as a collection of overlaysockets (see Figure 1). The overlay socket has a message-basedAPI for unicast and multicast transmissions that is independentof the overlay topology and the substrate (underlay) network.An overlay socket is configured with attributes from a config-uration file that specify the name of the overlay network tobe joined, the type of overlay topology, the type of substratenetwork, as well as detailed information on the size of inter-nal buffers, protocol-specific timers, and security properties.Overlay sockets must have compatible configuration attributesto join the same overlay network.
Each overlay socket has alogical addressand aphysicaladdress. The logical address is a unique identifier of the socketin the overlay network, with a format that is specific to the
1The measurement data presented in this paper are a selection of a largeset of measurement data available at [2].
Substrate Network
Overlaysocket
Application
Overlaysocket
Application
ApplicationOverlaysocket
Application
ApplicationOverlaysocket
Application
(a) Overlay socket(b) Overlay Network
(Collection of overlay sockets)
Overlay Socket
ForwardingEngine
Overlay Socket API
Messages ofoverlay protocol
MessageBuffer
OverlayProtocol
NodeAdapter
Applicationmessages
Application Program
Substrate Network (e.g., Internet)
SocketAdapter
Fig. 1. Components of overlay sockets.
topology of the overlay. The physical address is a transportlayer address in the substrate network. When the overlaysocket runs over an IP network, physical addresses consistsof IP addresses and TCP or UDP port numbers.
In Figure 1(a) we show the main components of an overlaysocket and their interactions. The overlay protocol componentestablishes and maintains the overlay network topology. Thead-hoc routing protocol presented in Section IV is imple-mented as a new type of overlay protocol. Other available over-lay protocols include a triangulation graph [15], a hypercube[14], and the Pastry distributed hash table [23].2 The forward-ing engine is responsible for sending and receiving formattedapplication messages in the overlay network. Applicationmessages have a header of 26 bytes or more. Overlay messagescan be transmitted to a single overlay socket (unicast) or toall overlay sockets in the network (multicast). The componentsused to access the substrate network are called adapters. Eachoverlay socket has two adapters: a node adapter and a socketadapter. The former handles messages of the overlay protocoland the latter transmits and receives application messages. Thetwo interfaces to the substrate network reflects a separation ofthe control path (for routing messages) and the data path (forapplication data).
Note the similarity of the overlay socket to a softwareimplementation of IP router functions: the forwarding enginecorresponds to the IP module, the overlay protocol correspondsto a routing protocol, and the adapters play a similar role asdevice drivers.
B. Measurements in a Static Ad-hoc Network
Next we present measurement experiments that evaluatethe performance of an overlay network on wireless hand-held devices. The experiments involve up to eight HP iPAQ5550 PDAs, each with a 400 MHz XScale CPU, 128 MBSDRAM, 48 MB Flash ROM memory, and a 802.11b wirelessnetwork card. The 802.11b card is configured to run inpeer-to-peer mode, where data is exchanged directly betweenwireless cards without access points. The software platform isWindows Mobile 2003 and the Jeode Runtime 1.9 Java VirtualMachine (JVM). The Jeode JVM implements the PersonalJava
2The implementation of Pastry is based on the FreePastry distribution [1].
without overlay (plain TCP)
100
200
300
400
500
600
700
800
900
1000
0 2000 4000 6000 8000 10000
Thr
ough
put (
kbps
)
Sequence Number
with overlay
0
(a) Throughput.
with overlay
250
500
750
1000
1250
1500
0 2000 4000 6000 8000 10000
Rou
nd T
rip T
ime
(ms)
Sequence Number
without overlay (plain TCP) 0
(a) Round-trip delay.
Fig. 2. Single-hop measurements.
specification, which is a subset of Java 1.1. External classlibraries are added for functions not supplied by the JeodeJVM.
The experiments in this section evaluate the throughputand delay performance of a static ad-hoc overlay networkwith fixed topologies. All PDAs run a single applicationprogram, each with a single identically configured overlaysocket. The following experiments attempt to give insight inthe performance limitations of the PDAs and the overhead ofthe overlay software.Single-Hop (Unicast). In this experiment, two PDAs locatedin a room at a distance of about 30 feet exchange traffic. OnePDA (sender) transmits 10,000 messages with a payload of512 bytes to another PDA (receiver). For each message, thereceiver transmits a short acknowledgment with a payload of32 bytes. The sender transmits messages in a greedy fashion.
We use TCP connections over an IP network as substratenetwork (i.e., the overlay sockets are configured with socketadapters that establish TCP connections for transmitting ap-plication messages). With this choice, the flow and congestioncontrol algorithms of TCP settle the transmission rate of thesender to the maximum sustainable transmission rate. Wecompare the results with a data transfer over a plain TCPconnection without an overlay network.
Figure 2(a) depicts the throughput values, where thethroughput is calculated at the receiver by computing thenumber of messages received over a sliding window of
��������������������������������������
��������������������������������������
���������������������������������������������
���������������������������������������������
���������������������������������������
���������������������������������������
���������������
���������������
���������������
���������������
������������
������������
with overlay
200
400
600
800
1000
1200
1400
75321
Ave
rage
Thr
ough
put (
kbps
)
Number of Receivers
without overlay (plain TCP)
0
Fig. 3. Single-hop measurements (Multicast).
500 messages. Figure 2(b) shows the round-trip time for eachtransmitted message. The round-trip time is the elapsed timebetween the transmission of a message at the sender and thereturn of the corresponding acknowledgment. The measureddata exhibits a high degree of variability, which is typical forIEEE 802.11b traffic measurements. The throughput hoversaround 500 kbps when an overlay network is used, and around700 kbps for a direct TCP connection. We conclude that theoverhead of the overlay software is noticeable, but does notstymie performance.Single-Hop Measurements (Multicast). We repeat the pre-vious experiment with multiple receivers. We transmit appli-cation data with a multicast operation of the overlay socketAPI, which is translated into unicast TCP transmissions toeach receiver by the overlay socket. The distance between thesending PDA and the receiving PDAs is again 30 feet, and allreceivers are placed next to each other. To avoid that the senderbecomes overwhelmed with acknowledgments, receivers donot send acknowledgments.
Figure 3 shows the average throughput of all data transmis-sion, averaged over all receivers, as a function of the numberof receivers. The error bars indicate the range of throughputvalues for any window of 500 messages. As receivers areadded, the throughput expectedly declines. The performancedifference of the results with and without an overlay decreaseswith the number of receivers. The reason is that, with manyreceivers, the bottleneck is the transmission of multiple copiesof the same message, regardless of the presence of an overlaynetwork.Multi-Hop Measurements (Unicast). Here we present theresults from a multi-hop outdoor experiment. For the mea-surement experiments, we set up six PDAs in a line as shownin Figure 4 at a distance of 30, 60, or 90 feet. The leftmostPDA in the scenario is the sender. (Increasing the distancebetween PDAs to 120 feet or more did not result in reliablemeasurements as the communication between neighboringPDAs became intermittent.) Each PDA is fixed to a pole ata height of approximately 4 feet off the ground. Figure 5depicts the physical setup. As in the first experiment, thesender transmits 10,000 unicast messages to a single receiver,which are each acknowledged by the receiver. We computethe round-trip time and the throughput of the transmissions asdescribed in the first experiment.
Figure 6 depicts the average throughput values when in-
30-90ft 30-90ft 30-90ft 30-90ft 30-90ft
Fig. 4. Six PDAs in a line topology.
Fig. 5. Outdoor experimental setup with PDAs.
0
100
200
300
400
500
600
700
54321
Ave
rage
Thr
ough
put (
kbps
)
Hop Count
30 feet60 feet90 feet
Fig. 6. Multi-hop throughput.
creasing the number of hops, for different distances betweenPDAs. With 1 hop, the sender and the receiver communicatedirectly, with 2 hops, there is 1 PDA between the senderand the receiver, and so forth. The fact that the performancesometimes seems to improve when the distance is increasedcan be attributed to the limitations of running wireless ex-periments. Our experiments were conducted over a period ofseveral days, since the battery lifetime of the PDAs limitedthe number of experiments that can be conducted at one time.However, as has been observed elsewhere [3], [7], conductingthe identical wireless measurement at different times of theday or under different weather conditions may have widelyvarying outcomes.
III. N EIGHBORHOODKEY METHOD
We present a new key management and encryption scheme,called theneighborhood key method, that can assure integrityand confidentiality of application data in overlay networks,with backward secrecy and forward secrecy. Even though ourevaluation will focus on ad-hoc networks, we note that themethod can be applied to overlays connected to a networkinfrastructure. We remark that the solutions presented in thissection are orthogonal to the problem of secure routing, whichseeks protection against attacks to the routing protocol [11],[13].
The security mechanisms discussed in this section areimplemented as a layer between the adapters and the overlayprotocol in the overlay socket (see Section II). This hasthe benefit that the implementation of the mechanisms isindependent of a particular overlay protocol. Details of thesecurity protocols and their implementation can be found in[2].
In most approaches to secure group communications inoverlays or network-layer multicast, members share a singlesymmetric group key for encrypting and decrypting messages[26]. The group key is updated and distributed each time thegroup membership changes [25], [28], [31]. This is referredto as group re-keying. Since group re-keying can be complexand often assumes access to a common server, we resort toa different solution. In our approach, each group member hasits own key that it shares only with its immediate neighborsin the overlay network. As a result, re-keying becomes a localoperation. The drawback of a straightforward implementationof local keys is that each message must be decrypted and re-encrypted each time it is forwarded. Our proposed schemeavoids this pitfall by encrypting message with message-specific keys which are attached to a message. In this way, onlythe message key must be decrypted and re-encrypted when amessage is forwarded.
A. Authentication
The difficulty of authentication and trust management with-out access to an infrastructure with trusted third parties orintermediaries is well-documented [11], [24], [32]. Several so-lutions have been proposed, including advance disseminationof private keys for all node pairs, threshold cryptography ap-proaches [18], [32], and many more, each offering a particulartrade-off with respect to overhead, scalability, availability, andthe ability to perform trust revocation.
We employ an authentication method based on public keycertificates. We assume that each node has a certificate that hasbeen previously signed by a trusted third party. Each node alsoholds certificates of trusted third parties. Without online accessto certificate authorities, trust revocation is not resolved by thismethod, unless it is enhanced by a distributed authenticationprotocol, e.g., [18].
In our scheme, an exchange and verification of certificatesbetween neighbors in the overlay occurs only when needed.When a node receives an overlay protocol message from an-other node for the first time it requests a signed certificate fromthis node and includes its own certificate in the request. Oncecertificates are exchanged, the nodes exchange secret keysthat are used to encrypt or sign messages. Each node acceptsprotocol and application messages only from authenticatednodes.
The exchange of certificates is illustrated in Figure 7 fortwo nodes A and B. When B receives an overlay protocolmessage from A and the certificate of A is unknown, node Bdiscards the message (Step 1), and sends a certification request(CertRequest) message to A (Step 2), which includes B’s cer-tificate. When A receives the request, it verifies the signatureof B’s certificate and, if valid, stores the certificate. Verificationof the signature requires that the private key that signed thecertificate in question be the private counterpart of the publickey known to belong to a trusted third party. In the next step(Step 3), A sends a certification reply (CertReply) messagecontaining its own certificate. In Figure 7, B’s authenticationat A is completed in Step 2, and A’s authentication at B is
A BProtocol message
1. Check for certificate2. If not found, discard message
and send CertRequest
Step 1.
A BCertRequest
1. Check certificate validity2. If valid, store certificate and send CertReply
A BCertReply
1. Check certificate validity2. If valid, store certificate
Step 3.
Step 2.
Fig. 7. Authentication of nodes.
completed in Step 3. Once authenticated, the nodes can processeach others protocol messages and application messages.
B. Exchange of Private Keys and Data Encryption
Encryption of data and the signing of hashes is done withsymmetric keys. Each node maintains a single symmetric keywith all authenticated nodes. We call this key aneighborhoodkey. Note that a node authenticates each node from which itreceives a protocol message. This includes the current neigh-bors in the overlay, but also potential future neighbors. When-ever the set of (current or potential) authenticated neighborschanges, i.e., a new neighbor appears or an existing neighbordisappears, the node computes a new neighborhood key andsends this new key to all authenticated nodes. Neighborhoodkeys are securely exchanged in aKeyUpdatemessage, byencrypting the key with the public key of the receiver using theRSA algorithm. The public key is obtained from the certificatethat was exchanged during the authentication.
The generation of a new neighborhood key and the trans-mission of aKeyUpdatemessage to authenticated neighbors istriggered when (1) a new authenticated neighbor has appeared;(2) an authenticated neighbor requests the neighborhood key;(3) an authenticated neighbor leaves the neighborhood or hasnot sent a message for a long time; (4) the node has reached themaximum sequence number;3 or (5) the current neighborhoodkey has exceeded a specified maximum lifetime.
In Figure 7, theKey Updatemessages are sent immediatelyafter the authentication is complete. That is, A sends aKeyUp-date immediately following theCertReplymessage, and Asends aKeyUpdateafter it has verified the certificate containedin the CertReply. A KeyRequestmessage is transmitted whena integrity check fails on a message. Here, the node assumesthat it does not have an updated neighborhood key. To preventa malicious adversary from staging a DoS attack by sendingforged messages that never pass an integrity test, the frequencyof transmittedKeyRequestmessages is limited.
If messages are encrypted or signed with neighborhoodkeys, only neighbors in the overlay network can decrypt or
3Every node maintains a sequence number for outgoing protocol andapplication messages, which is recorded at the receiver of a message. Areceiver only accepts messages with increasing sequence numbers. Thesequence number is reset when a new key is generated. When the sequencenumber wraps around, a new key must be generated.
verify transmitted messages. Since a note changes its neigh-borhood key each time a new neighbor appears or an existingneighbor departs, a newly joined node is unable to readmessages sent before the node joined, and a departing nodecannot read messages that are transmitted after it leaves. Inthis fashion, the neighborhood key method realizes backwardand forward secrecy.
An alternative to a neighborhood key is a scheme wherea node maintains a separate key for each neighbor. This,however, not only involves additional overhead for maintainingand storing the keys, it also requires that an outgoing messagebe encrypted separately for each neighbor.
In compassion to shared group keys where all nodes in theoverlay network must update (re-key) the shared key wheneverthe membership in the overlay network changes, updating keysin the neighborhood method is a local operations, i.e., eachnode updates keys only with current neighbors in the overlaynetwork. On the other hand, the workload due to updatingneighborhood keys can be high. For example, when a newnode joins the overlay network it may establish a neighborhoodrelationship with many other nodes before it converges to itsfinal position in the overlay network. Since each change tothe neighborhood requires that a node builds and distributesa new neighborhood key, the security features may delaythe convergence of the overlay protocol. The problem isexacerbated during failures in the substrate network when theoverlay topology must be reconstructed and many nodes joinand leave the overlay network at the same time. When the timeinterval between changes to the neighborhood is smaller thanthe time required to update a neighborhood key, the overlayprotocol may no longer converge to a stable topology. As aremedy, it is possible to relax the requirement of generatingnew keys each time the neighborhood of a node changes theoverlay topology is unstable, at the cost of weakening forwardand backward secrecy.
C. Data Confidentiality and Integrity
In the neighborhood key method, when an encrypted mes-sage is forwarded in the overlay network, the message mustbe decrypted and re-encrypted at each hop. Clearly, this isvery time-consuming and not practical in large networks. Toreduce the overhead incurred at each node we employ separatekeys for each message. Here, when a node wants to transmit amessage, it generates a new symmetric key for this message,called amessage key, and encrypts the payload of the messagewith the message key. Then, the message key is encrypted withthe neighborhood key and appended to the message. Whena node receives an encrypted message it first decrypts themessage key. (Recall that each node has the neighborhoodkeys of all authenticated neighbors.) If the message must beforwarded to another node, it re-encrypts the message key withits own neighborhood key.
In Figure 8(a) we show the encryption of a message that istransmitted by a node A with neighborhood keyNKey(A).The node generates a message keyMKey(M) for a messageM , encrypts the message with the message key, encrypts
1. Local peer creates a messagekey.
2. Message is encrypted a withmessage key.
3. Message key is encryptedwith neighborhood key.
M
MKey(M)
EMKey(M)(M)ENKey(A)(MKey(M))
EMKey(M)(M)
MKey(M)
1. Arrived Message
2. Message key is decrypted with neighborhood key of neighbor
3. Message key is encrypted with own neighborhood key
EMKey(M)(M)ENKey(B)(MKey(M))
MKey(M)
EMKey(M)(M)ENKey(A)(MKey(M))
EMKey(M)(M)
(b) Forwarding.
(a) Transmission.
Fig. 8. Processing an encrypted application message (M is the message,MKey(M) is the message key for messageM , NKey(A) andNKey(B)are the neighborhood keys of nodesA and B, EMKey(M)(M) is themessage encrypted with the message key,ENKey(B)(MKey(M)) is themessage key encrypted with the neighborhood key ofB).
the message key with its neighborhood key, appends theencrypted message key to the message, and, finally forwardsthe message to a neighbor. In Figure 8(b) we show how nodeA forwards an encrypted message received from a neighbor B.First, A decrypts the message with B’s neighborhood key, re-encrypts the message key with its own neighborhood key, andthen forwards the message. Note that the encrypted messagepayload is not modified in this process. Merely, the encryptedmessage key must be processed. Since a message key is short(128 bits in our implementation, which reflects current bestpractices), the delay incurred by decrypting and re-encryptingthe message key is limited.
The neighborhood key method is also involved in ensuringintegrity of application messages and protocol messages. Boththe neighborhood key and messages keys are involved increating signed hashes, referred to as message authenticationcodes (MACs)4. There is a separate MAC for the messagepayload and the message header. First, a message key isused to compute the MAC of the message payload. Themessage key is added and encrypted with the neighborhoodkey, as described earlier. Then, the neighborhood key is usedto compute a MAC for the message header. Both MACs,together with the encrypted message key, are transmitted as anextension header of the application message. Integrity is alsoprovided for protocol messages. Here, the MAC is computedover the entire protocol message with the neighborhood key.Note that the MACs provides some level of route security inthe sense of [11]. In our implementation, with the assumptionthat data confidentiality implies a desire for integrity, theMACs for the payload and header of application messages,and the MAC for protocol messages are always computed,when encryption of application payload is requested.
4Precisely, we use a keyed-hash message authentication code (HMAC),which involves a cryptographic hash function in combination with a secretkey.
Confidentiality and Integrity
20
40
60
80
100
120
140
160
180
200
0 2000 4000 6000 8000 10000
Thr
ough
put (
kbps
)
Sequence Number
Integrity
0
(a) Throughput.
Confidentiality and Integrity
Integrity
4000
6000
0
1000
2000
3000
8000
9000
10000
0 2000 4000 6000 8000 10000
Rou
nd T
rip T
ime
(ms)
Sequence Number
5000
7000
(b) Round-trip time.
Fig. 9. Single-hop measurements.
0
10
20
30
40
50
60
70
80
90
100
54321
Ave
rage
Thr
ough
put (
kbps
)
Hop Count
30 feet60 feet90 feet
Fig. 10. Multi-hop throughput with neighborhood keys.
D. Neighborhood Key Method in Ad-Hoc Networks
We evaluate the neighborhood key method in single-hopindoor measurements and multi-hop outdoor measurements,in the same setup as discussed in Subsection II-B. We againevaluate the throughput and delay performance of a staticapplication-layer ad-hoc overlay network. All required certifi-cates are distributed before the measurements take place. (Dueto space restrictions we cannot include our measurements ofthe authentication process and we refer to [2].)
We measure the performance of two following securitysettings. WithIntegrity, the software computes MACs for themessage payload, the message header, and protocol messages,as described at the end of the previous subsection. WithConfidentiality and Integrity, in addition, the message payloadis encrypted as shown in Figure 8. A new message key isgenerated for each message. We only measure the performanceof application messages.
The results of the throughput and (round-trip) delay mea-surements are shown in Figure 9. A comparison with the mea-
surements without security from Section II shows that thereis a noticeable performance penalty. The results also reflectthat the operations performed for integrity and confidentialityare quite similar. The additional cost of data confidentiality islimited.
In Figure 10 we present throughput results of a multi-hopoutdoor experiments, where PDAs are set up as shown inFigure 4. The values present the average throughput valuesover the duration of the experiment. The results show that thedegradation of the throughput is small as the hop count isincreased.
Our data lets us conclude that currently available PDAs cansupport our neighborhood key method at the application layerat data rates below 100 kbps or more. It remains open howthese rates can be improved upon with an implementation thatdoes not require a JVM.
IV. SPANNING TREE PROTOCOL
In this section, we describe a protocol that establishesand maintains a spanning tree overlay network topology. Theprotocol is referred to asSpanning Tree Protocolor SPTprotocol. The SPT protocol assumes that the substrate networksupports a broadcast operation for sending protocol messages.Our target environment for the SPT protocol is a mobile ad-hoc network, however, the protocol can also be used over non-wireless substrate networks.
The protocol has been implemented as an overlay protocolof the overlay socket in Figure 1. In our implementation, theoverlay socket is configured with a node adapter that supportsUDP multicast. Each node has a randomly assigned 32-bitlong logical address that serves as unique identifier within anoverlay network.
As other tree based approaches to ad-hoc routing, e.g.,[22], the SPT protocol is inspired by Perlman’s spanning treealgorithm for bridges [21] to a wireless environment. In theSPT protocol, all nodes agree on one node to be the root (core)of the spanning tree, and each node selects another node asits upstream neighbor (ancestor) in the rooted tree. Also, anode keeps track if it has downstream neighbors (children)in the rooted tree. The ancestor and the children of a nodeare referred to as its neighbors. A node exchanges applicationdata only with its neighbors. Information about the neighborsis maintained in aneighbor table. A node also maintains a anadjacency tablewhich contains a list of all nodes with whichit can exchange messages.
Each node periodically broadcasts abeacon messagein thesubstrate network. The information in the beacon messages isused (1) to accomplish a rendezvous of a new node with anexisting spanning tree network, (2) to eliminate asymmetriclinks, (3) to select an ancestor in the tree, and (4) to repairpartitions of the tree topology. Each node processes everybeacon message that it receives.
The format of the beacon message is shown in Figure 11.The first field, theoverlay hashcontains a checksum computedover the overlay network identifier. Nodes use the hash todetect protocol messages from other overlays, which are then
Overlay Hash4 bytes
SenderID
Physical Address
Core ID
Ancestor ID
Hop Count
Metric
Sequence Number
Adjacency Table
4 bytes
variable
4 bytes
4 bytes
2 bytes
2 bytes
8 bytes
4 bytes +5 bytes per
entry
Size
4 bytesID 1
Link Quality
ID 2
1 byte
4 bytes
1 byte
. . .
Adjacency TableEntry
Beacon Message
Link Quality
4 bytes
Fig. 11. Format of a beacon message.
discarded. TheSenderIDis the logical address of the senderof the message, andPhysical Addressis the address of thesender in the substrate network. If the TCP/IP suite is used assubstrate network (which is the case in all our experiments),the physical address consists of an IP address and a portnumber. TheCoreID is the logical address of a node, whichis, according of the sender of this message, the root of thespanning tree. TheAncestorIDindicates the upstream neighborof the sender of this message. TheHopCountis the path lengthof the sender of this message to the core. The content of theMetric field plays a role when selecting an ancestor. Belowwe discuss two metrics and ancestor selection algorithms. Thebeacon message also contains the content of the adjacencytable of the sender. Each entry of the table consists of anidentifier and a link quality metric.
A. Measuring Link Quality
Many existing ad-hoc routing protocols attempt to minimizethe number of hops of a route. While such protocols mayexhibit good performance in simulation programs, they oftenlook less favorably in actual networks, particularly IEEE802.11b networks [3]. The reason is that minimizing the hopcount tends to increase the geographical distance betweennodes. This, however, leads to higher losses and possiblyunstable links [5], [12], [17].
Alternative approaches, e.g., as proposed in [6], [7], [29],estimate the latency or the reachability between nodes whencomputing a path, and attempt to find routes that have lowlatency or good reachability. In the SPT protocol, we use anapplication-layer equivalent of these strategies. Specifically,we interpret the rate of successful beacon transmissions asa metric for the link quality between adjacent nodes. Usingbeacon messages to measure link quality does not introduceadditional control traffic. We express the link quality of theunidirectional link between a node A and a node B,LQB(A),as the ratio of beacon messages that B received from A, mea-sured over a time period ofN beacon transmission intervals(We setN = 10 in all of our experiments.). The quality of abidirectional link quality is computed as
LQ(A, B) = min(LQB(A), LQA(B)) .
Each node A keeps track of the valueLQA(B) for all receivedbeacon messages from adjacent nodes. When A sends a beaconmessage, it includes all valuesLQA(q) for each nodeq in
its adjacency table.5 When A receives a beacon messagefrom node B, the adjacency table in the message containsLQB(A). With this information, A can computeL(A, B).WhenLQ(A, B) is below a threshold value (30% by default),then B is ineligible to become the ancestor of A.
When A receives a beacon message, and A is not listed inthe adjacency list of the message, then A has discovered anasymmetric link, that is, A knows that B does not receive A’sbeacon messages. If an asymmetric link persists for a longerperiod of time, B is not eligible to be a neighbor of A.
B. Ancestor Selection
Each node uses the beacon messages received from adjacentnodes to select its ancestor in the spanning tree. In the SPTprotocol, we have realized two ancestor selection algorithm.They both create a spanning tree, yet with different properties.The first seeks to minimize the number of hops to the core,the other seeks to maximize the quality of the path to thecore. Both algorithms are extension of Perlman’s spanningtree algorithm to a mobile ad-hoc environment. Due to spaceconstraints, the following discussion is abbreviated, and werefer to [2] for details of the protocol.
The fields in the beacon message that play a role in theselection of the ancestor are theSenderID, Core ID, and theMetric. Initially, each node believes that it is the core and sendsa beacon message withSenderID = CoreID. If a node receivesa beacon that advertises a core with a smaller identifier, it willtry to get connected to that tree and select the sender of themessage as its ancestor. For messages with identicalCoreIDs,a node selects a node as new ancestor if it advertises a smallermetric value. To prevent oscillatory behavior, a new ancestoris selected only if the metric is improved by a threshold value.Minimum Hop Count to Core.Here, each node selects anancestor that minimizes the path length to the core. This resultsin a minimum-hop spanning tree. Each node sets the metric tothe value of theHopCountfield. A node changes its ancestorwhenever it reduces the hop count by at least one.Path Quality to Core.This metric tries to optimize the qualityof the path to the core, by considering the link quality alongthe path to the core when selecting the ancestor. IfL ={1, 2, . . . , K} denotes a set of links that form a path in thenetwork andpi (0 ≤ pi ≤ 1) is the bidirectional link qualityof the i-th link, we calculate the path quality as
∏i∈L pi.
By expressing the metric of a path as the product of the linkmetrics of the path, the metric can be related to the probabilityof a successful message transmission on the path (assumingindependence of the link quality at each link). In our protocolwe write the link metric asδi = − log pi, which yields
∏
i∈L
pi = e−
∑i∈L
δi .
When transmitting the path quality, we transmit the sum in theexponent
∑i∈L δi. A core node sets the value of the metric
5The actual value transmitted in the message is the number of receivedbeacon messages, and not a ratio.
to 1. The values in theMetric field are scaled to yield goodaccuracy in the relevant range.
As most distributed shortest path or minimum spanning treealgorithms, the algorithm presented above is susceptible tocreating transient loops and to the count-to-infinity problem.The latter problem occurs when the network state has changedand information about the old state is still propagated inthe network. As suggested in the DSDV protocol [19], theproblem is mitigated by adding a sequence number field to amessage. In our context, a core node sets the sequence numberin its beacon message and increments the number for eachsubsequent message. Other nodes do not change the sequencenumber. Every node stores the sequence number of each core,and takes action when the sequence number has not increasedfor a longer time period.
C. Forwarding of Data
The spanning tree established by the SPT protocol is suitedfor forwarding application messages to a specific destination(unicast) or to all nodes (multicast).Multicast routing.At the source, an application transmits anew multicast message to each neighbor. At intermediatenodes, the message is forwarded to all neighbors except theneighbor form which the message was received. A message isforwarded to a neighbor with a unicast send operation over thesubstrate network. We also support broadcast operations in thesubstrate network (e.g., UDP multicast over 802.11b), wherea single transmission can forward a message to all neighbors.We refer to [2] for the problems that can arise and how theSPT protocol deals with it.Unicast routing.Unicast routing in a spanning tree poses achallenge since a node does not know if a particular destinationis located upstream or downstream in the tree. Thus, asin the spanning tree algorithm for bridges [21], a nodemaintains a forwarding table for routing unicast messages.New entries to the forwarding table are added in two ways.The first method is a passive learning algorithm analogous tothe learning algorithm for bridges [21]. The second methodis an active search for a route that is triggered by sending aRouteRequestmessage. This is a control message that triggersthe establishment of routing table entries. Nodes that receivera RouteRequesteither forward the request or respond to it bysending aRouteReply.
In the SPT protocol, if an address is not found in theforwarding table, the message is forwarded to all neighbors(with exception of the neighbor from which the message wasreceived). As an alternative, the node could buffer messagesuntil a RouteReplymessage delivers the desired entry. Sucha modification would give the protocol the flavor of an on-demand protocol, such as DSR or AODV.
D. Evaluation of the SPT Protocol
We evaluate the spanning tree protocol in terms of sim-ulation experiments using the Glomosim [30] simulator forad-hoc networks. We evaluate how well the SPT protocolcan maintain connectivity between nodes in a mobile ad-hoc
Parameter ValueSimulated Area 1500 m× 500 mNumber of Nodes 50Number of Sending Nodes 10Wireless range 250 mSimulation Time 900 secData Rate 1 packet/secMessage Size 512 BytesMax. speed 0 − 20 m/secMobility Mode Random Waypoint
Speed Uniform[0, max. speed]Pausing Time 20 sec
Transmission mode unicast
TABLE I
SIMULATION PARAMETERS.
network. The parameters of the simulations, shown in Table I,are typical for simulations in the published literature thatevaluate ad-hoc routing protocols. There are 50 mobile nodesand 10 members transmit unicast packets to 10 receivers at aconstant rate.
We compare the two versions of the SPT protocol (hopcount and path quality) to the AODV protocol [20], whichis one of the main on-demand ad-hoc routing protocols. Theterm ‘on-demand’ refers to the fact that AODV builds a pathto a destination only if there is data to be transmitted. Thepath established by AODV follow the shortest reverse pathto the source. Data is buffered at the source until a path isestablished. AODV has a MAC layer notification mechanismthat detects when a link of a path becomes unavailable, andrepairs an interrupted path.
We consider the following performance metrics, which arefrequently used to evaluate ad-hoc routing protocols. TheDelivery Ratio, defined as the fraction of transmitted packetsthat are successfully delivered to the destination, measures howwell a protocol finds routing paths in a network with mobilenodes. TheAverageEnd-to-End Delayis the time to deliver apacket to the destination averaged over all transmissions. TheNormalized Forwarding Overheadis the ratio of the numberof events when packet transmissions occur (either sent at thesource or forwarded at intermediate nodes) and the number ofevents when a packet arrives at the receiver. The optimal ratiois achieved when packets are always forwarded on the shortestpath to their destination. Inefficient routes, routes that are outof date because of mobile nodes, and inefficient forwarding,e.g., flooding of packets, increase the normalized forwardingoverhead.
Figure 12 depicts the performance measures as a functionof increasing mobility of nodes. Each data point representsthe average of ten simulation runs, Figure 12(a) shows thatthe delivery ratio of the SPT protocol is lower than that of theAODV protocol, with a larger difference at higher speeds. Wealso consider a modification to AODV where we disable theMAC notification for unavailable links. The purpose of thisis to show how an application-layer version of AODV mayperform that does not have access from lower layers of theprotocol stack.
The graph in Figure 12(b) shows that the SPT protocol has
SPT (path quality)
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
0 4 8 12 16 20
Del
iver
y R
atio
Maximum Speed (m/s)
AODV
AODV (no MAC notification)
SPT (minimum hop)
0
(a) Delivery ratio.
SPT (minimum hop) 10
20
30
40
50
60
70
80
90
100
0 4 8 12 16 20
End
−to
−E
nd D
elay
(m
s)
Maximum Speed (m/s)
AODV (no MAC notification)
AODV
SPT (path quality)
0
(b) Delay.
SPT (minimum hop)
5
10
15
20
0 4 8 12 16 20
Nor
mal
ized
For
war
ding
Ove
rhea
d
Maximum Speed (m/s)
AODV (no MAC notification)
AODV
SPT (path quality)
0
(c) Forwarding overhead.
Fig. 12. Simulation of mobile network.
lower delays. This is intuitive, since AODV buffers packetswhen it does not know how to forward a packet, whereas theSPT protocol floods a packet in such a situation. Figure 12(c)illustrates the cost of the SPT protocol in terms of forwardingoverhead. The forwarding overhead is higher than in AODVsince unicast routes in the SPT protocol do not minimize thepath between senders and receivers. Also, when a route isnot known a message is flooded to all neighbors resulting inmultiple transmissions of the same packet. In all graphs, theminimum-hop version of SPT has a better performance thanthe path quality variant. In the next section, we will see thatthis is not true in our measurement experiments.
Overall, the simulation results show that the SPT protocolprovides favorable results, which, in comparison to a popularad-hoc protocol, improves delay performance at the cost of alower delivery ratio and higher forwarding overhead.
V. SPT PROTOCOL WITH DATA SECURITY
In this section we put together all protocols developed in thispaper to evaluate how the neighborhood key method performsin an ad-hoc network with mobile nodes that self-organizeusing the SPT protocol.
The experiments are outdoor measurements with PDAs asshown in Figure 5. The setup of the PDAs is shown inFigure 13. Six PDAs (A, B, C, D, E, F) are placed in a line witha distance of approximately 90 ft between them. In addition,a person holding a PDA (labeled as M) walks parallel to thefixed PDAs at a distance of about 50 ft, covering a round-tripdistance of about 1260 ft.
In the experiment, A transmits unicast messages with a 512byte payload to the mobile PDA at a rate of 10 messages persecond. All messages are transmitted using UDP unicast assubstrate network. The spanning tree protocol is configuredso that E is the core of the tree.
Sender
Receiver
90ft 90ft 90ft 90ft 90ft
50ft
90ft 90ft
Core
M
A B C D E F
Fig. 13. Measurement scenario with a mobile receiver.
E/2
C/3 A/1 C/3
E/2C/3 A/1
Con
secu
tive
Mes
sage
Los
ses
60
70
80
0 500 1000 1500 2000 2500 3000 3500Sequence Number
40
30
20
10
0
50
(a) Minimum hop count metric.
B/4B/3F/4 D/3D/3 F/4 D/3C/2
0
60
70
80
0 500 1000 1500 2000 2500 3000 3500 4000
Con
secu
tive
Mes
sage
Los
ses
Sequence Number
40
30
20
10
50
(b) Path quality metric.
Fig. 14. Measurements with mobile receiver (confidentiality not enabled).
E/2 B/2 E/2 B/3 E/2A/1 E/2
0
40
50
60
70
80
0 500 1000 1500 2000 2500 3000 3500
Con
secu
tive
Mes
sage
Los
ses
Sequence Number
20
10
30
(a) Minimum hop count metric.
C/3 B/3 C/3 F/4 E/2 F/4 E/2 F/4 E/2 D/4 B/3 C/3
0
30
40
50
60
70
80
0 500 1000 1500 2000 2500 3000 3500
Con
secu
tive
Mes
sage
Los
ses
Sequence Number
10
20
(b) Path quality metric.
Fig. 15. Measurements with mobile receiver (confidentiality enabled).
We present results of two sets of measurements. For eachset, we run the spanning tree protocol with the minimum hopmetric and the path quality metric. We measure the degradationdue to mobility by recording gaps of the transmission streamat the receiver. Specifically, we plot the consecutive numberof lost messages at the receiver. We also record changes to theroute between the sender and the receiver.
Figure 14 shows the outcome a measurement when securityfeatures are not enabled. The crosses (×)) in the plots indicatea change of the spanning tree topology that affects the mobilePDA. We also include the length of the route form the senderto the receiver. For example, a label ‘C/3’ indicates that Cis the ancestor of the mobile PDA, and that the path fromthe sender (A) to the mobile receiver (M) is 3 hops long. Acomparison of Figures 14(a) and 14(b) shows that the pathquality metric has significantly fewer losses.
In Figure 15 we repeat the first measurement, but, inaddition, provide data confidentiality and integrity with theneighborhood key method. Here, each time the mobile PDAexchanges a beacon message with one of the fixed PDAsfor the first time, there is an exchange of certificates andneighborhood keys. For message encryption, we generatea new message key for each transmitted message. Recallthat the message key is decrypted and re-encrypted at eachhop between the sender and the receiver. A comparison ofFigures 14 and 15 shows that the security mechanisms onlycause a limited degradation of the recorded message losses.
VI. CONCLUSIONS
We presented overlay network protocols for ad-hoc net-works that ensure forward and backward secrecy for applica-tion data. All routing and security functions were realized andevaluated in an operational application-layer overlay networksystem. Measurement experiments with PDAs shed light onthe throughput and delay performance achievable with state-of-the-art handheld wireless devices. While throughput anddelay performance of currently available PDAs limit theirapplicability to low-bandwidth scenarios, this paper has em-pirically demonstrated the efficacy of application layer ad-hocnetworking with (and without) data security.
REFERENCES
[1] Freepastry. http://freepastry.rice.edu.[2] Hypercast design documents and materials.
http://www.cs.virginia.edu/hypercast/material.html, 2005.[3] D. Aguayo, J. Bicket, S. Biswas, G. Judd, and R. Morris. Link-
level measurements from an 802.11b mesh network. InProc. of ACMSigcomm’04, Aug. 2004.
[4] K. Chen and K. Nahrstedt. Effective location-guided overlay multicastin mobile ad hoc networks, 2005. To appear.
[5] K.W. Chin, J. Judge, A. Williams, and R. kermode. Implementationexperience with manet routing protocols.ACM Sigcomm ComputerCommunications Review, 32(5), Nov. 2002.
[6] D. S. J. De Couto, D. Aguayo, J. Bicket, and R. Morris. A high-throughput path metric for multi-hop wireless routing. InProc. of ACMMobiCom’03, Sep. 2003.
[7] R. Draves, J. Padhye, and B. Zill. Comparison of routing metrics forstatic multi-hop wireless networks. InProc. of ACM Sigcomm’04, Aug.2004.
[8] M. Ge, S. V. Krishnamurthy, and M. Faloutsos. Overlay multicasting forad hoc networks. InProc. of Third Mediteranean Ad Hoc NetworkingWorkshop (Med-Hoc-Net), Bordum, Turkey, 2004.
[9] C. Gui and P. Mohapatra. Efficient overlay multicast for mobile ad hocnetworks. InProc. of IEEE Wireless Communications and NetworkingConference (WCNC), pages 1118–1123, March 2003.
[10] Y. C. Hu, S. M. Das, and H. Pucha. Exploiting the synergy betweenpeer-to-peer and mobile ad hoc networks. InProc. of 9th Workshop onHot Topics in Operating Systems (HotOS IX), May 2003.
[11] Y.-C. Hu and A. Perrig. A survey of secure wireless ad hoc routing.IEEE Security and Privacy, 2(3):28–39, May/June 2004.
[12] Y.C. Hu and D.B. Johnson. Design and demonstration of live audioand video over multihop wireless ad hoc networks. InProc. of IEEEMilcom’02, 2002.
[13] C. Karlof and D. Wagner. Secure routing in wireless sensore networks:attacks and countermeasures.Ad Hoc Networks (Elsevier), 1(3):293–315, 2003.
[14] J. Liebeherr and Tyler K. Bean. Hypercast: a protocol for maintainingmulticast group members in a logical hypercube topology.Proc. of FirstWorkshop on Networked Group Communications (NGC), Jul 1999.
[15] J. Liebeherr, M. Nahas, and W. Si. Application-layer multicast withdelaunay triangulations.IEEE Journal on Selected Areas in Communi-cations, 40(8):1472–1488, Oct 2002.
[16] J. Liebeherr, J. Wang, and G. Zhang. Programming overlay networkswith overlay sockets. InProc. 5th COST 264 Workshop on NetworkedGroup Communications (NGC 2003), LNCS 2816, pages 242–253, Sep.2003.
[17] H. Lundgren, E. Nordstrom, and C. Tschudin. Coping with communi-cation grayzones in IEEE 802.11b. InProc. of 5th ACM InternationalWorkshop on Wireless Mobile Multimedia (WoWMoM 2002), Sep. 2002.
[18] H. Luo, J. Kong, P. Zerfos, S. Lu, and L. Zhang. Ursa: Ubiquitousand robust access control for mobile ad hoc networks.ACM/IEEETransactions on Networking, 2005. To appear.
[19] C. E. Perkins and P. Bhagwat. Highly dynamic destination-sequenceddistance vector routing (DSDV). InProc. of ACM Sigcomm, pages 234–244, Sep. 1994.
[20] C. E. Perkins and E. M. Royer. Ad-hoc on-demand distance vectorrouting. In Proc. 2nd IEEE Workshop on Mobile Computing Systemsand Applications, pages 90–100, Feb. 1999.
[21] R. Perlman. An algorithm for distributed computation of spanning treesin an extended LAN. InProc. of 9th Data Communications Symposium,pages 44–53, Sep. 1985.
[22] S. Radhakrishnan and G. Racherla. Protocol for dynamic ad-hocnetworks using distributed spanning trees.Wireless Networks, 9:673–686, 2003.
[23] A. Rowstron and P. Druschel. Pastry: Scalable, distributed objectlocation and routing for large-scale peer-to-peer systems. InProc. ofIFIP/ACM International Conference on Distributed Systems Platforms(Middleware), Heidelberg, Germany, Nov. 2001.
[24] R. Shollmeier, I. Gruber, and M. Finkenzeller. Routing in mobile ad-hoc and peer-to-peer networks: A comparison. InProc. of InternationalWorkshop on Peer-to-Peer Computing, Pisa, Italy, May 2002.
[25] M. Steiner, G. Tsudik, and M. Waidner. Key agreement in dynamicpeer groups.IEEE Transactions on Parallel and Distributed Systems,11(8):769–780, Aug. 2000.
[26] D. Wallner, E. Harder, and R. Agee. Key management for multicast:Issues and architectures. IETF RFC 2627, June 1999.
[27] L. Xiao and et. al. Prioritized overlay multicast in mobile ad hocenvironments.IEEE Computer, 37(2):67–74, Feb 2004.
[28] Y. R. Yang, X. S. Li, X. B. Zhang, and S. S. Lam. Reliable grouprekeying: A performance analysis. InProc. of ACM Sigcomm, pages27–38, Aug. 2001.
[29] M. Yarvis, W. S. Conner, and L. Krishnamurthy. Real-world experiencewith an interactive ad hoc sensor network. InProc. of the InternationalWorkshop on Ad Hoc Networks, Aug. 2002.
[30] X. Zeng, R. Bagrodia, and M Gerla. Glomosim: A library for parallelsimulation of large-scale wireless networks. InProc. of Workshop onParallel and Distributed Simulation, pages 154–161, 1998.
[31] X. B. Zhang, S. S. Lam, and H. Liu. Efficient group rekeying usingapplication-layer multicast. InProc. of the 25th IEEE InternationalConference on Distributed Computing Systems (ICDCS 2005), Jun.2005. To appear.
[32] L. Zhou and Z. J. Haas. Securing ad hoc networks.IEEE Network,13(6):24–30, Nov./Dec. 1999.
