1. Hash-Based IP Traceback Alex C. Snoeren †, Craig Partridge, Luis A. Sanchez, Christine E. Jones, Fabrice Tchakountio, Stephen T. Kent, W. Timothy Strayer BBN Technologies † MIT Laboratory for Computer Science

2. The Need for Traceback Internet hosts are vulnerable  Many attacks consist of very few packets  Fraggle, Teardrop, ping-of-death, etc. Internet Protocol permits anonymity  Attackers can “spoof” source address  IP forwarding maintains no audit trails Need a separate traceback facility  For a given packet, find the path to source

3. Approaches to Traceback Path data can be noted in several places  In the packet itself [Savage et al.],  At the destination [I-Trace], or  In the network infrastructure Logging: a naïve in-network approach  Record each packet forwarding event  Can trace a single packet to a source router, ingress point, or subverted router(s)

4. Log-Based Traceback V R R1R1 R2R2 R3R3 RR RR R4R4 AR RR7R7 R6R6 R5R5

5. Challenges to Logging Attack path reconstruction is difficult  Packet may be transformed as it moves through the network Full packet storage is problematic  Memory requirements are prohibitive at high line speeds (OC-192 is ~10Mpkt/sec) Extensive packet logs are a privacy risk  Traffic repositories may aid eavesdroppers

6. Solution: Packet Digesting Record only invariant packet content  Mask dynamic fields (TTL, checksum, etc.)  Store information required to invert packet transformations at performing router Compute packet digests instead  Use hash function to compute small digest  Store probabilistically in Bloom filters Impossible to retrieve stored packets

7. Invariant Content Total Length Identification Checksum VerTOSHLen TTLProtocol Source Address Destination Address Fragment Offset MFMF DFDF Options Remainder of Payload First 8 bytes of Payload 28 bytes

8. Impact of Traffic Diversity 1e-06 1e-05 0.0001 0.001 0.01 0.1 1 2022242628303234363840 Fraction of Collided Packets Prefix Length (in bytes) WAN (6031 hp) LAN (2879 hp)

9. Variable capacity  Easy to adjust  Page when full Bloom Filters Fixed structure size  Uses 2 n bit array  Initialized to zeros Insertion is easy  Use n-bit digest as indices into bit array 1 n bits 2 n bits H(P) H 2 (P) H k (P) H 3 (P) H 1 (P) 1 1 1...  Mitigate collisions by using multiple digests

10. Mistake Propagation is Limited Bloom filters may be mistaken  Mistake frequency can be controlled  Depends on capacity of full filters Neighboring routers won’t be fooled  Vary hash functions used in Bloom filters  Each router select hashes independently Long chains of mistakes highly unlikely  Probability drops exponentially with length

11. Adjusting Graph Accuracy False positives rate depends on:  Length of the attack path  Complexity of network topology  Capacity of Bloom filters Bloom filter capacity is easy to adjust  Required filter capacity varies with router speed and number of neighbors  Appropriate capacity settings achieve linear error growth with path length

12. Simulation Results 0 0.2 0.4 0.6 0.8 1 051015202530 Length of Attack Path (in hops) Random Graph 0 0.2 0.4 0.6 0.8 1 051015202530 Length of Attack Path (in hops) 0 0.2 0.4 0.6 0.8 1 051015202530 Length of Attack Path (in hops) Real ISP, 100% Utilization 0 0.2 0.4 0.6 0.8 1 051015202530 Length of Attack Path (in hops) Degree-Independent Expected Number of False Positives Real ISP, Actual Utilization

13. How long can digests last? Filters require 0.5% of link capacity  Four OC-3s require 47MB per minute  A single drive can store a whole day Access times are equally important  Current drives can write >3GB per minute  OC-192 needs SRAM access times Still viable tomorrow  128 OC-192 links need <100GB per minute

14. Prototype Implementation Implemented on a FreeBSD PC router  Packet digesting on kernel forwarding path  Bloom filters stored in kernel space  Zero-copy kernel/user table move User-level query-support daemons  Supports topology discovery through gated  Queries automatically triggered by IDS

15. Summary Hash-based traceback is viable  With reasonable memory constraints  Supports common packet transforms  Timely tracing of individual packets Publicly Available Implementation  FreeBSD version will be available soon  Linux port coming shortly thereafter…. http://www.ir.bbn.com/projects/SPIE

16. SPIE Architecture Data Generation Agents (DGAs)  Compute packet digests & maintain tables  Reside in, at, or near each router Collection & reduction agents (SCARs)  Maintain local topology information  Generate attack sub-graphs Traceback manager (STM)  Authenticates and manages query process

17. Transformations Occasionally invariant content changes  Network Address Translation (NAT)  IP/IPsec Encapsulation, etc. Packets sometimes give rise to others  IP Fragmentation  ICMP errors (smurf attacks) Routers need to invert these transforms  Often requires additional information

18. Transform Lookup Table Only need to restore invariant content  Often available from the transform (e.g., ICMP) Otherwise, save data at transforming router  Index required data by transformed packet digest  Record transform type and sufficient data to invert  Use indirect storage for complicated transforms DigestPacket DataIType 29 bits3 bits32 bits

19. Hardware Implementation