Утечка маршрутов Telekom Malaysia в 2015 году: урок подотчётности

Кратко

Независимый мониторинг относит начало масштабной серии BGP-анонсов из AS4788 компании Telekom Malaysia примерно к 08:43 UTC 12 июня 2015 года. BGPMon сообщил примерно о 179 000 анонсированных префиксов, а RFC 7908 впоследствии называл это событие крупным примером утечки маршрутов, когда Level 3 приняла и распространила около 179 000 префиксов. [2][10]
В разных анализах приводятся разные количества маршрутов, потому что используются разные коллекторы, временные окна и определения. В анализе Джеффа Хьюстона говорилось примерно о 2500 новых видимых маршрутах и рассматривался набор из 22 577 затронутых маршрутов. Сводить эти цифры в одну ложную точность нельзя. [1][2]
AS3549 компании Level 3 не просто наблюдала анонсы от AS4788. Она приняла и распространила их, расширив радиус поражения через крупную глобальную транзитную сеть. ThousandEyes зафиксировала серьёзные потери пакетов и тупиковые маршруты в нескольких точках присутствия Level 3. [2][3]
Свидетельства указывают на утечку, связанную с нарушением политики взаимоотношений: маршруты, полученные от пиров, по-видимому, были повторно анонсированы в сторону вышестоящих транзитных провайдеров. Точная конфигурация маршрутизатора Telekom Malaysia, route map, команда, ПО и цепочка согласований в этом пакете материалов не раскрыты. [1]
Ответственность распределена по границам контроля. AS4788 контролировала свою экспортную политику и жизненный цикл route map. AS3549 контролировала, что принимается от клиента, какие проверки объёма и путей применяются и распространяются ли принятые маршруты. Нижестоящие сети контролировали собственную импортную политику и мониторинг.
Обычная проверка источника маршрута в RPKI не даёт полного ответа на это событие. Большинство утёкших путей сохраняли легитимные источники. Авторизация источника может быть действительной, даже если путь нарушает экспортные намерения клиента, пира или провайдера. [1][15][16]
Более поздние стандарты уточняют возможные средства контроля. RFC 8212 делает явную импортную и экспортную политику требованием по умолчанию для eBGP, а RFC 9234 добавляет учитывающие взаимоотношения роли BGP и атрибут Only to Customer. Это ретроспективные рекомендации по контролю, а не доказательство нарушения требований в 2015 году. [11][12]
Достоверное заявление об устранении требует большего, чем восстановление. Нужна зафиксированная реконструкция набора анонсов, целевая политика сессии, доказательства конфигурации до и после, тесты против того же класса утечек, независимое наблюдение за маршрутами и доказательство того, что и экспортирующая, и принимающая стороны могут сдержать повторение.

Анонс маршрута стал полномочием распоряжаться чужим трафиком

BGP часто представляют как протокол, который сообщает интернету, где находятся сети. Это описание точное, но неполное. Анонс BGP — это ещё и заявка на операционные полномочия.

Когда одна автономная система сообщает другой, что через неё достижим префикс, получатель может предпочесть этот путь и анонсировать его дальше. Другие сети затем могут направлять трафик по этому анонсированному пути. Маршрут не несёт гарантии, что анонсирующая сеть имеет достаточную ёмкость, что путь соответствует коммерческим взаимоотношениям или что каждый промежуточный оператор намеревался предоставлять транзит. BGP распространяет информацию о достижимости и данные о пути AS; политика определяет, какие заявления сеть принимает и повторяет. [8]

Именно на уровне этой политики событие 2015 года с Telekom Malaysia приобрело глобальные последствия.

Независимые источники сообщают, что масштабная серия анонсов началась примерно в 08:43 UTC 12 июня. AS4788 компании Telekom Malaysia анонсировала в AS3549 компании Level 3 огромный набор маршрутов. Level 3 приняла эти маршруты и распространила их среди пиров и клиентов. Трафик пошёл по изменившимся путям. Путь через AS3549 и AS4788 мог выглядеть привлекательным с точки зрения политики маршрутизации, хотя соединения не могли безопасно выдержать возникший объём. Потери пакетов и задержки выросли, а сервисы далеко за пределами собственной клиентской базы Telekom Malaysia стали труднодостижимыми или вовсе недоступными. [2][3]

Это событие не было поддельным сертификатом, компрометацией доменного имени или сфабрикованным источником маршрута в простейшем смысле. Многие затронутые префиксы по-прежнему заканчивались на своих легитимных исходных автономных системах. Вредное изменение состояло в том, что AS4788 вставила себя в транзит для маршрутов, которые не должна была экспортировать в этом направлении. Путь может быть синтаксически корректным, свободным от петель и валидным по источнику, но при этом нарушать экономические и операционные взаимоотношения, в рамках которых он был получен.

