Зачем сетевым операторам нужно разрешение на источник маршрута (ROA)
ROA указывает, какая сеть вправе анонсировать маршрут от своего имени. Как подготовить разрешение, проверить его действие и сменить сеть, не принимая подписанную запись за гарантию доставки.
Разрешение на источник маршрута связывает блок адресов с сетью, которой разрешено его анонсировать. Оно не гарантирует прохождение всего пути.
Ваши адреса не изменились, но вы хотите, чтобы их анонсировала другая сеть. Новое подключение готово. Примет ли маршрут остальной интернет? Разрешение на источник маршрута, или ROA, — одна из записей, которые нужно привести в порядок до перехода.
Оно позволяет держателю адресов указать, какая автономная система вправе быть источником маршрутов для префикса — блока IP-адресов. Это утверждение даёт другим сетям данные для проверки. Оно не анонсирует маршрут, не переносит пакеты и не гарантирует, что каждый провайдер примет маршрут.
Начните с анонса, который собираетесь опубликовать
Автономная система — это сеть с собственной политикой маршрутизации, идентифицируемая номером ASN. ASN источника — номер системы, указанной как начальная точка анонсируемого маршрута. Этой автономной системой не обязательно управляет организация, зарегистрированная как держатель адресов.
Прежде чем публиковать разрешение, определите префикс, предполагаемый ASN его источника и все более специфичные префиксы, которые вы действительно планируете анонсировать. Формат ROA, описанный в RFC 9582, связывает ASN с префиксами и их допустимыми максимальными длинами. Более длинный префикс описывает меньший блок адресов.
Например, разрешить конкретный /24 — не то же самое, что разрешить все меньшие блоки внутри него. Неоправданно большое значение maxLength даёт больше свободы, чем требуется для текущего анонса. В RFC 9319 объясняется, почему операторам следует задавать это разрешение точно.
Публикация и проверка — разные задачи
Держатель публикует подписанные материалы разрешения через используемую им инфраструктуру RPKI. ПО проверки принимающей сети проверяет эти материалы и формирует набор проверенных записей. Её маршрутизаторы могут использовать эти записи для сопоставления источников входящих маршрутов. Оператор настраивает, как результат влияет на маршрутизацию.
Совпадающий источник и разрешённая длина префикса дают статус Valid. Наличие охватывающего префикс разрешения без подходящего совпадения даёт Invalid. Отсутствие охватывающего разрешения даёт NotFound. Эти три состояния позволяют отличить отсутствие записи от противоречия с ней. Само по себе наличие ROA в репозитории не блокирует ложный анонс повсюду.
Вносите изменения в правильном порядке
Если блок адресов переходит к другому источнику маршрута, подготовьте необходимое разрешение до того, как начнёте полагаться на новый анонс. Если в переходный период намеренно используются оба источника, разрешения должны отражать этот план. Проследите, какие данные поступают к валидаторам и принимающим сетям, затем подтвердите фактические маршруты и достижимость. Удаляйте устаревшие разрешения, когда они больше не нужны.
Не существует единого момента, когда все маршрутизаторы видят новую запись. Публикация RPKI, проверка и обновление маршрутизаторов происходят в свои сроки; уменьшение TTL в DNS ими не управляет. В RFC 7115 рассматриваются эксплуатационные различия в работе кэшей и обновлений.
Проверяйте ошибочные источники и длины префиксов в изолированной лаборатории. В рабочей сети отслеживайте ожидаемые маршруты, данные проверки, состояние сеансов и политики ваших провайдеров. Резервные валидаторы помогают при отдельных отказах, но их источники данных, программное обеспечение и конфигурации всё равно могут иметь общие зависимости.
Не отказывайтесь от остальных проверок
Проверка источника не подтверждает подлинность всего пути AS, не останавливает все утечки маршрутов и не шифрует пользовательский трафик. Фильтры префиксов, отношения между сетями при маршрутизации и другие эксплуатационные меры по-прежнему важны. Если маршрут не работает, исследуйте конкретное несоответствие и политику принимающей стороны; ни отключение всех проверок, ни предположение, что каждый маршрут со статусом Invalid — это атака, не являются обоснованной диагностикой.
Безопасность должна служить тем, кто управляет сетью
В заметке 28 Лу Хэн утверждает, что необходимое ведение реестров не должно превращаться в наказание по усмотрению администратора. Полезное подписанное разрешение — это техническое утверждение; оно не даёт неограниченных полномочий организации, которая ведёт связанные с ним записи.
В заметке 64 он призывает к общим правилам, проверяемым локально, переносимым координационным записям и праву участников выбирать, принимать ли будущие изменения. Для сетевых операторов причина уделять этому внимание — непрерывность работы: нужно знать, от каких записей зависит ваш сервис, кто может их менять и как сохранить возможность пользоваться достоверными подтверждающими данными, если координатор перестанет выполнять свои функции.
Продолжите чтение статьёй о том, почему у IPv4-префикса меняется ASN источника, чтобы различать изменение маршрутизации и смену держателя.