i2p.www/i2p2www/pages/site/docs/transport/index.html

{% extends "global/layout.html" %}
{% block title %}{% trans %}Transport Overview{% endtrans %}{% endblock %}
{% block lastupdated %}{% trans %}June 2018{% endtrans %}{% endblock %}
{% block accuratefor %}0.9.36{% endblock %}
{% block content %}
<h2>{% trans %}Transports in I2P{% endtrans %}</h2>

<p>{% trans -%}
A "transport" in I2P is a method for direct, point-to-point communication
between two routers.
Transports must provide confidentiality and integrity 
against external adversaries while authenticating that the router contacted 
is the one who should receive a given message.
{%- endtrans %}</p>

<p>{% trans -%}
I2P supports multiple transports simultaneously.
There are three transports currently implemented:
{%- endtrans %}</p>
<ol>
<li>{% trans ntcp=site_url('docs/transport/ntcp') %}<a href="{{ ntcp }}">NTCP</a>, a Java New I/O (NIO) TCP transport{% endtrans %}</li>
<li>{% trans ssu=site_url('docs/transport/ssu') %} <a href="{{ ssu }}">SSU</a>, or Secure Semireliable UDP{% endtrans %}</li>
<li>{% trans ntcp2=site_url('docs/spec/ntcp2') %}<a href="{{ ntcp2 }}">NTCP2</a>, a new version of NTCP{% endtrans %}</li>
</ol>

<p>{% trans -%}
Each provides a "connection" paradigm, with authentication,
flow control, acknowledgments and retransmission.
{%- endtrans %}</p>


<h2>{% trans %}Transport Services{% endtrans %}</h2>

<p>{% trans -%}
The transport subsystem in I2P provides the following services:
{%- endtrans %}</p>
<ul>
<li>{% trans i2np=site_url('docs/protocol/i2np') -%}
Reliable delivery of <a href="{{ i2np }}">I2NP</a> messages.
Transports support I2NP message delivery ONLY.
They are not general-purpose data pipes.
{%- endtrans %}</li>
<li>{% trans %}In-order delivery of messages is NOT guaranteed by all transports.{% endtrans %}</li>
<li>{% trans -%}
Maintain a set of router addresses, one or more for each transport,
that the router publishes as its global contact information (the RouterInfo).
Each transport may connect using one of these addresses, which may be
IPv4 or (as of version 0.9.8) IPv6.
{%- endtrans %}</li>
<li>{% trans %}Selection of the best transport for each outgoing message{% endtrans %}</li>
<li>{% trans %}Queueing of outbound messages by priority{% endtrans %}</li>
<li>{% trans %}Bandwidth limiting, both outbound and inbound, according to router configuration{% endtrans %}</li>
<li>{% trans %}Setup and teardown of transport connections{% endtrans %}</li>
<li>{% trans %}Encryption of point-to-point communications{% endtrans %}</li>
<li>{% trans -%}
Maintenance of connection limits for each transport, implementation of various thresholds for these limits,
and communication of threshold status to the router so it may make operational changes based on the status
{%- endtrans %}</li>
<li>{% trans %}Firewall port opening using UPnP (Universal Plug and Play){% endtrans %}</li>
<li>{% trans %}Cooperative NAT/Firewall traversal{% endtrans %}</li>
<li>{% trans %}Local IP detection by various methods, including UPnP, inspection of incoming connections, and enumeration of network devices{% endtrans %}</li>
<li>{% trans %}Coordination of firewall status and local IP, and changes to either, among the transports{% endtrans %}</li>
<li>{% trans %}Communication of firewall status and local IP, and changes to either, to the router and the user interface{% endtrans %}</li>
<li>{% trans %}Determination of a consensus clock, which is used to periodically update the router's clock, as a backup for NTP{% endtrans %}</li>
<li>{% trans -%}
Maintenance of status for each peer, including whether it is connected, whether it was recently connected,
and whether it was reachable in the last attempt
{%- endtrans %}</li>
<li>{% trans %}Qualification of valid IP addresses according to a local rule set{% endtrans %}</li>
<li>{% trans -%}
Honoring the automated and manual lists of banned peers maintained by the router,
and refusing outbound and inbound connections to those peers
{%- endtrans %}</li>
</ul>


<h2>{% trans %}Transport Addresses{% endtrans %}</h2>