Это различие важно для подотчётности. Если проблему описывать только как «Telekom Malaysia утекла маршруты», ответственность будто заканчивается на экспортирующей сети. Но распространение BGP на каждой сессии двустороннее. Одна сторона анонсирует; другая решает, что принимать, чему отдавать предпочтение и что анонсировать дальше. Крупная транзитная сеть обладает большей силой распространения, чем отдельный клиент. Эта сила порождает соответствующую обязанность фильтрации и сбора доказательств.

Главный вопрос не в том, какой оператор первым допустил ошибку. А в том, сколько независимых средств контроля практически могли остановить ошибку до того, как она стала сбоем других сетей.

Хронология ясна снаружи и неполна внутри сетей

BGPMon сообщил, что AS4788 начала анонсировать огромный набор маршрутов в 08:43 UTC. Его мониторинг зафиксировал резкий рост сообщений BGP UPDATE в то же время, когда начались потери пакетов. В анализе говорилось примерно о 179 000 анонсированных префиксах; в качестве примера пути, который проходил через AS3549 и AS4788, прежде чем достичь легитимного источника, приводился затронутый префикс Facebook. [2]

ThousandEyes независимо описала ту же общую последовательность. Она наблюдала новые пути через Telekom Malaysia и Level 3, серьёзные потери пакетов и тупиковые маршруты в локациях, включая Амстердам, Чикаго, Франкфурт, Лондон, Лос-Анджелес, Сиэтл и Вашингтон. По её данным, Level 3 перестала принимать маршруты примерно в 10:45 UTC, и сервисы начали возвращаться к норме. [3]

BGPMon сообщил об улучшении около 10:40 и о более широком очищении к 11:15. Эти временные метки должны оставаться привязанными к источнику. Коллектор маршрутов, платформа активных измерений, транзитный оператор и конечный пользователь наблюдают одно и то же событие не в один и тот же момент. Фильтр может остановить новые анонсы, в то время как устаревшие пути остаются выбранными в других местах. Отзывы маршрутов могут распространяться неравномерно. Перегрузка может сохраняться после того, как триггер на уровне управления удалён. Поэтому восстановление — это последовательность, а не один универсальный момент времени.

Позже анализ на основе RIPE Atlas использовал это событие для изучения того, как крупные сбои в базовой инфраструктуре влияют на сквозную связность. Были найдены свидетельства и обхода трафиком инфраструктуры, находящейся под нагрузкой, и сквозных отказов. Авторы прямо говорили о репрезентативности: даже разнообразная глобальная система измерений наблюдает лишь конечный набор путей и пунктов назначения. [4]

Публичная хронология опирается на сильную внешнюю фиксацию и слабую внутреннюю.

Внешние наблюдатели могут определить примерное начало, изменившиеся пути, объём обновлений маршрутов, потери пакетов, задержки и общее восстановление. Они не видят приватную route map, терминал оператора, согласованное изменение, настроенный лимит префиксов, очередь алертов или разговор о решении между Telekom Malaysia и Level 3.

Этот пробел должен определять формулировки статьи.

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

В анализе Джеффа Хьюстона используется вероятностная формулировка о сбое политики маршрутизации, а в некоторых местах встречаются, по-видимому, опечатки в номерах AS. Сеть Telekom Malaysia — это AS4788. Статья не должна превращать упоминания AS4877 или AS4778 в дополнительных участников или использовать их для создания ложной определённости о внутреннем устройстве. [1]

Полная запись подотчётности связала бы внешнюю хронологию с внутренними доказательствами:

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

Без такой цепочки восстановление видно, но институциональное обучение трудно проверить.

Количество префиксов отражает разные точки наблюдения, а не один спорный факт

Крупные интернет-инциденты притягивают одно запоминающееся число. Здесь этот инстинкт может сделать картину менее точной.

BGPMon писал, что AS4788 начала анонсировать около 179 000 префиксов, а позже упоминал примерно 176 000 утёкших префиксов. В RFC 7908 говорится о «масштабной утечке маршрутов Telekom Malaysia» объёмом около 179 000 префиксов. ThousandEyes описывала большую часть глобальной таблицы маршрутизации. [2][3][10]

Анализ Хьюстона использовал другие точки наблюдения. Он показал чистое изменение таблицы маршрутизации, включающее тысячи новых видимых и отозванных маршрутов, а затем рассмотрел 22 577 маршрутов в конкретном затронутом наборе. [1]

Эти цифры могут сосуществовать, потому что у события BGP нет единственной естественной единицы измерения.

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

Ответственный редакционный выбор — сохранять определение измерения.

Статья может говорить, что BGPMon и RFC 7908 в своих реконструкциях описывали примерно 179 000 утёкших анонсов или префиксов. Можно сказать, что отдельный анализ Хьюстона рассматривал набор из 22 577 маршрутов и наблюдал тысячи добавлений и отзывов в таблице. Не следует усреднять значения, выбирать наибольшее ради драматизма или выдавать одно из них за полную перепись последствий для пользователей.

