Кратко

  • Реализация PCEPS с несколькими версиями TLS обязана предпочесть новейшую; при поддержке TLS 1.3 или выше она не должна использовать early data.
  • Проверяемая цепочка включает доступные версии, результат переговоров, отсутствие 0-RTT, завершённое рукопожатие, проверенного узла, принятое сообщение PCEP, разрешённый переход и наблюдаемый эффект.

Оптимизация выглядела почти незаметной: поместить первое сообщение PCEP в начальный полёт возобновляемой TLS-сессии. Шифрование уже есть, версия современная, задержка меньше. Но в этот момент новая сессия ещё не закончила обычное рукопожатие, а ранние байты могут появиться повторно в другом соединении. RFC 9916 запрещает превращать скорость в доказательство полномочий.

RFC 9916 опубликован в июле 2026 года в Standards Track IETF и обновляет спецификацию PCEPS RFC 8253. Он требует предпочитать новейшую версию TLS и запрещает early data при поддержке TLS 1.3 или новее. Инициация, кадрирование, закрытие, сертификаты, идентификация узла и обработка отказов остаются прежними.

TLS 1.3 не означает обязательный 0-RTT. Он нормально работает без ранних данных. Такая передача возможна только при общей допустимой PSK, полученной извне или из предыдущего рукопожатия. Тогда клиент отправляет прикладные данные в первом полёте, не дожидаясь завершения новой сессии.

Текущая спецификация TLS 1.3 RFC 9846 фиксирует ослабление свойств: early data не обладает прямой секретностью и не защищена от повтора между соединениями. Для использования нужен профиль прикладного протокола с перечнем безопасных взаимодействий и правилами отказа. RFC 9325 рекомендует избегать 0-RTT без такого явного документа.

HTTP выбрал иной профиль. RFC 8470 определяет Early-Data и ответ 425 Too Early, позволяя серверу отклонить рискованный запрос и добиться повторения после рукопожатия. В PCEPS такого ответа нет. RFC 9916 не ищет безопасное подмножество команд, а полностью исключает early data.

Исходный порядок PCEPS уже устанавливает границу: TCP, взаимный StartTLS, переговоры и установление TLS, затем PCEP. Даже Open идёт после защищённого транспорта. Базовый RFC 5440 описывает запросы и ответы расчёта пути между PCC и PCE либо двумя PCE.

В stateful-модели последствия шире. RFC 8231 добавляет синхронизацию состояния LSP, делегирование управления и управление последовательностью расчётов. RFC 8281 разрешает PCE инициировать создание, поддержку и удаление LSP. RFC 8283 помещает PCEP в централизованные сети, где программное обеспечение управляет устройствами пересылки.

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

Request-ID, SRP, LSP-ID и символическое имя пути помогают связать операции. Они не создают идемпотентность автоматически. Получатель должен знать прошлое состояние, ожидаемую последовательность, область делегирования, правила повторения и уже применённый результат. Это задача PCEP, а не транспортного шифрования.

Поэтому в журнале нужны отдельные ступени: версии на обоих узлах, выбранная версия, предложение и приём early data, завершение рукопожатия, сертификат и имя узла, первое принятое PCEP-сообщение, его идентификаторы, делегирование, переход, ответ и фактическое состояние сети. Поле «защищено» не отвечает на эти вопросы.

Та же модель локализует сбои. Понижение версии — политика переговоров. Прикладные байты до handshake — нарушение RFC 9916. Ошибка имени после шифрования — отказ идентификации. Двойное применение — состояние PCEP. Подтверждение без изменения forwarding требует проверки PCC и устройства.

Принцип Heng Lu Minimum Initial Specification оставляет в общем слое только детерминированные, локально проверяемые правила. Running-Code Primacy ставит исполненную сессию и состояние выше названия версии. Reality Layers не даёт символу «TLS 1.3» присвоить ещё не наблюдавшееся сетевое действие. Это раскрытые редакционные принципы, а не новые требования IETF.

Короткое правило RFC 9916 сохраняет длинную ответственность: выбрать новый TLS, отключить 0-RTT, завершить рукопожатие, проверить узел, принять PCEP и увидеть результат. Один пропущенный round trip не стоит неопределённости о том, кто и сколько раз изменил сеть.

Источники