Collaborative Attacks on Routing Protocols in Ad hoc Networks Neelima Gupta University of Delhi India

Neelima Gupta, Dept. of Computer Sc., University of Delhi ATTACKS on Routing Protocols in AD-HOC NETWORKS Black Hole Wormhole Rushing Attack Many more Attacks

Neelima Gupta, Dept. of Computer Sc., University of Delhi Black Hole Attack: M RREQ RREP RREQ S D

Neelima Gupta, Dept. of Computer Sc., University of Delhi Worm Hole Attack: Malicious nodes eavesdrops the packets, tunnel them to another location in the network and retransmit them at the other end. M1M1 M2M2 S D

Neelima Gupta, Dept. of Computer Sc., University of Delhi Rushing Attack Forward ROUTE Requests more quickly than legitimate nodes can do so, increase the probability that routes that include the attacker will be discovered, Attack against all currently proposed on-demand ad hoc network routing protocols.

Neelima Gupta, Dept. of Computer Sc., University of Delhi Collaborative Attacks Informal definition: “Collaborative attacks (CA) occur when more than one attacker synchronize their actions to disturb a target network”

Neelima Gupta, Dept. of Computer Sc., University of Delhi Different Models of Collaborative Attack Collaborative Black hole attack Collaborative Black hole and Wormhole attack Collaborative Black hole and Rushing Attack

Neelima Gupta, Dept. of Computer Sc., University of Delhi Collaborative Black Hole Attack S M D 5 M1 3

Neelima Gupta, Dept. of Computer Sc., University of Delhi S M D 5 M1 3 RREQ RREP RREQ

Neelima Gupta, Dept. of Computer Sc., University of Delhi S BH D 5 BH1 3 Collaborative Black Hole Attack (cont.)

Neelima Gupta, Dept. of Computer Sc., University of Delhi S BH D 5 BH 1 3 Collaborative Black Hole Attack (cont.)

Existing Approaches Cross Validation from neighbours (especially Next Hop Neighbours) will fail Neelima Gupta, Dept. of Computer Sc., University of Delhi

Dr. Neelima Gupta, Dept. of Computer Sc., University of Delhi S M D 5 M1 3 RREQ RREP RREQ

Neelima Gupta, Dept. of Computer Sc., University of Delhi S BH D 5 BH 1 3 Collaborative Black Hole Attack (cont.)

Existing Approaches Neighbour monitoring M1 will escape Neelima Gupta, Dept. of Computer Sc., University of Delhi

Collaborative Black hole and Wormhole attack S WH 2 c4 a1 c1 D WH 1 c3 c2 BH 1 RREQ RREP Out-of-Band Channel a3 a2 RREQ RREP RREQ RREP

Neelima Gupta, Dept. of Computer Sc., University of Delhi Collaborative Black hole and Wormhole attack (cont.) S WH 2 c4 a1 c1 D WH 1 c3 c2 BH 1 a3 a2

Neelima Gupta, Dept. of Computer Sc., University of Delhi Collaborative Black hole and Rushing Attack S c4 a1 c1 D a3 R1 c3 c2 BH 1 a2 b2

Neelima Gupta, Dept. of Computer Sc., University of Delhi Collaborative Black hole and Rushing Attack (cont.) S c4 a1 c1 D R1 c3 c2 BH 1 RREQ RREP a3 a2 RREQ RREP b2 RREQ RREP RREQ RREP

Neelima Gupta, Dept. of Computer Sc., University of Delhi Collaborative Black hole and Rushing Attack (cont.) S c4 a1 c1 D R1 c3 c2 BH 1 a3 a2 b2

Neelima Gupta, Dept. of Computer Sc., University of Delhi Current Proposed Solutions to handle collaborative black hole attack Collacorative Monitoring: Collaborative security architecture for black hole attack prevention in mobile ad hoc networks, A Patcha and A Mishra, Proceedings of RAWCON ’03 Recursive Validation: Sanjay Ramaswamy, Huirong Fu, Manohar Sreekantaradhya, John Dixon and Kendall Nygard. Prevention of Cooperative Black Hole Attack in wireless Ad-Hoc Networks, Intl Conference on wireless netwroks, 2003

Neelima Gupta, Dept. of Computer Sc., University of Delhi Collaborative Black Hole Attack S D M2 W W M1

Neelima Gupta, Dept. of Computer Sc., University of Delhi Consider this scenario- S D M2 W1 W RREQ RREP M1 Tell W1 to monitor M1

Neelima Gupta, Dept. of Computer Sc., University of Delhi Case 1: M1 itself drops packets S D M2 W W Data Packets M1 Buffer of sent packets to M1 Packets are not forwarded; M1 is Malicious

Neelima Gupta, Dept. of Computer Sc., University of Delhi Case 2: M1 forwards but does not inform watchdog to monitor M2 S D M2 W W Data Packets M1 Buffer of sent packets to M1 Overhear the packets but does not know the next hop id; increments SUSPECT_NODE counter ->M1 is Malicious Does not send SEND_DATA signal

Neelima Gupta, Dept. of Computer Sc., University of Delhi Case 3: M1 forwards and informs but M2 drops..will be caught by W2 S D M2 w1 w2 Data Packets M1 Buffer of sent packets to M1

Neelima Gupta, Dept. of Computer Sc., University of Delhi S D M2 WW M1 Buffer of sent packets to M1 Packets are not forwarded; M2 is Malicious SEND_DATA signal

Neelima Gupta, Dept. of Computer Sc., University of Delhi Analysis Problem with this appraoch ◦ Monitoring is done during data transmission => loss of data packets. The current solutions does not specify if and how the lost data is re-transmitted Solution : Some dummy packets may be sent before sending the data packets.

S 2 1 D M W W Data Packets M does not have a route to D, so forward to 3 (not in route) Data Packets 3 NULL or NON-NULL Node Neighbor List : M Neighbor List : 3 W

Neelima Gupta, Dept. of Computer Sc., University of Delhi Another Problem ◦ Malicious Nodes acting together can alternately drop packets to keep their individual SUSPECT_NODE counter less than SUSPECT_THRESHOLD, each time a route is established through them. ◦ Malicious nodes would not be detected. ◦ Data packets are permanently lost.

Neelima Gupta, Dept. of Computer Sc., University of Delhi Recursive neighbor validation D S B3 C2 A2 A1 B1 C3 C1 B2 A3 A4 B4 C4 B5 RREQ RREP Intermediate Node, IN Next Hop Node, NHN RREP

Neelima Gupta, Dept. of Computer Sc., University of Delhi Current Proposed Solution to handle collaborative attack Weichao Wang, Bharat Bhargava, Yi Lu, and Xiaoxin Wu. Defending against wormhole attacks in mobile ad hoc networks. In Wiley Journal Wireless Communications and Mobile Computing (WCMC), volume 6, pages 483 –503. Wiley, 2006.

Neelima Gupta, Dept. of Computer Sc., University of Delhi Monitoring / characterizing Defense Classification No anomaly anomaly Negligible anomaly Attack handled Attack detected

Challenges Two much of overhead in monitoring even if no attack is present. in isolating the malicious nodes recursively. We propose: 1. Get a count of the packets received from the destination. 2. If the count is less than a threshold then monitor. 3. If a node drops more than a certain threshold, declare it to be malicious. If more than one node drops packet, their sum is compared against the threshold. If greater, both the nodes are delcared to be malicious Neelima Gupta, Dept. of Computer Sc., University of Delhi

NEED TO THINK DIFFERENTLY Neelima Gupta, Dept. of Computer Sc., University of Delhi

Thank You!!!