Резюме

  • Cloudflare сообщила о двух разных событиях маршрутизации 27 июня 2024 года. AS267613 начал анонсировать более специфичный маршрут1.1.1.1/32, а AS262504 передал1.1.1.0/24вышестоящему провайдеру AS1031. Они затронули один и тот же адрес резолвера, но это не один и тот же анонс, путь или сбой управления [1].

  • Маршрут/32был более специфичным, чем обычный анонс Cloudflare/24. Cloudflare сообщила, что несколько сетей использовали его для пересылки, хотя его источник и длина префикса делали его недействительным по RPKI и непригодным для зоны без маршрута по умолчанию. Один провайдер первого уровня, как сообщается, принял его как маршрут удалённо запускаемого blackhole, из-за чего трафик из нижестоящих сетей этого провайдера отбрасывался [1].

  • Утёкший маршрут/24представлял другую проблему проверки. Его путь по-прежнему заканчивался на AS13335 Cloudflare, поэтому проверка источника маршрута могла считать источник действительным, даже если путь распространения «клиент — провайдер» и пиринговый путь были несанкционированными. Действительный ROA не авторизует каждое промежуточное отношение между AS [1][2][6][9].

  • Cloudflare сообщила, что завела внутренний инцидент в 20:03 UTC, отключила две точки пиринга с AS267613, связалась с названными сетями и зафиксировала полное устранение утечки/24в 02:28 UTC 28 июня. По сообщениям, пользователи либо не могли достичь 1.1.1.1, либо наблюдали высокую задержку. Cloudflare также отметила, что показанный трафик представлял относительно небольшую долю запросов из приведённых в примере стран [1].

  • Независимый комментарий APNIC отмечал, что событие не было глобально видимым и, вероятно, было незначительным относительно общей базы пользователей интернета, хотя всё же могло затронуть многих пользователей. Internet Society Pulse сообщил о более широкой картине наблюдений. Эти описания следует сохранять с указанием источника, а не объединять в неподтверждённое заявление о глобальном сбое [2][3].

  • Записи распределения APNIC и ROA Cloudflare — важные свидетельства об адресном блоке и авторизованном источнике. Они не программируют фильтры импорта в других сетях. Операционная непрерывность зависит от политик, которые фактически применяют исходные сети, клиенты, маршрутные серверы, транзитные провайдеры и системы blackhole [4][5][6].

  • RFC 4271, RFC 7908, RFC 6811, RFC 8893, RFC 7454 и RFC 8212 определяют контекст BGP, утечек маршрутов, проверки источника и фильтрации. RFC 9234 добавляет роли с учётом отношений и атрибут Only-to-Customer. RFC 7999 и RFC 3882 объясняют сигнализацию blackhole и удалённо запускаемый blackhole. Эти документы описывают доступные средства контроля, а не доказательство того, что каждая затронутая сеть их развернула [7]–[15].

  • RouteViews и RIPE RIS сохранили публичные наблюдения, которые помогли восстановить картину распространения. Коллекторы — это системы свидетельств, а не органы маршрутизации. Проверка подотчётности состоит в том, какая сторона могла предотвратить, отклонить, обнаружить, локализовать или отменить каждый маршрут и какая запись доказывает, что контроль сработал [16][17].

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

Визуальная простота1.1.1.1скрывает цепочку независимых решений. Пользователь вводит или настраивает один адрес. Локальное устройство отправляет пакет. Сеть выбирает маршрут. Транзитные провайдеры сравнивают альтернативы. Маршрутные серверы распространяют анонсы. Anycast-узлы Cloudflare анонсируют доступность. Реестр хранит информацию о номерных ресурсах, а RPKI может привязать префикс к авторизованному источнику. Каждый шаг отвечает на свой вопрос.

