Обзор
Данное предложение описывает дизайн протокола, позволяющего I2P-клиенту, сервису или внешнему процессу балансировщика прозрачно управлять несколькими router’ами, хостящими один Destination.
Предложение в настоящее время не определяет конкретную реализацию. Оно может быть реализовано как расширение к I2CP или как новый протокол.
Мотивация
Мультихоминг — это когда несколько router используются для хостинга одного и того же Destination. Текущий способ реализации мультихоминга в I2P — это запуск одного и того же Destination на каждом router независимо; router, который используется клиентами в конкретный момент времени, — это последний, который опубликовал LeaseSet.
Это хак и, предположительно, не будет работать для крупных веб-сайтов в масштабе. Скажем, у нас было 100 multihoming роутеров, каждый с 16 туннелями. Это 1600 публикаций LeaseSet каждые 10 минут, или почти 3 в секунду. Floodfill узлы были бы перегружены и включились бы ограничения. И это еще до того, как мы упомянем трафик поиска.
Предложение 123 решает эту проблему с помощью мета-LeaseSet, который содержит список 100 реальных хешей LeaseSet. Поиск становится двухэтапным процессом: сначала поиск мета-LeaseSet, а затем одного из указанных LeaseSet. Это хорошее решение проблемы трафика поиска, но само по себе оно создает значительную утечку приватности: можно определить, какие multihoming роутеры находятся в сети, отслеживая опубликованный мета-LeaseSet, поскольку каждый реальный LeaseSet соответствует одному роутеру.
Нам нужен способ для I2P клиента или сервиса распределить один Destination по нескольким router’ам таким образом, чтобы это было неотличимо от использования одного router’а (с точки зрения самого LeaseSet).
Дизайн
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
Представьте себе следующую желаемую конфигурацию:
- Клиентское приложение с одним Destination.
- Четыре router, каждый из которых управляет тремя входящими tunnel.
- Все двенадцать tunnel должны быть опубликованы в одном LeaseSet.
Single-client
-{ [Tunnel 1]===\
|-{ [Tunnel 2]====[Router 1]-----
|-{ [Tunnel 3]===/ \
| \
|-{ [Tunnel 4]===\ \
[Destination] |-{ [Tunnel 5]====[Router 2]----- \
\ |-{ [Tunnel 6]===/ \ \
[LeaseSet]--| [Client]
|-{ [Tunnel 7]===\ / /
|-{ [Tunnel 8]====[Router 3]----- /
|-{ [Tunnel 9]===/ /
| /
|-{ [Tunnel 10]==\ /
|-{ [Tunnel 11]===[Router 4]-----
-{ [Tunnel 12]==/
Определения
-{ [Tunnel 1]===\
|-{ [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]==/
Обзор высокого уровня
Загрузить или сгенерировать Destination.
Открыть сессию с каждым router, привязанную к Destination.
Периодически (примерно каждые десять минут, но больше или меньше в зависимости от активности туннелей):
Получить быстрый уровень от каждого router.
Использовать супермножество пиров для построения туннелей к/от каждого router.
- 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.
Собрать набор активных входящих туннелей от всех активных роутеров и создать LeaseSet.
Публикация LeaseSet через один или несколько router’ов.
Один клиент
Для создания и управления этой конфигурацией клиенту требуется следующий новый функционал помимо того, что в настоящее время предоставляется I2CP:
- Сказать маршрутизатору построить туннели, не создавая для них LeaseSet.
- Получить список текущих туннелей в пуле входящих соединений.
Кроме того, следующий функционал обеспечит значительную гибкость в том, как клиент управляет своими tunnel’ами:
- Получить содержимое быстрого уровня router’а.
- Сообщить router’у о необходимости построить входящий или исходящий tunnel, используя заданный список узлов.
Мульти-клиент
Client Router
---------------------> Create Session
Session Status <---------------------
---------------------> Get Fast Tier
Peer List <---------------------
---------------------> Create Tunnel
Tunnel Status <---------------------
---------------------> Get Tunnel Pool
Tunnel List <---------------------
---------------------> Publish LeaseSet
---------------------> Send Packet
Send Status <---------------------
Packet Received <---------------------
Общий процесс клиента
Создать сессию - Создать сессию для указанного Destination.
Статус сессии - Подтверждение того, что сессия была установлена, и клиент теперь может начать создание tunnel’ов.
Get Fast Tier - Запросить список пиров, через которые router в настоящее время рассматривает возможность построения tunnel.
Список пиров - Список пиров, известных роутеру.
Создать туннель - Запрос на создание нового tunnel через указанные узлы.
Статус туннеля - Результат построения конкретного туннеля, когда он становится доступным.
Get Tunnel Pool - Запрос списка текущих tunnel’ов в входящем или исходящем пуле для Destination.
Список Tunnel - Список tunnel’ей для запрошенного пула.
Публикация LeaseSet - Запрос роутеру опубликовать предоставленный LeaseSet через один из исходящих туннелей для Destination. Статус ответа не требуется; роутер должен продолжать повторные попытки до тех пор, пока не убедится, что LeaseSet был опубликован.
Send Packet - Исходящий пакет от клиента. При необходимости указывает исходящий tunnel, через который пакет должен (следует?) быть отправлен.
Статус отправки - Уведомляет клиента об успехе или неудаче отправки пакета.
Получен пакет - Входящий пакет для клиента. Опционально указывает входящий tunnel, через который был получен пакет(?)
Security implications
С точки зрения router’ов, эта архитектура функционально эквивалентна существующему положению дел. Router по-прежнему строит все tunnel’ы, поддерживает собственные профили узлов и обеспечивает разделение между операциями router’а и клиента. В конфигурации по умолчанию все полностью идентично, поскольку tunnel’ы для этого router’а строятся из его собственного быстрого уровня.
С точки зрения netDB, единичный leaseSet, созданный с помощью данного протокола, идентичен текущему положению дел, поскольку он использует уже существующую функциональность. Однако для больших leaseSet, приближающихся к 16 Lease, наблюдатель может определить, что leaseSet является мультихостовым:
Текущий максимальный размер быстрого уровня составляет 75 узлов. Входящий шлюз (IBGW, узел, опубликованный в leaseSet) выбирается из части уровня (разделенной случайным образом для каждого пула туннелей по хешу, а не по количеству):
1 hop The whole fast tier 2 hops Half of the fast tier (the default until mid-2014) 3+ hops A quarter of the fast tier (3 being the current default)
Это означает, что в среднем IBGW будут выбираться из набора 20-30 пиров.
В конфигурации single-homed полный 16-туннельный LeaseSet будет иметь 16 IBGW, случайно выбранных из набора до (скажем) 20 пиров.
В конфигурации с 4 роутерами и множественными соединениями, использующей настройки по умолчанию, полный 16-туннельный LeaseSet будет иметь 16 IBGW, случайно выбранных из набора максимум 80 пиров, хотя вероятно будет некоторая доля общих пиров между роутерами.
Таким образом, при конфигурации по умолчанию может быть возможно посредством статистического анализа выяснить, что LeaseSet генерируется данным протоколом. Также может быть возможно определить, сколько router’ов имеется, хотя эффект оттока на быстрых уровнях снизил бы эффективность такого анализа.
Поскольку клиент имеет полный контроль над выбором узлов, эта утечка информации может быть уменьшена или устранена путем выбора IBGW из ограниченного набора узлов.
Compatibility
Данная архитектура полностью обратно совместима с сетью, поскольку в формат LeaseSet не вносятся никакие изменения. Все роутеры должны будут поддерживать новый протокол, но это не является проблемой, так как все они будут контролироваться одной и той же организацией.
Performance and scalability notes
Верхний лимит в 16 Lease на LeaseSet не изменяется данным предложением. Для Destination, которым требуется больше туннелей, существует два возможных изменения в сети:
Увеличить верхний лимит размера LeaseSets. Это было бы проще всего реализовать (хотя все равно потребовалось бы повсеместная поддержка сети, прежде чем это можно было бы широко использовать), но могло бы привести к более медленным поискам из-за больших размеров пакетов. Максимальный возможный размер LeaseSet определяется MTU базовых транспортов и составляет около 16 КБ.
Реализовать Предложение 123 для многоуровневых LeaseSets. В сочетании с этим предложением, Destinations для под-LeaseSets могут быть распределены между несколькими routers, эффективно действуя как множественные IP-адреса для сервиса clearnet.
Acknowledgements
Благодарим psi за обсуждение, которое привело к этому предложению.