It is inarguable that the internet greatly undermines user privacy, and the risks are growing each day. This has fueled the development of several anonymity networks, such as Tor and the invisible Internet project (I2P). While the Tor network is currently the most commonly used solution for promoting anonymity and protecting a user’s privacy online, the low capabilities of I2P seem to hinder mass adoption of this anonymity network. A recently published research study attempted to improve the resistance of I2P networks to de-anonymization attacks by adding outproxy functionalities to all nodes on the network. Throughout this article, we will delve into the proposed improvement to the design of I2P networks, presented in that paper.
Proposed network design:
The below figure illustrates the proposed modification for I2P networks:
Figure (1) I2P enhancement via the use of public tunnels
Every node starts an inbound and an outbound tunnel, in addition to a public Internet tunnel which is only inbound, in the same way as the other inbound and outbound tunnels are defined and implemented. It then publishes a LeaseSet with the information about this public Internet tunnel to the netDB.
Moreover, when proxy policies are defined for an outproxy (requirement 9), these policies must be specified in the LeaseSet, and LeaseSet has to be searchable for these policies. For instance, when a user sends an anonymous email, they will need an outproxy to relay mails. Consequently, they need to search for an outproxy which will allow SMTP traffic on port 25.
A limitation on the possible outproxy policies is needed, to prevent a large number of different policies. There is also a problem that a user might want to use several different online applications, while connecting to the public Internet.
There are two basic different solutions for this:
∙ The I2P node asks for each different application a dedicated public Internet tunnel, and routes the network traffic for each application to the corresponding public Internet tunnel.
∙ The I2P node queries the netDB for a LeaseSet which includes all the necessary policies for the applications the user needs to use.
The first solution will need an extra capability included in the I2P software, to route all the network traffic to the right tunnel. The second solution is easier for the I2P node to accomplish, but might lead to a very limited group of outproxy routers that fulfill the required policies. This could in turn lead to a very limited subgroup of outproxies which are actually used. Due to the complexity of the first solution, each I2P node will most probably need to select an outproxy that satisfies all requested policies. With a careful definition of the policies, the number of outproxy routers that fulfill a policy will be high enough. This means that the way the netDB responds to queries has to be modified.
In the current situation, the netDB is queried for a LeaseSet, based on a unique ID of the destination. Querying the netDB on a totally different attribute (e.g. a public Internet policy) is not logic. The research study suggested that via a predefined algorithm; the required policies are calculated into an ID. This ID will then be used by the I2P node to query the netDB. This ID is not unique, it serves only as a search key to search for a LeaseSet for a router that supports the requested public Internet policies. The LeaseSet for a public Internet outproxy must be treated equal to the LeaseSet’s from internal I2P services, the I2P node itself is responsible for querying the netDB for a new LeaseSet after expiration of the old one.
How can users connect to the internet via the proposed design?
When Bob wants to anonymously access the public Internet, he asks the netDB for the endpoint of any public Internet tunnel, based on the required policy. The netDB must respond with one or more LeaseSet from routers that support the requested outproxy policy. The given LeaseSet must be randomly chosen from the available LeaseSets on the floodfill router. After a suitable LeaseSet has been received by the I2P node, communication to the internet can start.
The following steps represent how Bob can communicate to the internet using the proposed design. These steps are also illustrated in Figure (1).
1- Bob sends a message to his outbound tunnel.
2- That message is sent from the endpoint of his outbound tunnel to the entry point of the public Internet tunnel, via the information received from the netDB.
3- The I2P node whose Internet tunnel has been utilized, receives the message.
4- That I2P node will send the request to the public Internet. The message sent by Bob also includes the entry point of his own inbound tunnel.
5- The I2P node receives an answer from the Public Internet.
6- The I2P node then routes this message to its own outbound tunnel.
7- The message is then routed to Bob’s inbound tunnel.
8- The message is received by Bob’s computer. So, Bob’s access to the Internet was anonymous.
Possible enhancements to the proposed network design:
The proposed network design can enhanced by three extra possibilities:
∙ To minimize the risk on eavesdropping the public Internet connection, the new design can be developed in such a way that always several public Internet tunnels are used during an Internet session where some kind of round-robin selection decides which tunnel is used for any network session.
∙ The second option is to minimize the risk for the user of being accused of being part of illegal organizations, if any illegal activities were performed through their outproxy. This risk can be mitigated by only routing encrypted traffic to the public Internet. This must then be specified in the LeaseSet for the outproxy.
∙ The third enhancement is to make the outproxy functionality optional; this meets requirement 6. This is necessary to protect users in repressive regime countries where it might be dangerous to relay the “wrong kind of traffic”. This introduces the possibility of freeriding, people switching off their outproxy and thus minimizing outsourcing their resources to the network, but consuming other users’ resources for their own benefit.
The proposed I2P design can render the I2P network more resistant to de-anonymization attacks and network unavailability. However, with the new design, if I2P attracts a greater number of users, this will render the proposed design even better with greater resistance against de-anonymization attacks. Moreover, the distributed design of the I2P network minimizes the possibility of some party controlling a large proportion of the network, or in other words, “owning the network”. On other hand, the outproxy design renders the network more resistant to Sybil attacks.