Реализация Tunnel

Эта страница документирует текущую реализацию tunnel.

Обзор туннелей

В рамках I2P сообщения передаются в одном направлении через виртуальный tunnel из участников, используя любые доступные средства для передачи сообщения к следующему узлу. Сообщения поступают в шлюз tunnel’а, объединяются и/или фрагментируются в сообщения tunnel фиксированного размера и пересылаются следующему узлу в tunnel’е, который обрабатывает и проверяет действительность сообщения и отправляет его следующему узлу, и так далее, пока оно не достигнет конечной точки tunnel’а. Эта конечная точка принимает сообщения, объединенные шлюзом, и пересылает их согласно инструкциям - либо другому router’у, либо другому tunnel на другом router’е, либо локально.

Все tunnel работают одинаково, но могут быть разделены на две разные группы - входящие tunnel и исходящие tunnel. Входящие tunnel имеют недоверенный gateway, который передает сообщения вниз к создателю tunnel, который служит конечной точкой tunnel. Для исходящих tunnel создатель tunnel служит в качестве gateway, передавая сообщения к удаленной конечной точке.

Создатель tunnel выбирает точно, какие узлы будут участвовать в tunnel, и предоставляет каждому необходимые данные конфигурации. Они могут иметь любое количество переходов. Цель состоит в том, чтобы затруднить как участникам, так и третьим сторонам определение длины tunnel, или даже сговорившимся участникам определить, являются ли они частью одного и того же tunnel вообще (за исключением ситуации, когда сговорившиеся узлы находятся рядом друг с другом в tunnel).

На практике используется серия пулов tunnel для различных целей - каждое локальное клиентское назначение имеет свой собственный набор входящих tunnel и исходящих tunnel, настроенных для удовлетворения его потребностей в анонимности и производительности. Кроме того, сам router поддерживает серию пулов для участия в netDb и для управления самими tunnel.

I2P является сетью с коммутацией пакетов по своей природе, даже с этими tunnel, что позволяет использовать преимущества нескольких tunnel, работающих параллельно, повышая устойчивость и балансируя нагрузку. Помимо основного уровня I2P, для клиентских приложений доступна дополнительная библиотека сквозной потоковой передачи, предоставляющая TCP-подобную работу, включая переупорядочивание сообщений, повторную передачу, контроль перегрузки и т.д.

Обзор терминологии I2P tunnel представлен на странице обзора tunnel .

Работа tunnel (Обработка сообщений)

Обзор

После построения туннеля I2NP сообщения обрабатываются и передаются через него. Работа туннеля включает четыре различных процесса, выполняемых различными участниками в туннеле.

1. Сначала шлюз туннеля накапливает несколько I2NP сообщений и предварительно обрабатывает их в сообщения туннеля для доставки.
2. Затем этот шлюз шифрует предварительно обработанные данные и пересылает их на первый узел.
3. Этот узел и последующие участники туннеля снимают слой шифрования, проверяя, что это не дубликат, затем пересылают данные следующему узлу.
4. В конце концов сообщения туннеля прибывают в конечную точку, где I2NP сообщения, изначально собранные шлюзом, собираются заново и пересылаются по запросу.

Промежуточные участники tunnel не знают, находятся ли они во входящем или исходящем tunnel; они всегда “шифруют” для следующего узла. Поэтому мы используем преимущества симметричного AES-шифрования для “расшифровки” на шлюзе исходящего tunnel, чтобы открытый текст был раскрыт на конечной точке исходящего соединения.

Предварительная обработка сообщений

Функция tunnel gateway заключается в фрагментации и упаковке I2NP сообщений в tunnel сообщения фиксированного размера и шифровании tunnel сообщений. Tunnel сообщения содержат следующее:

• 4-байтный идентификатор туннеля (Tunnel ID)
• 16-байтный вектор инициализации (IV)
• Контрольная сумма
• Заполнение при необходимости
• Одна или более пар { инструкция доставки, фрагмент I2NP сообщения }

Tunnel ID — это 4-байтовые числа, используемые на каждом узле - участники знают, какой tunnel ID прослушивать для сообщений и на какой tunnel ID их следует перенаправлять на следующий узел, и каждый узел выбирает tunnel ID, на котором он получает сообщения. Сами tunnel являются недолговечными (10 минут). Даже если последующие tunnel строятся с использованием той же последовательности узлов, tunnel ID каждого узла изменится.

