diff --git a/i2p2www/spec/proposals/125-obep-to-one-of-many-tunnels.rst b/i2p2www/spec/proposals/125-obep-to-one-of-many-tunnels.rst index 5760f3d0..ee22ef13 100644 --- a/i2p2www/spec/proposals/125-obep-to-one-of-many-tunnels.rst +++ b/i2p2www/spec/proposals/125-obep-to-one-of-many-tunnels.rst @@ -1,11 +1,11 @@ -==================================== -OBEP Delivery to One-of-Many Tunnels -==================================== +========================================= +OBEP Delivery to 1-of-N or N-of-N Tunnels +========================================= .. meta:: - :author: zzz + :author: zzz, str4d :created: 2016-03-10 :thread: http://zzz.i2p/topics/2099 - :lastupdated: 2016-03-10 + :lastupdated: 2017-04-07 :status: Open .. contents:: @@ -14,44 +14,165 @@ OBEP Delivery to One-of-Many Tunnels Overview ======== -This proposal is about delegating IBGW selection to the OBEP by providing it -with a list of alternatives instead of a single option. +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 ========== -The idea is to reduce connection congestion, by giving the OBEP flexibility in -how it connects to IBGWs. +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 ====== -Give the OBEP a list of id/hash pairs (i.e. leases) to deliver the message to -rather than 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. +The originator (OBGW) would place some (all?) of the target [Leases]_ in the +delivery instructions [TUNNEL-DELIVERY]_ instead of picking just one. -The originator (OBGW) would stick some (all?) of the target leases in the -delivery instructions instead of picking just one. - -This would make the OBEP-IBGW path faster and more reliable, and reduce overall +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. Because we've previously discussed multicast at the OBEP (deliver to all -specified leases), we could plan for that feature as well at the same time. +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 +===================== + +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 ============= -:: +.. raw:: html - Flag byte: - Delivery type 0x03: count byte and multiple id/hash pairs follow - Bit 0: 0 to deliver to one of the tunnels; 1 to deliver to all of the tunnels - Count byte: 2-255 number of id/hash pairs to follow (36 bytes each) - That many id/hash pairs (36 bytes each) - rest of delivery instructions unchanged + {% highlight lang='dataspec' %} ++----+----+----+----+----+----+----+----+ + |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 +{% endhighlight %} + + +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: + +* 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] + {{ ctags_url('Destination') }} + +.. [Leases] + {{ ctags_url('Lease') }} + +.. [LeaseSet] + {{ ctags_url('LeaseSet') }} + +.. [RouterIdentity] + {{ ctags_url('RouterIdentity') }} + +.. [RouterInfo] + {{ ctags_url('RouterInfo') }} + +.. [TUNNEL-DELIVERY] + {{ ctags_url('TunnelMessageDeliveryInstructions') }}