Abstract 1. Introduction 2. Overview 3. Route Tables 4. AODV Terminology 5. Route Request (RREQ) Message Format 6. Route Reply (RREP) Message Format 7. Multicast Activation (MACT) Message Format 8. Group Hello (GRPH) Message Format 9. Security Considerations


for temporary operations or simply if there are no resources to set up elaborate networks. key exchange and management. and intrusion detection.Abstract Ad-hoc networks are an emerging area of mobile computing. The wireless nature of communication and lack of any security infrastructure raise several security problems. Ad-hoc networks therefore throw up new requirements and problems in all areas of networking. These are mostly due to the resource poorness of these networks. There are various challenges that are faced in the Ad-hoc environment. They are usually set up in situations of emergency. Ad-hoc routing. In this we attempt to analyze the demands of Ad-hoc environment. 2 . We focus on three areas of Ad-hoc networks. The solutions for conventional networks are usually not sufficient to provide efficient Ad-hoc operations.

AODV forms trees which connect multicast group members.1. AODV builds routes using a route request / route reply query cycle. it broadcasts a route request (RREQ) packet across the network. and scales to large numbers of mobile nodes. In addition to the source node's IP address. self-starting. Nodes keep track of the RREQ's source IP address and broadcast ID. It is an on demand algorithm. If this is the case. it will continue to be maintained. 3 . It maintains these routes as long as they are needed by the sources. The trees are composed of the group members and the nodes needed to connect the members. Otherwise. nodes set up forward pointers to the destination. it unicasts a RREP back to the source. the node upstream of the break propagates a route error (RERR) message to the source node to inform it of the now unreachable destination(s). Additionally. Once the source node receives the RREP. the RREQ also contains the most recent sequence number for the destination of which the source node is aware. If a link break occurs while the route is active. AODV uses sequence numbers to ensure the freshness of routes. it can reinitiate route discovery. It is loop-free. AODV is capable of both unicast and multicast routing.As the RREP propagates back to the source. it rebroadcasts the RREQ. Nodes receiving this packet update their information for the source node and set up backwards pointers to the source node in the route tables. and broadcast ID. the links will time out and eventually be deleted from the intermediate node routing tables. If the source later receives a RREP containing a greater sequence number or contains the same sequence number with a smaller hopcount. meaning that it builds routes between nodes only as desired by source nodes. it may update its routing information for that destination and begin using the better route. if the source node still desires the route. Introduction The Ad hoc On Demand Distance Vector (AODV) routing algorithm is a routing protocol designed for ad hoc mobile networks. As long as the route remains active. A node receiving the RREQ may send a route reply (RREP) if it is either the destination or if it has a route to the destination with corresponding sequence number greater than or equal to that contained in the RREQ. it may begin to forward data packets to the destination. If they receive a RREQ which they have already processed. A route is considered active as long as there are data packets periodically travelling from the source to the destination along that path. When a source node desires a route to a destination for which it does not already have a route. they discard the RREQ and do not forward it. After receiving the RERR. current sequence number. Once the source stops sending data packets.

So. One distinguishing feature of MAODV is its use of sequence numbers for multicast groups. A current route is defined as an 4 . Route Replies (RREPs). a requesting node always selects the one with the greatest sequence number. For join requests. a route is determined when the RREQ reaches a node that is already a member of the multicast tree. The range of dissemination of broadcast RREQs can be indicated by the TTL in the IP header. MAODV is the multicast protocol associated with the Ad hoc On-Demand Distance Vector (AODV) routing protocol.The Multicast Ad hoc On-Demand Distance Vector (MAODV) protocol Multicast routes are set up in a similar manner. Overview Route Requests (RREQs). many of the configuration parameters used by MAODV are defined by AODV. and normal IP header processing applies. Similarly. which is initialized by the multicast group leader and incremented periodically. MAODV enables mobile nodes to establish a tree connecting multicast group members. multicast trees are established independently in each partition. For non-join requests. and the node's record of the multicast group sequence number is at least as great as that contained in the RREQ. and trees for the same multicast group are quickly connected if the network components merge. When a node either wishes to join a multicast group or find a route to a multicast group. Multicast Activations (MACTs). and Group Hellos (GRPHs) are the message types utilized by the multicast operation AODV. The membership of these multicast groups is free to change during the lifetime of the network. MAODV does not play any role. except for certain procedures controlled by new flags. The Route Request and Route Reply packet types are based on those used by AODV. RREQs and RREPs are handled as specified in. As long as the multicast group members remain connected (with in a ``multicast tree''). Given the choice between two routes to a multicast tree. the requesting node is expected to use its IP address as the source IP address for the messages. the node uses a broadcast RREQ to discover a route to the multicast tree associated with that group. These message types are handled by UDP. as is the unicast Route Table. Using these sequence numbers ensures that routes found to multicast groups are always the most current ones available. Fragmentation is typically not required. 2. Each multicast group has its own sequence number. Mobile nodes are able to respond quickly to link breaks in multicast trees by repairing these breaks in a timely manner. any node with a current route to the multicast tree may respond to the RREQ. and as such it shares many similarities and packet formats with AODV. In the event of a network partition. for instance.

