Кратко

  • draft-liu-sidrops-rpki-rtr-over-quic-04 называет «0-RTT» преимуществом восстановления, но нормативно требует от клиента, сервера и TLS отключать или отклонять Early Data.
  • Параллельные QUIC-потоки уменьшают транспортную блокировку, однако полноту RPKI-кэша подтверждают Protocol Version, Session ID, Serial Number, известный набор потоков и последний ожидаемый End of Data.

Редакция 04 опубликована 7 сентября 2026 года. Это индивидуальный Internet-Draft с намерением Standards Track, а не принятый SIDROPS документ, консенсус IETF или RFC. В Datatracker нет RFC stream, ответственного AD и telechat. Рабочая группа ведёт 8210bis для базового протокола; его статус нельзя переносить на отдельное QUIC-отображение.

Введение строит аргумент на скорости. QUIC объединяет TLS 1.3 с несколькими независимыми streams. Клиент, ранее работавший с сервером, якобы может положить RTR request в первый пакет и получить «0-RTT» recovery, почти сразу возобновив синхронизацию RPKI verification database.

Section 3.1 задаёт противоположное требование. RTRoQUIC MUST NOT использовать Early Data. Клиент MUST NOT предлагать early_data, сервер MUST отклонять его, а TLS 1.3 stack MUST отключать 0-RTT. Противоречие присутствует в версиях 03 и 04.

Session resumption не равна 0-RTT. RFC 9001 разрешает возобновление при отключённом 0-RTT. Оно может сократить handshake, но не обязательно позволяет application data до его завершения. 0-RTT — именно ранняя отправка на основе сохранённых параметров. Введение обещает эту функцию, а правило запрещает.

Причина — replay и иные свойства forward secrecy. Проект не хочет принимать риск для данных, влияющих на BGP. Это может быть разумным выбором. Но запрещённую функцию нельзя включать в расчёт времени восстановления. Измерять надо разрешённый путь.

Вторая граница появляется при нескольких streams. В простом mapping все RTR PDU идут по одному bidirectional stream. Параллельный режим выделяет Control Channel для Serial Notify, Serial Query, Reset Query, Cache Reset и Error Report. Data Channels несут Cache Response, payload и End of Data.

Payload делится на IPv4 Prefix, IPv6 Prefix, Router Key и ASPA. Потеря в одном QUIC-stream не тормозит остальные. Но завершение трёх каналов не означает завершение четвёртого и всей версии.

Revision 04 требует Cache Response и End of Data на каждом Data Channel. Первый Cache Response считается действительным, последний End of Data — завершающим. Значит, ожидаемый набор streams входит в состояние транзакции. Без списка получатель не знает, какой конец последний.

QUIC сохраняет порядок внутри stream, не общий порядок всей connection. Commit по первому End of Data создаёт риск частичного snapshot. Ожидание последнего требует общей семантики создания, привязки к query, reset, close, error и числа каналов.

8210bis объясняет значение завершения. Serial Number представляет логическую версию одного cache. Session ID именует пространство последовательности. Protocol Version дополняет идентичность. Cache не должен передавать новые данные до завершения собственной validation. После End of Data router может считать текущие данные этого cache полными и принять новый serial.

Параллелизм не должен размывать атомарность. Корректный Router Key PDU не доказывает получение ASPA и prefix withdrawals той же версии. TLS аутентифицирует peer по локальной политике, а не целостность snapshot.

Числа имеют локальную область. Serial Number нельзя сравнивать между caches или versions; reset может его изменить. Базовый проект предупреждает, что ошибочный reuse Session ID оставит router out of sync, если последующий delta не противоречит старому состоянию. Шифрование QUIC не исправит неверный epoch.

Несколько preferred caches создают ещё один слой. VRP начинает действовать, когда его подал первый предпочтительный cache, и остаётся до withdrawal последним. Завершение одной сессии не означает завершение общей RPKI-картины. Нужны отдельные ledger для каждого cache и для результата объединения.

Ниже по цепочке сохраняются самостоятельные решения: PDU receipt, local install, BGP reevaluation, best path, RIB, FIB и packet outcome. Быстрый защищённый transport не получает власть над ними.

Проект включает fallback: при блокировке UDP router должен попробовать RTR по TCP. Мониторинг обязан разделять QUIC failure, начало TCP, authentication, первый Cache Response, последний End of Data, commit и BGP reevaluation. Зелёный индикатор connection скрывает устаревший serial.

Running-Code Primacy требует воспроизводимого опыта. Две независимые реализации выбирают одну RTR version, аутентифицируют нужные endpoints, отвергают 0-RTT, знают одинаковый stream set, переживают потерю в одном канале и фиксируют одну version по настоящему последнему End of Data. Схема с четырьмя стрелками не заменяет опыт.

Минимальная спецификация может оставить оператору число streams, certificate policy, cache preference и fallback. Но transaction receipt должен общим образом связать version, cache, Session ID, Serial Number, query, stream set и completion.

Руководство должно утверждать не бренд QUIC, а измеренное ускорение разрешённого протокола, атомарный commit, проверенный TCP fallback, разнообразие caches, rollback и доказательство до результата routing.

Источники