Trust Based Adaptive On Demand Ad Hoc Routing Protocol

Transcription

1 Trust Based Adaptive On Demand Ad Hoc Routing Protocol Rajiv K. Nekkanti Computer Science Dept, Auburn University, Auburn, Alabama (334) Chung-wei Lee Computer Science Dept, Auburn University, Auburn, Alabama (334) ABSTRACT In this paper, we propose a routing protocol that is based on securing the routing information from unauthorized users. Even though routing protocols of this category are already proposed, they are not efficient, in the sense that, they use the same kind of algorithms (mostly high level) for every bit of routing information they pass from one intermediate node to another in the routing path. This consumes lot of energy/power as well as time. Our routing algorithm basically behaves depending upon the trust one node has on its neighbor. The trust factor and the level of security assigned to the information flow decide what level of is applied to the current routing information at a source/intermediate node. In other words, above a certain level of trust level, there is no need for the source/intermediate node to perform high level on the routing information as it completely trusts the neighboring node. So based on level of trust factor, the routing information will be low-level, medium level, high level encrypted, the low-level being normal AODV. This not only saves the node s power by avoiding unnecessary encoding, but also in terms of time, which is very much valuable in cases of emergencies where the information is as valuable as the time. KEYWORDS Ad-hoc Routing Protocol, AODV, Encryption/Decryption, trust factor, security level Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ACMSE '04, April 2-3, 2004, Huntsville, Alabama, USA. Copyright 2004 ACM /04/04...$ INTRODUCTION Mobile host and wireless networking hardware are becoming widely available, and extensive work has been done in the recent years in integrating these elements into traditional networks such as internet. They can be often used in scenarios in which no infrastructure exists, or in which the existing infrastructure does not meet application requirements for reasons of security or cost. Ad hoc routing protocols are challenging to design and secure ones are even more so. Prior research has generally studied the routing problem in a non-adversarial setting, assuming a trusted environment [3]. These may be sufficient for normal day-to-day applications but for applications such as military exercises and disaster relief, a secure and a more reliable communication is a prerequisite. Our main focus is on on-demand routing protocols [3], in which a node attempts to discover a route to some destination, if and only if has a packet to send to that destination. The source must wait until a route has been discovered, but the traffic overhead is less than Table-driven algorithms [3] where many of the updates are for the unused paths. This reduced overhead affects bandwidth utilization, throughput as well as power usage. No prior advertisement is done, which makes the on-demand routing protocols covert in nature. However, this property is alone not enough to stop a malicious user to access the routing information and initiate directed attacks at the source, destination or any other intermediate node in the network, thus effectively disrupting or even bring down the network. In applications involving secure and covert operations, information security is one thing that can never be compromised. These operations would rather go for a dependable and unbreakable communication than for a cheap, insecure and fast communication. The idea is instead of going for a path, which involves unknown, not trustable enough nodes, it s better to go with the established path with 88

