ПРИМЕЧАНИЕ
Это предложение было одобрено и теперь входит в Tunnel Creation ECIES specification с API 0.9.65. Пока что известные реализации отсутствуют; даты внедрения / версии API TBD.
Обзор
Поскольку мы увеличили производительность сети за последние несколько лет с помощью новых протоколов, типов шифрования и улучшений управления перегрузками, стали возможны более быстрые приложения, такие как потоковое видео. Эти приложения требуют высокой пропускной способности на каждом шаге в их клиентских туннелях.
Однако участвующие маршрутизаторы не имеют информации о том, сколько пропускной способности будет использовать туннель, когда они получают сообщение о создании туннеля. Они могут только принять или отклонить туннель на основе текущей общей пропускной способности, используемой всеми участвующими туннелями, и общего лимита пропускной способности для участвующих туннелей.
Маршрутизаторы, запрашивающие туннели, также не имеют информации о том, сколько пропускной способности имеется в каждом шаге.
Кроме того, в настоящее время маршрутизаторы не могут ограничивать входящий трафик в туннеле. Это было бы очень полезно во времена перегрузок или DDoS-атак на сервис.
Это предложение решает эти проблемы, добавляя параметры пропускной способности к сообщениям запроса и ответа на создание туннеля.
Дизайн
Добавьте параметры пропускной способности к записям в сообщениях создания туннеля ECIES (см. Tunnel Creation ECIES specification) в поле отображения параметров создания туннеля. Используйте короткие названия параметров, так как доступное пространство для поля параметров ограничено. Сообщения создания туннеля имеют фиксированный размер, поэтому увеличение размера сообщений не происходит.
Спецификация
Обновите спецификацию сообщений создания туннеля ECIES следующим образом:
Для длинных и коротких записей создания ECIES:
Параметры Запроса Создания
Следующие три параметра могут быть установлены в поле отображения параметров создания туннеля записи: Запрашивающий маршрутизатор может включать любой, все или ни один из них.
- m := минимальная пропускная способность, требуемая для этого туннеля (KBps - положительное целое число в виде строки)
- r := запрашиваемая пропускная способность для этого туннеля (KBps - положительное целое число в виде строки)
- l := ограничение пропускной способности для этого туннеля; отправляется только на IBGW (KBps - положительное целое число в виде строки)
Ограничение: m <= r <= l
Участвующий маршрутизатор должен отклонить туннель, если указано “m”, и он не может предоставить хотя бы такую пропускную способность.
Параметры запроса отправляются каждому участнику в соответствующей зашифрованной записи запроса на создание, и не видны другим участникам.
Параметр Ответа на Создание
Следующий параметр может быть установлен в поле отображения параметров ответа на создание туннеля записи, когда ответ ПРИНЯТ:
- b := доступная пропускная способность для этого туннеля (KBps - положительное целое число в виде строки)
Участвующий маршрутизатор должен включить этот параметр, если в запросе создания было указано “m” или “r”. Значение должно быть не менее значения “m”, если оно указано, но может быть меньше или больше значения “r”, если оно указано.
Участвующий маршрутизатор должен попытаться зарезервировать и предоставить по меньшей мере эту пропускную способность для туннеля, однако это не гарантируется. Маршрутизаторы не могут предсказать условия через 10 минут, а участвующий трафик имеет более низкий приоритет, чем собственный трафик маршрутизатора и туннели.
Маршрутизаторы могут также перераспределять доступную пропускную способность при необходимости, и это, вероятно, желательно, так как другие шаги в туннеле могут его отклонить.
По этим причинам ответ участника должен рассматриваться как обязательство прилагать все усилия, но не как гарантия.
Параметры ответа отправляются запрашивающему маршрутизатору в соответствующей зашифрованной записи ответа на создание, и не видны другим участникам.
Примечания по Реализации
Параметры пропускной способности рассматриваются на уровне туннелей на участвующих маршрутизаторах, то есть определяется количество фиксированных 1 KB сообщений туннеля в секунду. Накладные расходы транспортировки (NTCP2 или SSU2) не включены.
Эта пропускная способность может быть намного большей или меньшей, чем та, которая видна клиенту. Сообщения туннеля содержат значительные накладные расходы, включая накладные расходы от более высоких уровней, включая ратчет и поток. Временные маленькие сообщения, такие как квитанции потоковой передачи, будут расширены до 1 KB каждое. Однако сжатие gzip на уровне I2CP может значительно уменьшить пропускную способность.
Наипростейшей реализацией на запрашивающем маршрутизаторе является использование средней, минимальной и/или максимальной пропускной способностей текущих туннелей в пуле для расчета значений, которые необходимо указать в запросе. Возможны более сложные алгоритмы, и они зависят от реализующего.
В настоящее время нет определенных параметров I2CP или SAM для клиента, чтобы сообщить маршрутизатору, какая пропускная способность требуется, и здесь не предлагаются новые параметры. Параметры могут быть определены позднее, если это необходимо.
Реализации могут использовать доступную пропускную способность или любые другие данные, алгоритмы, локальную политику или локальную конфигурацию для расчета значения пропускной способности, возвращаемого в ответе на создание. Это не указано в этом предложении.
Это предложение требует, чтобы входные шлюзы реализовали ограничение по туннелю по запросу параметра “l”. Оно не требует от других участвующих шагов реализации каких-либо типов ограничения по туннелю или глобального ограничения, или указывает конкретный алгоритм или реализацию, если таковые имеются.
Это предложение также не требует, чтобы клиентские маршрутизаторы ограничивали трафик до значения “b”, возвращенного участвующим шагом, и в зависимости от приложения это может быть невозможно, особенно для входных туннелей.
Это предложение касается только туннелей, созданных инициатором. Нет метода, определенного для запроса или распределения пропускной способности для “конечных” туннелей, созданных владельцем другого конца конечного подключения.
Анализ Безопасности
Может быть возможна распознаваемость клиента или корреляция на основе запросов. Клиентский (инициирующий) маршрутизатор может захотеть случайно выбрать значения “m” и “r” вместо того, чтобы отправлять одно и то же значение на каждый шаг; или отправлять ограниченный набор значений, представляющих “уровни” пропускной способности, или сочетание обоих.
DDoS через перераспределение: Хотя в настоящее время возможно DDoS-атака маршрутизатора путем создания и использования большого количества туннелей через него, это предложение, возможно, значительно упрощает это, просто запрашивая один или несколько туннелей с большими пропусками.
Реализации могут и должны использовать одну или несколько из следующих стратегий для снижения этого риска:
- Перераспределение доступной пропускной способности
- Ограничение распределения пропускной способности на туннель в процентном отношении от доступной пропускной способности
- Ограничение скорости увеличения выделенной пропускной способности
- Ограничение скорости увеличения используемой пропускной способности
- Ограничение выделенной пропускной способности для туннеля, если она не используется на ранних стадиях жизненного цикла туннеля (используй или теряй)
- Отслеживание средней пропускной способности на туннель
- Отслеживание запрашиваемой и фактически используемой пропускной способности на туннель
Совместимость
Проблем нет. Все известные реализации в настоящее время игнорируют поле отображения в сообщениях создания, и корректно пропускают непустое поле параметров.
Миграция
Реализации могут добавлять поддержку в любое время, координация не требуется.
Поскольку в настоящее время не определена версия API, где поддержка этого предложения обязательна, маршрутизаторы должны проверять наличие ответа “b” для подтверждения поддержки.