1. Security Considerations for Structured p2p Peng Wang 6/04/2003

2. Outline 1. p2p Networks for file sharing, Napster & Gnutella 2. Chord, Pastry, Tapestry & CAN 3. Security considerations 4. References

3. 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 peer. Architectures Centralized – Napster Unstructured decentralized – Gnutella Structured decentralized – Chord, etc

4. Napster A 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.

5. Napster con’t Napster BAX … Napster.com Join: upload a file list Query the centralized server. Download the file from a peer

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

7. P P: a node looking for a file O: offerer of the file Query QueryHit Download O Match O Unstructured: Gnutella

8. retrieve (K 1 ) 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?

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

10. Each node and each key have a m-bit ID. the ID space is 2 m. 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

11. 2 0 An example of ID circle (space) 6 1 1 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 2 2

12. finger tables To route messages, each node n maintains a finger table with m entries, which store nodeIDs & IPs i th entry in the table at node n contains the identity of the first node s, that succeeds n by at least 2 i-1 on ID circle. s = successor(n + 2 i-1 ), 1  i  m Distance increase exponentially 0 1 2 3 4 5 6 7 startfingers 2=(1+2 0) 3 (=successor(2)) 3=(1+2 1 )3 (=successor(3)) 5=(1+2 2 )0 (=successor(5)) e.g. finger table of node 1

13. finger table example

14. 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) pair. 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)

15. Join A new node N first finds the IP address of any node n’ currently in the system. external mechanisms Initialize fingers of node n asking n’ to look them up, n+2 i-1, 1  i  m. Update the fingers of existing nodes each node maintains a predecessor pointer n will become the i th finger of p, if p precedes n by at least 2 i-1 The i th finger of node p succeeds n. Transfer keys from n’s successor to n

16. Finger tables after node 6 joining

17. Leave is a reverse process of join Update the fingers of other nodes Transfer keys

18. Failures and replications Key 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

19. Pastry Each node and each key have a m-bit ID. the ID space is 2 m. 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.

20. Pastry node state IDs are thought of as a sequence of digits with base 2 b. E.g. b=2 Leaf set contains the numerically closest nodes. It is similar to successor list Routing table has m/b rows with 2 b entries each. The 2 b 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.

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

22. Join & failure Join : Bootstrap Initialize its state tables Inform other nodes in its state tables Failure: Lazily repair  Leaf set  Routing table

23. Similarity Pastry: b=2 0 2 m-1

24. Tapestry & CAN P 43215 1211 109876 20 15 1413 17161918 Tapestry is very similar to Pastry. CAN:

25. Design improvements Reduce the latency of routing, increase system robustness Increase 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

26. Security Considerations Assumption of attackers Node ID Message forwarding DoS Rapid Joins and Leaves Forged routing table update Inconsistent behavior

27. Assumption of Attackers Participants 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

28. Attacks related to NodeID Join 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 network Control other nodes accessing victim file. Partition the network?

29. Attackers may control victim node’s (e.g. V) access to the network. Attacker may control the access of a file. Pastry? V+2 m-1 V V+2 m-2 V+2 m-3 V+2 m-4 Illustration F F a victim node a victim file an attacker node

30. 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 space and signs nodeID certificate.  E.g. CA chooses a public key randomly for the joining node.  The nodeID is hash value of its public key PK. CA’s PK can be installed as part of the p2p software

31. Sybil attacks Attackers cannot choose nodeIDs or joining points But 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 word ID, etc to slow down attackers: Entrance fee, etc. Can a fully decentralized nodeID assignment scheme solve this problem ?

32. Attacks on message routing Assume secure nodeID assignment Attacker is the destination or on the path: E.g. on average, a Chord message is routed by (log 2 N )/2 nodes to reach destination. -- 1,000,000 nodes, (log 2 N )/2=10 -- 10% nodes are controlled by attackers -- P(meet a corrupted node)=1-0.9 10 =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

33. DoS Attacker 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

34. 11 8 13 16 12

35. Other attacks Forged routing table update ? Inconsistent behavior ? We have to have Secure NodeID generation & Multi hash functions !!!

36. 1. Napster. http://www.napster.comhttp://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