Guided tour puzzle protocol

Guided tour puzzle (GTP) protocol is a cryptographic protocol for mitigating application layer denial of service attacks. It aims to overcome the shortcoming of computation-based puzzle protocols, in which clients are required to compute hard CPU or memory-bound puzzles that favor clients with abundant computational resources. Guided tour puzzle protocol can be seen as a form of proof-of-work (POW) protocol.

Overview

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.

Protocol steps

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, $N$ tour guides has to be set up in the system, where $N\geq 2$. Meanwhile, the server establishes a shared secret $k_{js}$ with each tour guide $G_{j}$ using a secure channel, where $0\leq j<N$. The server keeps a short-lived secret $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 $L$, which is used to control the difficulty of a guided tour puzzle. The figure shows an example of a guided tour when $N=2$ and $L=5$.

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

• Service request: A client $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 $x$ with a puzzle message that informs the client to complete a guided tour. The puzzle message contains the length of the tour $L$ and a hash value $h_{0}$. The server computes $h_{0}$ using the following formula:

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

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

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

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

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

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

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

• Puzzle verification: when the server receives a request from client $x$ with a puzzle answer ($h'_{0}$, $h'_{L}$) attached, it first checks to see if $h'_{0}$ is equal to the $h_{0}$ it computed using the formula for $h_{0}$. If so, the server computes $h_{L}$ by repeatedly using the formula for $h_{l}$, and verifies that $h'_{L}$ is equal to $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 $k_{1s},k_{2s},\dots ,k_{Ns}$, it can compute the chain of hashes $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.

Comparison to other puzzle protocols

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.

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).

See also

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

External links

• Program of Annual Computer Security Applications Conference 2009