1) Online DPI

Online DPI inspecting all flows in real-time. Connections may be blocked or otherwise tampered with. Connection data or metadata may be identified and stored for offline analysis. The online DPI does not have access to the I2P network database. The online DPI has only limited real-time computational capability, including length calculation, field inspection, and simple calculations such as XOR. The online DPI does have the capability of fast real-time cryptographic functions such as AES, AEAD, and hashing, but these would be too expensive to apply to most or all flows. Any application of these cryptographic operations would apply only to flows on IP/Port combinations previously identified by offline analysis. The online DPI does not have the capability of high-overhead cryptographic functions such as DH or elligator2. The online DPI is not designed specifically to detect I2P, although it may have limited classification rules for that purpose.

It is a goal to prevent protocol identification by an online DPI.

The notion of online or "straightforward" DPI is here taken to include the following adversary capabilities:

1. The ability to inspect all data sent or received by the target.
2. The ability to perform operations on the observed data, such as applying block ciphers or hash functions.
3. The ability to store and compare with previously sent messages.
4. The ability to modify, delay or fragment packets.

However, the online DPI is assumed to have the following restrictions:

5. The inability to map IP addresses to router hashes. While this is trivial with real-time access to the network database, it would require a DPI system specifically designed to target I2P.
6. The inability to use timing information to detect the protocol.
7. Generally speaking, the online DPI toolbox does not contain any built-in tools that are specifically designed for I2P detection. This includes creating "honeypots", which would for example include nonrandom padding in their messages. Note that this does not exclude machine learning systems or highly configurable DPI tools as long as they meet the other requirements.

To counter payload analysis, it is ensured that all messages are indistinguishable from random. This also requires their length to be random, which is more complicated than just adding random padding. In fact, in Appendix A, the authors argue that a naive (i.e. uniform) padding scheme does not resolve the problem. Appendix A therefore proposes to include either random delays or to develop an alternate padding scheme that can provide reasonable protection for the proposed attack.

To protect against the sixth entry above, implementations should include random delays in the protocol. Such techniques are not covered by this proposal, but they could also resolve the padding length issues. In summary, the proposal provides good protection against payload analysis (when the considerations in Appendix A are taken into account), but only limited protection against flow analysis.

2) Offline DPI

Offline DPI inspecting data stored by the online DPI for later analysis. The offline DPI may be designed specifically to detect I2P. The offline DPI does have real-time access to the I2P network database. The offline DPI does have access to this and other I2P specifications. The offline DPI has unlimited computational capability, including all cryptographic functions defined in this specification.

The offline DPI does not have the ability to block existing connections. The offline DPI does have the capability to do near-realtime (within minutes of setup) sending to host/port of parties, for example TCP RST. The offline DPI does have the capability to do near-realtime (within minutes of setup) replay of previous messages (modified or not) for "probing" or other reasons.

It is not a goal to prevent protocol identification by an offline DPI. All decoding of obfuscated data in the first two messages, which is implemented by I2P routers, may also be implemented by the offline DPI.

It is a goal to reject attempted connections using replay of previous messages.

Future work

• Consider the behavior of the protocol when packets are dropped or reordered by an attacker. Recent interesting work in this area can be found in [IACR-1150].
• Provide a more accurate classification of DPI systems, taking into account the existing literature related to the subject.
• Discuss the formal security of the proposed protocol, ideally taking into account the DPI attacker model.

ChaCha20/Poly1305

Encrypted and authenticated data format.

Inputs to the encryption/decryption functions:

k :: 32 byte cipher key, as generated from KDF

nonce :: Counter-based nonce, 12 bytes.
         Starts at 0 and incremented for each message.
         First four bytes are always zero.
         Last eight bytes are the counter, little-endian encoded.
         Maximum value is 2**64 - 2.
         Connection must be dropped and restarted after
         it reaches that value.
         The value 2**64 - 1 must never be sent.

ad :: In handshake phase:
      Associated data, 32 bytes.
      The SHA256 hash of all preceding data.
      In data phase:
      Zero bytes

