Create Admin Requirements

[Shoalsteed]

Since we have lost communication with Backup, let's create the guide and responsibilities for a new person who can take on the Reseed Admin role.

[eyedeekay]

Going to draft things here as I think of them.

• Time Commitment: Reseed administration is likely to have a highly variable schedule, with periods where everything works fine and there is little to do, downtime for individual reseeds which may be time consuming, to coordinating updates which will be applied to all reseeds and which may require a great deal of coordination between the reseed admin and all reseed operators.
• Software and Software Skills: Reseed administrators should be able to run a reseed themselves, which means that they will need to be able to use I2P, find the location of their own NetDB locally, and use the Go compiler for their platform of choice. They should be familiar with the basics of HTTPS.

[Shoalsteed]

• Have monitoring in place and provide weekly reports ( this is part of an idea I have for network health access for people to keep eyes on )

• Be available to troubleshoot with people

• Needs to be be responsive

[Shoalsteed]

Can anyone except zzz add new reseeds? Can there be 2 contacts?

• must know what is required to include in java package ( send all the public keys/certificates to zzz for inclusion)

[eyedeekay]

Technically anyone with mtn privs can, but adding them without letting him in on the process will be(quite properly) interpreted as an attack. If he is unavailable, I will do it, otherwise, it's got to be something we both discuss

[eyedeekay]

Re: monitoring, we can pretty much monitor reseeds remotely too, it's just a matter of me finding the time required to actually implement it. What I'd like to do is have all the reseeds monitor eachother, and output it all to the educational page we give to browsers and non-I2P clients.

[eyedeekay]

https://github.com/eyedeekay/reseed-monitoring is about 50% ready as of this afternoon.

[eyedeekay]

https://eyedeekay.github.io/reseed-monitoring/ Snapshot of what it looks like right now

[eyedeekay]

Policy draft here: https://i2pforum.net/viewtopic.php?f=21&t=961

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
  3. The Reseed Administrator and the Reseed Operator work together to resolve the problem. When the problem is resolved, no further action is required.
  4. 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
  5. 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.
  6. If the Reseed Operator fails to respond:
  7. 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.
  8. 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.
  9. 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.
  10. 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]

IMO these rules do not need to be changed. They are current and adequate.

[Shoalsteed]

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 in the I2P network. These services must be reliable, publicly 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 team on IRC at #i2p-dev for non-sensitive issues.

Criteria For Inclusion As An 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, withtheir 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 its 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.

[Shoalsteed]

This is complete and can be added to Gitbook w/ testing addition