Secure PeertoPeer File Sharing Frans Kaashoek David Karger

SFS: a secure global file system Client H 21 client Oxygen H 21 Server

SFS results • Research: how to do server authentication? – Self-certifying pathnames – flexible

New direction: peer-to-peer file sharing • How to build distributed systems without centrally -managed

Peer-to-peer sharing example Internet • Internet users share music files – Share disk storage

Goal: Better Peer-to-Peer Storage • Lookup is the key problem • Lookup is not

Lookup problem N 1 N 2 ? N 3 Fetch(name) N 4 Author Insert(name,

Chord Architecture • Interface: – lookup(Document. ID) Node. ID, IP-Address • Chord consists of

Consistent Hashing D 120 (0) N 105 D 20 Circular 7 -bit ID space

Chord Uses log(N) “Fingers” (0) ½ ¼ 1/8 Circular 7 -bit ID space 1/16

Chord Finger Table (0) N 32’s Finger Table N 113 N 102 N 32

Chord Lookup (0) N 32’s Finger Table N 113 N 102 N 32 N

New Node Join Procedure N 20’s Finger Table (0) N 113 N 20 N

New Node Join Procedure (2) (0) N 113 N 20 N 102 N 32

New Node Join Procedure (3) (0) N 113 N 20 N 102 D 114.

Chord Properties • Log(n) lookup messages and table space. – Log(1, 000) 20 •

File sharing with Chord Client App (e. g. Browser) get(key) put(k, v) Key/Value Chord

Chord Status • • Working Chord implementation SFSRO file system layered on top Prototype

Open Issues • • • Network proximity Malicious data insertion Malicious Chord table information

Chord Summary • Chord provides distributed lookup – Efficient, low-impact join and leave •

Slides: 20

Download presentation

Secure Peer-to-Peer File Sharing Frans Kaashoek, David Karger, Robert Morris, Ion Stoica, Hari Balakrishnan http: //www. pdos. lcs. mit. edu/chord MIT Laboratory for Computer Science 1

SFS: a secure global file system Client H 21 client Oxygen H 21 Server MIT /global/mit/kaashoek/sfs • One name space for all files • Global deployment • Security over untrusted networks 2

SFS results • Research: how to do server authentication? – Self-certifying pathnames – flexible key management • Complete system available – www. fs. net – 80, 000 lines of C++ code? – Toolkit for file system research • System used inside and outside MIT • Ported to i. PAQ 3

New direction: peer-to-peer file sharing • How to build distributed systems without centrally -managed servers? • Many Oxygen technologies are peer-to-peer – INS, SFS/Chord, Grid • Chord is a new elegant primitive for building peerto-peer applications 4

Peer-to-peer sharing example Internet • Internet users share music files – Share disk storage and network bandwidth – Nodes are less reliable than centrally-managed ones 5

Goal: Better Peer-to-Peer Storage • Lookup is the key problem • Lookup is not easy: – GNUtella scales badly – Freenet is imprecise • Chord lookup provides: – Good naming semantics and efficiency – Elegant base for layered features 6

Lookup problem N 1 N 2 ? N 3 Fetch(name) N 4 Author Insert(name, document) Consumer N 6 N 5 – Current systems don’t scale: GNUtella, Free. Net 7

Chord Architecture • Interface: – lookup(Document. ID) Node. ID, IP-Address • Chord consists of – Consistent Hashing – Small routing tables: log(n) – Fast join/leave protocol 8

Consistent Hashing D 120 (0) N 105 D 20 Circular 7 -bit ID space N 32 N 90 D 80 Example: Node 90 is the “successor” of document 80. 9

Chord Uses log(N) “Fingers” (0) ½ ¼ 1/8 Circular 7 -bit ID space 1/16 1/32 1/64 1/128 N 80 knows of only seven other nodes. 10

Chord Finger Table (0) N 32’s Finger Table N 113 N 102 N 32 N 85 N 40 N 80 N 79 N 52 N 70 33. . 33 34. . 35 36. . 39 40. . 47 48. . 63 64. . 95 96. . 31 N 40 N 52 N 70 N 102 N 60 Node n’s i-th entry: first node n + 2 i-1 11

Chord Lookup (0) N 32’s Finger Table N 113 N 102 N 32 N 85 N 40 N 80 N 52 N 79 N 70 N 60 33. . 33 34. . 35 36. . 39 40. . 47 48. . 63 64. . 95 96. . 31 N 40 N 52 N 70 N 102 N 70’s Finger Table 71. . 71 N 79 72. . 73 N 79 74. . 77 N 79 78. . 85 N 80 86. . 101 N 102. . 5 N 102 6. . 69 N 32 N 80’s Finger Table 81. . 81 N 85 82. . 83 N 85 84. . 87 N 85 88. . 95 N 102 96. . 111 N 102 112. . 15 N 113 16. . 79 N 32 Node 32, lookup(82): 32 70 85. 12

New Node Join Procedure N 20’s Finger Table (0) N 113 N 20 N 102 N 32 N 40 N 80 21. . 21 22. . 23 24. . 27 28. . 35 36. . 51 52. . 83 84. . 19 N 52 N 70 N 60 13

New Node Join Procedure (2) (0) N 113 N 20 N 102 N 32 N 40 N 80 N 52 N 70 N 20’s Finger Table 21. . 21 22. . 23 24. . 27 28. . 35 36. . 51 52. . 83 84. . 19 N 32 N 40 N 52 N 102 N 60 Node 20 asks any node for successor to 21, 22, …, 52, 84. 14

New Node Join Procedure (3) (0) N 113 N 20 N 102 D 114. . 20 N 32 N 40 N 80 N 52 N 70 N 20’s Finger Table 21. . 21 22. . 23 24. . 27 28. . 35 36. . 51 52. . 83 84. . 19 N 32 N 40 N 52 N 102 N 60 Node 20 moves documents from node 32. 15

Chord Properties • Log(n) lookup messages and table space. – Log(1, 000) 20 • Well-defined location for each ID – No search required • Natural load balance • Minimal join/leave disruption • Does not store documents… 16

File sharing with Chord Client App (e. g. Browser) get(key) put(k, v) Key/Value Chord Client Server lookup(id) • Fault tolerance: store values at r successors • Hot documents: cache values along Chord lookup path 17 • Authentication: self-certifying names

Chord Status • • Working Chord implementation SFSRO file system layered on top Prototype deployed at 12 sites around world Understand design tradeoffs 18

Open Issues • • • Network proximity Malicious data insertion Malicious Chord table information Anonymity Keyword search and indexing 19

Chord Summary • Chord provides distributed lookup – Efficient, low-impact join and leave • Flat key space allows flexible extensions • Good foundation for peer-to-peer systems http: //www. pdos. lcs. mit. edu/chord 20