I2P Transit Traffic: The Lifeblood of the Network and a Key to Anonymity

I2P is one of the leading players among anonymous networks, alongside projects like ZeroNet, FreeNet, and others. According to the author’s subjective assessment, I2P is the second largest project after TOR. The “Invisible Internet Project” (I2P) boasts complete independence from legal and governmental entities, steady and long-term development, and top-notch cryptography implemented professionally in production languages like C++ and Java (as opposed to student projects on slow interpreted languages).

It’s important to note that the development of the two main I2P clients (one in C++ and one in Java) is carried out by different, essentially independent groups. This doesn’t prevent them from coordinating and implementing protocol updates. The development process is decentralized and discussions are transparent, which builds trust in the final product (see IRC chat logs: C++ team, Java team, and general chat for scheduled discussions).

If you’re interested in anti-censorship technologies and have the enthusiasm to learn something new, you’ll likely appreciate the spirit of I2P.

How I2P Works: The Role of Transit Traffic

I2P is a peer-to-peer network that operates as an additional encrypted transport layer on top of the regular internet (see also I2P over Yggdrasil Network). Unlike traditional networks, the path of traffic in I2P is unpredictable—on average, data passes through six random transit nodes, which are other I2P participants, before reaching its destination.

Unlike TOR, where the communication channel is bidirectional, I2P uses unidirectional tunnels. For example, packets to a server might pass through random nodes in Russia, Kazakhstan, and Europe, while the server’s response to the user might go through the USA, Canada, and Japan. Every ten minutes, all encrypted tunnels are rebuilt with new logical paths and cryptographic keys. At first, this can be hard to imagine: the user doesn’t know the physical location of the server they’re accessing, and the server knows nothing about the user, thanks to transit nodes that themselves have no way of knowing whom they’re serving. For more on tunnels, see a dedicated article.

Transit nodes in I2P are not trusted servers run by global organizations or institutions, but mainly the nodes of regular network participants. All I2P users can be transit nodes by default. If this is news to you, don’t worry: I2P’s architecture doesn’t involve exit proxies to the regular internet, so no one can use your IP address to visit questionable sites or “like” something. Within I2P, the IP addresses of participants are essentially meaningless, as they’re just addresses of ten-minute transit links that don’t know who or what is passing through them.

By default, the I2P router (the application for accessing the hidden network) sets a very low threshold for transit bandwidth—just 32KB/sec. This is to prevent users with limited data plans from running out of bandwidth after a few days of I2P use. To increase the transit bandwidth in i2pd (the C++ client), set bandwidth = X in the configuration file (where X means unlimited bandwidth).

Why Should You Provide Transit Bandwidth?

Why should you increase your transit bandwidth and provide your channel for unknown users? Why give your resources to the network? This is the main question of the article—and it’s not just about altruism!

The Issue

We’re used to running an app only when we need its functionality—like opening an online store to make a purchase. Simple enough.

But when it comes to anonymity and hidden networks, the first thing that comes to mind is a timing attack. In a timing attack, an observer uses special tools to monitor traffic in a geographic region and tracks a person’s activity in the hidden network, trying to match it to a real individual. According to some experts, identifying a specific TOR user with this method can require fewer than five time points. This is possible because only a limited number of people use TOR in a given city, region, or country. The main suspect is the one who is connected to TOR during all control measurements at the time of a post on an anonymous forum or chat. Note: a timing attack does not involve decrypting the protected connection. Its effectiveness relies on the observer’s persistence and attention.

Deep Packet Inspection (DPI) is widely used in internet control systems (for example, SORM in Russia). Such technologies can often determine which protocol or application the traffic belongs to, and thus what the user is likely doing or interested in.

Using a VPN is not very effective against timing attacks in hidden networks, since an observer can track not only TOR-specific traffic but also correlate it with any other anonymous data streams.

All serious projects focused on anonymity and censorship resistance have tools to evade DPI and protocol blocking. I2P is no exception. To use I2P’s full power, you don’t need extra plugins (unlike TOR). Everything works out of the box—just keep your I2P router updated to stay current with the latest technologies.

