Кратко
- EE-сертификат ROA обязан содержать явные IP-ресурсы без
inherit, но расширение делегирования идентификаторов AS в нём запрещено. - Разрешённая AS записана в подписанном
asID. Это полномочие владельца адресного пространства, а не аутентификация оператора и не свидетельство неотказуемости. - Файл, VRP, доставка к маршрутизатору, BGP-маршрут, локальное решение, выбранный путь и трафик требуют разных квитанций.
Зелёный файл лежал там, где маршрутизатор его не видел
В репозитории находился корректный ROA. Один валидатор уже вывел новый VRP, другой работал со старым снимком, а пограничный маршрутизатор ещё не получил следующий serial. Фраза «RPKI исправлен» описывала только одну точку цепочки.
RFC 9582 начинает раньше. Сертификат конечного объекта должен содержать расширение IP-ресурсов RFC 3779. Все префиксы подписанной нагрузки должны входить в этот набор, а inherit запрещён. Расширение ресурсов AS, напротив, не используется и не должно присутствовать.
Номер системы помещён в RouteOriginAttestation.asID. Сертификат устанавливает право подписанта распоряжаться адресным ресурсом; нагрузка фиксирует разрешение конкретной AS. Она не устанавливает юридическую личность оператора, владение BGP-ключами или факт объявления.
Стандарт прямо говорит: эта PKI даёт авторизацию, а не явную аутентификацию; ROA не предназначен для неотказуемости. Отсутствие AS-расширения — не пробел, который следует заполнить. Это граница модели.
Геометрия разрешения
Один ROA содержит один asID. Два разрешённых источника означают два объекта. Их следует хранить раздельно, иначе отзыв одного разрешения превратится в неясное изменение общей строки.
Адресный элемент содержит префикс и необязательный maxLength. Без него разрешён только точный префикс. С ним разрешаются более специфичные префиксы до указанной длины. RFC 9319 объясняет риск слишком широкого значения: оно может сделать допустимыми источники, которые не планировалось объявлять.
Поле всё равно не говорит, что такие объявления существуют. Оно задаёт множество потенциально разрешённых сравнений. Кто управляет ASN, какое устройство объявляет маршрут и доставляются ли пакеты — другие вопросы.
RFC 9582 также задаёт канонический порядок по AFI, начальному адресу, длине префикса и эффективному максимуму. Равные кортежи считаются дубликатами. Это устраняет неоднозначность представления, но не неодновременность репозиториев и кэшей.
Из файла получается VRP, но не BGP
Проверяющая сторона сначала выполняет RFC 6488: оболочка, подпись, сертификат и профиль объекта. Затем проверяет включение ресурсов, отсутствие inherit и AS-расширения, структуру и каноничность. Ошибка делает недействительным весь ROA.
Только после этого появляется VRP. RFC 6811 берёт отдельно полученный BGP-маршрут с префиксом, длиной и origin AS и сопоставляет его с VRP. Результаты Valid, Invalid, NotFound относятся к этой паре и этому набору данных.
Valid не аутентифицирует организацию и не проверяет полный путь. Invalid не доказывает злой умысел. NotFound означает отсутствие покрывающего VRP, а не отрицательную авторизацию. Время и точка наблюдения имеют значение.
RFC 8210 добавляет доставку к маршрутизатору. RFC 7115 и RFC 8893 добавляют локальные правила импорта и экспорта. Получение записи не доказывает применение правила; применение правила в одном AS не доказывает глобальную фильтрацию.
После выбора пути остаются FIB, передача пакетов и приложение. Поэтому точное утверждение ограничено: при таком trust anchor и снимке определённый подписанный объект разрешал указанной AS определённый диапазон. Всё последующее должно быть замечено отдельно.
Диагностика должна идти по цепочке
Сравнение только двух экранов создаёт ложные обвинения. Нужно связать hash файла, URI, manifest, сертификат, payload, VRP, версию валидатора, cache serial, BGP-наблюдение, вычисленное состояние, policy term, лучший путь и проверку сервиса.
Подход Heng Lu требует различать запись и исполняемое состояние. Общий стандарт координирует минимальный факт; добровольно принятая локальная политика решает, как его использовать. Символ не получает права объявить физический результат.
Источники
- https://www.rfc-editor.org/rfc/rfc9582.html
- https://www.rfc-editor.org/info/rfc9582/
- https://www.rfc-editor.org/rfc/rfc9582.txt
- https://www.rfc-editor.org/rfc/rfc9582.xml
- https://datatracker.ietf.org/doc/rfc9582/
- https://datatracker.ietf.org/doc/rfc9582/history/
- https://www.rfc-editor.org/errata/rfc9582
- https://www.rfc-editor.org/rfc/rfc6480.html
- https://www.rfc-editor.org/rfc/rfc6488.html
- https://www.rfc-editor.org/rfc/rfc3779.html
- https://www.rfc-editor.org/rfc/rfc6811.html
- https://www.rfc-editor.org/rfc/rfc8893.html
- https://www.rfc-editor.org/rfc/rfc9319.html
- https://www.rfc-editor.org/rfc/rfc8210.html
- https://www.rfc-editor.org/rfc/rfc7115.html
- https://www.rfc-editor.org/rfc/rfc6483.html
- https://www.iana.org/assignments/rpki/rpki.xhtml
- https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
