Январская утечка маршрутов IPv6 в Cloudflare: тест на подотчётнос

Резюме

Cloudflare сообщает, что изменение в репозитории, призванное удалить устаревшие ссылки на локальные списки префиксов площадки Богота, было объединено в 19:52 UTC 22 января 2026 года. Автоматизация применила полученную политику к одному маршрутизатору в Майами в 20:25 — в этот момент началось воздействие. Расследование началось в 20:40; инцидент был зафиксирован в 20:44; оператор вручную откатил конфигурацию маршрутизатора и приостановил автоматизацию в 20:50. Изменение в репозитории было отменено в 21:47, автоматизация признана исправной в 22:07, а её работа возобновлена в 22:40 [1].
По данным Cloudflare, удаление последнего условия списка префиксов не удалило включающий его экспортный терм. Терм сохранил более широкое условиеroute-type internalи действиеaccept. Поскольку, как утверждает Cloudflare, это условие охватывало невнешние маршруты, в том числе полученные через iBGP, итоговая политика могла отбирать внутренне перераспределённые сторонние IPv6-маршруты и экспортировать их пирам и транзитным провайдерам в Майами. Таким образом конфигурация стала семантически более широкой, хотя осталась синтаксически применимой [1].
Cloudflare ограничила воздействие 25 минутами и только IPv6. Компания сообщила о перегрузке магистрального участка Майами — Атланта, повышенной задержке на затронутых каналах, увеличенных потерях для части клиентского трафика Cloudflare и отбрасывании межсетевым экраном трафика, адресованного префиксам, не являющимся нижестоящими. По оценке компании, пиковый объём отброшенного трафика достиг примерно 12 Гбит/с. Эти измерения основаны на данных Cloudflare; открытая запись не позволяет независимо оценить число затронутых клиентов, отдельные потери или полный набор префиксов [1].
Cloudflare описала получение IPv6-маршрутов Meta от пира AS32934 и их анонсирование из сети Cloudflare AS13335 в сторону транзитного провайдера AS3356. Для префикса2a03:2880:f077::/48компания опубликовала путь64112 22850 174 3356 13335 32934. Ограниченный запрос RIPEstat BGPlay вернул 1548 событий обновлений, включая 1440 путей, содержащих одновременно AS13335 и AS32934. Это независимо подтверждает публичную видимость аномального шаблона пути, но не внутреннюю причину политики, объём трафика или влияние на клиентов [1][6][7][8].
Центральный сбой управления заключался не просто в удалении текста. Произошло расширение множества маршрутов, разрешённых к экспорту. Исходное намерение, итоговая конфигурация, действующая конфигурация, состояние Loc-RIB, candidate Adj-RIB-Out и отправленные BGP-обновления отвечают на разные вопросы. Безопасное изменение должно было показать, что удаление ссылок на Боготу привело только к ожидаемым исключениям и нулю новых подходящих маршрутов, полученных от пиров или провайдеров, на каждой затронутой IPv6-сессии [1][10].
Cloudflare классифицировала событие как сочетание утечек типов 3 и 4 по RFC 7908: маршруты, полученные от провайдера, экспортировались пирам, а маршруты, полученные от пира, экспортировались в сторону транзитного провайдера. Поведение отклонения по умолчанию из RFC 8212 устраняет отсутствие явной внешней политики, но само по себе не исправляет явную политику, у которой сохранившийся термacceptслишком широк. RFC 9234 «Roles» и «Only-to-Customer» предлагают учитывающие отношения механизмы, отличные от авторизации источника [11][12][13].
Проверка источника RPKI не обязательно отклонила бы опубликованный пример пути. Маршрут по-прежнему заканчивался в AS32934 Meta, поэтому авторизация источника и авторизация промежуточного пути — это разные вопросы. ROA, проверка источника и распространение данных из валидатора в маршрутизатор защищают утверждения об источнике; BGP Roles и OTC касаются распространения с учётом отношений, а ASPA предлагает развивающиеся механизмы проверки пути. Ни один из этих документов не доказывает, что Cloudflare или её соседи имели развёрнутые средства во время инцидента [12][15][16][17][18][20].
Применение изменения к одному маршрутизатору ограничило охват устройств, но не помешало этому маршрутизатору повлиять на внешнюю маршрутизацию. Осмысленная канареечная проверка должна сравнивать итоговые наборы соответствий и Adj-RIB-Out до отправки, отслеживать живые экспорты по соседям и семейству адресов, прерываться при нарушении отношений, коррелировать сигналы RIB/FIB и сброса, а также подтверждать отзыв маршрутов через внешние коллекторы.
Открытая запись оставляет неизвестными частную топологию, точные внутренние механизмы автоматизации, ответственных за решения, скрытые средства защиты и эффективность последующего исправления [1][7][14][19].

Узкий вывод, подтверждаемый открытой записью

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

Но это всё же рассказ Cloudflare о событии внутри её собственной сети, а не полная нейтральная реконструкция [1].

Независимые свидетельства играют более узкую роль. Ограниченный запрос RIPEstat BGPlay по одному раскрытому IPv6-префиксу Meta в ограниченном временном окне показывает, что пути, содержащие Cloudflare AS13335 и Meta AS32934, были видны через публичные коллекторы маршрутов. Это подтверждает вывод, что аномальный шаблон пути вышел за пределы закрытого конфигурационного контекста и появился в публичной плоскости управления. Запрос не может определить условие в исходном коде, установить, какой маршрутизатор отправил каждое обновление, измерить трафик, установить число затронутых клиентов или раскрыть частную топологию Cloudflare [6][7][8].

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

