Security Scheme for Malicious Node Detection in Mobile Ad Hoc Networks

Security Scheme for Malicious Node Detection in Mobile Ad Hoc Networks Punit Rathod 1, Nirali Mody 1, Dhaval Gada 1, Rajat Gogri 1, Zalak Dedhia 1, Sugata Sanyal 2 and Ajith Abraham 3 1 Mumbai University, India 2 School of Technology and Computer Science, Tata Institute of Fundamental Research, India, sanyal@tifr.res.in 3 Computer Science Department, Oklahoma State University, USA ajith.abraham@ieee.org Abstract. In Ad hoc On Demand Vector (AODV) routing protocol for MANET (Mobile Ad hoc Networks), malicious nodes can easily disrupt the communication because of inherent limitations. A malicious node that is not part of any route may launch Denial of Service (DoS) Attack. Also, once a route is formed, any node in the route may turn malicious and may refrain from forwarding packets, modify them before forwarding or may even forward to an incorrect intermediate node. Such malicious activities by a misbehaving node cannot be checked for in pure AODV protocol. In this paper, a proactive scheme is proposed that can detect a node performing the above-mentioned malicious activities, i.e. can detect any compromised node. The series of simulations reveal that the proposed scheme provides a better performance in securing the AODV routing protocol with minimal extra overhead as compared to pure AODV protocol. 1. Introduction In AODV, a communication link is established between the source and the destination by a route discovery procedure initiated by the source [1]. However, AODV is subject to various malicious activities before the route is formed as well as after its establishment. AODV routing protocol provides control messages for route discovery and subsequent route maintenance but cannot guard against their flooding, deliberate dropping or malicious modification. Before a route is established, a malicious node can flood the network with false control packets, such as RREQs (Route Requests), congesting the network leading to DoS attacks. Once a route is formed, any intermediate node in the route, which turns malicious can drop packets, modify them before forwarding or tunnel them [5][10]. Our scheme addresses these malicious activities and detects the node, which is misbehaving both prior to route for-

mation (during route discovery) and after its establishment (during communication). In section 2, we describe the malicious activities prior to route formation and details of their detection mechanism. Section 3 deals with identification and detection of malicious activities by any intermediate node in the established route. To quantify the effectiveness of the proposed scheme, malicious activities were simulated in the mobile environment and the resulting performance analysis of our scheme is reported in section 4. Finally section 5 gives the conclusions. 2. Malicious Activity Prior to Route Formation As mentioned in section 1, prior to route formation, a malicious node can launch DoS attacks. This section deals with their detection and prevention mechanism. 2.1 DoS Attack Due to RREQ Flooding during Route Formation In AODV, limit of initiating/forwarding RREQs is given by RREQ_RATELIMIT [1], which has a default value of 10 RREQs/sec. A malicious node can exceed this limit owing to self-control over all its parameters. This results in a specific kind of DoS attack launched by flooding the network with fake RREQs. In this attack a non-malicious node cannot fairly serve other nodes due to the network-load imposed by the fake RREQs. This leads to wastage of bandwidth and processing time as well as exhaustion of the network resources like memory (routing table entries) and node s battery power. These further result in degraded throughput. Most of the network resources are wasted in trying to generate routes to destinations that do not exist or routes that are not going to be used for any communication [9]. 2.2 Detecting and Preventing RREQ Flooding For detecting RREQ flooding, the proposed scheme shifts the responsibility to monitor RREQ_RATELIMIT parameter on the node s neighbors, thus ensuring the compliance of this restriction. Instead of self-control, the control exercised by a node s neighbor results in preventing the flooding of RREQs. The proposal is based on the application of two new parameters: RREQ_ACCEPT_LIMIT and RREQ_BLACKLIST_LIMIT.

