Secure routing for structured peer-to-peer overlay networks

Miguel Castro, Ayalvadi Ganesh, Antony RowstronMicrosoft Research Ltd.Peter Druschel, Dan S. WallachRice University

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.

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”

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.

Requirements of Secure Routing

1. A secure assignment of node identifiers

2. secure routing table maintenance

3. secure message forwarding

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

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

Pastry:

•nodeIds and keys are sequence of digits in base 2b

•Routing table has 128/2b and 2b columns

•2b 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

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,

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:

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

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”

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

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

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)

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 2nd attack fraction of bad routing table entries to increase

toward 1 as the bad routing updates are propagated.

Solution

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

Secure message forwarding

Probability of routing successfully between two non-faulty nodes is (1-f)h-1

h is log2b(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

Probability of routing to a correct replicab=4

Proposed Solution

Has to ensure that with high probability, one copy of the message reaches each replica root

1. Route message to the key2. Root node returns prospective set of replica

roots3. Did routing work? (apply failure test)

Yes: use these as replica roots No: use expensive redundant routing

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

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

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.

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

Performance of redundant routing100,000 nodes, b=4, l=r=32

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.