Review of IP traceback Ming-Hour Yang The Department of Information & Computer Engineering Chung Yuan Christian University [email protected].

Review of IP traceback

Ming-Hour Yang

The Department of Information & Computer Engineering

Chung Yuan Christian University

[email protected]

Outline

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

Introduction

DoS attack/DDoS attackFlooding based DoS attack

SYN flooding attack, SmurfSoftware exploit attack

LAND attack

IP source address spoofingHide 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 routersBorder routers

R9

R2

R5

R4

R3

R1

R7

R8

R6

Victim

Host

Attacker

Legitimate traffic

Link

Attack path

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 attackPacket marking-PPM, DPM ICMP message – iTrace(draft-ietf-itrace-04.txt

), backscatter Software exploits attack

Packet logging-SPIE,Bloom FilterHybrid IP traceback

https://tools.ietf.org/html/draft-ietf-itrace-04.txt

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

R2R1

Fragments of R2's IP

…1 2 K-1 K

PnP1 ...

PnP1 ...

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

R2R1PnP1 ...

1

0

1

1

0

H1(P1.digest)H2(P2.digest)

HK(Pn.digest)

…

Hybrid IP Traceback

13

Single packet traceback Reduce storage requirement Software exploit D/DOS attack Hybrid IP Traceback Categories

Digest packetsLog 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 twoHuffman 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 fieldMORE uses 16-bit marking field

Examples of marking-Packet oriented hybrid IP traceback

R3R2R1

Host

fixed-length 00120002

Huffman codes on R2

Huffman codes on R3

0102 0112 1002 1012

10121002 1102 1112 002 012

11121102 002 012 102

Interface number 10 2 3 4 5

11

1

0 0

0

2

22

3

34

3

4

5

000000002MRT and MORE000000012Huffman codes

000000012

000011112000010112

001111012

Marking field (8bits)000000012 000010012 010011012Fixed-length

R1, D(R1) = 4 R2, D(R2) = 5 R3, D(R3) = 6

R3R2R1

Host

fixed-length 00120002

Huffman codes on R2

Huffman codes on R3

0102 0112 1002 1012

10121002 1102 1112 002 012

11121102 002 012 102

Interface number 10 2 3 4 5

11

0

0 1

5

2

22

3

34

3

4

0

000000002MRT and MORE000000012Huffman codes

000000002

000011112000000002

001111012

Marking field (8bits)000000012 000010012 010011012Fixed-length

R1, D(R1) = 4 R2, D(R2) = 5 R3, D(R3) = 6

Problems in packet oriented hybrid IP traceback schemes Logging schemes in Huffman codes, MRT

and MORELog <digest, marking field> 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

Bit offset0

326496

128

0-3 4-7 8-15 16-18 19-31Version Header length TOS Total length

Identification field Flag Fragment offsetTTL Protocol Header checksum

Source addressDestination address

160or

196+

Options160

Payload (first 8bytes)

Log every packets-MPLS hybrid

20

Log the mark Switch label and router ID on the packet

R2R1

Inlabel Packet flow Outlabel

L F L

…

…

…

21

Exhaustive search required for table probing

Inlabel Packet flow Outlabel

L F L

…

…

…

131071

R2R1

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 markingPacket comes from the LANPacket comes from other routers

New marking field = marking field × (degree +1) + (IN +1)

Bit offset0

326496

128




160or

196+

Options160


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

‧‧‧

8

R1

D(R1)= 3

R2

D(R2)= 3R3

D(R3)= 4

marknew = ( 60 x 4 + 2 ) = 242

0

00

1

1

1

2

2

23

marknew = 242 x 4 + 2 = 970needs to log

P.m

ark = 242

P.mark = 32 P.mark = 163

P.mark = 60

marknew = ( 32 x 5 + 3 ) = 163

Source router‧‧‧

242‧‧‧

marknew = ( 8 x 4 + 0 ) = 32

mark

0

‧‧‧

Hash Table, m = 16

IN

‧‧‧

2‧‧‧

R4

R5

R6 R7

Path reconstruction -RIHT

26

