Туннели

Как входящие, так и исходящие туннели работают на аналогичных принципах. Шлюз туннеля аккумулирует некоторое количество сообщений, опционно предварительно их преобразует для последующей передачи через туннель. Далее, шлюз шифрует переработанные данные и переадресует сообщение на следующий этап. Этот партнер и последующие участники туннеля добавляются на уровне шифрования, после чего осуществляется переадресация сообщения на следующий этап. В конце концов, сообщение приходит адресату, где сообщения снова разделяются и переадресуются, куда следует. Различие возникает в том, что делает создатель туннеля – для входящих туннелей создателем является конечная точка, и они дешифруют все добавленные уровни, в то время как для исходящих туннелей, создателем является шлюз и они шифруют все слои, так что в конце концов добавляются слои с индивидуальным шифрованием для каждого из этапов, сообщение прибывает в место назначения туннеля незашифрованным.

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

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

I2P постоянно отслеживает профайлы партнеров, с которыми взаимодействуют - например, когда партнер реагирует на запрос netDb за 1.3 секунды, эта задержка записывается в профайлы всех маршрутизаторов, вовлеченных во входящий и исходящий туннели, через которые проходят запрос и отклик. Прямое измерение, такое как на транспортном уровне или при перегрузке, не используется, так как здесь возможны манипуляции, а также выявление измеряющего маршрутизатора, с последующими тривиальными атаками. В процессе сбора данных этих профайлов производится ряд вычислений, чтобы охарактеризовать рабочие параметры объекта – его задержку, пропускную способность, уровень перегрузки и т.д.. Эти вычисления затем сравниваются для активных партнеров, чтобы рассортировать маршрутизаторы на четыре группы – быстрые с большой полосой пропускания, с высокой пропускной способностью, устойчивые и нестабильные. Пороги для групп определяются динамически.

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

Путем выбора произвольного ключа и упорядочения партнеров по XOR-расстоянию от него, количество утекающей информации через предшественников уменьшается. Другой простой стратегией понижения возможности атак через netDb является дальнейшая рэндомизация партнеров в туннеле. Более жесткой стратегией является явная фиксация партнеров и упорядочение в туннеле, используя только индивидуальных партеров, если они все согласны выполнять свои функции всегда и в любое время. Это отличается от упорядочения на основе XOR, где предшественник и последователь каждого партнера всегда один и тот же. XOR-техника гарантирует неизменность порядка партнеров.

Как было упомянуто выше, I2P сейчас (версия 0.8) включает в себя послойную стратегию случайного выбора, с упорядочением на основе процедур XOR.

Сеть баз данных

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

Некоторая доля I2P-пользователей объявляются 'floodfill-партнерами'. В настоящее время I2P-инсталляции, которые имеют большую полосу и высокое быстродействие, объявляют себя floodfill, если число имеющихся floodfill-маршрутизаторов становится малым.

Большинство I2P-маршрутизаторов записывают свои данные и извлекают их путем посылки запросов 'store' и 'lookup' узлам floodfill. Если floodfill-маршрутизатор получает запрос 'store', он передает информацию другим floodfill-маршрутизаторам с использованием алгоритма Kademlia (распределенная хэш таблица для децентрализованных P2P сетей). Запросы 'lookup' реализуются иначе, для этой цели посылается в netdb I2NP DatabaseLookupMessage, чтобы получить нужные данные из floodfill маршрутизатора. При рлступлении запроса floodfill-маршрутизатор не переадресует его другим партнерам, а всегда выполняет сам (если имеет запрашиваемые данные).

В сетевой базе данных хранятся два типа данных.

• routerInfo хранит информацию о специфическом I2P-маршрутизаторе и как с ним контактировать
• leaseSet хранит информацию о специфическом месте назначения (напр., I2P-вебсайте, e-mail сервере...)

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

Неопубликованные и незашифрованные leaseset

Кто-то может захотеть разрешить определенным людям доступ к определенному месту назначения. Это возможно, если не публиковать место назначения в netDb. Вы будете, однако должны передать место назначения другими средствами. Альтернативой является 'зашифрованный leaseSet'. Эти наборы могут быть дешифрованы субъектами, имеющими доступ к соответствующему ключу.

Стартовая загрузка

Начальная загрузка netDb достаточно проста. Раз маршрутизатор может получать routerInfo доступного партнера, он может запросить, ссылки для других маршрутизаторов в сети. В настоящее время определенное число пользователей, выставляет свои routerInfo-файлы на вебсайте, чтобы сделать эту информацию доступной. I2P автоматически подключается к одному из этих вебсайтов, чтобы собрать вместе файлы routerInfo и осуществить стартовую загрузку.

Масштабируемость запросов Lookup

Запросы Lookup I2P-сети не переадресуются другим netDb-маршрутизаторам. Сейчас это несущественно, так как сеть невелика. Однако, по мере роста сети, не все файлы routerInfo и leaseSet будут присутствовать на каждом netDb-маршрутизаторе. Это вызовет ухудшение процента успешных запросов lookup. По этой причине, совершенствование netDb будет осуществлено в последующих версиях.

Транспортные протоколы

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

NTCP (NIO-базирующийся TCP)

NTCP является одним из двух видов транспорта, используемым в I2P. Другим из этих двух является SSU. NTCP представляет собой транспорт, базирующийся на NIO и введенный в I2P в версии 0.6.1.22. Java NIO (new I/O) не имеет ограничения на число тредов на одно соединение, присущего TCP-транспорту.

По умолчанию, NTCP использует пару IP/порт, автоматически детектируемых SSU. Когда это разрешено config.jsp, SSU запрашивает/перезапускает NTCP при изменении адреса или статуса firewall. Теперь вы можете разрешить входное TCP без статического IP или динамического DNS-сервиса.

Программа NTCP в I2P относительно проста, так как использует для надежной доставки Java TCP транспорт.

Спецификация протокола NTCP
Формат стандартного сообщения

После установления, NTCP-транспорт посылает индивидуальные I2NP сообщения, с простой контрольной суммой. Незашифрованное сообщение имеет следующий формат:

Рис. 5. Формат стандартного сообщения

Данные шифруются с использованием алгоритмов AES/256/CBC. Ключ сессии для шифрования согласуется в процессе установления соединения (с использованием алгоритма Диффи-Хелмана с 2048 битами). Установление соединения между двумя маршрутизаторами реализуется в классе EstablishState. Вектор IV для шифрования AES/256/CBC записывается в последних 16 байтах предшествующего зашифрованного сообщения.

Необходимы 0-15 байтов заполнителя, чтобы довести полную длину сообщения (включая байты размера и контрольной суммы) до значения, кратного 16. Максимальный размер сообщения в настоящее время равен 16 Kбайт. Следовательно, максимальный размер поля данных равен 16 Kбайт - 6, или 16378 байт. Минимальный размер = 1.

Формат сообщения Time Sync

Специальным случаем является сообщение метаданных, где в поле размера данных записывается 0. В этом случае незашифрованное сообщение выглядит следующим образом:

Рис. 6.

Полная длина: 16 байт. Сообщение time sync посылается примерно каждые 15 минут. Сообщение шифруется как стандартное сообщение.

Контрольные суммы

Стандартное сообщение и сообщения time sync используют контрольную сумму Adler-32, как это определено в http://tools.ietf.org/html/rfc1950.

Последовательность установления

Для установления соединения производится 4-фазный обмен DH ключами и подписями. В первых двух сообщениях реализуется обмен согласно 2048-битному алгоритму Диффи-Хелмана. Затем производится обмен, DSA-подписями критических данных, чтобы подтвердить соединение.

Алиса                   контакты                      Боб
=========================================================
X+(H(X) xor Bob.identHash)----------------------------->
<----------------------------------------Y+E(H(X+Y)+tsB+заполнитель, sk, Y[239:255])
E(sz+Alice.identity+tsA+ заполнитель +S(X+Y+Bob.identHash+tsA+tsB), sk, hX_xor_Bob.identHash[16:31])--->
<----------------------E(S(X+Y+Alice.identHash+tsA+tsB)+заполнитель, sk, prev)

