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 – 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 – 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)+p r *n – If we assume r = 1+log 1/p n, 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 i mprove 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 no des. 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 ?