6.5 Verifying RA Property for DTR2
6.5.1 The Model in CSP
All the notations, data types, channels and renaming relations used in the DTR2 model are similar to those used in the DTR1 model. The signed messages generated by TTMs are represented by events in the following set:
1. RangeMessages tRan.xxy|x P P 8 P 8 P 8
u. This represents the transfer blobs
exchanged among peers. For example, Ran.xi , l , rymodels the transfer blob created
by i and containing the rangerl, rsttype where ttype is the default token type known
2. CertMessages tCert.xxy|x P Nonces Y pNonces P 8
P 8
qu. This represents
the signed messages from TTM certifying the ranges that it has. For example, Cert.xi , l , ry models the signed message from i asserting that it has the range
rl, rsttype. This type of message is used for verification, whereas RangeMessages
are used during churn events when peers transfer their ranges to each other.
An event on channel join, leave : P8
.P8
signals that a churn event has completed and the system has moved to a new state. This is similar to the completeChurn channel in the DTR1 model.
6.5.1.1 Peer Processes.
Each peer is modeled by a process representing a TTM. Peer i is considered as having joined the network (an event on the join.i channel is performed) once it has received a range rl, isttype. The peer can transfer tokens belonging to its range (or a sub-range) to
other peers. It is considered as having left the network once its entire range has been transferred to its neighbor, and the neighbor has added the range to its own range. At the beginning, there exists a bootstrapping node b that has the entire range of tokens.
TTMN(i) receive.VF.i.SqN.xnvfy Ñsend.i.VF.Cert.xnvfy
Ñunlock.VF.i ÑTTMN(i) l
ü
l,r
receive.r.i.Ran.xr, l, iy Ñjoin.i.r ÑTTM(i,l)
TTM(i,l) receive.VF.i.SqN.xnvfy Ñsend.i.VF.Cert.xnvf, l, iy Ñunlock.VF.i ÑTTM(i,l)
l ü
j,ll
receive.j.i.Ran.xl, ll, lyÑleave.l.i ÑTTM(i,ll)
l ü
j
if mid(j,l,i) then send.i.j.Ran.xi, l, jy ÑTTM(i,j)
else send.i.j.Ran.xi, l, iy ÑTTMN(i)
TTMs ü bPP 8 TTM(b,b) ||| ||| ib T T M Npiq
6.5.1.2 Verifier Process.
VerifierProcess ü
r
send.VF.r.SqN.xnvfy Ñreceive.r?VF.Cert.xnvf, l, ry
Ñif lr then output.l.rÑunlock.VF.r ÑSTOP
else send.VF.l.SqN.xnvfyÑ receive.l.VF?Cert.xnvf, ll, ly
Ñoutput.l.r Ñunlock.VF.l Ñunlock.VF.rÑ STOP
6.5.1.3 Adversary Process.
Notice that the verification process checks only two certificates, therefore the adversary could do no better than relaying only two messages of type CertMessages.
RelayNonce learn.SqN.xnvfyÑ say.SqN.xnvfy ÑRelayNonce
RelayCert learn?Cert.xnvf, l, ryÑsay.Cert.xnvf, l, ryÑ STOP
RelayRange(i,l,r) learn.Ran.xi, l, ryÑ say.Ran.xi, l, ryÑRelayRange(i,l,r)
RelayRanges |||
i,l,r
RelayRange(i,l,r)
Adversary RelayNonce|||RelayCert |||RelayCert |||RelayRanges
6.5.1.4 Putting it together.
The DTR2 model is constructed from the processes above by first renaming their channels in the same way as in the DTR1 model, and then joining them together with parallel operators. More specifically,
Impl Verifier } Ω1 Adversary } Ω2 TTMs
where Ω2 αAdversary X αT T M s and Ω1 αV erif ier X Ω2.
6.5.2
Specification
The specification process models an ideal system that starts with a bootstrapping node and satisfies the NA property.
SpecProcess(ps,pn) ü i,jPP 8 join.i.j ÑSpecProcess(psYtiu, pnztiu) l leave.i.j ÑSpecProcess(psztiu, pnYtiu) Ü iPps output.i.right(i,ps) ÑSpecProcess(ps,pn) Spec ü bPP 8 SpecProcess(tbu,P 8 ztbu)
6.5.3
Verification
To prove that the DTR2 model satisfies the NA property, it is sufficient to show that:
Spec Implzt|take, fake, unlock|u (6.5.1)
6.5.3.1 Automated Verification
An instance of Impl and Spec where |P 8
| 3 is implemented in FDR, the detailed
implementation can be found in Appendix G. FDR returns true for the refinement check in Equation 6.5.1 after evaluating 85,477 states and 245,394 transitions. This automated proof confirms that the NA property is met by the DTR2 model of at least 3 peers.
6.5.3.2 Generalizing the Result
To prove that Equation 6.5.1 holds for P8
of any size, it is necessary to show that tracespImplzt|take, fake, unlock|uq tracespSpecq. The proof is derived from the follow-
ing theorem [31]:
Theorem 6.5.1. Let X, sq be a set and a sequence of events respectively. Let γpX, sqq
be the function defined as follows:
γpX, sqq $ ' ' ' ' ' ' ' & ' ' ' ' ' ' ' % X if sq xy γpXYtiu, tq if sq xjoin.i.jy ^ t for some i, j, t γpXztiu, tq if sq xleave.i.jy ^ t for some i, j, t γpX, tq if sq xxy ^
Then for any trace tr of Implzt|take, fake, unlock|u, the following holds:
s, t, l , r . tr s ^
xoutput.l .ry ^
t ñ tl , ruγptu,sq ^ l leftpr , γptu,sqq
The function γ returns the set of peers in the network after a given trace is executed. In other words, γ returns the state of the system after the evolution represented by the given trace. The theorem states that if output.l .r occurs at a given state, then l is in fact the immediate left neighbor of r in that state. The detailed proof of this theorem is included in Appendix H.
6.6
Related Work and Discussion
This chapter formalizes DTR1 and DTR2 in CSP, and verifies that they satisfy the RA property. The main implication for trust systems implementing DTR1 and DTR2 is that an honest peer can check if other peers have misbehaved in routing transactions, and can accordingly leave feedback for those peers. The work on formalizing and verifying properties of P2P systems in the literature is limited in number. Borgstrom et al. [11] modeled a structured overlay called Distributed K-ary Search (DKS) in CCS. They showed that the routing protocol in DKS, when there is no churn, is correct. Bakhshi et al. [7] modeled Chord in π-calculus and verified that the stabilization protocol is correct.
So far, the definitions of NA and RA property assume that verification and churn are atomic operations occurring one after another. The DTR1 model, for example, represents this by locking the TPM during verification and churn so that one cannot start while another is in progress. It would be interesting to investigate the implication of lifting this assumption. In particular, the verification protocols would be allowed to start while the churn protocols are being executed, which might present new opportunities for the adversary to break the NA property.
relaying messages. It was suggested that the model could be refined by the more compli- cated model that uses infinite number of nonces and whose adversary has infinite memory for remembering and replaying messages. This hypothesis needs to be verified in future work. One may start with the more complex model and use model abstraction techniques such as weakening the adversary and data independence to demonstrate that the model does indeed refine the one presented in this thesis.
Finally, NA and RA are considered as safety properties, because they concern with the attacker not being able to fool the honest peer. While safety properties require that undesirable behavior will not happen, liveness properties require that good behavior will eventually happen. In case of DTR1 and DTR2, the liveness property means that peers will eventually be able to engage in successful and correct routing transactions. In CSP, liveness properties are supported by the stable failure semantics model, as opposed to the trace semantics model that supports safety properties. Examining the liveness property of DTR1, DTR2 in CSP would be an interesting avenue for future work.
CHAPTER 7
EXPERIMENTAL ANALYSIS
This chapter provides further assessments of the proposed mechanisms for detecting mis- behavior at the routing layer (DTR1 and DTR2) presented in Chapter 4 and Chapter 6. More specifically, the high-level performance of DTR1 and DTR2 are evaluated by sim- ulation. A distributed simulation platform, which is called dPeerSim, is used for the large-scale simulation of DTR1 and DTR2 in dynamic network conditions. dPeerSim is a collaborative work involving Michael Lees, Georgios Theodoropoulos and Rob Minson. The simulation results suggest that DTR1 and DTR2 are comparable with respect to their performance, and that the latter is more scalable but is less robust under frequent churn. In both systems, under churn a high number of queries are found to be forwarded to the wrong destination nodes. Section 7.1 explains why simulation, particularly distributed large-scale simulation, is a useful method for evaluating P2P systems. Section 7.2 fol- lows with the design and analysis of the scalability of dPeerSim. Section 7.3 describes the simulation of DTR1 and DTR2 using dPeerSim, and discusses the simulation results. Finally, the related works and discussions are presented in Section 7.4.