Кратко

  • Разные текущие serial могут означать обычную разницу времени опроса. Разные хеши для одного ранее наблюдавшегося serial в той же сессии означают, что две стороны получили несовместимые версии одного исторического перехода.
  • Relying party сохраняет пересекающиеся пары serial–hash, предупреждает о мутации и переходит на последний snapshot. После этого отдельно проверяются manifests, сертификаты, CRL и подписанные объекты; решение по маршрутам принимает локальная политика.

Рассмотрим два сайта одной сети. Валидатор на востоке опросил репозиторий раньше и обработал delta 1774 с хешем A. Валидатор на западе пришёл позже и увидел уведомление, где той же сессии и тому же serial соответствует хеш B. Позднее оба интерфейса показывают текущий serial 1775. Простая проверка состояния считает узлы синхронными.

Это модель, а не сообщение о реальном инциденте. Она отделяет две причины различия. Если западный узел просто получил 1775 позже, он догоняет законную последовательность. Если байты шага 1774 изменились под прежним именем, догонять уже нечего: единой последовательности нет.

RFC 9697 вводит проверку памяти. Клиент хранит пары serial и hash из предыдущего успешно обработанного notification. При следующем опросе он сравнивает серийные номера, присутствующие в обеих версиях. Изменение хеша вызывает предупреждение и переход на самый свежий snapshot.

Слабая согласованность не разрешает менять прошлое

RFC 6811 прямо учитывает, что глобальное представление RPKI слабо согласовано: relying parties получают данные и обновляют локальные наборы в разное время. Поэтому два честных наблюдателя могут временно видеть разные Validated Payloads.

Такая разница описывается положением на временной оси. У наблюдателей разные последние шаги, но каждый шаг имеет одно содержание. После доставки пропущенных изменений они способны воспроизвести одинаковое состояние.

Мутация RRDP нарушает другое свойство — тождество шага. Один исторический адрес начинает означать два набора байтов. Доставка всех файлов не гарантирует сходимости, потому что кэш, CDN edge или валидатор может сохранить любую из версий.

По RFC 8182 notification указывает session_id, текущий serial, snapshot и удерживаемую последовательность delta. Продолжение допустимо при совпадении сессии, наличии непрерывной цепочки и соответствии каждого файла объявленному хешу. Иначе клиент использует snapshot.

Сам UUID сессии не является глобальной идентичностью репозитория. Его нужно связывать с местом notification: другой сервер способен повторить тот же UUID. Место задаёт область, сессия — цикл инициализации, serial — порядок, hash — конкретные байты.

Неизменность превращает кэширование в доказуемую оптимизацию

RRDP рассчитан на распространение snapshots и delta через HTTP и CDN. Это эффективно, если опубликованные URL и содержимое не меняются. Один объект можно хранить близко к множеству валидаторов, а получатель проверяет его по хешу.

При замене delta старый edge может продолжать отдавать первоначальные байты, новый — заменённые. Оба ответа могут пройти локальную проверку против notification своей эпохи. Ошибка проявится лишь у клиента, который помнит прежнюю связь serial с hash.

RFC 9697 требует не бесконечного архива, а ограниченного перекрытия двух уведомлений. Небольшой журнал превращает обещание сервера в проверяемое условие. Его ценность именно в независимости от репутации оператора репозитория или CDN.

Сигнал должен содержать URL notification, origin, session, serial, старый и новый hash, время получения и затронутый репозиторий. Общий статус «RRDP error» не показывает, был ли это сетевой сбой, пропуск delta, новая легитимная сессия или переписывание истории.

Snapshot устанавливает новую базу, но не новую истину

После обнаружения противоречия клиент не выбирает понравившуюся delta. Он загружает полный snapshot для текущего состояния и проверяет его hash, формат, session и serial. Если snapshot отвергнут, штатный путь восстановления RRDP не дал пригодной базы.

Полная загрузка дороже инкрементов. Одновременный reset большого числа валидаторов способен увеличить нагрузку на origin, CDN и сами процессы. Неограниченные повторы превращают защитную реакцию в усилитель отказа. Нужны backoff, jitter, ограничения параллелизма и поэтапное выполнение.

Перед заменой локального состояния сохраняются обе notification, пересекающиеся хеши, HTTP-ответы, redirects, отметки времени и причины отклонения. Без них восстановление может вернуть сервис, но уничтожить возможность установить, ошибся ли publisher, CDN, клиент или вмешался внешний участник.

RFC 9674 требует, чтобы URI snapshot и delta и перенаправления сохраняли тот же origin — схему, хост и порт — что notification. Это ограничивает способность одного репозитория направить нагрузку на чужой сервер. Но same-origin не делает RPKI-объект действительным.

Транспорт, публикация и криптографическая проверка не взаимозаменяемы

RFC 6480 описывает распределённую инфраструктуру и репозитории, которые делают публичные материалы доступными. Репозиторий обеспечивает доступность, а не создаёт полномочие объекта фактом хранения.

На стороне записи RFC 8181 задаёт протокол publish, replace и withdraw между CA и publication service. Сообщения аутентифицируются бизнес-PKI. Успешный ответ доказывает выполнение разрешённой операции публикации, но не будущую приемлемость объекта для relying party.

RFC 6481 описывает структуру publication points и необходимость избегать промежуточных состояний, где manifest и набор файлов расходятся. RRDP не исправляет плохо собранное состояние, а лишь доставляет его.

RFC 6488 требует проверять CMS, EE-сертификат, тип содержимого, digest и подпись, а также правила конкретного продукта. Подпись защищает от несанкционированного изменения, но сама не доказывает свежесть и полноту.

RFC 9286 определяет manifest — подписанный список файлов publication point с их хешами. Если перечисленный файл недоступен, нельзя молча считать случайно полученное подмножество полным. RFC 9981 обновляет обработку manifest number и replay, включая определённые случаи сброса.

Manifest number не равен RRDP serial. У RPKI-to-Router есть своя cache session и serial для передачи payloads. Эти числа относятся к разным автоматам и не складываются в единую «версию RPKI».

RFC 8897 сводит требования к relying parties. Получение и проверка могут выполняться разными компонентами, но оператору нужна связная трасса от скачанных байтов через manifest, сертификат и CRL к принятому payload.

Маршрут остаётся решением сети

После повторной проверки набор соответствий prefix–origin может измениться. RFC 6811 требует переоценить затронутые маршруты и предоставляет состояние в распоряжение routing policy. Сеть сама решает, отклонять ли Invalid, снижать предпочтение, маркировать или применять исключение.

RPKI Origin Validation не проверяет весь AS_PATH и не подтверждает фактический forwarding. Поэтому само обнаружение изменённого RRDP hash разрешает сброс истории синхронизации, но не немедленное удаление маршрута.

Доказательство продолжается через diff payloads, завершение RPKI-to-Router, выбранную ветвь политики, Loc-RIB, FIB и внешние пробы пакетов. Зелёный валидатор — промежуточный факт, а не итог работы сети.

Источники