Самый сильный защитимый вывод поэтому точен: Cloudflare сообщает, что один маршрутизатор в Майами экспортировал IPv6-маршруты, полученные от пиров и провайдеров, после того как автоматизированная очистка удалила последнее ограничение списка префиксов из принимающего условия политики. Публичные коллекторы наблюдали по меньшей мере один соответствующий шаблон AS-пути. Cloudflare отменила политику маршрутизатора через 25 минут, приостановила автоматизацию, позже отменила изменение в репозитории, признала автоматизацию исправной и затем возобновила её работу [1][7].

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

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

Восемь раскрытых отметок времени без выдуманной хронологии

Публичная последовательность Cloudflare начинается в 19:52 UTC, когда изменение в репозитории было объединено. Цель, по словам компании, состояла в удалении ссылок на устаревшие локальные списки префиксов площадки Богота после модернизации инфраструктуры. Такое описание устанавливает намерение: убрать больше не нужные локальные конфигурационные ссылки. Оно не устанавливает семантику итоговой конфигурации устройства [1].

В 20:25 автоматизация выполнилась на одном маршрутизаторе в Майами, и началось воздействие. Эта отметка важна по двум причинам. Во-первых, она связывает активацию с одним устройством, а не с одновременным изменением всего парка. Во-вторых, она отмечает начало раскрытого Cloudflare 25-минутного окна воздействия. Ограничение одним маршрутизатором сузило, где была активирована политика, но не удержало маршруты, отправленные этим маршрутизатором, внутри Cloudflare [1].

Расследование началось в 20:40. Cloudflare сообщает, что инцидент был зафиксирован в 20:44. Это разные операционные вехи, и их следует различать: расследование означает, что аномалию начали изучать; фиксация инцидента означает формальную эскалацию в процессе реагирования. Открытая запись не даёт достаточно деталей, чтобы определить, какое оповещение сработало первым, когда конкретный человек впервые увидел неожиданный AS-путь или поступали ли внутренние и внешние сигналы в определённом порядке.

В 20:50 оператор вручную откатил конфигурацию на маршрутизаторе в Майами и приостановил автоматизацию. Это двойное действие важно. Откат устройства устранил активное состояние маршрутизации, а приостановка автоматизации не дала системе «источник — устройство» немедленно восстановить плохое состояние. Откат только маршрутизатора мог остаться уязвимым к повторному применению, если генерирующий источник по-прежнему кодировал тот же результат [1].

Изменение в репозитории было отменено в 21:47. Cloudflare признала автоматизацию исправной в 22:07 и возобновила её в 22:40. Эти более поздние моменты показывают, что восстановление включало не только отзыв утёкших маршрутов. Нужно было исправить состояние источника, оценить автоматизацию и сделать возобновление явным решением. Открытая запись не раскрывает тесты, использованные для вывода в 22:07, или критерии возобновления в 22:40 [1].

Раскрытая Cloudflare граница воздействия заканчивается ручным откатом политики маршрутизатора и приостановкой автоматизации в 20:50. Компания сообщила, что событие длилось 25 минут и затронуло только IPv6. Она связала с событием перегрузку магистрали Майами — Атланта, повышенную задержку на затронутых каналах и увеличенные потери пакетов для части клиентского трафика Cloudflare. Также сообщается, что фильтры межсетевого экрана отбрасывали трафик для префиксов, не являющихся нижестоящими для Cloudflare, а пиковый объём отброшенного трафика оценивается примерно в 12 Гбит/с [1].

Эти цифры не следует расширять до итоговых значений, которые Cloudflare не публиковала. 12 гигабит в секунду отброшенного трафика — это не то же самое, что общий привлечённый трафик, общий трафик утёкших маршрутов, общий спрос клиентов или экономический ущерб. «Часть клиентского трафика» не определяет число клиентов или географическое распределение. Повышенная задержка на затронутых каналах не означает всеобщего роста задержки в сети Cloudflare.

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

Как удалённое условие расширило право на экспорт

Раскрытый сбой политики основан на разнице между синтаксической корректностью и семантикой множеств. Синтаксическая ошибка обычно заметна: парсер отклоняет оператор, коммит не проходит или устройство отказывается принимать candidate-конфигурацию. Cloudflare описала нечто более опасное. Сгенерированный терм остался приемлемым для системы конфигурации, но представлял гораздо большее множество маршрутов, чем предполагалось [1].

До очистки соответствующий терм сочетал широкое условиеroute-type internalс узким условием списка префиксов для площадки Богота. В условной нотации множеств подходящие маршруты можно представить так:

Внутренние маршруты ∩ Маршруты из списка префиксов Боготы

Очистка удалила последнее условие списка префиксов. По данным Cloudflare, она не удалила сам терм и не изменила его итоговое действие. Итоговая пригодность стала такой:

Внутренние маршруты

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

Терм по-прежнему заканчивался действиемaccept. Cloudflare сообщает, чтоroute-type internalохватывал невнешние маршруты, включая маршруты, полученные через iBGP. Маршрут, полученный по iBGP, не обязательно является префиксом, созданным Cloudflare, или маршрутом, принадлежащим клиенту Cloudflare. Он может нести информацию о достижимости, полученную в другом месте сети от пира или транзитного провайдера. Внутреннее распространение описывает, как локальный маршрутизатор получил или представил маршрут, но не доказывает, что его безопасно анонсировать наружу.

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

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

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