data :: Plaintext data, 0 or more bytes

Output of the encryption function, input to the decryption function:

+----+----+----+----+----+----+----+----+
|Obfs Len |                             |
+----+----+                             +
|       ChaCha20 encrypted data         |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+
|  Poly1305 Message Authentication Code |
+              (MAC)                    +
|             16 bytes                  |
+----+----+----+----+----+----+----+----+

Obfs Len :: Length of (encrypted data + MAC) to follow, 16 - 65535
            Obfuscation using SipHash (see below)
            Not used in message 1 or 2, or message 3 part 1, where the length is fixed
            Not used in message 3 part 1, as the length is specified in message 1

encrypted data :: Same size as plaintext data, 0 - 65519 bytes

MAC :: Poly1305 message authentication code, 16 bytes

For ChaCha20, what is described here corresponds to [RFC-7539], which is also used similarly in TLS [RFC-7905].

Notes

• Since ChaCha20 is a stream cipher, plaintexts need not be padded. Additional keystream bytes are discarded.
• The key for the cipher (256 bits) is agreed upon by means of the SHA256 KDF. The details of the KDF for each message are in separate sections below.
• ChaChaPoly frames for messages 1, 2, and the first part of message 3, are of known size. Starting with the second part of message 3, frames are of variable size. The message 3 part 1 size is specified in message 1. Starting with the data phase, frames are prepended with a two-byte length obfuscated with SipHash as in obfs4.
• Padding is outside the authenticated data frame for messages 1 and 2. The padding is used in the KDF for the next message so tampering will be detected. Starting in message 3, padding is inside the authenticated data frame.

AEAD Error Handling

• In messages 1, 2, and message 3 parts 1 and 2, the AEAD message size is known in advance. On an AEAD authentication failure, recipient must halt further message processing and close the connection without responding. This should be an abnormal close (TCP RST).
• For probing resistance, in message 1, after an AEAD failure, Bob should set a random timeout (range TBD) and then read a random number of bytes (range TBD) before closing the socket. Bob should maintain a blacklist of IPs with repeated failures.
• In the data phase, the AEAD message size is "encrypted" (obfuscated) with SipHash. Care must be taken to avoid creating a decryption oracle. On a data phase AEAD authentication failure, the recipient should set a random timeout (range TBD) and then read a random number of bytes (range TBD). After the read, or on read timeout, the recipient should send a payload with a termination block containing an "AEAD failure" reason code, and close the connection.
• Take the same error action for an invalid length field value in the data phase.

Notes

