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
-ACM = Association for Computing Machinery
-SIGCOMM: focused on communication and computer networks

2. Outline Goal / Motivation Background Previous work Terminology
Marking algorithms
Experiment
Authors’ limitations / extensions
My review

3. Goal / Motivation Goal: Motivation:
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
-CERT = Computer Emergency Response Team
Savage, Stefan; Wetherall, David; Karlin, Anna and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM Conference. Pg , 2000.

4. What this paper is and isn’t
This paper isn’t:
A perfect solution
Cannot find the real attacker
Very difficult problem (examples: compromised host attack, reflector attack)
This paper is:
A practical solution
Traceback problem: Find the direct attacker
Still a difficult problem due to IP spoofing
(Source:
(Source:
Savage, Stefan; Wetherall, David; Karlin, Anna and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM Conference. Pg , 2000.

5. Vulnerability of IP protocol to anonymous attacks
Sample IP Packet (IPv4)
(Modified from source:
Source address is specified by the sender
Can spoof as long as the attack doesn’t 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 , 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
-Problems with universal deployment:
-Administrators don’t want to deal with the added overhead and possible complications
-Some legit services rely on IP spoofing (example: Mobile IP)
Savage, Stefan; Wetherall, David; Karlin, Anna and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM Conference. Pg , 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
-Requires too much cooperation / coordination
-No direct economic incentive for network operator to help
-Network operators need enough free time and skill
-Cooperating across ISP’s is hard to coordinate
Savage, Stefan; Wetherall, David; Karlin, Anna and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM Conference. Pg , 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
Can’t be used post-mortem
-This is another link testing algorithm
-But unlike input debugging, doesn’t require the victim to communicate with a network operator
-Not effective against DDoS attack
-This link testing mechanism is inherently noisy and it can be difficult to discern the set of paths being exploited when multiple upstream links are contributing to the attack
-Can’t be used post-mortem is a common problem with link testing approaches
Savage, Stefan; Wetherall, David; Karlin, Anna and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM Conference. Pg , 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 , 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
Doesn’t work well without universal deployment
Attacker could send fake ICMP traceback messages
-ICMP = Internet Control Message Protocol
Savage, Stefan; Wetherall, David; Karlin, Anna and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM Conference. Pg , 2000.

12. Overview of previous work
-Distributed capability = ability to trace multiple simultaneous attacks
(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 , 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 , 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 can’t 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 , 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 can’t 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 , 2000.

17. Marking Algorithms

18. Node append Simplest marking algorithm Algorithm: Strengths:
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 , 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:
Savage, Stefan; Wetherall, David; Karlin, Anna and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM Conference. Pg , 2000.

20. Node sampling Strengths: Weaknesses: Low cost to implement
Takes too long to reconstruct full path
Must wait for a marked packet from far away from the victim
Doesn’t 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 , 2000.

21. Edge Sampling Illustration of Edge Sampling Algorithm
-Keep track of edges instead of nodes
-Random decision based on a decided probability p
Savage, Stefan; Wetherall, David; Karlin, Anna and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM Conference. Pg , 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 , 2000.

23. Edge Sampling Strengths: Weaknesses:
Distance field prevents attacker from spoofing a router within the valid suffix
Can identify multiple attackers
Weaknesses:
When multiple attackers, can’t trust paths longer than the closest attacker  requires additional precautions
Additional space in IP packet header  we’ll address this next
32 bits for start + 32 bits for end + 8 bits for distance = 72 bits
So not backwards compatible
-Distance field prevents an attacker from spoofing a router within the valid suffix
-Because any packets the attacker spoofs will have a distance >= the length of the true attack path
-Can identify multiple attackers
-Path reconstruction will diverge
Savage, Stefan; Wetherall, David; Karlin, Anna and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM Conference. Pg , 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 , 2000.

25. Compressed edge fragment sampling
Modification 2:
Split XOR’d 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 , 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: = 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 , 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 , 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: k=8, d=10, p=1/25, then E(X) = 1300
To ensure path can be reconstructed with c certainty:
Example: c=95%, 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 , 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 , 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  we’ll 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 , 2000.

31. IP header encoding Use IP identification field
3 bits for offset (k=8) + 5 bits for distance + 8 bits for edge fragment = 16 bits
Strengths:
Header checksum doesn’t change
Low overhead (usually just increment distance)
-5 bits for distance allows for up to 31 hops, which is more than almost all Internet paths
-8 bits for edge fragment based on using 32 bit hash
(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 , 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:
Don’t allow fragmentation (degrades performance)
-Original purpose: IP fragments
-If a packet became fragmented, would use this field to identify fragments belonging to the same packet so that the packet could be reconstructed
Savage, Stefan; Wetherall, David; Karlin, Anna and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM Conference. Pg , 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 , 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 , 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
-Flow label is used for QoS on real-time applications
(Modified from source:
Savage, Stefan; Wetherall, David; Karlin, Anna and Anderson, Tom. "Practical Network Support
for IP Traceback". In Proceedings of the 2000 ACM Conference. Pg , 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 don’t 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 , 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 can’t 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 , 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?
Didn’t report time it takes to reconstruct the path
Didn’t 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
-Both Node Sampling and Edge Sampling bounded by the time it takes to receive a packet from the furthest router

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 , [2] “IPv4”. Wikipedia. < [3] “IPv6”. Wikipedia. <
(Modified from source: