Кратко

  • ARIN создаёт отдельный ASPA для каждого Customer ASN и позволяет менять набор его Provider ASes. Даже точечное добавление повторно утверждает весь набор.
  • Документация различает немедленное действие в базе RPKI, появление в публичном репозитории в течение 24 часов, обновление репозитория каждые несколько минут и проверку валидатором. Это разные состояния, а не один момент успеха.
  • Активные Internet-Draft IETF требуют объединить всех провайдеров, включая непрозрачные route server, и отличают No Attestation от Not Provider+. Пропуск важен, но не делает автоматически недействительным любой связанный маршрут.
  • Квитанция должна связать авторизованный набор до изменения, полный набор после него, атомарный результат, выпущенный объект и внешнее наблюдение, не раскрывая контракты и внутреннюю топологию.

Сетевые изменения удобно называть в единственном числе: новый аплинк, старый контракт, резервный канал, route server. Такое название хорошо для календаря работ. Оно плохо описывает запись ASPA. Полагающаяся сторона получает не команду добавить один ASN, а подписанное состояние полного набора провайдеров данного Customer ASN.

Риск возникает, когда пишущих больше одного. Инженер читает {A, B} и готовит {A, B, C}. До отправки автоматизация добавляет непрозрачный route server R и публикует {A, B, R}. Поздняя отправка инженера удаляет R. Оба запроса могут быть корректны, обе транзакции — успешны. Второй автор просто действовал из уже исчезнувшего прошлого.

В описании ARIN множественная природа объекта видна напрямую. Организация с несколькими ASN создаёт уникальный ASPA для каждого Customer ASN. В ARIN Online меняется набор Provider ASes. RPKI REST API описывает aspaDelete и aspaAdd с полями customerAsId и providerAsIds. Операции ASPA и ROA можно объединить в транзакцию, где всё проходит или всё отклоняется.

Атомарность защищает от частичного применения пакета. Она не доказывает, что весь пакет основан на актуальном состоянии. Положительный ответ означает: ARIN принял эти элементы вместе. Он не означает, что автор видел последний набор, объект уже доступен в публичном репозитории или relying party успела его получить.

Интерфейс редактирует строки, подпись выражает состояние

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

Версия 29 Internet-Draft профиля ASPA требует перечислить все Provider ASes, в том числе ASN непрозрачных route server. Если для одного клиента существует несколько действительных ASPA, relying party строит их объединение. При этом проект рекомендует избегать нескольких объектов: разные интервалы действия способны создать гонки. Проект проверки версии 28 также рекомендует один ASPA с полным объединением.

Оба документа остаются Internet-Draft, а не окончательными RFC. Текст ещё может меняться. Но его текущая смысловая единица ясна: полный набор. Пропущенный член — не отсутствие поясняющей заметки, а другое подписанное утверждение.

Безопасная запись должна нести канонический хеш увиденного состояния. Тогда запрос означает: «заменить состояние H полным набором S». Если H больше не соответствует текущему, ARIN возвращает конфликт и новый набор. Реальна ли коммерческая связь с C или R, решает владелец ресурса. Задача ARIN — не дать расхождению скрыться за зелёным ответом.

Compare-and-set добавляет остановку только при настоящем конфликте. Именно тогда остановка дешевле продолжения. После инцидента прежнее состояние придётся собирать из истории браузера, API-логов, старых объектов репозитория и кешей валидаторов, у которых обычно нет общего идентификатора.

Нет утверждения — не то же самое, что нет провайдера в утверждении

Проект проверки различает результаты авторизации. Если пригодной записи ASPA нет, получается No Attestation. Если провайдер входит в пригодный набор, результат — Provider+. Если набор существует, но провайдера в нём нет, — Not Provider+.

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

Но Not Provider+ нельзя сокращать до вывода, будто любой связанный маршрут автоматически недействителен. Полная проверка AS path учитывает направление, сегменты и доступные авторизации. Проект предупреждает: отсутствующий провайдер может позже привести к ложному результату ASPA Invalid. Это механизм риска, а не описание подтверждённого происшествия в ARIN.

Резервные связи делают важным время. Проект рекомендует заранее регистрировать standby и emergency providers. Если авторизация появляется только после начала аварии, время приёма ARIN, публикации и обновления валидаторов входит во время восстановления. Молчащий в обычный день провайдер легче всего исчезает при проверке только активных путей.