𝑜𝑙𝑑 𝑚𝑎𝑟𝑘( )= ÷( 𝑜𝑟 𝑖𝑛𝑑𝑒𝑥 𝑚𝑎𝑟𝑘 𝑑𝑒𝑔𝑟𝑒𝑒+1)

𝐼𝑛𝑡𝑒𝑟𝑓𝑎𝑐𝑒. = 𝐼𝐷 𝑚𝑎𝑟𝑘 𝑚𝑜𝑑( +1)−1𝑑𝑒𝑔𝑟𝑒𝑒

Example of path reconstruction -RIHT

‧‧‧

8

R1

D(R1)= 3

R2

D(R2)= 3R3

D(R3)= 4

0

00

1

1

1

2

2

23

mark

req = 242

markreq = 32 markreq = 163

markreq = 60Source router

‧‧‧

242‧‧‧

mark

0

‧‧‧

Hash Table, m = 16

IN

‧‧‧

2‧‧‧

R4

R5

R6 R7

IN'ij = 163 % 5 = 3

markold = 163 / 5 = 32IN'i

j = 32 % 4 = 0 = IN'i-1

index = 32 / 4 = 8 ≠ 0logged on this router

loads HT[index] gets markold = 242

and IN'ij = 2

IN'ij = 242 % 4 = 2

markold = 242 / 4 = 60

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)

29

16 bits mark to mitigate the false positive

Bit offset0

326496

128




160or

196+

Options160


Log table of HAHIT

‧‧‧


markindex

0

HTk

UI

‧‧‧

l Pj.mark UIi‧‧‧

‧‧‧

‧‧‧

[Tt, Tt+1 )

Small index small table

Easy overflow

Table number

R1

D(R1)= 3

R2

D(R2)= 3 R3

D(R3)= 4

marknew = 7321 x 4 + (0 + 1) = 29285

2

1

0

2

1

0

1

0 2 3

marknew = 29285 x 4 + (2 + 1) = 117143needs to log

k = Htable(P1.srcIP) = 0l1 = Hindex(P1.mark) = 1

P1 .m

ark = 29285

P1.mark = 4 P1.mark = 23

P1.mark = 7321

marknew = 4 x 5 + (2 + 1) = 23

marknew = ( 1 x 4 ) = 4

R4

R5

R6 R7

1

Source router

17281

markindex

0

R2's HT0

UI

2

2

3

4

5

6

7

[T1, T∞ )marknew = Pj.mark x ( D(Ri) + 1 ) + (UIi + 1)

Example of marking and logging-HAHIT


R1

D(R1)= 3

R2

D(R2)= 3 R3

D(R3)= 4

marknew = 4166 x 4 + (0 + 2) = 16667

2

1

0

2

1

0

1

0 2 3



P2 .m

ark = 16667

P2.mark = 20 P2.mark = 103

P2.mark = 4166

marknew = 20 x 5 + (2 + 1) = 103

marknew = ( 5 x 4 ) = 20

R4

R5

R6 R7

1

Source router

30170

markindex

0

R2's HT3

UI

1

2

3 32177 1

4 16576 0

5 16667 2

6 24801 2

7 19651 2

[T0, T∞ )

1

2

34

5

marknew = Pj.mark x ( D(Ri) + 1 ) + (UIi + 1)


R1

D(R1)= 3

R2

D(R2)= 3 R3

D(R3)= 4

2

1

0

2

1

0

1

0 2 3



R4

R5

R6 R7

P3.mark = 17282

1

Source router

29285

markindex

0

R2's HT0

UI

2

2 25109 0

3 23428 1

4 27116 1

5 27718 0

6 20293 0

7 17203 1

[T0, T∞ )marknew = Pj.mark x ( D(Ri) + 1 ) + (UIi + 1)


R1

D(R1)= 3

R2

D(R2)= 3 R3

D(R3)= 4

2

1

0

2

1

0

1

0 2 3



P3.mark = 24 P3.mark = 123

marknew = 24 x 5 + (2 + 1) = 123

marknew = ( 6 x 4 ) = 24

R4

R5

R6 R7

P3.mark = 17282

1

Source router

29285

markindex

0

R2's HT0

UI

2

2 25109 0

3 23428 1

4 27116 1

5 27718 0

6 20293 0

7 17203 1

1

