Reseed Operator's Policy Draft

HowTos, FAQs, Tips & Tricks, & Guides
Post Reply
eyedeekay
Posts: 28
Joined: 21 Jul 2018 06:53

Reseed Operator's Policy Draft

Post by eyedeekay »

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.
eyedeekay
Posts: 28
Joined: 21 Jul 2018 06:53

Re: Reseed Operator's Policy Draft

Post by eyedeekay »

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: Privacy Policy
-------------------------

It is I2P's responsibility to treat your privacy seriously. The role of a reseed operator is a trusted role in the I2P
network which is responsible for the introduction of the majority of new I2P users.

 1. Reseed Operators must not collect and store IP address or geolocation data in excess of that required for routine
  server maintenance(see: Logging Requirements below).
 2. Reseed Operators must not collect and store reseed request timing data in excess of that required for rate-limiting
  software or routine maintenance.
 3. Reseed Operators must never share the IP addresses, geolocation data, user-agent data, or timing data of users who
  are requesting a reseed with anyone outside of the I2P team.
 4. Reseed Operators must only share the IP addresses, geolocation data, user-agent data, or timing data of users who
  are requesting a reseed with necessary persons inside of the I2P team when it is required to investigate the cause of
  an event affecting reseed services.
 5. A Reseed Operator may retain a daily, running total of *all* reseed requests made that day, but these must be 
  aggregated and must not contain timing, geolocation, or IP address data.
 6. Data which is not found to be necessary is assumed to be unnecessary, and therefore, long-term retention of any
  information gained from running an Official Reseed service is strictly prohibited.

Section 2: 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 3: Logging Requirements

 - Official Reseed services do not require long-term logging of user data, and in accordance with international
  regulations should not retain that data. Retaining this information will result in a reseed being removed from the
  I2P software.
 - Excessive retention of logging data shall be deemed to have occurred if logs containing user data which correlates IP
  addresses and timings for a period of greater than 3 days.

### Section 4: 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 5: 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.
Post Reply