Кратко

  • 24 августа 2026 года IESG одобрил редакцию 16 draft-ietf-masque-connect-udp-listen как Proposed Standard. На дату фиксации доказательств документ оставался Internet-Draft в очереди RFC Editor; в объявлении сказано о совместимости реализаций Google Quiche и quic-go.
  • Механизм сохраняет одну публичную UDP-пару адреса и порта для нескольких удалённых пар в рамках одного HTTP-запроса. Это выдача ресурса достижимости, а не всеобщее разрешение: согласование, регистрация Context ID, политика назначения и фактическая доставка остаются отдельными решениями.

Один порт, два отправителя

Браузер просит у HTTP-прокси публичный UDP-адрес для сеанса WebRTC. Прокси выбирает IP и порт. Первый пакет приходит от партнёра, выбранного ICE. Второй — от постороннего сканера, случайно обнаружившего тот же порт.

До сокета дошли оба. Право попасть в туннель из этого не следует ни для одного автоматически.

Это иллюстрация границы, а не сообщение об инциденте. Смысл «Proxying Bound UDP in HTTP» состоит в том, чтобы дать стабильную точку встречи, не создавая открытый relay. После сетевого прибытия значение имеют аутентифицированный запрос, удалённая пара IP/порт, Context ID, правила прокси и выбор клиента относительно неизвестных источников.

Что именно одобрил IESG

Объявление датировано 24 августа, 17:58 UTC. Редакция 16, подготовленная рабочей группой MASQUE, одобрена для статуса Proposed Standard.

RFC 9298 задаёт обычный CONNECT-UDP с одним фиксированным хостом и портом на запрос. Для клиент-серверного UDP, включая HTTP/3, этого достаточно. WebRTC использует ICE и может проверять несколько кандидатов. Несколько обычных HTTP-запросов не обязаны обрабатываться одним экземпляром прокси и выходить с одного публичного адреса; необходимая для ICE стабильность теряется.

Новое расширение удерживает сокет в одном запросе, а удалённую сторону указывает в каждом datagram или в зарегистрированном соответствии. Взаимодействие Quiche и quic-go доказывает реализуемость. Оно не доказывает массовое включение в браузерах, производственную нагрузку, общую политику безопасности или соответствие всех стеков.

28 августа Datatracker всё ещё показывал Active Internet-Draft со статусом IESG RFC Ed Queue. Действия IANA продолжались при положительных экспертных проверках; RFC Editor ожидал проверки ссылок и оформления. Одобрение состоялось, но номер RFC и развёртывание — последующие факты.

Поддержка подтверждается в обе стороны

Клиент отправляет Connect-UDP-Bind: ?1. Поддерживающий прокси возвращает то же истинное логическое значение. Конечная сторона включает механизм лишь после того, как и отправила, и получила его. Значение другого типа считается отсутствующим полем.

Успешного статуса HTTP недостаточно, чтобы предположить поддержку. Прокси также не вправе молча превратить запрос с фиксированным назначением в многопользовательский сокет.

Запрос может содержать допустимые хост и порт, сохраняя их как запасное фиксированное назначение. Для режима только с привязкой обе целевые переменные устанавливаются в *. Звёздочка лишь в одной переменной означает ошибку запроса. Этот выбор входит в аудит: от него зависит, имеет ли Context ID 0 прежнее фиксированное значение.

Публичный адрес — запись о выделенном ресурсе

Приняв запрос, прокси выбирает как минимум один публичный IP и свободный UDP-порт, привязывает их к запросу и сообщает через Proxy-Public-Address. Если пара одна, она должна сохраняться до закрытия туннеля. Для нескольких пар рекомендуется стабильность в каждой семье адресов. Изменение позднее нельзя сообщить тем же заголовком ответа.

ICE получает полезный кандидат. Но идентичность отправителя не возникает. Нужный партнёр и неизвестный сканер способны достичь одного сокета.

Телеметрия должна различать утверждения. «Публичный адрес выделен» подтверждает ресурс. «Пакет получен» подтверждает достижимость. Ни одно событие не доказывает регистрацию пары, разрешение политики, пересылку, доставку клиенту или принятие приложением.

Context ID превращает пару в явное состояние

Клиенты выделяют чётные идентификаторы, прокси — нечётные. Ноль запрещён в режиме без фиксированного назначения. Он сохраняет смысл RFC 9298 лишь при настоящей запасной цели.

