1 / 44

“Practical Network Support for IP Traceback ”

“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

ashleyk
Download Presentation

“Practical Network Support for IP Traceback ”

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 isn’t • This paper isn’t: • 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 • Source address is specified by the sender • Can spoof as long as the attack doesn’t rely on return traffic Sample IP Packet (IPv4) (Modified from source: http://en.wikipedia.org/wiki/IPv4#Header) 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 • Can’t 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 • Doesn’t 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 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.

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

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

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

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

  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) (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: • Don’t 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/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.

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

  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

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

More Related