Skip navigation

I2NP Specification

This page was last updated in February 2014 and is accurate for router version 0.9.11.

I2NP Specification

The I2P Network Protocol (I2NP), which is sandwiched between I2CP and the various I2P transport protocols, manages the routing and mixing of messages between routers, as well as the selection of what transports to use when communicating with a peer for which there are multiple common transports supported.

Common structures

The following structures are elements of multiple I2NP messages. They are not complete messages.

I2NP message header

Description

Common header to all I2NP messages, which contains important information like a checksum, expiration date, etc.

Contents

1 byte Integer specifying the type of this message, followed by a 4 byte Integer specifying the message-id. After that there is an expiration Date, followed by a 2 byte Integer specifying the length of the message payload, followed by a Hash, which is truncated to the first byte. After that the actual message data follows.

Standard (16 bytes):

+----+----+----+----+----+----+----+----+
|type|      msg_id       |  expiration
+----+----+----+----+----+----+----+----+
                         |  size   |chks|
+----+----+----+----+----+----+----+----+

Short (SSU, 5 bytes):

+----+----+----+----+----+
|type| short_expiration  |
+----+----+----+----+----+

Definition

type :: `Integer`
        length -> 1 byte
        
        purpose -> identifies the message type (see table below)

msg_id :: `Integer`
          length -> 4 bytes

          purpose -> uniquely identifies this message (for some time at least)
                     This is usually a locally-generated random number, but for
                     outgoing tunnel build messages it may be derived from
                     the incoming message. See below.

expiration :: `Date`
           8 bytes
           date this message will expire

short_expiration :: `Integer`
           4 bytes
           date this message will expire (seconds since the epoch)

size :: `Integer`
        length -> 2 bytes
        
        purpose -> length of the payload

chks :: `Integer`
        length -> 1 byte
     
        purpose -> checksum of the payload
                   SHA256 hash truncated to the first byte

data :: Data
        length -> $size bytes
        
        purpose -> actual message contents

Notes

  • When transmitted over SSU, the 16-byte standard header is not used. Only a 1-byte type and a 4-byte expiration in seconds is included. The message id and size are incorporated into various parts of the SSU data packet format. The checksum is not required since errors are caught in decryption.
  • The standard header is also required for I2NP messages contained in other messages and structures (Data, TunnelData, TunnelGateway, and GarlicClove). As of release 0.8.12, to reduce overhead, checksum verification is disabled at some places in the protocol stack. However, for compatibility with older versions, checksum generation is still required. It is a topic for future research to determine points in the protocol stack where the far-end router's version is known and checksum generation can be disabled.

BuildRequestRecord

Description

One Record in a set of multiple records to request the creation of one hop in the tunnel. For more details see the tunnel overview and the tunnel creation specification.

Contents

TunnelId to receive messages on, followed by the Hash of our RouterIdentity. After that the TunnelId and the Hash of the next router's RouterIdentity follow.

Definition

Cleartext:
+----+----+----+----+----+----+----+----+
| receive_tunnel    | our_ident         |
+----+----+----+----+                   +
|                                       |
+                                       +
|                                       |
+                                       +
|                                       |
+                   +----+----+----+----+
|                   | next_tunnel       |
+----+----+----+----+----+----+----+----+
| next_ident                            |
+                                       +
|                                       |
+                                       +
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
| layer_key                             |
+                                       +
|                                       |
+                                       +
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
| iv_key                                |
+                                       +
|                                       |
+                                       +
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
| reply_key                             |
+                                       +
|                                       |
+                                       +
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
| reply_iv                              |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
|flag| request_time      | send_msg_id
+----+----+----+----+----+----+----+----+
     |                                  |
+----+                                  +
|         29 bytes padding              |
+                                       +
|                                       |
+                             +----+----+
|                             |
+----+----+----+----+----+----+


ElGamal encrypted:
+----+----+----+----+----+----+----+----+
| toPeer                                |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
| encrypted data...                     |
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+


ElGamal and AES encrypted:
+----+----+----+----+----+----+----+----+
| encrypted data...                     |
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+

Definition

unencrypted:

receive_tunnel :: `TunnelId`
                  length -> 4 bytes
our_ident :: `Hash`
             length -> 32 bytes

next_tunnel :: `TunnelId`
               length -> 4 bytes

next_ident :: `Hash`
              length -> 32 bytes

layer_key :: `SessionKey`
             length -> 32 bytes

iv_key :: `SessionKey`
          length -> 32 bytes

reply_key :: `SessionKey`
             length -> 32 bytes

reply_iv :: data
            length -> 16 bytes