Next Hop Interface . When a link break on the multicast tree is detected. the tree branch should be immediately repaired through the use of the REQ/RREP/MACT messages. it selects the best route to the multicast tree and unicasts the next hop along that route a MACT message. Nodes monitor the link status of next hops on the multicast tree. Once the source node has waited the discovery period to receive RREPs. the RREP can be unicast back to the source from any node able to satisfy the request. Route Tables MAODV is a routing protocol.Last Hop Count .Next Hop . This message activates the route. and it deals with route table management. such as are created to temporarily store reverse paths towards nodes originating RREQs. The route to the multicast tree is made available by uncasting a RREP back to the source of the RREQ.List of Precursors .Hop Count (number of hops needed to reach destination) . 3. Route table information must be kept even for ephemeral routes. Since each node receiving the request caches a route back to the source of the request.Destination Sequence Number . MAODV uses the following fields with each route table entry.Destination IP Address .Lifetime (expiration or deletion time of the route) ± .unexpired multicast route table entry whose associated sequence number for the multicast group is at least as great as that contained in the RREQ.Routing Flags 5 . This message carries a multicast group and group sequence number and corresponding group leader IP address. A Group Hello message is periodically broadcast across the network by the multicast group leader. A multicast group leader is associated with each multicast group. The primary responsibility of this node is the initialization and maintenance of the group sequence number. which are based on the route table defined in the AODV . This information is used for disseminating updated group sequence numbers throughout the multicast group and for repairing multicast trees after a previously disconnected portion of the network containing part of the multicast tree becomes reachable once again.

which is an association between multicast groups and their corresponding group leaders. i.Multicast Group IP Address . Nodes MAY also maintain a Group Leader Table.The following information is stored in each entry of the multicast route table for multicast tree routes: . The fields of the group leader table are the following: -Multicast Group IP Address -Group Leader IP Address 4. A node on the multicast tree must necessarily have only one UPSTREAM link.Hop Count to Multicast Group Leader The Next Hops field is a linked list of structures.e. This node is responsible for initializing and maintaining the multicast group destination sequence number. The Next Hop Interface fields in the Route Table and Next Hop field of the Multicast Route Table are used for recording the outgoing interface on which the next hop can be reached. UPSTREAM is a next hop towards the group leader.Multicast Group Leader IP Address .Hop Count to next Multicast Group Member .Next Hops . to indicate requirement levels for various protocol features. A node which is a member of the given multicast group and which is typically the first such group member in the connected portion of the network. MAODV Terminology This protocol specification uses conventional meanings for capitalized words such as MUST. The IP Address of a Next Hop MUST NOT be used to forward multicast messages until after a MACT message has activated the route. etc.Multicast Group Sequence Number . and DOWNSTREAM is a next hop away from the group leader. 6 . each of which contains the following fields: -Next Hop IP Address -Next Hop Interface -Link Direction -Activated Flag The direction of the link is relative to the location of the group leader.. SHOULD.

..The table where ad hoc nodes keep routing (including next hops) information for various multicast groups.. it includes the Multicast Group Leader extension. set when a node wants to initiate a repair to connect two previously disconnected portions of the multicast tree. 5. Multicast tree ... When a node wishes to repair a multicast tree...Group leader table .A route set up to forward a reply (RREP) packet back to the source from the destination or from an intermediate node having a route to the destination.The table where ad hoc nodes keep information concerning each multicast group and its corresponding group leader.. 6.The tree containing all nodes which are members of the multicast group and all nodes which are needed to connect the multicast group members. except that the following flags have been added: J Join flag. set when source node wants to join a multicast group. Route Reply (RREP) Message Format 0123 01234567890123456789012345678901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | R |Reserved| Prefix Sz | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Other fields as specified for AODV. There is one entry in the table for each multicast group for which the node has received a Group Hello.. it appends the Multicast Group Rebuild extension. R Repair flag. 7 .. Multicast route table... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the Route Request message remains as specified. When a node wishes to unicast the RREQ for a multicast group to the group leader. Route Request (RREQ) Message Format 0123 01234567890123456789012345678901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |J|R|G| Reserved | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Other fields as specified for AODV. Reverse route.

