Secure Routing for Structured PeertoPeer Overlay Networks

1
Secure Routing for Structured Peer-to-Peer
Overlay Networks

• M. Castro, P. Druschel, A. Ganesh, A. Rowstron
  and D. S. Wallach
• Proc. Of the 5th Usenix Symposium on Operating
  Systems Design and Implementation, Boston, MA,
  Dec. 2002

Sai Rama Krishna Kona Bhavik Mehta
2
Outline

• Background of P2P overlay networks
• Routing Overlay model
• System model
• Secure routing
• Secure nodeId assignment
• Secure Routing table maintenance
• Secure message forwarding
• Conclusion

3
Structured P2P Overlays

• Provide a powerful platform for decentralized
  services network storage, content distribution,
  and application-level multicast.
• Examples CAN, Chord, Pastry and Tapestry

4
Routing overlay model

• An abstract model of a structured p2p routing
  overlay
• nodeIds, uniform random identifiers from a large
  id space
• keys, unique identifiers selected from the id
  space used for assigning nodeIds
• key is mapped to a unique live node, called root
• routing table, maintained by each node
• neighbor set, a random sample
• replica function, maps a key to replica keys.

5
Pastry Node State

• NodeIds, Keys sequence of digits in base 2b
• A nodes routing table has 128/2b rows and 2b
  columns.
• Each node maintains a neighbor set (leaf set)
• Includes a set of l nodes with nodeIds that are
  numerically closest to the present nodes nodeId
• l/2 larger and l/2 smaller nodeIds than the
  current nodes id
• l is constant for all nodes
• A typical value is 8log2bN
• Ensures reliable message delivery
• Used to store replicas

Routing table of a Pastry node with nodeId 65a1x,
b4. Digits are in base 16, x represents an
arbitrary suffix
6
Message routing in Pastry
Routing a message from node 65a1fc with key
d46a1c. The dots depict live nodes in Pastrys
circular namespace.
7
Tapestry, Chord, CAN

• Tapestry
• Neighboring nodes are not aware of each other
• Uses Surrogate routing
• Log2N, expected number of routing hops
• Chord
• Forwards messages only in clockwise direction
• (1/2)Log2N, expected number of routing hops
• CAN
• Routes messages in d-dimensional space
• Routing table, O(d) entries, does not grow with
  n/w size
• (d/4)(N1/d), routing hops on average
• CAN Chord Proximity routing is harder but
  protects from certain attacks

8
System model

• Assumptions
• N size of the overlay network
• f 0lt f lt 1, fraction of faulty nodes
• Constrained-collusion Byzantine failure model for
  faults
• c 1/N lt c lt f most damage case cf
• Each node has a static IP address
• Network level Overlay level
• A message is delivered within time D with
  probability PD (with no faulty nodes)

9
Secure Routing

• Routing primitives implemented by Pastry etc.,
  not suitable for developing secure applications
• Secure routing primitive ensures that when a
  non-faulty node sends a message to a key k, the
  message reaches all non-faulty members in the set
  of replica roots Rk with very high probability.
• Implementation requires
• Securely assigning nodeIds to nodes
• Securely maintaining the routing tables
• Securely forwarding messages

10
Secure nodeId assignment

• Goal
• ensure that uniform random distribution of
  nodeIds cannot be controlled by an attacker
• Attacks
• By carefully choosing nodeIds, attack a victim
  nodes routing table
• Control access to target objects by choosing
  closest nodeIds to all replica keys.
• Obtain a large number of legitimate nodeIds,
  Sybil attack
• Solution
• Centralized - Certified nodeId
• A set of trusted certification authorities (CAs)
  to assign nodeIds and to sign nodeId
  certificates.
• The nodeId certificate binds a random nodeId to
  the public key and IP address
• Nodes with valid certificates can join the
  overlay network
• CAs are not involved in the overlay network

11
Secure nodeId assignment (contd)

• Measures to counter Sybil attacks
• Charge a fee
• Identity-based CA
• Decentralized
• Require prospective node to solve crypto puzzle
  to gain a nodeId.
