Резюме

  • Примерно в 02:24 UTC 6 ноября 2012 года Cloudflare обнаружила, что сервисы Google недоступны из части интернета, и проследила маршруты к адресам Google через Moratel, AS23947, и PCCW, AS3491, перед легитимным источником Google, AS15169 [1].
  • Cloudflare охарактеризовала сбой как ограниченный и продлившийся около 27 минут. По её оценке, могли пострадать 3–5\u00A0% пользователей интернета, причём сильнее всего — в районе Гонконга. Эти цифры остаются оценкой Cloudflare, а не полной независимой переписью [1].
  • Позднее RFC 7908 отнесла инцидент Moratel–PCCW к утечкам маршрутов типа 4: префиксы пирингового партнёра были переданы транзитному провайдеру и распространены за пределы предусмотренной области [2].
  • Изначально Cloudflare сочла вероятным ошибочный анонс. В обновлении приведено заявление Moratel о том, что аномальное состояние вызвал непредвиденный аппаратный сбой и что событие не было злонамеренным [1]. Открытые данные не раскрывают достаточно внутренних доказательств, чтобы определить точный режим отказа.
  • Поверхность подотчётности охватывает и экспорт, и импорт. Moratel должна была не допустить уход неавторизованных маршрутов с соответствующей сессии; PCCW должна была отличать приемлемые маршруты клиента от маршрутов, полученных через другое отношение. Обнаружение, отзыв, сохранение доказательств и проверенный ремонт были общими операционными обязанностями.

Что показывают открытые источники

Cloudflare сообщила, что около 02:24 UTC её сотрудники заметили, что сервисы Google недоступны из её сети. Расследование началось с неудачной проверки доступности DNS, в том числе с невозможности обратиться к публичному резолверу Google 8.8.8.8. Трассировка затем показала, что трафик шёл через адрес Moratel в Индонезии — неожиданный путь для трафика из сети Cloudflare в Калифорнии в сторону Google [1].

Маршрут к префиксу Google, который наблюдала Cloudflare, включал последовательность AS4436, AS3491, AS23947 и AS15169. В этой последовательности AS15169 оставался источником Google. Аномалия была в пути к нему: Moratel появлялась между PCCW и Google в маршруте, который Cloudflare не ожидала получить через такое отношение [1]. Ту же картину Cloudflare наблюдала для публичного DNS-префикса Google.

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

Cloudflare сообщила, что связалась с коллегой в Moratel. Анонс был исправлен примерно в 02:50 UTC, и маршрутизация вернулась в норму примерно через три минуты [1]. В публикации оценивался ограниченный сбой длительностью 27 минут и более сильное влияние в некоторых частях Азии, особенно вокруг Гонконга. Статья не превращает эту оценку в общий подсчёт отказов. У Cloudflare была полезная операционная точка наблюдения, но она не следила за каждым пользователем, каждой сетью или каждым сервисом Google.

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

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

Почему RFC 7908 классифицирует это как утечку маршрутов типа 4

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

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

RFC 7908 определяет утечку маршрута как распространение анонсов маршрутизации за пределы предусмотренной области. Категория типа 4 охватывает сеть, передающую своему транзитному провайдеру маршруты, полученные от бокового пирингового партнёра. RFC называет утечку префиксов Google между Moratel и PCCW примером и говорит, что событие привело к недоступности сервисов Google [2].

Такая классификация задаёт инциденту точную рамку подотчётности. Критический вопрос не только в том, имел ли AS15169 право анонсировать префиксы Google. Вопрос в том, имел ли AS23947 право экспортировать изученный путь Google в сторону AS3491 и должен ли был AS3491 принять и распространить его в соответствии с действующей клиентской или транзитной политикой.

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

Обязанность собирать доказательства на стороне экспортирующей сети

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

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

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

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

Обязанность принимающего оператора по проверке маршрутов

Вторая обязанность по доказательствам лежит на принимающей сети. Cloudflare охарактеризовала PCCW как апстрим-провайдера Moratel и заявила, что PCCW доверилась и распространила маршруты, отправленные Moratel [1]. Текущий RDAP идентифицирует AS3491 как PCCWG-APAC-HK и связывает его с PCCW Global (HK) Limited [6]. Эти текущие идентификационные данные подтверждают непрерывность справочной информации, но сами по себе не доказывают каждый коммерческий термин или роль сессии, существовавшие в 2012 году.

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

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

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

Что могут и чего не могут доказать текущие записи реестров

Текущий RDAP APNIC идентифицирует AS23947 как MORATELINDONAP-AS-ID и связывает операционные контакты с PT. Mora Telematika Indonesia [5]. Текущий RDAP для AS3491 идентифицирует PCCWG-APAC-HK и PCCW Global (HK) Limited [6]. Эти записи помогают привязать номера автономных систем к текущим сетевым идентичностям.

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

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

Исторический ответ RIPEstat о маршрутизации для 8.8.8.0/24 показывает видимость AS15169 как источника в запрошенный день [4]. Его гранулярность — восемь часов, поэтому он не может доказать кратковременный утёкший путь AS или поминутный отзыв. Поэтому статья опирается на современное наблюдение пути Cloudflare и более позднюю классификацию RFC 7908, а ответ RIPEstat рассматривает лишь как ограниченный исторический контекст.

Контроли, отказывающие в безопасную сторону

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

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

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

Четвёртый контроль — сигнализация, учитывающая отношения. RFC 9234, опубликованная значительно позже инцидента, определяет роли BGP и атрибут Only-to-Customer. Эти механизмы могут сделать границы отношений более машиночитаемыми и помочь обнаруживать пути, нарушающие ожидаемые правила распространения [3]. Это полезный контекст контроля, а не доказательство того, что какой-либо оператор использовал их в 2012 году.

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

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

Полезное публичное подведение итогов инцидента

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

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

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

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

Почему этот инцидент по-прежнему важен

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

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

Самый сильный вывод — узкий. Открытые доказательства подтверждают, что утечка маршрутов между Moratel и PCCW повлияла на доступность сервисов Google 6 ноября 2012 года, что Cloudflare наблюдала аномальный путь и помогла эскалировать проблему, и что RFC 7908 позднее классифицировала событие как утечку от пирингового партнёра к транзитному провайдеру [1][2]. Открытые доказательства не устанавливают внутреннюю последовательность сбоев и не распределяют окончательную ответственность.

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

Источники

  1. https://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about/
  2. https://www.rfc-editor.org/rfc/rfc7908.txt
  3. https://www.rfc-editor.org/rfc/rfc9234.txt
  4. https://stat.ripe.net/data/routing-history/data.json?resource=8.8.8.0/24&starttime=2012-11-06T00:00:00&endtime=2012-11-07T00:00:00
  5. https://rdap.apnic.net/autnum/23947
  6. https://rdap.arin.net/registry/autnum/3491