Note

Network deployment and testing in progress. Subject to minor revisions.

Overview

Design

Use the existing MAX_PACKET_SIZE_INCLUDED option and MTU negotiation. Streaming continues to use the minimum of the sent and received MTU. The default remains 1730 for all connections, no matter what keys are used.

Implementations are encouraged to include the MAX_PACKET_SIZE_INCLUDED option in all SYN packets, in both directions, although this is not a requirement.

If a destination is ECIES-only, use the higher value (either as Alice or Bob). If a destination is dual-key, behavior may vary:

If dual-key client is outside the router (in an external application), it may not "know" the key being used at the far-end, and Alice may request a higher value in the SYN, while the max data in the SYN remains 1730.

If dual-key client is inside the router, the information of what key is being used may or may not be known to the client. The leaseset may not have been fetched yet, or the internal API interfaces may not easily make that information available to the client. If the information is available, Alice may use the higher value; otherwise, Alice must use the standard value of 1730 until negotiated.

A dual-key client as Bob may send the higher value in response, even if no value or a value of 1730 was received from Alice; however, there is no provision for negotiating upwards in streaming, so the MTU should remain at 1730.

As noted in [STREAMING-OPTIONS], the data in the SYN packets sent from Alice to Bob may exceed Bob's MTU. This is a weakness in the streaming protocol. Therefore, dual-key clients must limit the data in the sent SYN packets to 1730 bytes, while sending a higher MTU option. Once the higher MTU is received from Bob, Alice may increase the actual maximum payload sent.

Specification

Add the following changes and clarifications to the MTU Selection and Negotiation section of [STREAMING-OPTIONS]. No changes to [STREAMING-SPEC].

The default value of the option i2p.streaming.maxMessageSize remains 1730 for all connections, no matter what keys are used. Clients must use the minimum of the sent and received MTU, as usual.

There are four related MTU contants and variables:

• DEFAULT_MTU: 1730, unchanged, for all connections
• i2cp.streaming.maxMessageSize: default 1730 or 1812, may be changed by configuration
• ALICE_SYN_MAX_DATA: The maximum data that Alice may include in a SYN packet
• negotiated_mtu: The minimum of Alice's and Bob's MTU, to be used as the max data size in the SYN ACK from Bob to Alice, and in all subsequent packets sent in both directions

There are five cases to consider:

Justification

See [CALCULATION] for why the current value is 1730. See [ECIES] for why the ECIES overhead is 82 bytes less than ElGamal.

Implementation Notes

If streaming is creating messages of optimal size, it's very important that the ECIES-Ratchet layer does not pad beyond that size.

The optimal Garlic Message size to fit into two tunnel messages, including the 16 byte Garlic Message I2NP header, 4 byte Garlic Message Length, 8 byte ES tag, and 16 byte MAC, is 1956 bytes.

A recommended padding algorithm in ECIES is as follows:

• If the total length of the Garlic Message would be 1954-1956 bytes, do not add a padding block (no room)
• If the total length of the Garlic Message would be 1938-1953 bytes, add a padding block to pad to exactly 1956 bytes.
• Otherwise, pad as usual, for example with a random amount 0-15 bytes.

Similar strategies could be used at the optimal one-tunnel-message size (964) and three-tunnel-message size (2952), although these sizes should be rare in practice.

Issues

The 1812 value is preliminary. To be confirmed and possibly adjusted.

Migration

No backward compatibility issues. This is an existing option and MTU negotiation is already part of the specification.

Older ECIES destinations will support 1730. Any client receiving a higher value will respond with 1730, and the far-end will negotiate downward, as usual.

References