• The cost to solving a crypto puzzle must be
  acceptable to legitimate node but hard enough to
  slow down attackers
• Simple approach using crypto puzzle
• Each node generates a key pair public key and
  private key
• SHA-1(I, K) has the first p bits zero
• Iinitialization vector or MD5
• K public key
• The expected number of operations required to
  generate such a key pair is 2p.
• NodeId SHA-1(I, K)
• Periodically invalidate nodeIds

12
Secure routing table maintenance

• Goal
• Ensure that the fraction of faulty nodes that
  appears in the routing tables of correct nodes
  does not exceed f. (Damage Control, anyone??)
• Attacks
• Attackers fake proximity to increase the fraction
  of bad routing table entries
• A correct node p sends a probe to estimate delay
  to a faulty node.
• An attacker intercepts the probe and have the
  faulty node closest to p reply to the probe.

13
Good Old Honest Routing
Closest Node
Source Node
14
Honesty is not always the best policy !!
Closest Node
Source Node
15
Secure Routing Table-Attacks

• Point to faulty or non existent nodes
• Lie about next hop
• Supply incorrect routing updates while nodes join
  the overlay network.
• Causes fraction of bad routing table
  increase. Probability that a routing table entry
  is faulty after an update is (1-f)f f1 2f
  f2 gt f ( remember f lt1 )

16
Secure routing table maintenance

• Solutions constrained routing table
• One routing table that maintains network
  proximity information for efficient routing (as
  in Pastry and Tapestry)
• The other routing table constraints routing
  entries as in Chord needs to be the closest node
  id at some point in ID space bringing probability
  down to f.
• Normal operation the 1st table is used for
  efficiency purposes. If routing fails use the 2nd
  table

17
Secure Routing tables

• Use two routing tables PastryChord
• First normal locality-aware Pastry routing table
  Slot(l,d) share first l digits, has value d in
  l1 digit
• Second Constrained Pastry routing table
  Slot(l,d) closest nodeId to a point p
• p share first l digits, has value d in l1
  digit, and has the same remaining digits as l
• First is efficient, second is for backup

18
Secure routing table maintenance (cont)
64a1x
6501x
Constraint routing table of a Pastry node with
nodeId 65a1x, b4. Digits are in base 16, x
represents an arbitrary suffix
19
Secure routing table initialization

• Bootstrap Nodes
• - Use a diverse set of bootstrap nodes
• - Big enough to ensure one is correct
• Procedure
• Pick a set of bootstrap nodes and ask them to
  route using node id as key
• No-faulty bootstrap node uses secure forwarding
  techniques
• Collects all the proposed neighbor set from each
  of bootstrap nodes, pick the closest as its
  neighbor
• Pick the route entry with minimal delay as the
  locality-aware routing table
• Initialize each entry of constrained routing
  table as the live nodeId closest to the desired
  point p in the id space (secure forwarding)
• Alternative way to initialize constraint routing
  table
• Use secure forwarding to get live nodeId for each
  entry p for ns constraint routing table too
  expensive
• n request its neighbor sets constraint routing
  table
• Side Effect - Neighbours also know about new
  arrival

20
Secure message forwarding(1)

• Goal
• Ensures that at lease one copy of a message sent
  to a key reaches each correct replica root for
  the key with high probability.

• Attacks
• Faulty nodes can drop message
• route message to the wrong place
• Pretend to be the keys root.
• The root node itself may be faulty
• The probably of routing successfully to a correct
  replica node is (1-f)h (h is the average
  routing hops)

b 4
21
Secure message forwarding(2)

• Solution
• Detect faults and redundant routes
• Routes a message to the keys root using
  locality-aware routing table
• Collect the prospective set of replica roots from
  the prospective root node
• Apply failure test to the set of replica roots.
• If the test is negative, accept the prospective
  replica roots as the correct ones.
• Otherwise, message copies are sent over diverse
  routes toward the various replica roots

22
Secure message forwarding(3)

• Routing failure test(Based on the observation
  the average density of nodeIds per unit of
  volume in the id space is greater than the
  average density of faulty nodeIds).
• Input a key x and a set of prospective replica
  roots for the key x rn id0,, idl1