RREQ_ACCEPT_LIMIT denotes the number of RREQs that can be accepted and processed per unit time by a node. This parameter specifies a value that ensures uniform usage of a node's resources by its neighbors. RREQs from a node exceeding this limit are dropped, but their timestamps are recorded to monitor the rate at which RREQs are received. In the simulations carried out, the value of this parameter was kept as three (i.e. three RREQs can be accepted per unit time per neighbor). This value can be made adaptive, depending upon node metrics such as its memory, processing power, battery, etc. The RREQ_BLACKLIST_LIMIT parameter is used to specify a value that aids in determining whether a node is acting malicious or not. The number of RREQs originated/forwarded by a neighboring node per unit time should not exceed the value of RREQ_BLACKLIST_LIMIT. In the simulations, the value of RREQ_BLACKLIST_LIMIT is kept as 10 RREQs/sec. On identifying a neighboring node as malicious, it will be blacklisted, thus prevent further flooding of the fake RREQs in the network originating from that node. The blacklisted node is ignored for a period of time given by BLACKLIST_TIMEOUT after which it is unblocked. The BLACKLIST_TIMEOUT period is doubled each time the node repeats its malicious behavior. Prevention of the DoS attack is achieved because all the neighbors of the malicious node will eventually blacklist it and not accept further RREQs till BLACKLIST_TIMEOUT, thus isolating it in a distributed manner. 2.3 Illustration Figure 1a depicts the working in pure AODV routing protocol when a malicious node launches a DoS attack by flooding the network with fake RREQs. The black node represents a malicious node and the gray nodes represent two genuine nodes that want to communicate with each other. The optimal route consists of four intermediate nodes that are the four neighbors of the malicious node and are directly affected by the flooding of RREQs. The malicious node floods the network by generating greater than 10 RREQs per second as shown. Its immediate neighbors, (who are not malicious) observe the RREQ_RATELIMIT and hence forward 10 RREQs only. In the subsequent stages, the number of RREQs forwarded decay as a result of other possible genuine RREQs present in the network and the RREQ_RATELIMIT. As shown in Figure 1a, the malicious node s neighbors are most of the time occupied in processing fake RREQs from the malicious node, thereby rendering the genuine nodes starving for resources, and hence

leading to greater number of hops in the communication route formed between the two gray genuine nodes (shown by gray connecting links). Fig. 1. Illustration of route formation in AODV: (a) Original (b) Proposed Figure 1b illustrates the working in the proposed AODV scheme. In this scheme, the number of RREQs that can be accepted from a neighbor is limited by RREQ_ACCEPT_LIMIT. Hence, the neighbors of the malicious node will only accept and forward three RREQ packets received from it within a time interval of one sec. When the malicious node crosses the RREQ_BLACKLIST_LIMIT of 10 RREQ packets within a time interval of one second, its neighbors will blacklist it. Thus, in addition to limiting the clogging up of resources in the network, the proposed scheme also, isolates the malicious node. The route established in this scheme turns out to be the optimum route (shown by gray connecting links), which consists of minimum number of intermediate nodes. Thus, no DoS attack is experienced in the developed scheme. 3. Malicious Activity after Route Formation 3.1. Malicious Activities of any Intermediate Node in the Route The malicious activities that can occur after route formation on data packets are listed below [5][10]:

1. Dropping data packets randomly leading to their unnecessary retransmissions and possibly even new route discovery procedures 2. Forwarding data and / or AODV routing packets to incorrect next-hop node (tunneling). 3. Modifying data contents as well as its checksum before forwarding it to next-hop node. This activity will go undetected by the next-hop node, since at the TCP layer it will only recalculate the data checksum and verify with the checksum present in the received data packet, and find it equal. In our scheme, we handle these malicious activities as described in the following sub sections. 3.2. Detecting Compromised Node in the Route For detecting malicious activities by a compromised node in the route, we monitor the activities of the next-hop node. To do so, each node listens in the promiscuous mode [6], which is explained below. While in this mode, the next-to-next hop information is used to ensure correct forwarding of AODV routing packets as well as data packets. 3.2.1. Listening in promiscuous mode and the NTNH field in RREP Promiscuous listening [6] is defined as the process by which a node can overhear packets (data packets as well as routing protocol packets), which may not be intended for it (within its transmission range), and deliver it to the network stack. Using promiscuous mode in AODV, a node cannot verify whether the packets are being forwarded to the "correct" neighbor of the next hop node along the route because the AODV protocol supports only one-hop information in the routing table. To overcome this limitation of the AODV protocol, we give next-to-next hop information to each node of the route by adding a new field in the RREP packet, called the NTNH (Next-To-Next-Hop) field. It provides the MAC address of a node s next-hop node to its previous-hop node. Thus each node in the route now has two-hop information. While the RREP packet is forwarded from the destination node to the source node, every node (except the destination) puts its "next-hop" value (from its own routing table) in NTNH field (added to RREP). When an intermediate node receives this packet, it stores this value as the NTNH field for the corresponding destination in a buffer. This value is later used to verify that all the packets are forwarded to "correct" next-to-next node along the route.

