Guided tour puzzle protocol

The protocol steps of the guided tour puzzle protocol is similar to that of client puzzle protocol. All clients are required to complete a guided tour puzzle prior to receiving service from the server, if the server suspects it is currently under denial of service attack or its load exceeds a pre-defined threshold. Simply put, a guided tour puzzle is a tour that needs to be completed by taking multiple round-trips to a set of special nodes, called tour guides, in a sequential order. It is called a guided tour, because the order in which the tour guides are visited is unknown to the client, and each tour guide has to direct the client towards the next tour guide for the client to complete the tour in correct order. A single tour guide may appear multiple times in a tour, so the term stop is used to denote a single appearance of a tour guide in a tour. A client knows which tour guide is at the next stop, only after completing its visit to the current stop.

Solving a guided tour puzzle is essentially equal to completing a guided tour in the correct order. Starting from the first stop, the client contacts each stop and receives a reply. Each reply contains a unique token. The token in the reply message from the current stop is used for computing the address of the next stop tour guide. The address of the first stop tour guide is computed using the token contained in the server's first reply message that informs the client of the start of a puzzle process.

The client must send the token received from the current stop tour guide to the next stop tour guide, which will use it as an input to its token calculation function. The token received from the last stop tour guide plus the token from the server's puzzle message are sent to the server as the proof of completion of a tour. The server can efficiently validate these two tokens, and grants service to the client only after proving their validity.

Example of a guided tour puzzle when the number of tour guides is 2, and the tour length is 5. The order of the tour is: G1 -> G0 -> G1 -> G1 -> G0.

Before the guided tour puzzle can start, ${\displaystyle N}$ tour guides has to be set up in the system, where ${\displaystyle N\geq 2}$. Meanwhile, the server establishes a shared secret ${\displaystyle k_{js}}$ with each tour guide ${\displaystyle G_{j}}$ using a secure channel, where ${\displaystyle 0\leq j<N}$. The server keeps a short-lived secret ${\displaystyle K_{s}}$ for computing the first hash value that is returned to the client as part of a puzzle message. A puzzle message also contains the length of the tour ${\displaystyle L}$, which is used to control the difficulty of a guided tour puzzle. The figure shows an example of a guided tour when ${\displaystyle N=2}$ and ${\displaystyle L=5}$.

The details of the each protocol step of the guided tour puzzle protocol is explained in the following.[1]

• Service request: A client ${\displaystyle x}$ sends a service request to the server. If the server load is normal, the client's request is serviced as usual; if the server is overloaded, then it proceeds to the initial puzzle generation step.
• Initial puzzle generation: the server replies to the client ${\displaystyle x}$ with a puzzle message that informs the client to complete a guided tour. The puzzle message contains the length of the tour ${\displaystyle L}$ and a hash value ${\displaystyle h_{0}}$. The server computes ${\displaystyle h_{0}}$ using the following formula:

${\displaystyle h_{0}=hash(A_{x}\;||\;L\;||\;ts\;||\;K_{s})}$

where, ${\displaystyle ||}$ means concatenation, ${\displaystyle A_{x}}$ is the address (or any unique value) of the client ${\displaystyle x}$, ${\displaystyle ts}$ is a coarse timestamp, and ${\displaystyle hash}$ is a cryptographic hash function such as SHA-1.

• Puzzle solving: A client computes the index of the tour guide at the ${\displaystyle l}$-th stop of its tour using the following formula:

${\displaystyle S_{l}=(h_{l-1}\;mod\;N)}$

where, ${\displaystyle 0<l\leq L}$. When contacted by a client ${\displaystyle x}$, a tour guide ${\displaystyle G_{j}}$ computes a hash value ${\displaystyle h_{l}}$ (${\displaystyle 0<l\leq L}$) using the formula:

${\displaystyle h_{l}=hash(h_{l-1}\;||\;l\;||\;L\;||\;A_{x}\;||\;ts\;||\;k_{js})}$