2 known and trusted nodes. Routing protocols are very vulnerable since they can reveal topology information. Listening to few DSR messages in promiscuous mode gives valuable information. A GPS based routing algorithm may give exact node locations. Typically, an attacker can playback routing information and easily collapse the network in different ways. The remainder of this paper is organized as follows: Section 2 summarizes the basic operation of the Ad-hoc On-demand Distance Vector Routing [2] [5] [13] on which we base the design of our secure routing protocol including why we chose it. In Section 3, we present the design of our new secure ad-hoc network routing protocol. Section 4 presents our simulation based performance evaluation of a basic form of our protocol. Finally, section 5 present concluding remarks. 2.0 AODV The Ad hoc On Demand Distance Vector (AODV) routing algorithm is a routing protocol designed for ad hoc mobile networks. AODV is capable of both unicast and multicast routing. It is an on demand algorithm, meaning that it builds routes between nodes only as desired by source nodes. It maintains these routes as long as they are needed by the sources. AODV uses sequence numbers to ensure the freshness of routes. It is loop-free, self-starting, and scales to large numbers of mobile nodes. AODV builds routes using a route request / route reply query cycle. When a source node desires a route to a destination for which it does not already have a route, it broadcasts a route request (RREQ) packet across the network. Nodes receiving this packet update their information for the source node and set up backwards pointers to the source node in the route tables. In addition to the source node's IP address, current sequence number, and broadcast ID, the RREQ also contains the most recent sequence number for the destination of which the source node is aware. 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. If this is the case, it unicasts a RREP back to the source. Otherwise, it rebroadcasts the RREQ. Nodes keep track of the RREQ's source IP address and broadcast ID. If they receive a RREQ which they have already processed, they discard the RREQ and do not forward it. As the RREP propagates back to the source, nodes set up forward pointers to the destination. Once the source node receives the RREP, it may begin to forward data packets to the destination. If the source later receives a RREP containing a greater sequence number or contains the same sequence number with a smaller hop-count, it may update its routing information for that destination and begin using the better route. As long as the route remains active, it will continue to be maintained. A route is considered active as long as there are data packets periodically traveling from the source to the destination along that path. Once the source stops sending data packets, the links will time out and eventually be deleted from the intermediate node routing tables. If a link break occurs while the route is active, 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). After receiving the RERR, if the source node still desires the route, it can reinitiate route discovery. AODV is chosen because of the inherent security in the protocol. Notice that one of the differences between AODV and DSR is that, DSR requires every packet to carry the routing information, whereas, in AODV, once the route is established, the data packets just carry the flow-id. So, in DSR, we ve to encrypt the routing information in every single data packet which is, not impossible, but not desired. [2]. 3.0 TRUST BASED ADAPTIVE ON DEMAND AD HOC ROUTING PROTOCOL 3.1 Design Goals: The main aim is to mask the route path between the source and destination from all the other nodes, so as to avoid any kind of directed attacks. In fact, most of the routing disruption attacks are caused by malicious injection or altering of routing data. So, we feel that there is a need to prevent these attacks by totally hiding the routing information form unauthorized nodes. 3.2 Protocol Description: In this protocol, routing information is shielded from every other node except the source and the destination. A few other routing protocols already exist implementing this idea by encrypting the routing information. This also involves in keeping the source node anonymous. It is to be noted that is a very tedious process which involves 89