3.2.2. Detecting a Malicious Node in Promiscuous Mode If the next node along the route does not forward the "correct" data packet to the "correct" next-to-next node along the route, we can detect it as malicious. For this detection, each node along the route performs the following operations in the promiscuous mode: 1. Before forwarding the data packet, the node buffers its sequence no. and checksum so that it can use it for comparison later. 2. While in promiscuous listening mode, the node will listen to all the transmissions of its next-hop neighbor. For each data packet it listens, it checks the packet sequence no. and the checksum against those buffered earlier for this packet. If they match, it means that "correct" data packet was forwarded. 3. Next, the node checks the address to which the packet was forwarded and compares it against the address in the NTNH field (received along with the RREP packet and buffered as explained above). If it matches, it means that the data packet was forwarded to the "correct" next-to-next hop neighbor along the route. 3.3. Illustration 3.3.1. Appending NTNH field with RREP packet In our scheme, each node forwards the RREP packet along with the address of 'its next hop' (taken from routing table) in the NTNH field along the reverse route. Let us consider the following scenario: Source : A Destination : E Route : A-B-C-D-E Other nodes : M,F,X Node C forwards the RREP along with the address of its next hop (D) to Node B along the reverse route. Fig. 2. Example of how NTNH field is added in the RREP packet

3.3.2. Malicious Operation during Route Formation When RREP is being sent to the source node, each intermediate node is supposed to send its next-hop node address in the NTNH field of the RREP. But a malicious node can send wrong address of its ' next hop ' in the NTNH field. It thus tries to mislead its previous-hop node in the beginning itself by sending an incorrect or non-existent next-hop node address. Fig. 3. NTNH field modified by a malicious node Node C being malicious sends ' RREP+NTNH=M '(as its next hop) to B instead of ' RREP+NTNH=D ' so that B feels that node M follows C in the route. According to our proposal since each node is in promiscuous mode, when 'RREP+NTNH=M ' is sent by C to B, D can hear it and detect that C has deliberately sent wrong value (M) in the NTNH field. Node C can then be marked as Malicious. 3.3.3. Malicious Operation during Forwarding Data Packets A. Forwarding to Wrong Node Malicious node can forward packets to some other node instead of the correct next node. In the scenario considered below, Node C has to forward the data packets to Node D but C, being malicious sends data packets to M (tunneling). Fig. 4. Tunneling of Data Packets by a malicious node When data packet is sent by C to M, instead of D, B can detect this malicious activity by listening in promiscuous mode and matching the address to which C is forwarding the packet against the stored NTNH value.

B. Dropping Data Packets After forwarding data packet to C, B listens for certain time interval t, to check that C forwards the packet to intended node. If C fails to forward the packet, B resends it. B then waits for another time interval t. If C still fails to forward the packet, B sends an RERR packet to A. This prevents any intermediate node from dropping packets either because it turned greedy or malicious or was powered down. 4. Simulation/Experiments and Analysis 4.1 Simulation Environment NS-2 simulator [7][8][11] was used for the implementation of the proposed scheme. In the sample scenarios, the Radio transmission range [12] was set as 250 meters. Traffic sources used were Constant-Bit-Rate (CBR) and the field configuration was 2000 x 2000m with a total of 69 nodes. The Traffic scenario simulated was as follows: Node 0 floods the network with fake RREQs with destination addresses ranging from 4 to 60. Node 11 was configured as malicious node, which tunnels all incoming data packets to an unintended node (node 31 in the simulation). Normal network traffic was generated with the source and destination pairs randomly spread over the entire network. Some of the source-destination pairs are shown in Table 1. Table 1. Traffic generation summary Source Destination Simulation Start-Stop times Node 48 Node 20 11-16 sec Node 18 Node 27 5-12 sec Node 31 Node 66 6-11 sec Node 45 Node 16 9-12 sec Using this scenario, the performance of original AODV protocol and proposed AODV protocol in presence of compromised nodes was evaluated. 4.2 Network Simulation Metrics The following metrics have been used to compare the performance of original AODV protocol and proposed AODV protocol in presence of compromised nodes: End-to End Delay, Round Trip Time (RTT), Average simulation processing time at nodes for a packet, Average number of nodes receiving packets, Average number of nodes forwarding packets, Delays between current and other node, Number of data packets dropped and Throughput [2].

These show that the proposed scheme enhances the security of the routing protocol without causing substantial degradation in network performance. 4.3. Performance Evaluation This section consists of the results for the test cases. The recorded values were obtained by averaging over multiple runs for each test case. Graphical analysis was done using Trace Graph 2.02 [13]. 4.3.1. Acknowledgement packet receive time v/s RTT The network resources available to the nodes vary with simulation time and their availability decides the RTT. Figure 5 shows the Graph of Acknowledgment Packet receive time versus RTT. It is evident from Figure 5 that as time proceeds; RTT is lesser in the proposed AODV scheme, as compared to the original scheme. This is because of the limit (RREQ_ACCEPT_LIMIT) imposed on the number of RREQ packets being flooded in the network by malicious node and less number of intermediate nodes in the routes between genuine nodes. 14 12 10 Original AODV Proposed AODV RTT (sec) 8 6 4 2 0 2.63 4.42 5.46 7.89 12.63 13.44 14.14 15.31 16.77 17.03 ACK Packet Receive Time (sec) Fig. 5. Acknowledgement packet receive time versus round trip time 4.3.2. Cumulative Sum of Dropped Packets The number of packets dropped at a given instance of time in the simulation run determines the efficiency of the protocol. Figure 6, accommodates the information regarding the number of dropped packets throughout the simulation. It is found that during initial stages, the number of dropped packets is more in original AODV protocol since flooding of RREQ in the network causes congestion, and the route formation for genuine requests is delayed. During later stages, the unavailability of network resources causes the data packets to be dropped. Due to existence of optimum resource utilizations and no overload the number of dropped packets in proposed scheme is much less.

