I2P Network Explained: Garlic Routing, Tunnels, Eepsites and Comparison with Tor

The Invisible Internet Project, universally known as I2P, is a fully distributed anonymous network layer designed to provide robust privacy guarantees for both communication and application hosting. Unlike Tor, which was primarily designed to enable anonymous access to the regular internet, I2P was built from the ground up as a self-contained darknet -- an anonymous network where services are hosted internally and accessed by participants within the network. While I2P can provide outproxies to the clearnet, its primary strength lies in internal network services called eepsites. Originally launched in 2003 by a developer known as "jrandom," I2P has been continuously developed by a global community of volunteers and has matured into a stable, well-documented platform. This article provides a comprehensive technical examination of the I2P network architecture, its garlic routing protocol, tunnel construction, the floodfill network database, eepsite hosting, and a detailed comparison with the Tor network.

Architectural Overview

I2P is a message-oriented anonymous overlay network that operates on top of the regular internet (IP layer). Every participant in the I2P network runs a router that builds encrypted tunnels to other routers and uses these tunnels to send and receive messages. The fundamental design principle is that all participating nodes contribute to the network by routing traffic for others, creating a packet-switched network where every node is both a client and a relay. This contrasts with Tor's circuit-switched approach where there is a clear distinction between clients and relays.

The I2P network uses a destination-based addressing system. Each service or endpoint is identified by a cryptographic destination -- a data structure containing the endpoint's public encryption key (ElGamal or X25519), public signing key (DSA, EdDSA, or other supported algorithm), and a certificate. The I2P address that users see (a .i2p address or a base32-encoded hash) is derived from this destination. The complete technical documentation is available at geti2p.net/en/docs, which serves as the authoritative reference for the protocol specifications.

Garlic Routing: Beyond Onion Routing

I2P employs a technique called garlic routing, which extends the concept of onion routing with several important modifications. The term "garlic" is used because multiple messages can be bundled together into a single encrypted payload, analogous to the cloves contained within a head of garlic. While onion routing encrypts a single message in layers, garlic routing encrypts multiple messages (called cloves) together, making it more difficult for an adversary to perform traffic analysis based on message counting and timing.

Garlic Cloves and Bundling

Each garlic message contains one or more cloves, where each clove is an individually addressed message with its own delivery instructions. A typical garlic message might contain a clove with the actual data payload destined for the recipient, a clove containing a delivery status message sent back to the sender (through a different path), and additional padding cloves to obscure the true number of meaningful messages. This bundling provides several advantages: it reduces the number of distinct messages traversing the network (improving efficiency), it makes it harder for an observer to correlate individual messages, and it allows the protocol to include acknowledgment and status information without generating separate, observable traffic.

Encryption Layers

I2P uses a layered encryption scheme similar in concept to Tor's onion encryption but implemented differently. Each tunnel in I2P uses symmetric encryption (AES-256-CBC) with keys established during tunnel construction. The tunnel gateway encrypts a message with the keys of each hop in the tunnel, layered so that each hop can decrypt one layer and forward the result. I2P has been migrating its cryptographic primitives from older algorithms (ElGamal-2048 for asymmetric encryption) toward modern alternatives. The ECIES-X25519 specification, documented in the I2P proposal system, replaces ElGamal with X25519 Diffie-Hellman key agreement, providing better performance and stronger security. The implementation details can be reviewed in the I2P Java router source code on GitHub.

Tunnel Architecture

I2P's tunnel system is fundamentally different from Tor's circuit model. In Tor, a circuit is a bidirectional path through three relays. In I2P, tunnels are strictly unidirectional. Every I2P router maintains two types of tunnels: inbound tunnels (which receive messages from the network) and outbound tunnels (which send messages into the network). When router A wants to send a message to router B, A sends the message through one of its outbound tunnels, and the message arrives at one of B's inbound tunnels. This unidirectional design means that an observer monitoring a single point in the network cannot easily correlate incoming and outgoing traffic for a given router.

Tunnel Construction

Tunnels are built by the router that will be the tunnel endpoint (the inbound gateway for inbound tunnels, or the originator for outbound tunnels). The tunnel creator selects a set of participating routers based on performance profiles and constructs a tunnel build message. This build message is an encrypted request that is sent through the tunnel path itself -- each hop decrypts its portion of the request, decides whether to participate, and forwards the remainder to the next hop. Each hop in the tunnel only knows the identity of the previous and next hops, not the full tunnel path or the tunnel creator's identity.

Tunnels in I2P have a maximum lifetime of 10 minutes, after which they must be rebuilt. This relatively short lifetime limits the window of vulnerability if a tunnel is compromised and ensures that the network's topology is constantly changing. The default tunnel length is 3 hops (including the gateway and endpoint), though this is configurable per application. Longer tunnels provide more anonymity at the cost of increased latency and reduced reliability.

Exploratory and Client Tunnels

I2P distinguishes between exploratory tunnels and client tunnels. Exploratory tunnels are used for network management tasks such as communicating with the floodfill network database, building other tunnels, and testing network connectivity. These tunnels are typically shorter (often 2 hops) and lower bandwidth. Client tunnels are built for specific applications and endpoints, with their length and quantity configured based on the application's anonymity and performance requirements. A high-anonymity application might use 3-hop tunnels with multiple redundant tunnels, while a latency-sensitive application might use 2-hop tunnels.

