Definitions

Reseed Server: A Reseed server is a publically-accessible service that provides a  an initial set of peers to new routers joining the I2P network. A new router  builds exploratory tunnels through these peers to integrate into the I2P network.

Reseed Operator: A sysadmin who operates an individual reseed server.

Reseed Administrator: An I2P team member who is responsible for  communicating with Reseed Operators on any and all issues relating to reseed server operation, and to communicate those needs to the I2P team.

Official Reseed: An Official Reseed is a reseed which has met all the requirements to be included in the core Java I2P router implementation from geti2p.net, and which has been submitted to that project successfully for inclusion.
An aspiring Official Reseed which is in the process of meeting these criteria is referred to as an "Official Reseed Candidate" until the process is complete. The process is outlined here: https://geti2p.net/en/get-involved/guides/reseed

Unofficial Reseed: A reseed which is conducted in such a way that it cannot meet the criteria of the Official Reseed process is called an "Unofficial Reseed."

Reseed operation is a critical task on the I2P network. These services must be reliable, publically accessible, and they must be secure against attack. The operators must be attentive, responsive, and perform routine maintenance.

Reseed servers are themselves fairly simple to operate, and require a nominal amount of systems-administration knowledge to run successfully. Participation in the community by reporting and responding to reseed issues and remaining in contact with the I2P Project and with the Reseed Administrator is the most important aspect of reseed administration.

General support for reseed operation can be obtained by contacting the dev team on IRC at #i2p-dev for non-sensitive issues.

The following guide and policy is for people who wish to become an official reseed in the core Java software.

Criteria for Inclusion As An I2P Java Software Official Reseed

Log Requirements

Official reseed services do not require logging of user data, and in accordance with international regulations can not retain that data. This includes IP address data, and any kind of geolocation data. Retaining this information will result in a reseed being removed from the I2P software.

Reseed operators may, if they wish, log the number of requests they receive, but this must be in the aggregate and not be combined with any user data.

Communication Requirements

Reseed operators must be in communication with the Reseed Administrator. They must be reachable by GPG-encrypted e-mail, and also at least one other channel from the following list:

• I2PRC
• Jabber/XMPP (Off-The-Record)
• i2pforum.net/i2pforum.i2p
• i2pgit.org via a gitlab issue

In cases where none of these is suitable the Reseed Operator and Reseed Administrator may work together to coordinate another backup channel.

A Reseed Service is by definition a public-facing, essential service to the I2P network and should present itself to potential visitors in a professional and respectful way. The project will refuse reseed applications from domains and individuals we believe to be bad actors.

Reseed services serve an error page to non-I2P user agents. If the Reseed Operator chooses to customize this error page, educational or promotional material about I2P is acceptable.

Should a widespread attack on Reseed Services occur, the Reseed Administrator will contact all Reseed Operators via GPG-encrypted e-mail.

Service Requirements

Reseed services are sometimes targeted by attackers seeking to scrape them for peer information, or simply to deny service to legitimate reseed participants. The reseed server software contains built-in rate limiting defenses against this behavior which is enabled by default, and should remain on all reseed servers. In cases where the Reseed Operator chooses to implement fail2ban or another solution for rate-limiting or security, they may do at their discretion on the condition that the software can be made to meet the logging requirements from Section 2.

Rate-limiting to prevent reseed scraping activity is mandatory.

The operator of a Reseed Service should apply security updates to the host operating system as soon as possible, and if their operating system supports it, they should enable automatic updates.

Breakdown Procedure

There is no ongoing or periodic requirement to maintain communication with the Reseed Administrator. When a breakage occurs, the Reseed Administrator reaches out to the Reseed Operator to guide them to a solution.

The Reseed Administrator uses a tool to periodically check and validate that Reseed Services are working successfully. This procedure should run daily at a specified time, in order to produce consistent results.

Examples of a Broken Reseed Service

If a Reseed Service is providing out-of-date reseed data, has expired or invalid certificates, or simply becomes unavailable, the reseed is considered broken and the following procedure begins.

The Reseed Administrator initiates contact with the Reseed Operator by their GPG-encrypted e-mail with a short summary of the issue at hand. The Reseed Operator should respond within 72 hours to the Reseed Administrator, with
their availability to work with the Reseed Administrator to solve the problem.

If the Reseed Operator is available to continue operating their reseed server, the Reseed Administrator and the Reseed Operator work together to resolve the problem. When the problem is resolved, no further action is required.

If the issue cannot be resolved, the Reseed Service is removed from the list of default Reseed Services until such a time as service can be restored.

If the Reseed Operator is not available to continue operating their reseed server the Reseed Service is removed from the list of default Reseed Services. The operator is thanked for their time and participation in the I2P community.

If the Reseed Operator fails to respond, the Reseed Administrator notifies the development team via #i2p-dev and via a forum post on i2pforum.net/i2pforum.i2p

The following information will be provided:

• The malfunctioning reseed and the nature of the malfunction.
• Confirmation that the Reseed Operator has not responded within the required 72 hours.

If the Reseed Service is responding to new routers with out-of-date routerinfos and the Reseed Operator remains unresponsive, the Reseed Service will be removed from the I2P software. The Reseed Operator must resumes contact and re-apply to be a Reseed Service if necessary.

If the Reseed Service provides a TLS certificate and is responding to new participants via an invalid or incorrect certificate, is is to be assumed that the Reseed Service has had it's security compromised and that someone is attempting impersonation. The Reseed Service will be removed from the I2P software. Reseed services who's certificates merely expired can be re-added when they renew their certificates.

If the Reseed Service is unreachable then the service may remain in the reseed list until the next release, or it may be removed at the developers discretion.