Anonymous Peer to Peer Routing Protocol

Author: Rupert Scammell (
Date: January 3, 2001
Version: 1.00

I. Introduction

The Anonymous Peer to Peer Routing Protocol, which is referred to from here on in as simply "the protocol", is a packet routing system that takes inspiration from peer to peer file sharing systems like Napster and Gnutella.

In a typical configuration, the client makes a request for a network resource (i.e. another system on the network), which is either directly accessed (if the machine is on the same network), or routed through a gateway, if the machine lies on an external network. In either case, the machine making the connection can be identified by the host with very little difficulty, since the IP of the client is contained within TCP packets received by the host.

The protocol permits clients (which consist of systems accessing network resources) to effectively hide their own IP information from the resources they are accessing (e.g. web sites), by performing encrypted routing between a chain of anywhere from 1 to n different routing machines (gateways), the last of which actually accesses the desired resource, and passes the information requested back through the routing path to the client.

Machines participating in the network may act as pure clients, pure gateways, or operate in a mixed-mode configuration that permits both connections to upstream gateways, while accepting connections from downstream clients.

II. Client Overview

The client used in the peer to peer routing network has several significant components. In order to use the client, it must first be provided with at least one IP address for a gateway system capable of routing using the protocol, along with a port, or range of ports to which connections are permitted on the system.

In order to discover potential routes outside of those initially specified at startup, gateway systems are encouraged to share IP addresses of upstream gateways that it knows of, in order to promote load balancing and route diversity throughout the routing network. However, at the same time, it is perfectly permissible for routing gateways to reject the discovery request by the client, permitting any upstream links in the chain to remain anonymous.

Using a simple case as an example, assume Client A enters the routing network with two starting IP addresses for gateway systems, and Client A sends discovery requests to these systems, asking for upstream gateways that they know about. returns a list of 7 IP addresses for upstream routing gateways, and returns a list of 5 IP addresses for its routing gateways. At the conclusion of the query, Client A now knows of 14 potential routing paths for data. The query process can of course continue ad infinitum, with the client using the returned IPs as a source for subsequent discovery queries, but for purposes of demonstration, 14 known gateways is ample.

In order to route data through the network, Client A maintains a pool of ports which can potentially be connected to listening ports on upstream gateway systems that it has discovered.

Looking at a typical usage scenario, assume that Client A wishes to make an HTTP connection to, and at the same time download the latest Metallica album from In order to do this, the client randomly selects a routing gateway for the HTTP connection to, then selects another gateway to be used for the FTP connection to The client then performs key negotiation with each of the gateways selected, and builds an encrypted tunnel between the gateway and the client system.

Packets generated by the HTTP and FTP clients are intercepted by the routing client running on the machine, and encapsulated into packets that have the IP of the appropriate gateway as a destination IP. These packets are then sent to the gateway system using the encrypted tunnel that was previously established. Information is requested by the client is returned by the upstream gateway via the same tunnel.

III. Routing Gateway Overview

The routing gateway listens on a range of ports for client connections. After key negotiation is performed with the client, the gateway establishes an encrypted tunnel between itself and the client, which is used for the duration of the session. The routing gateway recieves packets from the tunnel which contain the actual destination IP that the client has requested for the data, along with the actual data being sent, and uses the same tunnel to send data back along the routing chain to the client.

The routing gateway extracts the encapsulated packet from the received packet, and can now do one of two things with it. If the particular routing gateway is the last link in the routing chain, it forwards the data received to the original destination IP specified by the client, then sends the response to the upstream system, which may either be the client itself, or another routing gateway acting as a client. If the routing gateway to which the data has been forwarded is acting as a client, and connecting to other routing gateways itself, then the packet received may (at the option of the routing gateway) be extracted and re-encapsulated into another packet that has a new destination IP in the header, for the next downstream routing gateway.

IV. Security Considerations

As with any system, the potential exists for abuse of the network, both by clients and routing gateways. The anonymous, untraceable nature of the network means that it would be particularly effective at cloaking the source of email and net news spam, and additionally could provide a springboard for single and distributed denial of service attacks. Other questions to consider include:

VI. Provisions

In order to tailor the configuration for particular networks and system configurations, both the server and client would ideally be able to have fairly extensive control over connection parameters, without the need to recompile either of the daemons. A possible configuration could consist of:
When the protocol is implemented, these factors should be considered: