RIPE: 37% определений ROA не видны в BGP

Кратко

На RIPE 93 NCC сопоставила два показателя: почти 100% наблюдаемых анонсов, уже покрытых ROA, были валидны по ROV; при этом около 37% определений ASN-префикс в ROA не наблюдались в BGP.
Часть ненаблюдаемых определений относится к резервным маршрутам. Другие могут остаться после прекращения анонса и позволить выдать поддельный источник за RPKI-valid.

Разрешение пережило маршрут

Маршрут исчез, а подписанное разрешение осталось. ROA создают, когда начинают анонсировать сеть. Удаление после остановки анонса редко вызывает сбой или жалобу, поэтому уборка легко откладывается, а запись продолжает действовать в репозитории.

28 октября на RIPE 93 руководитель направления RPKI в RIPE NCC Тим Брёйнзельс показал две стороны этой картины. По его словам, примерно 73% мировых префиксов имеют ROA, если считать IPv4 и IPv6 вместе. Среди анонсируемых префиксов, уже покрытых ROA, почти 100% были валидны для ROV. Операторы быстро исправляют или фильтруют анонсы Invalid — видимые маршруты быстро приходят в порядок.

Затем докладчик посмотрел со стороны разрешений. Около 37% определений ASN-префикс в ROA не были видны в BGP. Показатель считает разрешённые сочетания ASN и префикса. Маршруты, трафик, объём адресного пространства и число объектов ROA относятся к другим величинам. Один объект ROA может содержать несколько определений префиксов.

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

Тихий маршрут может быть намеренным резервом. Владелец ресурса вправе заранее авторизовать будущий маршрут или оставить запасной источник на случай сбоя. Брёйнзельс назвал резервные маршруты одним из возможных объяснений. Панель RIPE NCC сопоставляет ROA с анонсами, которые видят сборщики RIS; документация RPKI Management API говорит, что эти данные обновляются раз в восемь часов. Панель показывает текущие наблюдения сборщиков RIS. Долгосрочный замысел маршрута должен указать владелец ресурса.

Другие определения могли пережить объявленный маршрут. Брёйнзельс прямо описал перекос стимулов: при запуске анонса есть веская причина создать ROA, а после остановки анонса такой причины почти нет. Выгода от удаления заметна меньше, чем первоначальный эффект настройки, поэтому разрешение может остаться в репозитории.

У этого остатка есть техническое следствие. Проверка источника BGP сопоставляет префикс и ASN-источника с разрешающим ROA. Она не подтверждает подлинность всего AS-пути. Если кто-то объявит префикс от имени источника, который всё ещё разрешён старым ROA, валидаторы могут признать анонс Valid. Подпись, когда-то точно описывавшая реальный маршрут, способна и дальше легитимировать источник после исчезновения эксплуатационной причины.

Простое решение — предупреждать о каждом ROA без текущего BGP-наблюдения. RIPE NCC говорит, что сигнал уже виден в интерфейсе, но его трудно найти; организация хочет сделать его заметнее и расширить оповещения. Брёйнзельс также предложил дать владельцу возможность помечать намеренный резерв, чтобы прекратить повторные напоминания. Эта метка нужна не меньше предупреждения. Если удалить все ненаблюдаемые определения, можно стереть маршрут, который оператор собирался включить во время аварии.

Нужна очередь на проверку, а не красный счётчик с кнопкой удаления. Для каждого несовпадения следует показывать префикс, ASN-источника, время последнего наблюдения и возраст данных RIS. Затем владелец выбирает состояние: действует, запланирован, резервный или выведен. Он может обновить маршрут, оставить документированный резерв или удалить разрешение, утратившее смысл. «Не наблюдается» становится вопросом оператору, а не приговором панели.

Число RIPE NCC указывает на реальный пробел в обслуживании. Высокая доля валидных наблюдаемых маршрутов может соседствовать с бесхозным запасом разрешений. Следующий показатель должен разделить нынешние 37% на резервные, запланированные, действующие и выведенные разрешения, а также посчитать, сколько выведенных записей действительно отозвали.