ASPA — как новый стандарт проверяет путь интернет-трафика и защищает от утечек маршрутов
Перевод статьи Cloudflare про ASPA — криптографический стандарт, который проверяет путь интернет-трафика и защищает от утечек маршрутов BGP.
Это перевод с адаптацией статьи Mingwei Zhang и Bryton Herdes из блога Cloudflare.
BGP (Border Gateway Protocol) — протокол, по которому автономные системы (AS) обмениваются информацией о маршрутах. Автономная система — это сеть под управлением одного оператора: провайдера, облачной платформы, крупной компании. Когда вы открываете сайт, трафик проходит через цепочку таких AS. Но иногда он уходит не туда — из-за ошибок конфигурации или злонамеренных действий. Такие инциденты называются утечками маршрутов (route leaks). Новый криптографический стандарт ASPA (Autonomous System Provider Authorization) призван решить эту проблему — он проверяет не только пункт назначения, но и весь путь трафика.
Ключевые выводы
- ASPA — новый стандарт криптографической проверки маршрутов BGP, дополняющий существующий RPKI/ROA
- ROA проверяет пункт назначения трафика, ASPA проверяет путь — цепочку сетей, через которые он проходит
- ASPA обнаруживает утечки маршрутов, проверяя, что трафик движется по «горной» модели: вверх к провайдеру, через пиринг, вниз к получателю
- Создать ASPA-запись можно за пару кликов в RIPE или ARIN
- Cloudflare Radar теперь отслеживает глобальное внедрение ASPA в реальном времени
Как сейчас защищён BGP: RPKI и ROA
Сегодня сети используют инфраструктуру RPKI (Resource Public Key Infrastructure), внедрение которой значительно выросло за последние годы. В рамках RPKI сети публикуют криптографические записи — ROA (Route Origin Authorizations). ROA — это верифицируемое цифровое удостоверение, подтверждающее, что конкретная автономная система (AS) авторизована анонсировать определённые IP-адреса. Это решает проблему origin hijacks — когда одна сеть выдаёт себя за другую.
Но ROA проверяет только пункт назначения. А что насчёт пути?
Что такое ASPA и как он работает
ASPA (Autonomous System Provider Authorization) надстраивается над RPKI. Если ROA проверяет куда идёт трафик, то ASPA проверяет как он туда добирается.
Когда данные путешествуют по интернету, каждая сеть на пути записывается в лог — AS_PATH. ASPA позволяет сетям официально публиковать список авторизованных апстрим-провайдеров в системе RPKI. Любая принимающая сеть может посмотреть на AS_PATH, проверить ASPA-записи и убедиться, что трафик прошёл только через одобренную цепочку сетей.
Модель «горы»: как устроена здоровая маршрутизация
В нормальной топологии (valley-free routing) трафик движется по «горной» модели:
- Подъём (Up-Ramp) — трафик идёт от клиента вверх через всё более крупных провайдеров (ISP)
- Вершина (Apex) — на уровне магистрали трафик может пересечь один пиринговый линк
- Спуск (Down-Ramp) — трафик спускается через провайдеров к получателю
Один из типов утечки — «долина» в этой модели. Она происходит, когда трафик спускается к клиенту и неожиданно пытается снова подняться к другому провайдеру. Клиентские сети не предназначены для транзита трафика между крупными провайдерами.
Как ASPA валидирует маршруты
ASPA проверяет цепочку отношений с обоих концов маршрута:
- Проверка подъёма — начинаем от источника и двигаемся вперёд. На каждом хопе спрашиваем: «Авторизовала ли эта сеть следующую как своего провайдера?»
- Проверка спуска — то же самое, но в обратном направлении от получателя BGP-обновления
Если «подъём» и «спуск» встречаются или пересекаются на вершине — маршрут валидный. Форма горы сохранена.
Если пути не сходятся и в середине есть разрыв — ASPA отмечает маршрут как проблемный. Этот разрыв и есть «долина», то есть утечка.
Пример: обнаружение утечки маршрута
Допустим, сеть AS65539 получает подозрительный маршрут от клиента AS65538. Клиент пытается отправить трафик, полученный от одного провайдера (AS65537), «вверх» к другому провайдеру (AS65539) — действуя как мост между провайдерами. Это классическая утечка маршрута.
Процесс валидации ASPA:
- Проверяем подъём: источник (AS65536) авторизует своего провайдера — проверка пройдена
- Проверяем спуск: начинаем от получателя и смотрим назад — видим клиента (AS65538)
- Несовпадение: подъём заканчивается на AS65537, спуск — на AS65538. Пути не соединяются
Результат: маршрут отмечен как ASPA Invalid. Без подписанных ASPA-объектов в RPKI невозможно определить, какие сети авторизованы анонсировать префиксы горизонтально (пирам) или вверх (провайдерам).
ASPA против forged-origin hijacks
ASPA эффективно защищает от forged-origin hijacks — атак, при которых злоумышленник обходит проверку ROV: он анонсирует реальный IP-префикс с правильным origin AS, но вставляет себя в AS_PATH как промежуточный хоп. ROV это не замечает, так как проверяет только origin. Источник формально правильный, но связь между атакующим и жертвой — сфабрикована.
ASPA разоблачает это: сеть-жертва криптографически объявляет своих реальных провайдеров, и поскольку атакующий не входит в этот список, маршрут отклоняется.
Ограничение: ASPA не защищает от всех случаев. Провайдер может подделать пиринговый линк с другой AS, чтобы привлечь трафик клиента коротким AS_PATH, даже если такого пирингового линка в реальности не существует. ASPA работает только с информацией о провайдерах и ничего не знает о пиринговых отношениях.
Как создать ASPA-запись: пара кликов
Создание ASPA-объекта для вашей сети стало простым в реестрах RIPE и ARIN. Всё, что нужно — ваш номер AS и номера AS ваших провайдеров, у которых вы покупаете транзит. В обратном направлении это сети, которым вы разрешаете присылать полную таблицу маршрутизации — карту достижимости остального интернета.
Пример Cloudflare: для AS203898 (офис в Лондоне) с тремя интернет-провайдерами (AS8220, AS2860, AS1273) процесс занимает три шага:
- Войти в RPKI-дашборд RIPE и перейти в раздел ASPA
- Нажать «Create ASPA» для нужного AS
- Указать список провайдеров
Через короткое время ASPA-запись появляется в глобальной RPKI-экосистеме.
Отдельный случай — запись с AS0 в качестве провайдера. Это означает, что у сети нет апстрим-провайдеров. По определению, каждая транзитно-свободная сеть Tier-1 в будущем должна будет подписать ASPA только с «AS0» — если у неё действительно только пиринговые и клиентские отношения.
Мониторинг ASPA в Cloudflare Radar
Cloudflare Radar добавил новые возможности мониторинга внедрения ASPA:
- Графики роста внедрения ASPA по пяти региональным реестрам (RIR)
- Интеграция ASPA-данных в страницы маршрутизации по странам и ASN
- Для каждой AS — список провайдеров из ASPA-объекта, проверка BGP-апстримов и история изменений
Что нужно для полного внедрения ASPA
ASPA — это криптографический фундамент для валидации путей. Но, как показал опыт RPKI/ROA, внедрение займёт время. Необходимы обновления:
- RPKI Relying Party (RP) — программы проверки криптографических записей
- RTR (RPKI-to-Router protocol) — протокол передачи данных маршрутизаторам
- BGP-реализации на маршрутизаторах — для валидации путей с использованием ASPA
Помимо создания ASPA-записей, операторам рекомендуется настроить BGP roles (RFC 9234). BGP roles привязывают предполагаемые отношения между AS к конкретным BGP-сессиям, помогая ASPA определить, какой алгоритм валидации применять — для апстрима или даунстрима. Уточните у своих вендоров оборудования, поддерживают ли они BGP roles и атрибут OTC (Only-to-Customer).
Управление ASPA-записями не отличается от управления ROA. В будущем, когда сети начнут активно блокировать невалидные пути, пропуск легитимного провайдера может привести к потере трафика. Но это тот же риск, который операторы уже научились контролировать.
Часто задаваемые вопросы
Чем ASPA отличается от ROA?
ROA (Route Origin Authorization) проверяет пункт назначения трафика — авторизована ли конкретная AS анонсировать IP-адреса. ASPA проверяет путь — цепочку сетей, через которые трафик проходит. ROA защищает от origin hijacks, ASPA — от утечек маршрутов (route leaks) и forged-origin hijacks.
Что такое утечка маршрута (route leak)?
Утечка маршрута — это когда трафик направляется через сеть, через которую не должен проходить. Типичный случай: клиентская сеть получает маршрут от одного провайдера и перенаправляет его другому провайдеру, становясь нежелательным транзитным звеном между двумя крупными сетями.
Как проверить внедрение ASPA в моей сети?
Cloudflare Radar предоставляет мониторинг внедрения ASPA: можно проверить, есть ли ASPA-запись для конкретной AS, увидеть историю изменений и сравнить BGP-апстримы с авторизованными провайдерами.
Защищает ли ASPA от всех типов атак на BGP?
Нет. ASPA эффективен против утечек маршрутов и большинства forged-origin hijacks, но не защищает от случаев, когда провайдер подделывает пиринговый линк. ASPA работает только с информацией о провайдерских отношениях и не знает о пиринге.
Выводы
ASPA — следующий логичный шаг в безопасности интернет-маршрутизации после RPKI/ROA. Если ROA закрепил за каждой AS право анонсировать свои IP-адреса, то ASPA закрепляет право на транзит — описывает авторизованный путь трафика.
Для операторов сетей: проверьте в Cloudflare Radar, есть ли у вашей AS ASPA-запись, и создайте её в RIPE или ARIN. Чем больше сетей подпишут ASPA, тем быстрее стандарт начнёт реально блокировать утечки маршрутов.
