Transcript document

A Reputation-Based Approach for
Choosing Reliable Resources in
Peer-to-Peer Networks
E. Damiani S. De Capitani di Vimercati
S. Paraboschi P. Samarati F. Violante
http://seclab.dti.unimi.it/p2prep/
Outline
P2P Networks & Gnutella protocol [1]
 Motivation of Reputation Systems
 XRep protocol [2]
 Security considerations on XRep
 Distribution of Servent & Resource
 Conclusions
 References

P2P Networks




All the nodes offer the same services and follow
the same behavior.
Nodes act both as servers and as clients.
There are no nodes with a special responsibility to
monitor or supervise the network behavior.
P2P networks for file sharing involves two phases:
1 Search of the peers where the requested
file resides.
2 Download from the exporting peers the
requested information.
Gnutella






Gnutella is a protocol for distributed search.
Nodes are called servents.(server + client)
Servents communicate by exchanging descriptors.
Ping, Pong – are used to discover servents
Query, QueryHit – Searching files in the P2P
network
Push – allows a firewalled servent to contribute
files to the P2P network
The Gnutella Protocol Specification v0.4
www9.limewire.com/developer/gnutella_protocol_0.4.pdf
Descriptor routing

A servent P requiring a resource broadcasts a Query
out.

A servent S will respond with a QueryHit if a match is
found against its local database. And S will forward
incoming Query descriptors to all of its directly
connected servents, except the one that delivered the
incoming Query.

QueryHit descriptors may only be sent along the same
path that carried the incoming Query descriptor.

A servent receiving a descriptor with the same Payload
Descriptor and Descriptor ID as one it has received
before, should attempt to avoid forwarding the
descriptor to any connected servent.
Gnutella
A servent
S will descriptors
forward
incoming
QueryHit
may Query
A servent
S receiving
a descriptor
descriptors
all of
its directly
connected
be
sent
along
the
same
Awhich
servent
Stowill
respond
with
anot
S only
has
received
before
will
servents,
except
one that
the
A servent
Pthe
requiring
aincoming
resource
path
that
carried
thedelivered
forward
the
descriptor
QueryHit
if
a
match
is
found
incoming
Query. a Query out.
broadcasts
Query
descriptor
against its local database.
Match
O
O
P
P: servent looking for a resource
O: offerer
Query
QueryHit
Download
Match
Structure of Gnutella descriptor
Every descriptor has two parts:
1. Descriptor Header

Descriptor ID Payload Descriptor
TTL
Hops Payload Length
2. Payload
Query:
Minimum Speed
Search criteria
QueryHit:
Number
of Hits
Port
IP
Trailer Servent
Speed Result Set
File
File
Index Size
File
Name
ID
Motivation of Reputation systems

Most P2P systems protect peers’ anonymity. Anonymity
opens the door to possible misuses and abuses
-- Bad service, low quality resources
-- The content of a file is different than the title
-- Trojan horses and viruses

e.g. Mandragore – a Gnutella worm
-- Act as a servent and answer all Queries.
-- Provides a renamed copy of itself for downloading.
Peer review process: the peers’ opinions is used to
establish a reputation for peers and resources.
XRep: Basic Assumptions




Each node keeps track and share with others
information about the reputation of their peers and
resources
Reputation sharing is based on a distributed
polling protocol
Each servent has a servent_id which is a digest of
a public key obtained using a secure hash function
Each resource has an resource_id which is a
digest computed by applying a secure hash
function to the resource content
XRep: Reputations Storage





Each servent maintains two repositories that store its
opinions about resources and servents it had
experiences
resource_repository: set of pairs
(resource_id, value)
servent_repository: set of triples
(servent_id, num_plus, num_minus)
A peer votes on resources and servents with which it
had experiences
translation of reputations into votes: votes are
expressed on the basis of information available in the
resource_repository & servent_repository
XRep: Polling Protocol
Phase 1: Resource searching.

