ПРИМЕЧАНИЕ: Ниже приводится обсуждение причин, лежащих в основе системы наименования I2P, распространенных аргументов и возможных альтернатив. Текущую документацию см. на странице именования.

Отвергнутые альтернативы

Именование в рамках I2P с самого начала было предметом долгих споров сторонников по всему спектру возможностей. Однако, учитывая присущие I2P требование безопасной связи и децентрализованной работы, традиционная система именования в стиле DNS, равно как и система голосования по "правилам большинства", явно исключены.

Однако I2P не поощряет использование DNS-подобных сервисов, поскольку ущерб от захвата сайта может быть огромным, а незащищенные адресаты не имеют никакой ценности. DNSsec сам по себе по-прежнему опирается на регистраторов и центры сертификации, в то время как в I2P запросы, отправленные в пункт назначения, невозможно перехватить или подделать ответ, поскольку они зашифрованы в открытых ключах адреса назначения, а сам адрес назначения - это просто пара открытых ключей и сертификат. С другой стороны, системы в стиле DNS позволяют любому из серверов имен на пути поиска проводить простые атаки типа "отказ в обслуживании" и "подмена". Добавление сертификата, подтверждающего подлинность ответов, подписанных централизованным центром сертификации, решит многие проблемы враждебных серверов имен, но оставит открытыми атаки воспроизведения, а также атаки враждебных центров сертификации.

Именование в стиле голосования также опасно, особенно учитывая эффективность атак Sybil в анонимных системах - злоумышленник может просто создать произвольно большое число пиров и "голосовать" с каждого, чтобы завладеть заданным именем. Методы проверки работоспособности могут быть использованы для того, чтобы сделать идентификацию несвободной, но по мере роста сети нагрузка, необходимая для связи со всеми для проведения онлайн-голосования, становится невероятной, или, если не запрашивается вся сеть, могут быть доступны разные наборы ответов.

Однако, как и в случае с Интернетом, I2P не допускает разработку и эксплуатацию системы именования на коммуникационном уровне (IP-подобном). Комплектная библиотека именования включает простой интерфейс поставщика услуг, к которому могут подключаться альтернативные системы именования , что позволяет конечным пользователям самим определять, какие компромиссы в именовании они предпочитают.

Discussion

См. также Имена: Децентрализованный, Безопасный, Человекозначимый: Выберите два.

Comments by jrandom

(адаптировано из поста в старом Syndie, 26 ноября 2005 года)

Вопрос: Что делать, если несколько хостов не согласны с одним адресом, и если одни адреса работают, другие нет? Кто является правильным источником имени?

Ответ: Не вы. На самом деле есть критическое различие между именами в I2P и тем, как работают DNS - имена в I2P читаемы человеком, безопасны, но не уникальны глобально . Это сделано специально и является неотъемлемой частью нашей потребности в безопасности.

Если бы мне удалось каким-то образом убедить вас изменить назначение, связанное с каким-то именем, я бы успешно "захватил" сайт, а это недопустимо ни при каких обстоятельствах. Вместо этого мы делаем имена локально уникальными: они являются тем, что вы раньше называли сайтом, точно так же, как вы можете называть вещи как угодно, когда добавляете их в закладки браузера или в список друзей вашего IM-клиента. Тот, кого вы называете "Босс", может быть тем, кого кто-то другой называет "Салли".

Имена никогда не будут надежно читаемы человеком и глобально уникальны.

Comments by zzz

Ниже от zzz приводится обзор нескольких распространенных жалоб на систему именования I2P.

• Неэффективность: Загружается весь hosts.txt (если он изменился, так как eepget использует заголовки etag и last-modified). Сейчас цифра составляет около 400K для почти 800 хостов.

  Верно, но это не так много трафика в контексте i2p, который сам по себе дико неэффективен (переполненные базы данных, огромные накладные расходы на шифрование и изменение размера, чесночная маршрутизация и т.д.). Если вы скачиваете у кого-то файл hosts.txt каждые 12 часов, это в среднем составляет около 10 байт/сек.

  Как это обычно бывает в i2p, здесь существует фундаментальный компромисс между анонимностью и эффективностью. Некоторые говорят, что использование заголовков etag и last-modified опасно, поскольку раскрывает время последнего запроса данных. Другие предлагают запрашивать только конкретные ключи (подобно тому, как это делают сервисы jump, но более автоматизированным способом), возможно, с дополнительными затратами на анонимность.

  Возможными улучшениями могут быть замена или дополнение адресной книги (см. i2host.i2p.xyzp), или что-то простое, например, подписка на http://example.i2p/cgi-bin/recenthosts.cgi, а не на http://example.i2p/hosts.txt. Если бы гипотетический recenthosts.cgi распределил все хосты за последние 24 часа, например, это могло бы быть и более эффективным, и более анонимным, чем текущий hosts.txt с last-modified и etag.

  Пример реализации находится на stats.i2p http://stats.i2p/cgi-bin/newhosts.txt. Этот скрипт возвращает Etag с временной меткой. Когда приходит запрос с etag'ом If-None-Match, скрипт возвращает ТОЛЬКО новые хосты с этой временной метки, или 304 Not Modified, если их нет. Таким образом, скрипт эффективно возвращает только те хосты, о которых абонент не знает, совместимым с адресной книгой образом.

  Таким образом, неэффективность не является большой проблемой, и есть несколько способов улучшить ситуацию без радикальных изменений.

