ASPA и утечки маршрутов: как новый стандарт проверяет путь трафика

Интернет ломается не только из-за обрывов кабеля, пожаров в дата-центрах и неудачных обновлений. Иногда хватает одной кривой BGP-настройки, чтобы чужие маршруты внезапно поехали не туда. Пользователь видит странные задержки, потери пакетов или частичную недоступность сервисов. Сетевой инженер открывает таблицы маршрутизации и обнаруживает старую знакомую проблему: путь в BGP выглядит правдоподобно ровно до первого неприятного сюрприза.

ASPA, Autonomous System Provider Authorization, появился как попытка закрыть именно этот класс сбоев. Механизм не проверяет физический путь пакетов по проводам и не строит «истинную карту интернета». ASPA работает с контрольной плоскостью BGP и отвечает на более узкий вопрос: выглядит ли цепочка AS в AS_PATH правдоподобной с точки зрения отношений «клиент-провайдер». Разница не косметическая. Вокруг ASPA уже накопилось слишком много формулировок в духе «проверяет путь трафика», а дальше начинаются ложные ожидания.

По состоянию на май 2026 года ASPA остается не опубликованным RFC, а зрелым набором черновиков IETF SIDROPS. Профиль объекта ASPA и правила проверки AS_PATH уже хорошо оформлены, вокруг них есть рабочие реализации и реальный опыт внедрения, но называть механизм завершенным стандартом пока рано. Текст от такой осторожности только выигрывает: инженерная тема любит точные слова.

Почему BGP до сих пор спотыкается на утечках маршрутов

BGP прекрасно масштабируется, но исторически плохо умеет проверять смысл межоператорских отношений. Сам протокол не знает, какой сосед для кого клиент, какой сосед провайдер, а какой просто пир на точке обмена трафиком. Маршрутизатор получает AS_PATH и видит последовательность автономных систем, но без дополнительного контекста не понимает, нормальный перед ним путь или сосед отдал маршрут туда, куда отдавать не следовало.

На практике утечка маршрута часто выглядит куда прозаичнее, чем в презентациях про «глобальные сбои интернета». Допустим, AS C получила маршрут к префиксу от своего провайдера AS B. Дальше AS C по ошибке отдает тот же маршрут другому провайдеру AS D, хотя экспортная политика такого не допускает. Для AS D путь может выглядеть достижимым и даже удобным, но топологически перед нами уже неправильный транзит. Чужой маршрут внезапно оказывается там, где его не ждали.

Именно здесь многие впервые вспоминают про RPKI и ROA, а потом быстро понимают, что одной проверки origin мало. Если исходный AS у префикса объявлен легитимно, ROA не видит дальнейшую судьбу маршрута. Для route leak такого контроля недостаточно. Нужен отдельный механизм, который смотрит не только на начало маршрута, но и на правдоподобность самой AS-цепочки.

Что такое ASPA и что именно автономная система подписывает

ASPA можно читать как короткое подписанное заявление клиента о своих допустимых провайдерах. Не о всех соседях вообще, а именно о тех автономных системах, через которые клиент вправе получать транзит и которые могут законно появляться над ним в маршруте. Если убрать формулировки спецификации, остается почти бухгалтерская запись: «для AS X допустимы провайдеры Y и Z».

Здесь и кроется главный архитектурный ход. ASPA не пытается хранить весь граф интернета. Механизм складывается из множества локальных утверждений, которые создают сами владельцы AS. Поэтому ASPA не просит подписывать каждый BGP UPDATE и не пытается криптографически доказать весь путь hop-by-hop. Задача скромнее: дать проверяющему достаточно данных, чтобы заметить неправдоподобные customer-to-provider переходы в AS_PATH.

Из такого дизайна вытекает важное ограничение. В ASPA публикуют провайдеров, а не пиров и не клиентов. Если у соседа сложные отношения и сосед иногда выступает провайдером, такой сосед должен быть включен как провайдер. Если роль провайдера отсутствует, включать lateral peers и customers в ASPA нельзя: запись начнет размывать смысл проверки. Для сетей без провайдеров существует отдельный вариант, AS0 ASPA. Запись с единственным провайдером AS0 означает, что сеть не использует транзитных провайдеров, а не просто забыла опубликовать объект.

Как ASPA проверяет AS_PATH и почему важна valley-free логика

Нормальный междоменный маршрут чаще всего подчиняется valley-free логике, хотя сам термин можно и не произносить. Маршрут поднимается от клиентов к провайдерам, в верхней точке может встретить общий транзит или соседний пиринг, а затем спускается вниз к клиентам. Путь, который идет вверх, потом вниз, а затем снова вверх, выглядит подозрительно. Обычно такой рельеф указывает на route leak или на неправдоподобный фрагмент AS_PATH.