Жизненный цикл задают три Capsule. COMPRESSION_ASSIGN (0x11) предлагает смысл ID. COMPRESSION_ACK (0x12) подтверждает, что получатель сохранил соответствие. COMPRESSION_CLOSE (0x13) отклоняет его или закрывает.

Версия IP 0 создаёт несжатый контекст: каждый datagram несёт адрес и порт. От клиента к прокси это назначение, обратно — источник принятого пакета. Версия 4 или 6 создаёт сжатый контекст: пара регистрируется один раз, затем её обозначает ID.

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

Для меньшей задержки разрешена отправка до ACK, но данные могут потеряться, если ASSIGN ещё не дошёл или отклонён. Раннее использование ID — риск отправителя, не подтверждение согласия получателя.

Клиент закрывает путь неизвестным

Только клиент может запросить несжатый контекст, и открытым может быть лишь один. Его область широка: каждый datagram способен назвать ранее неизвестную пару источника.

Клиент может не открывать его или закрыть позднее. Тогда прокси фактически фильтрует неизвестных отправителей. Уже созданные сжатые соответствия продолжают работать, но прокси не может открыть новые после закрытия широкого контекста: иначе он обошёл бы отзыв клиента.

Публичный порт остаётся, а полномочие сужается. Выделение, известная пара и неизвестный источник — три разных состояния.

Политика назначения движется вместе с назначением

В фиксированном CONNECT-UDP цель проверяется при создании туннеля. Здесь она находится внутри данных или регистрации, значит, проверка должна выполняться там же.

Прокси проверяет IP и порт каждого несжатого datagram. Для сжатого режима он проверяет пару в COMPRESSION_ASSIGN и отказывает запрещённым назначениям. Локальные правила могут защищать loopback, link-local, частные и административные сети или отдельные службы.

Черновик не определяет всю политику оператора. Он фиксирует минимальную точку применения, чтобы изменяемая цель не стала обходом контроля.

Полезно сравнение с TURN. Выделение relay-адреса, permissions партнёров и channel bindings — отдельные состояния. Протоколы различаются, но общий вывод тот же: получение адреса ретранслятора не даёт неограниченного доступа ко всем сторонам.

Ресурсный предел — часть безопасности

Каждый открытый Context ID занимает память. ACK и CLOSE, задержанные управлением потоком или перегрузкой, занимают буфер. Поэтому число открытых ID и ожидающих ответов должно быть ограничено. При исчерпании второго предела прокси обязан прервать поток запроса.

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

Меняется и эффективный MTU. Несжатая форма каждый раз добавляет адрес и порт, сжатая — нет. Переход способен нарушить DPLPMTUD, поэтому сжатие лучше запросить рано. Размеры, потери и успех пути всё равно должны подтвердить результат.

Один IP скрывает много субъектов

RFC 6269 объясняет проблемы общего IP: грубая атрибуция, перенос репутации и чрезмерные блокировки. За одним адресом прокси могут находиться многие порты, туннели, клиенты, контексты и удалённые пары.

Расследованию нужны публичный порт, туннель, аутентифицированный клиент, состояние Context ID, удалённая пара, решение политики и итог пересылки. Отброшенный на границе скан не должен превращаться в отчёте в трафик пользователя.

Доказательство для одного datagram

Надёжная цепочка связывает:

  1. аутентифицированный запрос и туннель;
  2. двустороннее согласование привязки;
  3. запасное назначение или режим только привязки;
  4. публичную пару и срок её жизни;
  5. сторону выделения и уникальный Context ID;
  6. ASSIGN, ACK и CLOSE;
  7. сжатую или несжатую семантику;
  8. точную удалённую пару источника или назначения;
  9. версию политики и решение;
  10. бюджеты контекстов и ответов;
  11. принятие, отбрасывание или ожидание;
  12. отправку или приём на сокете;
  13. доставку клиенту и результат ICE или приложения.

Корректное соответствие ещё может закончиться потерей или неудачной проверкой ICE. Протокольное состояние разрешает обработку; наблюдаемое исполнение доказывает рабочий путь. В этом и состоит Running-Code Primacy: документ задаёт минимальные общие правила, а оператор подтверждает локальный результат.

Источники