Кратко

  • maxLength в ROA определяет максимальную длину префикса, которую разрешено анонсировать указанной AS, но не перечисляет реально одобренные более специфичные маршруты.
  • Слишком узкая авторизация может сделать законную, но не подготовленную аварийную дезагрегацию Invalid; слишком широкая — показать Valid для неутверждённого префикса.
  • Реестр намерений должен связывать каждый префикс с ASN, целью, окном действия, изменением ROA, наблюдением, владельцем отзыва и сроком отката.

В обычном режиме AS 64496 анонсирует 203.0.0.0/16, а ROA разрешает ровно этот /16. Во время атаки команда объявляет 203.0.113.0/24, чтобы направить сервис к провайдеру защиты. Изменение BGP одобрено, но авторизацию RPKI заранее не подготовили. Сети, применяющие проверку источника, могут классифицировать /24 как Invalid, потому что он длиннее разрешённого.

Быстрое решение — задать для 203.0.0.0/16 значение maxLength 24. Аварийный /24 становится допустимым. Одновременно указанная AS получает право быть источником любого /24 внутри /16 — 256 возможных блоков этой длины. ROA не отличает нужный маршрут от остальных 255 и не знает, где есть сервис, мониторинг или ответственный за отзыв.

RFC 9582 придаёт объекту более узкий смысл. ROA фиксирует разрешение владельца адресного пространства для AS быть источником перечисленных префиксов. Необязательное поле maxLength задаёт наибольшую разрешённую длину; без него допускается только записанная длина. Приказ на управление трафиком, окно изменения, инцидент и дата завершения в объект не входят.

Результат RFC 6811 столь же ограничен. Полученный маршрут сравнивается с покрывающими его проверенными payload ROA, исходной AS и допустимой длиной. Valid не подтверждает весь AS_PATH, доставку пакетов, пользу дезагрегации или действующее человеческое одобрение.

Минимальная авторизация делает намерение проверяемым

RFC 9319 рекомендует по возможности использовать минимальные ROA: разрешать префиксы, которые действительно исходят в BGP, а не потенциальное множество. В общем случае документ советует избегать maxLength, но описывает конкретные исключения. Поле допустимо; риск возникает, когда сокращённая запись даёт больше полномочий, чем фактический план.

Если оператор объявляет /16 и четыре определённых /24 для региональных входов, четыре точных разрешения показывают эту схему. Запись /16–24 включает их, но также ещё 252 незапланированных /24 той же длины. RPKI проверяет источник, а не весь путь, поэтому атакующий может составить ложный путь с разрешённой AS в конце и нацелиться на неиспользуемый, но широко разрешённый подпрефикс.

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

Аварийной гибкости нужен испытанный порядок

Защита от DDoS требует продуманных исключений. Поставщик может запросить более специфичный маршрут, другой ASN источника или маршрут отбрасывания по назначению. RFC 9319 разбирает эти случаи. Клиенту следует заранее знать точные требования и испытать порядок изменения RPKI и объявления BGP.

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

Репозитории RPKI, валидаторы, передача результата маршрутизаторам и распространение BGP сходятся не одновременно. Публичные RFC не доказывают и то, как каждая сеть обрабатывает Invalid. Поэтому RFC 7115 рассматривает проверку источника как внедрение операционной политики: с наблюдением, понятными исключениями и постепенными последствиями.

Источники