0.9.31

Roadmap update
Proposal 141

i2p2www/__init__.py

@@ -22,7 +22,7 @@ except ImportError:
 ###########
 # Constants
 
-CURRENT_I2P_VERSION = '0.9.30'
+CURRENT_I2P_VERSION = '0.9.31'
 
 CANONICAL_DOMAIN = 'geti2p.net'
 

i2p2www/pages/downloads/macros

-{% set i2pinstall_windows_hash = '1d037f4a03f00948b454c7e026617cab86fe2eeef9f87a9a7925f94350a11fd2' %}
-{% set i2pinstall_jar_hash     = '319421c892a12c36710ad71558927c844da08ea4e4d1c3ee69fc6be2cecce92e' %}
-{% set i2psource_hash          = 'fa18a31c56ce9dbce492d800fda8c947612199427f64f544b81e290dde1fce8f' %}
-{% set i2pupdate_hash          = '072ef8cfe9990715a130567f34b6083a51374099d15e419a041c152a4654ef73' %}
+{% set i2pinstall_windows_hash = 'c8fed029d71b819afc129d6a397ea5983de3375ae2985d97661153405ffc0dde' %}
+{% set i2pinstall_jar_hash     = 'dc26fb5c268dfe63b98bce66381c24c908f0b8265ddf731f4daf6fb82c4b7376' %}
+{% set i2psource_hash          = '94867fc8ac91eb561598736f6d51773375110db546f8b057c29758b0045931d8' %}
+{% set i2pupdate_hash          = 'a32ffb5f76aaa8bdc86854d741a32dc384e5e0b5ee00c6feec6fa3838467d1c4' %}
 {% set i2p_android_hash        = '5871f4b8cfd02dd298bf4ebf84ab697579196e85a3e9163bf1c1f2118fa17386' %}
 
 {% set i2p_windows_subver = '' %}

i2p2www/pages/site/get-involved/roadmap.html

@@ -183,7 +183,7 @@ Bug fixes, translation updates, geoip updates
 
 
 <h2 id="v0.9.31">0.9.31</h2>