Обозначения:
X, Y: 256 байта DH общедоступные ключи
H(): 32 байта хэша SHA256
E(данные, ключ сессии, IV): зашифровано AES256
S(): 40 байт DSA-подпись
tsA, tsB: временные метки (4 байта, секунд с начала эпохи)
sk: 32 байтный ключ сессии
sz: 2 байта размера идентификатора Алисы (который следует далее)

Ключевой обмен DH

Исходный 2048-битовый ключевой DH-обмен использует тот же исходный код р (prime) и генератор g, что и в случае I2P кодирования с привлечением алгоритма Эль-Гамаля.

Ключевой DH обмен реализуется в несколько этапов, представленных ниже. Сообщения, пересылаемые между I2P-маршрутизаторами, выделены жирным шрифтом.

1. Алиса генерирует секретное 226-битовое целое x. Она затем вычисляет X= g^x mod p.
2. Алиса посылает X Бобу (Сообщение 1).
3. Боб генерирует секретное 226-битовое целое y. Далее он вычисляет Y=g^ymod p.
4. Боб посылает Y Алисе (Сообщение 2)
5. Алиса может теперь вычислить ключ сессии sessionKey = Y^x mod p.
6. Боб может теперь вычислить ключ сессии sessionKey = X^y mod p.
7. Алиса и Боб теперь имеют общий ключ сессии sessionKey = g^(x*y) mod p

SessionKey затем используется для обмена идентификаторами в Сообщении 3 и Сообщении 4.

Сообщение 1 (Запрос сессии)

Это DH-запрос. Алиса уже имеет идентификатор маршрутизатора Боба, IP адрес и порт, содержащиеся в Router Info, которая была опубликована в сетевой базе данных. Алиса посылает Бобу:

X+(H(X) xor Bob.identHash)----------------------------->

Размер: 288 байт
Содержимое: Х за которым сразу следует HX xor HI.

X: 256 байт X от Диффи Хелмана
HXxorHI: SHA256 хэш(X) xor с SHA256 Хэш(идентификатор маршрутизатора Боба) (32 байта)

• Боб верифицирует HXxorHI , используя свой хэш марштутизатора. Если верификация не прошла, Алиса контактировала не с тем маршрутизатором, и Боб разрывает соединение.

Сообщение 2 (сессия создана)

Это DH-отклик. Боб посылает Алисе

<----------------------------------------Y+E(H(X+Y)+tsB+заполнитель, sk, Y[239:255])

Размер: 304 байта
Незашифрованное содержимое имеет формат:

Рис. 7. Формат сообщения DH-отклик

Y: 256 байт Y из алгоритма Диффи Хелмана
HXY: SHA256 Хэш(X объединен с Y) (32 байта)
tsB: 4 байтная временная метка (секунды с начала эпохи)
Заполнитель: 12 байт произвольных данных
Зашифрованное содержимое: Сначала следует Y, вычисленное на основе DH, за ним непосредственно располагаются зашифрованные данные. Y: 256 байт Y от Диффи Хелмана Зашифрованные данные: 48 байт зашифрованные AES с использованием ключа сессии DH и последние 16 байт Y в качестве IV (Initialization Vector).

• Алиса может разорвать соединение, если сбой часов в Бобом слишком велик (вычисление с использованием tsB)

Сообщение 3 (Session Confirm A)

Это сообщение содержит идентификатор маршрутизатора Алисы и DSA подпись критических данных. Алиса посылает Бобу:

E(sz+Alice.identity+tsA+padding+S(X+Y+Bob.identHash+tsA+tsB), sk, hX_xor_Bob.identHash[16:31])--->

Размер: 448 байт (для 387 байтного идентификатора)
Незашифрованное содержимое:

Рис. 8. Формат сообщения подтверждения

sz: 2 байта размера идентификатора маршрутизатора Алисы, который следует далее (должно быть всегда 387)
ident: 387-байтный идентификатор маршрутизатора Алисы
tsA: 4 байта временной метки (число секунд с начала эпохи)
Заполнитель: 15 байт произвольных данных
Подпись: 40-байтная DSA-подпись следующих ниже объединенных данных:

X, Y, идентификатор маршрутизатора Боба, tsA, tsB.

Алиса подписывает это секретным ключом, сопряженным с общедоступным ключом в ее идентификаторе маршрутизатора.

