Примечание: Этот документ содержит устаревшую информацию об альтернативах текущей реализации tunnel в I2P и предположения о будущих возможностях. Актуальную информацию смотрите на странице tunnel .
Эта страница документирует текущую реализацию построения tunnel по состоянию на релиз 0.6.1.10. Более старый метод построения tunnel, использовавшийся до релиза 0.6.1.10, задокументирован на странице старых tunnel .
Альтернативы конфигурации
Помимо их длины, для каждого tunnel могут использоваться дополнительные настраиваемые параметры, такие как ограничение частоты доставки сообщений, способ использования заполнения, продолжительность работы tunnel, необходимость внедрения ложных сообщений и какие стратегии группировки следует применять, если таковые имеются. В настоящее время ни один из этих параметров не реализован.
Альтернативы заполнения
Возможно несколько стратегий заполнения tunnel, каждая со своими преимуществами:
- Без заполнения
- Заполнение до случайного размера
- Заполнение до фиксированного размера
- Заполнение до ближайшего КБ
- Заполнение до ближайшего экспоненциального размера (2^n байт)
Эти стратегии дополнения можно использовать на различных уровнях, устраняя раскрытие информации о размере сообщений для разных противников. После сбора и анализа статистики из сети 0.4, а также изучения компромиссов анонимности, мы начинаем с фиксированного размера tunnel сообщения в 1024 байта. Однако внутри этого фрагментированные сообщения сами по себе вообще не дополняются tunnel (хотя для сквозных сообщений они могут быть дополнены как часть garlic wrapping).
Альтернативы фрагментации
Чтобы предотвратить возможность противников маркировать сообщения по пути путем изменения размера сообщения, все сообщения tunnel имеют фиксированный размер 1024 байта. Для размещения более крупных I2NP сообщений, а также для более эффективной поддержки меньших сообщений, gateway разделяет крупные I2NP сообщения на фрагменты, содержащиеся в каждом сообщении tunnel. Конечная точка будет пытаться восстановить I2NP сообщение из фрагментов в течение короткого периода времени, но при необходимости отбросит их.
Router-ы имеют большую свободу действий в том, как располагаются фрагменты - размещаются ли они неэффективно как отдельные единицы, группируются на короткий период для размещения большего количества полезной нагрузки в 1024-байтных tunnel сообщениях, или оппортунистически дополняются другими сообщениями, которые шлюз хотел отправить.
Другие альтернативы
Настройка обработки tunnel в процессе
Хотя простого алгоритма маршрутизации tunnel должно быть достаточно для большинства случаев, существуют три альтернативы, которые можно рассмотреть:
- Заставить peer’а, отличного от конечной точки, временно выступать в качестве точки завершения для tunnel’а путем корректировки шифрования, используемого на gateway, чтобы предоставить им plaintext предварительно обработанных I2NP сообщений. Каждый peer мог бы проверить, есть ли у него plaintext, обрабатывая сообщение при получении, как если бы у него он был.
- Разрешить router’ам, участвующим в tunnel’е, перемешивать сообщение перед его пересылкой - отправляя его через один из собственных исходящих tunnel’ей этого peer’а с инструкциями для доставки к следующему узлу.
- Реализовать код для создателя tunnel’а для переопределения “следующего узла” peer’а в tunnel’е, обеспечивая дальнейшее динамическое перенаправление.
Использование двунаправленных tunnel
Текущая стратегия использования двух отдельных tunnel для входящей и исходящей коммуникации не является единственной доступной техникой, и она имеет последствия для анонимности. С положительной стороны, использование отдельных tunnel уменьшает объем трафика, доступного для анализа участникам tunnel - например, узлы в исходящем tunnel из веб-браузера видели бы только трафик HTTP GET, в то время как узлы во входящем tunnel видели бы полезную нагрузку, доставляемую через tunnel. При двунаправленных tunnel все участники имели бы доступ к информации о том, что, например, 1КБ был отправлен в одном направлении, затем 100КБ в другом. С отрицательной стороны, использование однонаправленных tunnel означает, что существует два набора узлов, которые необходимо профилировать и учитывать, и необходимо принимать дополнительные меры для решения проблемы ускорения атак предшественников. Процесс объединения в пулы и построения tunnel, описанный ниже, должен минимизировать опасения по поводу атак предшественников, хотя если бы это было желательно, не составило бы большого труда построить как входящие, так и исходящие tunnel через одни и те же узлы.
Связь по обратному каналу
В настоящий момент используемые значения IV являются случайными. Однако возможно использовать эти 16 байт для отправки управляющих сообщений от gateway к endpoint, или в исходящих tunnel — от gateway к любому из участников. Входящий gateway мог бы закодировать определенные значения в IV один раз, которые endpoint смог бы восстановить (поскольку он знает, что endpoint также является создателем). Для исходящих tunnel создатель мог бы передавать определенные значения участникам во время создания tunnel (например, “если вы видите 0x0 как IV, это означает X”, “0x1 означает Y” и т.д.). Поскольку gateway в исходящем tunnel также является создателем, они могут построить IV таким образом, чтобы любой из участников получил правильное значение. Создатель tunnel мог бы даже дать gateway входящего tunnel серию значений IV, которые этот gateway мог бы использовать для связи с отдельными участниками ровно один раз (хотя это создало бы проблемы в отношении обнаружения сговора).
Данная техника может быть позже использована для доставки сообщений в середине потока или для того, чтобы позволить входящему шлюзу сообщить конечной точке о том, что она подвергается DoS-атаке или иным образом вскоре выйдет из строя. В настоящий момент нет планов по использованию этого обратного канала.
Сообщения tunnel переменного размера
Хотя транспортный уровень может иметь свой собственный фиксированный или переменный размер сообщений, используя собственную фрагментацию, уровень tunnel может вместо этого использовать сообщения tunnel переменного размера. Разница заключается в вопросе моделей угроз - фиксированный размер на транспортном уровне помогает уменьшить информацию, доступную внешним противникам (хотя общий анализ трафика все еще работает), но для внутренних противников (то есть участников tunnel) размер сообщения раскрывается. Сообщения tunnel фиксированного размера помогают уменьшить информацию, доступную участникам tunnel, но не скрывают информацию, доступную конечным точкам tunnel и шлюзам. Сообщения фиксированного размера от конца до конца скрывают информацию, доступную всем узлам в сети.
Как всегда, это вопрос того, от кого I2P пытается защитить. Сообщения tunnel переменного размера опасны, поскольку они позволяют участникам использовать сам размер сообщения как скрытый канал связи с другими участниками - например, если вы видите сообщение размером 1337 байт, вы находитесь в том же tunnel, что и другой сговорившийся узел. Даже при фиксированном наборе допустимых размеров (1024, 2048, 4096 и т.д.) этот скрытый канал все еще существует, поскольку узлы могут использовать частоту появления каждого размера как носитель информации (например, два сообщения по 1024 байта, за которыми следует одно на 8192). Сообщения меньшего размера действительно влекут за собой накладные расходы на заголовки (IV, tunnel ID, хеш-часть и т.д.), но сообщения большего фиксированного размера либо увеличивают задержку (из-за группировки), либо резко увеличивают накладные расходы (из-за заполнения). Фрагментация помогает амортизировать накладные расходы за счет потенциальной потери сообщений из-за утерянных фрагментов.
Атаки по времени также актуальны при оценке эффективности сообщений фиксированного размера, хотя для их успешного проведения требуется существенный обзор шаблонов сетевой активности. Чрезмерные искусственные задержки в tunnel будут обнаружены создателем tunnel из-за периодического тестирования, что приведет к отбрасыванию всего tunnel и корректировке профилей узлов внутри него.
Создание альтернатив
Ссылка: Hashing it out in Public
Старый метод построения tunnel
Старый метод построения tunnel, использовавшийся до версии 0.6.1.10, задокументирован на странице старых tunnel . Это был метод “все сразу” или “параллельный”, при котором сообщения отправлялись параллельно каждому из участников.
Одноразовое телескопическое построение
ПРИМЕЧАНИЕ: Это текущий метод.
Один вопрос, который возник относительно использования исследовательских tunnels для отправки и получения сообщений создания tunnel, заключается в том, как это влияет на уязвимость tunnel к атакам предшественников. Хотя конечные точки и gateways этих tunnels будут случайно распределены по сети (возможно, даже включая создателя tunnel в этот набор), другой альтернативой является использование самих путей tunnel для передачи запросов и ответов, как это делается в Tor . Однако это может привести к утечкам во время создания tunnel, позволяя узлам обнаружить, сколько прыжков находится дальше в tunnel, путем мониторинга времени или количества пакетов при построении tunnel.
“Интерактивное” телескопическое построение
Построить переходы по одному с сообщением через существующую часть туннеля для каждого. Имеет серьёзные проблемы, поскольку узлы могут подсчитывать сообщения, чтобы определить своё местоположение в туннеле.
Неисследовательские туннели для управления
Второй альтернативой процесса построения tunnel является предоставление router дополнительного набора неисследовательских входящих и исходящих пулов, используя их для запроса и ответа tunnel. Предполагая, что router имеет хорошо интегрированное представление о сети, это не должно быть необходимым, но если router был каким-то образом разделен, использование неисследовательских пулов для управления tunnel уменьшило бы утечку информации о том, какие узлы находятся в разделе router.
Доставка разведочных запросов
Третья альтернатива, использовавшаяся до версии I2P 0.6.1.10, применяла garlic encryption к отдельным сообщениям запросов tunnel и доставляла их к узлам по отдельности, передавая их через исследовательские tunnel с ответами, возвращающимися через отдельный исследовательский tunnel. Эта стратегия была отброшена в пользу той, что описана выше.
Дополнительная история и обсуждение
До введения Variable Tunnel Build Message существовало как минимум две проблемы:
- Размер сообщений (вызванный максимумом в 8 hop’ов, когда типичная длина tunnel составляет 2 или 3 hop’а… и текущие исследования показывают, что более 3 hop’ов не повышает анонимность);
- Высокий процент неудачных построений, особенно для длинных (и исследовательских) tunnel’ей, поскольку все hop’ы должны согласиться, иначе tunnel отбрасывается.
VTBM исправил #1 и улучшил #2.
Welterde предложил модификации параллельного метода для обеспечения возможности реконфигурации. Sponge предложил использовать некие «токены».
Любой студент, изучающий построение tunnel, должен изучить исторические записи, ведущие к текущему методу, особенно различные уязвимости анонимности, которые могут существовать в различных методах. Архивы почты за октябрь 2005 года особенно полезны. Как указано в спецификации создания tunnel , текущая стратегия возникла во время обсуждения в списке рассылки I2P между Майклом Роджерсом, Мэттью Тоузландом (toad) и jrandom касательно атаки предшественника.
Альтернативы упорядочивания пиров
Также возможен менее строгий порядок, гарантирующий, что хотя узел после A может быть B, B никогда не может быть перед A. Другие варианты конфигурации включают возможность фиксации только входных шлюзов tunnel и конечных точек исходящих tunnel, или их ротацию с частотой MTBF.
Смешивание/Группировка
Какие стратегии должны использоваться на шлюзе и на каждом переходе для задержки, изменения порядка, перенаправления или добавления заполняющих данных к сообщениям? В какой степени это должно делаться автоматически, сколько должно настраиваться как параметр для каждого tunnel или каждого перехода, и как создатель tunnel (и, в свою очередь, пользователь) должен контролировать эту операцию? Все это остается неизвестным и должно быть проработано для будущего выпуска.