Anonymous Peer to Peer Routing Protocol
Author: Rupert Scammell (firstname.lastname@example.org)
Date: January 3, 2001
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
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
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
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:
/etc/route-table.conf file, which would consist of known routing
gateways upstream from the server or client.
/etc/routesvr.conf file, which would contain human-readable
settings for the peer to peer routing gateway.
/etc/routeclient.conf file, which would contain human-readable
settings for the peer to peer routing client.
- Routing gateway operators would be able to determine the number of ports (and
potential active connections) on which the routing gateway server would listen.
- Routing gateways would have the potential to reject single IPs or hostmasks in
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
- Client systems may request min or max hop values, indicating the smallest or
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,
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
- 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