kytv/I2P_Website
1
0
Fork 0
forked from I2P_Developers/i2p.www
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Prop 125: Additional security implications

Browse Source
This commit is contained in:
str4d
2017-04-07 12:49:50 +00:00
parent 217f285b3b
commit 16e7769b36
1 changed files with 23 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
i2p2www/spec/proposals/125-obep-to-one-of-many-tunnels.rst
View File

@@ -64,6 +64,22 @@ flags for [TUNNEL-DELIVERY]_, which we can leverage to implement these features.
Security Implications 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. 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 This creates a performance vs. privacy trade-off that should be considered when
implementing higher-level protocols. Being an optional flag, users can make implementing higher-level protocols. Being an optional flag, users can make
@@ -147,7 +163,7 @@ Compatibility
The only peers that need to be understand the new specification are the OBGWs 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 and the OBEPs. We can therefore make this change compatible with the existing
network by making its use conditional on the target I2P version: network by making its use conditional on the target I2P version [VERSIONS]_:
* The OBGWs must select compatible OBEPs when building outbound tunnels, based * The OBGWs must select compatible OBEPs when building outbound tunnels, based
on the I2P version advertised in their [RouterInfo]_. on the I2P version advertised in their [RouterInfo]_.
@@ -176,3 +192,9 @@ References
.. [TUNNEL-DELIVERY] .. [TUNNEL-DELIVERY]
{{ ctags_url('TunnelMessageDeliveryInstructions') }} {{ ctags_url('TunnelMessageDeliveryInstructions') }}
.. [TunnelId]
{{ ctags_url('TunnelId') }}
.. [VERSIONS]
{{ spec_url('i2np') }}#protocol-versions