Source router

markindex

0

R2's HT0

UI

2

3

4

5

6 17282 1

7

[T0, T1)[T1, T∞ )marknew = Pj.mark x ( D(Ri) + 1 ) + (UIi + 1)

Example of path reconstruction -HAHIT

R1

D(R1)= 3

R2

D(R2)= 3

R3

D(R3)= 4

2

1

0

2

1

0

1

0

2

3

mark

req = 29585

markreq = 4

markreq = 23

markreq = 7396R4

R5

R6 R7

UI3 = 23 % 5 - 1 = 2markold = 23 / 5 = 4

UI2 = 4 % 4 - 1 = -1 l1 = 4 / 4 = 1 ≠ 0

T0 < Tr < T1

k = Htable(srcIPreq) = 0

gets markold = 29585and UI2 = 2

UI1 = 29585 % 4 - 1 = 0markold = 29585 / 4 = 7396

1

Source router

29285

markindex

0

R2's HT0

UI

2

2 25109 0

3 23428 1

4 27116 1

5 27718 0

6 20293 0

7 17203 1

[T0, T1)

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

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

2 15 28 41 54 67 80 93 1061191321451581711841972102232362492622752883013143273403533663793924054184314

8

16

32

64

128

256

512

1024

2048

4096

8191.99999999998

Degree of Router

Lo

g T

able

’s S

ize

4 8 16 32 64 128 256 512 1024 2048 4096 8191

0

100000

200000

300000

400000

500000

600000

700000

800000

900000

1000000

1

3

5

7

9

15

44

63

Log Table’s Size

Ave

rag

e L

og

gin

g T

imes

(10T

ho

usa

nd

)

Log Table’s Size and Threshold

39

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 Marknew(1)

42

if Pj is come from LAN

Pj.mark = 0

Else

marknew = Pj.mark × (D(Ri) + 1) + UIi + 1

if marknew > 65535 then

Logging and compute marknew

Else

Pj.mark = marknew

endif

forward the packet to the next router

end



Compute The Marknew(2)

43


Pj.mark = 0

Else




Else

Pj.mark = marknew

endif


end



Determine Packet Status

44


Pj.mark = 0

Else




Else

Pj.mark = marknew

endif


end



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

‧‧‧


markindex

0

HTk

l Pj.mark‧‧‧

‧‧‧

[Tt, Tt+1 )

‧‧‧


markindex

0

HTk

UI

‧‧‧


‧‧‧

‧‧‧

[Tt, Tt+1 )

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





50

Determine Log Table StatusCompute the marknew





Get Index of Log Table

51

Compute the marknew





Log Packet Mark

52

Compute the marknew





Compute Marknew

53

Compute the marknew





‧‧‧


markindex

0

HTk

UI

‧‧‧


‧‧‧

‧‧‧

[Tt, Tt+1 )

54

55

Logging Scheme – ( i) 𝐷 𝑅 ≦threshold

1

Source router

17282

markindex

0

R2's HT0

[T1, T∞ )

P4.mark = 68

1

Source router

17952

markindex

0

R2's HT0

2 25109

3 23428...

…

[T0, T1)

9 26227

10 20238

11 29285

R1

D(R1)= 3

R2

D(R2)= 3R3

D(R3)= 4

2

1 0

2

1

0

1

0 2 3

R5

R6 R7

P4.mark = 343

P4.mark = 17282

Logging Scheme – Table has filled up

56

Logging Scheme – Mark had existed

57

1

Source router

25689

markindex

0

R3's HT3

UI

1

2 30958 1

3 64015 2

4 17094 0

5 26785 2

6 24187 2

7 17453 1

[T0, T∞ )

R1

D(R1)= 3

R2

D(R2)= 3R3

D(R3)= 4

2

1 0

2

1

0

1

0 2 3

R5

R6 R7

P2.mark = 64015P2.mark = 15

P2.mark = 4000

P2.mark = 16003

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:Pj.mark, Pj.srcIP, Tr

UIi = Pj.mark % (D(Ri) + 1) – 1

if UIi = -1

The packet had log in this router

else

markold = Pj.mark / (D(Ri) + 1)

send reconstruction request with markold and Pj.srcIP to upstream router by UIi

