forked from I2P_Developers/i2p.www
Prop 125:
- Expand and clarify the specification - Add security implications, compatibility - Pull in discussion from thread into motivation - Cleanups
This commit is contained in:
str4d
@@ -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') }}
|
||||
|
||||
Reference in New Issue
Block a user