ASPA: Как криптография защищает маршруты интернет-трафика

Интернет-трафик полагается на протокол BGP (Border Gateway Protocol), чтобы находить путь между сетями. Однако этот трафик иногда может быть направлен неверно из-за ошибок конфигурации или злонамеренных действий. Когда трафик проходит через сети, через которые он не должен был проходить, это называется утечкой маршрутов. Мы неоднократно писали в нашем блоге об утечках маршрутов BGP и их влиянии на маршрутизацию в Интернете, и несколько раз даже намекали на будущее с проверкой путей в BGP.

Хотя сетевое сообщество достигло значительного прогресса в проверке конечного пункта назначения интернет-трафика, обеспечение безопасности самого пути, который он проходит, остается ключевой задачей для поддержания надежного Интернета. Для решения этой проблемы отрасль внедряет новый криптографический стандарт под названием ASPA (Авторизация Поставщика Автономной Системы), который предназначен для проверки всего пути сетевого трафика и предотвращения утечек маршрутов.

Чтобы помочь сообществу отслеживать внедрение этого стандарта, Cloudflare Radar представил новую функцию мониторинга развертывания ASPA. Это представление позволяет пользователям наблюдать за тенденциями внедрения ASPA с течением времени в пяти региональных интернет-регистратурах (RIR), а также просматривать записи ASPA и их изменения на уровне Автономной Системы (AS).

Чтобы понять, как работает ASPA, полезно взглянуть на то, как Интернет в настоящее время обеспечивает безопасность пунктов назначения трафика.

Сегодня сети используют безопасную инфраструктурную систему под названием RPKI (Инфраструктура Открытых Ключей Ресурсов), развертывание которой значительно выросло за последние годы. В рамках RPKI сети публикуют специальные криптографические записи, называемые ROA (Авторизация Исхода Маршрута). ROA действует как проверяемое цифровое удостоверение, подтверждая, что Автономная Система (AS) официально уполномочена анонсировать конкретные IP-адреса. Это решает проблему "перехвата происхождения" (origin hijack), когда одна сеть пытается выдать себя за другую.

ASPA (Авторизация Поставщика Автономной Системы) напрямую строится на этой основе. В то время как ROA проверяет пункт назначения, запись ASPA проверяет путь.

Когда данные перемещаются по Интернету, они ведут текущий журнал каждой сети, через которую проходят. В BGP этот журнал известен как AS_PATH (Путь Автономной Системы). ASPA предоставляет сетям способ официально опубликовать в системе RPKI список своих авторизованных вышестоящих поставщиков. Это позволяет любой принимающей сети просмотреть AS_PATH, проверить связанные записи ASPA и убедиться, что трафик прошел только через утвержденную цепочку сетей.

ROA помогает убедиться, что трафик прибывает в правильный пункт назначения, а ASPA гарантирует, что трафик следует по намеченному, авторизованному маршруту, чтобы попасть туда. Давайте посмотрим, как на практике работает оценка пути.

Как ASPA определяет, является ли маршрут обходным путем? Она полагается на иерархию Интернета.

В здоровой топологии маршрутизации Интернета (например, «беспропастной» (valley-free) маршрутизации), трафик, как правило, следует определенному пути: он движется «вверх» от клиента к крупному провайдеру (например, крупному ISP), при необходимости переходит к другому крупному провайдеру, а затем спускается «вниз» к пункту назначения. Это можно визуализировать как форму «горы»:

1. Подъем: Трафик начинается у Клиента и движется «вверх» через все более крупных Поставщиков (ISP), где ISP платят другим ISP за транзит их трафика.

2. Вершина: Он достигает верхнего уровня магистрали Интернета и может пересечь одно пиринговое соединение.

Спуск: Он движется «вниз» через поставщиков, чтобы достичь Клиента-получателя.

^{Визуализация «беспропастной» (valley-free) маршрутизации. Маршруты распространяются вверх к поставщику, при необходимости через одно пиринговое соединение, и вниз к клиенту.}

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

Такое движение «вниз-вверх» нежелательно, поскольку клиенты не предназначены и не оборудованы для транзита трафика между двумя более крупными сетевыми провайдерами.

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

ASPA проверяет пути AS, анализируя «цепочку отношений» с обоих концов распространения маршрутов:

• Проверка подъема: Проверка начинается у источника и движется вперед. На каждом переходе задается вопрос: «Авторизовала ли эта сеть следующую сеть в качестве Поставщика?» Она продолжается до тех пор, пока цепочка не остановится.

• Проверка спуска: То же самое делается с конца обновления BGP, двигаясь назад.

Если «восходящий» путь и «нисходящий» путь пересекаются или встречаются наверху, маршрут считается Действительным. Форма горы сохранена.

Однако, если два действительных пути не встречаются, т.е. в середине есть разрыв, где авторизация отсутствует или недействительна, ASPA отмечает такие пути как проблемные. Этот разрыв представляет собой «пропасть» или утечку.

Давайте рассмотрим сценарий, в котором сеть (AS65539) получает плохой маршрут от клиента (AS65538).

Клиент (AS65538) пытается отправить трафик, полученный от одного поставщика (AS65537), «вверх» другому поставщику (AS65538), выступая в роли моста между провайдерами. Это классическая утечка маршрута. Теперь пройдемся по процессу проверки ASPA.

1. Проверяем подъем: Исходный источник (AS65536) авторизует своего поставщика. (Проверка пройдена).

2. Проверяем спуск: Начинаем с пункта назначения и смотрим назад. Мы видим клиента (AS65538).