flag :: `Integer`
        length -> 1 byte

request_time :: `Integer`
                length -> 4 bytes
                Hours since the epoch, i.e. current time / 3600

send_message_id :: `Integer`
                   length -> 4 bytes

padding :: Data
           length -> 29 bytes
           source -> random

total length: 222


ElGamal encrypted:

toPeer :: First 16 bytes of the SHA-256 Hash of the peer's router identity
          length -> 16 bytes

encrypted_data :: ElGamal-2048 encrypted data (see notes)
                  length -> 512

total length: 528


ElGamal and AES encrypted:

encrypted_data :: ElGamal and AES encrypted data
                  length -> 528

total length: 528

Notes

BuildResponseRecord

unencrypted:
+----+----+----+----+----+----+----+----+
|                                       |
+                                       +
|                                       |
+   SHA-256 Hash of following bytes     +
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
| random data...                        |
~                                       ~
|                                       |
+                                  +----+
|                                  |ret |
+----+----+----+----+----+----+----+----+

Definition

unencrypted:
bytes 0-31   : SHA-256 Hash of bytes 32-527
bytes 32-526 : random data
byte  527    : reply

encrypted:
bytes 0-527: AES-encrypted record(note: same size as BuildRequestRecord)

total length: 528

Notes

  • The random data field could, in the future, be used to return congestion or peer connectivity information back to the requestor.
  • See the tunnel creation specification for details on the reply field.

GarlicClove

unencrypted:
+----+----+----+----+----+----+----+----+
| Delivery Instructions                 |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| I2NP Message                          |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
|    Clove ID       |     Expiration
+----+----+----+----+----+----+----+----+
                    | Certificate  |
+----+----+----+----+----+----+----+

Definition

unencrypted:
Delivery Instructions :: as defined below
       Length varies but is typically 1, 33, or 37 bytes

I2NP Message :: Any I2NP Message

Clove ID :: 4 byte `Integer`

Expiration :: `Date` (8 bytes)

Certificate :: Always NULL in the current implementation (3 bytes total, all zeroes)

Notes

  • Cloves are never fragmented. When used in a Garlic Clove, the first bit of the Delivery Instructions flag byte specifies encryption. If this bit is 0, the clove is not encrypted. If 1, the clove is encrypted, and a 32 byte Session Key immediately follows the flag byte. Clove encryption is not fully implemented.
  • See also the garlic routing specification.
  • Maximum length is a function of the total length of all the cloves and the maximum length of the GarlicMessage.
  • In the future, the certificate could possibly be used for a HashCash to "pay" for the routing.
  • The message can be any I2NP message (including a GarlicMessage, although that is not used in practice). The messages used in practice are DataMessage, DeliveryStatusMessage, and DatabaseStoreMessage.
  • The Clove ID is generally set to a random number on transmit and is checked for duplicates on receive (same message ID space as top-level Message IDs)

Garlic Clove Delivery Instructions

This specification is for Delivery Instructions inside Garlic Cloves only. Note that "Delivery Instructions" are also used inside Tunnel Messages, where the format is significantly different. See the Tunnel Message documentation for details. Do NOT use the following specification for Tunnel Message Delivery Instructions!

+----+----+----+----+----+----+----+----+
|flag|                                  |
+----+                                  +
|                                       |
+       Session Key (optional)          +
|                                       |
+                                       +
|                                       |
+    +----+----+----+----+--------------+
|    |                                  |
+----+                                  +
|                                       |
+         To Hash (optional)            +
|                                       |
+                                       +
|                                       |
+    +----+----+----+----+--------------+
|    |  Tunnel ID (opt)  |  Delay (opt)  
+----+----+----+----+----+----+----+----+
     |
+----+

Definition

flag:
       1 byte
       Bit order: 76543210
       bit 7: encrypted? Unimplemented, always 0
                If 1, a 32-byte encryption session key is included
       bits 6-5: delivery type
                0x0 = LOCAL, 0x01 = DESTINATION, 0x02 = ROUTER, 0x03 = TUNNEL
       bit 4: delay included?  Not fully implemented, always 0
                If 1, four delay bytes are included
       bits 3-0: reserved, set to 0 for compatibility with future uses

Session Key:
       32 bytes
       Optional, present encrypt flag bit is set. Unimplemented, never set, never present.

To Hash:
       32 bytes
       Optional, present if delivery type is DESTINATION, ROUTER, or TUNNEL
          If DESTINATION, the SHA256 Hash of the destination
          If ROUTER, the SHA256 Hash of the router
          If TUNNEL, the SHA256 Hash of the gateway router

