Upload
job-wilson
View
219
Download
0
Tags:
Embed Size (px)
Citation preview
Outline
1. p2p Networks for file sharing, Napster & Gnutella
2. Chord, Pastry, Tapestry & CAN3. Security considerations 4. References
P2P Networks for file sharing
p2p networks for file sharing involve two phases:1. find out the peer storing the requested file.2. Download the requested file from the exporting pe
er.
Architectures Centralized – Napster Unstructured decentralized – Gnutella Structured decentralized – Chord, etc
NapsterA central server stores a “index table”. (file name, IP address) pairs
The index table contains location info of all the files available within the Napster user community
To retrieve a file, a initiator queries this central server using the name of the desired file, and obtains the IP address of the supplier storing that file.
The file is downloaded directly from this supplier.
Napster con’t
Napster
BA X…
Napster.com
• Join: upload a file list
• Query the centralized server.
• Download the file from a peer
Napster con’t
Napster uses a p2p communication model for the actual file transfer.
The process of locating a file is still centralized.
To decentralize this process, Every node store its own list -- Unstructured break down the index table into small pieces. Each
peer stores a piece of the table -- Structured
PP
P: a node looking for a file
O: offerer of the file
Query
QueryHit
Download
OOMatch
OOMatch
Unstructured: Gnutella
retrieve (K1)
K V
K V
K V
K V
K V
K V
K V
K V
K V
K V
K V
www.acu.rl.ac.uk/msn2002/Talks/JonCrowcroft-futuregrid.ppt
Structured p2p
How to find the peer which stores the piece containing the location info of the desired file?
Chord, Pastry, Tapestry & CAN
The lookup protocol maps a desired key (hash value of file name) to the IP address of the node responsible for that key.
A storage protocol layered on top of the lookup protocol then takes care of storing, replicating, caching, retrieving, and authenticating the files.
Each node and each key have a m-bit ID. the ID space is 2m. Chord arranges the ID space on a circle.
Uses SHA-1 hash function to assign ID. Key ID = SHA-1(key) Node ID = SHA-1(IP address)
successor(k): the node with ID equal to or follows a key’s ID k in the ID space.File -- (k, IP address) pair(k, IP address) pair of a file is stored at successor(k).
Chord
2
0
An example of ID circle (space)
6
11
2
3
4
5
6
7
Successor(2)=3
Successor(1)=1
Successor(6)=0
• m=3
• 3 keys: 1,2,6
• 3 nodes: 0,1,3
2
6
a node
a file whose ID is 22
finger tablesTo route messages, each node n maintains a finger table with m entries, which store nodeIDs & IPs ith entry in the table at node n contains the identity of the first node s, that succeeds n by at least 2i-1 on ID circle.
s = successor(n + 2i-1), 1 i m Distance increase exponentially
01
2
3
4
5
6
7
start fingers
2=(1+20) 3(=successor(2))
3=(1+21) 3(=successor(3))
5=(1+22) 0(=successor(5))
e.g. finger table of node 1
finger table example
0
1
2
3
4
5
6
7
2
finger table
start Int. Succ.
4
57
[4,5)
[5,7)
[7,3)
0
0
0
keys
6
finger table
start Int. Succ.
1
24
[1,2)
[2,4)
[4,0)
1
3
0
keys
1
finger table
start Int. Succ.
2
35
[2,3)
[3,5)
[5,1)
3
3
0
keys
routing
0
1
2
3
4
5
6
7
6
Given k, to find the (k, IP address) pair of k. find immediate predecessor p of k, with
help from other nodes. p’s successor is the successor of k. the successor of k has the (k, IP address) pai
r.e.g. node 1 wants to find a key 6• finds out node 3 is a
predecessor• Sends a message to node 3• Node 3 knows it’s the
immediate predecessor of key 6
• Node 3 sends a message to its successor 0.
• 0 sends (6, IP) back to node 1.
Node 1 wants 6
(k, IP)
JoinA new node N first finds the IP address of any node n’ currently in the system.
external mechanismsInitialize fingers of node n
asking n’ to look them up, n+2i-1, 1 i m.
Update the fingers of existing nodes each node maintains a predecessor pointer n will become the ith finger of p, if
p precedes n by at least 2i-1
The ith finger of node p succeeds n.
Transfer keys from n’s successor to n
Finger tables after node 6 joining
0
1
2
3
4
5
6
7
2
finger table
start Int. Succ.
4
57
[4,5)
[5,7)
[7,3)
6
6
0
keys
finger table
start Int. Succ.
1
24
[1,2)
[2,4)[4,0)
1
3
6
keys
1
finger table
start Int. Succ.
2
35
[2,3)
[3,5)
[5,1)
3
3
6
keys
6
finger table
start Int. Succ.
7
02
[1,2)
[2,4)
[4,0)
0
0
3
keys
Leave is a reverse process of join
0
1
2
3
4
5
6
7
2
finger table
start Int. Succ.
4
57
[4,5)
[5,7)
[7,3)
6
6
0
keys
finger table
start Int. Succ.
1
24
[1,2)
[2,4)[4,0)
3
3
6
keys
6
finger table
start Int. Succ.
7
02
[1,2)
[2,4)
[4,0)
0
0
3
keys
1
Update the fingers of other nodes
Transfer keys
Failures and replicationsKey step: maintaining correct successor pointers Each chord node maintains a successor-list There are r immediate successors on the list After failure, a node will know first live
successor Correct successors guarantee correct lookups
The (key, IP address) pair database of the Failed node is lost. Replications of (key, IP address) pair databases. Periodical refresh messages sent by supplier (file
holder) to handle stale, lost pairs
PastryEach node and each key have a m-bit ID. the ID space is 2m. E.g. m=128, Uses md5 to assign ID. Pastry arranges the ID space on a circle.
Routes messages to the node whose nodeID is numerically closest to the given key. Prefix routing: forward message to a node
whose nodeID shares longer prefix with the given key comparing the present node.
If no such node, forward to a numerically closer node.
Pastry node state•IDs are thought of as a sequence of digits with base 2b. E.g. b=2
•Leaf set contains the numerically closest nodes. It is similar to successor list
•Routing table has m/b rows with 2b entries each.
•The 2b entries at row i each refer to a node whose nodeId shares the present node’s nodeId in the first i digits, but whose i+1th digit is the column number.
Routing When a message with key D arrives•If D is in the range of leaf set, forward it to the nearest one.•Or forward it to a node shares longer prefix with D according to the Routing table.•Otherwise, forward it to any node who is numerically closer to D.
e.g. route message with 10232333 to node 10232121
Join & failure
Join : Bootstrap Initialize its state tables Inform other nodes in its state tables
Failure: Lazily repair
Leaf setRouting table
Tapestry & CAN
P4321 5
1211
109876
20
15
1413
1716 1918
• Tapestry is very similar to Pastry.
• CAN:
Design improvementsReduce the latency of routing, increase system robustnessIncrease per-node state and system complexity
e.g. Multiple hash functions use k different hash functions a single file is mapped onto k points in the space and corresponding (hash value, IP) pairs are
stored at k distinct nodes k replicas, parallel routing, but more query traffic
Security Considerations
Assumption of attackers
Node IDMessage forwarding DoSRapid Joins and LeavesForged routing table updateInconsistent behavior
Assumption of AttackersParticipants who do not follow the protocol correctly
Provide false information, forge source IP address
Modify, drop message passing them
May conspire together
Cannot overhear or modify direct communication between other nodes
Attacks related to NodeIDJoin attack Where a node is located on the ID circle depends on its nodeID. If an attacker can choose its nodeID, then she can Control victim node’s access to the p2p net
work Control other nodes accessing victim file. Partition the network?
Attackers may control victim node’s (e.g. V) access to the network. Attacker may control the access of a file. Pastry?
V+2m-1
V
V+2m-2
V+2m-3
V+2m-4
Illustration
FF
a victim node
a victim file
an attacker node
Secure NodeID generation Prevent attackers from choosing joining point as they want !!!Certified nodeID Uses a central, trusted authority (CA) CA chooses nodeID randomly from the ID sp
ace and signs nodeID certificate. E.g. CA chooses a public key randomly for the jo
ining node. The nodeID is hash value of its public key PK.
CA’s PK can be installed as part of the p2p software
Sybil attacksAttackers cannot choose nodeIDs or joining pointsBut they can obtain a large number of legitimate nodeIDs easily.Attacker may control large amount of nodes
crypto puzzles ?Uses a trusted Authorities (CA) to guarantee the uniqueness: bind nodeID to real w
ord ID, etc to slow down attackers: Entrance fee, etc.
Can a fully decentralized nodeID assignment scheme solve this problem ?
Attacks on message routing
Assume secure nodeID assignmentAttacker is the destination or on the path: E.g. on average, a Chord message is routed by (lo
g2N)/2 nodes to reach destination.
-- 1,000,000 nodes, (log2N)/2=10
-- 10% nodes are controlled by attackers-- P(meet a corrupted node)=1-0.910=65%
Drops, modifies or sends wrong answer back Detect –check responder’s ID and signature ? Non-deterministic routing – change route ? Multi hash functions – replicas Attacker cannot control all replicas
DoSAttacker generates huge amount of query messages. Victim node can not serve other nodes Incoming Allocation Strategy
Assumption: Secure nodeID assignment,each node has a list of incoming messages senders
Processor scheduling strategy E.g. Round-Robin (RR) scheduling Check senders’ Ids
Rapid Joins and Leaves trivial to prevent with Secure nodeID assignment
Other attacksForged routing table update ?
Inconsistent behavior ?
We have to have Secure NodeID generation & Multi hash functions !!!
1. Napster. http://www.napster.com
2. The Gnutella Protocol Specification v0.4, www9.limewire.com/developer/gnutella_protocol_0.4.pdf
3. Sit, E. and Morris R. Security Considerations for Peer-to-Peer Distributed Hash Tables March 2002
4. John R. Douceur. The Sybil attack. March 2002
5. Neil Daswani and Hector Garcia-Molina Query-flood DoS attacks in Gnutella November 2002
6. A. Rowstron and P. Druschel, "Pastry: Scalable, distributed object location and routing for large-scale peer-to-peer systems". IFIP/ACM International Conference on Distributed Systems Platforms (Middleware), Heidelberg, Germany, pages 329-350, November, 2001.
7. M. Castro, P. Druschel, A. Ganesh, A. Rowstron, and D. S. Wallach, "Security for structured peer-to-peer overlay networks". In Proceedings of the Fifth Symposium on Operating Systems Design and Implementation (OSDI'02), Boston, MA, December 2002.
8. Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, and Hari Balakrishnan, Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications, ACM SIGCOMM 2001, San Deigo, CA, August 2001, pp. 149-160.
9. Dan S. Wallach, A Survey of Peer-to-Peer Security Issues, International Symposium on Software Security (Tokyo, Japan), November 2002.
10. Sylvia Ratnasamy, Paul Francis, Mark Handley, Richard Karp, Scott Shenker A Scalable Content-Addressable Network, ACM SIGCOMM 2001.
11. Ben Y. Zhao, John Kubiatowicz, Anthony D. Joseph Tapestry: An Infrastructure for Fault-tolerant Wide-area Location and Routing, UC Berkeley
References