Авторизация происхождения маршрута — это цифровая подпись RPKI Запись, которая определяет, какой автономной системе (AS) разрешено анонсировать IP-префикс в BGP. Она создаётся организацией, владеющей соответствующим интернет-ресурсом, или от её имени. Обычно ROA содержит три основных элемента: IP-префикс, авторизованный исходный номер автономной системы (ASN) и максимальную длину префикса, которую данная ASN может анонсировать. Например, организация может контролировать IPv4-префикс 203.0.113.0/24 и использовать AS64500 для его анонса. Соответствующая запись ROA может авторизовать AS64500 на анонс этого /24. Проще говоря, такая запись передаёт следующую инструкцию маршрутизационной экосистеме: «Этой ASN разрешено анонсировать данный префикс». Сети, выполняющие проверку RPKI, могут затем сравнить эту запись с тем, что они наблюдают в BGP. Запись ROA не передаёт право собственности на блок IP-адресов. Она не заменяет договор, запись в реестре, документ об аллокации или соглашение о передаче IPv4-адресов. Она лишь публикует информацию об авторизации, связанной с источником маршрута. Юридический контроль и маршрутная авторизация связаны между собой, но это не одно и то же. Записи ROA могут создаваться как для ресурсов IPv4, так и для ресурсов IPv6. Формат у них схож, хотя длины префиксов и операционные особенности могут различаться. В сетях IPv4 часто используются префиксы типа /24, тогда как в сетях IPv6 обычно анонсируются агрегаты, такие как /32, /36, /48 или другие длины, подходящие для их аллокации и плана маршрутизации.
Зачем нужен ROA?
Без ROA другие сети не имеют авторизации на основе RPKI для подтверждения того, что BGP-оригин ASN разрешено анонсировать префикс. Маршрут может быть легитимным, но при валидации RPKI он, как правило, будет возвращать результат Not Found (не найдено), поскольку отсутствует соответствующая авторизация. Результат Not Found не является автоматически проблемой маршрутизации. Многие действительные маршруты в интернете не имеют ROA. Однако, когда организация публикует точный ROA, она предоставляет другим сетям более сильный сигнал, который можно использовать для различения ожидаемого источника от несанкционированного или неправильно сконфигурированного. ROA становится особенно полезным, когда префикс ценен, критически важен для бизнеса или широко анонсируется. Предприятие может использовать собственное адресное пространство для публичных служб, облачная платформа может анонсировать инфраструктуру клиентов, а хостинг-провайдер может рекламировать большие диапазоны адресов из нескольких местоположений. В этих ситуациях неверный источник может повлиять на многих пользователей и службы. ROA также помогают при реагировании на инциденты. Если префикс внезапно появляется от неожиданного ASN, оператор сети может проверить статус RPKI и быстро определить, противоречит ли анонс опубликованным намерениям владельца ресурса. Это не объясняет все детали инцидента, но предоставляет важную отправную точку для расследования. Для организаций, использующих несколько провайдеров верхнего уровня, ROA может обеспечивать согласованную авторизацию независимо от того, какой провайдер транзитирует маршрут. Провайдер может измениться, но исходный ASN может остаться прежним. В этом случае ROA обычно не нужно изменять просто потому, что изменился транзитный путь.
Как работает ROA с BGP?
BGP распределяет объявления маршрутов между автономными системами. Объявление маршрута обычно включает IP-префикс и исходную автономную систему (ASN), а также другую информацию о пути и политиках. Исходная ASN — это автономная система, которая заявляет о себе как об источнике маршрута. Валидация RPKI работает совместно с BGP. Валидатор получает подписанные данные авторизации из системы RPKI и проверяет их подлинность и актуальность. Затем он формирует валидированный набор данных, который может использоваться маршрутизаторами, серверами маршрутизации или системами политик маршрутизации. Когда сеть получает объявление BGP, она сравнивает объявленный префикс и исходную ASN с валидированной информацией ROA. Возможны три основных результата: Valid (Действительно), Invalid (Недействительно) или Not Found (Не найдено). Результат Valid означает, что объявление покрывается ROA и исходная ASN авторизована. Результат Invalid означает, что существует соответствующая ROA, но объявление противоречит ей. Результат Not Found означает, что применимая ROA не найдена. Принимающая сеть решает, что делать с этими результатами. Некоторые операторы отклоняют маршруты со статусом Invalid. Другие назначают им меньший приоритет, генерируют оповещения или применяют различные политики в зависимости от источника. Не существует единой универсальной политики для всех сетей, однако многие провайдеры рассматривают объявления со статусом Invalid как серьёзную проблему безопасности маршрутизации. Важный момент заключается в том, что ROA напрямую не управляет глобальным Интернетом. Она публикует информацию об авторизации. Практический эффект зависит от того, извлекают ли другие сети эту информацию, проводят её валидацию и используют ли при принятии решений о маршрутизации.
Три основные части ROA
Первая часть ROA — это IP-префикс, который авторизован и определяет диапазон адресов, который исходный автономная система (ASN) может анонсировать. Для IPv4 префикс может выглядеть как 198.51.100.0/24; для IPv6 — как 2001:db8:1234::/48. Префикс должен соответствовать ресурсу, которым организация имеет право управлять через соответствующий реестр или спонсирующие отношения. Префикс следует вводить точно, поскольку опечатка, неверная граница сети или неправильная длина префикса могут сделать ROA недействительной или авторизовать другой диапазон, отличный от задуманного.
Вторая часть — это авторизованный AS-номер (ASN), который должен быть указан как источник префикса, то есть ASN, соответствующий тому, который фигурирует в качестве источника в объявлении BGP. Если компания владеет блоком адресов, но анонсирует его через ASN транзитного провайдера, правильный выбор исходного ASN зависит от фактической маршрутизации. ASN в ROA обычно должен указывать тот AS-номер, который фактически инициирует маршрут, а не просто ASN вышестоящего оператора связи. Это различие важно, поскольку транзитный провайдер может передавать маршрут, не являясь его источником; если префикс инициируется клиентским ASN, а провайдер лишь транспортирует его, то для авторизации обычно требуется указать именно клиентский ASN.
Третья часть — это максимальная длина префикса, часто называемая maxLength, которая определяет, насколько конкретным может быть объявление, оставаясь при этом покрытым ROA. Предположим, что ROA разрешает 198.51.100.0/24 с максимальной длиной /24: авторизованный ASN может объявить точный /24, но ему не разрешено объявлять более мелкие подпрефиксы, такие как /25 или /26. Если тот же префикс авторизован с максимальной длиной /26, объявления для /24, /25 и /26 могут считаться покрытыми в зависимости от конкретного маршрута и правил проверки. Это обеспечивает гибкость, но также позволяет более специфичные объявления. Поэтому максимальная длина должна отражать реальный план маршрутизации, поскольку установка слишком короткой длины может привести к тому, что легитимные более специфичные маршруты станут недействительными, а установка слишком длинной может авторизовать объявления, которые организация никогда не намеревалась разрешать.
Почему maxLength имеет значение?
Максимальная длина префикса является одним из наиболее важных и чаще всего неправильно понимаемых параметров ROA, определяющим уровень детализации, который разрешённый ASN может использовать при анонсе ресурса. Многие сетевые операторы анонсируют агрегированный префикс для сокращения роста таблицы маршрутизации; например, организация может владеть префиксом /20, но анонсировать его как единый агрегат. В некоторых случаях организация также может нуждаться в анонсе более специфичных префиксов для управления трафиком, региональной связности или разделения услуг. Если ROA охватывает только агрегированный префикс, а сеть анонсирует более специфичные маршруты, такие маршруты могут быть классифицированы как недействительные (Invalid). BGP-анонс может быть технически корректным с точки зрения организации, но он не соответствует авторизации, опубликованной в RPKI. С другой стороны, авторизация каждого возможного более специфичного маршрута может снизить точность политики, поскольку авторизация /20 с чрезвычайно широкой максимальной длиной позволяет гораздо меньшему субпрефиксу выглядеть авторизованным, даже если он выходит за рамки предполагаемой архитектуры. Практический подход заключается в том, чтобы авторизовать только те длины префиксов, которые сеть действительно планирует анонсировать на основе плана адресации, требований провайдера, схемы отказоустойчивости и стратегии управления трафиком. Изменения максимальной длины следует тщательно тестировать, подтверждая, что все рабочие анонсы возвращают ожидаемый результат проверки, прежде чем применять строгую фильтрацию.
ROAs for IPv4 and IPv6
ROA могут создаваться как для сетей IPv4, так и для сетей IPv6, а лежащий в основе принцип безопасности одинаков: связывание префикса с авторизованным автономным номером системы (ASN). Основное операционное различие заключается в структуре адресации. Ресурсы IPv4 являются дефицитными, и они часто анонсируются относительно небольшими префиксами, при этом /24 является распространённым минимальным размером анонса в публичном Интернете. Сети IPv6 обычно получают более крупные выделения адресного пространства и могут разделять их на сегменты по сайтам, службам или географическим признакам, анонсируя один агрегированный префикс, одновременно используя несколько внутренних префиксов. ROA должна соответствовать префиксам, анонсируемым публично. Операторы IPv6 не должны предполагать, что большое адресное пространство устраняет риски маршрутизации, поскольку несанкционированный анонс IPv6 всё ещё может вызывать проблемы с доступностью, перенаправление трафика или несоответствия в глобальной маршрутизации. RPKI предоставляет операторам IPv6 такую же возможность публиковать авторизацию происхождения, как и операторам IPv4. Перед созданием ROA для IPv6 сетевая команда должна задокументировать, какие агрегированные префиксы будут анонсироваться, ожидаются ли анонсы более специфичных префиксов и какой ASN будет их инициировать, чтобы избежать создания записей, которые либо слишком ограничительны, либо необоснованно широки.
Когда следует создавать ROA?
ROA следует создавать до объявления префикса в рабочей среде, если владелец ресурсов имеет четкий план маршрутизации, что дает проверяющим сетям время для получения информации до того, как маршрут станет широко видимым. Организациям также следует пересматривать ROA при получении нового выделения, приобретении блока IPv4, завершении передачи адресов, изменении исходного ASN или начале использования нового выделения IPv6, поскольку эти события изменяют связь между префиксом и исходящей сетью. Еще одним распространенным триггером является миграция провайдера: если организация сохраняет тот же исходный ASN и меняет только вышестоящего оператора, ROA может оставаться действительной; если миграция изменяет исходный ASN, запись должна быть обновлена до или одновременно с изменением маршрутизации. ROA следует пересматривать при слияниях, поглощениях, переездах в центры обработки данных, изменениях спонсорства ASN и крупных перепроектированиях сети, чтобы убедиться, что публичные разрешения соответствуют фактическому состоянию эксплуатации. Периодический пересмотр полезен даже в отсутствие известных изменений, так как документация по сети устаревает, обязанности персонала меняются, а старые авторизации могут оставаться активными долгое время после замены первоначальной схемы маршрутизации.
Распространённые ошибки конфигурации ROA
Одной из наиболее распространённых ошибок является указание неверного исходного ASN, что происходит, когда инженеры путают клиентский ASN с ASN транзитного провайдера или когда после миграции в конфигурации остаётся старый ASN. Другой распространённой ошибкой является забывчивость обновить ROA после передачи IPv4-адресов: новый владелец анонсирует префикс от своего ASN, тогда как старая авторизация всё ещё указывает на предыдущий источник, из-за чего маршрут становится недействительным (Invalid). Неправильная максимальная длина создаёт аналогичные проблемы, когда организация авторизует только /24, но позже анонсирует /25 для целей управления трафиком. Некоторые организации создают несколько пересекающихся ROA без документирования их назначения; хотя такие конфигурации могут быть корректными в определённых проектах, они способны приводить к непредвиденным результатам и усложнять диагностику. Отсутствие удаления устаревших записей позволяет ASN продолжать анонсировать префикс даже спустя долгое время после изменения сетевой архитектуры. Наконец, некоторые организации включают строгое отклонение маршрутов со статусом Invalid, не протестировав предварительно собственные анонсы; перед применением автоматической фильтрации необходимо всегда проверять производственные префиксы, максимальные длины и исходные ASNs.
ROA and IPv4 Transfer Planning
Переходы IPv4 требуют особого внимания, поскольку административный владелец, спонсирующая организация и источник маршрутизации могут меняться на разных этапах процесса. До завершения перехода текущий владелец должен задокументировать существующие ROA (Origin Authorization Records) и подтвердить, какая ASN в настоящее время инициирует префикс, а покупатель — подготовить предполагаемую информацию об источнике и согласовать её с транзитными провайдерами. В период перехода обе стороны должны иметь чёткий план обновления или замены записей авторизации: слишком долгое сохранение предыдущей ROA после перехода позволяет старому источнику оставаться авторизованным, а преждевременное удаление приводит к тому, что существующий маршрут становится недействительным (Invalid) до того, как новый маршрут будет готов. Точный процесс зависит от реестра, типа ресурса, соглашения о передаче и операционной архитектуры, что делает RPKI обязательным пунктом контрольного списка наряду с проверкой реестра, анализом контрактов, объявлениями BGP, объектами маршрутизации, обратным DNS и оценкой репутации. Публичный инструмент проверки готовности помогает определить текущую ASN-источник, состояние RPKI, информацию реестра и видимость префикса в BGP для технических предварительных проверок, однако он не подтверждает законное право собственности и не гарантирует возможность передачи.
Изменения в ROA и ASN
Изменение автономной системы (ASN) напрямую влияет на валидацию RPKI. Если префикс, ранее анонсировавшийся AS64500, теперь будет анонсироваться AS64510, ROA должна авторизовать новый источник до того, как BGP-анонс может быть принят как действительный. Это особенно важно, когда организация переходит от ASN, управляемого провайдером, к собственной ASN или изменяет условия сотрудничества с LIR, что требует совместного пересмотра отношений с реестром и маршрутизационных авторизаций. Тщательно спланированный переход может включать временную авторизацию как старого, так и нового источников для создания контролируемого окна миграции, при условии документирования этого процесса и удаления устаревшей авторизации по завершении перехода. Сетевая команда должна протестировать порядок операций перед внесением изменений в рабочую среду, убедившись, что новая авторизация опубликована и проверена до анонса нового BGP-маршрута.
Как проверить, работает ли ROA?
Первая проверка заключается в подтверждении того, что ROA содержит предполагаемый префикс, исходный ASN и максимальную длину префикса через соответствующий портал RIR, интерфейс спонсируемого LIR или систему управления RPKI. Далее следует сравнить авторизацию с фактическим объявлением BGP, убедившись, что объявленная длина префикса покрывается и что исходный ASN совпадает с ROA. Затем внешний валидатор RPKI может подтвердить публичный статус, где правильно настроенное объявление возвращает статус Valid (Действительно). Если результат Invalid (Недействительно), сначала проверьте исходный ASN и длину префикса; если Not Found (Не найдено), убедитесь, что ROA опубликована и у валидаторов было время для её получения. Результаты не обновляются мгновенно, поскольку репозитории, валидаторы и системы маршрутизации опираются на интервалы обновления, поэтому короткие задержки во время распространения являются нормальным явлением. Сравнение нескольких публичных источников, включая данные реестров, результаты валидации и текущие наблюдения BGP, позволяет избежать зависимости от кэшированной информации и обеспечивает полную картину.
Что происходит, когда ROA является недействительным?
Когда объявление BGP конфликтует с существующей ROA, валидаторы RPKI классифицируют его как недействительное (Invalid). Маршрут автоматически не удаляется из глобального Интернета, однако сети, применяющие политики на основе RPKI, могут отклонять его или назначать ему меньший приоритет. Операционные последствия зависят от масштаба применения политик: некоторые сети строго фильтруют такие маршруты, тогда как другие используют статус только для мониторинга, что означает, что недействительный маршрут может оставаться видимым в части Интернета, но становиться недоступным через другие сегменты. Если легитимный маршрут становится недействительным, организации следует рассматривать это как критическую проблему конфигурации, уделяя первоочередное внимание проверке исходного ASN, длины анонсируемого префикса и максимальной длины ROA. Маршрут не следует считать вредоносным, поскольку большинство случаев недействительности возникают из-за рутинных ошибок, таких как незавершённые миграции, устаревшие записи, неверные данные провайдера или случайное анонсирование более специфичных префиксов. После исправления системам требуется время для обновления данных, а команде сети необходимо отслеживать маршрут до его стабилизации во всех точках наблюдения.
Как организациям следует управлять ROA?
Управление ROA требует наличия четко определенного владельца, которым может быть команда сетевой инженерии, команда безопасности, спонсирующий LIR, управляющий провайдер услуг или другая группа, ответственная за ресурсы интернет-нумерации. Организация должна вести реестр, содержащий сведения о каждой префиксе, исходном ASN, максимальной длине, местах объявления и контактных лицах, ответственных за них, чтобы упростить проверку изменений и реагирование на инциденты. Изменения в ROA должны интегрироваться в стандартные процедуры управления изменениями в сети, рассматривая RPKI как явное требование при миграции ASN, смене провайдера, передаче IPv4-адресов или развертывании IPv6. Должны быть настроены мониторинг и оповещения для случаев получения статуса Invalid, неожиданных источников, отмены авторизаций или изменений видимости в BGP. Критически важно избегать чрезмерно широких авторизаций: точные ROA проще понять, легче аудировать и значительно реже приводят к разрешению непреднамеренных объявлений.
Часто задаваемые вопросы
Является ли ROA тем же самым, что и документ о праве собственности на IP-адрес?
Нет. ROA — это авторизация маршрутизации, указывающая, какой ASN может анонсировать префикс в BGP. Она не заменяет записи реестров, договоры, документы о передаче или доказательства юридического права собственности.
Может ли один префикс иметь более одного ROA?
Да. Несколько ROA могут быть уместны, когда префикс намеренно originates более чем одним ASN или когда контролируемая миграция требует временной авторизации для нескольких origins, хотя перекрывающиеся записи должны быть тщательно задокументированы.
Объявляет ли ROA мой префикс в BGP?
Нет. Создание ROA не создаёт BGP-анонс; сеть по-прежнему должна настраивать BGP через свои маршрутизаторы и провайдеров верхнего уровня.
Нужно ли указывать провайдера транзита в ROA?
Обычно ROA должна идентифицировать ASN, который инициирует маршрут. Провайдер, который только транзитно передает маршрут, не обязательно является исходным ASN, и правильное значение зависит от фактической архитектуры маршрутизации.
Сколько времени требуется, чтобы ROA стал видимым?
Сроки зависят от системы RIR, репозитория публикаций, интервалов обновления валидатора и кэширования. Обновления обычно становятся видимыми относительно быстро, однако для производственных изменений следует предусматривать достаточное время на проверку.
Должен ли каждый префикс IPv4 и IPv6 иметь ROA?
Настоятельно рекомендуется публиковать точные ROA для префиксов, анонсируемых в BGP. Организации следует сначала подтвердить свою маршрутизационную схему, чтобы авторизация случайно не сделала легитимные анонсы недействительными.
Может ли ROA защитить от каждой атаки BGP?
Нет. ROA в первую очередь поддерживает проверку происхождения маршрутов. Она не проверяет все части пути BGP, не предотвращает все утечки маршрутов, не шифрует трафик и не гарантирует, что трафик будет следовать по безопасному физическому маршруту.
Авторизация начала маршрутизации (ROA) является ключевым компонентом RPKI, устанавливающим криптографически подписанную связь между IP-префиксом и автономной системой (ASN), уполномоченной объявлять этот префикс в BGP. Запись обычно включает префикс, исходную ASN и максимальную длину префикса — каждый из этих параметров играет решающую роль в идентификации ресурса, разрешении начала маршрутизации и определении степени детализации объявления. Точные ROA помогают сетям выявлять несанкционированные или неправильно настроенные объявления, что имеет жизненно важное значение при передаче IPv4-адресов, изменении ASN, миграции провайдеров, развертывании IPv6 и работе многомаршрутизируемых сетей. В то же время ROA не является доказательством законного права собственности и не представляет собой самостоятельного решения для обеспечения безопасности маршрутизации; она наиболее эффективна в сочетании с точными записями в реестрах, дисциплинированными конфигурациями BGP, данными IRR, мониторингом маршрутов и документированными процессами изменений. Для любой организации, объявляющей публичные пространства IPv4 или IPv6, практическое правило простое: публиковать только те начала маршрутизации, которые вы намерены использовать, авторизовать только те длины префиксов, которые вы фактически планируете объявлять, и пересматривать записи при любых изменениях в сети. Это обеспечивает соответствие данных RPKI реальной среде маршрутизации и снижает вероятность того, что легитимный маршрут будет классифицирован как недействительный (Invalid).