The Network Database and Floodfill Routers

I2P does not rely on centralized directory authorities like Tor. Instead, it uses a distributed hash table (DHT) called the network database (netDB) to store two types of information: RouterInfo structures (which describe I2P routers and their transport addresses) and LeaseSets (which describe the inbound tunnels for a particular destination, analogous to Tor's onion service descriptors).

Floodfill Database

The netDB is maintained by a subset of I2P routers designated as floodfill routers. Any router with sufficient bandwidth and uptime can become a floodfill router, and the number of floodfill routers scales dynamically with the network size. When a router publishes its RouterInfo or a destination publishes its LeaseSet, the data is stored on the floodfill routers closest (in terms of the DHT keyspace distance, using the XOR metric) to the hash of the data's key. Lookups follow the same logic: a router querying for a particular RouterInfo or LeaseSet contacts the floodfill routers closest to the corresponding hash.

This distributed approach has both advantages and disadvantages compared to Tor's directory authority model. On the positive side, it eliminates single points of failure and does not require a small set of trusted authority operators. On the negative side, it is potentially more vulnerable to Sybil attacks where an adversary runs many floodfill routers to intercept lookups and manipulate the database. I2P mitigates this through verification of stored data (all RouterInfo and LeaseSet entries are cryptographically signed) and through redundant storage across multiple floodfill routers.

Eepsites: Hosting Services on I2P

Eepsites are websites hosted within the I2P network, accessible only through I2P's internal addressing system. They are the I2P equivalent of Tor's .onion sites. An eepsite is identified by a .i2p address, which is either a human-readable hostname registered with a naming service or a base32-encoded hash of the destination's public keys. Unlike Tor's .onion addresses, I2P supports a distributed naming system that allows human-readable names to be mapped to cryptographic destinations, though this naming system is based on local subscription lists rather than a global namespace.

Setting Up an Eepsite

Hosting an eepsite involves running a web server (commonly Jetty, Apache, or Nginx) bound to localhost and configuring an I2P server tunnel to expose it to the network. The I2P router includes a built-in Jetty web server and a preconfigured server tunnel for hosting eepsites, making the process straightforward for basic use cases. The general configuration process is as follows:

# Install I2P on Debian/Ubuntu
sudo apt-add-repository ppa:i2p-maintainers/i2p
sudo apt update
sudo apt install i2p

# Start the I2P router
i2prouter start

# Access the router console at http://127.0.0.1:7657
# Navigate to Hidden Services Manager
# Create a new server tunnel pointing to your local web server

# Example Nginx configuration for eepsite
server {
    listen 127.0.0.1:8080;
    server_name localhost;
    root /var/www/eepsite;
    index index.html;

    # Disable server tokens for anonymity
    server_tokens off;

    # Remove unnecessary headers
    proxy_hide_header X-Powered-By;
}

Important considerations for eepsite operators include stripping all identifying information from HTTP response headers, ensuring that the web server is bound exclusively to localhost (never to a public interface), and configuring the server to avoid leaking information through error pages, directory listings, or server identification strings. For comprehensive operational security guidance, refer to our OPSEC fundamentals article.

Transport Protocols: NTCP2 and SSU2

I2P operates at the application layer but requires transport protocols to move encrypted data between routers over the underlying IP network. Currently, I2P supports two transport protocols: NTCP2 (Noise-based Transport Connection Protocol 2) and SSU2 (Secure Semireliable UDP 2).

NTCP2 is a TCP-based transport that uses the Noise protocol framework (specifically the XK handshake pattern) for key agreement and authentication. It provides reliable, ordered delivery and includes obfuscation features to make I2P traffic less distinguishable from ordinary TLS connections. SSU2, the newer UDP-based transport, provides better performance through reduced connection overhead and improved resistance to network-level attacks. SSU2 also uses the Noise framework and includes features like path validation and connection migration. The specification for both protocols is maintained in the I2P technical specification.

I2P vs Tor: A Detailed Comparison

Understanding the differences between I2P and Tor is essential for choosing the right tool for a given use case. These are fundamentally different systems designed with different primary goals, and neither is universally superior.

Network Architecture

Tor uses a circuit-switched design with centralized directory authorities and a clear distinction between clients and relays. I2P uses a packet-switched design with a distributed network database and no distinction between clients and relays -- every participant routes traffic. Tor's circuits are bidirectional; I2P's tunnels are unidirectional. Tor uses exactly three hops per circuit; I2P's tunnel length is configurable per application. Tor has approximately 6,000-7,000 relays; I2P typically has 30,000-50,000 participating routers, though with significantly less total bandwidth.

Anonymity Model

Tor is optimized for anonymous access to the regular internet through exit nodes. I2P is optimized for anonymous communication within its own network. Tor's hidden services (onion services) provide a mechanism for internal services, but this was added as an extension to the original outproxy design. I2P was designed from the beginning as an internal network. This design difference has implications for anonymity: I2P's unidirectional tunnels and garlic routing provide stronger resistance to certain traffic analysis attacks within the network, while Tor's larger and more diverse user base provides a bigger anonymity set for clearnet access.

Performance

Tor generally provides lower latency for clearnet browsing because of its circuit-switched design and larger bandwidth capacity. I2P's packet-switched design introduces additional latency due to tunnel multiplexing and the overhead of garlic encryption, but it provides better throughput for internal services and is more resilient to congestion. I2P's performance has improved significantly in recent years, particularly with the introduction of SSU2 and ongoing optimization of the tunnel selection and profiling algorithms.

Censorship Resistance

Tor has invested heavily in censorship circumvention with pluggable transports like obfs4, meek, and Snowflake, which have been battle-tested in countries with sophisticated censorship infrastructure. I2P's censorship resistance relies primarily on the obfuscation properties of NTCP2 and SSU2 and the difficulty of enumerating all I2P routers (since there is no published list equivalent to Tor's consensus). However, I2P has historically received less attention from censorship circumvention researchers, and its pluggable transport ecosystem is less mature than Tor's.

