Кратко

  • 22 июня 2026 года IESG одобрил Best Current Practice, запрещающую передавать производные состояния проверки RPKI в атрибутах BGP через EBGP между разными административными доменами. Ревизия 12 находится в очереди RFC Editor.
  • Состояние вычисляется по локальной картине RPKI, её времени и локальной политике. Несигнированный атрибут не превращает вывод в переносимое доказательство, но связывает изменения ROA, cache и RTR с повторным объявлением огромного числа маршрутов.

Пять минут разделяют последствия одного отказа

В документе AS65536 выступает клиентом AS65537. Оба используют центральный RTR-сервис, обновляются раз в 300 секунд и добавляют Communities по результату проверки. Это аналитический сценарий авторов, а не описание реальной аварии.

AS65536 получает свежие данные за секунду до остановки сервиса. Очередь AS65537 наступает через секунду после неё. Провайдер первым теряет валидированные payloads, переводит множество маршрутов из Valid в NotFound и меняет Communities. Из-за изменения атрибута он отправляет UPDATE клиентам; AS65536 принимает и распространяет эту работу дальше.

Примерно через 300 секунд истекает локальная картина AS65536. Теперь меняются его Communities, и возникает вторая волна от того же исходного отказа. Длинный TTL сдвигает событие, но при достаточно долгой недоступности не устраняет разделение.

Префикс, Origin AS и достижимость могли не измениться. Сбой произошёл в источнике доказательств. Однако локальный вывод стал частью внешнего пути, поэтому расходы легли на BGP control plane.

У метки нет собственной цепочки доказательств

RFC 6811 определяет NotFound, Valid и Invalid через сопоставление принятого маршрута с Validated ROA Payloads, хранящимися локально. RFC прямо предлагает считать состояние локальным свойством маршрута.

На вывод влияют полученные подписанные объекты, успешность их проверки, время обновления cache, состояние RPKI-to-Router-сессии и последующая политика. Два домена могут некоторое время видеть разные результаты, и это ещё не означает злоупотребления.

Community переносит только итог. Вместе с ней не приходят набор VRP, время, trust anchor, состояние cache и правило решения. Получатель не способен воспроизвести проверку по одному атрибуту.

Обычные атрибуты BGP через EBGP также не подписаны. Третья сторона может добавить или изменить заявленное состояние. Полученное Valid не доказывает, кто его вычислил и соответствует ли оно текущей картине получателя. Это возможное описание внутреннего процесса, а не сертификат.

RFC 8097 оставлял состояние внутри доверия

RFC 8097 создал нетранзитивную Origin Validation State Extended Community для обмена внутри одного AS. Доверяющие друг другу IBGP speakers могли использовать единый расчёт.

По умолчанию реализация обязана удалить такую Community, полученную от EBGP peer, и не должна отправлять её EBGP peers. Возможное исключение — соседние AS под единым административным контролем. Границу определяет ответственность за доказательства, а не одна лишь нумерация.

Новый документ распространяет правило на стандартные, расширенные и Large Communities, значения операторов и будущие атрибуты, изменение которых запускает внешний UPDATE. Аналогичный запрет действует для локальных результатов ASPA или BGPsec, если их пытаются экспортировать тем же способом.

Внутри домена оборудование может требовать атрибут. Тогда он допустим, но перед объявлением NLRI другой администрации должен быть удалён. Внутреннее удобство не становится внешним полномочием.

Масштаб превращает аннотацию в нагрузку

Документ ссылается на измерение RIS в феврале 2024 года: от 8% до 10% наблюдавшихся BGP UPDATE содержали известные Communities для NotFound или Valid. После создания или удаления ROA-объекта цепочка обновлений продолжалась около часа. Это временной срез, не постоянная доля Интернета.

Для середины 2026 года используется совокупная таблица IPv4 и IPv6 примерно из 1,3 миллиона префиксов, около 65% которых покрыты ROA. Если отказ RPKI cache меняет экспортируемые состояния, повторной отправки могут потребовать более 850 тысяч маршрутов.

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

Связь можно использовать намеренно. Владелец префиксов способен выпускать и отзывать подписанные объекты, меняя состояние; сторона, повторно объявляющая NLRI, может изменить несигнированный атрибут. Внешняя аннотация превращает эти действия в рычаг churn.

Решение должно следовать за собственной картиной

Если сеть проверяет RPKI и отбрасывает Invalid, такие маршруты не должны попадать к клиентам. Экспортированный набор уже отражает эффект политики отправителя. Дополнительная Community не даёт соседу аутентифицированного объяснения.

Получателю, которому нужна origin security, следует проверять маршрут по собственной текущей картине. Так доказательства, время и решение остаются у одного ответственного субъекта. Сотрудничество не означает делегирование: сосед может сообщить, что он сделал, но не принимает решение за следующую сеть.

Практическая граница проста: получать и проверять RPKI локально, применять локальную политику, удерживать атрибуты состояния внутри общей администрации и удалять их на каждом внешнем edge. Наружу выходит принятый маршрут, а не несигнированная история его принятия.

Источники