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

{% extends "global/layout.html" %}
{% block title %}Transport Overview{% endblock %}
{% block content %}

Updated July 2010, current as of router version 0.8

<h1>Transports in I2P</h1>

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.

<p> I2P supports multiple transports simultaneously.
There are two transports currently implemented:
<ol>
<li> <a href="{{ site_url('docs/transport/ntcp') }}">NTCP</a>, a Java New I/O (NIO) TCP transport
<li> <a href="{{ site_url('docs/transport/ssu') }}">SSU</a>, or Secure Semireliable UDP
</ol>

Each provides a "connection" paradigm, with authentication,
flow control, acknowledgments and retransmission.


<h2>Transport Services</h2>

The transport subsystem in I2P provides the following services:
<ul>
<li>Maintain a set of router addresses, one or more for each transport,
    that the router publishes as its global contact information (the RouterInfo)
<li>Selection of the best transport for each outgoing message
<li>Queueing of outbound messages by priority
<li>Bandwidth limiting, both outbound and inbound, according to router configuration
<li>Setup and teardown of transport connections
<li>Encryption of point-to-point communications
<li>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
<li>Firewall port opening using UPnP (Universal Plug and Play)
<li>Cooperative NAT/Firewall traversal
<li>Local IP detection by various methods, including UPnP, inspection of incoming connections, and enumeration of network devices
<li>Coordination of firewall status and local IP, and changes to either, among the transports
<li>Communication of firewall status and local IP, and changes to either, to the router and the user interface
<li>Determination of a consensus clock, which is used to periodically update the router's clock, as a backup for NTP
<li>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
<li>Qualification of valid IP addresses according to a local rule set
<li>Honoring the automated and manual lists of banned peers maintained by the router,
    and refusing outbound and inbound connections to those peers
</ul>


<h2>Transport Addresses</h2>

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.
<p>
Typical scenarios are:
<ul>
<li>A router has no published addresses, so it is considered "hidden" and cannot receive incoming connections
<li>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="{{ site_url('docs/transport/ssu') }}">the SSU spec</a> for details)
<li>A router is not firewalled or its NAT ports  are open; it publishes both NTCP and SSU addresses containing
    directly-accessible IP and ports.
</ul>

<h2>Transport Selection</h2>

The transport system delivers <a href="i2np.html">I2NP messages</a>. The transport selected for any message is
independent of the application-layer protocol (TCP or UDP).
<p>

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

<p>
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.



<h2>New Transports and Future Work</h2>

Additional transports may be developed, including:

<ul>
<li>A TLS/SSH look-alike transport
<li>An "indirect" transport for routers that are not reachable by all other routers (one form of "restricted routes")
</ul>

<p>
Also, the existing transports will be enhanced to support multiple addresses within a single transport,
including IPV6 addresses. Currently, a transport may only advertise a single IPV4 address.

<p>
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).

<p>
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.

</p><p>
Analyze
<a href="http://www.cse.chalmers.se/%7Ejohnwolf/publications/hjelmvik_breaking.pdf">Breaking and Improving Protocol Obfuscation</a>
and see how transport-layer padding may improve things.
</p>


{% endblock %}