Та же дисциплина относится к затронутым сервисам. BGPMon и ThousandEyes привели примеры, связанные с крупными платформами и финансовыми сервисами. Эти примеры показывают масштаб и сопутствующие эффекты. Они не доказывают, что каждый префикс испытывал одинаковые потери пакетов, каждый сервис стал недоступен или каждый пользователь маршрутизировался через AS4788.

Цифры становятся доказательством подотчётности, когда сохраняются их определения:

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

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

Ложная точность — это не только проблема стиля. Она может скрыть, какой контроль отказал.

Политика взаимоотношений — невидимая структура, стоящая за достижимостью BGP

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

Упрощённое операционное правило выглядит так:

маршруты, полученные от клиентов, могут анонсироваться клиентам, пирам и провайдерам;
маршруты, полученные от пиров, могут анонсироваться клиентам, но обычно не другому пиру или провайдеру;
маршруты, полученные от провайдеров, могут анонсироваться клиентам, но обычно не другому провайдеру или пиру.

Эти правила дают знакомую модель «без долин». Путь может подниматься от клиентов к провайдерам, пересекать не более одного пирингового отношения и спускаться к клиентам. Путь, который сначала спускается, а затем снова поднимается, может указывать на то, что сеть предоставляет непредусмотренный транзит. [1][10]

Реальные коммерческие взаимоотношения сложнее. Две сети могут играть разные роли в разных местах, семействах адресов или сервисах. Частичный транзит, платный пиринг, route servers и региональные договорённости не всегда укладываются в один ярлык. Эта сложность — причина документировать и тестировать политику, а не опускать её.

Реконструкция Хьюстона говорит, что AS4788, по-видимому, собирала маршруты от пиров на точках обмена и повторно анонсировала их вышестоящим транзитным сетям. В этой модели маршруты, полученные «сбоку», экспортировались «вверх». Level 3 затем приняла и распространила эти пути. [1]

Сам протокол не может вывести все частные коммерческие взаимоотношения из пути AS. Последовательность легитимных номеров AS не говорит, разрешалось ли маршруту контрактно и операционно проходить через них. Эти знания должны быть закодированы в локальной политике, опубликованных routing Субъект-ах, согласованных ролях, communities, данных о клиентском конусе или другой системе валидации.

Именно поэтому утечки маршрутов остаются сложной проблемой. Маршрутизатор может получить валидное сообщение BGP UPDATE от аутентифицированного соседа, увидеть легитимный источник, построить свободный от петель путь AS и всё равно принять маршрут, нарушающий предполагаемые взаимоотношения.

Операционная подотчётность поэтому требует, чтобы сети делали свои ожидания машинно проверяемыми там, где это возможно:

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

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

AS4788 контролировала экспорт, но AS3549 контролировала приём и распространение

Telekom Malaysia обладала самым прямым контролем над набором анонсов, покинувших AS4788. Экспортирующая сеть должна знать, какие маршруты она сама анонсирует как источник, какие получила от клиентов, какие — от пиров или провайдеров, и какие классы можно отправлять каждому соседу.

Этот контроль начинается до активации конфигурации.

Изменение должно компилироваться в фактическую политику префиксов и путей AS, которую будет исполнять маршрутизатор. Ревью должно сравнивать результат с ожидаемыми клиентскими конусами, количеством маршрутов и правилами взаимоотношений. Тестовая среда или офлайн-оценщик должны прогонять через политику репрезентативные маршруты и показывать, что будет экспортировано. Независимая проверка должна помечать маршруты, полученные от пиров или провайдеров и отобранные для другой неклиентской сессии.

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

Граница контроля Level 3 отдельна и не менее важна для глобального распространения.

AS3549 решала, допустимы ли маршруты, полученные от AS4788, как они ранжируются и куда анонсируются. Крупный транзитный провайдер обладает знаниями о клиенте, которых нет у произвольных третьих сторон. Он может знать ожидаемое количество префиксов, зарегистрированные маршруты клиента, наблюдаемую историю, взаимоотношения клиентского конуса и назначение сессии. Он может применять:

явную импортную политику;
списки префиксов на основе аутентифицированных данных маршрутизации;
ограничения по пути AS и клиентскому конусу;
пороги максимального числа префиксов;
проверки длины маршрута и богонов;
обнаружение утечек с учётом взаимоотношений;
карантин или снижение приоритета для аномалий;
согласование человеком исключительного расширения.

Согласно отчёту BGPMon, Level 3 приняла анонсы и анонсировала их пирам и клиентам. Маршруты затем привлекли трафик и способствовали перегрузке в Level 3 и крупных пиринговых точках. [2]

Это не значит, что вышестоящий оператор может гарантировать корректность каждого клиентского маршрута. Статические фильтры устаревают. Мультихоминг-клиенты могут легитимно менять анонсы. Аварийная маршрутизация может расширить набор. Сложная политика может затруднить расчёт клиентских конусов. Слишком строгий фильтр может сам вызвать сбой.

