“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

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

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 295-306, 2000.

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

Vulnerability of IP protocol to anonymous attacks Sample IP Packet (IPv4) (Modified from source: http://en.wikipedia.org/wiki/IPv4#Header) 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 295-306, 2000.

Previous Work

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 295-306, 2000.

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 295-306, 2000.

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 295-306, 2000.

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.

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 295-306, 2000.

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 295-306, 2000.

Terminology

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.

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 295-306, 2000.

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 295-306, 2000.

Marking Algorithms

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 295-306, 2000.

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.

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 295-306, 2000.

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 295-306, 2000.

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.

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 295-306, 2000.

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.

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 295-306, 2000.

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.

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.

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 295-306, 2000.

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.

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 295-306, 2000.

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 295-306, 2000.

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 295-306, 2000.

Experiment

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.

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.

Authors’ Limitations / Extensions

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: http://en.wikipedia.org/wiki/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.

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 295-306, 2000.

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 295-306, 2000.

My Review

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

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

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

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. <http://en.wikipedia.org/wiki/IPv4>. [3] “IPv6”. Wikipedia. <http://en.wikipedia.org/wiki/IPv6>. (Modified from source: http://www.comixconnection.com/)