Distributed Quota Enforcement for Spam Control

1
Distributed Quota Enforcement for Spam Control

• Jee Whan Choi
• Chaoting Xuan

2
Contents

• Introduction
• Distributed Quota Enforcement (DQE)
• DQE Architecture
• Enforcer Design
• Evaluation
• Conclusions

3
Introduction

• SPAM
• Unsolicited Bulk Email
• 50-70 of email today is SPAM
• SPAM Filters
• Email text scanning
• Rate of false positive is approximately 1
• Economic damage estimated at 100s of millions of
  dollars
• Distributed Quota Enforcement (DQE)
• Quotas on the of mails a sender can send

4
Distributed Quota Enforcement

• Design Objectives
• Protocol
• No False Positives
• Untrusted Enforcer
• Privacy
• Enforcer
• Scalability
• Fault Tolerance
• High Throughput
• Attack-Resiliency
• Mutually Untrusting Nodes

5
Architecture
6
Quota Allocation and Creation

• Quota Allocation
• Quota allocated by select few globally trusted
  quota allocators (QA)
• Cs Spub, expiration time, quota QApriv
• Stamp
• Created by the sender
• Stamp Cs, i,tSpriv

7
Stamp Cancellation Protocol
8
Protocol Objectives

• False Positives
• Hash is unique and one way
• Untrusted Enforcer
• Returns a proof of reuse (fingerprint)
• Privacy
• Hash of the stamp is used instead of the stamp
  itself
• An adversary cannot cancel a victims stamp
  before it is created
• Stamp contains Senders private key

9
Enforcer

• Comprises of thousands of untrusted storage nodes
• Enforcer stores the fingerprints of stamps
  cancelled in the current and previous epochs
• List of approved nodes are published by a trusted
  authority (Bunker)
• Node receiving the clients request is called the
  portal for that request
• A client can discover a portal via hard-coding or
  DNS

10
Enforcer Design
11
TEST

• TEST
• Local check
• If not found, sequentially send request to other
  nodes (assigned-nodes)
• Assigned-nodes are determined by k and r
  independent hash functions, similar to Chord.
• r is configurable system parameter
• If any node contains ks value, return it,
  otherwise return not found

12
SET

• SET
• Local store
• Also store the value in a randomly chosen node
  from assigned-nodes

13
TEST and SET Algorithm
14
Stamp Reuse and Fault Tolerance

• False negative is possible.
• Byzantine faults and crash faults are the same
• Outcome of adversarial nodes giving false
  negatives (not-found response) are the same a
  nodes not responding (crash fault)
• Depends on the parameters r and p
• p fraction of n total machines that fail during
  a 2 day cycle
• Expected number of times a stamp is used before
  stamps fingerprint has been placed on a good
  node - 1/(1-2p)prn
• If we assume r 1log1/pn, use 13p 1.3 for
  p 0.1

15
Improvement of Fault Tolerance (our speculation)

• Randomly chose two or more nodes from the
  assigned nodes to store the (key, value) pair in
  the PUT algorithm.
• Increase the overall storage usage, but
  significantly improve the stamp reuse detection
  rate.

16
GET and PUT
17
GET and PUT (Continue)

• PUTs are fast
• Crash recovery of previously cancelled keys
• Key-value pairs are small in size
• Not Found answers are almost always fast
• Found answers are slow

18
Avoiding Distributed Livelock

• Distributed Pipeline
• 1. TEST/SET requests from clients.
• 2. GET/PUT requests from other enforcer nodes.
• 3. GET/PUT responses.
• Drop the beginning of a pipeline to maximize
  throughput.

19
Resource Exhaustion Attacks

• Attacks flood of spurious TEST/SET requests.
• Assumption Attackers (or zombies they control)
  have some bandwidth limit.
• Solution Max out attackers bandwith by
  requiring large size or multiple copies of
  TEST/SET packets .

20
Performance Evaluation
21
Performance Evaluation (Continue)

• Enforcer Size
• 1. 100 billion emails daily
• 2. 65 spam 
• 3. 65 billion disk seeks / day (pessimistic)
• 4. 400 disk seeks/second/node
• 5. 86400 seconds/day
• 1881 nodes (3GHz CPU, 1G RAM, 3 Mbits/sec
  Bandwith)

22
Performance Evaluation (Continue)
23

• Question ?