Security Considerations for Structured p2p

Peng Wang6/04/2003

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

Similarity

Pastry:b=2

0

2m-1

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

11

8

13

16

12

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