ПРИМЕЧАНИЕ: Ниже приводится обсуждение причин создания системы именования I2P, общих аргументов и возможных альтернатив. Текущую документацию смотрите на странице именования .
Отклоненные альтернативы
Именование в I2P было предметом частых дебатов с самого начала, с защитниками по всему спектру возможностей. Однако, учитывая врожденную потребность I2P в безопасной связи и децентрализованной работе, традиционная система именования в стиле DNS явно не подходит, как и системы голосования “правит большинство”.
I2P не поощряет использование DNS-подобных сервисов, поскольку ущерб от перехвата сайта может быть огромным - а незащищенные destination не имеют ценности. DNSsec по-прежнему полагается на регистраторов и центры сертификации, в то время как в I2P запросы, отправленные на destination, не могут быть перехвачены или подделаны ответы, поскольку они зашифрованы открытыми ключами destination, а само destination - это просто пара открытых ключей и сертификат. DNS-системы, с другой стороны, позволяют любому из серверов имен на пути поиска осуществлять простые атаки типа отказ в обслуживании и подмена данных. Добавление сертификата, аутентифицирующего ответы как подписанные каким-либо централизованным центром сертификации, решило бы многие проблемы враждебных серверов имен, но оставило бы открытыми атаки повторного воспроизведения, а также атаки враждебных центров сертификации.
Именование на основе голосования также опасно, особенно учитывая эффективность атак Сибиллы в анонимных системах - злоумышленник может просто создать произвольно большое количество узлов и “проголосовать” каждым из них, чтобы захватить контроль над определенным именем. Методы proof-of-work могут использоваться для того, чтобы создание идентичности не было бесплатным, но по мере роста сети нагрузка, необходимая для связи со всеми участниками для проведения онлайн-голосования, становится неосуществимой, или если не опрашивается вся сеть, могут быть получены различные наборы ответов.
Однако, как и в случае с Интернетом, I2P выносит проектирование и функционирование системы имен за пределы коммуникационного уровня (аналогичного IP). Встроенная библиотека имен включает простой интерфейс поставщика услуг, к которому могут подключаться альтернативные системы именования , позволяя конечным пользователям выбирать предпочтительные компромиссы в области именования.
Обсуждение
См. также Names: Decentralized, Secure, Human-Meaningful: Choose Two .
Комментарии от jrandom
(адаптировано из поста в старом Syndie, 26 ноября 2005 г.)
В: Что делать, если некоторые хосты не согласны с одним адресом и если некоторые адреса работают, а другие нет? Кто является правильным источником имени?
О: Вы не можете. Это фундаментальное различие между именами в I2P и работой DNS - имена в I2P читаемы человеком, безопасны, но не глобально уникальны. Это сделано намеренно и является неотъемлемой частью наших требований к безопасности.
Если бы я мог каким-то образом убедить вас изменить destination, связанный с каким-то именем, я бы успешно “захватил” сайт, и это недопустимо ни при каких обстоятельствах. Вместо этого мы делаем имена локально уникальными: они представляют то, как вы называете сайт, точно так же, как вы можете называть что угодно как угодно, когда добавляете их в закладки браузера или список контактов в мессенджере. Тот, кого вы называете “Босс”, может быть тем, кого кто-то другой называет “Салли”.
Имена никогда не будут одновременно безопасными для человеческого восприятия и глобально уникальными.
Комментарии от zzz
Следующий текст от zzz представляет собой обзор нескольких распространенных жалоб на систему именования I2P.
- Неэффективность: Весь файл hosts.txt загружается (если он изменился, поскольку eepget использует заголовки etag и last-modified). Сейчас он занимает около 400К для почти 800 хостов.
Верно, но это не так много трафика в контексте I2P, который сам по себе крайне неэффективен (floodfill базы данных, огромные накладные расходы на шифрование и дополнение, garlic routing и т.д.). Если вы загружаете файл hosts.txt от кого-то каждые 12 часов, это в среднем составляет около 10 байт/сек.
Как это обычно бывает в I2P, здесь существует фундаментальный компромисс между анонимностью и эффективностью. Некоторые считают, что использование заголовков etag и last-modified представляет опасность, поскольку раскрывает, когда вы последний раз запрашивали данные. Другие предлагают запрашивать только определенные ключи (аналогично тому, что делают jump-сервисы, но в более автоматизированном виде), возможно, с дополнительными затратами анонимности.
Возможными улучшениями могли бы стать замена или дополнение к address book (см. i2host.i2p), или что-то простое, как подписка на http://example.i 2p/cgi-bin/recenthosts.cgi вместо http://example.i 2p/hosts.txt. Если гипотетический recenthosts.cgi распространял бы все хосты за последние 24 часа, например, это могло бы быть как более эффективным, так и более анонимным, чем текущий hosts.txt с last-modified и etag.
Пример реализации доступен на stats.i2p по адресу http://stats.i 2p/cgi-bin/newhosts.txt. Этот скрипт возвращает Etag с временной меткой. Когда приходит запрос с etag If-None-Match, скрипт возвращает ТОЛЬКО новые хосты с указанной временной метки, или 304 Not Modified, если их нет. Таким образом, скрипт эффективно возвращает только те хосты, о которых подписчик не знает, в формате, совместимом с адресной книгой.
Таким образом, неэффективность не является большой проблемой, и существует несколько способов улучшить ситуацию без радикальных изменений.
- Немасштабируемо: Файл hosts.txt размером 400К (с линейным поиском) пока не так велик, и мы можем увеличить его в 10 или 100 раз, прежде чем это станет проблемой.
Что касается сетевого трафика, см. выше. Но если вы не собираетесь выполнять медленный запрос ключа по сети в реальном времени, вам необходимо хранить весь набор ключей локально, что требует около 500 байт на ключ.
- Требует настройки и “доверия”: Встроенная адресная книга по умолчанию подписана только на http://www.i2p2.i 2p/hosts.txt, который редко обновляется, что приводит к плохому пользовательскому опыту для новых пользователей.
Это сделано совершенно намеренно. jrandom хочет, чтобы пользователь “доверял” провайдеру hosts.txt, и как он любит говорить, “доверие - это не булева величина”. Этап конфигурации призван заставить пользователей задуматься о вопросах доверия в анонимной сети.
В качестве другого примера, страница ошибки “I2P Site Unknown” в HTTP Proxy перечисляет некоторые jump-сервисы, но не “рекомендует” какой-либо конкретный, и пользователь сам решает, какой выбрать (или не выбирать вообще). jrandom сказал бы, что мы доверяем перечисленным провайдерам достаточно, чтобы их перечислить, но недостаточно, чтобы автоматически получать ключ от них.
Насколько это успешно, я не уверен. Но должна существовать некая иерархия доверия для системы именования. Равное отношение ко всем может увеличить риск захвата.
- Это не DNS
К сожалению, запросы в реальном времени через I2P значительно замедлили бы веб-серфинг.
Кроме того, DNS основан на запросах с ограниченным кешированием и временем жизни, тогда как I2P-ключи являются постоянными.
Конечно, мы могли бы заставить это работать, но зачем? Это плохое решение.
- Ненадежно: Зависит от конкретных серверов для подписок на адресные книги.
Да, это зависит от нескольких серверов, которые вы настроили. В I2P серверы и сервисы появляются и исчезают. Любая другая централизованная система (например, корневые DNS-серверы) имела бы ту же проблему. Полностью децентрализованная система (где каждый является авторитетным) возможна путем реализации решения “каждый является корневым DNS-сервером” или чем-то еще более простым, например, скриптом, который добавляет всех из вашего hosts.txt в вашу адресную книгу.
Однако люди, выступающие за полностью авторитарные решения, обычно не продумывают вопросы конфликтов и захвата управления.
- Неудобно, не в реальном времени: Это лоскутное одеяло из провайдеров hosts.txt, провайдеров веб-форм добавления ключей, провайдеров jump-сервисов, репортеров статуса I2P-сайтов. Jump-серверы и подписки доставляют проблемы, это должно работать просто как DNS.
См. разделы о надёжности и доверии.
Итак, подводя итог, текущая система не является кардинально сломанной, неэффективной или немасштабируемой, а предложения “просто использовать DNS” недостаточно продуманы.
Альтернативы
Исходный код I2P содержит несколько подключаемых систем именования и поддерживает параметры конфигурации для экспериментов с системами именования.
- Meta - вызывает две или более других системы именования по порядку. По умолчанию вызывает PetName, затем HostsTxt.
- PetName - выполняет поиск в файле petnames.txt. Формат этого файла НЕ совпадает с форматом hosts.txt.
- HostsTxt - выполняет поиск в следующих файлах по порядку:
- privatehosts.txt
- userhosts.txt
- 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 destinations содержат сертификат, однако в настоящее время этот сертификат всегда равен null. При null-сертификате base64 destinations всегда составляют 516 байт и заканчиваются на “AAAA”, и это проверяется в механизме слияния адресной книги и, возможно, в других местах. Также отсутствует доступный метод для генерации сертификата или добавления его в destination. Поэтому их необходимо будет обновить для реализации сертификатов.
Одним из возможных применений сертификатов является proof of work .
Другой способ — это подписание “поддоменов” (в кавычках, потому что на самом деле их не существует, I2P использует плоскую систему именования) ключами домена второго уровня.
С любой реализацией сертификатов должен поставляться метод для проверки сертификатов. Предположительно это должно происходить в коде слияния адресной книги. Существует ли метод для нескольких типов сертификатов или нескольких сертификатов?
Добавление сертификата, подтверждающего подлинность ответов как подписанных некоторым централизованным центром сертификации, решило бы многие проблемы с враждебными серверами имен, но оставило бы открытыми атаки повторного воспроизведения, а также атаки со стороны враждебного центра сертификации.