Anonymous Peer to Peer Routing Protocol

Author: Rupert Scammell (rupe@sbcglobal.net)
Date: January 3, 2001
Version: 1.00
DRAFT

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, 192.168.0.5 and 192.168.0.6. Client A sends discovery requests to these systems, asking for upstream gateways that they know about. 192.168.0.5 returns a list of 7 IP addresses for upstream routing gateways, and 192.168.0.6 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 http://www.nsa.gov, and at the same time download the latest Metallica album from ftp.warez.fi. In order to do this, the client randomly selects a routing gateway for the HTTP connection to http://www.nsa.gov, then selects another gateway to be used for the FTP connection to ftp.warez.fi. 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:

Should routing gateways have any ability to determine whether a client is in fact the source of the query, or simply another routing gateway forwarding requests on behalf of the original client? Preventing this would stop a malicious routing gateway from being able to definitively say 'Client x.x.x.x made a request for an HTTP connection on y.y.y.y on m/d/yyyy', and knowing that x.x.x.x was the actual source of the requests.
Should some kind of an automated or manually arbited trust metric be put in place in order to make routing decisions? This could be based on several physical factors, including connection speed of the routing gateway, hops to the gateway, etc, and peer ratings regarding the gateway, that would aid in determining the reliability of the path.

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:

An /etc/route-table.conf file, which would consist of known routing gateways upstream from the server or client.
An /etc/routesvr.conf file, which would contain human-readable settings for the peer to peer routing gateway.
An /etc/routeclient.conf file, which would contain human-readable settings for the peer to peer routing client.

When the protocol is implemented, these factors should be considered:

Routing gateway operators would be able to determine the number of ports (and therefore potential active connections) on which the routing gateway server would listen.
Routing gateways would have the potential to reject single IPs or hostmasks in order to minimize troublesome clients.
Servers can opt-out of revealing the contents of their /etc/route-table.conf file when discovery requests are made by clients. This allows routing gateways to preserve the anonymity of their upstream gateways, should they desire to do so.
Routing gateways may impose global, IP based, or port based TTL values for client connections. Some provision for traffic shaping on these bases should also be made.
Client systems may request min or max hop values, indicating the smallest or largest number of distinct routing gateways that they wish their packets to be routed through prior to having their requests routed to the appropriate destination IP. If a particular routing path is chosen that is unable to fulfill this request, then the failure should be passed back down through the routing chain to the client, so another route can be tried.
Routing gateways should have the capability to make use of traceroute information, ping times, and other connection quality information in order to make routing decisions, and potentially use the information as a criteria for acceptance or rejection of client connections.
Some provision for authentication should be made, in order to restrict access to certain private routing gateways to a select group of users. This information would not be logged or linked in any way to connection activity after authentication