Но эти издержки не отменяют ответственности провайдера. Они определяют инженерную задачу.

Транзитный провайдер с глобальной силой распространения должен уметь ответить:

Какой диапазон количества маршрутов и формы путей был нормален для этого клиента?
Какие изменения требовали предварительной координации?
Включал ли принятый набор маршруты, за которыми стояли другие крупные пиры или провайдеры?
Существовал ли порог максимального числа префиксов и был ли он установлен относительно реалистичного базового уровня?
Было ли у сессии исключение, отключавшее или ослаблявшее проверки?
Какой алерт сработал первым?
Кто мог подавить маршруты, не дожидаясь клиента?
Как защищался сопутствующий трафик во время расследования?

Подотчётность следует из этой практической способности ограничивать вред. Ошибка экспорта в AS4788 и приём в AS3549 — не взаимоисключающие объяснения. Это последовательные отказы контроля в одной и той же цепочке распространения.

Концентрация транзита превратила ошибку политики в общий вред

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

Level 3 была крупным глобальным транзитным провайдером. Как только AS3549 распространила пути, сети и клиенты далеко за пределами Малайзии могли выбрать их. Трафик, который обычно шёл по прямым, региональным или лучше обеспеченным маршрутам, притягивался к пути через Level 3 и AS4788. [2][3]

За этим последовали два механизма вреда.

Первый — прямое перенаправление пути. Префикс назначения мог получить выбранный путь через AS3549 и AS4788. Пакеты затем шли в сторону Telekom Malaysia, хотя она не должна была предоставлять глобальный транзит для этого назначения. Соединение могло насытиться, пакеты — отбрасываться, а задержка — расти.

Второй — сопутствующая перегрузка. Сервису не обязательно было самому выбирать утёкший путь, чтобы пострадать. Если он зависел от ёмкости Level 3 или перегруженной точки присутствия, экстраординарная трафиковая нагрузка могла ухудшить его обычный маршрут. ThousandEyes описала примеры, когда собственный маршрут сервиса не менялся, но перегрузка внутри Level 3 снижала доступность. [3]

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

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

Событие связывает безопасность маршрутизации с риском концентрации. Высоко связная транзитная сеть улучшает достижимость в обычных условиях. Та же связность усиливает отказ политики, когда небезопасные маршруты принимаются и распространяются. Масштаб — одновременно актив устойчивости и множитель радиуса поражения.

Ответственная эксплуатация должна рассматривать охват распространения как переменную риска:

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

Цель — не устранить автоматизацию. Цель — сделать автоматизацию соразмерной тем полномочиям, которые она предоставляет.

Ограничения максимального числа префиксов помогают, но это не полная политика

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

BGPMon предположил, что аномальный объём маршрутов мог также вызвать срабатывание ограничений максимального числа префиксов на сессиях Level 3 с другими крупными сетями, порождая дополнительные колебания и изменения путей. [2]

Это наблюдение вскрывает и ценность, и опасность простых порогов.

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

Эффективные лимиты требуют контекста:

обычные агрегированные и более специфичные префиксы клиента;
ожидаемый рост;
сценарии обслуживания и аварий;
раздельное поведение для IPv4 и IPv6;
отклоняются ли маршруты с закрытием или сохраняется последний известный корректный набор;
эскалация алертов до жёсткой остановки;
безопасный процесс обхода с истечением срока;
тестирование реакции при реалистичном трафике.

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

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

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

Проверка источника в RPKI не решила бы отказ политики путей

В дискуссиях о безопасности маршрутизации RPKI часто используют как универсальный ответ на инциденты BGP. Здесь такой упрощённый подход опасен.

Инфраструктура открытых ключей для интернет-ресурсов позволяет держателям номерных ресурсов создавать криптографически проверяемые утверждения. Авторизация источника маршрута (ROA) определяет, какой автономной системе разрешено анонсировать префикс как источник, с учётом правил длины префикса в авторизации. Проверка источника маршрута (ROV) может классифицировать полученный анонс, сравнивая его префикс и исходную AS с этими авторизациями. [15][16]

Событие 2015 года с AS4788 было в основном утечкой из-за нарушения политики путей, а не простым неавторизованным источником.

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

Анализ Хьюстона прямо указывает на это. В рассмотренном им наборе маршрутов лишь небольшая часть касалась случаев, где AS4788 выступала источником так, что это могла бы отфильтровать обычная ROA-фильтрация. Большая часть проблемы относилась к транзитной информации. [1]

Это не делает RPKI неважной. Проверка источника может остановить неавторизованные источники, случайные ошибки происхождения и многие хайджеки. Она может сократить один класс ложной достижимости. Она также даёт аутентифицированную информацию о ресурсах, которая поддерживает более широкие средства контроля.

Но это значит, что заявление о контроле должно быть точным.