<p>{% trans -%}
The transport subsystem maintains a set of router addresses, each of which lists a transport method, IP, and port.
These addresses constitute the advertised contact points, and are published by the router to the network database.
Addresses may also contain an arbitrary set of additional options.
{%- endtrans %}</p>

<p>{% trans -%}
Each transport method may publish multiple router addresses.
{%- endtrans %}</p>

<p>{% trans %}Typical scenarios are:{% endtrans %}
<ul>
<li>{% trans %}A router has no published addresses, so it is considered "hidden" and cannot receive incoming connections{% endtrans %}</li>
<li>{% trans ssu=site_url('docs/transport/ssu') -%}
A router is firewalled, and therefore publishes an SSU address which contains a list of cooperating
peers or "introducers" who will assist in NAT traversal (see <a href="{{ ssu }}">the SSU spec</a> for details)
{%- endtrans %}</li>
<li>{% trans -%}
A router is not firewalled or its NAT ports  are open; it publishes both NTCP and SSU addresses containing
directly-accessible IP and ports.
{%- endtrans %}</li>
</ul>

<h2>{% trans %}Transport Selection{% endtrans %}</h2>

<p>{% trans i2np=site_url('docs/protocol/i2np'),
streaming=site_url('docs/api/streaming'),
datagrams=site_url('docs/api/datagrams') -%}
The transport system delivers <a href="{{ i2np }}">I2NP messages</a> only. The transport selected for any message is
independent of the upper-layer protocols and contents (router or client messages, whether an external application was using
TCP or UDP to connect to I2P, whether the upper layer was using
<a href="{{ streaming }}">the streaming library</a>
streaming
or
<a href="{{ datagrams }}">datagrams</a>,
datagrams
etc.).
{%- endtrans %}</p>

<p>{% trans -%}
For each outgoing message, the transport system solicits "bids" from each transport.
The transport bidding the lowest (best) value wins the bid and receives the message for delivery.
A transport may refuse to bid.
{%- endtrans %}</p>

<p>{% trans -%}
Whether a transport bids, and with what value, depend on numerous factors:
{%- endtrans %}</p>
<ul>
<li>{% trans %}Configuration of transport preferences{% endtrans %}</li>
<li>{% trans %}Whether the transport is already connected to the peer{% endtrans %}</li>
<li>{% trans %}The number of current connections compared to various connection limit thresholds{% endtrans %}</li>
<li>{% trans %}Whether recent connection attempts to the peer have failed{% endtrans %}</li>
<li>{% trans %}The size of the message, as different transports have different size limits{% endtrans %}</li>
<li>{% trans %}Whether the peer can accept incoming connections for that transport, as advertised in its RouterInfo{% endtrans %}</li>
<li>{% trans %}Whether the connection would be indirect (requiring introducers) or direct{% endtrans %}</li>
<li>{% trans %}The peer's transport preference, as advertised in its RouterInfo{% endtrans %}</li>
</ul>

<p>{% trans -%}
In general, the bid values are selected so that two routers are only connected by a single transport
at any one time. However, this is not a requirement.
{%- endtrans %}</p>



<h2>{% trans %}New Transports and Future Work{% endtrans %}</h2>

<p>{% trans -%}
Additional transports may be developed, including:
{%- endtrans %}</p>

<ul>
<li>{% trans %}A TLS/SSH look-alike transport{% endtrans %}</li>
<li>{% trans %}An "indirect" transport for routers that are not reachable by all other routers (one form of "restricted routes"){% endtrans %}</li>
<li>{% trans %}Tor-compatible pluggable transports{% endtrans %}</li>
</ul>

<p>{% trans -%}
Work continues on adjusting default connection limits for each transport.
I2P is designed as a "mesh network", where it is assumed that any router can connect to any other router.
This assumption may be broken by routers that have exceeded their connection limits, and by
routers that are behind restrictive state firewalls (restricted routes).
{%- endtrans %}</p>

<p>{% trans -%}
The current connection limits are higher for SSU than for NTCP, based on the assumption that
the memory requirements for an NTCP connection are higher than that for SSU.
However, as NTCP buffers are partially in the kernel and SSU buffers are on the Java heap,
that assumption is difficult to verify.
{%- endtrans %}</p>

<p>{% trans pdf='http://www.iis.se/docs/hjelmvik_breaking.pdf' -%}
Analyze <a href="{{ pdf }}">Breaking and Improving Protocol Obfuscation</a>
and see how transport-layer padding may improve things.
{%- endtrans %}</p>


{% endblock %}