Tunnel ID:
       4 bytes
       Optional, present if delivery type is TUNNEL
       The destination tunnel ID

Delay:
       4 bytes
       Optional, present if delay included flag is set
       Not fully implemented. A 4 byte integer specifying the delay in seconds.

Total length: Typical length is:
       1 byte for LOCAL delivery;
       33 bytes for ROUTER / DESTINATION delivery;
       37 bytes for TUNNEL delivery

Messages

Message Type
DatabaseStore 1
DatabaseLookup 2
DatabaseSearchReply 3
DeliveryStatus 10
Garlic 11
TunnelData 18
TunnelGateway 19
Data 20
TunnelBuild 21
TunnelBuildReply 22
VariableTunnelBuild 23
VariableTunnelBuildReply 24

DatabaseStore

Description

An unsolicited database store, or the response to a successful Database Lookup Message

Contents

An uncompressed LeaseSet or a compressed RouterInfo

with reply token:
+----+----+----+----+----+----+----+----+
| SHA256 Hash as key                    |
+                                       +
|                                       |
+                                       +
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
|type| reply token       | reply tunnel-
+----+----+----+----+----+----+----+----+
 Id  | SHA256 of the gateway RouterInfo |
+----+                                  +
|                                       |
+                                       +
|                                       |
+                                       +
|                                       |
+    +----+----+----+----+----+----+----+
|    | data ...
+----+-//

with reply token == 0:
+----+----+----+----+----+----+----+----+
| SHA256 Hash as key                    |
+                                       +
|                                       |
+                                       +
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
|type|         0         | data ...
+----+----+----+----+----+-//

Definition

key:
    32 bytes
    SHA256 hash

type:
     1 byte
     type identifier
     mapping:
             0    `RouterInfo`
             1    `LeaseSet`

reply token:
            4 bytes
            If greater than zero, a Delivery Status Message
            is requested with the Message ID set to the value of the Reply Token.
            A floodfill router is also expected to flood the data to the closest floodfill peers
            if the token is greater than zero.

reply tunnelId:
               4 byte `TunnelID`
               only included if reply token > 0
               This is the tunnel ID of the inbound gateway of the tunnel the response should be sent to

reply gateway:
              32 bytes
              Hash of the routerInfo entry to reach the gateway
              only included if reply token > 0
              This is the router hash of the inbound gateway of the tunnel the response should be sent to

data:
     If type == 0, data is a 2-byte integer specifying the number of bytes that follow,
                   followed by a gzip-compressed `RouterInfo`.
     If type == 1, data is an uncompressed `LeaseSet`.

Notes

  • For security, the reply fields are ignored if the message is received down a tunnel.
  • The key is the "real" hash of the RouterIdentity or Destination, NOT the routing key.

DatabaseLookup

Description

A request to look up an item in the network database. The response is either a DatabaseStore or a DatabaseSearchReply.

Contents

+----+----+----+----+----+----+----+----+
| SHA256 hash as the key to look up     |
+                                       +
|                                       |
+                                       +
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
| SHA256 hash of the routerInfo         |
+ who is asking, or the gateway to      +
| send the reply to                     |
+                                       +
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
|flag| reply_tunnelId    |size     |    |
+----+----+----+----+----+----+----+    +
| SHA256 of $key1 to exclude            |
+                                       +
|                                       |
+                                       +
|                                       |
+                                  +----+
|                                  |    |
+----+----+----+----+----+----+----+    +
| SHA256 of $key2 to exclude            |
+                                       +
~                                       ~
+                                  +----+
|                                  |    |
+----+----+----+----+----+----+----+    +
|                                       |
+                                       +
|   Session key if reply encryption     |
+   was requested                       +
|                                       |
+                                  +----+
|                                  |tags|
+----+----+----+----+----+----+----+----+
|                                       |
+                                       +
|   Session tags if reply encryption    |
+   was requested                       +
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+

Definition

key ::
    32 bytes
    SHA256 hash of the object to lookup

from ::
     32 bytes
     if deliveryFlag == 0, the SHA256 hash of the routerInfo entry this request came from (and to which the reply should be sent)
     if deliveryFlag == 1, the SHA256 hash of the reply tunnel gateway (to which the reply should be sent)

flags ::
     1 byte
     bit order: 76543210
     bit 0: deliveryFlag
             0  => send reply directly
             1  => send reply to some tunnel
     bit 1: encryptionFlag
             through release 0.9.5, must be set to 0
             as of release 0.9.6, ignored
             as of release 0.9.7:
             0  => send unencrypted reply
             1  => send AES encrypted reply using enclosed key and tag
     bits 7-2:
             through release 0.9.5, must be set to 0
             as of release 0.9.6, ignored, set to 0 for compatibility with future uses and with older routers