«Мы внедрили ROV» не доказывает защиту от маршрутов с валидным источником, но невалидным путём взаимоотношений. Сети нужна дополнительная информация о том, кто может предоставлять транзит кому и какие пути согласуются с политикой. RPSL, данные клиентского конуса, communities, роли BGP, атрибут Only to Customer, работы, связанные с ASPA, и операторские фильтры решают части этой проблемы на разном уровне зрелости.

Ответственное сообщение многослойно:

RPKI проверяет полномочия источника;
явная импортная и экспортная политика ограничивает сессии;
средства контроля с учётом взаимоотношений ограничивают распространение путей;
мониторинг обнаруживает аномалии, которые пропускают статические данные;
операционная координация сдерживает то, что не остановила профилактика.

Смешение этих слоёв создаёт ложную уверенность и слабое обучение после инцидента.

Реестры маршрутов могут публиковать намерения, но устаревшие намерения — это не контроль

Язык спецификации политики маршрутизации (RPSL) был создан для описания политики маршрутизации в интернет-реестрах маршрутов. RPSL и RPSLng могут выражать импортную и экспортную политику, наборы автономных систем, наборы маршрутов и связанные намерения. [13][14]

В принципе, провайдер может использовать аутентифицированные и поддерживаемые данные политики для генерации фильтров для клиента. Клиент может публиковать префиксы и взаимоотношения AS, которые планирует анонсировать. Пиры могут сравнивать наблюдаемые маршруты с заявленными намерениями.

Анализ Хьюстона объясняет и привлекательность, и ограничения. Данные реестров могут быть неполными, устаревшими, дублированными между базами или слишком грубыми для отношений конкретной сессии. Сложную политику трудно выразить и поддерживать. Некоторые реестры исторически допускали записи третьих лиц со слабой авторитетностью. [1]

Неверный урок — что реестры маршрутов бесполезны. Правильный урок — что объект реестра является доказательством только тогда, когда проверяемы его владелец, актуальность, охват и применение.

Зрелый конвейер фильтрации должен фиксировать:

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

MANRS описывает безопасность маршрутизации как коллективную операционную ответственность. Его действия для операторов подчёркивают фильтрацию анонсов, поддержание координационных контактов и публикацию информации, которую другие могут проверить. Текущее руководство по внедрению обсуждает гранулярность префиксов и путей AS и рекомендует средства контроля, не позволяющие экспортировать маршруты, полученные от клиентов или промежуточных сетей, неподходящим неклиентским пирам. [17][18]

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

Событие показывает, почему эта основа важна. Политику, известную только одной конфигурации маршрутизатора, другой сети трудно проверить. Политика, опубликованная, но никогда не скомпилированная в фильтры, — лишь документация. Фильтр, собранный из устаревших данных, может отклонять валидные маршруты или принимать невалидные. Подотчётность требует цепочки от заявленного намерения к развёрнутому поведению и наблюдаемым маршрутам.

Отказ по умолчанию меняет режим отказа

RFC 8212, опубликованный в 2017 году, обновляет поведение BGP так, что маршруты на сессии eBGP не импортируются и не экспортируются, пока не настроена явная политика. [11]

Это обманчиво важное проектное решение.

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

Позиция отказа по умолчанию меняет режим отказа. Отсутствие политики даёт отсутствие обмена маршрутами — это видимо и локально, а не непреднамеренное глобальное распространение. Операторы всё равно могут написать неверную явную политику. RFC 8212 прямо об этом говорит. Этот контроль не решает семантических ошибок, устаревших фильтров или намеренных исключений.

Однако он кодирует здравое правило подотчётности: глобальная достижимость должна требовать явного политического решения.

Для клиентской транзитной сессии это решение должно быть проверяемым:

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

Если бы на каждом значимом eBGP-соединении использовался строгий режим по умолчанию с корректной явной политикой, отсутствующий фильтр привёл бы к закрытому отказу. Публичные данные не могут показать, предотвратило бы поведение в духе RFC 8212 именно этот инцидент, потому что реальные конфигурации 2015 года не раскрыты. RFC остаётся полезным ретроспективным тестом: требовал ли обмен маршрутами явных и ограниченных полномочий с обеих сторон?

Роли BGP и Only to Customer решают проблему информации о взаимоотношениях

RFC 9234, опубликованный в 2022 году, стандартизирует роли BGP и атрибут Only to Customer. Соседи могут согласовывать такие роли, как провайдер, клиент, пир, route server и клиент route server. Распространяемые маршруты могут нести информацию, помогающую обеспечивать ожидаемое направление взаимоотношений и обнаруживать утечки. [12]

Этот механизм направлен на пробел, видимый в событии AS4788. Легитимный источник и свободный от петель путь не показывают, можно ли маршрут, полученный от пира, отправлять провайдеру. Информация о взаимоотношениях делает эту политику более явной в обмене протокола.

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

