1. Secure routing for structured peer-to-peer overlay networks Miguel Castro, Ayalvadi Ganesh, Antony Rowstron Microsoft Research Ltd. Peter Druschel, Dan S. Wallach Rice University

2. Issues addressed: Current structured P2P overlay networks are not secure Even a small fraction of malicious nodes can prevent correct message delivery throughout the overlay To study the attacks aimed at preventing correct message delivery in structured peer-to-peer overlays and presents defenses to these attacks. To evaluate techniques that allow nodes to join the overlay, to maintain routing state, and to forward messages securely in the presence of malicious nodes.

3. The problem P2P systems: resilient but not secure Malicious nodes:  fake IDs  distort routing table entries  prevent correct message delivery “Techniques to allow nodes to join, to maintain routing state, and to forward messages securely in presence of malicious nodes”

4. Why need Secure routing Traditionally P2P networks provide platform for decentralized services (NS, CD & app. Level Mcast) Scalable, fault-tolerant, effective load balancing Open env. Mutually dist. Ent. Allowed to join Unrealistic to assume that nodes are not compromised Struct. Overlays must be robust to a variety of security attacks. Secure routing is a key building block.

5. Requirements of Secure Routing 1. A secure assignment of node identifiers 2. secure routing table maintenance 3. secure message forwarding

6. Background, Models and solution Routing Overlay Model Nodes are assigned random nodeIds from a large IdSpace App. Specific objects are assigned unique keys Each key is mapped by the overlay to a unique live node the key’s root Each node maintains a routing table with nodeIds of other nodes and their as­sociated IP addresses neighbor set, consisting of some number of nodes with nodeIds near the current node in the id space application objects are stored at more than one node in the overlay A replica function maps an object’s key to a set of replica keys, such that the set of replica roots associated with the replica keys represents a random sample of participating nodes in the overlay

7. Pastry: nodeIds are random, uniform in circular 128-bit id space Msg. routed toward live node with closest numerical id to the key Node keeps track of neighbor set

8. Pastry: nodeIds and keys are sequence of digits in base 2 b Routing table has 128/2 b and 2 b columns 2 b entries in row r contain the IP addresses of nodes whose nodeIds share the first r digits with the present node’s nodeId Node State Leaf Set Set of l nodes with nodeids numerically closest to the present nodeId l/2 larger and l/2 smaller nodesIds Leaf set stores replicas of application objects

9. Pastry: Message Routing: A node seeks to forward the message to a node in the routing table whose nodeId shares with the key a prefix that is at least one digit (or b bits) longer than the prefix that the key shares with the present node’s id. Otherwise to a node whose nodeId shares a prefix with the key as long as the current node, but is numerically closer to the key than the present node’s id Otherwise current node or its immediate neighbor is the message’s final destination expected number of routing hops is slightly below log N,

10. X can initialize its state by asking any existing node A to route a special message using X as the key The message is routed to the existing node Z with nodeId numerically closest to X X then obtains the neighbor set from Z constructs its routing table by copying rows from the routing tables of the nodes it encountered on the original route from A to Z X announces its presence to the initial members of its neighbor set Members of the neighbor set update their own neighbor sets and routing tables New Node additions: Pastry:

11. Can, Chord, Tapestry In Tapestry, neighboring nodes in the names-pace are not aware of each other. Tapestry does Surrogate routing Chord uses a 160-bit circular id space, forwards messages only in clockwise direction in the circular id space Chord nodes maintain a routing table consisting of up to 160 pointers to other live nodes a.k.a. finger table. CAN routes messages in a d-dimensional space, where each node maintains a routing table with O(d) entries. CAN’s routing table does not grow with the network size

12. The system model N nodes Bound f on the fraction of faulty nodes Bound cN on the number of faulty nodes in coalition Every node has a static IP address “Secure routing ensures that when a non-faulty node sends a message to key k, the message reaches all non- faulty members is the set of replica roots Rk with very high probability”

13. Sub-problems Securely assigning IDs to nodes  attacker may capture all replicas for an object  attacker may target a particular victim Securely maintaining routing tables  attackers may populate with faulty entries  most messages are routed to faulty nodes Securely forwarding messages  even with proper routing tables, faulty nodes can corrupt, drop, misroute messages

