Кратко

  • 20 июля LACNIC сообщил, что FORT 1.7.0 проверяет объекты ASPA и передаёт информацию маршрутизаторам; там же сказано, что функция экспериментальная, поскольку ASPA ещё не опубликован как официальный стандарт.
  • В выпуске 1.7.0.experimental параметр --server.max-rtr-version по умолчанию равен 0, хотя ASPA появляется только в RTRv2. Отдельный вывод --output.aspa также изначально отключён.
  • Проверяемая запись должна раздельно фиксировать сборку, конфигурацию, согласованную версию, принятые объекты, результат проверки пути и действие маршрутной политики.

Новая возможность начинается с закрытого шлюза.

В блоге LACNIC FORT 1.7.0 описан как валидатор объектов ASPA, уже встречающихся в некоторых репозиториях RPKI, и источник данных для решений маршрутизаторов. Релиз проекта, опубликованный четырьмя днями ранее, называется 1.7.0.experimental: ASPA и RTRv2 реализованы, но максимальная версия RTR сервера по умолчанию остаётся нулевой.

Первое утверждение говорит о возможности, второе — о начальном поведении. Ни одно не раскрывает настройки конкретной сети.

Оснований говорить, что экспериментальный статус скрыт, нет. LACNIC прямо предупреждает о незавершённом стандарте. Разработчики объясняют осторожность: FORT пока не выдаёт Router Keys, поэтому RTRv1 не добавляет полезной нагрузки, а RTRv2 продолжает меняться. Вопрос подотчётности не в том, хорош ли ноль, а в том, можно ли проследить переход от пакета к маршруту.

Три независимых переключателя

Документация версии разделяет ограничения.

Параметр По умолчанию Что он определяет
--aspa.max-providers 4 000 Число ASN-провайдеров одного клиентского ASN за цикл проверки
--output.aspa NULL, отключён Вывод действительных ASPA в JSON
--server.max-rtr-version 0 Наивысшую версию RPKI-to-Router для переговоров с клиентами

Лимит проверки не включает файл. Файл не включает протокол. Протокол не задаёт политику выбора.

Руководство уточняет: RTRv0 несёт префиксные VRP, RTRv1 добавляет Router Keys, RTRv2 — ASPA. Значит, FORT способен проверить ASPA внутри процесса и при отдельной настройке вывести его в файл, но сессия v0 не передаст PDU ASPA версии 2.

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

Результат переговоров важнее намерения

RTRv2 revision 27 предписывает маршрутизатору начать с наивысшей реализованной версии. Кэш либо открывает её, либо переходит к совместимой младшей. После понижения функции старшей версии в сессии недоступны.

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

Цепочка может оборваться на бинарном файле, проверке объекта, выводе, потолке, клиенте, покрытии, вычислении или политике. Формула «ASPA включён» стирает различия между восемью причинами.

Проверенный объект ещё не проверенный путь

Профиль ASPA revision 29 задаёт подписанное разрешение держателя клиентского ASN для ASN-провайдеров. Relying Party проверяет объект, сертификат и содержимое; это ещё не оценка AS_PATH.

Процедура revision 28 выдаёт Valid, Unknown или Invalid. Рекомендуется исключать Invalid из выбора, а Unknown ставить на уровень Valid, но конкретное смягчение остаётся за оператором.

Число объектов измеряет валидатор, сессия v2 — транспорт, три состояния — вычисление, RIB/FIB и политика — применение. Получение PDU не равно отказу от маршрута.

И v0 не означает бездействие: префиксная проверка остаётся, файл пригоден для экспериментов. Доказанный вывод скромнее — FORT поставляет экспериментальную функцию, а доставку и действие оставляет явному выбору.

Номер черновика входит в идентичность сборки

Руководство связывает реализацию с 8210bis-25. На дату проверки текущей была revision 27, профиль ASPA достиг 29, а проверка пути — 28.

Разница не доказывает несовместимость: изменения могут быть редакционными или техническими, и нужен тест. Но она доказывает недостаточность общей метки RTRv2. В записи нужны revision, commit, пакет и проверенный партнёр.

RFC 8210 остаётся опубликованной спецификацией версии 1. PDU ASPA относится к версии 2, пока имеющей статус Internet-Draft. Это делает осторожный default понятным и требует фиксировать будущую миграцию.

Скачивание не равно установке, установка — процессу, процесс — v2, а v2 — применённой защите.

Публичная карточка и локальная квитанция

Карточка выпуска хранит tag, commit, пакеты и хэши, версии трёх документов, значения по умолчанию, ограничения, отклонения, совместимые клиенты и rollback. Для неё не нужна частная телеметрия.

Локальная квитанция связывает хэш пакета, запуск и отпечаток конфигурации с потолком RTR; агрегирует клиентов по согласованной версии; записывает цикл, принятые и отклонённые ASPA по причинам, файл и его хэш, режим проверки, состояния пути, политику и возврат.

Имена роутеров и топологию можно не публиковать. Безопасных агрегатов достаточно снаружи, подробность остаётся для аудита.

Ключ соединения — пакет, реализованный draft и конфигурация. Без него карточка описывает возможность, а отчёт — безымянный процесс.

Границы вывода

Источники не считают установки, изменения default, сессии v2, релевантные ASPA или отклонённые маршруты. Они не доказывают ошибочность объявления, необходимость v2 для всех или несовместимость revision 25 и 27.

ASPA не даёт полной безопасности BGP: он фиксирует авторизацию провайдеров и помогает искать утечки, но не проверяет forwarding, не устраняет Unknown и не отменяет локальную политику.

Установлены четыре факта: FORT 1.7.0.experimental реализует ASPA и RTRv2; потолок равен 0; файловый вывод отключён; окончательное действие принадлежит оператору. Полезный вопрос — не «есть ли ASPA», а «какая сборка, какой draft, какая сессия, какое состояние и какая политика».

Источники