I2P Infrastructure: Reseeds

What Is a "Reseed?"

"Reseeding" is the I2P terminology for "bootstrapping."

I2P is a peer-to-peer network, meaning that it relies on its own database of connected routers participating in the network, referred to as "peers" or "nodes." For a new router to begin participating in the network, it relies on files that share information about the network database (routerinfos). This information is a dataset of known peers in the network that provide the connections needed for a new router to join. This process is called "reseeding" and the service is a "reseed server." Think of it like a host at a party who introduces people when they arrive so that they can get to know other people and begin making new connections with other guests. The integration process created by the reseed server allows the new router to begin making its own peer connections and begin routing traffic within the network.

The I2P netDb is a distributed database that contains two types of data:

1 - Router contact information (RouterInfos).

2 - Destination contact information (LeaseSets).

Thanks to its design, the data handling is dynamic which allows for new entries and cycling out entries that are irrelevant to its function.

Distribution of the netDb is accomplished by a technique called "floodfill." This is a subset of routers that participate in maintaining the database.

New routers use these reseed servers to access the required information (routerinfos) from one or more of a hardcoded list of HTTPS URLs included in the core Java I2P router distribution. These servers are run by volunteers, and are vital to the infrastructure of the I2P network.

Running a Reseed Service

A reseed server must be reachable on the internet. A reseed service has to be hosted outside of the I2P network to be useful as a bootstrap service. In terms of anonymity, the service can be pseudonymous up to the point that an operator can decouple hosting from their real identity. A reseed will serve routerInfos that it knows are healthy from your local netDb, so there is small chance that it could technically reveal some information about what peers your floodfill knows about. Operators should not host a reseed server on a router that hosts other I2P services, unless you don't mind them being linkable.

Hosting concerns need to mitigate attacks and blocking. Attacks include scraping routerInfos from reseeds, and using excessive requests meant to exhaust the bandwidth and financial resources of reseed operators. Operators will need to use fail2ban and have an IDS, and keep their systems up to date.

The official I2P homepage, its mirror site, reseed servers deal with accessibility issues because of blocking attempts. Some regions block access to I2P by poisoning DNS resolutions of the I2P homepage and reseed servers; SNI-based blocking was detected in Oman and Qatar when accessing the I2P homepage over HTTPS; TCP packet injection has been detected in Iran, Oman, Qatar, and Kuwait when visiting the mirror site via HTTP; and explicit block pages were discovered when visiting the mirror site from Oman, Qatar, and Kuwait. Learn more about regional blocking research in the paper Measuring I2P Censorship at a Global Scale https://www.usenix.org/system/files/foci19-paper_hoang.pdf

There are also sometimes issues at the ISP level, for instance reseed.diva.exchange is "blocked" in Switzerland by Swisscom, one of the large internet providers in Switzerland by filtering. Using a Docker container mitigates these blocking strategies

OONI maintains statistics on access issues as well, and up-to-date information can be found here https://explorer.ooni.org/domain/i2p2.de?since=2023-09-25&until=2023-10-25

Failed Reseeds and Manual Reseeding

There are times when network connections are poor, or when distribution options require or choose discretion. A person may even just want to periodically generate a file from their own router to take with them when travelling. Firewall issues and regional considerations may require file based reseed support.

When a router is having connection issues it will prompt the user to Reseed.

The Reseed button will appears in the side bar.

Pressing it initiates a fetching process "fetching reseeds"

Once it is done, it will prompt "Reseed successful, fetched xx router infos"

Restart you router.

If an I2P participant wants to help a person with connectivity issues, they can generate a reseed file and share it. This can be done using any platform or network that allows the file to be shared and that will potentially take in to consideration monitoring and blocking.

🚨It is vital that the file is exchanged over a secure encrypted channel to avoid external tampering. You should consider using PGP to sign, encrypt and verify with a trusted public key. The file itself is unsigned, only accept files only from known trusted sources. Never import a reseed file if you can not verify its source. 🚨

To create a reseed file, go to the Reseed configuration page of your router.

Select "create reseed file" to create a zip file and share it. Keep in mind that the file should not be shared too many times or left for a long period to ensure that the information is as up-to-date as possible.

An i2preseed.zip file shared by a trusted source can be uploaded to an I2P router via the same  Reseed Configuration page. Navigate to Manual Reseed From File browse and “Select zip or su3 file” and choose the reseed file. You can check your router log for the router information received from the file and if there are any error messages.

Running A Core Distribution Reseed Server

The I2P core distribution relies on volunteers who maintain reseed servers that the router includes in its distribution to handle the process automatically for new download and installs. Please consider supporting the network by reviewing the guides and contacting zzz on the I2P dev channel on irc.

The following and further documentation can be found on the I2P site: https://geti2p.net/en/docs/reseed

Requirements for running a public reseed server:

• A well integrated I2P router that is running @ 24/7
• A server with static IPv4 (2 cpu/ 2GB ram is fine)
• Unix to run the golang solution
• Own domain, sub-domain or an anonymous third-level domain
• A self-signed SSL certificate, or an SSL certificate from Let's Encrypt
• Enough bandwidth and traffic volume - Around 15 GB/month
• Up-to-date web server (Apache/nginx), HTTPS ONLY with TLS 1.2 and good ciphers

Optional:

• fail2ban to protect you from botnets
• GnuPG/PGP for signed/encrypted emails
• IPv6

Information Required

When your setup is complete and ready for testing, we will need the HTTPS URL, the SSL public key certificate (only if selfsigned), and the su3 public key certificate. After testing is complete, these will be added to the hardcoded entries in the Java and C++ routers in the next release, and you will start seeing traffic. We also will need your email address so we may continue to contact you about reseed administration issues. The email will not be made public but will be known to the other reseed operators. You should expect that your nick or name and its association with that URL or IP will become public.

Privacy Policy

A reseed operator is a trusted role in the network. Operators must ensure the privacy of I2P participants by not publicizing logs or IPs found in those logs, except as necessary to discuss administration issues with the I2P reseed team.