reply_tunnelId ::
               4 byte `TunnelID`
               only included if deliveryFlag == 1
               tunnelId of the tunnel to send the reply to

size ::
     2 byte `Integer`
     valid range: 0-512
     number of peers to exclude from the DatabaseSearchReply Message

excludedPeers ::
              $size SHA256 hashes of 32 bytes each (total $size*32 bytes)
              if the lookup fails, these peers are requested to be excluded from the list in
              the DatabaseSearchReply Message.
              if excludedPeers includes a hash of all zeroes, the request is exploratory, and
              the DatabaseSearchReply Message is requested to list non-floodfill routers only.

reply_key ::
     32 byte `SessionKey`
     only included if encryptionFlag == 1, only as of release 0.9.7

tags ::
     1 byte `Integer`
     valid range: 1-32 (typically 1)
     the number of reply tags that follow
     only included if encryptionFlag == 1, only as of release 0.9.7

reply_tags ::
     one or more 32 byte `SessionTags` (typically one)
     only included if encryptionFlag == 1, only as of release 0.9.7

Notes

  • The key may be for a RouterInfo or LeaseSet, as they are in the same key space, and there is no flag to request only a particular type of data.
  • Encryption flag, reply key, and reply tags as of release 0.9.7.
  • Encrypted replies are only useful when the response is through a tunnel.
  • The number of included tags could be greater than one if alternative DHT lookup strategies (for example, recursive lookups) are implemented.
  • The lookup key and exclude keys are the "real" hashes, NOT routing keys.

DatabaseSearchReply

Description

The response to a failed Database Lookup Message

Contents

A list of router hashes closest to the requested key

+----+----+----+----+----+----+----+----+
| SHA256 hash as query key              |
+                                       +
|                                       |
+                                       +
|                                       |
+                                       +
|                                       |
+----+----+----+----+----+----+----+----+
|num | peer_hash $1                     |
+----+                                  +
|                                       |
+                                       +
|                                       |
+                                       +
|                                       |
+    +----+----+----+----+----+----+----+
|    |                                  |
+----+ $num peer_hashes                 +

+    +----+----+----+----+----+----+----+
|    | from                             |
+----+                                  +
|                                       |
+                                       +
|                                       |
+                                       +
|                                       |
+    +----+----+----+----+----+----+----+
|    |
+----+

Definition

key ::
    32 bytes
    SHA256 of the object being searched

num ::
    1 byte `Integer`
    number of peer hashes that follow, 0-255

peer_hash ($num entries) ::
          32 bytes
          SHA256 of the `RouterIdentity` that the other router thinks is close to the key

from ::
     32 bytes
     SHA256 of the `RouterInfo` of the router this reply was sent from

Notes

  • The 'from' hash is unauthenticated and cannot be trusted.
  • The returned peer hashes are not necessarily closer to the key than the router being queried.
  • Typical number of hashes returned: 3
  • The lookup key, peer hashes, and from hash are "real" hashes, NOT routing keys.

DeliveryStatus

Description

A simple message acknowledgment. Generally created by the message originator, and wrapped in a Garlic Message with the message itself, to be returned by the destination.

Contents

The ID of the delivered message, and the creation or arrival time.

+----+----+----+----+----+----+----+----+----+----+----+----+
|msg_id             |           time_stamp                  |
+----+----+----+----+----+----+----+----+----+----+----+----+

Definition

msg_id ::
       4 bytes
       unique ID of the message we deliver the DeliveryStatus for (see common I2NP header for details)

time_stamp :: Date
             8 bytes
             time the message was successfully created or delivered

Notes

  • It appears that the time stamp is always set by the creator to the current time. However there are several uses of this in the code, and more may be added in the future.
  • This message is also used as a session established confirmation in SSU. In this case, the message ID is set to a random number, and the "arrival time" is set to the current network-wide ID, which is 2 (i.e. 0x0000000000000002).

Garlic

Description

Used to wrap multiple encrypted I2NP Messages

Contents

When decrypted, a series of Garlic Cloves.

encrypted:
+----+----+----+----+----+----+----+----+
|      length       | data              |
+----+----+----+----+                   +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+


unencrypted data:
+----+----+----+----+----+----+----+----+
|num |  clove 1                         |
+----+                                  +
|                                       |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
|         clove 2 ...                   |
~                                       ~
~                                       ~
|                                       |
+----+----+----+----+----+----+----+----+
| Certificate  |   Message_ID      |     
+----+----+----+----+----+----+----+----+
          Expiration               |
