Обзор
Соединения потокового клиента могут зависать, когда подтверждения доставки теряются без уведомления. Отправитель повторно передаёт данные, пока не получит подтверждение или соединение не будет разорвано, при этом нет надёжного способа проверить, достигают ли подтверждения другой стороны. В данном предложении добавляется один новый флаговый бит в поле флагов SendMessageExpiresMessage , чтобы клиент мог указать маршрутизатору выбрать другой исходящий тоннель для последующих сообщений тому же получателю. Протокол потоковой передачи использует этот бит для инициации смены тоннеля при обнаружении зависшего соединения.
Триггеры
Клиент ДОЛЖЕН установить флаг в следующем исходящем сообщении при наступлении двух условий. Эти условия проверяются на уровне потоковой передачи.
Сторона отправителя
Подтверждение не было получено в течение текущего периода повторной передачи клиента.
Сторона получателя
Получатель обнаружил, что удалённая сторона повторно передаёт одни и те же данные более одного раза, что указывает на то, что её подтверждения не доходят до удалённой стороны. Получатель ДОЛЖЕН установить этот флаг в своём следующем исходящем I2CP-сообщении, чтобы подтверждения достигли удалённой стороны по другому пути. Получатель ОБЯЗАН дождаться выполнения следующих условий: (1) он получил дубликат данных, (2) он отправил хотя бы одно подтверждение, и (3) удалённая сторона снова выполнила повторную передачу, прежде чем устанавливать флаг.
Чтобы ограничить атаки по корреляции времени, клиент НЕ ДОЛЖЕН устанавливать флаг чаще одного раза в 10-секундное окно на одно соединение. Клиенту также следует задержать установку флага на случайное значение дрожания (jitter), равномерно выбранное из интервала [0, min(T/4, 2000ms)], где T — текущий тайм-аут повторной передачи клиента в миллисекундах, после обнаружения состояния зависания, с целью уменьшения точности корреляции по времени.
Спецификация
Поле флагов SendMessageExpiresMessage занимает старшие 2 байта после поля Date (переопределено начиная с версии 0.8.4) и передаётся в формате big-endian. Бит 15 в настоящее время не используется; данное предложение определяет его назначение.
Порядок битов: 15…0
| Бит | Имя | Описание |
|---|---|---|
| 15 | SWITCH_OUTBOUND_TUNNEL | Если установлен в 1, маршрутизатор ДОЛЖЕН выбрать другой исходящий туннель из своего пула для последующих сообщений этому получателю. Если альтернативный туннель недоступен, этот флаг игнорируется без уведомления. Маршрутизатор НЕ ДОЛЖЕН закрывать или выводить из эксплуатации ранее использованный туннель только потому, что этот флаг был установлен. |
| Значение этого флага по умолчанию равно 0. Маршрутизаторы, которые не реализуют его, ДОЛЖНЫ игнорировать его без ошибок. |
Заметки по реализации
Когда установлен параметр SWITCH_OUTBOUND_TUNNEL, маршрутизатор ДОЛЖЕН выбирать туннель равномерно случайным образом из исходящего пула, исключая:
- туннель, который в данный момент используется в этой сессии, и
- единственный наиболее недавно неудавшийся туннель в пуле, если таковой имеется.
Все остальные метрики состояния туннеля, времена построения или история выбора НЕ ДОЛЖНЫ влиять на выбор, поскольку взвешенный выбор может способствовать атакам типа sybil. Если после этих исключений в пуле не останется подходящих туннелей, флаг игнорируется без уведомления.
Этот флаг не требует дополнительных сообщений туннеля; переключение туннелей может изменить видимую задержку. Ограничение скорости в 10 секунд на подключение (см. Триггеры) предотвращает чрезмерное переключение.
Соображения по анонимности
Флаги в SendMessageExpiresMessage передаются через I2CP — локальный интерфейс между клиентом и его собственным роутером. Они недоступны для наблюдателей в сети.
Риск анонимности связан с анализом шаблонов трафика: злоумышленник, имеющий возможность наблюдать за несколькими конечными точками туннеля, может видеть, когда изменяется использование туннеля.
Переключение исходящих туннелей в прямой реакции на остановку на стороне клиента создаёт обнаруживаемый поведенческий паттерн. Существует два конкретных вектора наблюдения:
Атака Сибил на первые хопы исходящих туннелей
Первый узел каждого исходящего туннеля видит весь трафик, поступающий в этот туннель с маршрутизатора отправителя. Атакующий, контролирующий первый узел более чем одного туннеля в пуле отправителя, может наблюдать, как трафик прекращается на одном первом узле и почти сразу начинается на другом, что позволяет связать оба туннеля с одним отправителем. При наличии пула из N туннелей и контроле злоумышленником K первых узлов, вероятность наблюдения любого конкретного события переключения составляет K/N.
Временные интервалы трафика
Во время задержки клиент не отправляет новые данные, поэтому исходящий туннель становится неактивным. Когда происходит переключение, трафик возобновляется по другому пути. Атакующий, имеющий возможность наблюдения за маршрутизатором отправителя — например, интернет-провайдер отправителя или сам первый узел маршрута — может зафиксировать паттерн «тишина — возобновление». Продолжительность паузы дополнительно раскрывает приблизительное значение тайм-аута повторной передачи, используемого клиентом в данный момент.
Клиенты ДОЛЖНЫ соблюдать требования к ограничению скорости и джиттеру, указанные в разделе Triggers.