=========================================
OBEP Delivery to 1-of-N or N-of-N Tunnels
=========================================
Author: zzz, str4d
Created: 2016-03-10
Thread: http://zzz.i2p/topics/2099
Last updated: 2017-04-07
Status: Open
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
[TunnelId]: /spec/common-structures#type-tunnelid
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
==========
[Destination]
http://geti2p.net/spec/common-structures#struct-destination
[Leases]
http://geti2p.net/spec/common-structures#struct-lease
[LeaseSet]
http://geti2p.net/spec/common-structures#struct-leaseset
[RouterIdentity]
http://geti2p.net/spec/common-structures#struct-routeridentity
[RouterInfo]
http://geti2p.net/spec/common-structures#struct-routerinfo
[TUNNEL-DELIVERY]
http://geti2p.net/spec/tunnel-message#struct-tunnelmessagedeliveryinstructions
[TunnelId]
http://geti2p.net/spec/common-structures#type-tunnelid
[VERSIONS]
http://geti2p.net/spec/i2np#protocol-versions