• Output negative or positive
• p calculate the average numerical distance Up
  between consecutive nodesIds in its neighbor set.
• P checks
• All nodeIds in rn have a valid nodeId
  certificate, the closest nodeId to the key is the
  middle one, and the nodeIds satisfy the
  definition of a neighbor set.
• The average numerical distance Urn in rn
  satisfies Urn lt Up ?

Urn average numerical distance between
consecutive nodeIds in rn
Urn lt Up ?
23
Secure message forwarding(4)

• Other attacks
• Collect old nodeId certificates
• Include both nodeIds of nodes it controls and
  nodeId of correct nodes in a prospective root
  neighbor set.
• nodeId suppression attack
• Suppress nodeId close to sender, increase ß(false
  negative)
• Suppress nodeId in root neighbor set , which
  increase a(false positive)

24
Redundant Routing

• While failure test is positive, send message to
  each replica root via multiple routes.
• In Pastry, they send message from the source node
  to all of its neighbors in the p2p overlay.
• Because nodeIds are random, the neighbors should
  represent a random, geographically diverse,
  sampling of the nodes in the p2p overlay. From
  there, each neighbor node forwards the message
  toward the target node. If at least one of the
  neighbors can achieve a successful route, then
  the message is considered successfully delivered.

25
Redundant route

• Neighbor set anycast
• 1) p sends r messages to the destination key x
  with a nonce.
• 2) Any correct node that receives the message and
  has xs root in its neighbor set returns its
  nodeId certificate and the nonce, signed by its
  private key.
• 3) p collects in a set N the l/21 nodeId
  certificates closest to x on the left and l/21
  nodeId certificates closest to x on the right,
  marked pending.
• 4) After timeout or r replies are received, p
  sends a list of nodeIds in N to each node in N.
  and mark as done.
• 5) Any correct node that receives the list
  forwards ps original message to the nodes in its
  neighbor set that are not in the list or returns
  a confirmation if no such nodes exist.
• 6) P receives r confirmation or step 4 was
  executed three times. it computes the set of
  replica roots for x from N.

26
Simulation results
Model and simulation results for the
probability of reaching all correct replica roots
using redundant routing with neighbor set anycast.
27
Secure Routing

• Prevents attacks at join time secure nodeID
  assignment and bootstrapping
• Ensure that when a correct node sends a message
  for a particular key, the message reaches all
  correct replica roots for the key with very high
  probability.
• For data, we need other mechanisms, for example
  self-certifying data

28
Self Certifying Data

• Client can check data and only needs to rely on
  routing when certification check fails.
• Reduces the reliance on the redundant, secure
  routing primitive (you still need secure
  forwarding otherwise there is no data to verify
  in the first place)
• Uses concepts like proactive signature sharing or
  group keys/signatures.
• Self-certifying data can eliminate the overhead
  of secure routing in common cases

29
Related Work

• Dinglidiene and Doucers work addresses spoofing
  attacks. Goal is to prevent malicious nodes using
  reputation or micro-cash.
• Bellovin works with Gnutella and Napster
• Sit and Morris discuss security attack, Cover
  various node lookups, routing table maintenance,
  network partitioning, Denial of Service Attacks,
  file storage etc

30
Summary
31
Conclusion

• Presented the design and analysis of techniques
  for secure node joining, routing table
  maintenance and message forwarding in p2p overlay
• Based on modeling and corroborated with
  simulations, they have measured that this
  operation can be successful with a 99.9
  probability, as long as flt 30.

32
Questions ?
33
Since nodeIds are assumed to be uniformly
distributed, the routing failure test is based on
the observation that if faulty nodes try to
suppress the existance of some correct nodes, the
density of nodeIds in the id space would be much
lower than the average. The test works by
comparing the density of nodeIds in the neighbor
set of the sender with the density of nodeIds
close to the replica roots of the destination
key. If the density is suspiciously low, the
secure routing is repeated with a different set
of routes. Specically, let the nodeId density
around the responding node be d and the local
nodeId density be a. We accept the responding
node only if dlt ag , where g is a parameter
chosen for minimizing false positives and false
negatives.