Кратко

  • ASPA позволяет проверить форму AS_PATH по подписанным спискам провайдеров, но не подписывает каждую передачу UPDATE и не исключает все манипуляции со стороны уже авторизованного провайдера.
  • Редакция 28 рекомендует одинаковую предпочтительность Unknown и Valid, исключение Invalid из выбора с сохранением в Adj-RIB-In; состояние проверки не доказывает Loc-RIB, FIB или доставку трафика.

Авторизация не делает контрагента безошибочным

Клиент действительно мог авторизовать провайдера. Объект действительно мог пройти всю проверку RPKI. Пара клиент → провайдер тогда получает Provider+. Но из этого не следует, что провайдер не менял путь, не ошибся в экспортной политике и не отправил трафик иначе.

Раздел безопасности редакции 28 прямо оставляет границу: провайдер способен подделать origin или сегмент пути клиента так, что ASPA не всегда обнаружит атаку. Алгоритм также не замечает добавление или удаление повторных ASN. Его цель — проверка структуры отношений, а не полная подпись истории объявления.

Проект опубликован 24 августа 2026 года и истекает 25 февраля 2027 года. Datatracker показывает активный документ SIDROPS со статусом WG Consensus: Waiting for Write-Up; в IESG — I-D Exists. Это не RFC и не доказательство внедрения.

Что находится внутри ASPA

Владелец идентификатора клиентского AS подписывает полный список провайдеров, включая непрозрачный route server, если тот добавляет свой ASN в AS_PATH. Цепочка сертификатов подтверждает полномочие над ресурсом и целостность объекта.

Она не публикует договор, не фиксирует живую BGP-сессию и не показывает, через какую связь прошёл UPDATE. Рекомендуется один объект. При нескольких действительных ASPA используется объединение списков — полезно при переходе, но более permissive до удаления старых записей.

Ошибочно лишний провайдер ослабляет обнаружение. Отсутствующий настоящий провайдер может дать ложный Invalid. Поэтому «valid object» и «актуальный набор» — разные контрольные точки.

Три результата вместо бинарной печати

authorized(x, y) возвращает Provider+, когда y есть в наборе клиента x; Not Provider+, когда действительный набор есть, но y отсутствует; No Attestation, когда пригодный объект не получен.

Пропуск доказательства не равен отрицательному утверждению. После восстановления четырёхоктетного AS_PATH и сжатия соседних повторов алгоритм рассчитывает минимальные и максимальные длины восходящей и нисходящей рамп.

Если максимум не покрывает путь, состояние Invalid. Если максимум допускает путь, но отсутствие объектов останавливает минимум, — Unknown. Если минимум достаточен, — Valid. Результат привязан к снимку объектов и локально выбранному направлению.

Локальная роль меняет вопрос

Маршруты от Customer или Peer проверяются upstream-алгоритмом; от Provider — downstream. BGP Roles из RFC 9234 помогают сверить роль в OPEN, но всё равно остаются конфигурацией конкретной сессии.

Complex-отношения могут потребовать отдельных сессий или выбора по префиксу. Если это невозможно, проект разрешает downstream-процедуру для снижения ложных Invalid. Такая уступка сохраняет связность и одновременно расширяет множество допустимых форм.

AS_SET и несоответствие последнего ASN соседу обрабатываются раньше. Без кода причины один Invalid скрывает разные механизмы.

Unknown не получает происхождение Valid

Рекомендовано давать Unknown тот же уровень предпочтения, что Valid. Это политика доступности при неполном покрытии. Она не доказывает, что все отношения в Unknown-пути авторизованы.

Invalid становится непригодным для выбора, но остаётся в Adj-RIB-In. Изменение ASPA может прийти через репозиторий и валидатор без нового BGP UPDATE; сохранённый путь нужен для переоценки.

Затем BGP сравнивает атрибуты, выбирает маршрут, обновляет Loc-RIB, а оборудование программирует FIB. Даже после этого нужны пакеты и измерение сервиса. ASPA не выдаёт квитанцию ни за один из этих этапов.

Место противоречия не равно месту вины

Роутер должен записать пары Not Provider+, но проект предупреждает: он не всегда определит AS, вызвавшую утечку. Устаревший объект, миграция ASN или более раннее изменение пути могут сместить видимую границу.

Общий U-SPAS используется для IPv4 и IPv6. Отношение только в одной семье делает вторую проверку столь же permissive. Это сознательный обмен тонкости на простоту и меньше ложных Invalid, а не доказательство одинаковых контрактов.

ROA подтверждает разрешение на origin, BGPsec — подписанный путь распространения, OTC — ограничение экспорта. ASPA проверяет другую часть. Зелёный результат одной технологии не включает автоматически остальные.

От объекта к работающей сети

Надёжная запись содержит точную редакцию, payload и хэш ASPA, цепочку и состояние репозитория, версию relying party, время импорта, локальную роль, исходный и реконструированный AS_PATH, каждую пару, границы рамп, итог и действие policy. Далее отдельно фиксируются Loc-RIB, FIB и наблюдение трафика.

Доктрина Lu Heng требует локальной проверяемости и первичности работающего кода. Подписанная координационная запись авторитетна только для собственного утверждения. Она не получает власть над политикой маршрутизатора или фактом доставки.

Чего источники не доказывают

Замороженный набор подтверждает предложенные правила и заявленные ограничения. Он не доказывает соответствие конкретной реализации, злой умысел провайдера, предотвращённую утечку или измеримый эффект. Начальный сценарий показывает границу модели, не обвиняя сеть.

Источники