Инцидент важен тем, что два плохих пути могли по-разному влиять на эту цепочку. Один был анонсом источника для одного адреса. Другой — утечкой покрывающего/24. Первый поставил под сомнение авторизацию источника и длины префикса, а также средства контроля blackhole. Второй — экспортные политики с учётом отношений и фильтрацию клиентских маршрутов, хотя в конце AS-пути оставался источник Cloudflare [1].

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

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

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

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

Опубликованная Cloudflare хронология начинается в 18:51 UTC 27 июня, когда AS267613 начал анонсировать1.1.1.1/32пирам, провайдерам и клиентам, указывая AS267613 как источник. Минутой позже, по данным Cloudflare, AS262504 передал вышестоящему провайдеру AS1031 маршрут1.1.1.0/24, полученный через AS267613. Раскрытый путь был1031 262504 267613 13335. Cloudflare сообщила, что AS1031 затем распространил/24среди пиров на интернет-обменниках и маршрутных серверов [1].

В тот же момент 18:52, по данным Cloudflare, провайдер первого уровня получил/32от AS267613 как маршрут RTBH. Трафик, использующий маршрут этого провайдера к 1.1.1.1, отбрасывался. Это отдельный причинный путь, отличный от утечки/24: провайдер обработал host-маршрут как инструкцию отбрасывания, тогда как другие сети узнали покрывающий префикс через утёкший AS-путь [1].

Cloudflare завела внутренний инцидент в 20:03 после сообщений о недоступности из нескольких стран. В 20:08 она отключила партнёрскую точку пиринга с AS267613, которая получала трафик для/24, и связалась с AS267613. В 20:10 Cloudflare обнаружила новый утёкший путь для/24; по её словам, трафик, следовавший по этому пути, достигал Cloudflare, но с высокой задержкой. В 20:17 она связалась с AS262504 по поводу вышестоящей утечки [1].

Реагирование продолжалось и после первой локализации. Cloudflare сообщила, что отключила вторую точку пиринга с AS267613 в 21:56, поскольку та получала трафик для префикса из источников за пределами Бразилии. В 22:16 очередная утечка/24привлекла часть трафика к точке пиринга Cloudflare в Сан-Паулу. К этому времени перехват host-маршрута и blackhole, судя по всему, были устранены, хотя некоторые запросы всё ещё возвращались с повышенной задержкой. Cloudflare зафиксировала полное устранение утечки/24в 02:28 UTC 28 июня [1].

Эта последовательность не описывает один непрерывный опыт для каждого пользователя. Маршруты могут осциллировать. Разные сети могут принимать разные пути. Часть трафика могла отбрасываться, часть — следовать длинным путём к работающему узлу Cloudflare, а часть — оставаться на незатронутом пути. Cloudflare описала видимые пользователям результаты как невозможность достичь 1.1.1.1 или успешную доступность с высокой задержкой. Её примерные графики охватывали Германию и США, а не все исходные сети [1].

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

Почему host-маршрут мог переопределить обычную anycast-доступность

Cloudflare обычно анонсирует покрывающий1.1.1.0/24из многих точек в рамках anycast-сервиса. Anycast позволяет одному адресу быть доступным через несколько узлов, при этом политика BGP и топология влияют на то, какой узел выбирает сеть. Такая схема обеспечивает масштаб и близость, но по-прежнему зависит от того, что система маршрутизации выбирает авторизованный маршрут.

Пересылка IP использует выбор самого длинного префикса. Маршрут/32обозначает один адрес IPv4 и является более специфичным, чем маршрут/24, покрывающий 256 адресов. Если обе записи попадают в таблицу пересылки,/32выигрывает для пакетов к 1.1.1.1 независимо от того, имеет ли/24более привлекательный AS-путь. Это механическое правило объясняет, почему host-маршрут может перенаправить или отбросить трафик для одного адреса, не заменяя покрывающий маршрут для всех адресов блока.