I2P Applications and Ecosystem

The I2P network supports a rich ecosystem of applications beyond basic web hosting. I2PSnark is a built-in BitTorrent client that operates entirely within I2P, providing anonymous file sharing. Susimail and I2P-Bote provide anonymous email services with different design philosophies (Susimail uses traditional SMTP/POP3 through I2P, while I2P-Bote uses a distributed, serverless design with optional high-latency mixing for stronger anonymity). I2P also supports IRC through servers running within the network, providing anonymous real-time chat.

For developers, I2P provides the SAM (Simple Anonymous Messaging) protocol, which allows any application to create I2P tunnels and communicate over the network through a simple socket API. The SAM bridge listens on a local port and accepts connections from applications that want to use I2P. This makes it possible to I2P-enable virtually any networked application without modifying its core code. The SAM protocol is implemented in libraries for multiple programming languages, and the documentation is available through the I2P SAMv3 API specification.

I2P Java Router vs i2pd (C++ Implementation)

There are two primary implementations of the I2P protocol. The original I2P router is written in Java and is the reference implementation maintained by the I2P project. It includes a full-featured router console, built-in applications (eepsite server, I2PSnark, Susimail, SusiDNS), and comprehensive configuration options. The Java router is more feature-complete but requires a Java runtime environment and consumes more system resources.

The alternative implementation, i2pd (I2P Daemon), is written in C++ and provides a lightweight, high-performance router without the built-in applications. i2pd is particularly suitable for servers, embedded systems, and environments where resource consumption must be minimized. It can be found at github.com/PurpleI2P/i2pd and supports all core I2P protocols including NTCP2, SSU2, and the latest cryptographic specifications.

# Install i2pd on Debian/Ubuntu
sudo add-apt-repository ppa:purplei2p/i2pd
sudo apt update
sudo apt install i2pd

# Start i2pd
sudo systemctl start i2pd

# Access the web console
# http://127.0.0.1:7070

# Check i2pd status
sudo systemctl status i2pd

# View logs
sudo journalctl -u i2pd -f

Security Considerations and Known Limitations

Like any anonymity network, I2P is not a panacea. Its security depends on the size and diversity of the network, the correctness of the implementation, and the operational security practices of its users. Several categories of attacks merit consideration.

Sybil attacks pose a risk to the floodfill-based network database. An adversary running a significant number of floodfill routers could potentially intercept LeaseSet lookups and attempt to deanonymize service operators or users. I2P mitigates this through redundant storage, cryptographic verification, and router profiling that deprioritizes unreliable or suspicious routers.

Intersection attacks exploit the fact that I2P tunnels are rebuilt every 10 minutes. By observing which routers are online when a particular service is available, an adversary can gradually narrow down the possible set of routers hosting the service. Longer-lived tunnels and larger anonymity sets make this attack more difficult, but it remains a theoretical concern for services that are online for extended periods.

Timing attacks, while mitigated by garlic bundling and tunnel batching, cannot be entirely eliminated in a low-latency network. I2P's design prioritizes usability over maximum resistance to timing analysis, similar to Tor. High-latency mixnets like Mixmaster or the defunct Mixminion provide stronger timing resistance but at the cost of minutes or hours of message delay.

For users who need to combine I2P access with broader internet privacy, integrating I2P within a Tor-routed environment (such as running I2P inside Whonix) provides defense in depth. Understanding the principles of onion routing is valuable for comprehending both networks. For users handling financial transactions anonymously, our guide on Monero privacy covers cryptocurrency anonymity techniques that complement network-level anonymity.

Getting Started with I2P

For new users, the recommended approach is to install the Java I2P router, allow it to integrate into the network (which takes approximately 5-10 minutes for initial tunnel building), and then explore the built-in applications through the router console at http://127.0.0.1:7657. The I2P community maintains forums and IRC channels accessible within the network itself, and the I2P get involved page provides information on contributing to the project. I2P is a volunteer-run project that depends on community participation, and every router added to the network strengthens anonymity for all users.