Кратко

  • ASPA — подписанный объект RPKI, в котором клиентская AS разрешает набор AS-провайдеров. Это утверждение об отношениях для алгоритма, а не подпись каждого перехода.
  • Проверка возвращает Valid, Invalid или Unknown по доступным объектам и контексту распространения. Она не заменяет проверку происхождения маршрута, реальную идентичность или локальную политику.
  • Надёжный журнал разделяет валидность объекта, полноту набора, время кэша, роль сессии, результат, действие и неопределённость.

Слово «Valid» звучит как полный вывод. В ASPA оно означает лишь, что наблюдаемый путь согласуется с теми разрешениями клиент–провайдер, которые алгоритм способен оценить в нужном направлении. Это полезно, но не является подписанной историей каждого звена.

Текущий профиль ASPA всё ещё имеет статус Internet-Draft. Он определяет подписанный объект RPKI, где владелец номера клиентской AS перечисляет разрешённых провайдеров. Профиль ожидает полный список в одном объекте на клиента. Relying Party проверяет объект до использования данных.

Объект отвечает на узкий вопрос: разрешил ли клиент этого провайдера в опубликованных данных? Префикса маршрута в ASPA нет. ROA и Route Origin Validation решают задачу происхождения, поэтому эти механизмы дополняют друг друга.

Подпись не удостоверяет реальную организацию. RFC 9255 подчёркивает, что RPKI подтверждает полномочие на ресурс, а не личность. Валидный объект не доказывает действующий договор, правильность записи или текущий обмен трафиком.

Полнота — следующая граница. Проект проверки ожидает регистрации всех провайдеров и значимых непрозрачных route server. Пропуск законного провайдера может дать Invalid для настоящего пути по мере роста покрытия. Криптография может быть верна, а поддерживаемая декларация — неполна.

Алгоритм различает Provider+, Not Provider+ и No Attestation, а для пути — Valid, Invalid и Unknown. Unknown не является слабым Invalid: имеющихся свидетельств недостаточно. Valid, в свою очередь, не доказывает авторизацию происхождения маршрута, подпись каждой AS или соблюдение всех правил экспорта.

ASPA и BGPsec имеют разную семантику. ASPA сопоставляет путь с отдельно опубликованными разрешениями и не подписывает его переход за переходом. Важен и порядок. RFC 9774 фиксирует устаревший статус AS_SET и AS_CONFED_SET, потому что неупорядоченное множество не сохраняет направление клиент–провайдер.

BGP Roles из RFC 9234 дают контекст сессии для предотвращения утечек, но согласованная capability не является универсальным коммерческим реестром. Получающий оператор сам решает, как результат влияет на выбор, доступность и исключения.

Аудируемый журнал разделяет шесть слоёв: проверенный объект; свидетельство полноты инвентаря; наблюдение кэша и время; упорядоченный путь и роль; результат с причиной; локальное действие, владелец и срок. Провайдер, добавленный в пятницу, объект субботы и обновлённый в воскресенье кэш — разные состояния.

Проекты могут измениться до публикации RFC, и здесь не утверждается реальный инцидент. Устойчивый принцип — считать ASPA ограниченным разрешением провайдеров и хранить валидность, полноту и применение как отдельные свидетельства.

Источники