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 

Before the guided tour puzzle can start,  tour guides has to be set up in the system, where . Meanwhile, the server establishes a shared secret  with each tour guide  using a secure channel, where . The server keeps a short-lived secret  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 , which is used to control the difficulty of a guided tour puzzle. The figure shows an example of a guided tour when  and .

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

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

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

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

where, . When contacted by a client , a tour guide  computes a hash value  () using the formula:

where,  means the -th stop of the client's tour,  is the shared key between the tour guide  and the server. After client  receives the server's reply message, it starts a guided tour by computing the index  of the first tour guide using formula for . The client then sends a set of values (, , ) to the tour guide , where the second value denotes which stop of a tour the client is currently at. As a response, the client receives a hash value  from the tour guide , where  is computed using the formula for . The client  repeats this process  more times and contacts the tour guides . The reply message from the last-stop tour guide  contains the last hash value , and the client  sends () to the server as the puzzle answer.

 Puzzle verification: when the server receives a request from client  with a puzzle answer (, ) attached, it first checks to see if  is equal to the  it computed using the formula for . If so, the server computes  by repeatedly using the formula for , and verifies that  is equal to . If both hash values are valid, the server allocates resources to process the client's request. Since the server knows the shared keys , it can compute the chain of hashes  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

References

External links 
Program of Annual Computer Security Applications Conference 2009

Computer network security