and indicates to the group member receiving the message that it should become the new multicast group leader. set when a node wishes to prune itself from the tree. ignored on reception. and contains the following fields: Type4 J Join flag. Reserved Sent as 0. G Group Leader flag. set when a node is joining the multicast group. unset when the node is activating a tree link. set when a multicast tree member has repaired a broken tree link and is now a new distance from the group leader. except that the following flag has been added: R Repair flag. U Update flag.+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the Route Reply message remains as specified. Multicast Activation (MACT) Message Format 0123 01234567890123456789012345678901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |J|P|G|U|R| |Reserved| | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Multicast Group IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Sequence Number| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the Multicast Activation message is illustrated above. 8 . P Prune flag. as opposed to finding a route to the group for the transmission of data messages. When the RREP is sent for a multicast destination. set when a node is responding to a repair request to connect two previously disconnected portions of the multicast tree. 7. R Reboot flag. set by a multicast tree member that fails to repair a multicast tree link breakage. the Multicast Group Information extension is appended. set when a node has just rebooted.

Multicast Group IP Address: . Used only when the 'U' flag is set.Hop Count The distance of the sending node from the multicast group leader. Source Sequence Number: . Group Leader IP Address -The IP address of the group leader.. and contains the following fields: Type5 U Update flag. O Off_Mtree flag. set by a node receiving the group hello that is not on the multicast tree. inactivate its last link to the multicast tree). a multicast tree member sends a MACT with the 'P' flag = 1 to its next hop on the multicast tree. otherwise sent as 0. Reserved Sent as 0. Hop Count The number of hops the packet has traveled. Used by multicast tree nodes to update their distance from the group leader when the M flag is not set. set when there has been a change in group leader information.The current sequence number for route information generated by the source of the route request.The IP address of the Multicast Group for which a route is supplied. Group Hello (GRPH) Message Format 0123 01234567890123456789012345678901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type|U|O| Reserved| Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Group Leader IP address| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Multicast Group IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Group Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the Group Hello message is illustrated above. Source IP Address: . ignored on reception. 9 .e. Multicast Group IP Address -The IP address of the Multicast Group for which the sequence number is supplied. 8. A multicast tree member that has more than one next hop to the multicast tree SHOULD NOT prune itself from the multicast tree. To prune itself from the tree (i.The IP address of the sending node.

The CA. could lead to collapse of the entire system.The current sequence number of the multicast group. nodes cannot get the current public keys of other nodes or to establish secure communication with others. Key Management Service We employ cryptographic schemes. There is a trusted entity called Certification Authority (CA) for key management. which possesses the service private key. a node may refresh its key pair periodically to reduce the chance of a successful brute-force attack on its private key. in environments where security is an issue. We adopt a public key infrastructure because of its superiority in distributing keys and in achieving integrity and non-repudiation. responsible for the security of the entire network. the adversary can then sign any erroneous certificate using this private key to impersonate any node or to revoke any certificate. such as digital signatures. A standard approach to improve availability of a service is replication. while private keys should be kept confidential to individual nodes. to protect both routing information and data traffic. The CA has a public/private key pair. because the bindings could change over time: a public key should be revoked if the owner node is no longer trusted or is out of the network. however. To solve this problem. Route protocols. 9. 10 . Security Considerations Currently. If the CA is compromised and leaks its private key to an adversary. In a public key infrastructure. But a naive replication of the CA makes the service more vulnerable: compromise of any single replica. is a vulnerable point of the network: if the CA is unavailable. Efficient secret key schemes are used to secure further communication after nodes authenticate each other and establish a shared secret session key. MAODV does not specify any special security measures. and must be protected by use of authentication techniques involving generation of unforgettable and cryptographically strong message digests or digital signatures. and signs certificates binding public keys to nodes.Multicast Group Sequence Number. Use of such schemes usually requires a key management service. Public keys can be distributed to other nodes. It is problematic to establish a key management service using a single CA in ad hoc networks. The trusted CA has to stay on-line to reflect the current bindings. It is expected that. are prime targets for impersonation attacks. we distribute the trust to a set of nodes by letting these nodes share the key management responsibility. that IPSec authentication headers will be deployed along with the necessary key management to distribute keys to the members of the ad hoc network using MAODV. each node has a public/private key pair. with its public key known to every node.

as a whole. signed by the service private key. Each server also has its own key pair and stores the public keys of all the nodes in the network. All nodes in the system know the public key of the service and trust any certificates signed using the corresponding private key. If a server is compromised. our key management service. 3]. We assume that the adversary can compromise up to t servers in any period of time with certain duration. present within an ad hoc network. has a public/private key pair. Each server i also have a public/private key pair K/k and knows the public keys of all nodes. Provides reliable link. Every query always returns the last updated public key associated with the requested client. that is. servers can establish secure links among them. as clients. assuming no concurrent updates on this entry. creating a digital signature). t + 1) threshold cryptography scheme allows n parties to share the ability to perform a cryptographic operation (e. t+1) configuration (n _ 3t+1). Thus. consists of n special nodes. We also assume that the underlying network layer. Internally. The service is correct if the following two conditions hold: ‡ (Robustness) The service is always able to process query and update requests from clients.. sn. Cryptography Distribution of trust in our key management service is accomplished using Blowfish cryptography [4. so that any t + 11 . one share for each server. for erroneous bindings. with an (n. We also assume that the adversary lacks the computational power to break the cryptographic schemes we employ.g.. which we call servers. has a public/private key pair K/k. an adversary is never able to issue certificates. An (n. The service. a network with no bound on message-delivery and message-processing times. can submit query requests to get other clients¶ public keys or submit update requests to change their own public keys. Thus. whereas the private key k is divided into n shares s1. s2.9.e. The configuration of a key management service: the key management service consists of n servers. then the adversary has access to all the secret information stored on the server. In particular.1 System model Our key management service is applicable to an asynchronous ad hoc network. The public key K is known to all nodes in the network. ‡ (Confidentiality) The private key of the service is never disclosed to an adversary. Nodes. A compromised server might be unavailable or exhibit Byzantine behavior (i. each server knows the public keys of other servers. it can deviate arbitrarily from its protocols). as a whole. The service.

1 parties can perform this operation jointly. Using a (3. each server i gets a share si of the private key k. To make sure that a compromised combiner cannot prevent a signature from being computed. s2. compromised servers (there are at most t of them) cannot generate correctly signed certificates by themselves. More efficient robust combining schemes are proposed [13. even by collusion. . sn) an (n. s2. Let K/k be the public/private key pair of the service. . whereas it is infeasible for at most t parties to do so. si) using its share si. Even though server 2 fails to submit a partial signature. For a message m. t + 1) sharing of k. 12]. For the service to tolerate t compromised servers. we can use t + 1 servers as combiners to ensure that at least one combiner is correct and is able to compute the signature. The combiner is able to compute the signature for the certificate. For the service to sign a certificate. These schemes exploit the inherent redundancies in the partial signatures (note that any t+1 correct partial signatures contain all the information of the final signature) and use error correction codes to mask incorrect partial signatures. However. a compromised server could generate an incorrect partial signature. (iii) Any server can be a combiner. the n servers of the key management service share the ability to sign certificates. We call (s1. . . (i)With t + 1 correct partial signatures. 2) Blowfish cryptography scheme. assigning one share to each server. . because they can generate at most t partial signatures. No extra information about k is disclosed to a combiner. server i can generate a partial signature PS (m. When applying threshold cryptography. the combiner tries another set of t + 1 partial signatures. we must defend against compromised servers. 12 . . Correct servers 1 and 3 both generate partial signatures and forward the signatures to a combiner c. sn). Use of this partial signature would yield an invalid signature. t+1) threshold cryptography scheme and divide the private key k of the service into n shares (s1. In case verification fails. a combiner can verify the validity of a computed signature using the service public key. Fortunately. c is able to generate the signature k of m signed by service private key k. Our key management service actually works under a much weaker link assumption. which is more appropriate for ad hoc networks. we employ an (n. For example. each server generates a partial signature for the certificate using its private key share and submits the partial signature to a combiner. (ii) The duration depends on how often and how fast share refreshing is done. This process continues until the combiner constructs the correct signature from t + 1 correct partial signatures. . . In our case.

References: 1) Intrusion Detection in Wireless Ad-hoc Networks.B. Philip Ginzboorg. S. Johnson. Corson. IEE Computer Society. E. 7) Mobile Ad Hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Consideration. Bridget Dahill. M. N. Perkins and E. Clay Shields. 6) Key Agreement in Dynamic Peer Groups.Haas. Wenke Lee. Macker. Royer. Brian Neil. Toh . Zhou.K. L. Janne Lundberg. Helsinki University of Technology. Elizabeth Royer. 10) Ad Hoc On-Demand Distance Vector Routing Protocol. C. J. Gene Tsudik.Asokan.J. 3) Securing Ad-hoc Networks. Broch and D. 8) A Review of Current Routing Protocols for Ad Hoc Mobile Wireless Networks. J. 5) Routing Security in Ad Hoc Networks. 9) The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks. Yongguang Zhang. M. Z.E. 13 . 2) Key Agreement in Ad-hoc Networks. Royer and C. Michael Steiner. 4) A Secure Routing Protocol for Ad Hoc Networks. Michael Waidner.