EXPLORING THE FEASIBILITY OF PROACTIVE REPUTATIONS

1
EXPLORING THE FEASIBILITY OF PROACTIVE REPUTATIONS

• Gayatri Swamynathan, Ben Y. Zhao, Kevin C.
  Almeroth
• UC Santa Barbara
• IPTPS 2006

2
Reputation systems

• Quantify a peers trustworthiness
• Aggregate ratings earned by peer after each
  transaction

Make decision
SERVICE REQUESTER
rep 3
rep 1
rep 2
PROVIDER 1
PROVIDER 3
PROVIDER 2
3
Reliability of reputations

• Reputation benefits
• Increased cooperation and trustworthiness
• Reliability concerns
• Vulnerability to false ratings (collusion, sybil
  attacks)
• Passive
• No way to influence the reliability of reputation
• One reliability measure is the number of peer
  transactions
• More number of transactions higher reliability

4
Reputations for overlays

• Message routing increased reliability of P2P
  routes

T
A
B

• Distributed file storage reliability of file
  storage

T
A

• Other application-specific tasks

5
Reputations for overlays

• General reputation schemes less reliable
• More number of peer transactions desirable
• Overlay networks exhibit churn, short-term
  identities
• Reputations accrued from small number of past
  transactions
• Vulnerable to attacks from malicious peers
• How to produce quick and reliable ratings
• for peers?

6
Our solution Proactive reputations

• Quick and reliable reputations for peers with
  short lifetimes
• Opposite of a passive approach
• Proactively probe a peer to test how reliable it
  is
• Complementary to general reputation systems
• Scope of our work
• Explore proactive reputations for overlays
• Does not address vulnerabilities of general
  reputation systems

7
Proactive reputations
T
Target
I
Initiator

• Initiator sends proactive storage requests to
  test target

8
Proactive reputations
T
V
verify
Target
Verifier
report success
verify
I
Initiator

• Initiator (or trusted third-party) verifies the
  transaction success

9
Benefits of proactive reputations

• Peers control transaction rate
• Quick reputations
• First-hand
• More trustworthy
• Implications
• Addresses the problem of churn in overlays
• Addresses the problems posed by false ratings
• Complementary to general reputation system
• Confirm a peers reliability

10
Initiator-side requirements
T
Target
I
Initiator
proactive requests

• How do we create proactive requests?
• Low-cost and uniform value
• Verifiable

11
Handling initiator-side requirements

• Application domain
• YES P2P message routing, block-based storage,
  distributed computation
• Low resource (bandwidth and time) costs
• Uniform value
• NO Financial transactions (like EBay)
• High variance in value

12
Target-side requirements
T
Target
I
Initiator
proactive requests

• Processing of requests must be fair and unbiased
• Source must be unidentifiable
• Proactive requests must be indistinguishable from
  normal application traffic

13
Handling target-side requirements

• Unbiased processing of requests
• Anonymize a fraction (or all) proactive requests
• Per-source type behavior avoided
• Proactive requests must be indistinguishable from
  normal application traffic
• ALL peers anonymize a portion of the application
  traffic they generate (cover-traffic)
• Result Resists traffic analysis
• Statistically hard to distinguish normal and
  proactive requests
• Motivates honest participation

14
Producing cover-traffic

• All overlay peers produce cover-traffic
• Three models to anonymize application traffic
• Preset anonymous rate

Preset rate
0 0 1 0 0 1 0 0 0 0 0 0 1 1 1 0
P
30 anon. rate
0 open 1 - anonymous
15
Producing cover-traffic

• All overlay peers produce cover-traffic
• Three models to anonymize application traffic
• Preset anonymous rate
• Per-hour anonymous rate change

Per-hour rate change
0 0 1 0 0 1 0 0 0 0 0 0 1 1 1 0
1 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0
P
hour 1 30
hour 2 20
16
Producing cover-traffic

• All overlay peers produce cover-traffic
• Three models to anonymize application traffic
• Preset anonymous rate
• Per-hour anonymous rate change
• Per-transaction-set rate change

Per-transaction set rate change
0 0 1 0 0 1 0 0 0 0 0 0 1 1 1 0
1 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0
P
First set of 5 transactions 30
Second set of 20 transactions 10
17
Producing cover-traffic
P
P
1 1 1 1 0
P
1 0 1 1 0
1 0 1 1 1
P
P
1 0 0 1 0
0 open 1 - anonymous
I
0 0 1 0 0 1
T
1 1 1 1 1

• T 1 1 1 0 0 1 0 0 1 1 1 0 1 0 1 0 0 0 1 1 0
• Proactive bursts blend in with normal traffic!

18
Target-side analysis

• Normal traffic Reference window

0 0 1 0 0 1 0 0 0 0 0 0 1 1 1 0

• Bursty traffic

1 0 1 0 0 1 1 1 1 0 0 0 1 1 1 0
injected proactive requests

• Metric of success
• How large a consecutive burst of proactive
  requests can be injected without detection?

19
Using frequency histograms

• Normal traffic

0 0 1 0 0 1 0 0 0 0 1 1 1 0 0 0 0 0 1 1 0

• Bursty traffic

1 1 1 0 0 1 0 1 1 1 1 0 1 0 1 1 0 0 0 1 1

• Bursty traffic-2

1 1 1 0 1 1 1 1 0 1 1 1 1 0 1 1 1 1 1 1 1
Frequency count
8 7 6 5 4 3 2 1
Normal traffic histogram
0 1 2 3 4
Number of consecutive 1s
20
Histogram similarity metric

• Absolute difference (AD) histogram similarity
• AD ? Ha(j) Hp(j)
• j 1 to N
• Ha(j) histogram bin value of j consecutive 1s in
  normal application traffic
• Hp(j) histogram bin value of j consecutive 1s in
  traffic with injected bursts
• Small values of AD gt greater similarity of the
  two streams

21
Evaluation

• Preset model Effect of increasing anonymous
  rate, burst size and window size

22
Evaluation

• Comparison of the three traffic shaping models

• Per-hour and per-transaction set
• Effective with increasing burst sizes
• Similar in performance

23
Summary

• Proactive reputations
• Novel approach of generating quick, reliable
  reputations
• Addresses the problem of churn in overlays
• Addresses the problem of false ratings
• Lots more directions to go!
• Minimum anonymity required
• Relaying through a sybil or third-party could
  suffice
• Integration into global reputations
• Per-peer basis integration
• Counter-attack models

24
Questions?

• For more on our work,
• Email
• gayatri_at_cs.ucsb.edu
• Web
• http//www.nmsl.cs.ucsb.edu/
• http//p2p.cs.ucsb.edu/current/

25
Backup slides
26
Simulation parameters

• PARAMETER VALUE RANGE DEFAULT
• Size of the network 50-100 50
• of transactions 100-10000 5000
• Proactive burst size 0-70 40
• Window size 50-500 100
• Anon. rate (model 1) 0-70 30