Practical Network Support for IP Traceback

1
Practical Network Support for IP Traceback

• By Stefan Savage, David Wetherall, Anna Karlin
  Tom Anderson
• Affiliation Department of Computer Science and
  Engineering at the University of Washington
• Published ACM SIGCOMM Conference, 2000
• Presented by Andrew Mantel
• Presentation date March 19, 2009
• Class CAP6135 Malware and Software
  Vulnerability Analysis (Spring 2009)
• Professor Dr. Cliff Zou

2
Outline

• Goal / Motivation
• Background
• Previous work
• Terminology
• Marking algorithms
• Experiment
• Authors limitations / extensions
• My review

3
Goal / Motivation

• Goal
• Describe a technique for tracing anonymous
  packet flooding attacks in the Internet back
  towards their source (Savage et al, 295)
• Motivation
• Increase in denial of service (DoS) flood attacks
• From 1989 to 1995, CERT reported 50 increase per
  year
• Eliminate the problem by not allowing the
  attacking computer to hide

Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
4
What this paper is and isnt

• This paper isnt
• A perfect solution
• Cannot find the real attacker
• Very difficult problem (examples
  compromisedhost attack, reflector attack)
• This paper is
• A practical solution
• Traceback problem Find the direct attacker
• Still a difficult problem due to IP spoofing