Непрозрачный route server создаёт похожую проблему терминов. В коммерческих документах его могут не называть транзитом, однако его ASN должен входить в объединение, описанное профилем. Полный набор с закрытой аннотацией роли помогает не забыть его, не заставляя ARIN выводить отношения из топологии.

За зелёным результатом идут четыре часа

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

Вторые часы — транзакция. ARIN получает, аутентифицирует, проверяет и атомарно принимает либо отвергает пакет. Если ASPA и ROA входят в одну операцию, общий идентификатор доказывает результат «всё или ничего», не раскрывая публике лишние префиксы.

Третьи часы — публикация. ARIN сообщает, что изменение немедленно действует в базе RPKI и появляется в публичном репозитории в течение 24 часов. Та же страница говорит об обновлениях каждые несколько минут. Двадцать четыре часа — внешний предел, а не измерение обычной задержки. Нужны хеш выпущенного объекта, ссылка на repository или manifest и фактическое время первого наблюдения.

Четвёртые часы — потребление. Валидатор загружает материалы, проверяет цепочку и строит пригодный набор провайдеров. Результат принадлежит определённой точке наблюдения, программе, версии и времени. Он доказывает эту точку зрения, а не одновременную сходимость всех relying parties.

Если четыре времени превратить в одно поле «обновлено», расследование потеряет границы. Намерение могло быть неполным, запись — конфликтной, объект — ещё не видимым, валидатор — отставшим. У каждой причины свой владелец и своё исправление.

Из чего состоит квитанция о разнице

Квитанция начинается с Customer ASN и контекста сертификата или выпускающего CA. Затем сохраняет канонически отсортированный прежний набор либо его хеш со ссылкой на восстанавливаемый старый объект. После этого хранит полный отправленный набор. Добавленные, удалённые и сохранившиеся ASN вычисляются из двух состояний.

Сами состояния — первичное доказательство; diff лишь объясняет их. «Добавлен C» не доказывает, что B остался. «Удалён A» не показывает, пуст ли итог или равен {B, C}. При наличии обеих множеств независимая система повторно вычислит разницу.

Раздел запроса содержит идентификатор, класс аутентифицированного автора, хеш payload, условие прежнего состояния, время приёма и результат. Конфликт состояния требует отдельного статуса. Для общей транзакции с ROA можно показать связь и атомарность, не публикуя ненужные подробности.

Раздел публикации содержит хеш выпущенного ASPA, ссылку на репозиторий или manifest и первое публичное наблюдение. Раздел валидации называет точку, программу и версию, время загрузки, увиденный пригодный набор и проверенные переходы между No Attestation, Provider+ и Not Provider+.

Квитанции нужна собственная история: заменена, исправлена, истекла, выполнен откат. Откат — ещё одно решение о полном наборе. Он не должен стирать период ошибочного состояния, поскольку этот период связывает предупреждения и сетевые наблюдения.

Обычный транзит, непрозрачный route server и аварийный провайдер могут быть помечены в закрытом слое. Роль полезна для человеческой проверки, но не обязана входить в подписанный объект или публичную страницу.

Конфиденциальность не требует потери памяти

ASN провайдеров в ASPA предназначены для публичного использования RPKI. Из этого не следует публичность цены, объёма трафика, имён сотрудников, окна работ, учётных данных или внутренней топологии. Открытая квитанция может состоять из наборов, хешей, времени, грубых ролей и наблюдений.

Свидетельство валидатора тоже должно быть узким. Формула «монитор X версией Y в момент Z увидел S» воспроизводима. Фраза «Интернет сошёлся» превышает доказательство. Несколько независимых точек усиливают вывод, но не становятся всевидящей перспективой.

В марте 2026 года ARIN объявил ASPA полностью доступным в ARIN Online. Доступность продукта не измеряет внедрение и не доказывает отсутствие ошибок. На ARIN 57 John Curran отделил роль реестра в реализации и объяснении ASPA от решения операторов, применять ли его.

Предложенная квитанция соблюдает эту границу. ARIN не выбирает провайдера и не выводит связь из BGP. Он хранит аутентифицированное решение, замечает старое состояние, публикует объект и показывает, где тот был замечен.

Источники не показывают, что ARIN потерял, переставил, задержал или неверно опубликовал реальный набор. Ни один конкретный маршрут не объявляется ASPA Invalid. Контроль предлагается заранее: сохранить прежнее состояние в момент редактирования дёшево; восстановить его после ухода сессий и кешей может быть невозможно.

В рабочей заявке меняется один провайдер. В подписи меняется весь набор. Хорошая квитанция не позволяет первой правде скрыть вторую.

Источники