1. Review of IP traceback Ming-Hour Yang The Department of Information & Computer Engineering Chung Yuan Christian University mhyang@cycu.edu.tw

2. Outline Introduction to (D)DoS attacks Why Traceback Traceback Schemes Hybrid IP traceback Conclusion

3. Introduction DoS attack/DDoS attack  Flooding based DoS attack SYN flooding attack, Smurf  Software exploit attack LAND attack IP source address spoofing  Hide the origin of attacker

4. Flooding-base DDoS Attacks

5. Challenges to Against DDoS Attack Hard to separate attack packets from legitimate ones  Attack traffic usually comprises legitimate packets. Source IP address can be forged  Attackers can hide themselves by forging source IP address randomly.  It is hard to identify malicious packets according to their source addresses. Hard to prevent attack traffic from entering the Internet  DDoS traffic is distributed.  It could be too late if defense mechanisms drop attack packets in the proximity of the victim.  Why not Egress filtering?

6. Traffic in the network Network architecture  Core routers  Border routers

7. Give a Tracking Clue to Attack packets Packet logging  Intermediate nodes huge storage support  Low false positive rate by Bloom Filter Packet Marking  Marking Field is limited while marking on IP Header, Low Precision  No storage overhead Messaging  Routers probabilistically send ICMP messages, which contains the forwarding nodes the packet travel through, to the destination node.  Victims reconstruct attack paths from received ICMP messages.  Backscatter messages (ICMP error messages)

8. Traceback Approaches Flooding based DoS attack  Packet marking-PPM, DPM  ICMP message – iTrace(draft-ietf-itrace- 04.txt), backscatterdraft-ietf-itrace- 04.txt Software exploits attack  Packet logging-SPIE,Bloom Filter  Hybrid IP traceback

9. Assumptions The attackers knows the traceback approaches The attackers intend to pollute the tracing data The router knows the routers or its local network where the packets come from. All of the routers work together in marking and logging scheme and reconstruction scheme The path of traffic or the topology might be changed, but not often Packet marking schemes use the identification field, flags field and fragment offset field of IP header to be the 32-bit marking field, or use identification field to be 16-bit marking field

10. LOCATE ATTACKERS IN ONE PACKET Packet-marking schemes Packet-logging schemes Hybrid schemes

11. Packet-Marking Schemes 11 Must collect a lot of packets No storage requirement Node sampling Edge sampling Path

12. Packet-Logging Schemes 12 Single packet traceback High storage requirement Software exploit D/DOS attack 1 0 1 1 0 H 1 (P 1.digest) H 2 (P 2.digest) H K (P n. digest) …

13. Hybrid IP Traceback 13 Single packet traceback Reduce storage requirement Software exploit D/DOS attack Hybrid IP Traceback Categories  Digest packets  Log path information

14. Hybrid IP traceback-Packet Oriented Choi and Dai  Fixed-length Does not use the marking field efficiently, if degree of router is not a power of two  Huffman codes Using Huffman coding to reduce the bits required for marking Better performance when the traffic distribution for each interface is unequal

15. Hybrid IP traceback-Packet Oriented Malliga and Tamilarasi  MRT and MORE scheme New marking field = marking field × degree + IN Old marking field = marking field ÷ degree IN = marking field MOD degree  MRT uses 32-bit marking field  MORE uses 16-bit marking field

16. Examples of marking-Packet oriented hybrid IP traceback

17. Problems in packet oriented hybrid IP traceback schemes Logging schemes in Huffman codes, MRT and MORE  Log into log table and clear the marking field High storage requirement False positive rate Exhaustive search in reconstruction schemes

18. Path based hybrid IP traceback schemes  A Novel Approach for Single-Packet IP Traceback Based on Routing Path  RIHT: A Novel Hybrid IP Traceback Scheme  Hybrid Single-Packet IP Traceback with Low Storage and High Accuracy(HAHIT)  Storage-Efficient 16-Bit Hybrid IP Traceback with Single Packet 18

19. A Novel Approach for Single-Packet IP Traceback Based on Routing Path Packet Marking  Establish and switch label by MPLS Marking information  Upstream router ID  Inlabel

20. Log every packets-MPLS hybrid 20 Log the mark Switch label and router ID on the packet InlabelPacket flowOutlabel LFL … … …

21. 21 Exhaustive search required for table probing InlabelPacket flowOutlabel LFL … … … 131071 Path reconstruction –MPLS hybrid