Тест скомпилированной политики для этого события должен был построить репрезентативные маршруты как минимум пяти классов: маршруты, созданные Cloudflare; легитимные нижестоящие маршруты; маршруты, полученные от пира; маршруты, полученные от провайдера; и несвязанные маршруты, переносимые внутри через iBGP. Удаление ссылок на Боготу должно было вызвать только ожидаемые изменения, специфичные для Боготы. Любой вновь принятый маршрут, полученный от пира или провайдера, должен был остановить активацию.

Тот же тест следовало выполнить отдельно для IPv4 и IPv6. Cloudflare сообщает, что затронут был только IPv6, поэтому оценка по семейству адресов была обязательной. Общий результат «политика успешно скомпилирована» не доказывал бы, что IPv6-терм сохранил намеченные ограничения по отношениям и префиксам.

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

Исходное намерение, итоговая политика и действующее состояние — разные доказательства

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

Уровень доказательств	Вопрос, на который он отвечает	Предупреждение для этого события
Намерение изменения	Что оператор пытался удалить?	Устаревшие ссылки на Боготу описывают цель, но не итоговый охват экспорта.
Генерирующий источник	Какая логика и данные изменились?	Небольшое удаление может убрать последний узкий предикат.
Итоговый candidate	Какие точные термы и действия получит маршрутизатор?	`route-type internal`плюс`accept`может остаться синтаксически корректным.
Оценка множества совпадений	Какие текущие маршруты удовлетворяют каждому терму?	IPv6-маршруты, полученные от пиров и провайдеров, могут попасть в новое расширенное множество.
Действующая конфигурация	Что маршрутизатор активировал?	Принятие устройством не означает корректности политики отношений.
Состояние RIB и Adj-RIB-Out	Какие маршруты выбраны и подходят для каждого соседа?	Неожиданные сторонние маршруты могут быть подготовлены к внешнему анонсированию.
Отправленные обновления	Что маршрутизатор действительно отправил?	Публичные AS-пути могут показать, что граница была пересечена.
Состояние пересылки и трафика	Какой трафик пошёл по новым путям и что с ним произошло?	Cloudflare сообщила о перегрузке, задержках, потерях и сбросе трафика, не относящегося к нижестоящим.

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

RFC 4271 описывает BGP как протокол достижимости, управляемый политиками, и определяет концептуальные базы маршрутной информации, используемые при выборе и распространении. Adj-RIB-Out представляет маршруты, которые BGP-спикер анонсирует или готов анонсировать конкретному пиру. Реализации могут по-разному раскрывать это состояние, но вопрос подотчётности остаётся: что изменилось в экспортном множестве для каждого соседа и семейства адресов? [10]

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

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

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

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

Что Adj-RIB-Out должен был выявить до отправки

Adj-RIB-Out — наиболее специфичный для события недостающий мост между конфигурацией и публичной маршрутизацией. Терм политики может выглядеть разумным изолированно, и маршрут может выглядеть легитимным в Loc-RIB, однако сочетание может быть неприемлемым для конкретного внешнего соседа. Оценка исходящих наборов маршрутов делает сочетание явным [10].

Рассмотрим раскрытый маршрут Meta. Получение2a03:2880:f077::/48от пира AS32934 может быть совершенно нормальным в рамках пирингового отношения. Распространение этого маршрута внутри через iBGP также может быть нормальным. Сбой подотчётности возникает, когда маршрутизатор в Майами готовит маршрут к экспорту в сторону транзитного провайдера или другого пира вопреки правилу отношений, описанному Cloudflare.

Сравнение Adj-RIB-Out по каждому соседу должно ответить как минимум на такие вопросы:

Добавил ли candidate какой-либо маршрут, полученный от пира, в IPv6-сессию, направленную в сторону вышестоящего провайдера?
Добавил ли он какой-либо маршрут, полученный от провайдера, в пиринговую сессию?
Изменилось ли число сторонних источников, анонсируемых на сессии?
Были ли удалены или изменены сообщества, отражающие отношения?
Изменилась ли обработка AS-пути или next-hop так, что это повлияло на допустимость экспорта?
Входил ли каждый вновь подходящий префикс в утверждённый объём изменения?

Первые два вопроса прямо соответствуют направлениям утечки, описанным Cloudflare. Третий ловит неожиданное расширение, даже если метаданные о происхождении неполны. Четвёртый проверяет, сохранился ли вторичный контроль. Пятый проверяет отправляемые атрибуты, а не только членство в множестве префиксов. Шестой связывает результат с очисткой Боготы.

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

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

Происхождение сообществ заслуживает особого внимания. Cloudflare сообщила, что планировала дополнительные меры на основе BGP-сообществ [1]. Такие меры могут кодировать, вошёл ли маршрут от клиента, пира, провайдера или внутреннего источника, но только если метки присваиваются на доверенных границах и не могут быть случайно унаследованы или подделаны. Внешние сообщества, возможно, нужно очищать, нормализовать или записывать отдельно, прежде чем применять внутренние метки отношений.

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

Итоговое сравнение должно использовать именно ту candidate-политику, которая попадёт на маршрутизатор, а не абстрактный шаблон. Оно также должно использовать данные маршрутов, репрезентативные для момента активации. Тест без пиринговых маршрутов может дать ложное спокойствие, если живое состояние iBGP содержит их много.