В зоне без маршрута по умолчанию обычно фильтруются IPv4-маршруты длиннее/24. Cloudflare сообщила, что видела/32у нескольких публичных коллекторов и в данных мониторинга BGP до применения политики от маршрутных серверов. Она заявила, что её собственная политика импорта отклонила маршрут как недействительный по RPKI и недействительный для зоны без маршрута по умолчанию. Наблюдение до применения политики оставалось ценным, потому что показывало, что сосед отправил обновление, хотя Cloudflare его не установила [1].

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

ROA Cloudflare авторизовал AS13335 для1.1.1.0/24с максимальной длиной/24. Маршрут1.1.1.1/32, анонсированный AS267613, поэтому не соответствовал ни условию источника, ни условию максимальной длины, описанным проверкой источника. Сеть, выполняющая проверку источника маршрута, могла классифицировать маршрут как недействительный и связать это состояние с политикой отклонения [1][6][9].

Ключевое слово — «могла». RFC 6811 определяет проверку источника, а не всеобщий мандат на развёртывание. RFC 8893 объясняет терминологию и операционные соображения. Сеть может получать данные RPKI, но не применять их последовательно. Она может классифицировать маршрут, не отклоняя его. Она может создавать исключения. Маршрутный сервер и его клиенты могут применять разные политики. Запись доказывает, что основа для проверки существовала; она не доказывает, как ею воспользовалась каждая сеть [9][10].

RTBH превратил авторизацию в доступность

Самое существенное утверждение Cloudflare о/32состоит в том, что транзитный провайдер первого уровня принял его как маршрут удалённо запускаемого blackhole. RTBH — легитимный и широко используемый механизм защиты. Во время атаки типа «отказ в обслуживании» клиент может попросить провайдера отбрасывать трафик к цели до того, как этот трафик перегрузит соединение клиента. Пожертвовав доступностью одной цели, можно сохранить работоспособность остального сервиса.

RFC 7999 определяет общеизвестное сообществоBLACKHOLEдля сигнализации о том, что маршрут следует отбрасывать. Он требует строгого ограничения области действия и фильтрации, поскольку эффект сообщества разрушителен по замыслу. RFC 3882 описывает метод удалённо запускаемого blackhole, при котором маршрут и поведение пересылки координируются для отбрасывания трафика. Ни один документ не означает, что любой сосед вправе запрашивать отбрасывание для любого адреса [14][15].

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

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

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

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

Утечка/24прошла проверку источника, но не прошла проверку пути

Утёкший1.1.1.0/24иллюстрирует дополнительное ограничение авторизации источника маршрута. В раскрытых Cloudflare путях AS13335 оставался крайним правым источником. Если валидатор спрашивает только, может ли AS13335 анонсировать/24, ответ может быть «действителен». Это не отвечает на вопрос, должен ли AS267613 экспортировать маршрут в AS262504, должен ли AS262504 экспортировать его в AS1031 или должен ли AS1031 распространять его среди пиров и маршрутных серверов [1].

AS-путь в BGP — это одновременно механизм предотвращения петель и свидетельство о распространении. Это не подписанный коммерческий договор. Путь, содержащий авторизованный источник, всё равно может нарушать ожидаемые отношения «клиент — провайдер» или пиринговые отношения. RFC 7908 определяет утечки маршрутов как распространение за пределы предполагаемой области действия и предлагает таксономию типичных сбоев отношений [8].

В отчёте Cloudflare анализируется примерный путь и выделяется критический переход на AS262504. AS267613 описывается как функциональный пир Cloudflare, а AS262504 — как клиент AS267613. Согласно этому описанию, AS262504 получил маршрут Cloudflare со стороны своего провайдера, а затем анонсировал его вышестоящему провайдеру AS1031. Cloudflare сообщила, что AS1031 принял маршрут от своего клиента и перераспределил его в нескольких точках пиринга [1].

Эти утверждения об отношениях исходят из анализа Cloudflare и должны сохраняться с указанием источника. Тем не менее они выявляют конкретные средства контроля. Провайдер может вести явный список префиксов, которые клиент вправе анонсировать или объявлять. Он может использовать состояние источника по RPKI, данные Internet Routing Registry и наблюдаемые сведения о клиентском конусе как доказательства. Он может ограничивать количество принимаемых маршрутов, отклонять неожиданные источники или паттерны путей и не позволять клиенту становиться транзитом для произвольных интернет-маршрутов.

