Hash-Based IP Traceback

1
Hash-Based IP Traceback

• Alex C. Snoeren, Craig Partidge, Luis A. Sanchez,
  Christine E. Jones, Fabrice Tchakountio, Stephen
  T. Kent, and W. Timothy Strayer
• SigComm Aug. 2001 San Diego, Ca

Presented by Chris Dion
2
Tonights Outline

• Introduction to the problem
• What is IP Traceback?
• Some Previous Work
• Overview of the Proposed Solution
• Implementation/Simulation

3
Internet Anonymity

• Not all attacks are large flooding DOS attacks
• Well placed single packet attacks can be just as
  effective
• These packets can be spoofed to appear from
  almost anywhere
• How can we track these attacks and find their
  origin?

4
Current Methods

• Use of ingress filtering to limit source address
• Not all routers can look at every packets source
  address
• Spoofed addresses are all to often found
• NAT
• Mobile IP
• Hybrid satellite architectures

5
IP Traceback

• Some Assumptions about the network
• Packets may be Multi- or broadcast
• Tracing system must be prepared for multiple
  packets
• Attackers can get into routers
• Tracing must not be confounded by a motivated
  attacker
• Routing behavior of network can be unstable
• Tracing must be prepared to handle divergent
  information
• Packet Size Should not grow due to Tracing
• End hosts may be resource constrained
• Tracing is an infrequent operation
• Can use routers control path vs. data path

6
Attack Path
7
Packet Transformations

• Packets may be modified for number of valid
  reasons
• Packet fragmentation
• IP option processing
• ICMP processing
• Packet duplication
• NAT
• IPsec Tunneling
• Less then 3 of Internet traffic in 2000
• Attackers can use these!

8
Some Previous work

• 2 approaches to determining route
• Audit of flow as it traverses network
• Can grow packet with route information, use
  fields in header, or use out-of-band signaling
• Inference of flow based on its impact on state of
  network
• Systematically floods network and watch for
  variations in received packet flow
• Becomes infeasible when flow sizes approach a
  single packet

9
Packet Digests

• We do not need the entire packet
• Reduces storage requirements
• Need only packet header to determine attacker
• Still need to uniquely determine packet
• Security concerns
• Mask out fields that modify along a packets
  route
• Type of Service
• TTL
• Checksum
• IP Options

10
IP Packet fields for Hash Input
11
Why 28 bytes?

• WAN trace from OC-3 gateway router
• LAN trace from active 100Mb segment
• For 28 bytes
• .00092 WAN
• .139 LAN

12
Bloom filters

• Used to store digests in router
• From Communications of ACM July 1970
• Computes k distinct packet digests for each
  packet using hash functions
• Uses results to index into a bit array
• Could potentially create false positives

13
Bloom filter
K bit hash functions
n bit digests for each packet received
14
Bloom Filters (cont)

• Restrictions on Hash Family
• Must distribute a high correlated set of inputs
  (packet digests)
• Independent collision events (false positives at
  one router is independent of neighboring routers)
• Called universal hash families
• Must be easy to compute at high link speeds

15
Source Path Isolation Engine
16
SPIE System

• DGA Data Generation Agent
• Produces packet digests of each departing packet
  and stores them in a digest table
• Represents the traffic forwarded in a given time
  interval
• SCAR SPIE Collection and Reduction Agent
• When attack is detected, SCAR product attack
  graph for its region
• STM- SPIE Traceback Manager
• Interface to the intrusion detection system
• Gathers complete attack graph

17
Traceback processing

• IDS will signal potential attack and give STM
• Packet P
• Victim V, must be expressed in terms of the
  last-hop routers
• Time of attack T, must be in a timely fashion
• STM immediately asks all SCARs in domain to poll
  DGAs for digests
• SCAR will give Attack graph, then STM will work
  backwards to identify source

18
What if Packet is Transformed?

• Need a TLT Transform Lookup Table with each
  packet digest

IP Packet Digest
Indirect flag
Type of Transform (ICMP, NAT, etc.)
Variable for Packet Data needed to transform
19
Graph Construction

• Each SCAR is responsible for its region
• After gathering all digest tables, simulates
  reverse-path flooding (RPF)
• If packet is found in router, node is marked and
  arrival time is the latest possible time to search

20
Graph Construction Example
Attack Paths
SPIE Queries
21
Implementation

• Universal hash family is simulated using MD5
  Hashing (128-bit output)
• Random number is pre-pended to each packet for
  independency
• Output is taken as 4 32-bit digests
• Size of Digest Table varies with the total
  traffic capacity of the router

22
Possible DGA in hardware
23
False Positive Analysis

• Use probability of false positives at p1/8d for
  a theoretical limit (ddegree of routers
  neighbors)
• Assuming 32 node path length, approaching
  diameter of the Internet
• For simulation used topology for a major ISP
• 70 backbone routers with T-1 (1.54 Mbps) to OC-3
  (155 Mbps)
• Sent 1000 attack packets at a constant rate to
  one victim, with background traffic set to a
  fixed false-positive rate P

24
Simulation Result

• Low value was due to link utilizations
• Considerable Gap between theoretical and
  simulation

25
Time and Memory Analysis

• Give one minute to identify attack packet
• Memory will be linear with link capacity
• We will consider Bloom filter with 3 digesting
  functions and a capacity factor of 5 for a false
  positive rate of P .092 when full
• Average sized packets (1000 bits)
• Using this we get a rule of thumb
• SPIE requires 0.5 of total link capacity

26
Time and Memory Analysis (cont)

• 4 OC-3 links 47 MB of storage
• 32 OC-192 links 23.4GB for one minute
• Access Time is also important
• Given DRAM cycle time of 50ns, routers processing
  more then 1 OC-192 will need SRAM (only 16Mb
  which must be paged)

27
Some Issues

• Traceback may be requested when the network is
  unstable
• Possibly from the attack itself
• Best solution would be out-of-band management
• Priority handling may work for in-band
• ISP-ISP deployment
• Possible sharing of SPIE infrastructure?
• Grant STM requests to other domains

28
Conclusions

• Traceback of a single packet is very difficult
• SIPEs key contribution is that it is feasible
• Low Storage
• Does not aid in eavesdropping
• Complete System
• The future could discard packet digests
  probabilistically as they age to allow for longer
  traceback times