Оператор не обязан публично раскрывать содержимое Adj-RIB-Out. Однако следует сохранить достаточно доказательств, чтобы заявить, что candidate не внёс ни одного несанкционированного экспорта по отношениям и семейству адресов, и показать позднее проверяющим, как был сделан этот вывод. Публикация Cloudflare об инциденте не приводит такого сравнения до активации.

Чтение раскрытого AS-пути без выдумывания контракта

Пример Cloudflare сосредоточен на префиксе Meta2a03:2880:f077::/48и AS-пути:

64112 22850 174 3356 13335 32934

AS-пути BGP обычно читаются от наблюдающей стороны к источнику, при этом исходная AS находится справа. В этом примере AS32934 указана как источник, Cloudflare AS13335 — сразу перед ней, а AS3356 — перед Cloudflare. Cloudflare определяет AS32934 как пира, а AS3356 как транзитного провайдера [1].

Такая атрибуция даёт контекст отношений, которого сами числа не содержат. В сочетании с рассказом Cloudflare сегмент3356 13335 32934представляет маршрут, созданный Meta, полученный Cloudflare от пира и затем анонсированный Cloudflare в сторону её транзитного провайдера. Это направление «пир — провайдер», центральное для инцидента.

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

AS-пути не являются полными коммерческими контрактами. Они не кодируют цены, условия расчётов, исключения, отношения между материнскими и дочерними компаниями, частичный транзит или каждую деталь частной топологии. Классификации отношений часто зависят от внешней информации и могут различаться по точкам соединения. Здесь метки «пир» и «провайдер» обоснованы, потому что Cloudflare предоставила их для инцидента. Их не следует обобщать на каждую сессию между теми же организациями.

Левая часть —64112 22850 174— показывает, что маршрут был виден за пределами непосредственного сегмента Cloudflare—Lumen на наблюдаемом пути. Она не устанавливает, сколько сетей установило маршрут и как долго каждая его удерживала. Коллектор фиксирует обновления, доступные с подключённых точек наблюдения, а не полное состояние пересылки всего интернета.

Таким образом, путь — мощное, но ограниченное доказательство. Он показывает, что маршрут с Meta в качестве источника появился с Cloudflare и её вышестоящим провайдером в середине. Это согласуется с раскрытым Cloudflare направлением утечки. Он не раскрывает текст политики маршрутизатора, объём трафика маршрута или внутреннюю причину, по которой анонс прошёл.

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

Почему RFC 7908 даёт классификации типов 3 и 4

RFC 7908 предлагает словарь для утечек маршрутов, не превращая каждую аномалию маршрутизации в проблему источника. Его категории сосредоточены на непреднамеренном распространении через границы отношений [11].

Утечка типа 3 — это анонсирование маршрутов, полученных от транзитного провайдера, пиру. Такой экспорт может превратить сеть, допустившую утечку, в непреднамеренный путь между её пиром и провайдером. Утечка типа 4 — это анонсирование маршрутов, полученных от пира, транзитному провайдеру. Раскрытый пример Meta относится к направлению типа 4: Cloudflare сообщает, что получила маршрут от пира AS32934 и анонсировала его провайдеру AS3356 [1][11].

Cloudflare классифицировала более широкое событие как сочетание типов 3 и 4, поскольку расширенная политика экспортировала внутренне перераспределённые маршруты и пирам, и провайдерам. Маршруты, полученные от провайдера и отправленные пирам, соответствуют шаблону типа 3; маршруты, полученные от пира и отправленные провайдеру, — типу 4 [1][11].

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

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

Вот почему событие нельзя свести к «слишком много префиксов». Утёкшие маршруты пересекли границы отношений. Число маршрутов, идентичность префиксов, авторизация источника и авторизация отношений — всё это важно, но эти понятия не взаимозаменяемы.

RFC 7908 классифицирует поведение, но не предотвращает его. Для предотвращения нужны экспортная политика, метаданные об отношениях, фильтрация на принимающей стороне и, где поддерживается, протокольные механизмы, переносящие ограничения отношений. Классификация полезна, потому что переводит расширение политики в Майами в два проверяемых инварианта: ни один маршрут, полученный от провайдера, — пиру, и ни один маршрут, полученный от пира, — провайдеру.

Один маршрутизатор и одно семейство адресов не сделали изменение безопасным

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

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

Канареечная проверка ценна только при наличии контракта наблюдения и останавливающего действия. Для этого события контракт должен был требовать нуля новых экспортированных пирам маршрутов, полученных от пиров, нуля новых экспортированных пирам маршрутов, полученных от провайдеров, и отсутствия неожиданного роста IPv6 Adj-RIB-Out. Останавливающее действие должно было приостановить дальнейшую автоматизацию и отозвать или заблокировать candidate до того, как расследование человеком станет основным механизмом сдерживания.

Самая безопасная первая стадия может вообще не отправлять обновления. Candidate-политику можно отрисовать и оценить на текущем состоянии маршрутов, получив проекцию диффа Adj-RIB-Out. Если платформа поддерживает теневой режим или режим отложенных обновлений, операторы могут проверить candidate-набор экспорта до выпуска. Активация на устройстве должна следовать только после прохождения сравнения без отправки.

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

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