22. MPLS hybrid traceback scheme 22 Advantage  Storage was bounded by path number Disadvantage  Logging on every router  High computation loads and impractical

23. RIHT: A Novel Hybrid IP Traceback Scheme Packet marking  Packet comes from the LAN  Packet comes from other routers New marking field = marking field × (degree +1) + (IN +1)

24. Log the mark - RIHT Overwhelm the mark Index  H(mark)  Search empty indexed entry by quadratic probing New mark = index × (degree +1)

25. Example of marking and logging-RIHT

26. Path reconstruction -RIHT 26 ( )=÷( +1).= (+1)−1

27. Example of path reconstruction -RIHT

28. RIHT Hybrid Traceback Scheme 28 Advantage  Storage was bounded by path number Disadvantage  False positive rate grow with packet numbers

29. Hybrid Single-Packet IP Traceback with Low Storage and High Accuracy(HAHIT) 29 16 bits mark to mitigate the false positive

30. Log table of HAHIT Small index  small table Easy overflow Table number

31. Example of marking and logging-HAHIT

35. Example of path reconstruction -HAHIT

36. Analysis Skitter Project topology by CAIDA  Average hop count of paths is 15.86  Total number of its routers is 130,267  Average upstream degree is 3.89, max is 420  244,914 complete paths

37. Analysis Number of paths could hash table log  The load factor of hash table is α = l ÷ m l is the number of logged paths in hash table m is the size of hash table  Upper bound of α is used to be 0.5  Hash table can log m ÷ 2 paths If the hash table is full  Double the size of hash table  Log into different hash tables by G(left 24b its of P.srcIP) mod j j is the number of hash tables

38. Maximum Size of Log Table 38

39. Log Table’s Size and Threshold 39 Log table size:8 Threshold:10 Log table size:8 Threshold:10

40. Reduce storage overhead  Improve storage overhead caused by quadratic probing  Reduce times of duplicate log Storage-Efficient 16-Bit Hybrid IP Traceback with Single Packet 40

41. Marking Scheme(2) 41 To determine packet status To compute the marknew

42. Compute The Mark new (1) 42 if P j is come from LAN P j.mark = 0 Else mark new = P j.mark × (D(R i ) + 1) + UI i + 1 if mark new > 65535 then Logging and compute mark new Else P j.mark = mark new endif forward the packet to the next router end To determine packet status To compute the marknew

43. Compute The Mark new (2) 43 if P j is come from LAN P j.mark = 0 Else mark new = P j.mark × (D(R i ) + 1) + UI i + 1 if mark new > 65535 then Logging and compute mark new Else P j.mark = mark new endif forward the packet to the next router end To determine packet status To compute the marknew

44. Determine Packet Status 44 if P j is come from LAN P j.mark = 0 Else mark new = P j.mark × (D(R i ) + 1) + UI i + 1 if mark new > 65535 then Logging and compute mark new Else P j.mark = mark new endif forward the packet to the next router end To determine packet status To compute the marknew

45. Marking scheme 45

46. Marking Scheme 46

47. () ≦ threshold  log more packet mark in a log table  Reduce times of duplicate log ()>threshold  Log UI in the log table Logging Scheme(1) 47

48. Logging Scheme (2) 48 Compute the marknew Log packet mark(packet mark&UI) Get index of log table Determine log table status Get log table number

49. 49 Get Log Table Number Compute the marknew Log packet mark(packet mark&UI) Get index of log table Determine log table status Get log table number

50. 50 Determine Log Table Status Compute the marknew Log packet mark(packet mark&UI) Get index of log table Determine log table status Get log table number

51. Get Index of Log Table 51 Compute the marknew Log packet mark(packet mark&UI) Get index of log table Determine log table status Get log table number

52. Log Packet Mark 52 Compute the marknew Log packet mark(packet mark&UI) Get index of log table Determine log table status Get log table number

53. Compute Mark new 53 Compute the marknew Log packet mark(packet mark&UI) Get index of log table Determine log table status Get log table number

54. 54

55. 55 Logging Scheme – (i) ≦ threshold

56. Logging Scheme – Table has filled up 56

57. Logging Scheme – Mark had existed 57

58. Reconstruction Scheme 58 Send reconstruction request to upstream router Find out log table that has packet mark Determine the router status Compute the log table’s index Determine the logging status Compute upstream interface ID Get reconstruction request

