P2P Storage/Bandwidth Sharing:Fairness and Security

Examples

Gnutella/KazaA P2P Networks

Properties of Gnutella/KazaA

•Completely decentralized

•Nobody to sue (like in Napster), corporations try to sabotage use of the networks

•No revocation/security mechanisms

•Freeloaders thrive

Examples

Hey, I have a kool song

in asf format!

Oh really? Let me have a copy!

ExamplesCan I download

from you?I’m running

out of bandwidth

and storage!

Major Issues

•Malicious files and malicious servers should be flagged in a secure way

•Freeloaders should not be able to utilize the system as freely as honest contributors.

Flagging Malicious Content

The other “Good Guy” is

malicious!

How do we flag malicious behaviour/content?

• No centralized trusted entity to give this job to

• Some users may be “bad-mouthing” on others. Therefore, any one user can not be trusted

• Do we flag users that unknowingly pass somebody else’s content?

• Online or offline credentials checks?

How do we restrict freeloading?

• For fair storage distribution, we need to be assured that an “honest” user indeed stores the files he claims. This has to be done continuously since a user can always “dump” the files.

• For fair bandwidth usage, one needs to be assured that an “honest” user provides sufficient bandwidth to others.

• PAST is a secure distributed file-replication system based on Pastry routing network

• A user can not control where his file will be replicated but he can control the number of replicas (see a note below)

• A dynamic “challenge” mechanism makes sure that the replicas are really being stored

• PKI is used for digital signatures

• PAST is most suitable for backup storage or when the storage demands of a user are higher than his capacity.

PAST: review

PAST: review (cont’d)

• Every node has semi-random nodeId assigned to it. Each file is assigned semi-random fileId

• A file is replicated among the nodes whose nodeId’s are closest to the fileId (which is generated with a smartcard)

fileId=5, 3 copies

01

2

34

5

6

7

Any problems?

PAST: smart cards

CTA

User

Here is the secure smart card

PAST

Centralized Scheme(revocation mechanism is

needed)

Smart cards are assumedto be uncorruptable

P2P Storage Sharing based on PAST

• Smart card infrastructure contradicts decentralized nature of P2P networks (Napster is dead but Gnutella and KazaA are thriving)

• With no central control, decisions should be made by inquiring a quorum of other (random) users

• Business model should be defined

• Equilibrium should exist in the system

Business Model

• What does a user gain by allowing others to download its files?

• Should a user be charged for replication in PAST, or more generally for storing its files remotely?

• How 2 unacquainted users interact with each other?

• How would a new user be able to enter the network?

Can you store “Yesterday” for me?

Sure! Do I get credit for that?

Can I download this song?

Can I download this song?

Can I download this song?Can I download this

song?

For the right price!

Security Model

• How about collaboration attacks?

• Faking storage of a file?

• Faking/inflating popularity?

• Inflating bandwidth provided?

• Can these collaboration be formed dynamically in a way beneficial to the collaborating parties?

• Should the user have a say where he stores his files?

Storage Sharing Model

1). I’m auditing you. You store your files remotely but who do you store files for?

2). I’m storing files for the guy below

3) Is that true?4) It’s true

1) I want to store file A at your places

2) This file is huge! Let me keep the first half and you keep the 2nd and collaborate when

audited

Bandwidth Sharing Model

1) I need to download file from you. I’ll be 3 MB in debt to you

2) OK, but you’ll need to return the favor before next download from me

1) I know you don’t owe me, but the guy in between owes me and

you owe him.

2) OK but the transfer has to go through the middle guy

Cold start?

Cold Start

• A user with no bandwidth credit should not be given “good faith” credit

• Instead the new user should cache/publish popular content to accumulate bandwidth credit. Should PAST replication be used?

• QoS metrics can be used on a pairwise level

Reputations of content and servers

• Orthogonal to fair storage/bandwidth sharing

• A server may be publishing somebody else’s malicious file, or a malicious server may be publishing also good files. Need to separate reputations of servers and files.

• Good reputation allows for server to download more files and attracts others, thereby accumulating bandwidth/storage credit. “Rich get richer”

• How to avoid cold starts for servers and files?

1) Go ahead, download my files

2) OK, these files look fine. I’ll publish them as well

3) I want to dload the files

4) Why is my system down? Did the guy on the right send

bad files on purpose?

1) Can you send me “Matrix Reloaded?

2) Sending it now

3) How about “Hours” instead?

Need to be able to check integrity of files incrementally

Other issues

•Changing 1 bit in a song does not change the song but the file is different. If 2 files differ slightly should they have similar reputation?

•A fixed file should have a fixed fileId (hash of its content for example) but it’s not required. The same goes for nodeId

•One can poll for reputations but can this be done offline?

•When do we eject the server from the network?

Avoiding attacks

I’m controlling this IP subnet!

Need to inquire over different IP subnets andconfirm the results

More attacks

1) I’m sending a query for “Yesterday”

2) I have it and the good guy below does

Incentives to users

•Changing 1 bit nullifies reputation, therefore self-modifying worms/viruses will not spread quickly.

•A fixed file should have a fixed fileId (hash of its content for example) but it’s not required. The same goes for nodeId

•One can poll for reputations but can this be done offline?

•When do we eject the server from the network?

Conclusions

Any comments or ideas?