Проверка ASPA как раз пытается найти максимально длинные допустимые участки такого «подъема» и «спуска». Если допустимые отрезки не покрывают путь целиком, маршрут можно признать invalid. Если данных по части соседей нет, получается unknown. Если цепочка полностью укладывается в подписанные customer-to-provider отношения, проверка возвращает valid. Ключевая деталь здесь в том, что unknown не равен valid. Unknown означает не «все подтверждено», а «данных недостаточно, чтобы доказать некорректность».

Дальше уже вступает в дело политика оператора. Проект verification draft рекомендует считать invalid непригодным для выбора маршрута, но не выкидывать запись из Adj-RIB-In, чтобы оставить возможность последующей переоценки. Для unknown рекомендация мягче: не понижать такой маршрут относительно valid. Причина простая. При неполном охвате ASPA слишком жесткое обращение с unknown быстро ломает связность и превращает защиту в источник аварий.

Чем ASPA отличается от ROA, OTC и BGPsec

Путаница обычно начинается в тот момент, когда все механизмы маршрутной безопасности пытаются описать одной фразой. У каждого своя задача. ROA и origin validation проверяют, имеет ли конкретный AS право объявлять префикс как источник. ASPA работает уровнем выше и оценивает правдоподобность AS_PATH через отношения «клиент-провайдер». RFC 9234 с ролями BGP и атрибутом OTC решает соседнюю, но не тождественную задачу: помогает не передавать маршрут дальше за пределы допустимого экспортного контура.

OTC, Only to Customer, полезно описывать не абстрактно, а по-человечески. Маршрут получает признак, который говорит соседу: дальше такой маршрут допустимо передавать только клиентам. В паре с явно согласованными BGP roles такой подход хорошо ловит часть утечек уже на стадии распространения маршрута. ASPA и OTC поэтому не конкуренты, а дополняющие инструменты. Сам draft verification прямо рекомендует использовать RFC 9234 рядом с ASPA, а не вместо него.

BGPsec стоит особняком. Механизм куда тяжелее и защищает сам путь AS через подписи на распространении UPDATE. На бумаге защита сильнее. На практике внедрение сложнее, требования к инфраструктуре выше, а распространение заметно скромнее. ASPA занимает промежуточную позицию: не обещает полного криптографического доказательства пути, зато заметно дешевле по операционной цене и закрывает важный класс route leaks и некоторых path manipulations.

Где ASPA помогает хорошо, а где быстро упирается в ограничения

Сильнее всего ASPA выглядит там, где источник маршрута легитимен, а проблема начинается позже, на этапе распространения. Ровно такие случаи годами и мучили операторов. Формально все похоже на нормальный анонс, а топология уже поехала в сторону. Для таких утечек ASPA действительно полезен. Механизм также усложняет некоторые варианты path spoofing и forged-path-segment hijack, хотя обещать полную защиту здесь было бы нечестно.

Главное ограничение связано с частичным внедрением. Если часть AS в маршруте не публикует ASPA, проверка чаще заканчивается статусом unknown, а не valid или invalid. Польза от ASPA поэтому нелинейна. На малом охвате механизм уже может ловить явные ошибки, но полноценный эффект растет по мере того, как записи появляются у все большего числа участников по пути. Именно поэтому вокруг ASPA так много разговоров про экосистему, а не только про сами драфты.

Есть и чисто операционные сложности. Сложные отношения с соседями, несимметричный IPv4 и IPv6 транзит, неочевидные роли route server, миграция между ASN, резервные апстримы на случай аварии, мультихоминг с двумя и более провайдерами - все это нужно описывать аккуратно. Для обычного multihoming ответ простой: в ASPA надо включить всех реальных провайдеров, через которых AS вправе отправлять маршруты вверх. Но простота формулы не отменяет необходимости держать запись в актуальном состоянии.

Что с ASPA на практике в 2026 году

Самое важное уточнение здесь простое. ASPA в апреле 2026 года - не RFC, а активная работа IETF SIDROPS. У profile draft и verification draft есть привязка к milestone с отправкой в IESG, но в Datatracker оба документа по-прежнему видны как Internet-Draft. Для инженерной статьи такой нюанс нельзя замазывать словами «стандарт уже почти принят», потому что у сетевой аудитории на такие вещи глаз набит.

При этом механизм давно вышел из стадии чистой теории. RIPE уже дал публичную документацию и интерфейсы для работы с ASPA. ARIN включил ASPA в ARIN Online. APNIC публично писал, что планирует развернуть поддержку к концу второго квартала 2026 года. Значит, на стороне регистратур движение идет вполне предметно. Для оператора вопрос уже не «существует ли ASPA вообще», а «готова ли моя операционная модель поддерживать еще один объект в RPKI без хаоса».