Граница по семейству адресов должна была быть видна до активации. Сравнение итоговых политик могло бы показать, что IPv4-наборы экспорта не изменились, а изменения IPv6 ограничились намеченными удалениями для Боготы. Живые проверки затем должны отдельно сравнивать BGP-обновления IPv4 и IPv6, состояние RIB/FIB, трафик и достижимость.

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

Стек доказательств, нужный именно для этого режима сбоя

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

Доказательства итоговой политики

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

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

Расширение набора маршрутов

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

Результат должен объяснять, почему каждый вновь совпавший маршрут подходит. Если iBGP-полученный маршрут Meta появляется только из-за исчезновения последнего условия списка префиксов, объяснение достаточно конкретно, чтобы остановить изменение. Процентное изменение менее полезно, чем список вновь разрешённых классов маршрутов.

Состояние RIB и FIB

Loc-RIB показывает выбранную маршрутную информацию, доступную маршрутизатору. FIB показывает, что может использовать плоскость пересылки. Ни то ни другое само по себе не доказывает, что было анонсировано наружу, но оба важны, когда начинает поступать трафик.

Cloudflare сообщила, что трафик для префиксов, не являющихся нижестоящими, отбрасывался фильтрами межсетевого экрана [1]. Это означает, что экспорт и контроль пересылки дали разные результаты: плоскость управления привлекла трафик, который политика плоскости данных не стала бы передавать. Оператор должен обнаружить это противоречие. Анонсирование маршрута при одновременном отбрасывании трафика для него — сигнал высокой достоверности о расхождении заявлений о достижимости и полномочий на пересылку.

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

BGP-обновления и Adj-RIB-Out

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

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

Трафик, задержка и сброс

Cloudflare сообщила о перегрузке между Майами и Атлантой, повышенной задержке на затронутых каналах, увеличенных потерях для части клиентского трафика и примерно 12 Гбит/с пикового отброшенного трафика, не относящегося к нижестоящим [1]. Эти сигналы описывают последствия, а не исходную ошибку авторизации.

Они всё же ценны для автоматического сдерживания. Внезапный рост сброса для префиксов, не классифицированных как нижестоящие, в сочетании с неожиданными сторонними маршрутами в Adj-RIB-Out сильнее, чем любой из сигналов по отдельности. Перегрузка магистрали может показать, где привлечённый трафик нагружает внутренние мощности. Задержка и потери могут выявить побочные эффекты для легитимного клиентского трафика.

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

Внешняя видимость маршрутов

Коллекторы RIPE RIS получают BGP-информацию от участвующих сетей и сохраняют публичные наблюдения за маршрутизацией. BGPlay превращает доступные события маршрутов в ограниченный по времени вид; данные MRT предлагают другую структурированную форму записей маршрутизации [6][8][9]. Эти системы обеспечивают независимую видимость, но только с подключённых точек наблюдения.

Cloudflare также описывает обнаружение утечек маршрутов и расследование аномалий BGP через Radar и связанные интерфейсы [2][3][4][5]. Эти материалы показывают доступные концепции и возможности. Они не устанавливают, какой путь обнаружения выявил инцидент в Майами, когда это произошло или вызвало ли откат конкретное оповещение.

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

Состояние восстановления

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

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

Что доказывает запрос RIPEstat — и чего не может

Ограниченный запрос RIPEstat BGPlay охватывает2a03:2880:f077::/48с 20:24 до 20:52 UTC. Он вернул статусok, 1548 событий обновлений и 1440 событий с путями, содержащими одновременно Cloudflare AS13335 и Meta AS32934 [7].

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

Запрос не доказывает независимо, что удаление условия списка префиксов вызвало обновления. Публичные данные BGP обычно содержат итоговый префикс, AS-путь, атрибуты, временные метки и контекст коллектора, а не исходный код или итоговую политику маршрутизатора, ответственную за них. Внутренняя причина остаётся атрибутированной раскрытию Cloudflare [1][7][8].

Он не измеряет трафик. BGP-обновления описывают анонсы и отзывы достижимости, а не объём пакетов. Оценка пикового сброса в 12 Гбит/с, перегрузка, задержка и потери клиентов остаются измерениями, сообщёнными компанией [1].

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

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

Он также не показывает всеобщее распространение. Коллекторы RIPE RIS обеспечивают существенную, но частичную видимость [6]. Маршрут, не увиденный конкретным коллектором, может существовать в другом месте, а маршрут, увиденный коллектором, может не быть выбран для пересылки во всём интернете.

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

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

Пять семейств средств контроля с разными задачами

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

RFC 8212: отклонять при отсутствии внешней политики

RFC 8212 меняет ожидаемое поведение внешних BGP-сессий так, чтобы маршруты не импортировались и не экспортировались без явно сконфигурированной политики [13]. Его принцип подотчётности важен: внешнее распространение должно требовать осознанной авторизации.

Условие в Майами отличалось от сессии без экспортной политики. Cloudflare описывает явный терм, сохранившийroute-type internalиaccept. Маршрутизатор может удовлетворять наличию сконфигурированной политики, хотя эта политика разрешает слишком много. Отклонение по умолчанию — это базовый уровень, а не семантическое доказательство того, что каждый явный терм безопасен с точки зрения отношений.

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

RFC 7454 и MANRS: дисциплина операционной фильтрации

RFC 7454 собирает операционные рекомендации и рекомендации по безопасности BGP, включая практики фильтрации и политик [14]. MANRS также описывает фильтрацию маршрутов как операционную ответственность [19]. Эти источники поддерживают принцип, что и отправляющая, и принимающая сети должны ограничивать распространение в соответствии с известными полномочиями маршрутизации и отношениями.

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

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