-<p><b>Target release date: Week of July 3, 2017</b></p>
+<p><b>Released: August 7, 2017</b></p>
 <ul><li>
 Console redesign phase 1 ("refresh") (ticket #738)
 </li><li>
@@ -197,8 +197,8 @@ Bug fixes, translation updates, geoip updates
 </li></ul>
 
 
-<h2 id="v0.9.32">0.9.32</h2>
-<p><b>Target release date: September 2017</b></p>
+<h2 id="v0.9.32">0.9.32 and 0.9.33</h2>
+<p><b>Target release date: October and December 2017</b></p>
 <ul><li>
 EdDSA updates
 </li><li>
@@ -257,7 +257,7 @@ Bug fixes, translation updates, geoip updates
 </li></ul>
 
 
-<h2 id="2017">0.9.33-0.9.34 (4th quarter 2017)</h2>
+<h2 id="2018">0.9.34-0.9.35 (February and April 2018)</h2>
 <ul><li>
 New crypto (ElGamal replacement) further progress
 </li><li>

i2p2www/spec/proposals/141-deprecate-hostnames-in-addresses.rst

+=======================================
+Deprecate hostnames in router addresses
+=======================================
+.. meta::
+    :author: zzz
+    :created: 2017-08-03
+    :thread: http://zzz.i2p/topics/2363
+    :lastupdated: 2017-08-03
+    :status: Open
+
+.. contents::
+
+
+Overview
+========
+
+As of release 0.9.32, update the netdb specification
+to deprecate hostnames in router infos,
+or more precisely, in the individual router addresses.
+In all I2P implementations,
+publishing routers configured with hostnames should replace hostnames with IPs before publishing,
+and other routers should ignore addresses with hostnames.
+Routers should not do DNS lookups of published hostnames.
+
+
+Motivation
+==========
+
+Hostnames have been allowed in router addresses since the beginning of I2P.
+However, very few routers publish hostnames, because it requires
+both a public hostname (which few users have), and manual configuration
+(which few users bother to do).
+In a recent sample, 0.7% of routers were publishing a hostname.
+
+The original purpose of hostnames was to help users with frequently
+changing IPs and a dynamic DNS service (such as http://dyn.com/dns/)
+to not lose connectivity when their IP changed. However, back then
+the network was small and router info expiration was longer.
+Also, the Java code did not have working logic to restart the router or
+republish the router info when the local IP changed.
+
+Also, in the beginning, I2P did not support IPv6, so the complication
+of resolving a hostname to either an IPv4 or IPv6 address did not exist.
+
+In Java I2P, it's always been a challenge to propagate a configured
+hostname to both published transports, and the situation got more complex
+with IPv6. Open ticket 1050 http://trac.i2p2.i2p/ticket/1050 details some of the problems.
+It isn't clear if a dual-stack host should publish both a hostname and a literal
+IPv6 address or not. The hostname is published for the SSU address but not the NTCP address.
+
+Recently, DNS issues were brought up (both indirectly and directly) by
+research at Georgia Tech. The researchers ran a large number of floodfills
+with published hostnames. The immediate issue was that for a small number of
+users with possibly broken local DNS, it hung I2P completely.
+
+The larger issue was DNS in general, and how
+DNS (either active or passive) could be used to very quickly enumerate the network,
+especially if the publishing routers were floodfill.
+Invalid hostnames or unresponsive, slow, or malicious DNS responders could
+be used for additional attacks.
+EDNS0 may provide further enumeration or attack scenarios.
+DNS may also provide attack avenues based on time-of lookup,
+revealing router-to-router connection times, help to build connection graphs,
+estimate traffic, and other inferences.
+
+Also, the Georgia Tech group, led by David Dagon, has listed several concerns
+with DNS in privacy-focused applications. DNS lookups are generally done by
+a low-level library, not controlled by the application.
+These libraries were not specifically designed for anonymity;
+may not provide fine-grained control by the application;
+and their output may be fingerprinted.
+Java libraries in particular may be problematic, but this is not just a Java issue.
+Some libraries use DNS ANY queries which may be rejected.
+All this is made more worrisome by the widespread presence
+of passive DNS monitoring and queries available to multiple organizations.
+All DNS monitoring and attacks are out-of-band from the perspective of
+I2P routers and require little to no in-network I2P resources,
+and no modification of existing implementations.
+
+While we haven't completely thought through the possible issues,
+the attack surface seems to be large. There are other ways to
+enumerate the network and gather related data, but DNS attacks
+could be much easier, faster, and less detectable.
+
+Router implementations could, in theory, switch to using a sophisticated
+3rd-party DNS library, but that would be quite complex, be a maintenance burden,
+and is well outside the core expertise of I2P developers.
+
+The immediate solutions implemented for Java 0.9.31 included fixing the hang problem,
+increasing DNS cache times, and implementing a DNS negative cache. Of course,
+increasing cache times reduces the benefit of having hostnames in routerinfos to begin with.
+
+However, these changes are only short-term mitigations and do not fix the underlying
+issues above. Therefore, the simplest and most complete fix is to prohibit
+hostnames in router infos, thus eliminating DNS lookups for them.
+
+
+Design
+======
+
+For the router info publishing code, implementers have two choices, either
+to disable/remove the configuration option for hostnames, or to
+convert configured hostnames to IPs at publishing time.
+In either case, routers should republish immediately when their IP changes.
+
+For the router info validation and transport connection code,
+implementers should ignore router addresses containing hostnames,
+and use the other published addresses containing IPs, if any.
+If no addresses in the router info contain IPs, the router
+should not connect to the published router.
+In no case should a router do a DNS lookup of a published hostname,
+either directly or via an underlying library.
+
+
+
+Specification
+=============
+
+Change the NTCP and SSU transport specs to indicate that the "host" parameter must be
+an IP, not a hostname, and that routers should ignore individual
+router addresses that contain hostnames.
+The relevant section is "Router Address Specification" in the transport specifications:
+http://i2p-projekt.i2p/en/docs/transport/ntcp
+and
+http://i2p-projekt.i2p/en/docs/transport/ssu
+
+
+Notes
+=====
+
+This proposal does not address hostnames for reseed hosts.
+While DNS lookups for reseed hosts are much less frequent,
+they could still be an issue. If necessary, this can be fixed simply
+by replacing the hostnames with IPs in the hardcoded list of URLs;
+no specification or code changes would be required.
+
+
+Migration
+=========
+
+This proposal may be implemented immediately, without a gradual migration,
+because very few routers publish hostnames, and those that do generally
+don't publish the hostname in all addresses.
+
+Routers need not check the published router's version
+before deciding to ignore hostnames, and there is no need
+for a coordinated release or common strategy across
+the various router implementations.
+
+For those routers still publishing hostnames, they will get less
+inbound connections, and may eventually have difficulty building
+inbound tunnels.
+
+To minimize the impact further, implementers could start by ignoring
+router addresses with hostnames only for floodfill routers,
+or for routers with a published version less than 0.9.32,
+and ignore hostnames for all routers in a later release.