Summary

  • RPKI relying party создаёт локальное состояние с временными границами из распределённых репозиториев, настроенных trust anchors, результатов синхронизации, правил проверки и возможных локальных преобразований.
  • draft-su-sidrops-rpki-rp-requirements-00 предлагает стабильный экспорт проверенного кэша, диагностику причин отказа и хранение исторических состояний для сравнения, replay и последующего анализа.
  • Daniel Kade предлагает квитанцию состояния проверки, связывающую исполнение, входы и пробелы, digest кэша, локальную политику, доставку маршрутизаторам и хранение. Это редакционная рекомендация, а не требование IETF.

Между публикацией и маршрутом находится локальная машина решений

Подписанный объект RPKI имеет определённого издателя, но маршрутизатор не получает глобальный репозиторий напрямую. RP выбирает trust anchors, обнаруживает точки публикации, загружает данные, проверяет сертификаты, CRL, манифесты и типы объектов, а затем строит локальный валидированный кэш. Оператор может применить фильтры или assertions SLURM. Отдельный RPKI-to-Router protocol доставляет производный набор маршрутизатору, где действует собственная BGP policy.

Каждый этап ограничивает смысл доказательства. Верная подпись не подтверждает доступность всех репозиториев. Текущий манифест описывает инвентарь одной точки публикации, а не полноту всего наблюдения. Получение payload не доказывает установку или выбор маршрута.

RFC 8210 подчёркивает локальность serial. Номер задаёт логическую версию внутри cache session, не сопоставим между кэшами или версиями протокола и может не сохраняться после reset. Без Protocol Version и Session ID число не идентифицирует состояние для аудита.

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

Проект добавляет требования к операционной памяти

Индивидуальный Internet-Draft от 12 июня 2026 года обновляет идею RFC 8897 как единой карты требований. Он учитывает successor keys для trust anchors, same-origin для RRDP, восстановление после desynchronization, новые правила для манифестов, ROA, ASPA, RSC, TAK, CRL, распространения кэша и локального контроля.

Процедурный статус ограничен. Datatracker не показывает принятия Working Group, RFC stream, ответственного AD или telechat. Заголовок называет Informational лишь предполагаемым статусом и обновляет RFC 8897 только в случае одобрения. Ссылки на активные SIDROPS drafts названы временными. Нельзя утверждать консенсус, реализацию или развёртывание.

Но новая операционная секция важна. RP software должна уметь экспортировать состояние в стабильном машиночитаемом виде, показывать диагностику загрузки, синхронизации, parsing, validation и object rejection, а также хранить прежние результаты или эквивалентный audit trail для сравнения, воспроизведения и анализа.

Экспорт отвечает, что вошло. Диагностика — что не вошло и почему. История — когда изменилась граница. Без любого из трёх зелёный результат не воспроизводим.

У синхронизации есть собственные развилки

RRDP требует same-origin проверок RFC 9674 и, по проекту, должен применять обнаружение и восстановление desynchronization из RFC 9697. Клиент может перейти от delta к snapshot либо сменить механизм. Финальный набор кортежей не раскрывает этот путь.

Манифест создаёт важные отрицательные факты. Он может отсутствовать, быть недействительным или stale; заявленный файл может не загрузиться, не совпасть по hash или находиться не в той точке публикации. Релевантная CRL связана с действующим текущим манифестом. Счётчик принятых объектов не объясняет исключения.

Есть и несколько часов: сроки сертификатов и объектов, время наблюдения репозитория, refresh/retry/expire между кэшем и маршрутизатором, часы самого валидатора. Два корректных исполнения могут временно расходиться. Поздний успех не восстанавливает раннее окно отказа.

Локальное исключение не становится глобальной истиной

RFC 8416 позволяет SLURM локально фильтровать и добавлять данные origin validation. Это может поддержать непрерывность при известной проблеме или ограничить неблагоприятное воздействие. Однако меняется локальный output, а не опубликованный подписанный объект.

Если преобразование скрыто, решение оператора приписывается издателю или владельцу ресурса. Если сохранены policy ID, утверждение, срок и digest, исключение можно проверить, отменить и исправить.

Поэтому два зелёных кэша могут различаться из-за версии, anchors, пути синхронизации, обработки ошибок или SLURM. Даже одинаковый output не обязательно воспроизводим без исходных условий.

Квитанция состояния проверки

Такой квитанции в draft нет. Daniel Kade предлагает компактную связку имеющихся свидетельств, не раскрывающую secrets и не создающую глобальный центр управления.

Идентичность исполнения включает продукт, версию, validation profile, digest конфигурации, активные типы объектов, anchors и состояние часов. Блок получения фиксирует точки публикации, протоколы, последний успех, текущую попытку, fallback и классы ошибок.

Блок validation хранит состояние manifest и CRL, число принятых и отвергнутых объектов по типам, причины, переход anchor, нормативный профиль и canonical cache digest. Локальный блок содержит policy ID, одобрение, период действия и digest преобразования.

Доставка связывает RPKI-to-Router Version, Session ID, serial, время экспорта, набор consumers и пробелы. Хранение указывает предыдущее состояние, срок, ответственный system и correction link.

Private keys, credentials и ненужная topology исключаются. Подробности могут храниться под ограниченным доступом, а digests, времена и классы результатов — использоваться для независимого сравнения. Аудитируемость не требует централизации.

Сила ограниченного утверждения

Квитанция не докажет фактическую правильность каждой публикации, выбор маршрутизатора или человеческую мотивацию локальной политики. Она не превратит draft в стандарт и не вынесет автоматический вердикт спору реализаций.

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

RP — непрерывный компонент управления: синхронизируется, ошибается, восстанавливается, обновляется и меняет настройки. Если его output влияет на routing security, переходы входят в поверхность governance. Зелёный индикатор полезен, но за ним должна стоять экспортируемая, объяснимая и воспроизводимая история.

Sources

  1. Lu Heng — The Policy Mirror
  2. Lu Heng — Minimum Initial Specification
  3. Lu Heng — Why BTW Media Exists
  4. Проект требований RPKI RP, редакция 00
  5. Статус Datatracker
  6. История редакций
  7. Рабочая группа SIDROPS
  8. RFC 8897 — Требования к RPKI relying parties
  9. RFC 6480 — Инфраструктура безопасной маршрутизации
  10. RFC 9286 — Манифесты RPKI
  11. RFC 9674 — Same-Origin Policy для RRDP
  12. RFC 9697 — Desynchronization RRDP
  13. RFC 9691 — RPKI Trust Anchor Keys
  14. RFC 8416 — SLURM
  15. RFC 8210 — RPKI-to-Router Protocol v1
  16. RFC 9582 — Route Origin Authorizations
  17. RFC 9829 — RPKI CRL Number Extensions