3 consuming lot of nodes time and energy. So, if this process is implemented at all intermediate nodes, it s very difficult to design a scalable, viable and efficient routing protocol design. Here is where the trust factor and security level of the application are implemented. So, instead of masking from all the nodes, both time and energy can be saved by masking this information only from the un-trusted nodes. This also depends on the level of security that the application demands. The application demands and the trust levels can be classified as follows: Security level : {high, medium, low} Trust factor :{ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10} Encryption : {high, medium, low} HIGH MEDIUM LOW 9, 10 medium low no 6, 7, 8 high medium no 2, 3, 4, 5 high high no 0, Table 1: Security level description The numbers in the table 1 correspond to the trust factor. The top column of high, medium, low relate to the security level of application. Suppose, if there is a neighboring node whose trust factor with the source node falls between 6 and 8, and the security level is set to high, then the routing information is highly encrypted. This doesn t necessarily mean that this kind of is going to take place all the way to the destination. Depending on the trust factor one node has on its neighbors and the level of security assigned to the application, the level of varies. If the trust factor of a node falls below 2, then that node will not be included in any routing path. Even though all the nodes in the routing path do encrypt their routing information, the difference lies in the keys they use. For ensuring the high level security 128-bit key will be used, where as for a lowlevel a 32-bit key will be used. This ensures that instead of applying 128-bit key for every bit of routing information between every two nodes in the routing path, which involves spending considerable amount of time and node s energy, we can actually fluctuate between these keys and save on the above mentioned parameters. 3.3 Route Discovery: Route discovery allows any host in the ad hoc network to dynamically discover a route to any other host in the ad hoc network, whether directly reachable within wireless transmission range or reachable through one or more intermediate network hops through other hosts. A host initiating a route request first broadcasts a route request packet, which is received by those hosts within the wireless transmission range of it. An additional field, Security Level, has been added to the original RREQ. This is where the application will set the level of security it requires. Since, we are trying to keep the source anonymous from other nodes and also take the trust factor of the neighboring node into consideration; we first look up the source nodes trust table and depending on the trust factor and the level of security for the application, we encrypt the Source ID with the public key of the destination. Now, the source broadcasts this message to its neighboring nodes. Source -> broadcast: {RREQ, seqnum, P b D[S id ], D id, SL } where seqnum is the sequence number, P b D[Sid] is the encrypted Source ID with the destination s (D) public key, D id is the Destination ID and SL is the security level set by the application. This is to make sure that only the destination can unlock the information and know who the source is. When the neighboring node, node B, receives the RREQ packet, it looks into the packet and checks whether the RREQ is destined to it or not. It then looks up it s trust table for each of it s neighboring node and then encodes its own information first with it s private key, appends it to the source information and then encodes the whole with the public key of destination and locally broadcasts the RREQ packet. Intermediate node -> broadcast: {RREQ, seqnum, P b D[P v B[ B id ], P b D[S id ]], D id, SLq} where P b D[P v B[B id ]] is the encrypted intermediate nodes ID (B). Here, one might argue that the since the destination is open to everyone, then this RREQ might not be propagated all the way down. This might be true in cases where a malicious node is bent on disrupting the network. It s not possible to eliminate the bad node altogether, so the best way is to avoid it. But here, it is not possible to initiate any directed attacks towards a particular route between a 90

4 particular source and a particular destination. Since the source is not known, it is impossible for the passive malicious node to get information about the source. And if it still initiates its attack directed towards the destination, then it can be easily identified using ARIADNE, LHAP, ANODR etc., [9] [10] [11] [14] and listed as bad node and be avoided in further route discoveries. In this way, the RREQ is propagated along the network and finally reaches the destination. The destination checks that this RREQ is destined to itself, then applies its private key and then public keys of the intermediate nodes in the order they were encoded. This helps in authenticating that the intermediate nodes themselves encoded their information and prevent any kind of misrepresentation by any malicious node. The destination node then checks to see if there are any designated bad nodes (trust factor less than 2) in the intermediate node list. It compares each node with its list of known bad nodes. If it finds any known bad nodes, it simply discards the RREQ and wait for the next RREQ to arrive. If every intermediate node is not in its bad node list then the destination node generates a flow-id and encodes it with the public keys of intermediate nodes in the order they would receive. Once this is done, the destination node locally broadcasts the RREP packet. D -> broadcast: {RREP, P b C[F id,p b B [F id,p b S[P v D[F id ]]]]]} where P b C, P b B, are the public keys of the intermediate nodes in the order they were encoded. P b S refers to the public key of the source and P v D is the private key of the destination. When the neighboring nodes receive the RREP packet, they would try to decode it using their public key. If they fail, they just discard the RREP, but it they are successful then they will update their corresponding route table path with the local source and destination along with the flow-id. And then, they will remove their part from the packet and locally broadcast it. C -> broadcast: {RREP, P b B[F id,p b S[P v D[F id ]]]]]} When the source receives the RREP, it first applies its private key and then the public key of destination. This authenticates the destination, and prevents misrepresentation of the destination by any malicious node. Now, the source gets the flow-id generated by the destination which completes the process of route discovery. Now the source just uses the flow-id in the header of the data packet to identify the route. All the intermediate nodes also use the flow-id to identify the packet and forward them accordingly. S -> B: {F id, Data} S Figure 1: Example Scenario 3.4 Route Maintenance: All nodes maintain tables which contain the information about the routes. Route disruption can occur due to various reasons. One of the important reasons is that since the nodes are mobile, it happens that some times they might move out of each other s transmission range. Once the route is broken, a node cannot forward the packet to its neighbor. In this case, the node generates a route error packet, with the flow-id as the header and transmits it to the node up in the hierarchy. The error packet will be propagated all the way up to the source, which then issues a new route request. This is similar to normal AODV operation except for the local repair. 4.0 PEFORMANCE EVALUATION An extended version of UCB/LBNL network simulator (NS-2) was used for the experimental study. NS-2 is a discrete event simulator that was developed as part of the VINT project at the Lawrence Berkeley National Laboratory. The extensions implemented by the CMU Monarch project enable it to simulate mobile nodes connected by wireless network interfaces. The NS-2 AODV protocol implementation was modified with cryptographically delay. 4.1 Simulation Environment: To simulate the effects of encoding and decoding, we introduced delay when the nodes are issuing a RREQ, RREP, RERR, forwarding etc., Table 2 shows the performance ( and decryption bit-rate) of different cryptosystems. Table 2. Processing Over head of Various Cryptosystems (on ipaq3670 pocket PC with Intel StrongARM 206MHz CPU)[15] Cryptosystem decryption ECAES (160-bit key) 42ms 160ms RSA (1024-bit key) 900ms 30ms El Gamal (1024-bit key) 80ms 100ms B C D E 91

