Обзор
Начиная с выпуска 0.9.32, обновите спецификацию netdb, чтобы устареть имена хостов в информации о маршрутизаторах, точнее, в отдельных адресах маршрутизаторов. Во всех реализациях I2P маршрутизаторы, настроенные с использованием имен хостов, должны заменять имена хостов на IP-адреса перед публикацией, и другие маршрутизаторы должны игнорировать адреса с именами хостов. Маршрутизаторы не должны выполнять DNS-запросы опубликованных имен хостов.
Мотивация
Имена хостов разрешены в адресах маршрутизаторов с самого начала I2P. Однако очень немногие маршрутизаторы публикуют имена хостов, так как это требует как публичного имени хоста (которое мало кто имеет), так и ручной настройки (которую мало кто делает). В недавней выборке 0,7% маршрутизаторов публиковали имя хоста.
Изначальная цель имен хостов заключалась в том, чтобы помочь пользователям с часто меняющимися IP и динамическим DNS сервисом (таким как http://dyn.com/dns/) не терять связь при смене их IP. Однако тогда сеть была маленькой, и истечение срока действия информации о маршрутизаторах было дольше. Также код Java не имел рабочей логики для перезапуска маршрутизатора или перепубликации информации о маршрутизаторах при смене локального IP.
Также в начале I2P не поддерживал IPv6, так что проблемы с резолвингом имени хоста в адреса IPv4 или IPv6 не существовало.
В Java I2P всегда было вызовом пропагандировать настроенное имя хоста в оба опубликованных транспорта, и ситуация стала более сложной с IPv6. Неясно, должен ли хост с двумя стеками публиковать как имя хоста, так и литеральный адрес IPv6 или нет. Имя хоста публикуется для адреса SSU, но не для адреса NTCP.
Недавно вопросы DNS были подняты (как косвенно, так и прямо) в ходе исследования в Georgia Tech. Исследователи запустили большое количество заливных маршрутизаторов с опубликованными именами хостов. Непосредственная проблема заключалась в том, что для небольшого количества пользователей с возможными проблемами локального DNS это полностью загружало I2P.
Более крупной проблемой был DNS в общем, и то, как DNS (как активный, так и пассивный) может быть использован для быстрого перечисления сети, особенно если публикующие маршрутизаторы были заливными. Недопустимые имена хостов или неотзывчивые, медленные или вредоносные DNS-ответчики могли бы быть использованы для дополнительных атак. EDNS0 может предоставить дальнейшие сценарии перечисления или атак. DNS также может предоставить векторы атак на основе времени запроса, раскрывая время соединений маршрутизатор-до-маршрутизатора, помогая строить графы соединений, оценивать трафик и другие предположения.
Также группа из Georgia Tech, возглавляемая Дэвидом Дагоном, перечислила несколько опасений по поводу DNS в приложениях, ориентированных на конфиденциальность. DNS-запросы, как правило, выполняются библиотекой низкого уровня, не контролируемой приложением. Эти библиотеки не были специально разработаны для анонимности; могут не предоставлять точный контроль приложением; и их выходные данные могут быть сняты с отпечатков. Библиотеки Java в частности могут быть проблематичны, но это не только проблема Java. Некоторые библиотеки используют DNS ANY-запросы, которые могут быть отвергнуты. Все это усугубляется широким присутствием пассивного мониторинга DNS и запросов, доступных нескольким организациям. Все мониторинг DNS и атаки происходят вне полосы с точки зрения маршрутизаторов I2P и требуют мало или вообще не требуют ресурсов I2P внутри сети, и не требуют модификации существующих реализаций.
Хотя мы не полностью продумали возможные проблемы, поверхность атаки кажется большой. Существуют другие методы перечисления сети и сбора связанных данных, но атаки DNS могут быть значительно проще, быстрее и менее обнаружимы.
Реализации маршрутизаторов могли бы, теоретически, переключиться на использование сложной сторонней библиотеки DNS, но это было бы весьма сложным, обременительным для обслуживания, и выходит далеко за рамки основной компетенции разработчиков I2P.
Немедленные решения, реализованные в Java 0.9.31, включали исправление проблемы зависания, увеличение времени кэширования DNS и реализацию отрицательного кэша DNS. Конечно, увеличение времени кэширования снижает выгодность наличия имен хостов в информации о маршрутизаторах изначально.
Однако эти изменения являются лишь краткосрочными мерами и не устраняют вышеуказанные основные проблемы. Поэтому, самое простое и наиболее полное решение - запретить имена хостов в информации о маршрутизаторах, исключив тем самым DNS-запросы для них.
Дизайн
Для кода публикации информации о маршрутизаторах, у разработчиков есть два варианта: либо отключить/удалить опцию конфигурации для имен хостов, либо преобразовать настроенные имена хостов в IP при публикации. В любом случае, маршрутизаторы должны перепубликовывать немедленно при изменении их IP.
Для кода проверки информации о маршрутизаторах и подключений транспорта, разработчики должны игнорировать адреса маршрутизаторов, содержащие имена хостов, и использовать другие опубликованные адреса, содержащие IP, если таковые имеются. Если ни один адрес в информации о маршрутизаторе не содержит IP, маршрутизатор не должен подключаться к опубликованному маршрутизатору. В любом случае, маршрутизатор не должен выполнять DNS-запросы опубликованного имени хоста, ни напрямую, ни через основную библиотеку.
Спецификация
Измените спецификации транспорта NTCP и SSU, чтобы указать, что параметр “host” должен быть IP-адресом, а не именем хоста, и что маршрутизаторы должны игнорировать отдельные адреса маршрутизаторов, содержащие имена хостов.
Это также применимо к параметрам “ihost0”, “ihost1” и “ihost2” в адресе SSU. Маршрутизаторы должны игнорировать адреса вводных узлов, содержащие имена хостов.
Примечания
Это предложение не касается имен хостов для хостов повторной загрузки. Хотя DNS-запросы для хостов повторной загрузки намного реже, они все еще могут представлять проблему. Если необходимо, это можно исправить просто заменив имена хостов на IP в жестко заданном списке URL; никакие изменения спецификации или кода не будут необходимы.
Миграция
Это предложение может быть реализовано немедленно, без постепенной миграции, поскольку очень немногие маршрутизаторы публикуют имена хостов, и те, которые это делают, обычно не публикуют имя хоста во всех адресах.
Маршрутизаторы не нужно проверять версию опубликованного маршрутизатора перед решением игнорировать имена хостов, и нет необходимости в скоординированном выпуске или общей стратегии между разными реализациями маршрутизаторов.
Для тех маршрутизаторов, которые все еще публикуют имена хостов, они будут получать меньше входящих соединений и, возможно, со временем столкнутся с трудностями при создании входящих туннелей.
Для дополнительного минимизации воздействия разработчики могли бы начать с игнорирования адресов маршрутизаторов с именами хостов только для заливных маршрутизаторов, или для маршрутизаторов с опубликованной версией менее 0.9.32, и игнорировать имена хостов для всех маршрутизаторов в более позднем выпуске.