(Source http//www.yojoe.com/)
(Source http//raw.channelfrederator.com/)
Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
5
Vulnerability of IP protocol to anonymous attacks
Sample IP Packet (IPv4)
(Modified from source http//en.wikipedia.org/wik
i/IPv4Header)

• Source address is specified by the sender
• Can spoof as long as the attack doesnt rely on
  return traffic

Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
6

• Previous Work

7
Previous work 1 Ingress Filtering

• Goal
• Prevent attackers from spoofing the source IP
• Approach
• Routers block packets with illegitimate source
  addresses
• Cost
• Computational cost to verify source address
• Farther away from the source, harder to verify
  the address
• Problems
• Requires universal deployment
• Attacker could spoof a valid address

Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
8
Previous work 2.1 Input debugging

• Input debugging router feature to filter
  particular packets on some egress port and
  determine which ingress port they arrived on
  (Savage et al, 296)
• Approach
• Victim identifies signature of attacker packet
• Victim calls a network operator who uses input
  debugging to trace the packet port upstream
• Process continues, possibly across ISP borders,
  until the source site is found
• Problems
• Assumes attack is in progress
• Requires too much cooperation / coordination

Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
9
Previous work 2.2 Controlled flooding

• Approach
• Using a map of Internet topology, victim asks
  some hosts to iteratively flood each incoming
  link on the router closest to the victim
• Network buffer fills up, and attacker packets
  start dropping
• Monitor change in rate of incoming attacker
  packets to determine which link they came from
• Repeat recursively until source is found.
• Problems
• Controlled flooding is a DoS attack
• Requires a topological map of the Internet and
  willing flooding hosts
• Not effective against DDoS attack
• Cant be used post-mortem

Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
10
Previous work 3 Logging

• Approach
• Log packets at key routers and then use data
  mining techniques to determine the path that the
  packets traversed (Savage et al, 297)
• Strength
• Can be used post-mortem
• Problems
• Large resource requirements
• Requires large scale inter-provider database
  integration

Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
11
Previous work 4 ICMP Traceback

• Approach
• Every router randomly selects (with low
  probability) a packet it is forwarding
• Copies this packet to a special ICMP traceback
  message
• Includes info about the adjacent routers the
  packet travelled through
• If an attack occurs, use these ICMP traceback
  messages to reconstruct the path back to the
  attacker
• Problems
• ICMP traffic gets limited/dropped
• Not all routers can debug the message
• Doesnt work well without universal deployment
• Attacker could send fake ICMP traceback messages

Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
12
Overview of previous work
(Savage et al, 297)
Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
13

• Terminology

14
Attack path

• Symbols
• V Victim
• Ai Attack origin i
• Ri Router i
• Attack path unique ordered list of routers from
  Ai to V
• Example R6, R3, R2, R1

(Savage et al, 298)
Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
15
Approximate traceback problem

• Exact traceback is very difficult
• MAC address spoofing of source
• Insert false routers
• Focus on approximate traceback
• Find attack path with valid suffix
• Valid suffix Suffix of attack path is the true
  attack path
• Example R5, R6, R3, R2, R1
• Robust Attacker cant stop the victim from
  finding the valid suffix

FRi Fake Router i inserted by an
attacker (Modified from Figure 1, Savage et al,
298)
Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
16
Assumptions

• An attacker may generate any packet
• Multiple attackers may conspire
• Attackers may be aware they are being traced
• Packets may be lost or reordered
• Attackers may send numerous packets
• The route between attacker and victim is fairly
  stable
• Routers are both CPU and memory limited
• Routers are not widely compromised

intelligent attacker
nature of modern networks
solution cant be costly
would destroy traceback
Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
17

• Marking Algorithms

18
Node append

• Simplest marking algorithm
• Algorithm
• Each router appends its address to the end of the
  packet
• Victim can reconstruct path from the ordered list
• Strengths
• Reconstruct path from a single packet
• Weaknesses
• High overhead to append data in flight
• May not have enough space for all addresses
• Attacker could just fill this space beforehand

Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
19
Node sampling

• Algorithm
• Add a node field to the packet header
• Each router has the same probability p of
  overwriting this node field with their address
• Path reconstruction
• Same p used by every router
• Will receive more packets marked by a certain
  router based on their distance

(Modified from source http//www.loriotpro.com/)
Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
20
Node sampling

• Strengths
• Low cost to implement
• Weaknesses
• Takes too long to reconstruct full path
• Must wait for a marked packet from far away from
  the victim
• Doesnt work against multiple attackers
• Multiple routers may appear to have the same
  distance

Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
21
Edge Sampling
Illustration of Edge Sampling Algorithm
Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
22
Edge Sampling

• Attack path reconstruction
• Bounded by the furthest router d hops away
• Also a small chance of receiving a sample from
  the furthest router, but not from one closer
• Expected number of packets X required by Victim
  to reconstruct the attack path of length d

Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
23
Edge Sampling

• Strengths
• Distance field prevents attacker from spoofing a
  router within the valid suffix
• Can identify multiple attackers
• Weaknesses
• When multiple attackers, cant trust paths longer
  than the closest attacker ? requires additional
  precautions
• Additional space in IP packet header ? well
  address this next
• 32 bits for start 32 bits for end 8 bits for
  distance 72 bits
• So not backwards compatible

Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
24
Compressed edge fragment sampling

• Modification 1
• Edge-id XOR the addresses
• Router nearest the Victim comes intact
• Reconstruct path starting near the Victim using

(Savage et al, 301)
Reduces space requirements to 32 bits (XOR
addresses) 8 bits (distance) 40 bits
Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
25
Compressed edge fragment sampling

• Modification 2
• Split XORd address into k chunks
• Include offset of chunk
• Problem
• Edge-id no longer unique

(Modified from Figure 6, Savage et al, 301)
For this example, reduces space requirements to 8
bits (chunk of the XOR address) 2 bits (offset)
8 bits distance 18 bits
Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
26
Compressed edge fragment sampling

• Modification 3
• Bit-interleave router address with the hash of
  the address
• Increases the length of edge-id

(Savage et al, 301)
For this example 8
3 8 19 bits
Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
27
Compressed edge fragment sampling

• Address reconstruction

(Savage et al, 301)
Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
28
Compressed edge fragment sampling

• How many packets do we need?
• Need kd edge fragments
• Each comes with probability p(1 p)d-1
• Example k8, d10, p1/25, then E(X) 1300
• To ensure path can be reconstructed with c
  certainty
• Example c95, then E(X) 2150

Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
29
Compressed edge fragment sampling

• Summary
• Big-interleave address with hash of address
• Split into k fragments
• XOR fragments
• Reconstruct address using
  , starting at router b nearest Victim, validating
  it using the hash
• Reconstruct path(s) by graphing

(Savage et al, 298)
Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
30
Compressed edge fragment sampling

• Strengths
• Requires less bits than Edge Sampling
• of packets required to reassemble path is
  within range of DoS attack
• Good against multiple attackers (get divergent
  paths)
• Can be used post-mortem
• Weaknesses
• Can take a long time to reconstruct paths when
  multiple attackers
• We still need a place in the IP header to store
  this data ? well address this next

Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
31
IP header encoding

• Use IP identification field
• 3 bits for offset (k8) 5 bits for
  distance 8 bits for edge fragment 16 bits
• Strengths
• Header checksum doesnt change
• Low overhead (usually just increment distance)

(Savage et al, 302)
Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
32
IP header encoding

• But what about the IP identification field?
• Original purpose IP fragments
• Fragmentation is rare (0.25) but we still want
  some backwards-compatibility
• If fragmentation occurs before a marked router
• Based on probability q, prepend a new ICMP echo
  reply header with full edge data
• If fragmentation occurs after a marked router
• Dont allow fragmentation (degrades performance)

Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
33

• Experiment

34
Experiment

• Implemented their algorithm on a simulator
• Simulator generates random paths and originates
  attacks
• Settings
• Marking probability p 1/25
• Path length 1,31
• 1,000 random tests per path length

Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
35
Experiment

• Results
• Most paths resolved using 1000-2000 packets
• Usually need less than 4000 packets
• Flood DoS attacks send hundreds or thousands of
  packets per second

(Savage et al, 303)
Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
36

• Authors Limitations / Extensions

37
Backwards Compatibility

• Overwriting the IP identification field limits
  backwards compatibility
• Solution Enable traceback only by request
• There is no IP identification field in IPv6
• Solution Use the flow label field instead

Sample IPv6 Packet
(Modified from source http//en.wikipedia.org/wik
i/IPv6)
Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
38
Path Validation

• Some packets can arrive unmarked
• Attacker could mark these with bogus edges
• Valid suffix unaffected
• Spoof edges past the end of the true attack path
• Solution 1
• Use traceroute to determine valid network
  connections
• Solution 2
• Include a secret with each marked packet
• Contact associated network to determine the
  secret
• Disregard packets that dont have valid secret

Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
39
Other Problems

• For large distributed attacks, very hard to
  reconstruct paths (may misattribute an edge)
• Still not a perfect solution
• Find source of attack traffic
• But cant find real attacker

Savage, Stefan Wetherall, David Karlin, Anna
and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM
Conference. Pg 295-306, 2000.
40

• My Review

41
Contributions

• Presented a traceback algorithm that is
• Easy to understand
• Requires little router overhead
• Can be used post-mortem
• Can be implemented in IPv4 with little loss of
  functionality
• Focus on valid suffix
• Theoretically estimated applicability to
  flooding-style DoS attacks
• Experimentally demonstrated that their algorithm
  works
• Fair comparison between other existing traceback
  techniques

42
Weaknesses

• Weak explanation of experimental design
• Did they test single or multiple sources of
  attacks?
• What of the network were marking routers?
• Did simulated attackers try anything sneaky?
• Didnt report time it takes to reconstruct the
  path
• Didnt report performance cost of dealing with
  fragmentation
• Authors note that Node Sampling would take too
  long, but seems similar to Edge Sampling
• Not a perfect solution ? Authors admit to this

43
Extensions

• Test on IPv6 and determine countermeasures to
  dealing with loss of flow label field
• Test on real networks
• Combine with automated attack detection

44
References

• 1 Savage, Stefan Wetherall, David Karlin,
  Anna and Anderson, Tom. "Practical Network
  Support for IP Traceback". In Proceedings of the
  2000 ACM Conference. Pg 295-306, 2000.
• 2 IPv4. Wikipedia. lthttp//en.wikipedia.org/wi
  ki/IPv4gt.
• 3 IPv6. Wikipedia. lthttp//en.wikipedia.org/wi
  ki/IPv6gt.

(Modified from source http//www.comixconnection.
com/)