Обзор
В этом предложении описывается проект протокола, позволяющего клиенту I2P, сервису или внешнему процессу балансировки управлять несколькими маршрутизаторами, прозрачно размещающими одну и ту же Destination .
На данный момент предложение не определяет конкретную реализацию. Оно может быть реализовано как расширение I2CP , либо как новый протокол.
Мотивация
Мультихоминг — это использование нескольких маршрутизаторов для размещения одной и той же Destination. Текущий способ мультихоминга в I2P — это запуск одной и той же Destination на каждом маршрутизаторе независимо; маршрутизатор, который будет использоваться клиентами в конкретный момент времени, — это тот, который последним опубликовал LeaseSet.
Это костыль, и, вероятно, он не будет работать в масштабе для крупных веб-сайтов. Допустим, у нас есть 100 маршрутизаторов с мультихомингом, каждый с 16 туннелями. Это 1600 публикаций LeaseSet каждые 10 минут, или почти 3 в секунду. Floodfill-узлы будут перегружены, и сработают ограничения. И это ещё до того, как мы упомянем трафик поиска.
Предложение 123 решает эту проблему с помощью meta-LeaseSet, в котором перечислены хэши 100 реальных LeaseSet. Поиск становится двухэтапным процессом: сначала ищется meta-LeaseSet, а затем один из указанных LeaseSet. Это хорошее решение проблемы поискового трафика, но само по себе оно создаёт значительную утечку приватности: можно определить, какие маршрутизаторы с мультихомингом находятся в сети, отслеживая опубликованный meta-LeaseSet, поскольку каждый реальный LeaseSet соответствует одному маршрутизатору.
Нам нужен способ, позволяющий клиенту или сервису I2P распределять одну Destination по нескольким маршрутизаторам так, чтобы с точки зрения самого LeaseSet это было неотличимо от использования одного маршрутизатора.
Проект
Определения
User
Человек или организация, желающая использовать мультихоминг для своей Destination(s). Здесь рассматривается одна Destination без потери общности (WLOG).
Client
Приложение или сервис, работающий за Destination. Это может быть клиентское, серверное или пиринговое приложение; мы называем его клиентом в том смысле, что он подключается к маршрутизаторам I2P.
Клиент состоит из трёх частей, которые могут находиться в одном процессе или быть разделены по процессам или машинам (в многоклиентской конфигурации):
Balancer
Часть клиента, управляющая выбором пиров и построением туннелей. В каждый момент времени существует один балансировщик, и он взаимодействует со всеми маршрутизаторами I2P. Возможны резервные балансировщики.
Frontend
Часть клиента, которая может работать параллельно. Каждый фронтенд взаимодействует с одним маршрутизатором I2P.
Backend
Часть клиента, общей для всех фронтендов. Не имеет прямого взаимодействия с каким-либо маршрутизатором I2P.
Router
Маршрутизатор I2P, запущенный пользователем, находящийся на границе между сетью I2P и сетью пользователя (аналогично edge-устройству в корпоративных сетях). Строит туннели по команде балансировщика и маршрутизирует пакеты для клиента или фронтенда.
Общее описание
Представим следующую желаемую конфигурацию:
- Клиентское приложение с одной Destination.
- Четыре маршрутизатора, каждый управляющий тремя входящими туннелями.
- Все двенадцать туннелей должны быть опубликованы в одном LeaseSet.
Одноклиентская конфигурация
-{ [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.
Открыть сессию с каждым маршрутизатором, привязанную к Destination.
Периодически (примерно каждые десять минут, но чаще или реже в зависимости от активности туннелей):
Получить быстрый уровень (fast tier) от каждого маршрутизатора.
Использовать объединённый набор пиров для построения туннелей к/от каждого маршрутизатора.
- По умолчанию туннели к/от конкретного маршрутизатора будут использовать пиры из его быстрого уровня, но протокол не требует этого.
Собрать набор активных входящих туннелей со всех активных маршрутизаторов и создать LeaseSet.
Опубликовать LeaseSet через один или несколько маршрутизаторов.
Отличия от I2CP
Для создания и управления такой конфигурацией клиенту требуется следующая новая функциональность, которой в настоящее время нет в I2CP :
- Приказать маршрутизатору построить туннели без создания для них LeaseSet.
- Получить список текущих туннелей во входящем пуле.
Кроме того, следующая функциональность обеспечит значительную гибкость в управлении клиентом своими туннелями:
- Получить содержимое быстрого уровня маршрутизатора.
- Приказать маршрутизатору построить входящий или исходящий туннель с использованием заданного списка пиров.
Схема протокола
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 <---------------------
Сообщения
Create Session
- Создать сессию для указанной Destination.
Session Status
- Подтверждение, что сессия настроена, и клиент может начать построение туннелей.
Get Fast Tier
- Запросить список пиров, через которые маршрутизатор в данный момент может строить туннели.
Peer List
- Список пиров, известных маршрутизатору.
Create Tunnel
- Запрос на построение маршрутизатором нового туннеля через указанных пиров.
Tunnel Status
- Результат построения конкретного туннеля, как только он станет доступен.
Get Tunnel Pool
- Запросить список текущих туннелей во входящем или исходящем пуле для Destination.
Tunnel List
- Список туннелей для запрошенного пула.
Publish LeaseSet
- Запросить публикацию маршрутизатором предоставленного LeaseSet через один из исходящих туннелей для Destination. Ответный статус не требуется; маршрутизатор должен продолжать повторные попытки, пока не убедится, что LeaseSet опубликован.
Send Packet
- Исходящий пакет от клиента. Опционально указывает исходящий туннель, через который пакет должен (должен?) быть отправлен.
Send Status
- Сообщает клиенту об успешной или неудачной отправке пакета.
Packet Received
- Входящий пакет для клиента. Опционально указывает входящий туннель, через который был получен пакет(?)
Последствия для безопасности
С точки зрения маршрутизаторов, этот проект функционально эквивалентен текущему состоянию. Маршрутизатор по-прежнему строит все туннели, поддерживает собственные профили пиров и обеспечивает разделение между операциями маршрутизатора и клиента. В конфигурации по умолчанию всё полностью идентично, поскольку туннели для маршрутизатора строятся из его собственного быстрого уровня.
С точки зрения netDB, один LeaseSet, созданный с помощью этого протокола, идентичен текущему состоянию, поскольку он использует уже существующую функциональность. Однако для больших LeaseSet, приближающихся к 16 лизам, наблюдатель может определить, что LeaseSet использует мультихоминг:
Текущий максимальный размер быстрого уровня — 75 пиров. Входной шлюз (IBGW, узел, опубликованный в Lease) выбирается из части этого уровня (разделённой случайным образом по пулу туннелей по хэшу, а не по количеству):
1 хоп Весь быстрый уровень 2 хопа Половина быстрого уровня (по умолчанию до середины 2014 года) 3+ хопа Четверть быстрого уровня (3 — текущее значение по умолчанию)Это означает, что в среднем IBGW будут выбираться из набора из 20–30 пиров.
В однородной конфигурации полный LeaseSet с 16 туннелями будет иметь 16 IBGW, случайно выбранных из набора до (скажем) 20 пиров.
В 4-маршрутизаторной мультихоминговой конфигурации с настройками по умолчанию полный LeaseSet с 16 туннелями будет иметь 16 IBGW, случайно выбранных из набора максимум из 80 пиров, хотя, вероятно, будет доля общих пиров между маршрутизаторами.
Таким образом, при конфигурации по умолчанию с помощью статистического анализа можно определить, что LeaseSet генерируется с помощью этого протокола. Также возможно определить количество маршрутизаторов, хотя влияние смены пиров в быстром уровне снизит эффективность такого анализа.
Поскольку клиент полностью контролирует выбор пиров, эту утечку информации можно уменьшить или устранить, выбирая IBGW из ограниченного набора пиров.
Совместимость
Этот проект полностью обратно совместим с сетью, поскольку формат LeaseSet не изменяется. Все маршрутизаторы должны быть осведомлены о новом протоколе, но это не является проблемой, поскольку ими будет управлять одна и та же сущность.
Замечания о производительности и масштабируемости
Верхний предел в 16 лиз на LeaseSet остаётся неизменным в этом предложении. Для Destination, которым требуется больше туннелей, возможны два варианта модификации сети:
Увеличить верхний предел размера LeaseSet. Это было бы самым простым в реализации (хотя всё равно потребовало бы повсеместной поддержки сети, прежде чем можно будет широко использовать), но могло бы привести к более медленным поискам из-за увеличения размера пакетов. Максимальный допустимый размер LeaseSet определяется MTU базовых транспортов и составляет около 16 кБ.
Реализовать Предложение 123 для иерархических LeaseSet. В сочетании с этим предложением Destination для под-LeaseSet можно распределить по нескольким маршрутизаторам, что эффективно будет работать как несколько IP-адресов для сервиса в clearnet.
Благодарности
Спасибо psi за обсуждение, приведшее к этому предложению.