• When the published address is "NTCP", Bob supports both NTCP and NTCP2 on the same port. For compatibility, when initiating a connection to an address published as "NTCP", Alice must limit the maximum size of this message, including padding, to 287 bytes or less. This facilitates automatic protocol identification by Bob. When published as "NTCP2", there is no size restriction. See the Published Addresses and Version Detection sections below.
• The unique X value in the initial AES block ensure that the ciphertext is different for every session.
• Bob must reject connections where the timestamp value is too far off from the current time. Call the maximum delta time "D". Bob must maintain a local cache of previously-used handshake values and reject duplicates, to prevent replay attacks. Values in the cache must have a lifetime of at least 2*D. The cache values are implementation-dependent, however the 32-byte X value (or its encrypted equivalent) may be used.
• Diffie-Hellman ephemeral keys may never be reused, to prevent cryptographic attacks, and reuse will be rejected as a replay attack.
• The "KE" and "auth" options must be compatible, i.e. the shared secret K must be of the appropriate size. If more "auth" options are added, this could implicitly change the meaning of the "KE" flag to use a different KDF or a different truncation size.
• Bob must validate that Alice's ephemeral key is a valid point on the curve here.
• Padding should be limited to a reasonable amount. Bob may reject connections with excessive padding. Bob will specify his padding options in message 2. Min/max guidelines TBD. Random size from 0 to 31 bytes minimum? (Distribution to be determined, see Appendix A.)
• On any error, including AEAD, DH, timestamp, apparent replay, or key validation failure, Bob must halt further message processing and close the connection without responding. This should be an abnormal close (TCP RST). For probing resistance, after an AEAD failure, Bob should set a random timeout (range TBD) and then read a random number of bytes (range TBD), before closing the socket.
• DoS Mitigation: DH is a relatively expensive operation. As with the previous NTCP protocol, routers should take all necessary measures to prevent CPU or connection exhaustion. Place limits on maximum active connections and maximum connection setups in progress. Enforce read timeouts (both per-read and total for "slowloris"). Limit repeated or simultaneous connections from the same source. Maintain blacklists for sources that repeatedly fail. Do not respond to AEAD failure.
• To facilitate rapid version detection and handshaking, implementations must ensure that Alice buffers and then flushes the entire contents of the first message at once, including the padding. This increases the likelihood that the data will be contained in a single TCP packet (unless segmented by the OS or middleboxes), and received all at once by Bob. Additionally, implementations must ensure that Bob buffers and then flushes the entire contents of the second message at once, including the padding. and that Bob buffers and then flushes the entire contents of the third message at once. This is also for efficiency and to ensure the effectiveness of the random padding.
• "ver" field: The overall Noise protocol, extensions, and NTCP protocol including payload specifications, indicating NTCP2. This field may be used to indicate support for future changes.
• Message 3 part 2 length: This is the size of the second AEAD frame (including 16-byte MAC) containing Alice's Router Info and optional padding that will be sent in the SessionConfirmed message. As routers periodically regenerate and republish their Router Info, the size of the current Router Info may change before message 3 is sent. Implementations must choose one of two strategies: a) save the current Router Info to be sent in message 3, so the size is known, and optionally add room for padding; b) increase the specified size enough to allow for possible increase in the Router Info size, and always add padding when message 3 is actually sent. In either case, the "m3p2len" length included in message 1 must be exactly the size of that frame when sent in message 3.
• Bob must fail the connection if any incoming data remains after validating message 1 and reading in the padding. There should be no extra data from Alice, as Bob has not responded with message 2 yet.
• The network ID field is used to quickly identify cross-network connections. If this field is nonzero, and does not match Bob's network ID, Bob should disconnect and block future connections. As of 0.9.42. See proposal 147 for more information.

Notes

• Alice must validate that Bob's ephemeral key is a valid point on the curve here.
• Padding should be limited to a reasonable amount. Alice may reject connections with excessive padding. Alice will specify her padding options in message 3. Min/max guidelines TBD. Random size from 0 to 31 bytes minimum? (Distribution to be determined, see Appendix A.)
• On any error, including AEAD, DH, timestamp, apparent replay, or key validation failure, Alice must halt further message processing and close the connection without responding. This should be an abnormal close (TCP RST).
• To facilitate rapid handshaking, implementations must ensure that Bob buffers and then flushes the entire contents of the first message at once, including the padding. This increases the likelihood that the data will be contained in a single TCP packet (unless segmented by the OS or middleboxes), and received all at once by Alice. This is also for efficiency and to ensure the effectiveness of the random padding.
• Alice must fail the connection if any incoming data remains after validating message 2 and reading in the padding. There should be no extra data from Bob, as Alice has not responded with message 3 yet.

Options block: Note: All fields are big-endian.

+----+----+----+----+----+----+----+----+
| Rsvd(0) | padLen  |   Reserved (0)    |
+----+----+----+----+----+----+----+----+
|        tsB        |   Reserved (0)    |
+----+----+----+----+----+----+----+----+

Reserved :: 10 bytes total, set to 0 for compatibility with future options

padLen :: 2 bytes, big endian, length of the padding, 0 or more
          Min/max guidelines TBD. Random size from 0 to 31 bytes minimum?
          (Distribution to be determined, see Appendix A.)

tsB :: 4 bytes, big endian, Unix timestamp, unsigned seconds.
       Wraps around in 2106

Notes

