Transcript P2P

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
1.
2.
3.
4.
5.
P2P Networks & Gnutella protocol [1]
XRep protocol [2]
Security considerations on XRep
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)
Each servent has a servent_id
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 1

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.
Descriptor routing 2

A servent will decrement a descriptor header’s TTL
field, and increment its Hops field, before it forwards
the descriptor to any directly connected servent.

If, after decrementing the header’s TTL field, the TTL
field is found to be zero, the descriptor is not
forwarded along any connection.

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
ServentsQueryHit
will forward
incoming Query
descriptors
may
A servent
receiving
a
descriptor
which
descriptors to all of its directly
only
be
sent
along
the
same
Ahas
servent
will
respond
with
aone
received
before
will
not
forward
connected
servents,
except
the
If
the
TTL
field
is
found
tothat
A servent
requiring
a
file
path
that
carried
the
incoming
thedelivered
descriptor
QueryHit
ifbe
a match
found is
the
incoming
Query.
zero,
theisdescriptor
broadcasts
a Query out.
Query descriptor
against itsnot
local
database.
forwarded
along any
connection.
8
3
Match
2
4
7
Match
9
5
1: initiator
2&7: responders
6
1
Query
QueryHit
Not a descriptor
Structure of Gnutella descriptor
Every descriptor has two parts:
1. Header

Descriptor ID Payload Descriptor
TTL
Hops Payload Length
+
2. Payload
Query: sent by initiator
Minimum Speed
Search criteria
QueryHit: sent by responder
Number
of Hits
Port
IP
Speed Result Set
File
File
Index Size
Trailer Servent
File
Name
file1
file2
file3
ID
Motivation of Reputation systems

Most P2P systems protect peers’ anonymity.
Anonymity opens the door to possible misuses and
abuses. No way to verify the source or content of files
-- Bad service, low quality files
-- 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 files.
XRep: Basic Assumptions

Each servent maintains information on its own
experience on files and other servents and share such
experience with others upon request

Each servent has a servent_id which is a digest of a
public key obtained using a secure hash function
Servent reputations are associated with the servent_id



Each file has a resource_id which is a digest
computed by applying a secure hash function to the
file content
File reputations are coupled to resource_id
Reputations Storage & votes calculation 1

Each servent maintains a resource_repository &
a servent_repository that store its opinions about
files and servents it had experiences

A servent votes on files and servents with which it
had experiences.Votes are its opinion on files and
servents
Votes are expressed on the basis of information
available in the resource_repository &
servent_repository.

Reputations Storage & votes calculation 2


resource_repository: set of pairs
(resource_id, value) value=0 or 1
servent_repository: set of triples
(servent_id, num_plus, num_minus)
num_plus, num_minus are positive integers

Vote = 0 or 1
Vote of servent =1, if num_plus>>num_minus

Vote of file = value

XRep: Polling Protocol
Phase 1: Resource searching.

p sends a Query message for searching files, 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_set,trailer,servent_i
d)
Trailer:
resource_ids of files in result set
Phase 2: Vote polling



P selects a file r that best seems to satisfy its request. Such
selection may be guided by the user’s preference
p polls its peers about the reputation of a file and the set of
servents that offer it.
Servents wishing to respond vote on the resource_id and
servent_ids and send back a PollReply
Initiator p
Servent s
Poll (resource_id, {servent_id1… servent_idn}, PKpoll)
PollReply ({(IP,port,Votes)}PKpoll)
Phase 3: Vote evaluation & reliability check
1. p decrypts PollReply, discards tampered ones.
2. p clusters Voter’s IP and weight the votes within a
cluster --Reducing the effect of a clique
3. p selects a set of voters in each cluster, contacts them
directly, and expects back confirmation messages. If
not enough responses, then p repeats step 3.
Initiator p
Servent s
TrueVote ( Vote )
TrueVoteReply ( responses )
Phase 4: Best servent check



p cannot always download file from best servent
p contacts the best servent S to check the fact that
it exports file which p wants to download
Preventing ID stealth attack.
Initiator p
Servent s
AreYou (servent_ids, resource_id)
AreYouRepley({response}SKs, PKs)
Phase 5: Resource download
p selects a servent s, downloads the file r
and checks it against its digest
 Update its resource_repository &
servent_repository

Initiator p
Servent s
download ( r )
resource ( r )
Servent s
Initiator p
Query (Min_Speed, Search_criteria)
Resource
Searching
{
{
Vote
evaluation {
Vote polling
Best
servent
check
download
QueryHit(num_hit,IP,port,speed,Result,trailer,servent_id)
Poll (resource_id, {servent_id1… servent_idn}, PKpoll)
PollRepley ({(IP,port,Votes)}PKpoll)
TrueVote ( Vote )
TrueVoteRepley ( responses )
AreYou (servent_ids, resource_id)
{
AreYouRepley({response}SKs, PKs)
{
download ( r )
resource ( r )
XRep: Security Considerations

XRep allows to protect P2P against
following attacks
Self replication
 Man in the middle
 ID Stealth
 Pseudospoofing
 Shilling

Self replication:
A malicious servent 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 file

-- 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.
The fake content provided by E will not match the digest
of the legitimate file, then be discarded. (Phase 5)
A
E
B
ID Stealth:

A malicious peer answers with two
QueryHits, carrying the digest of a
doctored file and one of them carrying the
ID of a reputable servent
 Xrep
checks whether the best servent is
offering that file (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 (phase 3)
 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 (phase 3)

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 files are more frequently searched
=> the number of votes will be high
 few servents offering many files
=> these servents will probably well know
 Cold-start problem

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/