На стороне инструментов картина тоже стала взрослее. Routinator умеет обрабатывать ASPA и отдавать данные через RTR, JSON и JSONext, если включить поддержку явно. BIRD документирует `aspa_check_downstream`, `aspa_check_upstream` и общий `aspa_check`, так что ASPA уже можно использовать в фильтрах. Но наличие функций в валидаторе и программном маршрутизаторе еще не означает массового включения по всей отрасли. От готовности к аккуратной эксплуатации до реального охвата всегда длиннее путь, чем кажется по презентациям.

Как внедрять ASPA без самообмана

Самообман в таких проектах обычно начинается с фразы «сейчас быстро подпишем и станем безопаснее». ASPA не любит спешку. Неполная или неряшливая запись может навредить быстрее, чем полное отсутствие ASPA. Если забыть реального провайдера, маршруты через такого апстрима начнут выглядеть подозрительно. Если добавить лишних соседей «на всякий случай», защита ослабнет и перестанет ловить часть плохих путей.

Нормальный порядок действий скучный, а потому правильный. Сначала собрать реальную карту провайдеров по каждой AS, включая резервные и редкие сценарии. Затем опубликовать ASPA и синхронизировать обслуживание записей с изменениями контрактов и конфигураций. После этого проверить, что RPKI-валидатор, RTR-контур и маршрутизаторы действительно получают и используют новые данные. И только потом включать политику принятия маршрутов, начиная с журналирования и мягких действий по invalid.

Сразу жестко рубить все invalid на живой сети без периода наблюдения - плохая идея. Правильнее сначала смотреть, какие маршруты получают такой статус и почему. Параллельно стоит включать BGP roles и OTC там, где инфраструктура уже умеет RFC 9234. ASPA лучше воспринимать не как волшебный рубильник, а как еще один слой маршрутной гигиены. Работает не громко, зато полезно.

FAQ

ASPA заменяет ROA?

Нет. ROA отвечает на вопрос, какой origin AS вправе объявлять префикс. ASPA отвечает на другой вопрос: правдоподобна ли цепочка провайдеров в AS_PATH. Один механизм без другого оставляет заметные дыры. Вместе связка выглядит куда сильнее, чем по отдельности.

Если говорить совсем коротко, ROA проверяет начало истории маршрута, а ASPA проверяет, не испортили ли историю по дороге. Подменять один механизм другим не стоит.

Почему ASPA не публикует пиринговые отношения?

Потому что логика проверки строится вокруг customer-to-provider attestations. Механизм должен понимать, кто для кого допустимый провайдер. Пиринги учитываются косвенно в алгоритме проверки «долины», но не как основной тип записи внутри самого ASPA-объекта.

Если в запись начать массово добавлять peers и customers, проверка потеряет остроту. Исключения бывают только там, где у соседа есть сложная роль с провайдерской компонентой или в игру входит non-transparent route server.

Что происходит при частичном внедрении?

Чаще всего маршрут получает статус unknown. Такой исход не означает, что путь хороший. Такой исход означает, что данных недостаточно, чтобы его признать invalid или fully valid. Поэтому в драфте и рекомендуют относиться к unknown мягко, иначе сеть сама себе устроит отказ в обслуживании.

Из-за этого эффект ASPA на старте почти всегда фрагментарный. Механизм начинает ловить часть явных проблем сразу, но по-настоящему раскрывается только там, где охват подписанными отношениями становится заметным.

Подходит ли ASPA для обычного multihoming?

Да, и именно здесь механизм особенно полезен. Если автономная система подключена к двум или трем провайдерам, в ASPA нужно перечислить всех провайдеров, через которых сеть вправе поднимать маршруты вверх. С точки зрения модели такой случай обычный, а не экзотический.

Сложность не в самой схеме, а в дисциплине сопровождения. Резервный апстрим, который годами молчит, а потом включается во время инцидента, должен быть в записи заранее. Иначе первая же авария превратится в спор с собственным ASPA.

Главный практический вывод для оператора?

ASPA закрывает не весь BGP, а конкретный и болезненный класс ошибок и атак вокруг AS_PATH. Польза реальна, но не автоматическая. Успех зависит не от красивого названия механизма, а от трех скучных вещей: точных ASPA-записей, поддержки валидаторов и аккуратной политики на eBGP-входе.

Если смотреть на ASPA именно так, без лишнего пафоса и без обещаний «полной защиты интернета», механизм выглядит убедительно. Для маршрутной безопасности иногда и не нужно больше.