Ценность в том, что обе стороны могут сравнивать ожидания. Односторонняя локальная метка может быть ошибочной без немедленной обратной связи. Согласованная роль может привести к отказу установления сессии или пометить путь, когда концы расходятся во мнениях. Атрибут Only to Customer помогает выявлять маршруты, которые не должны уходить к другому провайдеру или пиру.

Повторим: это более поздние рекомендации. Исторически неточно утверждать, что AS4788 или AS3549 не использовали стандарт 2022 года в 2015-м.

Инцидент вместо этого даёт тестовый пример:

Можно ли экспортировать маршрут, полученный от пира, вышестоящему оператору без обнаружимого нарушения политики?
Может ли вышестоящий оператор определить, что путь клиента включает маршруты вне ожидаемых клиентских взаимоотношений?
Может ли любая из сторон остановить маршрут до глобального распространения?
Позволяют ли доказательства отличить политическое исключение от случайной утечки?

Современные механизмы с учётом ролей следует оценивать на реконструированном наборе маршрутов, подобном AS4788, а не только на синтетических примерах, соответствующих чистой топологии.

Мониторинг должен сравнивать маршруты с намерениями, а не только отслеживать доступность

Мониторинг доступности обнаруживает вред после того, как пользователи начинают терять достижимость. Мониторинг маршрутов может выявить аномалию плоскости управления раньше.

Публичная картина 2015 года была сохранена несколькими формами наблюдения:

BGPMon обрабатывал потоки обновлений и выявил серию анонсов;
RouteViews и RIPE RIS сохранили сырые архивы BGP;
ThousandEyes объединила измерения маршрутов и сети;
RIPE Atlas предоставил активные сквозные измерения;
независимые аналитики сравнивали пути, количество префиксов и время. [2][3][4][5][6]

Эти системы видели разные срезы. Такое разнообразие — сила. Внутренний взгляд одного провайдера может не замечать, как его маршруты выглядят в других местах. Активный пробник видит потери пакетов, но не политику, которая их вызвала. Коллектор маршрутов видит путь AS, но не каждый трафиковый путь или частную сессию.

Современные системы обнаружения могут искать утечки маршрутов на основе топологии, взаимоотношений AS, истории маршрутов и аномального распространения. Cloudflare описывает публичное обнаружение утечек маршрутов как способ выявления аномальных путей, а документация RIPE Atlas поддерживает воспроизводимые измерения с распределённых проб. [19][20]

Обнаружение должно быть связано с действием.

Алерт «количество маршрутов выросло» слаб, если за порог никто не отвечает или никто не может подавить маршрут. Полезный путь инцидента определяет:

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

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

Мониторинг также должен отличать профилактику от обнаружения. Публикация алерта об утечке маршрутов после глобального распространения — ценные публичные доказательства. Но она не доказывает, что у провайдера был контроль до распространения. Отчёты о подотчётности должны говорить, на каком этапе событие было обнаружено и на каком этапе остановлено.

Безопасное изменение политики маршрутизации требует доказательств на уровне актуальных байтов

Конфигурация маршрутизации часто проходит через шаблоны, базы данных, автоматизацию, компиляторы политик и синтаксис конкретного вендора, прежде чем попасть на маршрутизатор. Человек-ревьюер может утвердить одно представление, а устройство получит другое.

Цепочка доказательств должна связывать актуальные байты на каждом этапе:

исходная политика или запрос на изменение;
нормализованные данные о взаимоотношениях и префиксах;
сгенерированный route map или язык политики;
конфигурация под конкретное устройство;
дифф кандидатной конфигурации;
хэш зафиксированной конфигурации;
результирующий набор анонсированных и принятых маршрутов;
наблюдение внешнего коллектора.

Это важно, потому что «политика была проверена» — неоднозначно. Какая версия проверялась? Расширила ли автоматизация набор AS после утверждения? Создал ли фильтр устаревший снимок реестра? Обошла ли ручная аварийная команда обычный конвейер? Получили ли все маршрутизаторы одинаковый результат?

Ответственная система изменений должна отказывать, если эти привязки расходятся.

Перед развёртыванием она должна прогонять репрезентативные маршруты через скомпилированную политику. Для условий, подобных AS4788, тесты должны включать:

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

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

После развёртывания коллекторы маршрутов или looking glasses должны проверять наблюдаемый результат. Один хэш конфигурации не доказывает, что маршрутизатор анонсировал только целевые маршруты. Состояние плоскости управления, ошибки устройств и взаимодействие с другой политикой могут изменить фактическое поведение.

Эта дисциплина актуальных байтов — не бюрократия ради самой себя. Это способ, которым организация доказывает, что обсуждаемые код, политика и маршруты — те же объекты, которые произвели или предотвратили вред.

Восстановление — не то же самое, что подтверждённое устранение

Публичные источники показывают, что маршруты были отозваны или перестали приниматься, и сервис восстановился в течение последующих часов. Это операционное восстановление.