RFC 7454 описывает операционные практики BGP, включая фильтрацию маршрутов, получаемых от клиентов и пиров. RFC 8212 меняет опасное историческое значение по умолчанию, требуя явной политики импорта и экспорта для маршрутов eBGP в соответствующем поведении. Эти меры снижают случайную открытость, но не обнаруживают автоматически, что явная клиентская политика слишком широка. Фильтр, который проверяет только соседнюю AS, всё равно может принять маршрут, который клиент не был уполномочен распространять [11][12].

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

Роли и OTC добавляют сведения об отношениях

RFC 9234 решает проблему утечек маршрутов с помощью ролей BGP и атрибута Only-to-Customer. Роли позволяют двум участникам eBGP описать свои отношения, например «провайдер», «клиент», «пир» или «маршрутный сервер». OTC может пометить маршрут так, чтобы принимающая сеть могла обнаружить распространение, несовместимое с этими ролями [13].

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

OTC не является ретроспективным доказательством того, что произошло в июне 2024 года. Используемые здесь публичные материалы не устанавливают, согласовывали ли AS267613, AS262504, AS1031, их маршрутные серверы или затронутые нижестоящие сети роли и применяли ли OTC. Стандарт полезен как контрольный ориентир, потому что он определяет применимую границу, соответствующую классу сбоя. Его нельзя описывать как средство контроля, о котором известно, что оно отказало в этом событии.

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

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

Записи распределения и ROA — это доказательства, а не дистанционное управление

История1.1.1.0/24делает особенно заметным слой учёта. В рамках prop-109 APNIC распределила1.0.0.0/24и1.1.1.0/24лаборатории APNIC Labs как исследовательские префиксы. В материалах политики описаны адресные блоки, привлекавшие значительный незапрошенный трафик, поскольку их долго использовали в примерах и частных конфигурациях. Позднее APNIC заключила соглашение, в рамках которого Cloudflare управляет сервисом резолвера 1.1.1.1 [2][4][5].

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

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

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

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

Коллекторы показывают распространение, а не каждое решение о пересылке

Cloudflare использовала публичные коллекторы маршрутов, чтобы показать наблюдения/32и/24. RouteViews и RIPE RIS получают потоки BGP от участвующих сетей и сохраняют обновления и снимки таблиц. Их данные помогают установить, когда маршрут был виден коллектору, какой пир его отправил, какой AS-путь и атрибуты были записаны и когда появился отзыв или замена [1][16][17].

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

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

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

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

Влияние было реальным, но неоднородным и не измеренным глобально

Cloudflare сообщила, что затронутые пользователи либо не могли достичь 1.1.1.1, либо могли достичь его только с высокой задержкой. Blackhole-маршрут объясняет один режим отказа: трафик отбрасывался до достижения Cloudflare. Утечка/24объясняет другой: трафик мог следовать в сторону Бразилии и в итоге достигать узла Cloudflare по пути, значительно более длинному, чем обычный anycast-выбор [1].

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

Комментарий APNIC гласит, что событие не было глобально видимым и, вероятно, было незначительным относительно общей базы пользователей интернета, хотя большое абсолютное число пользователей могло пострадать. Internet Society Pulse описал наблюдения во многих сетях и странах. Разные системы видимости, определения и точки наблюдения могут давать разные описания масштаба [2][3].

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

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

Локализация Cloudflare показала пределы односторонних действий

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

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

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

Cloudflare также несла ответственность за мониторинг высокозаметного сервиса с разных точек наблюдения. Публичная хронология показывает более часа между первым раскрытым анонсом и внутренним инцидентом в 20:03. Сам по себе этот интервал не доказывает сбой мониторинга: публичные материалы не сообщают, когда влияние пересекло порог оповещения, какие сигналы были доступны и были ли более ранние события видны системам Cloudflare. Но он задаёт вопрос для проверки: какое наблюдение должно было обнаружить неожиданный источник или путь и как быстро следовало эскалировать?

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

