1. P2P Storage/Bandwidth Sharing: Fairness and Security

2. Examples Gnutella/KazaA P2P Networks

3. 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

4. Examples Hey, I have a kool song in asf format! Oh really? Let me have a copy!

5. Examples Can I download from you? I’m running out of bandwidth and storage!

6. 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.

7. Flagging Malicious Content The other “Good Guy” is malicious!

8. 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?

9. 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.

10. 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

11. 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 0 1 2 3 4 5 6 7 Any problems?

12. PAST: smart cards CTA User Here is the secure smart card PAST Centralized Scheme (revocation mechanism is needed) Smart cards are assumed to be uncorruptable

13. 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

14. 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?

15. Can you store “Yesterday” for me? Sure! Do I get credit for that? Can I download this song?

16. For the right price!

17. 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?

18. 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

19. 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 2 nd and collaborate when audited

20. 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?

21. 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

22. 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?

23. 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?

24. 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

25. 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?

26. Avoiding attacks I’m controlling this IP subnet! Need to inquire over different IP subnets and confirm the results

27. More attacks 1) I’m sending a query for “Yesterday” 2) I have it and the good guy below does

28. 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?

29. Conclusions Any comments or ideas?