Устранение задаёт более сложный вопрос: может ли тот же класс маршрутов снова выйти наружу?

Достоверная программа устранения зафиксировала бы репрезентативный набор инцидента из RouteViews, RIPE RIS и внутренних журналов. Она определила бы целевые взаимоотношения для каждого маршрута и воспроизвела бы решения об экспорте и импорте в тестовой среде.

Для AS4788 тест проверил бы, что маршруты, полученные от пиров или провайдеров, не могут быть отобраны для экспорта в сторону AS3549, если не действует явное и проверенное исключение. Для AS3549 тест проверил бы, что клиент не может анонсировать пути вне ожидаемого клиентского конуса или превышать обоснованный объём без карантина.

Программа затем формировала бы доказательства:

непройденные тесты до исправления;
изменения политики или системы;
пройденные тесты после исправления;
версии устройств и ПО;
охват развёртывания;
учения по алертам и сдерживанию;
внешние наблюдения маршрутов;
реестр исключений и сроки их действия;
ответственного за постоянный мониторинг.

Устранение должно также тестировать деградированные условия. Что происходит, если данные реестра недоступны? Система закрывается, использует последний известный корректный набор или принимает всё? Что происходит, если детектор аномалий не работает? Может ли оператор изолировать сессию через независимый путь управления? Останавливает ли срабатывание максимального числа префиксов критические клиентские маршруты или сбрасывает их все?

Публичное раскрытие не обязано показывать частные коммерческие условия или эксплуатируемую конфигурацию. Оно может указать класс отказа, затронутую границу политики, добавленные средства контроля, метод тестирования, охват развёртывания и дату проверки.

Без этих доказательств «мы исправили фильтр» — утверждение о намерении. С ними клиенты и пиры могут оценить, изменил ли оператор систему, которая допустила глобальное распространение.

Подотчётность не должна сводиться к личной вине

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

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

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

Личная вина может скрыть эти средства контроля. Она также может отвращать от раскрытия. Более удачная модель подотчётности спрашивает:

Кто имел возможность не выпустить маршрут?
Кто имел возможность отклонить его?
Кто имел возможность ограничить его распространение?
Кто мог независимо обнаружить вред?
Кто мог отозвать или поместить в карантин?
Кто сохранил доказательства?
Кто имел полномочия финансировать и проверять устранение?

Эти вопросы позволяют определить ответственность, не заявляя об умысле или халатности, которые не подтверждаются публичными источниками.

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

Что клиенты и пиры могут разумно требовать

Большинство клиентов не могут аудировать маршрутизаторы транзитного провайдера. Пиры не видят каждый частный процесс изменений. Но они могут требовать доказательства, соразмерные зависимости.

До инцидента оператор может публиковать:

актуальные контакты по маршрутизации;
зарегистрированные префиксы и автономные системы;
наборы маршрутов и AS;
высокоуровневую политику пиринга и фильтрации;
покрытие RPKI;
поддержку соответствующих механизмов ролей и валидации;
каналы статуса и инцидентов.

Во время инцидента — сообщать:

затронутый класс маршрутов или сессий;
продолжаются ли анонсы;
действие по сдерживанию;
известные регионы и сервисы;
неопределённость измерений;
доказательства восстановления;
время следующего обновления.

После инцидента — предоставлять:

границы источника и приёма;
определения количества маршрутов;
хронологию с указанием происхождения данных;
отказавшие средства контроля;
средства контроля, которые сдержали вред;
проверяемое устранение;
оставшиеся ограничения.

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

Независимый мониторинг маршрутов, измерения RIPE Atlas и проверки looking glass могут выявить часть этой подверженности. [4][5][6][20]

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

Что публичная картина не может доказать

Набор источников поддерживает серьёзный анализ сетевой подотчётности, но не полный внутренний разбор.

Он не может доказать:

точный маршрутизатор или локацию Telekom Malaysia;
точную команду конфигурации или шаблон;
был ли триггером плановое изменение, устаревшее состояние, сбой автоматизации или ручная ошибка;
версию ПО или оборудования;
частные условия взаимоотношений между AS4788 и AS3549;
точные настройки импорта, экспорта и максимального числа префиксов на обеих сторонах;
первый внутренний алерт и реакцию оператора;
частные сообщения координации;
единое согласованное число префиксов по всем коллекторам;
полную перепись пострадавших пользователей или финансовых потерь;
юридическую ответственность или нарушение контракта;
долговременное устранение, развёрнутое любым из операторов.

Пакет материалов также не должен превращать более поздние средства контроля в исторические требования. RFC 8212 опубликован в 2017 году, RFC 9234 — в 2022-м, а текущее руководство по внедрению MANRS отражает более позднюю операционную работу. Они задают полезные современные тесты. Они не доказывают, какие конфигурации или обязательства существовали в 2015 году. [11][12][18]