Экспортёр остаётся ответственным за свой Adj-RIB-Out. Защитная фильтрация соседями не должна восприниматься как разрешение отправлять несанкционированные маршруты.

Проверка источника RPKI: авторитет источника, а не полномочия всего пути

Архитектура RPKI предоставляет фреймворк для проверяемых утверждений о ресурсах номеров интернета [15]. Route Origin Authorizations позволяют держателю авторизовать исходную AS для префикса. RFC 6811 определяет проверку источника BGP, RFC 8210 определяет передачу проверенной информации маршрутизаторам, а RFC 7115 обсуждает операционное использование проверки источника [16][17][18].

В раскрытом пути Meta AS32934 осталась источником. Если подходящий ROA авторизовал AS32934, маршрут мог быть валидным по источнику, даже если Cloudflare переносила его через несанкционированное промежуточное отношение. Неверным фактом было не обязательно «кто может создавать этот префикс?», а «можно ли этот маршрут, полученный от пира, экспортировать в сторону этого транзитного провайдера?».

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

Механизм «маршрутизатор — кэш» из RFC 8210 распространяет проверенную информацию об источнике; он не добавляет коммерческую семантику отношений в AS-путь. Операционные рекомендации RFC 7115 также не превращают проверку источника в авторизацию пути.

RFC 9234: Roles и Only-to-Customer

RFC 9234 определяет BGP Roles и атрибут Only-to-Customer, помогая сетям выражать и применять ограничения отношений [12]. Конструкция затрагивает направление распространения, характерное для утечек маршрутов: маршруты, полученные в контекстах, помеченных как подходящие только для доставки клиентам, не должны реэкспортироваться через недопустимые пиринговые или провайдерские пути.

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

Cloudflare сообщила, что проверит поддержку этих механизмов вендорами [1]. Это заявленное направление, а не доказательство того, что Roles и OTC были развёрнуты во время инцидента или позже на каждой релевантной сессии.

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

ASPA: развивающаяся проверка пути

Работа над ASPA предлагает способ, которым AS авторизует своих провайдеров, а полагающиеся сети оценивают отношения провайдеров вдоль AS-путей [20]. Это более прямо касается структуры пути, чем проверка только источника.

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

Поэтому ASPA следует обсуждать условно. Она может улучшить обнаружение или отклонение аномалий политики пути, которые не видит проверка источника. Она не доказывает задним числом, что путь Cloudflare был бы отклонён везде, и её документ не доказывает развёртывание какой-либо AS из примера.

Вместе эти средства образуют уровни, а не замены. RFC 8212 предотвращает несанкционированное внешнее распространение без конфигурации. Локальная экспортная политика определяет точную авторизацию. Сообщества и RFC 9234 могут переносить ограничения отношений. Проверка источника RPKI проверяет полномочия источника. ASPA нацелена на авторизацию пути провайдера. Фильтрация соседями сдерживает ошибки, ускользнувшие из исходной сети. Ничто не снимает необходимости проверять итоговую политику и Adj-RIB-Out.

Проектирование автоматической остановки для режима сбоя в Майами

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

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

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

Матрица отношений должна быть явной:

Происхождение маршрута	Экспорт клиенту	Экспорт пиру	Экспорт провайдеру
Создан Cloudflare	Разрешён при намерении	Разрешён при намерении	Разрешён при намерении
Легитимный нижестоящий клиент	Разрешён согласно услуге	Разрешён согласно соглашению	Разрешён согласно транзитной схеме
Получен от пира	Может доставляться нижестоящим клиентам	Отклонять, если нет конкретного исключения	Отклонять
Получен от провайдера	Может доставляться нижестоящим клиентам	Отклонять	Отклонять в сторону другого провайдера, если это не предусмотрено явно
Неизвестное или недоверенное происхождение	Отклонять до классификации	Отклонять	Отклонять

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

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

Затем candidate Adj-RIB-Out следует рассчитать или зафиксировать без выпуска обновлений, если платформа это позволяет. Сравнение должно включать префикс, источник, путь, next-hop, сообщества и разрешающий терм. Его следует подписывать отдельно для IPv6, поскольку раскрытое воздействие было специфичным для семейства.

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

любой маршрут, полученный от пира, заново анонсированный провайдеру;
любой маршрут, полученный от провайдера, заново анонсированный пиру;
любое добавление префикса за пределами утверждённого объёма Боготы;
исчезновение требуемого сообщества отношений;
неожиданный рост сторонних источников в IPv6 Adj-RIB-Out;
сброс трафика для заново анонсированных префиксов, не являющихся нижестоящими;
коррелированная перегрузка, задержка или потери на пути Майами — Атланта;
публичное наблюдение запрещённого сегмента AS-пути, приписываемого канареечной проверке.

Первые четыре условия должны останавливать изменение до того, как понадобятся доказательства трафика. Сброс, перегрузка и публичные коллекторы — более поздние защиты. Ожидание 12 Гбит/с сброшенного трафика превратило бы профилактический контроль в сигнал о последствиях.

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

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

Доказательства RIB, FIB и межсетевого экрана должны согласовываться