14. Secure nodeId assignment Attacker can partition a chord or Pastry overlay by controlling two complete and disjoint neighbor sets Attacker may arrange for every entry in a victim's routing table and neighbor set to point to a hostile node Victim's access to the overlay network is completely mediated by the attacker. Attacker can choose the closest nodeIds to all replica keys for a particular target object, thus controlling all replica roots and may delete, corrupt, or deny access to the object a.k.a. ”DOS” Attacker can launch a “Sybil attack” by obtaining a large number of legitimate nodeIds easily Attacks

15. Solution: Certified nodeIDs Offline certification authorities  assign random IDs to nodes  certificate binds the ID to public key and IP attacker cannot swap IDs between his nodes bad for dynamic address assignment, host mobility, or organizational changes CAN nodeIDs change when nodes join and depart  Avoid giving multiple IDs to one entity charge for each certificate – increases cost of attack (e.g. cost of 1 net with 1,000,000 nodes is $2,000,000 with $20 per cert.) bind IDs to existing trustworthy identities (like in the case of vitual private overlays)

16. Secure routing table maintenance Should have at most fraction f of faulty entries  worst for row 0 of the Pastry routing table  during node joins, probability of getting a faulty entry is (1 - f) x f + f x 1 > f Impose constraints on the table entry  required to be closest to some point in ID space like Chord  This constraint can be verified and independent of network proximity information Attacks  Attackers may fake proximity to increase the fraction of bad routing table entries  In 2 nd attack fraction of bad routing table entries to increase toward 1 as the bad routing updates are propagated. Solution

17. One solution for Pastry: two routing tables Normal locality-aware routing table A constrained routing table  Row l, column d entry for node i: shares a prefix of length l with I has d as its (l+1) st digit closest nodeID to the point p: p satisfies above properties and has remaining digits same as i New state initialization algorithm exploiting an interesting property

18. Secure message forwarding Probability of routing successfully between two non- faulty nodes is (1-f) h-1  h is log 2 b (N) for Pastry Probability of routing correctly to a non-faulty replica root is (1-f) h Tradeoff: increasing b decreases the number of hops but also increases the amount of state information

19. Probability of routing to a correct replica b=4

20. Proposed Solution Has to ensure that with high probability, one copy of the message reaches each replica root 1. Route message to the key 2. Root node returns prospective set of replica roots 3. Did routing work? (apply failure test) Yes: use these as replica roots No: use expensive redundant routing

21. Routing failure test Takes a key and the set of prospective replica roots Returns negative if the set of roots is likely to be correct for the key; otherwise positive If no set is returned, returns positive Works by comparing the density of nodeIDs in the sender’s neighborhood set with the density of nodeIDs close to the replica roots of the destination key

22. Attacks against Routing failure test 1. Attacker can collect nodeId certificates of nodes that have left the overlay, and use them to increase the density of a prospective root neighbor set. 2. Attacker can include both nodeIds of nodes it controls and nodeIds of correct nodes in a prospective root neighbor set

23. Counter-measures against RFT attacks Have the sender contact all the prospective root neighbors to  determine if they are live  if they have a nodeId certificate that was omitted from the prospective root neighbor set. Prospective root returns to the sender a message with the list of  nodeId certificates  secure hashes of the neighbor sets reported by each of the prospective root neighbors  set of nodeIds that are used to compute the hashes in the above list. The sender checks that the hashes are consistent with the identifiers of the prospective root neighbors. Then, it sends each prospective root neighbor the corresponding neighbor set hash for confirmation.

24. Redundant routing If the failure test returns positive Use constrained routing table P sends the message to key x via different members of its neighborhood set  messages take diverse paths Any non-faulty node that receives the message and has the root of x in its neighborhood set, sends its certificate to p p collects such certificates in a list; sends the list to all nodes in the list. Process iterates upto 3 times p computes the closest neighbor’s to x Neighbor set anycast

25. Performance of redundant routing 100,000 nodes, b=4, l=r=32

26. Conclusions Structured peer-to-peer overlay networks have previously assumed a fail-stop model for nodes, however, it is possible to compromise the overlay and the applications built upon it. Different techniques for secure node joining, routing table maintenance, and message forwarding in structured p2p overlays are there. The routing failure test allows the use of efficient proximity-aware routing in the common case The use of secure routing can be reduced by using self-certifying application data. These techniques allow us to tolerate up to 25% malicious nodes while providing good performance when the fraction of compromised nodes is small.