Source Path Isolation Engine

1
Source Path Isolation Engine

• Tim Strayer, Craig Partridge, Alex
  Snoeren,Christine Jones, Fabrice
  Tchakountio,Walter Milliken, Steve Kent
• Internetworking Research Department

2
SPIE Programmatics

• Project Start Date June 30, 2000
• Contract Duration 24 months
• Agent POC S. Spendlove
• Team Members
• Tim Strayer, Craig Partridge, Alex Snoeren,
  Christine Jones, Fabrice Tchakountio, Walter
  Milliken, Steve Kent

3
Motivation

• Internet hosts are vulnerable
• Internet Protocol permits anonymity
• Packet source address is not validated
• Attackers can spoof source address
• IP forwarding maintains no audit trails
• Response is difficult without knowledge of attack
  path

4
IP Traceback

• Solution Create audit trails
• Either at the end host
• By marking packets with where theyve been
• Or by sending out-of-band notifications
• Or in the network
• By recording each packet forwarding event
• The issue here is the cost of recording and
  storing events

• SPIE is a network-based auditing mechanism

• Challenge is how to make it space efficient

5
SPIEs Basic Idea
Bad Packet Discovery
6
The Problem with Logging

• Inter-router correlation is difficult
• Packets change at each hop (TTL, Checksum, ICMP,
  NAT, etc.)
• Packet storage is problematic
• Memory requirements are prohibitive at even
  moderate line speeds
• Extensive packet logs are a security risk
• Solution record packet digests instead

7
Logging in SPIE

• Record only invariant packet content
• Ignore constantly changing fields
• Consider transforms (IP fragmentation, NAT, ICMP,
  etc.) as special cases
• Store digests
• Space efficient, supports rapid insertions
• Membership tests are straightforward
• Impossible to retrieve stored packets

8
Minimizing Storage

• Whats the minimum information we can keep about
  each packet?
• An OC-192c moves 10 Mpkt/s
• One 32-bit digest per packet is 320 Mbit/s

• But we want even less
• How about 1 bit? Use digest as an index into a
  bit array
• This is 10 Mbits/s per link
• And this is only 0.1 of the bandwidth

9
How many bits per packet?

• Initial idea one digest per packet, same hash
  function at each router
• Probabilistic logging (some chance of collision
  at a particular bit)
• Failure chance of long train of false matches is
  large
• If bitmap is 50 full, and we have an average of
  4 or 5 neighbors, chances near 100 of continuous
  chain of false positives
• To reduce matches, bitmap would have to be no
  more than 13 full, but that is very expensive in
  storage
• Result Bloom Filters
• Moral do your math carefully!

10
Bloom Filters

• Fixed structure size
• Uses 2n bit array
• Initialized to zeros
• Insertion is fast
• Compute multiple (k) independent digests
• Use digest results as indices into bit array
• Variable capacity
• Easy to adjust by varying n and k

n bits
1
1
H1(P)
H2(P)
2n bits
H3(P)
1
. . .
1
Hk(P)
11
False Positives

• Packets are confused for two reasons
• Insufficient input to the digesting functions
• Bloom filter membership collision
• Both problems can be mitigated
• Ensure sufficient payload prefix length
• Vary hash functions used in Bloom filters
• Choose functions randomly, and change often
• Select independently at each router

12
How Deep To Look in Packet?
13
Invariant Content
Total Length
Ver
TOS
HLen
Identification
Fragment Offset
M F
D F
Checksum
TTL
Protocol
28 bytes
Source Address
Destination Address
Options
First 8 bytes of Payload
Remainder of Payload
14
Simulation Results
15
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
• SPIE keeps ancillary data to map packets back to
  original

16
SPIE Architecture

• Hierarchical query mechanism
• Data Generation Agents (DGAs)
• Hashes and stores the digest of each packet
  through router
• Answers specific queries
• SPIE Collection and Reduction agents (SCARs)
• Manages a group of DGAs
• Assembles answers from DGAs into a partial graph
• SPIE Traceback Manager (STM)
• Authenticates and throttles the requests
• Assembles the partial graphs from SCARs
• IDS (or any discovery mechanism) not defined

17
Prototype Implementation

• FreeBSD Zero Copy Page Moves
• FreeBSD Kernel Loadable Module
• Bloom Filters (3 Hashes) computed over every
  through packet, bits set in hash tables
• Tables periodically zero-copied into user space
  DGA
• User space daemons
• DGAs, SCARs, STM
• All derived from same daemon base classes
• IDS
• Using snort (fixed and reported bugs)

18
Summary and Future Work

• Completed the Architecture and Design phases
• Defined requirements
• Analyzed hashes and fields for hashing
• Analyzed transforms and false positives
• Designed major architecture components
• In midst of Implementation phase
• DGA kernel hashing module and user space query
  mechanism
• STM/SCAR daemons and communication protocol
• IDS/SPIE API