5 AES/Rijndael (128-bit key & block) 29.2Mbps 29.1Mbps RC6 (128-bit key & block) 53.8Mbps 49.2Mbps Mars (128-bit key & block) 36.8Mbps 36.8Mbps Serpent (128-bit key & block) 15.2Mbps 17.2Mbps TwoFish (128-bit key & block) 30.9Mbps 30.8Mbps unreliable when it is broken and/or saturated with heavy traffic. When a link is unreliable, the node fails to forward packets, causing packet drops or longer delays. Average End-End Delay A unique property of ad hoc networks is the dynamicity of the topology. The velocity of nodes is the main component of the network dynamicity. Ad hoc routing algorithms are designed to cope up with this property, thus, we choose a fast maximum velocity of 20m/sec (72km/hr) in an environment of 500 x 500. The velocity has small amounts of pause time ranging from 0 to 200 seconds. Time (in secs) Level0 Level 1 Level 2 The random mobility generator based on the random way point algorithm [17] is used for the node movement pattern in the networks. The node movement is restricted to a flat terrain without any obstacles. The node starts moving toward a point independently and randomly chosen at speeds ranging between 0 and 20m/sec. It pauses for a predefined amount of time on arriving at the point. For the communication pattern, we used constant bit rate (CBR) traffic model. The number of sources of CBR in the simulation is 30. Each source sends out 8 packets/sec using 64 byte packets. We run the simulation using twenty random scenarios at each pause time. The simulation lasts for 100 seconds. Table 3 summarizes the parameters chosen for this simulation environment. Table 3. Simulation Parameter Values Pause Time (in secs) Figure 2: Average End-End Delay From the figure, it can be seen that low security level has the lowest average end-end delay whereas at high level, which requires higher level of, has the highest end-end delay. This is the price which has to be paid for information security and network reliability. 4.3 Packet Delivery Ratio: Figure 3 shows how many packets are successfully received at the destination in the 500 x 500 networks. It shows that at high level security we have the lowest percentage of packet delivery because of obvious delay occurring due to high level cryptographic operations at the nodes. Packet Delivery Fraction Network Size 500 x 500 Number of Nodes 50 Initial Transmission 100 m Range Movement Speed 20 m/sec Pause Time (second) 0, 10, 20, 60,100, 200 Traffic Type/Sources CBR/30 Packet Size 60 byte Transmission Rate 8 packets/sec Number of Scenarios 20 / pause time Simulation Time 100 secs Packets delivered (%) Pause Time (in secs) Level 0 Level 1 Level 2 We implemented simple AODV (low level security), and then modified with the new trust based algorithm for medium level and high level security. 4.2 Average End-End Delay: The average end-end delay at the given traffic load is shown in the Figure 2. Note that a link becomes Figure 3: Packet Delivery Fraction It can be seen that the Packet Delivery Fraction gradually increases from around 25% at pause time 0 sec (high mobility) to 50% at pause time 200 sec (low mobility). 92