where, ${\displaystyle l}$ means the ${\displaystyle l}$-th stop of the client's tour, ${\displaystyle k_{js}}$ is the shared key between the tour guide ${\displaystyle G_{j}}$ and the server. After client ${\displaystyle x}$ receives the server's reply message, it starts a guided tour by computing the index ${\displaystyle S_{1}}$ of the first tour guide using formula for ${\displaystyle S_{l}}$. The client then sends a set of values (${\displaystyle h_{0}}$, ${\displaystyle 1}$, ${\displaystyle L}$) to the tour guide ${\displaystyle G_{S_{1}}}$, where the second value denotes which stop of a tour the client is currently at. As a response, the client receives a hash value ${\displaystyle h_{1}}$ from the tour guide ${\displaystyle G_{S_{1}}}$, where ${\displaystyle h_{1}}$ is computed using the formula for ${\displaystyle h_{l}}$. The client ${\displaystyle x}$ repeats this process ${\displaystyle L-1}$ more times and contacts the tour guides ${\displaystyle G_{S_{2}},G_{S_{3}},...,G_{S_{L}}}$. The reply message from the last-stop tour guide ${\displaystyle G_{S_{L}}}$ contains the last hash value ${\displaystyle h_{L}}$, and the client ${\displaystyle x}$ sends (${\displaystyle h_{0},\;h_{L}}$) to the server as the puzzle answer.

• Puzzle verification: when the server receives a request from client ${\displaystyle x}$ with a puzzle answer (${\displaystyle h'_{0}}$, ${\displaystyle h'_{L}}$) attached, it first checks to see if ${\displaystyle h'_{0}}$ is equal to the ${\displaystyle h_{0}}$ it computed using the formula for ${\displaystyle h_{0}}$. If so, the server computes ${\displaystyle h_{L}}$ by repeatedly using the formula for ${\displaystyle h_{l}}$, and verifies that ${\displaystyle h'_{L}}$ is equal to ${\displaystyle h_{L}}$. If both hash values are valid, the server allocates resources to process the client's request. Since the server knows the shared keys ${\displaystyle k_{1s},k_{2s},\dots ,k_{Ns}}$, it can compute the chain of hashes ${\displaystyle h_{1},h_{2},...,h_{L}}$ without contacting any tour guide. A loose time synchronization between the server and tour guides is required in order to compute the same hash value at the server and tour guides.

CPU-bound computational puzzle protocols, such as the Client Puzzle Protocol, can mitigate the effect of denial of service attack, because the more an attacker wants to overwhelm the server, the more puzzles it has to compute, and the more it must use its own computational resources. Clients with strong computational power can solve puzzles at much higher rate than destitute clients, and can undesirably take up most of the server resources.[1][2][3][4]

Another crucial shortcoming of computational puzzle protocols is that all clients, including all legitimate clients, are required to perform such CPU-intensive computations that do not contribute to any meaningful service or application.

Guided tour puzzle protocol enforces delay on the clients through round trip delays, so that clients' requests arrive at a rate that is sustainable by the server. The advantage of using round-trip delays, as opposed to hard computational problems, is that the round trip delay of a small packet is determined mostly by the processing delays, queuing delays, and propagation delays at the intermediate routers, therefore is beyond the control of end hosts (clients). As such, even an attacker with abundant computational resources cannot prioritize themselves over poorly provisioned legitimate clients.

Furthermore, in guided tour puzzle protocol, the computation required for the client is trivial. Since the length of a guided tour is usually a small number in the order of tens or lower, the bandwidth overhead for completing a guided tour is also trivial. As a result, clients are not burdened with heavy computations (that are usually required by CPU-bound or memory-bound puzzle protocols).

• Proof-of-work system
• Client Puzzle Protocol
• CAPTCHA

• Program of Annual Computer Security Applications Conference 2009