NetDb
|
netDb, или "Сетевая база данных" - специализированная распределенная база данных, содержащая всего лишь два типа данных: контактная информация роутера и контактная информация точек назначения (так называемые LeaseSets). Каждый кусочек данных подписан соответствующей стороной, и проверена любым, кто использует или хранит его. Кроме того, там же хранится информация о "живости", позволяющая удалять нерелевантные вхождения, заменять более новыми записями более старые, и защищающая данные от некоторых типов атак.
NetDb хранится распределенно с помощью простого механизма, называющегося "floodfill", когда часть от общего числа роутеров, называемая "floodfil-роутеры" поддерживает распределенную базу данных.
Оригинальная статья на официальном сайте (англ.)
Структура RouterInfo
Когда один I2P роутер хочет соединиться с другим роутером, им необходимо "знать" кое-какие ключевые данные. Эти данные упакованы и подписаны в одной структуре данных, называемой "RouterInfo", которая распространяется с помощью SHA-256 от идентификатора роутера в качетсве ключа. Сама структура содержит следующие данные:
- Идентификационные данные роутера (2048-битный ключ шифрования для алгоритма ElGamal, 1024-битный DSA ключ подписи, а также сертификат)
- Контактные адреса, по которым до этого роутера можно достучаться (например TCP: example.org порт 4108)
- Когда данная структура была опубликована
- Набор произвольных текстовых опций
- Подпись для данных, перечисленных выше, сгенерированная с помощью того самого DSA-ключа подписи, из идентификационных данных.
Следующие текстовые опции не строго обязательны, но очень желательно, чтобы они были:
- caps (Флаги совместимости - раньше использовались для идентификации участия в процессе floodfill, а также средней пропускной способности и примерную "достижимость")
- coreVersion (Версия библиотеки ядра, всегда такая же, как и версия самого роутера)
- netId = 2 (Базовая совместимость на уровне сети. Роутер откажется обмениваться данными с пиром, который имеет другой netId)
- router.version (Использовался для определения совместимости с новыми функциями и сообщениями)
- stat_uptime = 90m (Всегда отсылается 90 минут, для совместимости со старой схемой, когда роутеры публиковали свое реальное время аптайма, и посылали запросы на туннели только тем пирам, у которых время аптайма более 60 минут)
Эти значения используются другими роутерами для принятия основных решений. Стоит ли нам соединяться с этим роутером? Должны мы пытаться построить туннель через этот роутер? Флаг пропускной способности, в частности, используется только для определения того, соответствует ли роутер минимальному порогу для пропускания туннелей. Если у роутера пропускная способность выше минимально допустимого порога, то "распространяемая" полоса не является доверенной где угодно в роутере, исключая цели отображения в пользовательском интерфейсе, для отладки, а также для анализа сети.
Дополнительные текстовые опции включают небольшой набор статистических данных о "здоровье" роутера, которые собираются такими сайтами, как stats.i2p для анализа производительности сети и отладки. Эта статистические данные необходимы, чтобы дать очень важную информацию разработчикам. Например, процент успешно построенных туннелей, которые отображают всякие побочные эффекты. Текущая статистика ограничена следующими данными:
- Успешно построенные клиентские и зондирующие туннели, отклоненные и туннели с истекшим таймаутом.
- Среднечасовое количество транзитных туннелей.
Публикуемые данные можно посмотреть в пользовательском интерфейсе (консоли) роутера, но они не используются и не являются доверенными в пределах роутера. Поскольку сеть растет, разработчики удалили большую часть публикуемой статистики, чтобы улучшить анонимность, и планируют удалить больше в последующих релизах.
RouterInfo: время жизни
Структуры RouterInfo не имеют установленного времени жизни. Каждый роутер свободен в выборе своей собственной локальной политики, которая будет обеспечивать компромисс между частотой поиска данных RouterInfo и использованием диска/памяти. В текущей реализации используются следующие основные политики:
- Нет никакого "истечения срока годности" в течении первого часа работы, поскольку постоянно хранимые данные могут быть старыми.
- Нет срока годности, если у роутера всего 25 или менее структур RouterInfo.
- Когда число локальных RouterInfo растет, срок годности уменьшается, в попытке поддержать целесообразное число структур RouterInfo. Срок годности, с числом маршрутизаторов менее 120, составляет 72 часа, в то время как срок годности при 300 роутерах составляет уже 30 часов.
- Структуры RouterInfo содержать также SSU интродьюсеров, "протухающих" примерно через час, также как и список интродьюсеров, который также протухает примерно в такое же время.
- Роутеры Floodfill используют маленькое время годности (1 час) для всех локальных структур RouterInfo, так как валидные структуры будут очень часто публиковаться на них.
RouterInfo - постоянное хранилище
Структуры RouterInfo периодически записываются на диск, соответственно они будут доступны после перезагрузки.
LeaseSet
Следующая часть данных, распределенно хранимых в netDb называется "LeaseSet" (дословно на русский - "Договор аренды") - группа точек входа в тоннели (leases) для конкретных Destination клиента. Каждый из данных наборов содержит следующую информацию:
- Туннельный маршрутизатор входа (по его идентификатору)
- ID туннеля на этом роутере, для отправки сообщений (четырёхбайтовое число)
- Когда данный тоннель "умрет" - то есть пройдёт его срок годности.
LeaseSet сам сохранен в netDb с ключом, полученным из SHA-256 хэша от destination. (Возможно фраза не совсем понятна - LeaseSet это по сути распределенное хранилище в формате key=value, где key - sha256 хэш от полного destination, которое в свою очередь является value). Дополнительно к данным Leases, LeaseSet включает в себя:
- Свой собственный destination (2048-битный ключ шифрования по алгоритму ElGamal, 1024-битный ключ подписи DSA и сертификат).
- Дополнительный публичный ключ для шифрования: используется для шифрования точка-точка в чесночных сообщениях.
- Дополнительный публичный ключ для шифрования: предназначен для аннулирования (отзыва) данного LeaseSet, но на данный момент не используется.
- Подпись всех данных, хранящихся в данном LeaseSet, для того, чтобы удостоверить destination, опубликованный в LeaseSet.
Внешние ссылки
Неопубликованные LeaseSets
В LeaseSet не публикуются destination, используемые только для исходящих соединений. Они никогда не посылаются для публикации на floodfil-роутеры. Клиентские туннели, используемые для веб-браузеров и IRC клиентов также не публикуются. Сервера всё ещё могут посылать сообщения к этим неопубликованным Destinations, так как существуют "сообщения хранения" I2NP.
Отозванные LeaseSets
LeaseSet может быть отозван с публикации новым LeaseSet'ом, с нулевыми Leases. Отзыв должен быть подписан дополнительным ключом подписи в LeaseSet, упомянутым выше. Отзывы не реализованы полностью, и неясно - понадобятся ли они на практике. Это просто планы по использованию данного ключа шифрования, и на данный момент он не используется.
Зашифрованные LeaseSets
В зашифрованном LeaseSet все Leases зашифрованы (ваш К.О.) с помощью отдельного DSA-ключа. Leases могут быть расшифрованы, и Destination's могут быть получены (а также открыты) только тем, кто имеет ключ. Нет никакого "флага" или другой информации о том, что данный LeaseSet вообще зашифрован. Зашфифрованные LeaseSet'ы не особенно широко используются, и это тема для дальнейших исследований в будущем, когда пользовательский интерфейс и реализация зашифрованных LeaseSet'ов могли бы быть улучшены.
Срок годности LeaseSet
Все Leases (то есть, туннели, по сути), годны в течении 10 минут. Следовательно, LeaseSet "протухает" через 10 минут, после самого раннего времени создания всех этих Leases.
LeaseSet: постоянное хранилище
Нет никакого постоянного хранилища данных в LeaseSet, так как они протухают очень быстро.
Bootstrapping (Начальная загрузка)
NetDb децентрализована, тем не менее вам необходима как минимум одна ссылка на пир, для начала интеграционного процесса в сеть. Это совершается с помощью процесса под названием "Reseeding" вашего роутера активным пиром. Собственно, это прием его файла routerInfo-$hash.dat и сохранение его в вашей локальной директории netDb/. Кто угодно может предоставить вам эти файлы, и даже вы можете предоставлять их другим, с помощью вашей собственной netDb директории. Для упрощения данного процесса добровольцы публикуют их netDb директории (или часть их) в обычном (не I2P) интернете, и некоторые из URL таких добровольцев просто захардкожены в I2P роутер. Когда роутер стартует в первый раз, он автоматически затягивает данные с этих URL, выбранных случайно из списка.
Floodfill
Floodfill netDb - простой механизм распределенного хранения. Алгоритм сохранения прост: послать данные ближайшему пиру, который рекламирует себя как floodfill роутер. Затем подождать 10 секунд, выбрать другой floodfill роутер, и попросить его проверить, что отправка и распределение данных прошли корректно. Если проверяемый пир не отвечает, или не имеет нужных данных, отправитель повторяет процесс. Когда пир во floodfill netDb получает хранилище netDb от пира, который не существует в сетевой БД floodfill'ов, они посылают его в подмножество пиров floodfill netDb. Пиры выбираются, как один из ближайших (в соответствии с XOR-метриками) для конкретного ключа.
Определить, кто является частью floodfill netDb очень просто - он дает возможность любому роутеру публиковать свою routerInfo.
Floodfills не имеют центрального авторизующего узла, и это не форма "консенсуса", они только реализуют простой DHT-оверлей.
Как стать Floodfill роутером?
В отличие от Tor, где "серверы директорий" захардкожены и доверены, и управляются известными участниками, участники I2P floodfill не являются доверенными и изменяются со временем.
Для улучшения устойчивости netDb и минимизировать воздействие трафика netDb на роутер, floodfill автоматически включается только на роутерах, которые сконфигурированы с высокими лимитами пропускной способности. Роутеры с высокой пропускной способностью (которые должны быть сконфигурированы вручную, так как настройки по-умолчанию намного меньше) предполагают соединения с маленькой задержкой и лучше всего, если они доступны 24/7. Текущий минимальный порог пропусной способности, чтобы стать floodfill-роутером - 128 килобайт в секунду.
В дополнение, роутер должен пройти несколько дополнительных тестов на "здоровье" (очередь исходящих сообщений, рабочие лаги, и так далее), прежде чем работа во floodfill будет автоматически включена.
При текущих правилах для автоматического включения, в среднем 6% от всех роутеров в сети являются floodfill роутерами.
Пока некоторые роутеры вручную сконфигурированы, чтобы быть floodfill-ами, другие, которые просто имеют широкую полосу пропускания, автоматически вызываются, чтобы быть floodfill, когда общее количество floodfill-роутеров падает ниже определенного порога. Это препятствует любым долговременным повреждениям сети, а также от потери большей части floodfill, например, если на всех них будет проводиться атака. В свою очередь, эти роутеры сами отключатся от floodfill сети, если вдруг таких роутеров станет слишком много.
Роли Floodfill роутера
Floodfill роутеры выполняют, в общем-то, одну единственную функцию (кроме тех, какие есть у всех обычных роутеров): это прием netDb и ответы на запросы в неё. Так как они сами по себе имеют высокую полосу пропускания, то они вероятно будут также иметь много транзитных туннелей (то есть быть релеями для остальных), но это не связано напрямую с их работой по поддержке распределенной базы данных.
Метрики соседей
NetDb использует простые, Kademlia-style XOR метрики для определения соседей. SHA256 хэш от ключа, который кто-то искал либо сохранял XOR-ится с хэшем роутера в запросе на определение близости. Этот алгоритм был модифицирован, для того чтобы увеличить стоимость атак "Предсказания". Вместо, собственно, SHA256-хэша от ключа, в нашем случае SHA256-хэш берется от ключа к которому присоединена дата в формате yyyyMMdd (SHA256(key + yyyyMMdd).
Механизм хранения, верификации и поиска
На мой взгляд раздел переведен сумбурно и отвратительно, но только на такой вариант хватает моего знания английского. Если можете лучше - я только счастлив, смело исправляйте стилистические и смысловые ошибки.
RouterInfo хранилище для пиров
I2NP DatabaseStoreMessages содержат локальную routerInfo которой обменивались с другими пирами, в части процесса инициализации транспортного соединения NTCP или SSU.
LeaseSet хранилище для пиров
I2NP DatabaseStoreMessages содержащий локальный LeaseSet периодически обменивается с другими пирами, помещая его в в чесночное сообщение вместе с нормальным трафиком со стороны связанного Destination. Это позволяет инициализационным ответам и поздним ответам быть помещенными в соответствующий Lease, без необходимости поиска любого LeaseSet, или необходимости связывать destinatio'ы чтобы публиковать LeaseSet'ы для всех.
RouterInfo хранилище для Floodfills
Роутер публикует свою собственную routerInfo структуру напрямую на floodfill роутер, а также посылает её в I2NP DatabaseStoreMessage с ненулевым "токеном ответа". Сообщение не является "чесночно-шифрованным" типа точка-точка, так как оно передаётся по прямому соединению, соответственно нет никаких промежуточных роутеров (и нет никакой необходимости скрывать эти данные). Floodfill роутер отвечает I2NP DeliveryStatusMessage (сообщением о статусе доставки), с идентификатором сообщения установленным в значении токена ответа.
