How to Set up a Reseed Server

Diese Seite wurde zuletzt Februar 2017 aktualisiert.

Übersicht

Thank you for volunteering to run an I2P reseed server.
"Reseeding" is our term for bootstrapping new routers into the network.
New routers fetch a bundle of peer references, or "router infos", from one or more of a hardcoded list of HTTPS URLs.

Voraussetzungen

At its simplest, a reseed server consists of a Java I2P router, an HTTPS web server,
and some scripts that periodically gather router infos from the router,
bundle and sign them into a custom file format, and deliver these files over HTTPS.
In practice, it's a bit more complex, and a reseed operator must be fairly competent and attentive.
A reseed server is not appropriate for a residential internet connection. The complexities include:

You must have a secure SSL setup with either a self-signed certificate or a cert that chains up to a standard CA

The SSL configuration must conform to current best practices on allowed ciphers and protocols, and the CN/SAN host name must match the URL

The scripts are designed to deliver different router info bundles to different requestors for network diversity

The scripts are designed to deliver the same bundle to the same repeated requestor to prevent scraping

The reseed servers are under periodic attacks and DDoS attempts, and from other buggy I2P implementations and botnets.
This necessitates that you run fail2ban or an equivalent solution.

Informationen benötigt

When your setup is complete and ready for testing, we will need the HTTPS URL,
the SSL public key certificate, and the "su3" bundle public key.
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.

Datenschutzbestimmungen

A reseed operator is a trusted role in the network.
While we do not yet have a formal privacy policy, you must ensure the privacy of our users
by not publicizing logs or IPs found in those logs, except as necessary to discuss administration issues with the I2P reseed team.

Finanzielle Unterstützung

Modest financial support may be available to those running reseed servers.
This support would be in partial reimbursement for your server costs.
Support will not be paid in advance and will probably not cover all your expenses.
Support is only available to those who have been running reseed servers in good standing for several months, and is based on actual need.

If you would like to discuss support, please contact echelon and CC: backup.

Erste Schritte

Our reseed coordinator is "backup" and he may be contacted at backup at mail.i2p or backup at i2pmail.org.
Unfortunately, he is not generally on IRC. The reseed setup is somewhat specialized, and you should direct most questions to him.

For actual implementation, details below. We have one recommended reseed solution:

A Go implementation that includes the web server and all the scripts. This is the recommended solution.

For further information, read the information at the following links, and then contact backup.
Thank you!

1. Introduction

Public reseed servers are necessary to bootstrap into the I2P net.
New installed I2P routers needs one-time about one hundred RouterInfo's (RI) as jump start.

RI contains IP and Port from other I2P routers and are stored in dat-files in the netDB folder.

A random bunch of dat-files from the netDB are zipped, then signed to a su3-file
and finally offered to I2P routers seeking reseed service.

To secure bootstrap and enable a trusted start, HTTPS/TLS and signed su3-files are mandatory.

It is essential not to publish all RI from netDB, or all RI to one client.

2. Requirements

Requirements for running a public reseed server:

Well integrated running I2P router @ 24/7

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 as of December 2016

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

This How-to is tested with Ubuntu/Debian as well as FreeBSD.
The web server has to be public reachable from all over the world, an eepsite inside I2P can be setup in addition.
Also frequent or infrequent attempts to scrape all your reseed files, and of course attacks on your server.
The web server doesn't need to listen at default SSL/TLS port 443 - any other port can be used for obfuscation.

3. Go Solution - Quick Guide

1. Fire Up Your Favorite Webserver

Connect a domain, sub-domain or (anonymous) third-level-domain

Setup a state-of-the-art TLS(SSL) certificate

Allow access only via HTTPS/TLS, no unencrypted HTTP

Allow only very good ciphers, compatible to Java 7/8/9. See Cipherli.st

Note: A non default port other than 443 can be used; TLS certificate can be self signed; configure fail2ban as bot-net protection

Note: i2p-tool has also an build-in standalone webserver with TLS support which can be used without a webserver. Please contact me (backup at mail.i2p.de) if you need help, or stop by #i2p-dev on IRC2P and talk to other reseed operators.

9. Send Us Your Information

4. Go Solution - Detailed Instructions

1. Overview

The previous steps for reseeding involves many steps, scripts and programs.
Most of them are easy and plain straight forward, but overall you can call it a little confusing.

