Review of IP traceback Ming-Hour Yang The Department of Information & Computer Engineering Chung Yuan Christian University

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

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

Flooding-base DDoS Attacks

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?

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

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)

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

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

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

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

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

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

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

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

Examples of marking-Packet oriented hybrid IP traceback

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

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

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

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

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

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

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)

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

Example of marking and logging-RIHT

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

Example of path reconstruction -RIHT

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

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

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

Example of marking and logging-HAHIT

Example of path reconstruction -HAHIT

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

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

Maximum Size of Log Table 38

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

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

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

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

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

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

Marking scheme 45

Marking Scheme 46

() ≦ 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

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

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

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

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

55 Logging Scheme – (i) ≦ threshold

Logging Scheme – Table has filled up 56

Logging Scheme – Mark had existed 57

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

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

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

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

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

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

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 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 Reconstruction Scheme- D(R i )>threshold(2)

Reconstruction Scheme 69

70

71 Reconstruction Scheme- D(R i )>threshold

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

Storage Overhead – Average logging times 73

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

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

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

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

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

False Positive 79

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

Thanks for your attention 81