Code: Select all
Reseed Policy ============= This page was last updated in July of 2020. Definitions ----------- - Reseed Server: A Reseed server is a publically-accessible service which allows a new participant to join the I2P network by providing them with a small initial set of peers, the participant then builds exploratory tunnels through these peers to integrate themselves into the I2P network. - Reseed Operator: A sysadmin who operates an individual reseed server. - Reseed Administrator: An I2P Project team member who's responsibility it is to work 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. - 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." The guidelines in this document **do not** apply to Unofficial Reseed. Section 1: Responsibilities --------------------------- Reseed operation is a critical task on the I2P network, and the vast majority of new network participants join the network by getting their initial peers from a Reseed Service. 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 only 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. Reseed operators can contact the Reseed Administrator at [EMAIL TO BE FILLED IN]. Please encrypt e-mails to this address using the following [GPG KEY TO BE FILLED IN]. General support for reseed operation can be obtained by contacting the project on IRC at #i2p-dev for non-sensitive issues. Criteria for Inclusion as an Official Reseed -------------------------------------------- ### Section 2: Log Requirements - Official Reseed services do not require logging of user data, and in accordance with international regulations should 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 recieve, but this must be in the aggegate and not be combined with any user data. ### Section 3: 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 professional and respectful way. We 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 ill contact *all* Reseed Operators via GPG-encrypted e-mail. ### Section 4: 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, *except* - in cases where the Reseed Operators chooses to implement fail2ban or another solution 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. #### Section 5: 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. - **When a breakage occurs,** i.e. 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. 1. 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. 2. When the Reseed Operator responds: - If the Reseed Operator is available to continue operating their reseed server 1. The Reseed Administrator and the Reseed Operator work together to resolve the problem. When the problem is resolved, no further action is required. 2. If the issue cannot be resolved, for instance, because operating the Reseed Service is not reconciliable with the hosting provider's terms-of-use, then 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 1. The Reseed Service is removed from the list of default Reseed Services, the former operator is thanked for their time and participation in the I2P community. 3. If the Reseed Operator fails to respond: 1. The Reseed Administrator notifies the development team via #i2p-dev *and* via a forum post on i2pforum.net/i2pforum.i2p - The malfunctioning reseed and the nature of the malfunction. - That the Reseed Operator has not responded within the required 72 hours. 2. If the Reseed Service is responding to new participants with out-of-date routerinfos and the Reseed Operator remains unresponsive: - The Reseed Service will be removed from the I2P software until such a time as the Reseed Operator resumes contact and re-applies to be a Reseed Service. 3. 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. 4. 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.