Точно так же текущие данные RIPEstat — это текущий контекст сетевых ресурсов, а не замороженный снимок реестра 2015 года. [7]

Эти границы делают вывод более достоверным. Наблюдаемого отказа достаточно, чтобы установить разделённый контроль. Отсутствие внутренней записи — само по себе пробел подотчётности, но это не разрешение что-то выдумывать.

Многоразовый тест подотчётности для фильтрации у вышестоящего оператора

Событие даёт практический тест для любого клиента, транзитного провайдера или пира, эксплуатирующего BGP на значимом масштабе.

1. Определите взаимоотношения для каждой сессии.
Фиксируйте роли провайдера, клиента, пира, route server и исключительные роли с той гранулярностью, где политика различается.

2. Свяжите целевые маршруты с аутентифицированными доказательствами.
Ведите префиксы, источники, клиентские конусы, наборы AS и исключения с указанием владельца, актуальности и происхождения.

3. Компилируйте политику до развёртывания.
Показывайте конкретные маршруты и пути, которые примут импортная и экспортная политики. Оценивайте фактическое поведение, а не только текст шаблона.

4. Закрывайтесь при отсутствии явной политики.
Ни один маршрут eBGP не должен получать глобальные полномочия из-за отсутствия фильтра или сбоя получения данных.

5. Тестируйте нарушения взаимоотношений.
Прогоняйте маршруты, полученные от пиров и провайдеров, через клиентские и вышестоящие сессии. Проверяйте, что неверное направление отклоняется и экспортёром, и получателем.

6. Калибруйте контроль объёма.
Устанавливайте максимальное число префиксов и пороги аномалий относительно обычного поведения, обоснованного роста и аварийных случаев. Определяйте безопасное сдерживание, а не только полное отключение сессии.

7. Разделяйте проверку источника и пути.
Используйте RPKI для полномочий источника, но не описывайте ROV как доказательство валидного по взаимоотношениям распространения. Добавляйте контроль пути и клиентского конуса.

8. Наблюдайте извне.
Используйте независимые коллекторы и активные измерения, чтобы сравнивать наблюдаемые маршруты и достижимость с целевой политикой.

9. Назначьте ответственного за сдерживание.
Определите, кто может поместить маршруты в карантин, снизить приоритет, восстановить последний известный корректный набор или сбросить сессию, в том числе вне обычных окон изменений.

10. Сохраняйте доказательства на уровне актуальных байтов.
Связывайте утверждённую политику, сгенерированную конфигурацию, развёрнутые байты, состояние маршрутов, алерты, решения и внешние наблюдения.

11. Доказывайте устранение на исходном классе события.
Прогоняйте реконструированную утечку через обе стороны сессии и показывайте, где она останавливается. Тестируйте семантические варианты, а не один сохранённый список префиксов.

12. Публикуйте достаточно для проверки зависимыми сетями.
Объясняйте границу контроля, определения количества маршрутов, устранение и оставшуюся неопределённость, не раскрывая чувствительные частные условия.

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

Заключение

Утечка маршрутов Telekom Malaysia 12 июня 2015 года показала, как быстро локальная политика маршрутизации может превратиться в глобальный вред для инфраструктуры.

AS4788 выпустила очень большой набор маршрутов. AS3549 приняла и распространила их. Трафик сместился на пути через Level 3 и Telekom Malaysia. Потери пакетов, задержки и отказы достижимости распространились по регионам, затронув и сервисы, чьи пути были напрямую перенаправлены, и пользователей, столкнувшихся с перегрузкой в общей транзитной сети. Независимые коллекторы маршрутов и платформы измерений сохранили публичную картину. [1][2][3][4]

Событие нельзя ответственно объяснить как один плохой анонс одной сети. Экспорт и импорт — раздельные средства контроля. У клиента есть обязанность анонсировать только авторизованные маршруты. У транзитного провайдера есть обязанность, соразмерная его силе принимать и распространять эти маршруты. У пиров и нижестоящих сетей есть дополнительные средства мониторинга и импорта. Ни один слой не может гарантировать безупречность, но каждый может не дать одной ошибке получить больше охвата.

Проверка источника в RPKI ценна и недостаточна для этого отказа политики путей. Реестры маршрутов могут публиковать намерения и всё равно устаревать. Контроль максимального числа префиксов может сдерживать объём, но пропускать мелкие утечки. Более поздние стандарты отказа по умолчанию и учёта взаимоотношений улучшают модель контроля, но не доказывают ретроактивно нарушение в 2015 году. Долговременный ответ многослоен: явная политика, аутентифицированные данные маршрутов, проверки взаимоотношений, калиброванные лимиты, независимый мониторинг, быстрое сдерживание и воспроизводимое устранение.

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

Утечка маршрутов Telekom Malaysia в 2015 году сделала фильтрацию у вышестоящего оператора тестом на подотчётность транзита

Почему это важно