Обзор
Эта страница содержит обзор терминологии и принципов работы I2P tunnel с ссылками на более технические страницы, подробности и спецификации.
Как кратко объяснялось во введении , I2P создает виртуальные “tunnel” - временные и однонаправленные пути через последовательность router’ов. Эти tunnel классифицируются либо как входящие tunnel (где всё, что в них поступает, направляется к создателю tunnel), либо как исходящие tunnel (где создатель tunnel отправляет сообщения от себя). Когда Алиса хочет отправить сообщение Бобу, она (обычно) отправляет его через один из своих существующих исходящих tunnel с инструкциями для конечной точки этого tunnel переслать его к шлюзовому router’у одного из текущих входящих tunnel Боба, который в свою очередь передает его Бобу.
A: Outbound Gateway (Alice)
B: Outbound Participant
C: Outbound Endpoint
D: Inbound Gateway
E: Inbound Participant
F: Inbound Endpoint (Bob)
Словарь терминов Tunnel
Tunnel gateway - первый router в tunnel. Для входящих tunnel это тот, который упоминается в LeaseSet, опубликованном в сетевой базе данных . Для исходящих tunnel, gateway является исходным router. (например, и A, и D выше)
Конечная точка tunnel - последний router в tunnel. (например, и C, и F выше)
Участник tunnel - все router в tunnel, кроме шлюза или конечной точки (например, B и E выше)
n-Hop tunnel - tunnel с определенным количеством межроутерных переходов, например:
- 0-hop tunnel - tunnel, где gateway также является конечной точкой
- 1-hop tunnel - tunnel, где gateway связывается напрямую с конечной точкой
- 2-(или более)-hop tunnel - tunnel, где есть как минимум один промежуточный участник tunnel. (приведенная выше диаграмма включает два 2-hop tunnel - один исходящий от Alice, один входящий к Bob)
Tunnel ID - 4-байтовое целое число , различное для каждого узла в tunnel и уникальное среди всех tunnel на router. Выбирается случайно создателем tunnel.
Информация о построении tunnel
Роутерам, выполняющим три роли (шлюз, участник, конечная точка), передаются различные фрагменты данных в первоначальном Сообщении Построения Туннеля для выполнения их задач:
Tunnel gateway получает:
- tunnel encryption key - приватный ключ AES для шифрования сообщений и инструкций к следующему узлу
- tunnel IV key - приватный ключ AES для двойного шифрования IV к следующему узлу
- reply key - публичный ключ AES для шифрования ответа на запрос построения tunnel
- reply IV - IV для шифрования ответа на запрос построения tunnel
- tunnel id - 4-байтовое целое число (только для входящих шлюзов)
- next hop - какой router является следующим в пути (если это не 0-hop tunnel, и шлюз не является конечной точкой)
- next tunnel id - ID tunnel на следующем узле
Все промежуточные участники tunnel получают:
- tunnel encryption key - приватный ключ AES для шифрования сообщений и инструкций к следующему переходу
- tunnel IV key - приватный ключ AES для двойного шифрования IV к следующему переходу
- reply key - публичный ключ AES для шифрования ответа на запрос построения tunnel
- reply IV - IV для шифрования ответа на запрос построения tunnel
- tunnel id - 4-байтовое целое число
- next hop - какой router является следующим в пути
- next tunnel id - ID tunnel на следующем переходе
Конечная точка tunnel получает:
- tunnel encryption key - приватный ключ AES для шифрования сообщений и инструкций к конечной точке (к себе)
- tunnel IV key - приватный ключ AES для двойного шифрования IV к конечной точке (к себе)
- reply key - публичный ключ AES для шифрования ответа на запрос построения tunnel (только для исходящих конечных точек)
- reply IV - IV для шифрования ответа на запрос построения tunnel (только для исходящих конечных точек)
- tunnel id - 4-байтовое целое число (только для исходящих конечных точек)
- reply router - входящий шлюз tunnel для отправки ответа через него (только для исходящих конечных точек)
- reply tunnel id - ID tunnel ответного router (только для исходящих конечных точек)
Подробности приведены в спецификации создания tunnel .
Объединение Tunnel в пул
Несколько tunnel для определенной цели могут быть сгруппированы в “пул tunnel”, как описано в спецификации tunnel . Это обеспечивает избыточность и дополнительную пропускную способность. Пулы, используемые самим router, называются “исследовательские tunnel”. Пулы, используемые приложениями, называются “клиентские tunnel”.
Длина tunnel
Как упоминалось выше, каждый клиент запрашивает у своего router’а предоставление tunnel’ей, включающих как минимум определённое количество переходов. Решение о том, сколько router’ов включить в исходящие и входящие tunnel’ы, оказывает важное влияние на задержку, пропускную способность, надёжность и анонимность, обеспечиваемые I2P - чем больше узлов должны пройти сообщения, тем дольше они добираются до места назначения и тем выше вероятность преждевременного отказа одного из этих router’ов. Чем меньше router’ов в tunnel’е, тем легче противнику провести атаки анализа трафика и нарушить чью-то анонимность. Длина tunnel’ей задаётся клиентами через опции I2CP . Максимальное количество переходов в tunnel’е составляет 7.
0-hop tunnel’ы
При отсутствии удаленных router’ов в tunnel пользователь имеет очень базовое правдоподобное отрицание (поскольку никто не знает наверняка, что узел, который отправил им сообщение, не просто пересылал его как часть tunnel). Однако было бы довольно легко провести атаку статистического анализа и заметить, что сообщения, нацеленные на конкретное назначение, всегда отправляются через один шлюз. Статистический анализ против исходящих 0-hop tunnel более сложен, но может показать похожую информацию (хотя его было бы несколько сложнее провести).
1-hop tunnel’ы
При наличии только одного удалённого router в tunnel пользователь имеет как правдоподобное отрицание, так и базовую анонимность, пока он не сталкивается с внутренним противником (как описано в модели угроз ). Однако, если противник управляет достаточным количеством router таким образом, что единственный удалённый router в tunnel часто является одним из скомпрометированных, он сможет провести вышеописанную атаку статистического анализа трафика.
2-хоповые tunnel
При наличии двух или более удаленных router в tunnel, стоимость проведения атаки анализа трафика возрастает, поскольку для ее осуществления потребуется скомпрометировать множество удаленных router.
3-hop (или более) tunnel’ы
Для снижения восприимчивости к некоторым атакам рекомендуется использовать 3 или более хопов для обеспечения максимального уровня защиты. Недавние исследования также показывают, что использование более 3 хопов не обеспечивает дополнительной защиты.
Длины tunnel по умолчанию
Router использует 2-хоповые tunnel по умолчанию для своих исследовательских tunnel. Настройки клиентских tunnel по умолчанию устанавливаются приложением, используя опции I2CP . Большинство приложений используют 2 или 3 хопа в качестве значения по умолчанию.
Тестирование туннелей
Все tunnel периодически тестируются их создателем путем отправки DeliveryStatusMessage через исходящий tunnel к другому входящему tunnel (тестируя оба tunnel одновременно). Если любой из них не прошел несколько последовательных тестов, он помечается как неисправный. Если он использовался для входящего tunnel клиента, создается новый leaseSet. Сбои тестирования tunnel также отражаются в рейтинге пропускной способности в профиле узла .
Создание tunnel
Создание туннелей обрабатывается с помощью garlic routing — отправки сообщения Tunnel Build Message роутеру с запросом на участие в туннеле (предоставляя ему всю необходимую информацию, как указано выше, вместе с сертификатом, который сейчас является ’null’ сертификатом, но будет поддерживать hashcash или другие платные сертификаты при необходимости). Этот роутер пересылает сообщение следующему узлу в туннеле. Подробности изложены в спецификации создания туннелей .
Шифрование tunnel
Многослойное шифрование обрабатывается с помощью garlic encryption сообщений туннелей. Подробности приведены в спецификации туннелей . Вектор инициализации каждого узла шифруется отдельным ключом, как объяснено там.
Будущая работа
Могут использоваться другие методы тестирования туннелей, такие как garlic wrapping нескольких тестов в cloves, отдельное тестирование участников туннеля и т.д.
Переход к 3-прыжковым исследовательским tunnel по умолчанию.
В отдаленном будущем релизе могут быть реализованы опции, определяющие настройки объединения в пулы, смешивания и генерации шумового трафика.
В далеком будущем релизе могут быть реализованы ограничения на количество и размер сообщений, разрешенных в течение жизни tunnel (например, не более 300 сообщений или 1 МБ в минуту).