Secure routing for structured peertopeer overlay networks

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

• A secure assignment of node identifiers
• secure routing table maintenance
• 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 keys root
• Each node maintains a routing table with nodeIds
  of other nodes and their associated 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 objects 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
Node State

• 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 ?rst r digits with
  the present nodes nodeId

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 nodes id.
• Otherwise to a node whose nodeId shares a pre?x
  with the key as long as the current node, but is
  numerically closer to the key than the present
  nodes id
• Otherwise current node or its immediate neighbor
  is the messages ?nal destination
• expected number of routing hops is slightly below
  log N,

10
Pastry
New Node additions

• 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

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.
  ?nger table.
• CAN routes messages in a d-dimensional space,
  where each node maintains a routing table with
  O(d) entries.
• CANs 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
Attacks

• 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

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

• 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

• 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 gt 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

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 (l1) 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 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

19
Probability of routing to a correct replicab4
20
Proposed Solution

• Has to ensure that with high probability, one
  copy of the message reaches each replica root
• Route message to the key
• Root node returns prospective set of replica
  roots
• 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
  senders neighborhood set with the density of
  nodeIDs close to the replica roots of the
  destination key

22
Attacks against Routing failure test

• 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.
• 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
Neighbor set anycast

• 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 neighbors to x

25
Performance of redundant routing100,000 nodes,
b4, lr32
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.