+----+----+----+----+----+----+----+

Definition

Encrypted:

length ::
       4 byte Integer
       number of bytes that follow 0 - 64 KB

data ::
     $length bytes
     ElGamal encrypted data


Unencrypted data:

num ::
     1 byte Integer number of `GarlicCloves` to follow

clove ::  a `GarlicClove`

Certificate :: always NULL in the current implementation (3 bytes total, all zeroes)

Message_ID :: 4 byte `Integer`

Expiration :: `Date` (8 bytes)

Notes

  • When unencrypted, data contains one or more Garlic Cloves.
  • The AES encrypted block is padded to a minimum of 128 bytes; with the 32-byte Session Tag the minimum size of the encrypted message is 160 bytes; with the 4 length bytes the minimum size of the Garlic Message is 164 bytes.
  • Actual max length is less than 64 KB; see the I2NP Overview.
  • See also the ElGamal/AES specification.
  • See also the garlic routing specification.
  • The 128 byte minimum size of the AES encrypted block is not currently configurable, however the minimum size of a DataMessage in a GarlicClove in a GarlicMessage, with overhead, is 128 bytes anyway. A configurable option to increase the minimum size may be added in the future.
  • The message ID is generally set to a random number on transmit and appears to be ignored on receive.
  • In the future, the certificate could possibly be used for a HashCash to "pay" for the routing.

TunnelData

Description

A message sent from a tunnel's gateway or participant to the next participant or endpoint. The data is of fixed length, containing I2NP messages that are fragmented, batched, padded, and encrypted.

Contents

+----+----+----+----+----+----+----+----+
|     tunnnelID     | data              |
+----+----+----+----+                   |
|                                       |
~                                       ~
~                                       ~
|                                       |
+                   +----+----+----+----+
|                   |
+----+----+----+----+

Definition

tunnelId ::
         4 byte `TunnelID`
         identifies the tunnel this message is directed at

data ::
     1024 bytes
     payload data.. fixed to 1024 bytes

Notes

TunnelGateway

Description

Wraps another I2NP message to be sent into a tunnel at the tunnel's inbound gateway.

Contents

+----+----+----+----+----+----+----+-//
| tunnelId          | length  | data...
+----+----+----+----+----+----+----+-//

Definition

tunnelId ::
         4 byte `TunnelID`
         identifies the tunnel this message is directed at

length ::
       2 byte `Integer`
       length of the payload

data ::
     $length bytes
     actual payload of this message

Notes

  • The payload is an I2NP message with a standard 16-byte header.

Data

Description

Used by Garlic Messages and Garlic Cloves to wrap arbitrary data.

Contents

A length Integer, followed by opaque data.

+----+----+----+----+----+-//-+
| length            | data... |
+----+----+----+----+----+-//-+

Definition

length ::
       4 bytes
       length of the payload

data ::
     $length bytes
     actual payload of this message

TunnelBuild

+----+----+----+----+----+----+----+----+
| Record 0 ...                          |

|                                       |
+----+----+----+----+----+----+----+----+
| Record 1 ...                          |

.....
+----+----+----+----+----+----+----+----+
| Record 7 ...                          |

|                                       |
+----+----+----+----+----+----+----+----+

Definition

Just 8 `BuildRequestRecords` attached together
record size: 528 bytes
total size: 8*528 = 4224 bytes

Notes

TunnelBuildReply

same format as TunnelBuild message, with BuildResponseRecords

Notes

VariableTunnelBuild

+----+----+----+----+----+----+----+----+
|num | BuildRequestRecords...
+----+----+----+----+----+----+----+----+

Definition

Same format as TunnelBuildMessage, except for the addition of an "num" field in front and $num number of Build Request Records instead of 8

num ::
       1 byte `Integer`
       Valid values: 1-8

record size: 528 bytes
total size: 1 + $num*528

Notes

  • This message was introduced in router version 0.7.12, and may not be sent to tunnel participants earlier than that version.
  • See also the tunnel creation specification.
  • The I2NP message ID for this message must be set according to the tunnel creation specification.

VariableTunnelBuildReply

+----+----+----+----+----+----+----+----+
|num | BuildResponseRecords...
+----+----+----+----+----+----+----+----+

Definition

Same format as VariableTunnelBuild message, with Build Response Records.

Notes

  • This message was introduced in router version 0.7.12, and may not be sent to tunnel participants earlier than that version.
  • See also the tunnel creation specification.
  • The I2NP message ID for this message must be set according to the tunnel creation specification.