• Alice must reject connections where the timestamp value is too far off from the current time. Call the maximum delta time "D". Alice must maintain a local cache of previously-used handshake values and reject duplicates, to prevent replay attacks. Values in the cache must have a lifetime of at least 2*D. The cache values are implementation-dependent, however the 32-byte Y value (or its encrypted equivalent) may be used.

Issues

• Include min/max padding options here?

Notes

• Bob must perform the usual Router Info validation. Ensure the signature type is supported, verify the signature, verify the timestamp is within bounds, and any other checks necessary.
• Bob must verify that Alice's static key received in the first frame matches the static key in the Router Info. Bob must first search the Router Info for a NTCP or NTCP2 Router Address with a matching version (v) option. See Published Router Info and Unpublished Router Info sections below.
• If Bob has an older version of Alice's RouterInfo in his netdb, verify that the static key in the router info is the same in both, if present, and if the older version is less than XXX old (see key rotate time below)
• Bob must validate that Alice's static key is a valid point on the curve here.
• Options should be included, to specify padding parameters.
• On any error, including AEAD, RI, DH, timestamp, or key validation failure, Bob must halt further message processing and close the connection without responding. This should be an abnormal close (TCP RST).
• To facilitate rapid handshaking, implementations must ensure that Alice buffers and then flushes the entire contents of the third message at once, including both AEAD frames. This increases the likelihood that the data will be contained in a single TCP packet (unless segmented by the OS or middleboxes), and received all at once by Bob. This is also for efficiency and to ensure the effectiveness of the random padding.
• Message 3 part 2 frame length: The length of this frame (including MAC) is sent by Alice in message 1. See that message for important notes on allowing enough room for padding.
• Message 3 part 2 frame content: This format of this frame is the same as the format of data phase frames, except that the length of the frame is sent by Alice in message 1. See below for the data phase frame format. The frame must contain 1 to 3 blocks in the following order: 1) Alice's Router Info block (required) 2) Options block (optional) 3) Padding block (optional) This frame must never contain any other block type.
• Message 3 part 2 padding is not required if Alice appends a data phase frame (optionally containing padding) to the end of message 3 and sends both at once, as it will appear as one big stream of bytes to an observer. As Alice will generally, but not always, have an I2NP message to send to Bob (that's why she connected to him), this is the recommended implementation, for efficiency and to ensure the effectiveness of the random padding.
• Total length of both Message 3 AEAD frames (parts 1 and 2) is 65535 bytes; part 1 is 48 bytes so part 2 max frame length is 65487; part 2 max plaintext length excluding MAC is 65471.

Notes

• For efficiency and to minimize identification of the length field, implementations must ensure that the sender buffers and then flushes the entire contents of data messages at once, including the length field and the AEAD frame. This increases the likelihood that the data will be contained in a single TCP packet (unless segmented by the OS or middleboxes), and received all at once the other party. This is also for efficiency and to ensure the effectiveness of the random padding.
• The router may choose to terminate the session on AEAD error, or may continue to attempt communications. If continuing, the router should terminate after repeated errors.

SipHash obfuscated length

Reference: [SipHash]

Once both sides have completed the handshake, they transfer payloads that are then encrypted and authenticated in ChaChaPoly "frames".

Each frame is preceded by a two-byte length, big endian. This length specifies the number of encrypted frame bytes to follow, including the MAC. To avoid transmitting identifiable length fields in stream, the frame length is obfuscated by XORing a mask derived from SipHash, as initialized from the data phase KDF. Note that the two directions have unique SipHash keys and IVs from the KDF.

      sipk1, sipk2 = The SipHash keys from the KDF.  (two 8-byte long integers)
    IV[0] = sipiv = The SipHash IV from the KDF. (8 bytes)
    length is big endian.
    For each frame:
      IV[n] = SipHash-2-4(sipk1, sipk2, IV[n-1])
      Mask[n] = First 2 bytes of IV[n]
      obfuscatedLength = length ^ Mask[n]

    The first length output will be XORed with with IV[1].

The receiver has the identical SipHash keys and IV. Decoding the length is done by deriving the mask used to obfsucate the length and XORing the truncated digest to obtain the length of the frame. The frame length is the total length of the encrypted frame including the MAC.

Notes

• If you use a SipHash library function that returns an unsigned long integer, use the least significant two bytes as the Mask. Convert the long integer to the next IV as little endian.

Raw contents

+----+----+----+----+----+----+----+----+
|obf size |                             |
+----+----+                             +
|                                       |
+   ChaChaPoly frame                    +
|   Encrypted and authenticated         |
+   key is k_ab for Alice to Bob        +
|   key is k_ba for Bob to Alice        |
+   as defined in KDF for data phase    +
|   n starts at 0 and increments        |
+   for each frame in that direction    +
|   no associated data                  |
+   16 bytes minimum                    +
|                                       |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+

obf size :: 2 bytes length obfuscated with SipHash
            when de-obfuscated: 16 - 65535

Minimum size including length field is 18 bytes.
Maximum size including length field is 65537 bytes.
Obfuscated length is 2 bytes.
Maximum ChaChaPoly frame is 65535 bytes.

Unencrypted data

There are zero or more blocks in the encrypted frame. Each block contains a one-byte identifier, a two-byte length, and zero or more bytes of data.

For extensibility, receivers must ignore blocks with unknown identifiers, and treat them as padding.

Encrypted data is 65535 bytes max, including a 16-byte authentication header, so the max unencrypted data is 65519 bytes.

(Poly1305 auth tag not shown):

+----+----+----+----+----+----+----+----+
|blk |  size   |       data             |
+----+----+----+                        +
|                                       |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+
|blk |  size   |       data             |
+----+----+----+                        +
|                                       |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+
~               .   .   .               ~

blk :: 1 byte
       0 for datetime
       1 for options
       2 for RouterInfo
       3 for I2NP message
       4 for termination
       224-253 reserved for experimental features
       254 for padding
       255 reserved for future extension
size :: 2 bytes, big endian, size of data to follow, 0 - 65516
data :: the data

Maximum ChaChaPoly frame is 65535 bytes.
Poly1305 tag is 16 bytes
Maximum total block size is 65519 bytes
Maximum single block size is 65519 bytes
Block type is 1 byte
Block length is 2 bytes
Maximum single block data size is 65516 bytes.

Block Ordering Rules

In the handshake message 3 part 2, order must be: RouterInfo, followed by Options if present, followed by Padding if present. No other blocks are allowed.

In the data phase, order is unspecified, except for the following requirements: Padding, if present, must be the last block. Termination, if present, must be the last block except for Padding.

There may be multiple I2NP blocks in a single frame. Multiple Padding blocks are not allowed in a single frame. Other block types probably won't have multiple blocks in a single frame, but it is not prohibited.

DateTime

Special case for time synchronization:

+----+----+----+----+----+----+----+
| 0  |    4    |     timestamp     |
+----+----+----+----+----+----+----+

blk :: 0
size :: 2 bytes, big endian, value = 4
timestamp :: Unix timestamp, unsigned seconds.
             Wraps around in 2106

Options

Pass updated options. Options include: Min and max padding.

Options block will be variable length.

+----+----+----+----+----+----+----+----+
| 1  |  size   |tmin|tmax|rmin|rmax|tdmy|
+----+----+----+----+----+----+----+----+
|tdmy|  rdmy   |  tdelay |  rdelay |    |
~----+----+----+----+----+----+----+    ~
|              more_options             |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+

blk :: 1
size :: 2 bytes, big endian, size of options to follow, 12 bytes minimum

tmin, tmax, rmin, rmax :: requested padding limits
    tmin and rmin are for desired resistance to traffic analysis.
    tmax and rmax are for bandwidth limits.
    tmin and tmax are the transmit limits for the router sending this options block.
    rmin and rmax are the receive limits for the router sending this options block.
    Each is a 4.4 fixed-point float representing 0 to 15.9375
    (or think of it as an unsigned 8-bit integer divided by 16.0).
    This is the ratio of padding to data. Examples:
    Value of 0x00 means no padding
    Value of 0x01 means add 6 percent padding
    Value of 0x10 means add 100 percent padding
    Value of 0x80 means add 800 percent (8x) padding
    Alice and Bob will negotiate the minimum and maximum in each direction.
    These are guidelines, there is no enforcement.
    Sender should honor receiver's maximum.
    Sender may or may not honor receiver's minimum, within bandwidth constraints.

tdmy: Max dummy traffic willing to send, 2 bytes big endian, bytes/sec average
rdmy: Requested dummy traffic, 2 bytes big endian, bytes/sec average
tdelay: Max intra-message delay willing to insert, 2 bytes big endian, msec average
rdelay: Requested intra-message delay, 2 bytes big endian, msec average

Padding distribution specified as additional parameters?
Random delay specified as additional parameters?

more_options :: Format TBD

Options Issues

• Options format is TBD.
• Options negotiation is TBD.

RouterInfo

Pass Alice's RouterInfo to Bob. Used in handshake message 3 part 2. Pass Alice's RouterInfo to Bob, or Bob's to Alice. Used optionally in the data phase.

+----+----+----+----+----+----+----+----+
| 2  |  size   |flg |    RouterInfo     |
+----+----+----+----+                   +
| (Alice RI in handshake msg 3 part 2)  |
~ (Alice, Bob, or third-party           ~
|  RI in data phase)                    |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+

blk :: 2
size :: 2 bytes, big endian, size of flag + router info to follow
flg :: 1 byte flags
       bit order: 76543210
       bit 0: 0 for local store, 1 for flood request
       bits 7-1: Unused, set to 0 for future compatibility
routerinfo :: Alice's or Bob's RouterInfo

Notes

• When used in the data phase, receiver (Alice or Bob) shall validate that it's the same Router Hash as originally sent (for Alice) or sent to (for Bob). Then, treat it as a local I2NP DatabaseStore Message. Validate signature, validate more recent timestamp, and store in the local netdb. If the flag bit 0 is 1, and the receiving party is floodfill, treat it as a DatabaseStore Message with a nonzero reply token, and flood it to the nearest floodfills.
• The Router Info is NOT compressed with gzip (unlike in a DatabaseStore Message, where it is)
• Flooding must not be requested unless there are published RouterAddresses in the RouterInfo. The receiving router must not flood the RouterInfo unless there are published RouterAddresses in it.
• Implementers must ensure that when reading a block, malformed or malicious data will not cause reads to overrun into the next block.
• This protocol does not provide an acknowledgement that the RouterInfo was received, stored, or flooded (either in the handshake or data phase). If acknowledgement is desired, and the receiver is floodfill, the sender should instead send a standard I2NP DatabaseStoreMessage with a reply token.

Issues

• Could also be used in data phase, instead of a I2NP DatabaseStoreMessage. For example, Bob could use it to start off the data phase.
• Is it allowed for this to contain the RI for routers other than the originator, as a general replacement for DatabaseStoreMessages, e.g. for flooding by floodfills?

I2NP Message

An single I2NP message with a modified header. I2NP messages may not be fragmented across blocks or across ChaChaPoly frames.

This uses the first 9 bytes from the standard NTCP I2NP header, and removes the last 7 bytes of the header, as follows: truncate the expiration from 8 to 4 bytes, remove the 2 byte length (use the block size - 9), and remove the one-byte SHA256 checksum.

+----+----+----+----+----+----+----+----+
| 3  |  size   |type|    msg id         |
+----+----+----+----+----+----+----+----+
|   short exp       |     message       |
+----+----+----+----+                   +
|                                       |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+

blk :: 3
size :: 2 bytes, big endian, size of type + msg id + exp + message to follow
        I2NP message body size is (size - 9).
type :: 1 byte, I2NP msg type, see I2NP spec
msg id :: 4 bytes, big endian, I2NP message ID
short exp :: 4 bytes, big endian, I2NP message expiration, Unix timestamp, unsigned seconds.
             Wraps around in 2106
message :: I2NP message body

Notes

• Implementers must ensure that when reading a block, malformed or malicious data will not cause reads to overrun into the next block.

Termination

Noise recommends an explicit termination message. Original NTCP doesn't have one. Drop the connection. This must be the last non-padding block in the frame.

+----+----+----+----+----+----+----+----+
| 4  |  size   |    valid data frames   |
+----+----+----+----+----+----+----+----+
    received   | rsn|     addl data     |
+----+----+----+----+                   +
~               .   .   .               ~
+----+----+----+----+----+----+----+----+

blk :: 4
size :: 2 bytes, big endian, value = 9 or more
valid received :: The number of valid AEAD data phase frames received
                              (current receive nonce value)
                              0 if error occurs in handshake phase
                              8 bytes, big endian
rsn :: reason, 1 byte:
       0: normal close or unspecified
       1: termination received
       2: idle timeout
       3: router shutdown
       4: data phase AEAD failure
       5: incompatible options
       6: incompatible signature type
       7: clock skew
       8: padding violation
       9: AEAD framing error
       10: payload format error
       11: message 1 error
       12: message 2 error
       13: message 3 error
       14: intra-frame read timeout
       15: RI signature verification fail
       16: s parameter missing, invalid, or mismatched in RouterInfo
       17: banned
addl data :: optional, 0 or more bytes, for future expansion, debugging,
             or reason text.
             Format unspecified and may vary based on reason code.

Notes

Not all reasons may actually be used, implementation dependent. Handshake failures will generally result in a close with TCP RST instead. See notes in handshake message sections above. Additional reasons listed are for consistency, logging, debugging, or if policy changes.

Padding

This is for padding inside AEAD frames. Padding for messages 1 and 2 are outside AEAD frames. All padding for message 3 and the data phase are inside AEAD frames.

Padding inside AEAD should roughly adhere to the negotiated parameters. Bob sent his requested tx/rx min/max parameters in message 2. Alice sent her requested tx/rx min/max parameters in message 3. Updated options may be sent during the data phase. See options block information above.

If present, this must be the last block in the frame.

+----+----+----+----+----+----+----+----+
|254 |  size   |      padding           |
+----+----+----+                        +
|                                       |
~               .   .   .               ~
|                                       |
+----+----+----+----+----+----+----+----+

blk :: 254
size :: 2 bytes, big endian, size of padding to follow
padding :: random data

Notes

• Padding strategies TBD.
• Minimum padding TBD.
• Padding-only frames are allowed.
• Padding defaults TBD.
• See options block for padding parameter negotiation
• See options block for min/max padding parameters
• Noise limits messages to 64KB. If more padding is necessary, send multiple frames.
• Router response on violation of negotiated padding is implementation-dependent.

Other block types

Implementations should ignore unknown block types for forward compatibility, except in message 3 part 2, where unknown blocks are not allowed.

Future work

• The padding length is either to be decided on a per-message basis and estimates of the length distribution, or random delays should be added. These countermeasures are to be included to resist DPI, as message sizes would otherwise reveal that I2P traffic is being carried by the transport protocol. The exact padding scheme is an area of future work, Appendix A provides more information on the topic.

Identity Hiding

Deniability is not a goal. See overview above.

Each pattern is assigned properties describing the confidentiality supplied to the initiator's static public key, and to the responder's static public key. The underlying assumptions are that ephemeral private keys are secure, and that parties abort the handshake if they receive a static public key from the other party which they don't trust.

This section only considers identity leakage through static public key fields in handshakes. Of course, the identities of Noise participants might be exposed through other means, including payload fields, traffic analysis, or metadata such as IP addresses.

Alice: (8) Encrypted with forward secrecy to an authenticated party.

Bob: (3) Not transmitted, but a passive attacker can check candidates for the responder's private key and determine whether the candidate is correct.

Bob publishes his static public key in the netdb. Alice may or may not?

Issues

• If Bob changes his static key, could fallback to a "XX" pattern?