Algorithms based on the circulation of a unique token are often indicated in the coordination of distributed systems. We introduce the design of the token passing operation at application level, that exhibits the requirements of security, since the token is a sensitive resource, and scalability, since the token passing protocol must not implement security at expense of scalability. These characteristics make our solution suitable for large scale distributed infrastructures.

1. Secure token passing
at application level
http://dx.doi.org/10.1016/j.future.2009.12.003
Augusto Ciuffoletti
University of Pisa
Pisa – ITALY
augusto@di.unipi.it

2. What this paper is not about
● Many algorithms rely on a reliable token exchange
(mutual exclusion, network overlay, etc)
● Few of them describe a protocol that effectively
implements such operation
● None of them discusses an application level
protocol
● Here we will not discuss an algorithm based on
token exchange, but the token exchange itself
● Being implemented at the application level, it can
be embedded in any sort of application

3. Basics of a token
● Token presence reflects in the state of the
application
● Persistence of several tokens is to be avoided
● Long periods of absence of token are to be
avoided
● The token circulates fairly in the system
● A token is never forged, or spoofed (by
unauthorized entities)

4. A token passing protocol
● The presence of a token on a host must induce,
after some time
– the release of the token inside the host holding it, and
– the presence of the token inside another host
● We consider that this operation (the token passing
operation) is implemented with a protocol based
on UDP datagrams
● In order to effectively implement the token
passing operation, the protocol must fulfill some
requirements...

5. Protocol requirements
● Token passing latency is concentrated around a
value: this ensures fairness
● Token passing failure with token loss is an
infrequent event: this event deteriorates the
performance of the system
● Token duplication is deterministically excluded: it
would be extremely difficult to detect and recover
from this event
● The presence of several (distinct) tokens in the
system is an infrequent event: it deteriorates the
performance of the system

6. Protocol requirements
● The source of the token must be authenticated: this
ensures that only trusted peers participate in token
sharing
The above requirement entails the maintenance of a
trust relationship among participants.
It is the kind of problem that may be solved using a
token based scheme, and is related with the topology
used to circulate the token.
Here we propose a “vanilla” solution...

7. Token circulation topology
● We introduce a full mesh topology (all-to-all) and
a randomized circulation of the token
● As a consequence, the membership consists of all
hosts sharing the token
● Such membership relies on the existence of a
Certification Authority
● All datagrams in the protocol are signed, and
exceptionally contain the certificate
● Hosts maintain a cache of certificates, and public
keys of the peers

8. Host architecture
Token
enters
here
Receiver Sender
Port 9000 Process Unix pipe process
Token
exits
here
Local
read/update Cache read

9. 4-way token exchange protocol
● Types of packets:
– Move pkt: submits token exchange
– Acknowledge pkt: accepts packet exchange
– Commit pkt: confirms token exchange
– EarlyStop pkt: stops resending Commit
pkts
● All types except EarlyStop can be resent
● Non conformant packets are silently
dropped
● All packets are signed
● Resent packets carry sender certificate

10. Sender process state diagram
Transition notation:
● event (rcv or timeout)
● -------
● action (send etc.)
Transition arrow:
● blue: high probability
● yellow: low probability
● red: failure
Transition label:
● green: send event

11. Receiver process state diagram
Transition notation:
● event (rcv or timeout)
● -------
● action (send etc.)
Transition arrow:
● blue: high probability
● yellow: low probability
● red: failure
Transition label:
● green: send event

12. Is it real?
● In order to assess the consistency of our
specification, we implemented the specification
using the Perl language
● It is about 700 lines of Perl code
● Exchanged packets are about 50 bytes long, 4 per
token passing operation
● The security issues are partially implemented in
the prototype: we use public keys instead of
certificates issued by a cert. authority.

13. Does it work?
● In order to assess the conformace of the prototype with
respect to the requirements we run two experiments
● The first experiment was run in the real Internet, using
a testbed of three hosts located in Italy and Greece
● The purpose was to establish the robustness against
Internet failures
● The token kept bouncing among the hosts for as long
as 20 days (one bounce every 5 secs) before being lost
● More details reported in paper...

14. Does it work?
● Another experiment was run in a virtual network
composed of 10 virtual hosts (using Netkit
support)
● In that case, we injected token loss events and
induced randomized delays
● Also in this case the results were satisfactory.
They are not published in this issue.

15. Conclusions
● A communication protocol that ensures a reliable
token passing operation is a basic building block
● An authentication mechanism is required in order
to protect from disruptive intrusions
These results have been published in the Future
Generation Computer Systems journal.
The Perl implementation of the protocol is available
at the Wandering Token home page.

16. Useful links
● Augusto Ciuffoletti. Secure token passing at
application level. Future Generation Computer
Systems, 2010. doi:10.1016/j.future.2009.12.003.
● Wandering token home page:
http://www.di.unipi.it/~augusto/WanderingToken/index.html