Чтобы предотвратить возможность противников помечать сообщения вдоль пути путем изменения размера сообщения, все tunnel сообщения имеют фиксированный размер 1024 байта. Для размещения более крупных I2NP сообщений, а также для более эффективной поддержки меньших, gateway разбивает более крупные I2NP сообщения на фрагменты, содержащиеся в каждом tunnel сообщении. Конечная точка будет пытаться восстановить I2NP сообщение из фрагментов в течение короткого периода времени, но будет отбрасывать их по мере необходимости.

Детали описаны в спецификации tunnel сообщений .

Шифрование шлюза

После предварительной обработки сообщений в дополненную полезную нагрузку, шлюз создает случайное 16-байтовое значение IV, итеративно шифрует его и сообщение tunnel по мере необходимости, и передает кортеж {tunnelID, IV, зашифрованное сообщение tunnel} следующему узлу.

Как выполняется шифрование на gateway, зависит от того, является ли tunnel входящим или исходящим. Для входящих tunnel они просто выбирают случайный IV, постобрабатывают и обновляют его для генерации IV для gateway и используют этот IV вместе со своим собственным ключом слоя для шифрования предварительно обработанных данных. Для исходящих tunnel они должны итеративно расшифровывать (незашифрованный) IV и предварительно обработанные данные с помощью IV и ключей слоя для всех хопов в tunnel. Результат шифрования исходящего tunnel заключается в том, что когда каждый узел шифрует данные, конечная точка восстановит исходные предварительно обработанные данные.

Обработка участника

Когда узел получает сообщение tunnel, он проверяет, что сообщение пришло от того же предыдущего узла, что и раньше (инициализируется при получении первого сообщения через tunnel). Если предыдущий узел является другим router, или если сообщение уже было получено ранее, сообщение отбрасывается. Участник затем шифрует полученный IV с помощью AES256/ECB, используя свой ключ IV для определения текущего IV, использует этот IV с ключом слоя участника для шифрования данных, снова шифрует текущий IV с помощью AES256/ECB, используя свой ключ IV, а затем пересылает кортеж {nextTunnelId, nextIV, encryptedData} следующему узлу. Это двойное шифрование IV (как до, так и после использования) помогает противостоять определенному классу атак подтверждения.

Обнаружение дублированных сообщений обрабатывается с помощью затухающего фильтра Блума по IV сообщений. Каждый router поддерживает единый фильтр Блума, содержащий XOR от IV и первого блока полученного сообщения для всех tunnel, в которых он участвует, модифицированный для удаления просмотренных записей через 10-20 минут (когда tunnel истекут). Размер фильтра Блума и используемые параметры достаточны для более чем полного насыщения сетевого соединения router с незначительной вероятностью ложного срабатывания. Уникальное значение, подаваемое в фильтр Блума, представляет собой XOR от IV и первого блока, чтобы предотвратить возможность неsequential сговаривающихся узлов в tunnel пометить сообщение путем повторной отправки с переставленными IV и первым блоком.

Обработка конечных точек

После получения и валидации сообщения tunnel на последнем переходе в tunnel, способ восстановления данных, закодированных gateway, зависит от того, является ли tunnel входящим или исходящим. Для исходящих tunnel конечная точка шифрует сообщение своим ключом слоя точно так же, как и любой другой участник, раскрывая предварительно обработанные данные. Для входящих tunnel конечная точка также является создателем tunnel, поэтому она может просто итеративно расшифровывать IV и сообщение, используя ключи слоя и IV каждого шага в обратном порядке.

На этом этапе конечная точка туннеля имеет предварительно обработанные данные, отправленные шлюзом, которые она затем может разобрать на включенные I2NP сообщения и переслать их согласно инструкциям доставки.

Построение туннелей

При создании tunnel создатель должен отправить запрос с необходимыми данными конфигурации каждому из хопов и дождаться согласия всех участников перед активацией tunnel. Запросы шифруются таким образом, что только те узлы, которым необходимо знать определенную информацию (например, ключ уровня tunnel или IV), имеют доступ к этим данным. Кроме того, только создатель tunnel будет иметь доступ к ответу узла. При создании tunnel важно учитывать три ключевых аспекта: какие узлы используются (и где), как отправляются запросы (и принимаются ответы), и как они поддерживаются.

Выбор пиров

Помимо двух типов туннелей - входящих и исходящих - существует два стиля выбора узлов, используемых для различных туннелей - исследовательские и клиентские. Исследовательские туннели используются как для обслуживания сетевой базы данных, так и для обслуживания туннелей, в то время как клиентские туннели используются для сквозных клиентских сообщений.