Here comes now an all-in-one solution from matt (Big Thanks!) for providing
a reseed server which merges the following functions into one binary:

Create su3-files

Create su3 signer certificate+key

Create SSL-certificate+key

Replaces the http-server and the PHP code (or run next to them in parallel)

Almost all previous used scripts and described steps are not needed with this solution,
but to understand the overall reseed process it is recommended to read them too :-)

If you already have an SSL-certificate and su3-signer-key you can reuse them, see one of the following chapter.

For testing and new reseeders the required certs and keys are created automatically at first start.

Also take a look at the content and the naming scheme of these pem and crt files.

Of course you need an up-to-date netDB folder with routerinfos from a running I2P router.
I2P does not have to be running on the same machine as this reseed binary.
In this case you can setup a cronjob to transfer the netDB from the I2P machine to the reseed machine.

Matt's go solution can be used in parallel next to an already running http-server.
For this leave the http-server running at normal port 80 and 443,
and configure Go solution too use another port, e.g. port 8443.

Redirect the output from the go solution to a logfile, format is default apache-style combined logs

Add a logrotate for the logfiles, since they grow big :-(

Logfiles can be used by fail2ban

Both of the certificates (*.crt) will need to be sent to the reseed maintainer
in order for your reseed server to be included in the standard I2P package.

Add a proper startup script, to run the reseed server, see next chapter

4. Draft for Startup Script "seedserver"

The reseed server should be started automatically, so you need a init.d or some sort of
startscript, here named as "seedserver".
This is only a very first draft for a simple startscript (it could be done better :-))

Login as I2P user:

Place the shell-script "seedserver" in the /home/i2p/bin folder (next to i2p-tools)

Make it executable: chmod u+x /home/i2p/bin/seedserver

Update the header "# Your settings" with your individual settings.

Now you can use the shell-script:

seedserver start

And then (give it some seconds) take a look at the status:

seedserver status
seedserver showlog

Some short explanation about seedserver:

runs i2p-tools in the background

creates logfiles

take care of all settings

If this is working fine, you can put the script in your personal crontab, to run it by auto-start
and to do logrotes simply by restarting it regularly once a week to avoid too big logfiles.
If you already reboot your server regularly, you can skip of course the "restart" command line.

5. Reverse-Proxy Setup

You can run i2p-tools also behind your normal web-server (reverse-proxy).

The web-server handles the TLS handshake, encryption, SSL Certificate and the logfiles.
But you don't need the scripts su3.php and the shell cronjob for creating su3-files.
i2p-tools is running "behind" the web-server, without TLS management, only bind to
local interface 127.0.0.1 and is handling complete building and handling of su3-files.

6. Convert Existing Java Keystore to crt- and pem-file

This describes how to convert your existing Java keystore with your su3 signing key to a plain crt- and pem-file.
This is only needed, when you already have a Java keystore and want to use Go solution.
If you create new keys+certs with matt's solution you can skip this chapter!

Requirements:

Java keytool

openssl

and of course your secret password for the keystore

Keep in mind: the Java keystore has two passwords:

The secret key password you have entered while creating your keystore the first time (SU3File keygen ...)

5. Seamless SSL-Certificate Exchange

The update/exchange of an already existing self-signed certificates has to be correct timed
on server *and* client side. Considering thousands of clients (many with older I2P version) the exchange
will not be seamless possible and will have very bad impact on many clients: reseed won't work for them.

To avoid this issue and make the exchange as smooth as possible follow these simple steps:

Generate a new SSL-certificate NOW, but do NOT implement it on server

Send the new SSL-certificate to us to perform a roll-out towards clients NOW

WAIT some month, e.g. 3-4 i2p-releases

New SSL-certificate is now hopefully present on many clients (in parallel to the current/old one)

THEN exchange the SSL-certificate on server

This idea based on the fact, that you can provide in i2p/certificates/ssl more than one crt-file for a server, e.g.
server.com.crt and server.com2.crt

6. Reseed Server Domain/URL/Port Exchange

You are already operating a reseed server but want to change your Domain/URL/Port?
To make the exchange as smooth as possible for many clients please follow these steps if possible:

Replace "--no-check-certificate" with "--ca-certificate=~/i2p/certificates/ssl/your-server.com.crt"
which contains the path to your local public SSL-certificate to check also your ssl-certificate chain.