I2P Address: [http://git.idk.i2p]

Skip to content
Snippets Groups Projects
Commit 334b6df0 authored by str4d's avatar str4d
Browse files

Prop140: 

- Add definitions of user, client (with sub-definitions for balancer, frontend
  and backend), and router
- Replace "edge router" with "router"
- Add a second diagram showing a multi-client setup with split-out balancer,
  frontends and backend
parent 4de3987a
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
i2p2www/spec/proposals/140-invisible-multihoming.rst
+ 117
− 55
View file @ 334b6df0
...@@ -5,7 +5,7 @@ Invisible Multihoming ...@@ -5,7 +5,7 @@ Invisible Multihoming
:author: str4d :author: str4d
:created: 2017-05-22 :created: 2017-05-22
:thread: http://zzz.i2p/topics/2335 :thread: http://zzz.i2p/topics/2335
:lastupdated: 2017-05-22 :lastupdated: 2017-07-04
:status: Open :status: Open
.. contents:: .. contents::
...@@ -14,8 +14,9 @@ Invisible Multihoming ...@@ -14,8 +14,9 @@ Invisible Multihoming
Overview Overview
======== ========
This proposal outlines a design for a protocol enabling an I2P client or service This proposal outlines a design for a protocol enabling an I2P client, service
to transparently use multiple routers to host a single [Destination]_. or external balancer process to manage multiple routers transparently hosting a
single [Destination]_.
The proposal currently does not specify a concrete implementation. It could be The proposal currently does not specify a concrete implementation. It could be
implemented as an extension to [I2CP]_, or as a new protocol. implemented as an extension to [I2CP]_, or as a new protocol.
...@@ -30,10 +31,10 @@ router independently; the router that gets used by clients at any particular ...@@ -30,10 +31,10 @@ router independently; the router that gets used by clients at any particular
time is the last one to publish a [LeaseSet]_. time is the last one to publish a [LeaseSet]_.
This is a hack and presumably won't work for large websites at scale. Say we had This is a hack and presumably won't work for large websites at scale. Say we had
100 multihoming routers (edges) each with 16 tunnels. That's 1600 LeaseSet 100 multihoming routers each with 16 tunnels. That's 1600 LeaseSet publishes
publishes every 10 minutes, or almost 3 per second. The floodfills would get every 10 minutes, or almost 3 per second. The floodfills would get overwhelmed
overwhelmed and throttles would kick in. And that's before we even mention the and throttles would kick in. And that's before we even mention the lookup
lookup traffic. traffic.
[Prop123]_ solves this problem with a meta-LeaseSet, which lists the 100 real [Prop123]_ solves this problem with a meta-LeaseSet, which lists the 100 real
LeaseSet hashes. A lookup becomes a two-stage process: first looking up the LeaseSet hashes. A lookup becomes a two-stage process: first looking up the
...@@ -41,78 +42,138 @@ meta-LeaseSet, and then one of the named LeaseSets. This is a good solution to ...@@ -41,78 +42,138 @@ meta-LeaseSet, and then one of the named LeaseSets. This is a good solution to
the lookup traffic issue, but on its own it creates a significant privacy leak: the lookup traffic issue, but on its own it creates a significant privacy leak:
It is possible to determine which multihoming routers are online by monitoring It is possible to determine which multihoming routers are online by monitoring
the published meta-LeaseSet, because each real LeaseSet has corresponds to a the published meta-LeaseSet, because each real LeaseSet has corresponds to a
single edge. single router.
We need a way for an I2P client or service to spread a single Destination across We need a way for an I2P client or service to spread a single Destination across
multiple edge routers, in a way that is indistinguishable to using a single multiple routers, in a way that is indistinguishable to using a single router
router (from the perspective of the LeaseSet itself). (from the perspective of the LeaseSet itself).
Design Design
====== ======
Definitions
-----------
User
The person or organisation wanting to multihome their Destination(s). A
single Destination is considered here without loss of generality (WLOG).
Client
The application or service running behind the Destination. It may be a
client-side, server-side, or peer-to-peer application; we refer to it as
a client in the sense that it connects to the I2P routers.
The client consists of three parts, which may all be in the same process
or may be split across processes or machines (in a multi-client setup):
Balancer
The part of the client that manages peer selection and tunnel
building. There is a single balancer at any one time, and it
communicates with all I2P routers. There may be failover balancers.
Frontend
The part of the client that can be operated in parallel. Each
frontend communicates with a single I2P router.
Backend
The part of the client that is shared between all frontends. It has
no direct communication with any I2P router.
Router
An I2P router run by the user that sits at the boundary between the I2P
network and the user's network (akin to an edge device in corporate
networks). It builds tunnels under the command of a balancer, and routes
packets for a client or frontend.
High-level overview High-level overview
------------------- -------------------
Imagine the following desired configuration: Imagine the following desired configuration:
- A client application with one Destination. - A client application with one Destination.
- Four edge routers, each managing three inbound tunnels. - Four routers, each managing three inbound tunnels.
- All twelve tunnels should be published in a single LeaseSet. - All twelve tunnels should be published in a single LeaseSet.
Single-client
`````````````
.. raw:: html .. raw:: html
{% highlight lang='text' %} {% highlight lang='text' %}
-{ [Tunnel 1]===\ -{ [Tunnel 1]===\
|-{ [Tunnel 2]====[Edge Router 1]----- |-{ [Tunnel 2]====[Router 1]-----
|-{ [Tunnel 3]===/ \ |-{ [Tunnel 3]===/ \
| \ | \
|-{ [Tunnel 4]===\ \ |-{ [Tunnel 4]===\ \
[Destination] |-{ [Tunnel 5]====[Edge Router 2]----- \ [Destination] |-{ [Tunnel 5]====[Router 2]----- \
\ |-{ [Tunnel 6]===/ \ \ \ |-{ [Tunnel 6]===/ \ \
[LeaseSet]--| [Client] [LeaseSet]--| [Client]
|-{ [Tunnel 7]===\ / / |-{ [Tunnel 7]===\ / /
|-{ [Tunnel 8]====[Edge Router 3]----- / |-{ [Tunnel 8]====[Router 3]----- /
|-{ [Tunnel 9]===/ / |-{ [Tunnel 9]===/ /
| / | /
|-{ [Tunnel 10]==\ / |-{ [Tunnel 10]==\ /
|-{ [Tunnel 11]===[Edge Router 4]----- |-{ [Tunnel 11]===[Router 4]-----
-{ [Tunnel 12]==/ -{ [Tunnel 12]==/
{% endhighlight %} {% endhighlight %}
To create and manage this configuration, the client needs the following new Multi-client
functionality beyond what is currently provided by [I2CP]_: ````````````
.. raw:: html
- Tell a router to build tunnels, without creating a LeaseSet for them.
- Get a list of the current tunnels in the inbound pool.
Additionally, the following functionality would enable significant flexibility
in how the client manages its tunnels:
- Get the contents of a router's fast tier. {% highlight lang='text' %}
- Tell a router to build an inbound or outbound tunnel using a given list of -{ [Tunnel 1]===\
peers. |-{ [Tunnel 2]====[Router 1]---------[Frontend 1]
|-{ [Tunnel 3]===/ \ \
| \ \
|-{ [Tunnel 4]===\ \ \
[Destination] |-{ [Tunnel 5]====[Router 2]---\-----[Frontend 2] \
\ |-{ [Tunnel 6]===/ \ \ \ \
[LeaseSet]--| [Balancer] [Backend]
|-{ [Tunnel 7]===\ / / / /
|-{ [Tunnel 8]====[Router 3]---/-----[Frontend 3] /
|-{ [Tunnel 9]===/ / /
| / /
|-{ [Tunnel 10]==\ / /
|-{ [Tunnel 11]===[Router 4]---------[Frontend 4]
-{ [Tunnel 12]==/
{% endhighlight %}
General client process General client process
`````````````````````` ``````````````````````
- Load or generate a Destination. - Load or generate a Destination.
- Open up a session with each edge router, tied to the Destination. - Open up a session with each router, tied to the Destination.
- Periodically (around every ten minutes, but more or less based on tunnel - Periodically (around every ten minutes, but more or less based on tunnel
liveness): liveness):
- Obtain the fast tier from each edge. - Obtain the fast tier from each router.
- Use the superset of peers to build tunnels to/from each edge. - Use the superset of peers to build tunnels to/from each router.
- By default, tunnels to/from a particular edge router will use peers from - By default, tunnels to/from a particular router will use peers from
that router's fast tier, but this is not enforced by the protocol. that router's fast tier, but this is not enforced by the protocol.
- Collect the set of active inbound tunnels from all active edges, and create a - Collect the set of active inbound tunnels from all active routers, and create a
LeaseSet. LeaseSet.
- Publish the LeaseSet through one or more of the edges. - Publish the LeaseSet through one or more of the routers.
Differences to I2CP
```````````````````
To create and manage this configuration, the client needs the following new
functionality beyond what is currently provided by [I2CP]_:
- Tell a router to build tunnels, without creating a LeaseSet for them.
- Get a list of the current tunnels in the inbound pool.
Additionally, the following functionality would enable significant flexibility
in how the client manages its tunnels:
- Get the contents of a router's fast tier.
- Tell a router to build an inbound or outbound tunnel using a given list of
peers.
Protocol outline Protocol outline
---------------- ----------------
...@@ -120,7 +181,7 @@ Protocol outline ...@@ -120,7 +181,7 @@ Protocol outline
.. raw:: html .. raw:: html
{% highlight %} {% highlight %}
Client Edge Router Client Router
---------------------> Create Session ---------------------> Create Session
Session Status <--------------------- Session Status <---------------------
...@@ -186,10 +247,10 @@ Messages ...@@ -186,10 +247,10 @@ Messages
Security implications Security implications
===================== =====================
From the perspective of the edge routers, this design is functionally equivalent From the perspective of the routers, this design is functionally equivalent to
to the status quo. The edge router still builds all tunnels, maintains its own the status quo. The router still builds all tunnels, maintains its own peer
peer profiles, and enforces separation between router and client operations. In profiles, and enforces separation between router and client operations. In the
the default configuration is completely identical, because tunnels for that edge default configuration is completely identical, because tunnels for that router
are built from its own fast tier. are built from its own fast tier.
From the perspective of the netDB, a single LeaseSet created via this protocol From the perspective of the netDB, a single LeaseSet created via this protocol
...@@ -217,13 +278,14 @@ observer to determine that the LeaseSet is multihomed: ...@@ -217,13 +278,14 @@ observer to determine that the LeaseSet is multihomed:
- In a single-homed setup, a full 16-tunnel LeaseSet would have 16 IBGWs - In a single-homed setup, a full 16-tunnel LeaseSet would have 16 IBGWs
randomly selected from a set of up to (say) 20 peers. randomly selected from a set of up to (say) 20 peers.
- In a 4-edge multihomed setup using the default configuration, a full 16-tunnel - In a 4-router multihomed setup using the default configuration, a full
LeaseSet would have 16 IBGWs randomly-selected from a set of at most 80 peers, 16-tunnel LeaseSet would have 16 IBGWs randomly-selected from a set of at most
though there are likely to be a fraction of common peers between edge nodes. 80 peers, though there are likely to be a fraction of common peers between
routers.
Thus with the default configuration, it may be possible through statistical Thus with the default configuration, it may be possible through statistical
analysis to figure out that a LeaseSet is being generated by this protocol. It analysis to figure out that a LeaseSet is being generated by this protocol. It
might also be possible to figure out how many edge nodes there are, although the might also be possible to figure out how many routers there are, although the
effect of churn on the fast tiers would reduce the effectiveness of this effect of churn on the fast tiers would reduce the effectiveness of this
analysis. analysis.
...@@ -236,9 +298,9 @@ Compatibility ...@@ -236,9 +298,9 @@ Compatibility
============= =============
This design is completely backwards-compatible with the network, because there This design is completely backwards-compatible with the network, because there
are no changes to the [LeaseSet]_ format. All edge routers would need to be are no changes to the [LeaseSet]_ format. All routers would need to be aware of
aware of the new protocol, but this is not a concern as they would all be the new protocol, but this is not a concern as they would all be controlled by
controlled by the same entity. the same entity.
Performance and scalability notes Performance and scalability notes
...@@ -255,8 +317,8 @@ modifications: ...@@ -255,8 +317,8 @@ modifications:
underlying transports, and is therefore around 16kB. underlying transports, and is therefore around 16kB.
- Implement [Prop123]_ for tiered LeaseSets. In combination with this proposal, - Implement [Prop123]_ for tiered LeaseSets. In combination with this proposal,
the Destinations for the sub-LeaseSets could be spread across multiple edges, the Destinations for the sub-LeaseSets could be spread across multiple
effectively acting like multiple IP addresses for a clearnet service. routers, effectively acting like multiple IP addresses for a clearnet service.
Acknowledgements Acknowledgements
......
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment

Base32 Address: [http://7qeve4v2chmjdqlwpa3vl7aojf3nodbku7vepnjwrsxljzqipz6a.b32.i2p] Onion Address: [http://47ggr2fa3vnwfyhvgskzdmr3i32eijwymxohtxsls45dulmriwxszjad.onion]