Раскрытое поведение сброса добавляет особенно важный вопрос подотчётности. Cloudflare сообщает, что фильтры её межсетевого экрана отбрасывали трафик для префиксов, не являющихся нижестоящими, с пиком около 12 Гбит/с [1]. Следовательно, фильтры распознали границу полномочий пересылки, которую экспортная политика BGP не сохранила.

Это расхождение можно превратить в профилактический сигнал. Если маршрутизатор анонсирует префикс, а его политика пересылки или межсетевого экрана классифицирует назначение как не-нижестоящее, сеть делает противоречивые заявления: «отправляйте этот трафик мне» в BGP и «я не буду нести это назначение» в плоскости данных.

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

Доказательства RIB и FIB отвечают на разные вопросы. RIB может показать выбранный next-hop и происхождение маршрута. FIB может показать, установлено ли состояние пересылки. Счётчики межсетевого экрана могут показать, отклоняется ли трафик вопреки анонсу. Телеметрия интерфейсов и магистрали может показать, где привлечённый трафик создаёт нагрузку.

В Майами сообщённая перегрузка между Майами и Атлантой указывает, что последствия вышли за пределы внешней сессии, отправившей обновления. Открытая запись не раскрывает, какие префиксы использовали этот путь, как распределялся трафик и прошёл ли каждый отброшенный пакет по примерному AS-пути. Эти детали остаются неизвестными [1].

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

Восстановление требует того же согласия в обратном порядке. Недостаточно, чтобы candidate-конфигурация показывала старую политику. Adj-RIB-Out должен вернуться к базовому уровню, отзывы должны быть отправлены, внешние пути должны сойтись от утечки, сброс должен нормализоваться, а легитимный клиентский трафик — восстановиться.

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

Откат был проблемой непрерывности двух состояний

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

В 20:50, по сообщению Cloudflare, оператор вручную откатил конфигурацию и приостановил автоматизацию [1]. Оба действия были необходимы для стабильного отката. Маршрутизатору требовалось немедленное исправление, а контроллеру — остановка применения всё ещё неотменённого состояния репозитория.

В 21:47 изменение в репозитории было отменено. Это вернуло генерирующий источник в соответствие с желаемым состоянием маршрутизатора. В 22:07 операторы признали автоматизацию исправной. В 22:40 они возобновили её [1].

Эта последовательность даёт полезный шаблон непрерывности:

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

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

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

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

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

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

Коммуникация об инциденте как операционное доказательство

Публикация Cloudflare предоставляет несколько деталей, делающих событие анализируемым: намеченную очистку, сохранившееся условие политики, принимающее действие, семейство адресов, расположение маршрутизатора, направления отношений, пример префикса, пример AS-пути, границу воздействия, измеренные последствия, хронологию реагирования и будущие направления контроля [1].

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

У раскрытия есть и пределы. Оно не включает полную итоговую политику «до и после», полный список утёкших префиксов, изменения Adj-RIB-Out по каждому соседу, все представления публичных коллекторов, детальные доказательства RIB/FIB, эффекты для конкретных клиентов, хронологию оповещений, частную топологию или названных ответственных за решения. Оно не демонстрирует последующую эффективность контроля.

Будущие обязательства следует чётко обозначать как обязательства. Cloudflare заявила, что оценит пустые или ошибочные термы политики в автоматических проверках, добавит меры на основе BGP-сообществ, проверит поддержку вендорами BGP Roles и OTC и улучшит раннее обнаружение [1]. Это подходящие направления для раскрытого режима сбоя. Сама публикация об инциденте не может установить их последующий охват или эффективность.

Материалы Cloudflare о обнаружении утечек маршрутов в Radar, расследовании аномалий, интерфейсах утечек и терминологии маршрутизации дают контекст публичной наблюдаемости BGP [2][3][4][5]. Их не следует использовать для утверждения, что Radar автоматически предотвратил, обнаружил или закрыл именно это событие, если об этом не говорят привязанные к событию доказательства.

Полезное последующее раскрытие сообщало бы результаты, а не намерения: сколько принимающих термов проверено, тестируется ли теперь расширение итоговых наборов маршрутов, какие контроли отношений применяются, прерываются ли автоматически канареечные проверки IPv6 Adj-RIB-Out и как последующие учения показали, что откат остаётся стабильным.

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

Специфичная для события шкала подотчётности

