Overview

This proposal covers two improvements for improving network performance:

• Delegating IBGW selection to the OBEP by providing it with a list of alternatives instead of a single option.
• Enabling multicast packet routing at the OBEP.

Motivation

In the direct connection case, the idea is to reduce connection congestion, by giving the OBEP flexibility in how it connects to IBGWs. The ability to specify multiple tunnels also enables us to implement multicast at the OBEP (by delivering the message to all specified tunnels).

An alternative to the delegation part of this proposal would be to send through a [LeaseSet] hash, similar to the existing ability to specify a target [RouterIdentity] hash. This would result in a smaller message and a potentially newer LeaseSet. However:

1. It would force the OBEP to do a lookup
2. The LeaseSet may not be published to a floodfill, so the lookup would fail.
3. The LeaseSet may be encrypted, so the OBEP couldn't get the leases.
4. Specifying a LeaseSet reveals to the OBEP the [Destination] of the message, which they could otherwise only discover by scraping all the LeaseSets in the network and looking for a Lease match.

Design

The originator (OBGW) would place some (all?) of the target [Leases] in the delivery instructions [TUNNEL-DELIVERY] instead of picking just one.

The OBEP would select one of those to deliver to. The OBEP would select, if available, one that it is already connected to, or already knows about. This would make the OBEP-IBGW path faster and more reliable, and reduce overall network connections.

We have one unused delivery type (0x03) and two remaining bits (0 and 1) in the flags for [TUNNEL-DELIVERY], which we can leverage to implement these features.

Security Implications

This proposal does not change the amount of information leaked about the OBGW's target Destination or their view of the NetDB:

• An adversary that controls the OBEP and is scraping LeaseSets from the NetDB can already determine whether a message is being sent to a particular Destination, by searching for the [TunnelId] / [RouterIdentity] pair. At worst, the presence of multiple Leases in the TMDI might make it faster to find a match in the adversary's database.
• An adversary that is operating a malicious Destination can already gain information about a connecting victim's view of the NetDB, by publishing LeaseSets containing different inbound tunnels to different floodfills, and observing which tunnels the OBGW connects through. From their point of view, the OBEP selecting which tunnel to use is functionally identical to the OBGW making the selection.

The multicast flag leaks the fact that the OBGW is multicasting to the OBEPs. This creates a performance vs. privacy trade-off that should be considered when implementing higher-level protocols. Being an optional flag, users can make the appropriate decision for their application. There may be benefits to this being the default behaviour for compatible applications, however, as wide-spread usage by a variety of applications would reduce the information leakage about which particular application a message is from.

Specification

The First Fragment Delivery Instructions [TUNNEL-DELIVERY] would be modified as follows:

+----+----+----+----+----+----+----+----+
|flag|  Tunnel ID (opt)  |              |
+----+----+----+----+----+              +
|                                       |
+                                       +
|         To Hash (optional)            |
+                                       +
|                                       |
+                        +----+----+----+
|                        |dly | Message
+----+----+----+----+----+----+----+----+
 ID (opt) |extended opts (opt)|cnt | (o)
+----+----+----+----+----+----+----+----+
 Tunnel ID N   |                        |
+----+----+----+                        +
|                                       |
+                                       +
|         To Hash N (optional)          |
+                                       +
|                                       |
+              +----+----+----+----+----+
|              | Tunnel ID N+1 (o) |    |
+----+----+----+----+----+----+----+    +
|                                       |
+                                       +
|         To Hash N+1 (optional)        |
+                                       +
|                                       |
+                                  +----+
|                                  | sz
+----+----+----+----+----+----+----+----+
     |
+----+

flag ::
       1 byte
       Bit order: 76543210
       bits 6-5: delivery type
                 0x03 = TUNNELS
       bit 0: multicast? If 0, deliver to one of the tunnels
                         If 1, deliver to all of the tunnels
                         Set to 0 for compatibility with future uses if
                         delivery type is not TUNNELS

Count ::
       1 byte
       Optional, present if delivery type is TUNNELS
       2-255 - Number of id/hash pairs to follow

Tunnel ID :: TunnelId
To Hash ::
       36 bytes each
       Optional, present if delivery type is TUNNELS
       id/hash pairs

Total length: Typical length is:
       75 bytes for count 2 TUNNELS delivery (unfragmented tunnel message);
       79 bytes for count 2 TUNNELS delivery (first fragment)

Rest of delivery instructions unchanged

Compatibility

The only peers that need to be understand the new specification are the OBGWs and the OBEPs. We can therefore make this change compatible with the existing network by making its use conditional on the target I2P version [VERSIONS]:

• The OBGWs must select compatible OBEPs when building outbound tunnels, based on the I2P version advertised in their [RouterInfo].
• Peers that advertise the target version must support parsing the new flags, and must not reject the instructions as invalid.

References