Зашифрованные данные: 448 байтов зашифрованных AES с использованием ключа сессии DH и последними 16 байт HXxorHI в качестве IV (т.e., последние 16 байт сообщения #1)

• Боб верифицирует подпись, и в случае неудачи, разрывает соединение.
• Боб может разорвать соединение, если сбой часов с Алисой слишком велик (данные берутся из tsA).

Сообщение 4 (Session Confirm B)

Это DSA-подпись критических данных. Боб посылает Алисе:

<----------------------E(S(X+Y+Alice.identHash+tsA+tsB)+заполнитель, sk, prev)

Размер: 48 байтов
Незашифрованное содержимое: Сначала следует подпись, за которой может располагаться заполнитель.
Подпись: 40-байтоваяDSA-подпись следующих ниже объединенных данных:

X, Y, Alice's Router Identity, tsA, tsB.

Боб подписывает это с помощью секретного ключа, соответствующего общедоступному ключу в его идентификаторе маршрутизатора.

Заполнитель: 8 байт произвольных данных
Зашифрованные данные: 48 байт зашифрованных AES с использованием ключа сессии DH, а последние 16 байт зашифрованных данных сообщения #2 служат в качестве IV.

• Алиса верифицирует подпись, и в случае неудачи, разрывает соединение.

После установления

Соединение установлено, и обмен стандартными или синхронизирующими сообщениями можно начинать. Все последующие сообщения зашифрованы AES с использованием согласованного ключа сессии DH. Алиса будет использовать последние 16 байт зашифрованного сообщения #3 в качестве следующего IV. Боб будет использовать последние 16 байт зашифрованного сообщения #4 в качестве следующего IV.

Сообщение проверки соединения

Когда Боб установил соединение, оно может быть протестировано (возможно Боба может кто-то попросить, проверить одного из своих контактеров). Тестирование может быть выполнено следующим способом. Тестовые данные включают в себя 256 байтов, содержащих:

• 32 байта не интерпретируемых, игнорируемых данных
• 1 байт размера
• Соответствующее число байт, содержащих локальные IP-адреса маршрутизаторов (доступные для удаленных объектов)
• 2 байта номера порта, через который доступен локальный маршрутизатор.
• 4 байта времени сети i2p (секунд с начала эпохи)
• Не интерпретируемые данные заполнителя, до 223 байт.
• xor хэша идентификатора локального маршрутизатора и SHA256 с 32 до 223 байт.

I2P поддерживает несколько обменов одновременно. Определенный транспорт для исходящего соединения выбирается посредством заявок (“bids”). Каждая транспортная заявка на соединение и относительные значения этих заявок определяют приоритет заявки.

Текущая реализация позиционирует NTCP в большинстве ситуаций как высокоприоритетный транспорт для исходящих соединений. SSU допустимо, как для исходящих, так и для входящих соединений. Ваш firewall и ваш I2P-маршрутизатор должен быть сконфигурирован так, чтобы позволять входящие NTCP-соединения.

Криптография

Для обеспечения многослойной безопасности I2P минимальный набор криптографических примитивов объединяются с тем, чтобы противостоять различным угрозам. На самом нижнем уровне, внутри маршрутизаторные коммуникации защищены средствами транспортного уровня - SSU шифрует каждый пакет с помощью AES256/CBC с использованием как IV (Initialization Vector) так и MAC (HMAC-MD5-128) после согласования ключа сессии с помощью 2048-битового обмена в рамках алгоритма Диффи-Хелмана. Аутентификация станция-станция выполняется с привлечением ключа DSA, плюс каждое сетевое сообщение имеет свой собственный хэш для проверки локальной целостности. Туннельные сообщения имеют свой собственный уровень криптозащиты (AES256/CBC). Различные прочие сообщения передаются в "garlic-сообщениях", которые шифруются с привлечением алгоритмов Эль-Гамаля/AES+метки сессии (SessionTags).

Сообщения Garlic

Сообщения Garlic являются расширением "onion"-слоя шифрования (см. протокол TOR), позволяя отдельным сообщениям содержать в себе несколько секций ("cloves") –сообщений со своими инструкциями по доставке. Сообщения объединяются в garlic-сообщение всякий раз, когда сообщение может быть передано через партнера открытым текстом, а его доступ к данным нежелателен. - например, когда маршрутизатор хочет запросить другой маршрутизатор участвовать в туннеле. Другим примером может быть случай, когда клиент хочет послать сообщение адресату – маршрутизатор отправителя вкладывает это информационное сообщение в garlic, шифрует этот garlic с привлечением 2048-битового общедоступного ключа Эль-Гамаля, опубликованного в leaseSet получателя, и переадресует его через соответствующий туннель.

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

Метки сессий

Для обеспечения конфиденциальности и целостности garlic-сообщений I2P использует простую комбинацию асимметричных и симметричных крипто алгоритмов. В целом комбинация включает в себя ElGamal/AES+метки сессий, но это многословный способ описать простое использование 2048-битового алгоритма ElGamal, AES256, SHA256 и 32 байтового защитного кода (nonce).

Когда маршрутизатор хочет зашифровать garlic-сообщение, адресованное другому маршрутизатору в первый раз, он шифруют ключевой материал для ключа сессии AES256 с привлечением алгоритма ElGamal и присоединяет данные, зашифрованные посредством AES256/CBC, сразу вслед за блоком кодов ElGamal. Кроме зашифрованного поля данных, зашифрованная AES секция содержит длину поля данных, SHA256-хэш незашифрованных данных, а также несколько меток сессии - случайных 32-битовых кодов защиты (nonce). В следующий раз, когда отправитель захочет зашифровать garlic-сообщение, другому маршрутизатору, вместо того чтобы ElGamal-шифровать новый ключ сессии, они просто берут одну из доставленных раннее меток сессии и шифруют с помощью AES поле данных, используя ключ сессии с меткой сессии. Когда маршрутизатор получает зашифрованное garlic-сообщение, он проверяет первые 32 байта, чтобы посмотреть, соответствует ли это доступной метке сессии – если это так, он просто дешифрует сообщение с помощью AES, но если это не так, он дешифрует с помощью ElGamal первый блок данных.

Каждая метка сессии может быть использована только один раз. Отправитель сообщения, шифрованного ElGamal/AES+SessionTag выбирает, когда и как доставлять метки, предоставляя получателю достаточно меток, чтобы покрыть поток сообщений. Garlic-сообщения могут детектировать успешную доставки метки путем добавления небольшого сообщения в качестве секции ("сообщение состояния доставки") - когда garlic-сообщение прибывает адресату и успешно дешифруется, это небольшое статусное сообщение является одной из секций (cloves). Оно содержит инструкции для получателя, послать секцию назад исходному отправителю (через входящий туннель). Когда исходный отправитель получает это статусное сообщение, он знает, что метки сессии, включенные в garlic-сообщение, успешно доставлены.

Сами метки сессий имеют очень короткое время жизни, после которого они уничтожаются, если не используются. Кроме того, число меток, запомненное для каждого ключа ограничено, как и число самих ключей – если их приходит слишком много, либо новые, либо старые сообщения могут быть отброшены. Отправитель отслеживает, прошли ли благополучно сообщения, использующие метки сессии, и, если нет, он может отбросить сообщение, которое предполагалось ранее доставленным корректно.

Альтернативой может быть передача лишь одной метки сессии, и далее, запустить детерминистский PRNG (Pseudo-Random Number Generator) для определения того, какую метку использовать или ожидать. Поддерживая синхронность PRNG для отправителя и получателя (получатель предварительно вычисляет окно для, например, следующих 50 меток), избыточность периодического добавления большого числа меток при этом удаляется, допуская больше опций в плоскости пространство/время, и, возможно уменьшая число необходимых шифрований с привлечением алгоритма ElGamal. Однако это будет зависеть от возможности PRNG обеспечить необходимое прикрытие от внутренних атакеров, хотя при этом ограничивается число раз использования PRNG.

Работа с ограниченными маршрутами

I2P является сетью для работы поверх сети с коммутацией пакетов, использующий схему точка-точка, обеспечивающий анонимность и безопасность. В то время как Интернет не реализует более принцип точка-точка (благодаря использованию NAT), I2P в действительности требует, чтобы существенная доля сети была достижимой – могут быть много партнеров на краях, работающие с использованием ограниченных маршрутов, но I2P не включает в себя соответствующий алгоритм маршрутизации для вырожденного варианта, где большинство партнеров недостижимы. Это будет, однако работать поверх сети, использующей такой алгоритм.

Операции с ограниченными маршрутами, где имеются ограничения того, какие партнеры доступны непосредственно, имеет несколько различных функционалов и возможностей анонимности, в зависимости от того, как обрабатываются ограниченные маршруты. На базовом уровне ограниченные маршруты реализуются, когда партнер находится за NAT или firewall, при запрете входящих соединений. Это относится, прежде всего, к версии I2P 0.6.0.6, позволяя людям, находящимся за NAT и firewall, осуществлять соединения по собственной инициативе без какой-либо конфигурации. Однако это не ограничивает раскрытие IP-адресов партнеров маршрутизаторам внутри сети.

За пределами функциональной обработки ограниченных маршрутов имеется два уровня ограниченных операций, которые могут быть использованы для ограничения доступа к IP-адресам – использование специальных туннелей для коммуникаций маршрутизаторов, и предложение ‘клиентских маршрутизаторов'. Для первых, маршрутизаторы могут либо строить новый пул туннелей или повторно использовать свой диагностический пул, раскрывая данные о шлюзах входящих каналов для некоторых из них, в своих routerInfo вместо своих транспортных адресов. Когда партнер хочет вступить в контакт с ними, они видят эти шлюзы туннелей в netDb и просто посылают соответствующие сообщения к ним через один из опубликованных туннелей. Если партнер на другом конце ограниченного маршрута хочет ответить, он может сделать это либо непосредственно (если он согласен раскрыть партнеру свой IP) либо через свой исходящий туннель. Когда маршрутизаторы, с которыми партнер имеет непосредственное соединение, захотят с ним взаимодействовать (например, переслать туннельное сообщение), он просто отдает предпочтение соединению через опубликованный шлюз туннеля. Концепция 'клиентских маршрутизаторов' просто расширяет ограниченный маршрут, не публикуя каких-либо адресов маршрутизаторов. Такому маршрутизатору даже не нужно публиковать свою routerInfo в netDb, просто предоставляя самоподписанную routerInfo партнерам, с которыми он контактирует (необходимо передать общедоступный ключ маршрутизатора). Оба уровня работы с ограниченными маршрутами планируется реализовать в версии I2P 2.0.

Существуют методы оптимизации для случая ограниченных маршрутов, так как они, вероятно участвуют в других туннелях менее часто, и маршрутизаторы, с которыми они связаны, могут быть способны извлекать определенные данные из трафика, которые в противном случае не будут раскрыты. С другой стороны, если цена раскрытия меньше стоимости публикации IP, это может иметь смысл. Это, конечно, предполагает, что партнеры, с которыми контактируют маршрутизаторы ограниченного маршрута, не являются враждебными – либо сеть достаточно велика, так что вероятность использования враждебного партнера достаточно мала, либо используются исключительно надежные (проверенные) партнеры.

Переменные задержки

Хотя большая часть начальных усилий в I2P была потрачена на коммуникации с малыми задержками, эта сеть спроектирована из расчета на сервисы с переменной задержкой. На базовом уровне приложения, работающие поверх I2P, могут предложить анонимность для коммуникаций со средней и высокой задержкой. Внутренне I2P может предложить свои собственные коммуникации со средней и высокой задержкой за счет garlic-шифрования – специфицируя условие, что сообщение должно быть послано после некоторой задержки, в определенное время, после определенного числа сообщений. На уровне шифрования только маршрутизатор, которому передан секцией запрос задержки, будет знать, что сообщение требует высокой задержки, допуская смешение трафика с потоками низкой задержки. Раз выполнены условия передачи, маршрутизатор, задействованный для clove-секции (которая сама может быть garlic-сообщением), просто переадресует его маршрутизатору в туннель, или, более вероятно, удаленному клиенту места назначения.

Аналогичные системы

Архитектура I2P строится на основе программ, осуществляющих обмен сообщениями, топологии DHT (Distributed Hash Table), анонимности и криптографии смешанной сети свободных маршрутов, и адаптивности сетей с коммутацией пакетов. Решение приходит не из новых концепций алгоритмов, а из тщательной инженерной проработки, комбинирования результатов исследования существующих систем и статей.

Tor

Прикладной уровень

Сам I2P делает не так много – он просто посылает сообщения удаленному адресату и получает сообщения, адресованные локальному объекту – наиболее интересная работа выполняется на уровнях, расположенных выше. Сам по себе, I2P может рассматриваться как анонимный и безопасный IP-уровень, и потоковую библиотеку в качестве реализации анонимного и безопасного TCP-уровня поверх него.

Поточная библиотека
Библиотека имен и адресная книга

Протокол I2P использует библиотеку для работы с именами и базовая реализация сконструирована так, чтобы избавиться от локальных имен для удаленных объектов. Уникальность имен является лишь локальной. Так как все сообщения в I2P криптографически адресуемы в местах назначения, разные люди могут иметь в своей адресной локальной книге запись для "Alice", которая имеет отношение к разным местам назначения. Люди могут выявлять новые имена путем импортирования опубликованных адресных книг партнера. В какой-то мере эти адресные книги могут рассматриваться как традиционная система DNS.

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

Именование с использованием мажоритарной выборки также представляет определенную опасность из-за атак на анонимные системы типа Sybil – атакер может создать сколь угодно большое число партнеров и голосование пройдет, так как ему надо в отношении нужного ему имени. Чтобы сделать идентичность фиксированной можно использовать методы Proof-of-work, но при росте размера сети такие методики становятся неэффективными.

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

I2PTunnel

I2PTunnel является, вероятно, наиболее популярным и универсальным клиентским приложением, позволяющим прокси обмены, как внутрь, так и вне I2P-сети. I2P-туннель может рассматриваться как четыре раздельных прокси-приложения - "клиент", который принимает входящие TCP -соединения и переадресует их заданному I2P месту назначения, "httpclient" (известный под названием "eepproxy"), который действует подобно HTTP-прокси и переадресует запросы соответствующему I2P месту назначения (после запроса в систему имен, если требуется), "сервер", который получает входное потоковое I2P-соединение с местом назначения и переадресует его на данную комбинацию TCP машина+порт, и "httpserver", который расширяет "сервер" путем анализа HTTP-запросов и откликов, обеспечивая более безопасную работу.

Сам I2P не является выходной прокси сетью – соображения анонимности и безопасности, присущие сети, которая переадресует данные в и из сети, поддерживают I2P принципы, ориентированные на реализацию анонимной сети, которая способна удовлетворить потребность пользователя, не требуя внешних ресурсов. Однако, Приложение I2PTunnel "httpclient" предлагает вариант для внешних прокси. Если имя запрошенной машины не соответствует концу туннеля ".i2p", берется произвольное место назначения из списка внешних прокси, предоставленного пользователем, и переадресует запрос туда.

I2P-туннель допускает использование большинства приложений. "httpserver", позволяет любому работать со своим анонимным web-сайтом (или "eepsite") – для этой цели web-сервер объединяется с I2P, но может использоваться любой web-сервер. Любой может запустить "клиент", указывающий на один из анонимно расположенных IRC-серверов, каждый из которых работает как "сервер", указывающий на свой локальный IRCd и работающий с IRCd через свой "клиентский" туннель. Конечные пользователи также имеют "клиентские" туннели, указывающие на I2Pmail's POP3 и места назначения SMTP, аналогично "клиентские" туннели указывают на I2P CVS-серверы, реализуя анонимные операции.

I2Pmail/susimail

I2Pmail является скорее сервисом, чем приложением - почтальон предлагает как внутреннюю так и внешнюю почту через POP3 и SMTP-сервис, работающий с привлечением I2Ptunnel, позволяя клиентам использовать свой, предпочтительный для них почтовый клиент для псевдонимной посылки и приема почты. Однако большинство почтовых клиентов раскрывают значительный объем идентифицирующей информации, I2P объединяет почтовый клиент susi, базирующийся на web, с возможностями анонимности I2P. Сервис I2Pmail/mail.i2p предлагает прозрачную фильтрацию вирусов и предотвращение DoS. Кроме того, каждый пользователь может контролировать стратегию подбора, прежде чем осуществит пересылку почты через систему выходных прокси i2p, которые отделены от mail.i2p SMTP и POP3-серверов – выходные и входные прокси взаимодействуют с mail.i2p SMTP и POP3-серверами через I2P.

I2P-Bote

I2P-Bote представляет собой распределенное приложение электронной почты. Оно не использует традиционную концепцию e-mail с посылкой сообщения серверу и извлечением его из сервера. Вместо этого, оно использует распределенную хэш таблицу (DHT) Kademlia для запоминания электронной почты. Один пользователь может уложить почтовое сообщение в DHT, в то время как другой пользователь может запросить это сообщение из DHT. Все сообщения в пределах сети I2P-Bote автоматически шифруются.

Более того, I2P-Bote предлагает функцию анонимной переадресации сообщений поверх I2P.

I2P-система обмена сообщениями

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

Каждый из слоев в стеке предоставляет дополнительные возможности. Эти возможности перечислены ниже, начиная со дна стека.

Tunnel messages: туннельные сообщения являются большими сообщениями, содержащими зашифрованные I2NP-сообщения и зашифрованные инструкции по их доставке. Шифрование многослойно. На первом этапе дешифруется туннельное сообщение и читается часть. Другая часть может быть зашифрованной другим ключом, в таком виде она будет переадресована.

• I2NP messages: сообщения сетевого протокола I2P используются для передачи данных через последовательность маршрутизаторов. Эти I2NP-сообщения объединяются в туннельные сообщения.
• Garlic-уровень I2P: предоставляет шифрованный, анонимный точка-точка обмен сообщениями.

I2NP messages: сетевые протокольные сообщения I2P вкладываются друг в друга и используются, чтобы реализовать шифрование между двумя туннелями, сохраняя анонимность отправителя и получателя.

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

• Клиентский уровень I2P: позволяет любому клиенту использовать функциональность I2P, без необходимости прямого использования прикладного интерфейса маршрутизатора.

I2CP: Протокол клиента I2P, обеспечивает безопасность и асинхронный обмен сообщениями поверх I2P, передавая сообщения через I2CP TCP-сокета.

• Транспортный уровень точка-точка I2P: позволяет TCP- или UDP-подобную функциональность поверх I2P. Streaming Library: реализация TCP-подобных потоков поверх I2P. Это позволяет проще доставлять существующие приложения в I2P.
• Datagram Library: реализация UDP-подобных сообщений поверх I2P. Это позволяет проще доставлять существующие приложения в I2P.
• Уровень прикладного интерфейса I2P: дополнительные (опционные) библиотеки, позволяющие работать поверх I2P. I2PТуннель SAM/SAMv2/SAMv3(*), BOB
• Уровень прикладного прокси I2P: прокси системы. HTTP Клиент/Сервер, IRC клиент, SOCKS, Streamr

Наконец, следует рассмотреть 'уровень приложений I2P', где имеется большое число программ, работающих поверх I2P.

• Потоковые приложения для дейтограмм: i2psnark, Syndie, i2phex...
• SAM/BOB приложения: IMule, i2p-bt, i2prufus, Robert...
• Прочие I2P приложения: Syndie, EepGet, plugins...
• Регулярные приложения: Jetty, Apache, Monotone, CVS, браузеры, электронная почта...

Сетевой протокол I2P (I2NP)

Сетевой протокол I2P (I2NP), который размещается между I2CP и различными транспортными протоколами I2P, управляет маршрутизацией и микшированием сообщений между маршрутизаторами, а также выбором того, какой транспорт использовать, при коммуникациях с партнерами, для которых существуем многопротокольная транспортная поддержка.

Определение I2NP

I2NP-сообщения (сетевой протокол I2P) могут использоваться для одношаговой пересылки сообщений маршрутизатор-маршрутизатор, точка-точка. За счет шифрования и вложения одних сообщений в другие он могут пересылаться безопасным образом оконечному месту назначения.

Как NTCP, так и UDP-транспорт осуществляют приоритетную передачу, но в несколько разных манерах. UDP имеет сложный код с отдельными очередями для каждого приоритета, однако обрабатывает сообщения с приоритетами 400-499 одинаково, Это общие очереди для всех партнеров. NTCP имеет тривиальный линейный поиск для высшего приоритета в пределах буфера для конкретного партнера. Это много менее эффективно.

Формат сообщения

В то время как максимальный размер поля данных равен в норме 64Kб, размер может ограничиваться в случае фрагментации I2NP-сообщений при работе с несколькими 1Kб туннельными сообщениями, как это описано в туннель-alt.html. Максимальное число фрагментов равно 63.

Максимальный размер фрагмента составляет 956 байтов (в случае туннельного режима доставки); максимальный размер последующего фрагмента равен 996 байт. Следовательно максимальный размер сообщения равен 956 + (62 * 996) = 62708 байтов, или 61.2 Kбайт.

Кроме того, транспорты могут иметь дополнительные ограничения. NTCP в настоящее время устанавливает ограничения на уровне 16Kбайт - 6 = 16378 байт, но в будущем это значение может быть увеличено. Ограничение SSU составляет 32 Kбайта.

Заметим, что это не предел для дейтограмм, которые попадают клиенту, так как маршрутизатор может объединить leaseset отклика и/или метки сессии с сообщением клиента в garlic-сообщении. Leaseset и метки вместе могут добавить около 5.5Kбайт. Следовательно, на данный момент предельный размер дейтограмм лежит в области 10Kбайт.

Типы сообщений

Большие значения кодов соответствуют большему приоритету. Большую часть трафика составляет TunnelDataMessages (приоритет 400), таким образом все, что выше 400 – это высокий приоритет, а все что ниже - низкий. Заметим также, что многие сообщения маршрутизируются через тестовые, а не клиентские туннели, и следовательно не могут быть в той же очереди, если только ближайший шаг не соответствует тому же самому партнеру.

Кроме того, не все типы сообщений посылаются незашифрованными. Например, при тестировании туннеля, маршрутизатор упаковывает DeliveryStatusMessage, который вложен в GarlicMessage, который в свою очередь вложен в DataMessage.

Таблица 1. Типы сообщений

Спецификация сетевого протокола I2P

Общие структуры

Следующие структуры являются элементами многих I2NP-сообщений. Они не являются завершенными сообщениями.

Заголовок сообщения I2NP

Общий заголовок всех сообщений I2NP содержит контрольную сумму, время истечения пригодности и т.д..

1 байт специфицирует тип этого сообщения, следующие 4 байта представляют собой идентификатор сообщения. После этого следует код, характеризующий время пригодности, далее идут 2 байта длины поля данных сообщения, после этого кода идет хэш, который укорачивается вплоть до первого байта. После заголовка идут данные сообщения. Время пригодности равно числу миллисекунд с полночи 1-го января 1970 года во временной зоне GMT. Если это число равно нулю, то время не определено или равно 0. Стандартный заголовок (16 байт):

Рис. 9. Стандартный заголовок I2NP

Ниже рассматриваются форматы данных для протокола SSU. Ниже на рис. 10 представлен формат короткого заголовка (SSU, 5 байт):

Рис. 10. Короткий заголовок

Тип :: целое
длина -> 1 байт
назначение -> определение типа сообщения (см. таблицу ниже)
Msg-ID :: целое
длина -> 4 байта
назначение -> однозначно идентифицировать это сообщение.

Время пригодности :: Дата
8 байт
Дата, когда пригодность сообщения истечет.

Короткое время пригодности :: целое
4 байта
Дата, когда пригодность сообщения истечет (число секунд с начала эпохи)

Размер :: целое
длина -> 2 байта
назначение -> длина поля данных

Сtl-S :: целое
длина -> 1 байт
назначение -> контрольная сумма поля данных
хэш SHA256, сокращенный до одного байта

Данные :: Data
длина -> $размер байт
назначение -> содержимое сообщения.

• При передаче посредством SSU (Secure Semireliable UDP), 16-байтовый стандартный заголовок не используется. Включаются только 1-байт типа и 4-байта времени истечения пригодности (в секундах). Идентификатор сообщения и размер инкорпорировались в различные части информационных пакетов SSU.
• Стандартный заголовок необходим также для I2NP сообщений, содержащихся в других сообщениях и структурах (Данные, TunnelData, TunnelGateway и GarlicClove).

BuildRequestRecord

Один рекорд в наборе из нескольких рекордов для запроса создания одного шага туннеля.

За TunnelId принимаемого сообщения следует Hash нашего RouterIdentity, после которого следует TunnelId и Hash RouterIdentity следующего маршрутизатора.

Рис. 11. Формат BuildRequestRecord

Зашифровано c привлечением алгоритма ElGamal:

незашифровано:

Для поля зашифрованные данные используются алгоритмы Эль-Гамаля и AES:

Не зашифровано
Туннель получателя :: TunnelId
длина -> 4 байта

Наш идентификатор :: хэш
длина -> 32 байта
Следующий_туннель :: TunelId
длина -> 4 байта

Следующий идентификатор :: хэш
длина -> 32 байта
ключ слоя :: SessionKey длина -> 32 байта Ключ iv :: SessionKey (ключ вектора инициализации)
длина -> 32 байта
ключ ответа :: SessionKey
длина -> 32 байта
iv ответа :: данные
длина -> 16 байта
Флаг :: целое
длина -> 1 байт
Время запроса :: целое
длина -> 4 байта
Часы с начала эпохи, т.e. текущее время / 3600
ID посланного сообщения :: целое
длина -> 4 байта
Заполнитель :: Data
длина -> 29 байт
source -> random

Полная длина: 222
Зашифровано ElGamal:
toPeer :: первые 16 байт SHA-256 хэша ID маршрутизатора партнера
длина -> 16 байт
Зашифрованные данные :: данные, зашифрованные ElGamal-2048
длина -> 512

Полная длина: 528
Зашифровано ElGamal и AES:
Зашифрованные данные :: данные, зашифрованные с помощью ElGamal и AES
длина -> 528
Полная длина: 528

• В 512-байтной зашифрованной записи, данные ElGamal содержат байты 1-256 и 258-513 зашифрованного блока 514-байт ElGamal. Два байта заполнителя из блока (нулевые байты в положении 0 и 257) удаляются.

BuildResponseRecord

незашифровано:

Рис. 12.

0-526 байтов: произвольные данные
527 байт : отклик (reply)

Зашифровано:
0-527 байтов: запись, зашифрованная AES (замечание: тот же размер, что и BuildRequestRecord)
Полная длина: 528

• Первые 527 байт могут, в будущем, использоваться для посылки информации о перегрузке или коннективности партнера субъекту, пославшему запрос.

GarlicClove

незашифровано:

Рис. 13. Формат GarlicClove

Не зашифровано:
Инструкции доставки :: http://www.i2p2.de/tunnel_message_spec.html#delivery
Длина варьируется, но обычно равно 39, 43 или 47 байт
I2NP-сообщение :: Любое I2NP-сообщение
ID секции :: 4 байта целое
Время истечения пригодности :: дата (8 байт)
Сертификат :: В настоящей реализации всегда NULL (3 байта, все нули)

• Секции (Garlic Clove) никогда не фрагментируются. Когда используются в Garlic Clove, первый бит байта флага инструкций доставки (бит фрагмента) переопределен. Если этот бит равен 0, секция (clove) не зашифрована. Если 1, секция зашифрована и за байтом флага немедленно следует 32-байтовый ключ сессии.
• Смотри также http://www.i2p2.de/how_garlicrouting.html.
• Смотри также http://www.i2p2.de/tunnel_message_spec.html#delivery
• Максимальная длина является функцией полной длины всех секций (cloves) и максимальной длины GarlicMessage.
• Сообщением может быть любое I2NP-сообщение (включая GarlicMessage, хотя это и не используется на практике). На практике используются сообщения DataMessage, DeliveryStatusMessage и DatabaseStoreMessage.В будущем для HashCash может использоваться сертификат.
• Clove ID (идентификатор секции) устанавливается при передаче равным случайному числу и проверяется на дублирование при получении

Инструкции доставки

Определены в http://www.i2p2.de/tunnel_message_spec.html#delivery.

Таблица 2. Типы сообщений

DatabaseStore

Запись в базу данных по собственной инициативе, или отклик на успешный запрос-сообщение базы данных (Lookup).

Некомпрессированный LeaseSet или компрессированный RouterInfo с кодами отклика:

Рис. 14. Формат DatabaseStore

с кодом отклика == 0:

Рис. 14A.

ключ: 32 байт
SHA256 хэш
Тип: 1 байт
Идентификатор типа
соответствие:br> 0 RouterInfo
1 LeaseSet

Коды отклика: 4 байта

Если больше нуля, запрошен Delivery Status Message c ID-сообщения равным значению Reply Token.

Если код больше нуля, ожидается, что Floodfill-маршрутизатор направляет поток данных ближайшему floodfill-партнеру.

TunnelId отклика: 4 байта ID туннеля
Включается только, если код отклика > 0
Это ID шлюза входящего туннеля, отклик которому должен быть послан.

Шлюз отклика: 32 байта
Хэш записи routerInfo включается только, если код отклика > 0

Это хэш маршрутизатора шлюза входящего туннеля, куда должен быть послан отклик.

Данные:
Если тип == 0, данные содержат 2-байтовое целое, специфицирующее число байт, которые далее следуют, далее располагается gzip-компрессированная RouterInfo.
Если тип == 1, данные являются некомпрессированным набором LeaseSet.

DatabaseLookup

Рис. 15. Формат DatabaseLookup

Ключ: 32 байта
SHA256 хэш объекта запроса lookup
От (from): 32 байт

Если флаг == 0, SHA256 хэш записи routerInfo, указывает, откуда пришел этот запрос (и куда должен быть послан отклик).

Если флаг == 1, SHA256 хэш отклика шлюза туннеля (которому должен быть послан отклик).

Флаг: 1 байт
Возможные значения:
0 FALSE => послать отклик непосредственно
1 TRUE => послать отклик в некоторый туннель

TunnelId отклика: 4 байта Туннель ID
Включается, если только flag==TRUE
TunnelId туннеля, чтобы послать отклик
Размер: 2 байта целое
Возможный диапазон: 0-512

Число партнеров, которых следует исключить из Database Search Reply Message.

excludedPeers:

Остальная часть сообщения имеет размер $size SHA256 хэшей по 32 байта каждый (всего $size*32 байт).

Если запрос lookup неудачен, партнеры запрашиваются на предмет исключения их из списка сообщения отклика Database Search.

Если excludedPeers включает в себя хэш со всеми нулями, запрос является исследовательским, и сообщение Database Search Reply запрошено для получения списка non-floodfill маршрутизаторов.

DatabaseSearchReply

Отклик на сообщение о неудаче запроса базе данных.

Список хэшей маршрутизаторов, наиболее близких к запрошенному ключу.

Рис. 16. Формат DatabaseSearchReply

Ключ: 32 байта
SHA256 объекта, который ищется
num: 1 байт целое
Число хэшей партнеров, которые далее следуют
хэш партнера: 32 байта
SHA256 RouterInfo, которую другие маршрутизаторы считают наиболее близкой к ключу $num записей
от: 32 байта
SHA256 RouterInfo маршрутизатора, от которого должен быть послан отклик.

Хэш 'от' не аутентифицирован и ему нельзя доверять.

DeliveryStatus

Простое сообщение подтверждения. Обычно формируется отправителем сообщения, и помещается в Garlic-сообщение, для отправки по адресу места назначения.

ID доставленного сообщения и время создания или прибытия.

Рис. 17. Формат DeliveryStatus

msg-id: 4 байта
уникальный ID сообщения, в котором мы посылаем DeliveryStatus (см. Общий заголовок I2NP)
Временная метка: дата
8 байт
Время, когда сообщение было сформировано или доставлено

Временная метка всегда устанавливается отправителем равной текущему времени.

Garlic

Используется, чтобы сворачивать вместе несколько зашифрованных I2NP-сообщений. После расшифровки, представляет последовательность Garlic Cloves (секций).

зашифровано:

Рис. 18. Формат DeliveryStatus

Незашифрованные данные:

Рис. 18A.

Зашифровано:
Длина: 4 байта целое
Число, которое следуют далее, 0 - 64 Kбайта

Данные: $length байт
ElGamal зашифрованные данные
Незашифрованные данные:
num: 1 байт целое число Garlic-секций, следующих далее.

секция: Garlic Clove
Сертификат :: всегда нуль в текущей реализации (всего 3 байта нулей)
ID сообщения :: 4 байта целое
Время пригодности :: дата (8 байт)

• Когда данные незашифрованы, они содержат одну или более Garlic Cloves (секций).
• Блок, зашифрованный AES дополняется заполнителем до минимального размера 128 байт; с 32-байтовым флагом секции. Минимальный размер зашифрованного сообщения равен 160 байтам; Вместе с 4 байтами длины минимальный размер Garlic-сообщения равен 164 байтам.
• Реальная максимальная длина меньше 64 Kбайтов.
• Смотри http://www.i2p2.de/how_elgamalaes.html.
• Смотри также http://www.i2p2.de/how_garlicrouting.html.
• 128-байтный минимальный размер блока, зашифрованного AES в настоящее время не конфигурируется, однако минимальный размер DataMessage в GarlicClove в GarlicMessage, с избыточностью равен 128 байтам в любом случае.
• ID-сообщения обычно является случайным числом при передаче и игнорируется при приеме.
• В будущем, возможно, будет использоваться сертификат для HashCash.

TunnelData

Рис. 19. Формат TunnelData

ID-туннеля: 4 байта ID туннеля
идентифицирует туннель, куда следует послать сообщение
Данные: 1024 байт
Поле данных до 1024 байт

TunnelGateway

Рис. 20. Формат TunnelGateway

TunnelId: 4 байта ID туннеля
идентифицирует туннель, куда должно быть направлено сообщение.
Длина: 2 байта целое
Длина поля данных
Данные : $length байт
Поле данных сообщения.

Данные

Используется в качестве упаковки для зашифрованных Garlic-сообщений и Garlic Cloves (секций).

Длина - целое, далее следуют непрозрачные данные.

Рис. 21. Формат поля данные

Длина: 4 байта
Длина поля данных
Данные: $length байт
Поле данных сообщения

TunnelBuild

Содержит в себе 8 рекордов Build Request, пронумерованных от 0 до 7, объединенных вместе.

Размер записи: 528 байт
Полная длина: 8*528 = 4224 байта

TunnelBuildReply

Тот же формат, что и у сообщения ТуннельBuild, c Build Response Records

VariableTunnelBuild

Рис. 22. Формат VariableTunnelBuild

Тот же формат, что и ТуннельBuildMessage, за исключением добавления в начале поля "num" и числа $num записей, образующих запрос вместо 8.

num: 1 байт целое
Возможные значения: 1-8
Размер записи: 528 байт
Полный размер: 1 + $num*528

• Это сообщение было введено в маршрутизаторы версии 0.7.12, и может не посылаться в туннель для участников более ранней версии.
• Смотри также http://www.i2p2.de/tunnel-alt-creation.html.

VariableTunnelBuildReply

Рис. 23. Формат VariableTunnelBuildReply

Тот же формат, что и в сообщении VariableTunnelBuild, с записями Build Response.

• Это сообщение было введено в маршрутизаторы версии 0.7.12, и не может быть послано в туннель участников более ранней версии.
• Смотри также http://www.i2p2.de/tunnel-alt-creation.html и http://www.i2p2.de/common_structures_spec.html.

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

I2P поддерживает много видов транспорта одновременно. В настоящее время реализованы две разновидности транспорта:

1. NTCP, Java New I/O (NIO) TCP транспорт
2. SSU - http://www.i2p2.de/udp.html, или Secure Semireliable UDP

Каждый реализует парадигму соединения с аутентификацией управлением потока, подтверждениями и повторными передачами.

Транспортные услуги

Транспортная подсистема I2P предоставляет следующие сервисы:

• Поддерживает набор адресов маршрутизаторов, один или более для каждого из видов транспорта, которые маршрутизатор публикует, как свою глобальную контактную информацию (RouterInfo)
• Выбор наилучшего транспорта для каждого исходящего сообщения
• Организует очереди исходящих сообщений в соответствии с приоритетом
• Ограничивает полосу для входящего и исходящего потоков согласно конфигурации маршрутизатора
• Устанавливает и прерывает транспортных соединений
• Шифрование коммуникаций точка-точка
• Поддержка ограничений соединений для каждого вида транспорта, реализация различных порогов для этих ограничений, и передача состояния порогов маршрутизатору, чтобы он мог внести нужные изменения на основе этих данных.
• Обеспечение работы портов Firewall, используя UPnP (Universal Plug and Play)
• Совместное отслеживание NAT/Firewall
• Детектирование локальных IP различными методами, включая UPnP, инспекция входящих соединений и нумерация сетевых устройств
• Координация статуса и локальных IP firewall
• Передача состояния firewall и изменений маршрутизатору и пользовательскому интерфейсу
• Определение согласованности часов, которые используются для периодической коррекции показаний часов маршрутизатора в качестве подстраховки для NTP.
• Поддержание состояния каждого из партнеров, включая контроль подключенности
• Квалификация корректности IP-адресов согласно набору локальных правил
• Отслеживание автоматических и ручных списков запрещенных партнеров, поддерживаемых маршрутизатором, и реализация запретов входящих и исходящих соединений с этими партнерами.

Транспортные адреса

Транспортная подсистема поддерживает набор адресов маршрутизатора, каждый из которых содержит транспортный метод, IP и порт. Эти адреса представляют собой анонсированные контактные точки, которые публикуются маршрутизатором в сетевой базе данных.

Типичными сценариями являются:

• Маршрутизатор не имеет опубликованных адресов, таким образом, он считается "скрытым" и не может реализовать входящих соединений.
• Маршрутизатор является защищенным посредством firewall, и, следовательно, публикует SSU-адрес, который содержит список взаимодействующих партнеров.
• Маршрутизатор не защищен Firewall’ом или его порты NAT открыты; Он публикует NTCP и SSU адреса, содержащие непосредственно доступные IP и порты.

Выбор транспорта

Транспортная система доставляет сообщения I2NP. Выбор транспорта для каждого сообщения является независимым от протокола прикладного уровня (TCP или UDP).

Для каждого исходящего сообщения транспортная система запрашивает "цену” (bids) для каждого вида транспорта. При транспортной оценке нижняя цена выигрывает и получает сообщение для доставки. Транспорт может отказаться конкурировать.

Будет ли транспорт конкурировать (bids), и с каким значением, зависит от многих факторов:

• Конфигурации транспортных предпочтений
• Подключен ли транспорт к партнеру
• Числа текущих соединений по сравнению со значениями порогов на число соединений
• Потерпела ли неудачу попытка соединения с партнером
• Размер сообщения, так как разные виды транспорта требуют разных ограничений размера
• Может ли партнер принять входящее соединение для данного вида транспорта, как это объявлено в RouterInfo
• Будет ли соединение непрямым (нужен посредник) или прямым
• Транспортное предпочтение партнера, как указано в его RouterInfo

Вообще, значения цены выбираются так, чтобы два маршрутизатора имели только одно соединение одновременно. Однако это не является обязательным требованием.

Управление перегрузкой

SSU нужен только для полунадежной доставки, TCP-подобных операций, и емкости для высокой пропускной способности, чтобы обеспечить приемлемую широту управления перегрузкой. Алгоритм управления перегрузкой, описанный ниже, достаточно прост для реализации.

Пакеты посылаются в порядке, определяемом политикой маршрутизатора, заботясь о том, чтобы не превысить выходной емкости маршрутизатора или возможностей удаленного партнера. Измеренная полоса учитывается во всех каналах при медленном старте TCP и при избегании перегрузки (используется алгоритм AIMD (additive increases and multiplicative decreases)). В отличие от TCP, маршрутизаторы могут прерывать попытки передать определенное сообщение после определенного числа неудач, продолжая передавать другие сообщения.

Методики детектирования перегрузки также отличаются от TCP, так как каждое сообщение имеет свой собственный уникальный идентификатор, и каждое сообщение имеет ограниченный размер – не более 32Kбайт. Чтобы эффективно обеспечить обратную связь с отправителем, получатель периодически включает список идентификаторов полностью подтвержденных сообщений и может также включать битовые поля для частично доставленных сообщений, где каждый бит представляет получение определенного фрагмента. Если приходит задублированный фрагмент, сообщение должно быть подтверждено снова, или если сообщение не было полностью доставлено, битовое поле должно быть переслано повторно.

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

MTU

Так как для версии маршрутизатора 0.8.12, используются два значения MTU: 620 и 1484. Значение MTU определяется процентом повторно пересылаемых пакетов.

Для обоих значений MTU, желательно, чтобы (MTU % 16) == 12, так что для целей шифрования доля поля данных после 28-байтного IP/UDP заголовка была кратной 16 байтам. Это справедливо только для IPv4.

Для малого значения MTU, желательно упаковать 2646-байтное сообщение в несколько пакетов.

На основе измерений MTU=1492 подходит практически для всех разумно малых I2NP-сообщений (большие I2NP-сообщения могут достигать 1900 - 4500 байт, которые не согласуются с сетевым значением MTU).

Значения MTU равнялись 608 и 1492 для версий 0.8.9 - 0.8.11.

Максимальный размер получаемых пакетов равен 1571 байтам (для версии 0.8.12). Для версий 0.8.9 - 0.8.11 это число равно 1535 байтам.

Ограничения размера сообщений

В то время как номинально максимальный размер сообщения равен 32Kбайт, на практике этот предел может варьироваться. Протокол ограничивает число фрагментов 7 битами, или 128. Текущая реализация, однако, ограничивает каждое сообщение максимум 64 фрагментами, каждый из которых достаточен для 64 * 534 = 33.3 Kбайт, при использовании 608 MTU. Из-за избыточности в случае добавления LeaseSets и ключей сессии, практическое ограничение на прикладном уровне несколько ниже 6Kбайт, или около 26Kбайт. Необходима дальнейшая работа, чтобы поднять транспортный предел UDP выше 32Kбайт. Для соединений, использующих большие значения MTU, допустимы сообщения большей длины.

Ключи

Все шифрования используют AES256/CBC с 32-байтными ключами и 16 байтами IV. MAC и ключи сессии согласуются в процессе DH-обмена, используемого для HMAC (Hashed Message Authentication Code) и шифрования, соответственно. Перед DH-обменом, для MAC и шифрования используется общедоступный introKey.

При использовании introKey, как исходное сообщение, так и любой последующий отклик используют introKey Боба – субъект отклика не обязан знать introKey субъекта запроса (Алисы). DSA-ключ подписи, используемый Бобом, должен быть известен Алисе, когда она с ним контактирует, хотя ключ DSA Алисы может быть не известен Бобу.

По получении сообщения получатель проверяет IP-адрес "От" и порт для всех установленных сессий – если соответствие имеется, MAC ключи сессий проверяются в HMAC. Если ни один из них не верифицирован или, если нет соответствия для IP-адресов, получатель пытается применить свои introKey в MAC. Если верификация не прошла, пакет отбрасывается. Если верификация успешна, результат интерпретируется в соответствии с типом сообщения, хотя если получатель перегружен, он может отбросить пакет все равно.

Если Алиса и Боб имеют установленную сессию, но Алиса по каким-то причинам теряет ключи и она хочет контактировать с Бобом, она может в любое время установить новую сессию с помощью SessionRequest. Если Боб потерял ключ, а Алиса его не знает, она сначала попытается вызвать его отклик, послав DataMessage с установленным флагом wantReply, и, если Боб не отвечает, она предполагает ключ потерянным и формирует новый.

Для ключевого соглашения DH, RFC3526 2048бит MODP используется:

p=2²⁰⁴⁸ - 2¹⁹⁸⁴ - 1 + 2⁶⁴ ×{ [2¹⁹¹⁸ pi] + 124476}
g=2;

Аналогичные значения p и g используются для шифрования I2P's ElGamal.

Предотвращение отклика

Предотвращение отклика на SSU-уровне происходит при отбрасывании пакета с чрезмерно старой временной меткой или пакетов, который повторно используют IV. Чтобы детектировать дубликаты IV, применена последовательность фильтров Блума (Bloom).

MessageIds используемые в DataMessages определены на уровне выше SSU-транспорта и передаются прозрачным образом. Эти ID никак не упорядочены – и в действительности являются случайными кодами. Уровень SSU не делает попыток предотвращения отклика с messageId – эту задачу должны брать на себя более высокие уровни.

Адресация

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

Непосредственно: машина, порт, introKey, опции
Апосредовано: метка, relayhost, порт, relayIntroKey, targetIntroKey, опции

Каждый из адресов может также предоставлять некоторый набор опций – специальные возможности конкретного партнера.

Прямое установление сессии

Непосредственное установление сессии используется, когда не нужен какой-либо посредник для NAT преобразования. Последовательность обмена выглядит следующим образом:

Установление соединения (прямого)

Алиса устанавливает непосредственное соединение с Бобом.

       Алиса                            Боб
SessionRequest--------------------->
          <---------------------SessionCreated
SessionConfirmed------------------>
          <---------------------->Данные

Вводные ключи доставляются через внешний канал (сетевая база данных, где они на данный момент идентичны хэшу маршрутизатора) и должны использоваться при формировании ключа сессии. Для непрямых адресов партнер должен сначала контактировать с узлом-ретранслятором и просить его представления партнеру, известному этому ретранслятору под заданным именем (tag). Если возможно, ретранслятор посылает сообщение адресуемому партнеру, уведомляя его о необходимости контактировать с партнером, пославшим запрос, а также дает запрашивающему партнеру IP и порт, по которым он находится. Кроме того, партнеру, устанавливающему соединение, должен быть известны общедоступные ключи партнера, с которым они устанавливают соединение.

Установление непрямых сессий через посредника необходимо для эффективного отслеживания NAT. Чарли, маршрутизатор за NAT или firewall’ом, который не допускает незапрошенных входящих UDP-пакетов, сначала контактирует с несколькими партнерами, выбирая те, которые могут быть ретрансляторами. Каждый из этих партнеров (Боб, Бил, Бетти и т.д.) предоставляет Чарли вводную метку - 4 байтовое случайное число, которое он делает доступным для контактирования с ним. Алиса, маршрутизатор, который знает опубликованные методы контакта с Чарли, сначала посылает пакет RelayRequest одному или более посредникам, прося представить ее Чарли (предлагая метку, идентифицирующую Чарли). Боб переадресует пакет RelayIntro Чарли, включая публичный IP и номер порта Алисы, затем возвращает Алисе пакет RelayResponse, содержащий IP-адрес Чарли и его номер порта. Когда Чарли получает пакет RelayIntro, он посылает небольшой пакет по IP-адресу Алисы, и, когда Алиса получает от Боба пакет RelayResponse, она начинает формирование новой сессии для специфицированного IP и номера порта.

Установление соединения

Алиса сначала устанавливает соединение с Бобом, который передает запрос Чарли.

        Алиса                         Боб                  Чарли
    RelayRequest ---------------------->
         <--------------RelayResponse    RelayIntro----------->
         <--------------------------------------------HolePunch (данные игнорируются)
    SessionRequest-------------------------------------------->
         <--------------------------------------------SessionCreated
    SessionConfirmed------------------------------------------>
         <----------------------------------------------->Данные

Тестирование партнера

Автоматизация тестирования коллаборативной доступности для партнеров обеспечивается с помощью последовательности PeerTest-сообщений. При их корректном исполнении партер будет способен определить свою доступность и скорректировать свои рабочие параметры. Процесс тестирования достаточно прост:

        Алиса                  Боб                  Чарли
    PeerTest ------------------->
                             PeerTest-------------------->
                                <-------------------PeerTest
         <-------------------PeerTest
         <------------------------------------------PeerTest
    PeerTest------------------------------------------>
         <------------------------------------------PeerTest

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

• Если она не получила отклик от Боба, она снова выполнит передачу определенное число раз, но если отклика все равно не приходит, она знает, что ее firewall или NAT сконфигурированы некорректно, отбрасывая все входящие UDP-пакеты. В свою очередь Боб может быть отключен или неспособен заставить Чарли откликнуться.
• Если Алиса не получает сообщения PeerTest с ожидаемым кодом от посредника (Чарли), она будет ретранслировать свой исходный запрос Бобу определенное число раз, даже если она уже получила отклик Боба. Если первого сообщения Чарли нет, а Боба - есть, она знает, что она находится за NAT или firewall, которые отвергают попытки не запрошенных соединений и что порт переадресации не функционирует (IP и порт, которые Боб предложил для переадресации).
• Если Алиса получает сообщение PeerTest Боба и оба сообщения PeerTest Чарли, но IP номера портов во вторых сообщениях Боба и Чарли не согласуются, она знает, что находится за симметричным NAT, переписывающим все ее исходящие пакеты с другими портами 'от' для каждого контактируемого партнера. Ей будет нужно явно переадресовать порт.
• Если Алиса получает первое сообщение Чарли, но не получает второго, она повторно пошлет свое сообщение PeerTest к Чарли оговоренное число раз, но если не будет получено отклика, она будет знать, что Чарли недоступен.

Алиса должна выбрать Боба произвольно из числа известных партеров, которые кажутся способными участвовать в тестировании партнеров. Боб в свою очередь должен аналогично выбрать Чарли из числа известных ему партнеров, кто кажется способным участвовать в тестировании и кто использует IP отличающиеся от адресов Боба и Алисы. Если реализовано условие ошибки (Алиса не получила сообщения PeerTest от Боба), Алиса может решить назначить новым партнером Боба и попытаться снова с другим кодом безопасности (nonce).

Вводный ключ Алисы включен во все сообщения PeerTest, так что ей не нужно устанавливать сессию с Бобом и что Чарли может контактировать с ней, не имея какой-либо дополнительной информации. Алиса может продолжить, установив сессию с Бобом или Чарли, но это не является необходимым.