6 5. CONCLUSIONS In this paper, we proposed a solution for the application to choose the level of security it needs. Based on this level of security the application needs and the level of trust a particular node has on its neighbors, the nodes encrypt the information. So, instead of using the same kind of for all the information exchanged, this protocol provides a way to limit this kind of high level of to only the applications which really need them. This saves a lot of time as shown in our study. We also speculate decrease in energy consumption to a certain degree, which will analyzed in our future research. No one protocol can effectively solve all existing security problems. Our protocol can be easily combined with other routing protocols, e.g.: to detect a malicious node [8] [15] [16], and can be implemented in normal civilian networks to high level security military networks. 6. REFERENCES [1]NS-2 with Wireless and Mobility Extensions, available via website [2] html [3]S.J. Lee, M. Gerla and C.K Toh. A Simulation Study of Table-Driven and On-Demand Routing Protocols for Mobile Ad Hoc Netwroks, IEEE Network, Jul [4]D. L. Chaum. Untraceable electronic mail, return addresses, and digital pseudonymns, Communications of the ACM, 24(2):84-88, 1981 [5]M. K. Marina and S. R. Das. Ad Hoc On-demand Multipath Distance Vector Routing. In ICNP, Pages 14-23, [6]Onion Routing, [9]L. Zhou and Z. Hass. Securing Ad Hoc Networks. IEEE Network Magazine, 13(6), November, December [10]Y. Zhang and W. Lee. Intrusion Detection in Wireless Ad-Hoc Networks, MOBICOM [11]S. Zhu, S. Xu, S. Setia, S. Jajodia. LHAP: A Lightweight Hop-by-Hop Authentication Protocol for Ad-Hoc Networks. George Mason University and University of California at Irvine. [12]Marina Dupcinov, Srdjan Krco. Routing in adhoc Networks, Technical Report, Applied Research Lab, EEI, Ericsson, Ireland, [13]David B. Johnson, David A. Maltz. Dynamic Source Routing in Ad Hoc Wireless Networks, Mobile Computing, [14]Yin-Chun Hu, Adrian Perrig, David B. Johnson. Ariadne: A Secure On-Demand Routing Protocol for Ad-Hoc Networks, MOBICOM [15]J. Kong, Xiaoyan Hong. ANODR: Anonymous On Demand Routing with Untraceable Routes for Mobile Ad-Hoc Networks. MOBIHOC, June [16]Tom Goff, B. Nael, Abu-Ghazaleh, Dhananjay. S. Phatak and Ridvan Kahvecioglu, Preemptive Routing in Ad Hoc Networks. ACM SIGMOBILE, July, [17]J. Broch, D. A. Maltz, D. B. Johnson, Y-C. Hu, J. Jetcheva, A Performance Copmaprioson of Mulit-Hop Wireless Ad Hoc Routing Protocols, In the Proceedings of the 4 th International Conference on Mobile Computing and Networking, ACM MOBICOM 98, pp , Oct [7]P. Papadimitratos and Z. Haas. Secure Routing for Mobile Ad Hoc Networks. Ins SCS Communication Networks and Distributed Systems Modeling and Simulation Conference (CNDS 2002), [8]S, Yi, P. Naldurg, R. Kavets. Security-Aware Ad- Hoc Routing for Wireless Networks. Technical Reprt, UIUCDCS-R , UILU-ENG