59. Get Reconstruction Request 59 input:P j.mark, P j.srcIP, T r UI i = P j.mark % (D(R i ) + 1) – 1 if UI i = -1 The packet had log in this router else mark old = P j.mark / (D(R i ) + 1) send reconstruction request with mark old and P j.srcIP to upstream router by UI i Endif Send reconstruction request to upstream router Find out log table that has packet mark Determine the router status Compute the log table’s index Determine the logging status Compute upstream interface ID Get reconstruction request

60. 60 input:P j.mark, P j.srcIP, T r UI i = P j.mark % (D(R i ) + 1) – 1 if UI i = -1 The packet had log in this router else mark old = P j.mark / (D(R i ) + 1) send reconstruction request with mark old and P j.srcIP to upstream router by UI i endif Compute Upstream Interface ID Send reconstruction request to upstream router Find out log table that has packet mark Determine the router status Compute the log table’s index Determine the logging status Compute upstream interface ID Get reconstruction request

61. Determine The Logging Status 61 Send reconstruction request to upstream router Find out log table that has packet mark Determine the router status Compute the log table’s index Determine the logging status Compute upstream interface ID Get reconstruction request

62. 62 Compute Log Table’s Index Send reconstruction request to upstream router Find out log table that has packet mark Determine the router status Compute the log table’s index Determine the logging status Compute upstream interface ID Get reconstruction request

63. Determine The Router Status 63 Send reconstruction request to upstream router Find out log table that has packet mark Determine the router status Compute the log table’s index Determine the logging status Compute upstream interface ID Get reconstruction request

64. Find Out Log Table(1) 64 Send reconstruction request to upstream router Find out log table that has packet mark Determine the router status Compute the log table’s index Determine the logging status Compute upstream interface ID Get reconstruction request

65. Find Out Log Table(2) 65 Send reconstruction request to upstream router Find out log table that has packet mark Determine the router status Compute thelog table’s index Determine the logging status Compute upstream interface ID Get reconstruction request

66. Send Request to Upstream Router 66 Send reconstruction request to upstream router Find out log table that has packet mark Determine the router status Compute the log table’s index Determine the logging status Compute upstream interface ID Get reconstruction request

67. 67 l = P j.mark /(D(R i ) + 1) if not l = 0 this router is not the nearest border router to the attacker else this router is the nearest border router to the attacker endif Reconstruction Scheme- D(R i )>threshold(1)

68. 68 Reconstruction Scheme- D(R i )>threshold(2)

69. Reconstruction Scheme 69

70. 70

71. 71 Reconstruction Scheme- D(R i )>threshold

72. Analysis Storage overhead  Average logging times  Storage overhead in worst case  Storage overhead in average case  Average storage overhead in worst case Computation overhead  Packet logging  Path reconstruction False positive 72

73. Storage Overhead – Average logging times 73

74. Storage Overhead – Worst case 74 Log table size remains intact Storage overhead of the largest router  Send 0.1M~50M packets into the network Storage Overhead Our Scheme0.7MB ~ 0.8MB HAHIT1.5MB ~ 2MB RIHT320KB

75. Storage Overhead – Average case 75 Log table size not remains intact Storage overhead of the largest router  Send 0.1M~50M packets into network Storage Overhead Our Scheme172KB ~ 220KB HAHIT1.5MB ~ 2MB RIHT320KB

76. Average Storage Overhead – Worst case 76 Average storage of all routers Log table size remains intact Storage overhead of the largest router  Send 0.1M~50M packets into network Storage Overhead Our Scheme0.5MB HAHIT1.5MB RIHT0.37MB

77. Computation Overhead – Packet logging 77 Computation overhead  HAHIT and RIHT’s expectations of collision times is 2  Our scheme’s expectations of probing times is 4.5 and 6 75% of our probes is 0 Average probing times is 0.43 Probability of log table filled up is 0.008

78. Computation Overhead – Path reconstruction 78 Average Probing Times Our Scheme 2 HAHIT2 RIHT1 Our Scheme 、 HAHIT  Find out log table  Query mark logged in the table Our table is difficult to filled up than HAHIT

79. False Positive 79

80. Conclusion 80 Single packet traceback Storage overhead is bound by the number of paths Reassembly of fragmented packets Low storage overhead

81. Thanks for your attention 81