Продолжение перевода официальной документации I2P.
На этот раз он чуть более вольный, чтобы текст был читаем на русском языке.
Оглавление:
Часть 1: «Всё что вы хотели знать и боялись спросить о I2P»
Часть 2: Туннельная магия, NetDB и «жонглирование» протоколами
Туннели
Входящий и исходящий туннели работают на схожих принципах. Туннель шлюз накапливает некоторое количество информации о туннелях, в конечном итоге формируя из этого туннель для доставки. Затем шлюз предварительно шифрует данные и направляет их через первый Хоп. Этот пир и последующие участники туннеля проверяют, является ли сообщение дубликатом, добавляя ещё один слой шифрования и направляют в последующий туннель.
В конечном счёте сообщение попадает к цели, после чего оно полностью расшифровывается и обрабатывается самой целью. Разница заключается в том, что создатель туннеля для транзитных туннелей, будет целью, а для транзитных дополнительным — уровнем шифрования. Создатель исходящего туннеля является шлюзом и предварительно дешифрует сообщение так, чтобы оно дошло до получателя не заметно для пиров.
Выбор пиров и соединение их в определённой последовательности очень важно для понимания, как I2P остаётся анонимным и производительным (Мощным, быстрым — прим. пер.).
В то время как NetDB (Сетевая база данных)(см. ниже) имеет свои собственные критерии для выбора, запроса и хранения записей о пирах, а инициализатор туннеля может использовать любых пиров, в любом порядке и количестве раз в одном туннеле.
Если данные с минимальной задержкой и максимальной эффективностью доступны по всему миру, то обеспечение потребностей клиента будет обеспечиваться исходя из его требований, с учётом возможных угроз. К сожалению, задержки и пропускная способность не идеальна и зависит от пиров, способных предоставить свою пропускную способность. Обеспечиваемый уровень анонимности накладывает свой отпечаток на скорость работы сети.
Анонимность обеспечивается просто: пиры выбираются случайным образом из всей сети, запросы по пирам происходят случайным образом и может длиться вечно. Производительность обеспечивается выборкой самых быстрых пиров и распределение нагрузки между ними, для обеспечения прозрачности и отказоустойчивости. Так же они используются для восстановления и перестройки туннелей, когда происходит изменение пропускной способности сети. Раньше всё было хрупко и неэффективно: могли быть проблемы с доступом к информации и предлагалась недостаточная анонимность.
I2P предлагает широкий спектр различных стратегий выборки, в сочетании с анонимной организацией пиров по профилям.
I2P использует для работы постоянные профили пиров которые он генерирует исследуя их работу в сети, например, если пир, отвечает на поиск в netDB в течении 1.3 секунд, то информация о маршруте и задержках для обоих туннелей (входящего и исходящего), записывается в его профиль, в котором так же записаны все запросы и ответы пира. Данные полученные при измерении транспортных задержек и “заторов”, не используется как часть профиля пира, а ассоциируется с конкретными маршрутизаторами.
Во время сбора информации для профилей, информация будет систематизироваться и в итоге мы получим информацию о производительности, задержках, способности пира к обработке больших объёмов информации, насколько сейчас он нагружен и насколько хорошо он интегрирован в сеть. Эти расчёты выполняются для каждого пира в отдельности, а затем пиры сравниваются между собой и раскладываются по полочкам: быстрый и ёмкий, высокая пропускная способность, рабочий не рабочий.
Пороги для распределения по этим уровням генерируются динамически, и хотя в настоящее время для этого используются довольно простые алгоритмы, существуют альтернативы.
Дальнейший текст описывает очень специфические моменты, термин “Сборка урожая” (harvesting attacks) обозначает вид атаки, который позволит составить список пользователей работающих с I2P. Я хотел бы, чтобы кто-то предложил более удачный эквивалент, мне этот вариант режет слух.
Развёртывание клиентского тоннеля осуществляется путём простой и эффективной случайной выборки пиров, из наиболее хороший по ёмкости и скорости. Выборка пиров осуществляется из netDB, пиры используемые для расширения, обладают только некоторой устойчивость (not failing) и используются для переброса “вершины холма” (центральной точки нагрузки — прим. пер.). Такой тип работы, обеспечивает очень слабую устойчивость к атакам типа “сборки урожая”. Как вариант решения, роутер может не балансировать нагрузку между пирами, а использовать преимущественно только отдельный канал, для ослабления воздействия этой атаки, но делает сеть менее устойчивой к другим типам угроз.
Получая случайный ключ, по средствам XOR генерируется маршрут. В случае атаки “сборки урожая”, информация теряется и пир сообщает об ошибке, после чего отключается.
Другая простая стратегия для защиты от сборки сборки информации, это простая регенерация входящего туннеля, используя новых пиров для создания нового туннеля. Чтобы справиться с типом атаки, целью которой являются клиенты, конечные точки исходящего туннеля должны оставаться неизменными. Конечное, если пиры как конечные точки туннеля остаются фиксированными, нужно установить ограничение времени соединения. Пир, как конечная точка туннеля, может имитировать временный отказ маршрутизатора, как следствие туннель будет автоматически пересоздан.
Эти две стратегии защиты могут быть объединены, тогда будут использоваться фиксированные участники и функция XOR для создания туннелей. Более жёсткая стратегия защиты, подразумевает под собой точные (конкретные) соединения между отдельными пирами, которые являются доверенными и участвуют в создании маршрута на таких же условиях (Напоминает Tor — прим. пер.). Использование XOR подразумевает неизменность порядка и то, что начальный и конечный пир, всегда одинаков, а XOR лишь обеспечивает неизменность порядка.
Как упоминалось ранее, в настоящее время I2P (выпуск 0,8) включает в себя многоуровневую стратегию по выборке с использованием XOR. Более подробное обсуждение механики работы туннеля, об управления и подборки пиров можно найти в спецификациитуннелей.
Сетевая база данных
Как говорилось ранее I2P, работает с помощью обменена метаданными сети, ниже это будет объяснено подробнее.
Некоторый процент пользователей I2P обозначаются как ‘FloodFill’ (Полностью нагруженные). В настоящее время машины, на которые установлен I2P, имеют достаточно высокую пропускную способность, поэтому в случае резкого падения, количество ‘FloodFill’-маршрутизаторов, маршрутизатор (тавтология) сам назначает себя ‘FloodFill’.
Другие маршрутизаторы могут хранить информацию и данные для поиска, которые будут получать путём запроса к полностью заполненным маршрутизаторам. Если ‘FloodFill’ маршрутизатор получает запрос на хранение, то ‘FloodFill’ маршрутизатор начинает пересылать это сообщение другим ‘FloodFill’ маршрутизаторам с использованием алгоритма Kademlia. Поисковые запросы реализуются по разному, чтобы предотвратить проблемы безопасности, когда поиск будет закончен, ‘FloodFill’-маршрутизатор не перешлёт результат кому-либо, но ответит если данные будут запрошены.
В сетевой базе данных хранится два типа информации:
- RouterInfo хранит информацию по конкретному маршрутизатора I2P и то как с ним можно связаться.
- leaseSet хранит информацию о специфических точках назначения (напрмер: I2P веб-сервер, e-mail сервер и etc. ).
Вся эта информация будет подписана “издателем” (publishing party) и проверена любым I2P роутером, а также будет сохранена им же. Также хранимая информация содержит временные метки, для того чтобы избежать хранения устаревшей информации и предотвратить некоторые возможные виды атак.
Так же некоторые важные замечания:
Не опубликованные и зашифрованные leasesets:
Если в таком варианте определённый человек хочет достичь определённого получателя. Это возможно это можно сделать не публикуя место назначения в netDb. Однако вы должны тогда передать адрес другим способом. Например, зашифрованным альтернативным способом leaseSets. Этот leaseSets может быть расшифрован человеком, имеющем доступ к ключу расшифровки.
Самонастройка:
Самонастраивается NetDB довольно просто. После того, как маршрутизатор удается получить хотя бы один routerInfo из досягаемых пиров, он может запросить у пира ссылки на другие маршрутизаторы в сети. В настоящее время пользователи размещают информацию о своих routerInfo на веб-сайты, чтобы сделать её доступной всем. I2P автоматически подключается к одному из этих веб-сайтов для сбора routerInfo файлов и их загрузки.
Поисковая масштабируемость:
Поиски в сети I2P не происходит по netDb в других маршрутизаторах. В настоящее время это не является большой проблемой, так как сеть не очень большая. Тем не менее, по мере роста сети, не все routerInfo и leaseSet файлы будут присутствовать на каждом маршрутизаторе netDb. Это приведет к ухудшению процента успешных поисков. Из-за этого исправления к netDb будет сделано в следующих выпусках.
Транспортный протокол
Связь между роутерами должна обеспечивать конфиденциальность и целостность данных, при этом аунтефикация и проверка подлинности должна гарантировать, что маршрутизатор связался с тем, кто должен получать это сообщение. Подробные сведения о том, как маршрутизаторы общаются друг с другом не важны, но мы рассмотрим 3 отдельных протокола, которые были использованы в различных узлах чтобы обеспечить эти “нужды”.
История I2P началась на основе протокола TCP который позже перестал использоваться. Затем, чтобы удовлетворить высокий спрос на потребность в хорошем качестве связи (число роутеров в конечном итоге только увеличивалось), I2P перешёл от протокола основанном на TCP, на протокол основанный на UDP — «Secure Semireliable UDP» или «SSU».
Как рассказывается в SSU спецификации:
Целью данного протокола является обеспечение безопасной проверки подлинности, надёжную и неупорядоченную доставку сообщений, оставляя минимальный объем данных, которые могут просмотреть третьи лица. Он должен обеспечивать высокое качество связи, а также TCP-дружественное управление нагрузкой и может включать в себя обнаружение PMTU. Он должен быть способен эффективно перемещать большие объемы данных со скоростью достаточной для домашних пользователей. Кроме того, он должна поддерживать возможность отделения(ограничения) сети, как делают большинство NAT, или брандмауэры.
После введения SSU проблемы с сетевыми “заторами” были решены новым, основанным на NIO-протоколе, TCP, который позволил включить NTCP-протокол. Он включён по-умолчанию для исходящих соединений. Если настроить NAT/Firewall для разрешения входящих соединений и указания внешнего хоста и порта (DynDNS и etc) можно использовать /config.jsp, чтобы устанавливать входящие соединения. NTCP основан на NIO и не страдает ограничением в 1 поток как старые версии TCP протокола.
I2P поддерживает разные транспортные протоколы. Нужный транспортный протокол для исходящего соединения выбирается со ставкой. В зависимости от ставки выбирается приоритет. Транспорт отвечает с различной ставкой, в зависимости от того, есть уже установленное соединение с партнером.
В большинстве ситуаций текущей реализации NTCP имеет более высокий приоритет для установки исходящих соединение. SSU включён и для исходящих и входящих соединений. Ваш firewall и I2P роутер, должны быть верно настроены для установки NTCP соединения.
Для получения дополнительной информации см. протокол NTCP.
Автор: nefelim4ag