Let’s not get bogged down in technical details or rhetoric. Ultimately, no matter how much a user tries to hide, if their traffic doesn’t look like they’re just browsing state news portals, they’ll become a suspect at the first sign of “unusual” activity.

Why Transit Matters for Users

Timing attacks generally rely on the observer’s ability to monitor a user’s activity. For example, when you watch streaming video, your provider sees a large data flow. If your plan has a data cap, every byte you receive is counted. This clearly demonstrates how transparent user activity is to the ISP. When you’re asleep, the provider sees a lull.

Suppose a user hosts a personal website on their computer and makes it accessible via a hidden network. If someone wants to find out who owns the resource, they’re unlikely to try to break the complex transport protocol. Instead, they’ll use social engineering or timing attacks.

Simplified, a timing attack might work like this: thousands of requests are sent to the hidden site at once, and the observer watches for a spike in activity somewhere on the regular internet—where all those requests land. It’s a big task, but “the uncatchable Joe” is only uncatchable until someone wants to catch him.

If the site has no visitors and the server’s internet channel is almost idle, and then suddenly an observer sends a flood of requests (a basic DDoS attack), all the requests pass through the hidden network’s tunnels and the server’s real network channel experiences a noticeable load spike.

If the target server is physically located in a controlled segment of the internet (for example, in a country where law enforcement is conducting an operation), just a few such coincidences at different times of day can reveal the true location of the hidden site.

The same principle applies to regular users: virtual activity is matched to real spikes in user activity. In practice, it’s more complicated, but those details are beyond the scope of this article.

Now imagine that the server’s or user’s internet channel activity is unrelated to their actual activity. This is possible if the network channel is always under load. In that case, outside observation is useless, since real activity is just noise in the constant stream of transit traffic. It’s like background noise: if loud music is playing at home, you can shout all you want, but your neighbors will only complain about the music, not your shouting.

The screenshot below shows the difference between Sent and Transit in the i2pd web console: out of 9TiB of outgoing packets, the server sent only about 6GiB of its own real data to users.

The fact that these 6 GiB can’t be separated from the entire encrypted stream by an outside observer is a clear illustration of how high transit traffic protects against timing attacks.

With a large number of transit tunnels, the I2P router builds its own tunnels using routers that also participate in other users’ transit tunnels. Mixing your data with others’ tunnels turns I2P router connections into an unsolvable tangle of encrypted labyrinths, impossible to analyze from the outside.

How to Get More Transit Traffic

First, check your I2P router settings as discussed earlier.

I2P routers connect directly to each other. To receive a lot of transit traffic, your node should be easily accessible. In other words, you need a dedicated IP address to accept external connections. However, even for a home PC or smartphone with a “gray” (NAT) IP, the small amount of transit you do get still helps add noise for outside observers. Even without a dedicated IP, I2P routers can still establish direct contact (see more here).

Each I2P router has a profiling function that helps select reliable nodes as transit points—the more stable your node’s uptime, the more likely it is to be chosen for tunnels by others.

If you need to shut down your “well-established” server or PC for a long time, you’ll cause many failed connection attempts from other users, and your status as a reliable node will gradually drop. When you restart, your transit traffic will decrease significantly. In i2pd, profiling data is considered current for three days (about the same in the Java version), after which the I2P router is ready to re-evaluate a previously unreliable router and, if it’s improved, mark it as reliable. Alternatively, you can quickly start “fresh” by deleting the router identifier file (router.info) and restarting the I2P router. In Debian, this file is usually in /var/lib/i2pd/.

Open the Floodgates

The more nodes in I2P, the more distributed and resilient the network is to analysis. The more traffic on each node, the more anonymous the entire network becomes. By enabling transit for your own purposes, you help everyone. By helping everyone, you ensure your own anonymity.

If you have not only unlimited internet but also disk space, you can “make noise” with double benefit: check out the article on torrents in I2P.

Author: pureacetone