Cumulative sum of dropped pkts 3500 Original AODV 3000 Proposed AODV 2500 2000 1500 1000 500 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Simulation Time (sec) Fig. 6. Throughput of dropping packets 4.3.3. End-to-End Delay v/s Packet Size Figure 7 depicts how the proposed method affects the end-to-end delay. This is the average delay of all data packets. The delay in case of both data and AODV packets in the proposed scheme is lesser compared to that in the original AODV. avg End-to-End delay (sec) 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 Original AODV Proposed AODV 40 Packet Size (bytes) 1040 Fig. 7. Packet size versus average end-to-end delay 4.3.4. Packet size versus simulation time The comparison of simulation processing times, as illustrated in Figure 8, reveals that the proposed scheme incurs no additional overhead as compared to the original scheme.

Simulation processing time (sec) 3.E-05 3.E-05 2.E-05 2.E-05 1.E-05 5.E-06 0.E+00 Fig. 6. Average simulation processing time Original AODV Proposed AODV 40 Packet Size (bytes) 1040 4.3.5. Network information for sample scenario Table 2 gives the comparative study of network information for original AODV and proposed AODV. Table 2. Overall network simulation results Original AODV Proposed AODV Average End-to-end delay [sec] 0.32539 0.27576 Receiving packets 0.4356328083 0.3580786026 Forwarding packets 0.4285714286 0.3499688085 Average RTT [sec] 0.58819 0.45346 5. Conclusions In this paper we have aimed at detecting malicious nodes both prior to route formation and after it in a network using AODV as the base protocol. A malicious node launching DoS attacks is detected and isolated in a distributed manner by the neighbors using two parameters: RREQ_ACCEPT_LIMIT and RREQ_BLACKLIST_LIMIT. Any intermediate node turning malicious by modifying data/control packets, tunneling them, dropping them is detected by its neighbors listening to its activities in the promiscuous mode and using next-to-next-hop node information. The simulation results show that our scheme incurs minimal processing overhead, minimal performance degradation, increased security and increased efficiency in time. The techniques to isolate an intermediate malicious node detected by our scheme are to be investigated.

References [1] C. Perkins, S. Das, Ad hoc On-Demand Distance vector (AODV) Routing, RFC 3561, July 2003. [2] S. Corson, J. Macker, Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations, RFC 2501, January 1999. [3] Broch J., Maltz D.A., Johnson D.B., Hu Y.C., and Jetcheva J., A performance comparison of multi-hop wireless ad hoc network routing protocols, 4th International Conference on Mobile Computing and Networking (ACM MOBICOM 98), pages 85 97, Oct 1998. [4] Computer Science Department, University of Kentucky, Security in Ad hoc Networks http://cs.engr.uky.edu/~singhal/termpapers/fourth-paper.doc [5] Bruce Schneier, Applied Cryptography (Second Edition), John Wiley & Sons, 1996 [6] David B. Johnson, David A. Maltz, Yih-Chun Hu, The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR), IETF MANET Working Group, Internet Draft, April 2003. [7] Fall K. and Varadhan K. (Eds.), NS notes and documentation. http://www.mash.cs.berkely.edu/ns/, 1999. [8] UCB/LBNL/VINT, Network Simulator-NS, http://www.mash.cs.berkely.edu/ns, 1995. [9] Jacquetand P., Viennot L., Overhead in Mobile Ad-hoc network Protocols, INRIA Research Project RR-3965, 2000. [10] Karpijoki V., Signaling and routing security in mobile and ad-hoc networks.http://www.hut.fi/vkarpijo/iwork00/, 2000 (accessed on May 03, 2004). [11] Fall K. and Varadhan K. (Eds.), NS notes and documentation. http://www.mash.cs.berkely.edu/ns/, 1999 (accessed on May 03, 2004). [12] Wireless LAN medium access control (MAC) and physical layer (PHY) specifications, IEEE standard 802.11-1997, 1997. [13] Jaroslaw Malek, Trace Graph 2.02, http://www.geocities.com/tracegraph.