Collaborative Attacks on Routing Protocols in Ad hoc Networks

1. Collaborative Attacks on Routing Protocols in Ad hoc Networks NeelimaGupta University of Delhi India

2. 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

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

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

5. 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

6. 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

7. 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

8. Collaborative Black Hole Attack 3 1 2 5 S D 4 M2 M1 Neelima Gupta, Dept. of Computer Sc., University of Delhi

9. 1 3 RREQ RREQ RREQ RREQ 2 5 S RREQ D RREP 4 M2 RREQ M1 RREP Neelima Gupta, Dept. of Computer Sc., University of Delhi

10. Collaborative Black Hole Attack (cont.) 3 1 2 5 S D BH1 BH2 4 Neelima Gupta, Dept. of Computer Sc., University of Delhi

11. Collaborative Black Hole Attack (cont.) 3 1 2 5 S D BH1 BH2 4 Neelima Gupta, Dept. of Computer Sc., University of Delhi

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

13. 1 3 RREQ RREQ RREQ RREQ 2 5 RREP RREP RREP RREP S RREQ D RREP 4 M2 RREQ RREQ M1 RREP RREP Dr. Neelima Gupta, Dept. of Computer Sc., University of Delhi

14. Collaborative Black Hole Attack (cont.) 3 1 2 5 S D BH1 BH2 4 Neelima Gupta, Dept. of Computer Sc., University of Delhi

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

16. Collaborative Black hole and Wormhole attack RREQ BH1 a2 RREQ RREQ WH1 a3 RREP a1 WH2 Out-of-Band Channel RREP RREQ RREQ RREP S D RREP RREQ RREP c1 c4 RREQ c2 RREQ c3 RREP RREP Neelima Gupta, Dept. of Computer Sc., University of Delhi

17. Collaborative Black hole and Wormhole attack (cont.) BH1 a2 WH1 a3 a1 WH2 S D c1 c4 c2 c3 Neelima Gupta, Dept. of Computer Sc., University of Delhi

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

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

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

21. 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, ManoharSreekantaradhya, 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

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

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

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

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

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

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

28. 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. Neelima Gupta, Dept. of Computer Sc., University of Delhi

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

30. 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

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

32. 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

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

34. Challenges Two much of overhead in monitoring even if no attack is present. in isolating the malicious nodes recursively. We propose: Get a count of the packets received from the destination. If the count is less than a threshold then monitor. 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

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

36. Thank You!!! Neelima Gupta, Dept. of Computer Sc., University of Delhi