Предотвращение нужно оценивать на каждой границе

Граница анонсирования для/32должна не позволять AS объявлять host-маршрут для адреса, который он не уполномочен анонсировать. Проверка конфигурации до активации может сравнивать предполагаемые префиксы с данными реестра, IRR и RPKI. Экспортная политика может ограничивать анонсируемые префиксы по соседу и сервису. Максимальная длина префикса может остановить/32, когда авторизован только/24. Мониторинг после изменений может сравнивать фактический Adj-RIB-Out с утверждённым набором.

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

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

Граница распространения/24требует контроля клиентов и ролей. Если анализ отношений Cloudflare верен, экспортная политика AS262504 должна была помешать отправке маршрута, полученного от провайдера, другому провайдеру. Политика AS1031 для клиентов должна была отклонить маршрут за пределами авторизованного набора клиента или несовместимый с отношением. Маршрутные серверы должны применять или включать средства контроля, соответствующие их операционной модели, а участники не должны предполагать, что маршрутный сервер делает каждый клиентский маршрут безопасным.

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

Наконец, граница доказательств требует хранения. Версии конфигурации, результаты проверки, обновления BGP, решения RIB, состояние FIB, активации blackhole, наблюдения коллекторов, изменения пиринга и переписка по инциденту должны иметь согласованные временные метки. Без этой цепочки операторы могут восстановить сервис, но не смогут объяснить, какой контроль отказал, или доказать, что исправление устраняет класс сбоя.

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

Одного оповещения «аномалия маршрута» для этого инцидента недостаточно./32мог вызвать оповещение о неожиданном источнике, оповещение о недействительности RPKI и оповещение о чрезмерной длине префикса./24мог не вызвать первые два, потому что AS13335 оставался источником, а длина префикса была допустимой. Ему нужен анализ отношений пути или авторизации клиента.

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

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

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

Локализация и восстановление требуют независимых доказательств

Локализация host-маршрута означает прекращение его анонсирования, удаление из политики blackhole и пересылки, а также подтверждение отзывов на внешних точках наблюдения. Локализация утечки/24означает прекращение несанкционированного экспорта на AS262504 и дальнейшего распространения на AS1031 и в других сетях. Изменения пиринга Cloudflare сократили пути трафика под её контролем, но не заменили эти отзывы.

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

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

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

Ограниченная матрица подотчётности

Исходная AS для/32контролировала, был ли создан и экспортирован host-маршрут. Её доказательства должны включать утверждённые списки префиксов, записи об изменениях конфигурации, Adj-RIB-Out и подтверждение отзыва. Публичные материалы фиксируют наблюдаемый анонс, но не раскрывают внутреннюю причину или намерение.

AS262504 контролировала, экспортировался ли/24, полученный по одному отношению, вышестоящему провайдеру. Соответствующие доказательства — роль соседа, источник импорта, экспортная политика, авторизация маршрута и исправление после инцидента. Cloudflare называет её сетью, допустившей утечку; более полный внутренний отчёт в использованных публичных материалах отсутствует [1].

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

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

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

APNIC и система RPKI контролировали целостность записей в рамках своих определённых ролей. Записи распределения и авторизации дали доказательства, которые могли поддержать отклонение. Они не контролировали каждый опирающийся маршрутизатор. Их подотчётность — точность, доступность и безопасная публикация записей, а не прямая ответственность за политику приёма другого оператора [4][5][6].

RouteViews и RIPE RIS контролировали работу коллекторов и публикацию доказательств. Они помогли сделать внешнее распространение проверяемым. Они не авторизовали маршруты, не выбирали их для пересылки клиентам и не отзывали их. Их ценность — независимая проверка реальности того, какие части системы маршрутизации оказались открыты [16][17].