3. Несоответствие: Подъем заканчивается на AS65537, а спуск заканчивается на AS65538. Два склона не соединяются.

Поскольку «восходящий» и «нисходящий» пути не соединяются, система помечает это как Недействительный результат проверки ASPA. ASPA требуется выполнять эту проверку пути, так как без подписанных объектов ASPA в RPKI мы не можем определить, какие сети уполномочены анонсировать какие префиксы кому. Подписывая список сетей-поставщиков для каждой AS, мы узнаем, какие сети должны иметь возможность распространять префиксы по горизонтали или вверх по течению.

ASPA может служить эффективной защитой от поддельных перехватов происхождения (forged-origin hijacks), когда злоумышленник обходит Проверку Происхождения Маршрута (ROV), притворяясь и анонсируя путь BGP к реальному префиксу происхождения. Хотя исходная AS остается правильной, отношения между злоумышленником и жертвой являются сфабрикованными.

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

Однако ASPA не может полностью защитить от поддельных перехватов происхождения. Все еще существует по крайней мере один случай, когда даже проверка ASPA не может полностью предотвратить такую атаку на сеть. Примером поддельного перехвата происхождения, который ASPA не может учесть, является ситуация, когда поставщик подделывает анонс маршрута своему клиенту.

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

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

Создание объекта ASPA для вашей сети (или автономной системы) теперь стало простым процессом в реестрах, таких как RIPE и ARIN. Всё, что вам нужно, — это номер вашей AS и номера AS провайдеров, у которых вы покупаете услугу интернет-транзита. Это авторизованные вышестоящие сети, которым вы доверяете анонсировать ваши IP-адреса в глобальный Интернет. В обратном направлении, это также сети, которым вы разрешаете отправлять вам полную таблицу маршрутизации, которая служит полной картой того, как достичь остальной части Интернета.

Мы хотели бы показать вам, насколько просто создать объект ASPA, на быстром примере.

Допустим, нам нужно создать объект ASPA для AS203898 — AS, которую мы используем для интернета в нашем лондонском офисе Cloudflare. На момент написания у нас есть три интернет-провайдера для офиса: AS8220, AS2860 и AS1273. Это означает, что мы создадим объект ASPA для AS203898 с этими тремя провайдерами в списке.

Сначала мы входим в RPKI-панель RIPE и переходим в раздел ASPA:

Затем мы нажимаем «Create ASPA» для объекта, для которого хотим создать ASPA. После этого нам остаётся только заполнить поля с провайдерами для этой AS.

Всё просто. После короткого периода ожидания мы можем запросить глобальную экосистему RPKI и найти наш объект ASPA для AS203898 с определёнными нами провайдерами.

Аналогичная история с ARIN — единственным другим Региональным интернет-реестром (RIR), который в настоящее время поддерживает создание объектов ASPA. Войдите в ARIN Online, затем перейдите в раздел «Routing Security» и нажмите «Manage RPKI».

Оттуда вы сможете нажать «Create ASPA». В этом примере мы создадим объект для ещё одного нашего номера AS — AS400095.

И всё — теперь мы создали наш объект ASPA для AS40095 с провайдером AS0.

Запись провайдера «AS0» является особой при использовании и означает, что владелец AS заявляет, что для его сети нет действительных вышестоящих провайдеров. По определению это означает, что каждая транзитно-независимая сеть уровня Tier-1 в конечном итоге должна подписать ASPA только с «AS0» в своём объекте, если у неё действительно есть только отношения пиринга и клиентов.

Мы добавили новую функцию мониторинга развёртывания ASPA в Cloudflare Radar. Новое представление развёртывания ASPA позволяет пользователям изучать рост внедрения ASPA с течением времени, с возможностью визуализировать тенденции по всем пяти Региональным интернет-реестрам (RIR) на основе регистрации AS.

Мы также интегрировали данные ASPA непосредственно на страницы маршрутизации по странам/регионам и ASN. Теперь пользователи могут отслеживать, как различные локации продвигаются в защите своей инфраструктуры, на основе связанных записей ASPA от зарегистрированных локально ASN клиентов.

Также появились новые функции, когда вы детализируете конкретную Автономную систему (AS), например, AS203898.

Мы можем видеть, являются ли наблюдаемые вышестоящие BGP-провайдеры сети авторизованными по ASPA, их полный список провайдеров в объекте ASPA и хронологию изменений ASPA, затрагивающих их AS.

Теперь, когда ASPA наконец становится реальностью, у нас есть криптографическое обновление для проверки интернет-путей. Однако те, кто был с самого начала RPKI для проверки происхождения маршрутов, знают, что это будет долгий путь к реальному предоставлению значимой ценности в Интернете. Чтобы фактически использовать объекты ASPA и проверять пути с их помощью, необходимы изменения в пакетах Relying Party (RP) RPKI, реализациях подписывающих сторон, программном обеспечении RTR (RPKI-to-Router protocol) и реализациях BGP.

Помимо внедрения ASPA, операторам также следует настроить роли BGP, как описано в RFC9234. Роли BGP, настроенные на сессиях BGP, помогут будущим реализациям ASPA на маршрутизаторах решить, какой алгоритм применять: upstream (вышестоящий) или downstream (нижестоящий). Другими словами, роли BGP дают нам, как операторам, возможность напрямую привязать наши предполагаемые BGP-отношения с другой AS к сессиям с этими соседями. Уточните у ваших вендоров маршрутизации, поддерживают ли они реализацию ролей BGP RFC9234 и атрибута OTC (Only-to-Customer, «только для клиентов»).