Выбор узлов для исследовательских tunnel

Исследовательские tunnel строятся из случайного выбора узлов из подмножества сети. Конкретное подмножество зависит от локального router и от потребностей в маршрутизации tunnel. В общем случае исследовательские tunnel строятся из случайно выбранных узлов, которые находятся в категории профиля “не отказывающие, но активные”. Вторичная цель tunnel, помимо простой маршрутизации tunnel, состоит в поиске недоиспользуемых узлов высокой пропускной способности, чтобы их можно было повысить для использования в клиентских tunnel.

Исследовательский выбор пиров более подробно обсуждается на странице профилирования и выбора пиров .

Выбор узлов для клиентского tunnel

Клиентские tunnel создаются с более строгим набором требований - локальный router выберет узлы из категории профиля “быстрые и высокой пропускной способности”, чтобы производительность и надежность соответствовали потребностям клиентского приложения. Однако есть несколько важных деталей помимо этого базового выбора, которых следует придерживаться в зависимости от потребностей клиента в анонимности.

Выбор клиентских peer’ов более подробно рассматривается на странице Профилирование и выбор peer’ов .

Упорядочивание пиров в tunnel’ах

Узлы упорядочены внутри tunnel для защиты от атаки предшественника (обновление 2008 ).

Чтобы предотвратить атаку предшественника, выбор tunnel поддерживает строгий порядок выбранных узлов - если A, B и C находятся в tunnel для определенного пула tunnel, переход после A всегда ведет к B, а переход после B всегда ведет к C.

Упорядочивание реализуется путем генерации случайного 32-байтового ключа для каждого tunnel pool при запуске. Узлы не должны иметь возможность угадать порядок, иначе злоумышленник мог бы создать два router hash’а, расположенных далеко друг от друга, чтобы максимизировать шанс оказаться на обоих концах tunnel’я. Узлы сортируются по XOR-расстоянию SHA256 хеша (хеш узла, объединенный со случайным ключом) от случайного ключа:

      p = peer hash
      k = random key
      d = XOR(H(p+k), k)

Поскольку каждый пул tunnel использует разный случайный ключ, упорядочивание согласовано в пределах одного пула, но не между разными пулами. Новые ключи генерируются при каждом перезапуске router.

Доставка запроса

Многосегментный tunnel строится с использованием одного сообщения сборки, которое многократно расшифровывается и пересылается. В терминологии статьи Hashing it out in Public , это «неинтерактивное» телескопическое построение tunnel.

Этот метод подготовки запроса tunnel, доставки и ответа разработан для уменьшения количества раскрываемых предшественников, сокращения числа передаваемых сообщений, проверки правильного соединения и предотвращения атаки подсчета сообщений при традиционном телескопическом создании tunnel. (Этот метод, который отправляет сообщения для расширения tunnel через уже установленную часть tunnel, называется “интерактивным” телескопическим построением tunnel в статье “Hashing it out”.)

Детали сообщений запроса и ответа tunnel, а также их шифрование, указаны здесь .

Узлы могут отклонять запросы на создание туннелей по различным причинам, хотя известны четыре типа отказов с возрастающей степенью серьезности: вероятностный отказ (из-за приближения к пределу пропускной способности router’а или в ответ на поток запросов), временная перегрузка, перегрузка по пропускной способности и критический сбой. При получении этих четырех типов отказов создатель туннеля интерпретирует их, чтобы скорректировать свой профиль соответствующего router’а.

Для получения дополнительной информации о профилировании пиров см. страницу Профилирование и выбор пиров .

Пулы туннелей

Для обеспечения эффективной работы router поддерживает серию пулов туннелей, каждый из которых управляет группой туннелей, используемых для конкретной цели с собственной конфигурацией. Когда туннель нужен для этой цели, router случайным образом выбирает один из соответствующего пула. В целом, существует два исследовательских пула туннелей - один входящий и один исходящий - каждый использует конфигурацию router по умолчанию. Кроме того, есть пара пулов для каждого локального назначения - один входящий и один исходящий пул туннелей. Эти пулы используют конфигурацию, указанную при подключении локального назначения к router через I2CP , или настройки router по умолчанию, если не указано иное.

Каждый пул содержит в своей конфигурации несколько ключевых настроек, определяющих, сколько tunnel следует поддерживать активными, сколько резервных tunnel сохранять на случай сбоя, какой длины должны быть tunnel, следует ли рандомизировать эти длины, а также любые другие настройки, разрешенные при настройке отдельных tunnel. Параметры конфигурации указаны на странице I2CP .