p sends a Query message for searching resources, and
servents matching the request respond with a QueryHit
Initiator p
Servent s
Query (Min_Speed, Search_criteria)
QueryHit(num_hit,IP,port,speed,Result,trailer,servent_i
d)
Trailer:
resource_id
XRep: Polling Protocol
Phase 2: Vote polling.
 p polls its peers about the reputation of a resource
and the set of servents that offer it. Peers wishing
to respond send back a PollReply
 Peers vote on the resource_id and each servent_id
Initiator p
Servent s
Poll (resource_id, {servent_id1… servent_idn}, PKpoll)
PollRepley ({(IP,port,Votes)}PKpoll)
XRep: Polling Protocol
Phase 3: Vote evaluation. (two steps)
1. p clusters Voter’s IP and weight the votes within a
cluster --Reducing the effect of a clique
2. p selects a set of voters in each cluster, contacts them
directly, and expects back a confirmation message.
Not enough responses, then p repeats step 2.
Initiator p
Servent s
TrueVote ( Vote )
TrueVoteRepley ( responses )
XRep: Polling Protocol
Phase 4: Best servent check.
 p contacts the best servent S to check the
fact that it exports resource r
Initiator p
Servent s
AreYou (servent_ids, r)
AreYouRepley({response}SKs, PKs)
XRep: Polling Protocol
Phase 5: Resource download.
 p selects a servent s, downloads resource r and
checks it against its digest
 Update its resource_repository &
servent_repository
Initiator p
Servent s
download ( r )
resource ( r )
XRep: Security Considerations

XRep allows to protect P2P against most
knows attacks
Self replication
 Man in the middle
 ID Stealth
 Pseudospoofing
 Shilling

Self replication:
A malicious peer could answer all Queries and
provide doctored content.
 Even honest peers, unaware of the malicious
content, could share it and contributing to its
diffusion.
e.g. Mandragore – a Gnutella worm
 Bad reputations of resource

-- Worms slightly modifying themselves
 Cannot collect positive recommendations
 Check reputation of the servent
Man in the middle:




A broadcasts a Query. B responds a QueryHit.
E replaces IP and Port of the QueryHit with E’s IP and
Port, sends it back to A.
A may download from E.
Unlikely to be chosen. Even is so, the fake content
provided by E will not match the digest of the legitimate
resource, then be discarded. (Phase 5)
A
E
B
ID Stealth:

A malicious peer answers with two
QueryHits, carrying the digest of a
doctored resource and one of them carrying
the ID of a reputable servent
 Xrep
checks whether the best servent is
offering that resource (Phase 4).
Psedospoofing & Shilling: 1


Attackers create and control multiple servents.
They give positive votes to the attacker.
Four cases:
 Multiple servents have same IP address
 IP cluster
 Servents have different but faked IP address

TrueVote/TrueVoteRepley (phase 3)
These two cases are called Psedospoofing
Psedospoofing & Shilling: 2
Servents have different real IP address. And
those IP addresses have same net_id.
 IP cluster may reduce the effect

Servents have different real IP address. And
those IP addresses have different net_id.
 To ensure a high number of voters.

These two cases are call Shilling.
Distribution of Servent & Resource
An important aspect for the applicabilty
of this approach
frequent resources are more frequently
searched
=> the number of votes will be high
 few servents offering many resources
=> these servents will probably well know

Conclusions
XRep is a reputation management protocol
for anonymous P2P environments
 It prevents malicious behaviors in P2P
network
 Future work:

-- reputation mechanism with supernodes
-- performance optimization
References
[1] The Gnutella Protocol Specification v0.4
www9.limewire.com/developer/gnutella_protocol_0.4.pdf
[2] “ A Reputation-based Approach for Choosing Reliable
Resources in Peer-to-Peer Networks," E. Damiani, etc.
[3] http://www.limewire.com/