Вопрос подотчётности по Майами	Доступные публично доказательства	Поддерживаемый результат	Недостающие доказательства
Осталась ли очистка Боготы вычитающей после отрисовки?	Cloudflare сообщает, что последнее условие списка префиксов исчезло, а`route-type internal`и`accept`остались [1].	Нет; итоговый смысл расширился за пределы заявленного намерения очистки.	Старые и новые итоговые термы и их оценённые множества совпадений.
Могла ли автоматизация обнаружить вновь недостаточно ограниченный принимающий терм?	Cloudflare назвала оценку пустых или ошибочных термов будущей работой [1].	Профилактическое обнаружение не было продемонстрировано для этого изменения.	Проходящий структурный тест на эквивалентных случаях удаления последнего предиката.
Применялись ли направления «пир» и «провайдер» независимо от списка префиксов?	Маршруты, полученные от пиров и провайдеров, экспортировались в запрещённых направлениях; работа с сообществами и RFC 9234 описана как перспективная [1].	Независимое применение отношений не было продемонстрировано.	Роли по сессиям, доверенные метки происхождения и результаты отклонения.
Содержала ли активация на одном маршрутизаторе внешнюю достижимость?	Один маршрутизатор в Майами отправил маршруты, появившиеся в публичных данных путей [1][7].	Масштаб устройств был узким; масштаб маршрутизации не был сдержан.	Сравнение Adj-RIB-Out до отправки и доказательства автоматического прерывания.
Была ли дельта IPv6-набора маршрутов ограничена до выпуска?	Cloudflare сообщает о воздействии только на IPv6, но не публикует candidate-дельту [1].	Масштаб по семейству адресов известен после события; граница до активации неизвестна.	Добавления и удаления IPv6 по каждому соседу и допустимый конверт.
Подтвердили ли публичные данные маршрутизации раскрытый путь?	Ограниченный запрос BGPlay вернул 1548 событий, 1440 с AS13335 и AS32934 в пути [7].	Да, для запрошенного префикса, временного окна и видимости коллекторов.	Более широкая сверка префиксов и точек наблюдения, если доступна.
Ограничили ли контроли пересылки последствия плохих анонсов?	Cloudflare сообщает, что фильтры межсетевого экрана отбрасывали трафик, не относящийся к нижестоящим, с пиком около 12 Гбит/с, при этом возникли перегрузка, задержка и потери [1].	Сброс ограничил несанкционированный транзит, но не предотвратил привлечение трафика и сопутствующее воздействие.	Корреляция RIB/FIB, межсетевого экрана и трафика по префиксам.
Мог ли ручной откат оставаться стабильным, пока состояние источника было неверным?	Cloudflare откатила маршрутизатор и приостановила автоматизацию в 20:50, затем отменила изменение в репозитории в 21:47 [1].	Реагирование последовательно устранило и действующее, и генерирующее состояния.	Доказательства, что ни один маршрутизатор не получил повторное применение и все экспорты отозваны.
Было ли возобновление основано на поведении маршрутов, а не только на выполнении контроллера?	Автоматизация признана исправной в 22:07 и возобновлена в 22:40 [1].	Вывод о восстановлении и осознанное возобновление раскрыты; критерии — нет.	Результаты итоговой политики, Adj-RIB-Out, RIB/FIB, трафика и внешних путей.
Отделяет ли раскрытие доказательства от неопределённости?	Приведены механизм, хронология, последствия и пример пути, но нет полной топологии, потерь клиентов или доказательств контроля [1].	Сильное специфичное для события раскрытие с существенными открытыми вопросами.	Более поздние доказательства развёртывания и эффективности исправлений.

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

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

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

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

Подтверждённые факты, ограниченные выводы, рекомендации и неизвестное

Подтверждено в пределах приписанных публичных доказательств

Cloudflare публично заявляет, что изменение в репозитории было объединено в 19:52 UTC; автоматизация выполнилась на одном маршрутизаторе в Майами, и воздействие началось в 20:25; расследование началось в 20:40; инцидент зафиксирован в 20:44; оператор вручную откатил конфигурацию и приостановил автоматизацию в 20:50; изменение в репозитории отменено в 21:47; автоматизация признана исправной в 22:07; автоматизация возобновлена в 22:40 [1].

Cloudflare заявляет, что воздействие длилось 25 минут, затронуло только IPv6 и включало перегрузку участка Майами — Атланта, повышенную задержку, увеличенные потери для части клиентского трафика и сброс трафика, не относящегося к нижестоящим, с пиком, оценённым примерно в 12 Гбит/с [1].

Cloudflare заявляет, что удаление последнего условия списка префиксов оставилоroute-type internalиaccept, позволив экспортировать внутренне перераспределённые маршруты пирам и транзитным провайдерам. Компания указывает направление «пир Meta — провайдер Lumen» и публикует пример префикса и AS-путь [1].

Независимо ограниченный запрос RIPEstat вернул публичные события обновлений с соответствующей комбинацией AS в окне события [7]. Независимо подтверждена видимость этого шаблона пути, а не частная причина или измерения воздействия Cloudflare.

Ограниченные выводы

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

Сегмент3356 13335 32934в сочетании с метками отношений Cloudflare поддерживает интерпретацию «пир — провайдер». Сам AS-путь не устанавливает коммерческие отношения.

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

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

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

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

Она также не показывает, были ли более поздние работы по сообществам, оценке политик, обнаружению или RFC 9234 развёрнуты в релевантной сети и остановили ли они эквивалентный сбой.

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

Тест подотчётности пустой экспортной политики

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

Слияние в репозитории показало, что Cloudflare намеревалась изменить. Итоговый терм определил, что маршрутизатор мог принять. Состояние маршрутов определило, какие префиксы подходили. Adj-RIB-Out определил, что мог получить каждый сосед. Публичные коллекторы показали, что просочилось наружу. Измерения трафика и сброса показали последствия. Откат потребовал возврата в безопасное состояние и работающего маршрутизатора, и генерирующего источника.

Каждый уровень несёт свой вид истины. Исходное намерение не может отменить широкий итоговый терм. Валидный источник не может авторизовать промежуточное отношение. Активация на одном маршрутизаторе не гарантирует малый радиус маршрутизации. Успешный прогон контроллера не устанавливает, что отправленные маршруты безопасны. Восстановленная конфигурация сама по себе не доказывает, что внешние пути и трафик восстановились.

Для этого события решающий профилактический вопрос было просто сформулировать: после удаления ссылок на списки префиксов Боготы стал ли какой-либо IPv6-маршрут, полученный от пира или провайдера, заново допустимым для экспорта из Майами?

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

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