• Не масштабируется: 400K hosts.txt (с линейным поиском) не так уж велик на данный момент и мы можем вырасти в 10 или 100 раз, прежде чем это станет проблемой.

  Что касается сетевого трафика, см. выше. Но если вы не собираетесь выполнять медленный запрос в реальном времени по сети для получения ключа, вам нужно хранить весь набор ключей локально, затрачивая около 500 байт на ключ.

• Требуется настройка и "trust": Встроенная адресная книга подписана только на http://www.i2p2.i2p/hosts.txt, которая редко обновляется, что приводит к плохому опыту новых пользователей.

  Это сделано намеренно. jrandom хочет, чтобы пользователь "доверял" провайдеру hosts.txt. а, как он любит говорить, "доверие - это не булева величина". Шаг настройки пытается заставить пользователей задуматься о вопросах доверия в анонимной сети.

  В качестве другого примера, страница ошибки "I2P Site Unknown" в HTTP Proxy перечисляет некоторые сервисы передачи управления, но не "рекомендует" какой-либо конкретный, и пользователь сам решает, выбрать его (или нет). jrandom сказал бы, что мы достаточно доверяем перечисленным провайдерам, чтобы перечислить их, но не настолько, чтобы автоматически получать от них ключ.

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

• Это - не DNS

  К сожалению, поиск в реальном времени через i2p значительно замедляет просмотр веб-страниц.

  Кроме того, DNS основан на поиске с ограниченным кэшированием и временем жизни, в то время как i2p-ключи являются постоянными.

  Конечно, мы могли бы сделать так, чтобы это работало, но зачем? Это плохой вариант.

• Не надежен: Зависит от конкретных серверов для подписки на адресную книгу.

  Да, это зависит от нескольких серверов, которые вы настроили. В рамках i2p серверы и сервисы приходят и уходят. Любая другая централизованная система (например, корневые серверы DNS) будет иметь ту же проблему. Полностью децентрализованная система (каждая является авторитетной) возможна путем реализации решения "каждый является корневым DNS-сервером" или чего- то еще более простого, например, скрипта, который добавляет всех в ваш hosts.txt в адресную книгу.

  Однако, люди, выступающие за все-авторитарные решения, как правило, не продумали вопросы конфликтов и хайжекинга.

• Неудобный режим не реального времени: Это лоскутное одеяло из провайдеров hosts.txt, провайдеров веб-форм для добавления ключей, провайдеров сервисов переходов, отчеты о состоянии сайта I2P. Серверы переходов и подписки - это боль, они должно работать как DNS.

  См. разделы "Надежность" и "Доверие".

Итак, в целом, текущая система не является ужасно сломанной, неэффективной или немасштабируемой, и предложения "просто использовать DNS" не являются хорошо продуманными.

Альтернативы

Исходный код I2P содержит несколько подключаемых систем именования и поддерживает параметры конфигурации, позволяющие экспериментировать с системами именования.

• Meta — вызывает две или более других систем именования в установленном порядке. По умолчанию сначала вызывает PetName, потом HostsTxt.
• PetName — Производит поиск в файле petnames.txt. Формат этого файла НЕ совпадает с hosts.txt.
• HostsTxt — Производит поиск в следующих файлах в порядке:
1. privatehosts.txt
2. userhosts.txt
3. hosts.txt
• AddressDB - каждый хост перечислен в отдельном файле в каталоге addressDb/.
• Eepget - выполняет HTTP-запрос на поиск с внешнего сервера. Сервер должен быть уложен после поиска HostsTxt с помощью Meta. Это может дополнить или заменить систему переходов. Включает кэширование в памяти.
• Exec - вызывает внешнюю программу для поиска, позволяет дополнительные эксперименты со схемами поиска, независимо от java. Может использоваться после HostsTxt или как единственная система именования. Включает кэширование в памяти.
• Dummy - используется в качестве запасного варианта для имен Base64, в противном случае не работает.

Текущая система именования может быть изменена в дополнительных настройках 'i2p.naming.impl' (требуется перезагрузка). Подробнее см. core/java/src/net/i2p/client/naming.

Любая новая система должна быть дополнена HostsTxt, или должна реализовать локальное хранение и/или функции подписки на адресную книгу, поскольку адресная книга знает только о файлах и формате hosts.txt.

Сертификаты

Адреса I2P содержат сертификат, однако в настоящее время этот сертификат всегда является нулевым. При нулевом сертификате адресаты в формате base64 всегда имеют 516 байт, заканчивающиеся на "AAAA", и это проверяется в механизме слияния адресной книги и, возможно, в других местах. Кроме того, не существует метода для генерации сертификата или добавления его к месту назначения. Поэтому их придется обновить, чтобы реализовать сертификаты.

Одно возможное применение сертификатов proof of work.

Другой вариант - "поддомены" (в кавычках, потому что на самом деле такого понятия не существует, i2p использует плоскую систему именования) должны подписываться ключами домена второго уровня.

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

Добавление сертификата, подтверждающего подлинность ответов, подписанных каким-либо централизованным центром сертификации, решило бы многие проблемы враждебного сервера имен, но оставило бы открытыми атаки воспроизведения, а также атаки враждебного центра сертификации.