IP Traceback and Network Security

1
IP Traceback and Network Security

• Kang-Won Lee
• IBM Research
• With the courtesies of A. Snoeren and S. Savage

2
Outline

• Preliminaries
• What is IP traceback?
• Why IP traceback?
• Probabilistic marking
• Hashed-based logging
• Case Studies
• Conclusions

3
Preliminaries

• Coping with attacks
• Prevention ingress/egress filtering, rate
  limiting
• Detection - logging, performance monitoring
• Tolerance resource provisioning, SYN cookies,
  hot standbys, filtering, rate limiting
• Analysis traceback, log mining

4
(No Transcript)
5
Why IP Traceback?

• Internet hosts are vulnerable
• Denial-of-service via packet flooding
• Some attacks consist of very few packets, e.g.,
  Teardrop, ping-of-death, etc.
• Internet Protocol permits anonymity
• Attackers can spoof source address
• Network is stateless (IP maintains no audit
  trails)
• Need a separate traceback facility
• To account for the loss
• To discourage potential attackers

6
Approaches to Traceback

• Link testing
• Input debugging
• Controlled flooding Burch and Cheswick
• Sampling
• ICMP traceback Bellovin
• Probabilistic Marking Savage et al.
• Logging
• Naïve logging
• Hash-based IP traceback (SPIE) Snoeren et al.

7
1. Probabilistic marking
8
(No Transcript)
9
(No Transcript)
10
(No Transcript)
11
(No Transcript)
12
(No Transcript)
13
(No Transcript)
14
2. Logging Challenges

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

15
Hash-based logging

• 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

16
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
17
Impact of Traffic Diversity
1
WAN (6031 hp)
0.1
LAN (2879 hp)
0.01
Fraction of Collided Packets
0.001
0.0001
1e-05
1e-06
20
22
24
26
28
30
32
34
36
38
40
Prefix Length (in bytes)
18
Bloom Filters

• Fixed structure size
• Uses 2n bit array
• Initialized to zeros
• Insertion is easy
• Use n-bit digest as indices into bit array

n bits
1
H(P)
2n bits

• Variable capacity
• Easy to adjust
• Page when full

19
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

20
Simulation Results
1
1
1
1
Random Graph
Real ISP, 100 Utilization
Real ISP, Actual Utilization
0.8
0.8
0.8
0.8
0.6
0.6
0.6
0.6
Expected Number of False Positives
0.4
0.4
0.4
0.4
0.2
0.2
0.2
0.2
0
0
0
0
0
5
10
15
20
25
30
0
5
10
15
20
25
30
0
5
10
15
20
25
30
0
5
10
15
20
25
30
Length of Attack Path (in hops)
Length of Attack Path (in hops)
Length of Attack Path (in hops)
Length of Attack Path (in hops)
21
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 gt3GB per minute
• OC-192 needs SRAM access times
• Still viable tomorrow
• 128 OC-192 links need lt100GB per minute

22
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

23
Case study 1 Cisco Systems

• Filtering
• ip verify unicast reverse-path interface command
• Filter all RFC1918 address space using access
  control lists
• Apply ingress and egress filtering (see RFC 2267)
  using ACL (access control list)
• Rate-limiting
• Use CAR (committed access rate) to rate limit
  ICMP packets and TCP SYN packets
• NetFlow
• Data collection and analysis per flow basis
  (defined by source/destination address, port,
  protocol,TOS, etc.)

24
Case study 2 Arbor networks
25
(No Transcript)
26
Case study 3 Asta Networks

• Vantage System 2.0
• Automatic detection of DoS attacks
• Real-time report of network traffic behavior
• Interacts with Cisco (NetFlow), Juniper routers
  (packet sampling)

27
Case study 4 Mazu Networks

• DDoS enforcers 300/10000/SP
• Detect attacks
• Bandwidth trigger
• Suspicious traffic trigger
• Notify an operator the attack
• Characterize the traffic and recommend a filter
  (Mazu filters or Cisco ACL filters)

28
(No Transcript)
29
Summary

• Traceback is a hard problem
• Backward compatibility
• Audit trail collection
• Wide deployment inside network
• Traceback is not implemented/deployed in real
  systems yet