Endif








60

input:Pj.mark, Pj.srcIP, Tr

UIi = Pj.mark % (D(Ri) + 1) – 1

if UIi = -1

The packet had log in this router

else

markold = Pj.mark / (D(Ri) + 1)

send reconstruction request with markold and Pj.srcIP to upstream router by UIi

endif

Compute Upstream Interface ID Send reconstruction request to upstream

router







Determine The Logging Status

61








62

Compute Log Table’s Index Send reconstruction request to upstream

router







Determine The Router Status

63




Compute the log table’s index Determine the logging status



Find Out Log Table(1)

64








Find Out Log Table(2)

65




Compute thelog table’s index


Compute upstream interface ID Get reconstruction request

Send Request to Upstream Router

66



Determine the router status Compute the log table’s index




67

l = Pj.mark /(D(Ri) + 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(Ri)>threshold(1)

68

Reconstruction Scheme-D(Ri)>threshold(2)

Reconstruction Scheme

69

R1

D(R1)= 3

R2

D(R2)= 3R3

D(R3)= 4

2

1 0

2

1

0

1

0 2 3

R5

R6 R7

P1.mark = 29285

P1.mark = 172P1.mark = 863

P1.mark = 7321

70

1

Source router

17282

markindex

0

R2's HT0

[T1, T∞ )

1

Source router

17952

markindex

0

R2's HT0

2 25109

3 23428...

…

[T0, T1)

9 26227

10 20238

11 29285

R1

D(R1)= 3

R2

D(R2)= 3R3

D(R3)= 4

2

1 0

2

1

0

1

0 2 3

R5

R6 R7

P1.mark = 29285

P1.mark = 172P1.mark = 863

P1.mark = 7321

1

Source router

25689

markindex

0

R3's HT3

UI

1

2 30958 1

3 64015 2

4 17094 0

5 26785 2

6 24187 2

7 17453 1

[T0, T∞ )

R1

D(R1)= 3

R2

D(R2)= 3R3

D(R3)= 4

2

1 0

2

1

0

1

0 2 3

R5

R6 R7

P2.mark = 64015P2.mark = 15

P2.mark = 4000

P2.mark = 16003

71

Reconstruction Scheme-D(Ri)>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

1 2 3 4 50

1

2

3

4

5

6

7

8

HAHITOur SchemeRIHT

Packets Numbers(10M)

Ave

rag

e L

og

gin

g T

imes

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 Scheme 0.7MB ~ 0.8MB

HAHIT 1.5MB ~ 2MB

RIHT 320KB

0.1 1 2 3 4 50

0.51

1.52

2.53

3.5

HAHIT Our SchemeRIHT

Packet Numbers (10M)

Sto

rag

e

Ov

erh

ea

d

(MB

)

Storage Overhead – Average case

75

Log table size not remains intact


packets into network

Storage Overhead

Our Scheme 172KB ~ 220KB

HAHIT 1.5MB ~ 2MB

RIHT 320KB

0.1 1 2 3 4 50

0.51

1.52

2.53

3.5

HAHIT RIHTOur Scheme


Sto

rag

e

Ov

erh

ea

d

(MB

)

Average Storage Overhead – Worst case

76

Average storage of all routers

Log table size remains intact


packets into network

Storage Overhead

Our Scheme 0.5MB

HAHIT 1.5MB

RIHT 0.37MB

1 2 3 4 50

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8



Sto

rag

e

Ov

erh

ea

d

(MB

)

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

1 2 3 4 50

0.5

1

1.5

2

2.5



Av

era

ge

Pro

bin

g

Tim

es

Average Probing Times

Our Scheme

2

HAHIT 2

RIHT 1

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

1 2 3 4 50

2000000

4000000

6000000

8000000

10000000

12000000

14000000

0 0 0 0 0

RIHTOur SchemeHAHIT

Packet Numbers(10M)

Fa

lse

Po

sit

ive

s

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

Review of IP traceback Ming-Hour Yang The Department of Information & Computer Engineering Chung Yuan Christian University [email protected].

Documents

packet packet

attack packets packet

marking field slide

marking schemes

digest slide

attack paths

packet travel

traceback approaches