Длина Tunnel и значения по умолчанию

На странице обзора tunnel .

Упреждающая стратегия сборки и приоритеты

Построение tunnel является дорогостоящим, и tunnel истекают через фиксированное время после их создания. Однако, когда пул исчерпывает tunnel, Destination по сути становится мёртвым. Кроме того, успешность построения tunnel может сильно варьироваться в зависимости как от локальных, так и от глобальных условий сети. Поэтому важно поддерживать упреждающую, адаптивную стратегию построения, чтобы обеспечить успешное создание новых tunnel до того, как они понадобятся, не создавая избыточных tunnel, не строя их слишком рано и не потребляя слишком много CPU или пропускной способности на создание и отправку зашифрованных сообщений построения.

Для каждого кортежа {exploratory/client, in/out, length, length variance} router ведет статистику времени, необходимого для успешной сборки tunnel. Используя эту статистику, он рассчитывает, за сколько времени до истечения срока действия tunnel следует начать попытки построения замены. По мере приближения времени истечения без успешной замены, он запускает несколько попыток сборки параллельно, а затем при необходимости увеличивает количество параллельных попыток.

Для ограничения пропускной способности и использования процессора, router также ограничивает максимальное количество одновременных попыток построения для всех пулов. Критические построения (для исследовательских tunnel и для пулов, в которых закончились tunnel) имеют приоритет.

Ограничение пропускной способности сообщений tunnel

Несмотря на то, что tunnel в I2P напоминают сеть с коммутацией каналов, всё в I2P строго основано на сообщениях — tunnel являются лишь учётными приёмами, помогающими организовать доставку сообщений. Никаких предположений относительно надёжности или упорядочивания сообщений не делается, а повторные передачи оставлены на более высокие уровни (например, клиентская потоковая библиотека I2P). Это позволяет I2P использовать преимущества методов регулирования пропускной способности, доступных как сетям с коммутацией пакетов, так и сетям с коммутацией каналов. Например, каждый router может отслеживать скользящее среднее количества данных, используемых каждым tunnel, объединять это со всеми средними значениями, используемыми другими tunnel, в которых участвует router, и принимать или отклонять дополнительные запросы на участие в tunnel на основе своей пропускной способности и загрузки. С другой стороны, каждый router может просто отбрасывать сообщения, превышающие его возможности, используя исследования, применяемые в обычном Интернете.

В текущей реализации router’ы используют стратегию взвешенного случайного раннего сброса (WRED). Для всех участвующих router’ов (внутренний участник, входящий gateway и исходящая конечная точка) router начинает случайно сбрасывать часть сообщений по мере приближения к ограничениям пропускной способности. По мере приближения трафика к ограничениям или их превышения сбрасывается больше сообщений. Для внутреннего участника все сообщения фрагментированы и дополнены заполнением, поэтому имеют одинаковый размер. Однако на входящем gateway и исходящей конечной точке решение о сбросе принимается для полного (объединенного) сообщения, и размер сообщения учитывается. Более крупные сообщения с большей вероятностью будут сброшены. Кроме того, сообщения с большей вероятностью сбрасываются на исходящей конечной точке, чем на входящем gateway, поскольку эти сообщения не прошли столь “далеко” в своем путешествии, и таким образом сетевая стоимость сброса этих сообщений ниже.

Будущая работа

Смешивание/Пакетирование

Какие стратегии могут использоваться на шлюзе и на каждом узле для задержки, изменения порядка, перенаправления или заполнения сообщений? В какой степени это должно выполняться автоматически, сколько должно настраиваться как параметр для каждого tunnel или каждого узла, и как создатель tunnel (и, в свою очередь, пользователь) должен управлять этой операцией? Всё это остаётся неизвестным и должно быть проработано для будущих релизов.

Заполнение

Стратегии заполнения могут использоваться на различных уровнях, решая проблему утечки информации о размере сообщений различным противникам. Текущий фиксированный размер сообщения tunnel составляет 1024 байта. Однако внутри этого фрагментированные сообщения сами по себе вообще не дополняются tunnel, хотя для сквозных сообщений они могут быть дополнены как часть garlic-обёртки.

WRED

Стратегии WRED оказывают значительное влияние на сквозную производительность и предотвращение коллапса сетевых перегрузок. Текущая стратегия WRED должна быть тщательно оценена и улучшена.