Что стандарты могут и не могут доказать

RFC 4271 объясняет механизм BGP, посредством которого автономные системы обмениваются сведениями о доступности. Он не возлагает ответственность за это событие. RFC 7908 предлагает категории утечек маршрутов, но классификация зависит от фактов об отношениях, которые могут быть частными или спорными. RFC 6811 и RFC 8893 объясняют проверку источника, тогда как фактическое отклонение остаётся локальной политикой [7]–[10].

RFC 7454 и RFC 8212 дают серьёзные основания для явных фильтров и политик. Они не доказывают, что у конкретного оператора не было политики, и не гарантируют, что явная политика достаточно узка. RFC 9234 предоставляет роли и OTC, но исходные материалы не устанавливают их развёртывание участниками инцидента [11]–[13].

RFC 7999 и RFC 3882 показывают, что blackholing — это преднамеренный механизм управления сетью с серьёзными требованиями к области действия и авторизации. Они не указывают точную реализацию сигнализации, использованную неназванным провайдером первого уровня. Специфическое для инцидента утверждение остаётся приписанным Cloudflare сообщением о том, что/32был принят как RTBH [1][14][15].

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

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

Инцидент июня 2024 года показывает, почему подотчётность в интернете не может останавливаться на владении ресурсами. Записи APNIC и ROA Cloudflare дали серьёзные доказательства. Собственная политика импорта Cloudflare, как сообщается, использовала эти доказательства для отклонения/32. Другие сети всё же принимали, распространяли или исполняли маршруты, которые не должны были определять доступность 1.1.1.1 [1][4][5][6].

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

Практическая проверка строится на пяти вопросах.

Во-первых, предотвращение: мог ли оператор до активации доказать, что сосед был уполномочен анонсировать, распространять или отбрасывать этот префикс такой длины?

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

В-третьих, наблюдение: могли ли внутренняя телеметрия и независимые коллекторы показать, когда маршрут был получен, принят, экспортирован, выбран и отозван?

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

В-пятых, восстановление: вернулись ли состояние маршрутов, пересылка и производительность резолвера к норме, и показал ли повторяемый тест, что тот же сбой авторизации больше не проходит?

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

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

Инцидент Cloudflare с 1.1.1.1 не показал, что какое-то одно средство контроля бесполезно. Он показал, почему несколько средств должны быть взаимосвязаны. Проверка источника могла отклонить/32, но не утёкший путь с действительным источником. Политика отношений могла ограничить/24, но сама по себе не авторизовала бы RTBH. Записи распределения задали контекст ресурса, но не могли принудительно применить фильтры. Коллекторы выявили распространение, но не могли его отозвать.

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

Источники

  1. https://blog.cloudflare.com/cloudflare-1111-incident-on-june-27-2024/
  2. https://blog.apnic.net/2024/08/02/when-routing-breaks-your-open-dns-service/
  3. https://pulse.internetsociety.org/en/news/2024/07/cloudflare-dns-outage-traced-to-bgp-hijacking-incident/
  4. https://www.apnic.net/community/policy/proposals/prop-109/
  5. https://www.apnic.net/wp-content/uploads/prop-109/assets/prop-109-v001.txt
  6. https://rpki.cloudflare.com/?prefix=1.1.1.0%2F24&view=explorer
  7. https://www.rfc-editor.org/rfc/rfc4271
  8. https://www.rfc-editor.org/rfc/rfc7908
  9. https://www.rfc-editor.org/rfc/rfc6811
  10. https://www.rfc-editor.org/rfc/rfc8893
  11. https://www.rfc-editor.org/rfc/rfc7454
  12. https://www.rfc-editor.org/rfc/rfc8212
  13. https://www.rfc-editor.org/rfc/rfc9234
  14. https://www.rfc-editor.org/rfc/rfc7999
  15. https://www.rfc-editor.org/rfc/rfc3882
  16. https://www.routeviews.org/routeviews/
  17. https://ris.ripe.net/docs/