1 / 23

Distributed Quota Enforcement for Spam Control

Distributed Quota Enforcement for Spam Control. Jee Whan Choi Chaoting Xuan. Contents. Introduction Distributed Quota Enforcement (DQE) DQE Architecture Enforcer Design Evaluation Conclusions. Introduction. SPAM Unsolicited Bulk Email 50-70% of email today is SPAM SPAM Filters

knut
Download Presentation

Distributed Quota Enforcement for Spam Control

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 100’s 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,t}Spriv }

  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 victim’s stamp before it is created • Stamp contains Sender’s 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 client’s 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 k’s 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 stamp’s fingerprint has been placed on a good node - 1/(1-2p)+pr*n • If we assume r = 1+log1/pn, use = 1+3p = 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 ?

More Related