Кратко
- RFC 9674 требует, чтобы Snapshot, Delta и цели HTTP-редиректов сохраняли scheme, host и port Update Notification File.
- Доступность и совпавший hash не дают другому origin полномочия; same-origin, в свою очередь, не доказывает валидность RPKI-объектов и состояние router.
- Нужна цепочка отдельных квитанций: referral, origin policy, RRDP state/hash, object validation, validated payload, cache-router session, local policy и observed route.
Вчера RP успешно синхронизировался и cache выдал новый serial. Ночью распределение файлов перевели на другой host, а router сохранил прежнюю сессию с cache. Утренний отчёт всё ещё называл систему «RPKI current», хотя теперь в нём смешивались три разных времени и два разных полномочия.
Первый вопрос задаёт RFC 9674: имело ли RRDP-уведомление право направить клиент к новому origin? Если нет, сеанс должен быть отвергнут, даже когда файл скачался. Но положительный ответ ещё ничего не говорит о свежести cache и данных у router.
Origin привязан к уведомлению, а не к бренду
RFC 8182 начинает цепочку с rpkiNotify в SIA resource certificate. URI ведёт к Update Notification File с session_id, serial, Snapshot и возможными Delta. Hash связывает ссылку с извлечённым файлом.
В исходной спецификации не было прямого запрета cross-origin URI и правил для redirect на другой principal. RFC 9674 добавляет их. Server обязан держать ссылки и redirects в origin уведомления. Relying Party обязан сравнивать, отклонять файл или сеанс и должен журналировать обнаружение.
RFC 6454 определяет origin через scheme, host и port. Организация, контракт CDN, материнский домен и визуальная метка «тот же repository» не входят в tuple. http отличается от https; другой host остаётся другим; новый port тоже меняет boundary.
Эта механичность предотвращает незаметное расширение authority. Иначе клиенту пришлось бы знать договоры и внутреннюю топологию каждого оператора, которых в protocol record нет.
Последний 200 скрывает решающий переход
RFC 9110 описывает redirect как дальнейшее действие к другой URI. Если мониторинг хранит лишь конечный статус, он теряет путь, на котором RFC 9674 принимает решение.
Нужно сохранять SIA URI, нормализованный origin, все ссылки notification, каждый HTTP status и Location, а также решение до следующего запроса. Совпавший hash отвечает только за bytes. Он не разрешает чужому principal обслуживать запрос и не устраняет нагрузку, которую один repository способен перенести на другой.
Same-origin тоже не гарантирует правильный content. Допустимый server может вернуть malformed XML, несовместимую session, неправильный serial или hash mismatch. Полномочие и целостность — разные поверхности.
RRDP-проверки следуют после boundary
RFC 8182 требует well-formed notification и schema, связывает session_id с location, проверяет непрерывность Delta и значения serial. Snapshot и Delta должны совпасть с заявленными hashes и состоянием session.
Rejected Delta может привести к Snapshot. Rejected Snapshot означает, что RRDP использовать нельзя. Альтернативный access method из SIA открывает новый путь получения, но не делает предыдущий сеанс допустимым.
Дальше начинается собственно RPKI validation. RFC 6480 разделяет resource PKI, signed objects и distributed repository. RFC 6487 задаёт certificate/CRL profile и path validation. RFC 9286 проверяет manifest number, time и список filename/hash.
Поэтому Snapshot из верного origin с правильным transport hash может содержать object, который не проходит certificate, CRL или manifest rules. Authorized retrieval не превращается в valid authorization.
Cache и router живут в разных сеансах
RFC 7115 называет validated cache набором объектов, фактически проверенных RP. RFC 8210 определяет отдельный cache-router protocol с version, session и serial. RFC 6811 даёт origin validation state, который лишь поступает в local policy.
Значит, вчерашний origin pass не подтверждает сегодняшнюю router session. Даже новый validated payload не доказывает, что router принял его, применил политику и выбрал ожидаемый маршрут. Квитанция должна называть subject, build/session/serial и время.
Cross-origin detection также не является атрибуцией атаки. Он подтверждает нарушение правила URI. Same-origin pass не является аттестацией честности repository, свежести данных или forwarding result.
Историческое наблюдение не продлевается автоматически
RFC 9674 сообщает, что в изученных архивах с октября 2021 по октябрь 2024 не наблюдал cross-origin ссылок в notification, а в другой части 2024 года нашёл один server с same-origin redirect. Это аргумент deployability в указанной выборке и времени.
Это не текущий глобальный census. Срок годности есть и у исследования, и у внутреннего теста, и у cache-router serial. Удаление времени превращает запись в более сильное утверждение, чем позволяла evidence.
Минимальная исходная спецификация оставляет общий инвариант узким: одно уведомление не делегирует за пределы origin. Слои реальности разделяют организацию, URI, bytes, validated object, router state и route. Приоритет работающего кода требует доказать фактическое исполнение на RP, cache и router.
RFC 9674 хорошо отвечает, откуда RRDP не должен брать данные. Именно поэтому ему нельзя приписывать ответ на вопрос, какую route сеть использует сейчас.
Источники
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров

