Cloudflare, утечка маршрутов в июне 2019 года и подотчётность за пределами сетевого периметра

Краткое содержание

• 24 июня 2019 года оптимизированные, более специфичные маршруты, сгенерированные внутри сети DQE Communications, были переданы через клиентскую AS396531 и приняты AS701 компании Verizon. Verizon затем распространила пути, охватывающие тысячи сетей. Поскольку маршрутизаторы предпочитают более специфичный префикс назначения, значительная часть трафика последовала по утёкшим путям в каналы, не рассчитанные на такую нагрузку; Cloudflare сообщила о потере около 15 % своего глобального трафика в худшей точке инцидента.
• Публичная запись маршрутов подтверждает цепочку отказов контроля, а не объяснение единственной причиной. Генератор маршрутов не удержал свои оптимизационные маршруты локально, мультигомный клиент экспортировал маршруты, полученные от провайдера, другому провайдеру, а крупная транзитная сеть приняла и распространила маршруты, не соответствовавшие ожидаемой маршрутной компетенции клиента. Cloudflare могла обнаружить, сообщить и помочь отозвать маршруты, но не могла в одностороннем порядке изменить импортную политику другой сети.
• Валидация происхождения маршрута (RPKI) была необычно хорошо применима к части инцидента, касающейся Cloudflare, поскольку её авторизации происхождения маршрута (ROA) разрешали агрегированные префиксы только до указанной максимальной длины. Утёкшие более специфичные маршруты превышали эту длину и потому были недействительными. Это не делает RPKI полным решением проблемы утечек маршрутов: пути с действительным происхождением всё равно могут нарушать коммерческие отношения, поэтому остаются необходимыми фильтрация клиентов, ограничения префиксов, роли BGP, контроль путей, мониторинг и доступные операционные контакты.
• Подотчётность следует за возможностью контроля. Операторы, генерирующие или экспортирующие исключительные маршруты, должны сдерживать и тестировать их; провайдеры должны проверять, что клиенты могут анонсировать; облачные платформы обязаны публиковать маршрутные полномочия, наблюдать за внешними путями, быстро координироваться и раскрывать влияние на клиентов; клиенты должны планировать отказ зависимостей; советы директоров и регуляторы должны требовать измеримых гарантий безопасности маршрутизации, а не общих заявлений о следовании отраслевым лучшим практикам.

Сбой маршрутизации, а не отказ серверов Cloudflare

В 10:34:25 UTC 24 июня 2019 года публичные коллекторы BGP начали фиксировать аномальные, более специфичные маршруты для адресного пространства Cloudflare. Последний из изученных маршрутов Cloudflare исчез в 12:38:54 UTC. Подробный разбор архивных маршрутовCloudflareвосстанавливает этот интервал по данным RIPE NCC и показывает удивительно согласованный путь: AS13335 Cloudflare, один из её транзитных провайдеров, AS33154 DQE Communications, AS396531 компании Allegheny Technologies и AS701 компании Verizon. Другие сети затем узнавали маршрут через Verizon.

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

В современном объяснении инцидентакомпания Cloudflareсообщила, что в худшей точке потеряла примерно 15 % глобального трафика. Это корпоративное измерение, а не независимо проверенный универсальный процент сбоя. Оно описывает трафик Cloudflare, а не 15 % всего интернета. Тем не менее независимые наблюдения подтверждают общий механизм и влияние на разные сервисы. ThousandEyes в своёманализе сетевых путейсообщила, что пользователи в течение примерно двух часов испытывали трудности с доступом к сервисам на базе Cloudflare и некоторым сервисам AWS, а Catchpoint вобзоре инцидентазафиксировала проблемы с производительностью у перечисленных онлайн-сервисов около 10:30 UTC.

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

Взаписи о статусеCloudflare сначала описывались проблемы с производительностью сети, затем была указана возможная утечка маршрутов, а позже сказано, что ответственная сеть устранила проблему. Публичные копии обновлений статуса относят уведомление о расследовании к 11:02 UTC, идентификацию — к 11:36 UTC, а мониторинг после исправления — к 12:42 UTC. Архив BGP показывает аномальные маршруты до первого уведомления о статусе. Эта разница не доказывает, что Cloudflare игнорировала известное событие в течение 28 минут.

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

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

Как локальная оптимизация стала глобальным маршрутом

Интернет — это соглашение между автономными системами, а не централизованно управляемая сеть. Каждая автономная система использует протокол BGP, чтобы сообщать соседним системам, какие IP-префиксы она может достичь и через какой путь AS. Базовый протокол вRFC 4271даёт операторам значительную свободу политики. Эта гибкость поддерживает коммерческий пиринг, платный транзит, мультигоминг, инженерию трафика и локальные предпочтения. Она также означает, что маршрут, полученный от соседа, не сопровождается универсальным доказательством того, что каждая AS в пути намеревалась распространять анонс так далеко.

До инцидента DQE использовала продукт оптимизации BGP от Noction. Такой продукт может измерять производительность путей и вносить более специфичные маршруты, чтобы влиять на то, какой канал несёт выбранный трафик. В опубликованном Cloudflare примере обычный анонс104.20.0.0/20был разделён на104.20.0.0/21и104.20.8.0/21. Два /21 покрывают тот же диапазон адресов, что и /20, но каждый задаёт меньший блок назначения.

Внутри контролируемой сети более специфичные маршруты могут быть законным инструментом инженерии трафика. Опасность — в области действия. Маршруты предназначались для влияния на внутренние решения DQE. DQE анонсировала их в AS396531. AS396531 была подключена и к DQE, и к Verizon и экспортировала полученные маршруты в сторону Verizon. Verizon приняла их от своего клиента и распространила дальше. Локальная инструкция стала глобальным заявлением.

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

Это не независимый разбор, и он не публикует точную конфигурацию, запись изменений или результаты тестов развёртывания у DQE.

Отдельныйанализ маршрутизации Qrator Labsсвязывает начало с восстановлением сеанса BGP между AS396531 и Verizon вскоре после 10:35 UTC. Согласно его описанию, AS396531 потеряла фильтры и экспортировала маршруты, полученные от DQE. Это даёт правдоподобный триггер того, почему состояние началось именно тогда, но доступная публичная запись не содержит конфигураций маршрутизаторов или журналов от AS396531, DQE или Verizon. Безопасный вывод уже: наблюдаемый путь доказывает, что маршруты пересекли эти границы AS; описания операторов указывают на отсутствующие или неадекватные фильтры; точная последовательность внутренних изменений остаётся непубличной.

Это различие предотвращает три распространённые ошибки. Во-первых, DQE не следует описывать как источник адресного пространства Cloudflare в смысле BGP. Наблюдаемый путь AS по-прежнему заканчивался на AS13335 Cloudflare. Оптимизатор DQE создал и распространил более специфичный путь с сохранённым законным источником. Во-вторых, Verizon не изобретала маршруты, но её принятие и глобальное распространение значительно расширили их охват. В-третьих, сеть Cloudflare не выбирала AS396531 как предпочтительный путь. Удалённые сети принимали решения о пересылке на основе полученных анонсов.

Почему более специфичные маршруты победили расстояние и anycast

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

Предположим, маршрутизатор знает, что104.20.0.0/20Cloudflare достижим через обычного провайдера, а также узнаёт104.20.0.0/21через Verizon, AS396531 и DQE. Назначение внутри первой /21 соответствует обоим анонсам. /21 более специфична, поэтому она побеждает, даже если её путь AS длиннее или операционально абсурден. Обычные атрибуты пути выбирают среди маршрутов к одному и тому же префиксу; они не позволяют здоровой /20 победить принятую /21.

Именно поэтому инфраструктура anycast Cloudflare не обошла проблему автоматически. Anycast позволяет многим площадкам Cloudflare анонсировать одни и те же префиксы, позволяя BGP выбрать подходящий экземпляр. Он обеспечивает географическое распределение и может поглощать отказы отдельных сайтов или каналов. Но утёкшие /21 были более специфичными, чем обычные анонсы /20 Cloudflare. Глобальная система маршрутизации могла предпочесть /21 до сравнения того, какая anycast-площадка Cloudflare ближе. Избыточность за проигравшим маршрутом не восстанавливала трафик.

Нежелательный путь также концентрировал нагрузку. AS396531 и её соединения не были спроектированы как глобальный транзит для Cloudflare, Amazon, Linode и многих других затронутых сетей. Трафик, привлечённый более специфичными анонсами, попадал в коридор без достаточной пропускной способности или политики. Пакеты задерживались или отбрасывались. Утечка маршрутов иногда может доставлять трафик по неэффективному пути; здесь масштаб превратил путь в узкое место.

Таксономия утечек маршрутовRFC 7908от Internet Engineering Task Force определяет утечку маршрута как распространение за пределы предполагаемой области анонса. Событие июня 2019 года сочетает признаки, которые таксономия разделяет для аналитических целей. В нём участвовали маршруты, полученные от провайдера и экспортированные мультигомной сетью другому провайдеру, что напоминает классическую схему разворота, и внутренне полезные более специфичные маршруты, которые никогда не предназначались для глобального распространения.

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

Хронология и расширяющееся окно подотчётности

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

Самый важный период начался до первой отметки времени. Если совет директоров начинает свой разбор в 10:34, он сосредоточится на оповещениях и звонках. Если он начинает, когда оптимизаторные маршруты были разрешены к эксплуатации, он может изучить безопасность конструкции, область действия маршрутов, настройки fail-closed, политики пиринга, контроль изменений и независимые тесты распространения. Реагирование на инцидент сократило продолжительность. Превентивные меры определяли, будет ли вообще инцидент, на который нужно реагировать.

Четыре возможности фильтрации отказали в одном направлении

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

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

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

Экспортный контроль мультигомного клиента.AS396531 не должна была предлагать другому провайдеру полные или оптимизированные маршруты одного провайдера, если только она намеренно не действовала как транзит. Листовая или корпоративная сеть может применить простое исходящее правило: анонсировать только свои авторизованные префиксы и явно одобренные клиентские префиксы. Запрет по умолчанию надёжнее, чем попытка определить каждый маршрут, который не должен покидать сеть.RFC 8212, опубликованный в 2017 году, закрепил отклонение внешних BGP-объявлений по умолчанию при отсутствии явно настроенной импортной или экспортной политики.

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

Входной контроль клиента у провайдера.У Verizon была точка остановки с наибольшим рычагом влияния. Транзитный провайдер знает, какой сеанс является клиентским, и должен знать, какие префиксы клиент уполномочен объявлять как источник или транзит. Подробный разбор Cloudflare показал, что информация реестра маршрутов, связанная с клиентом, не включала ASN Cloudflare или другие утёкшие сети. Поэтому клиентский префиксный и AS-path фильтр мог бы отклонить эти анонсы.

Руководство по эксплуатации и безопасности BGP в RFC 7454, опубликованное в 2015 году, рекомендует политики для маршрутов, получаемых и анонсируемых на каждой границе, контроль клиентских префиксов, фильтрацию AS-path и ограничения максимального числа префиксов.

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

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

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

RPKI могла бы заблокировать эти маршруты, но это не полное решение

Cloudflare начала подписывать маршруты и внедрять валидацию в 2018 году, как описано в еёотчёте о развёртывании RPKI. Авторизация происхождения маршрута (ROA) указывает, какая автономная система может объявлять префикс и, опционально, наиболее специфичную длину префикса, которую она может анонсировать. Cloudflare сообщает, что её соответствующие маршруты авторизовали AS13335 с максимальной длиной /20. Утёкшие /21 сохраняли AS13335 как источник, но превышали авторизованную максимальную длину. Поэтому они были недействительны согласно валидации происхождения маршрута.

Логика формализована вRFC 6811. Полученный маршрут действителен, если проверенная запись ROA покрывает префикс, ASN источника совпадает и длина префикса маршрута не превышает максимум ROA. Он недействителен, когда существует покрывающая авторизация, но ни одна не соответствует всем требуемым свойствам.Объяснение проверки происхожденияот RIPE NCC полезно разделяет состояния «действителен», «недействителен» и «неизвестен» и подчёркивает, что операторы сети по-прежнему решают, какую политику применять к этим состояниям.

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

Для этого инцидента RPKI была особенно сильным превентивным контролем, потому что оптимизатор изменил длину префикса. Было бы ошибкой обобщать это условие успеха на любую утечку маршрутов. Если бы AS396531 утекла обычный /20 Cloudflare, сохранив AS13335 в конце пути, проверка происхождения могла бы считать маршрут действительным. Маршрут всё равно нарушал бы ожидаемую топологию «провайдер—клиент». Валидация происхождения по RPKI отвечает на вопрос, кто может объявлять префикс и какой длины. Она не доказывает, что каждое транзитное отношение в пути AS авторизовано.

Эта граница — не критика RPKI. Это причина развёртывать её вместе с другими контролями.Руководство SP 800-189 NISTобъединяет RPKI и валидацию происхождения BGP с фильтрацией префиксов и более широкими практиками устойчивости междоменных связей. Оно рассматривает утечки маршрутов, перехваты, перенаправление трафика, отказ в обслуживании и ухудшение производительности как связанные операционные риски, требующие слоёв. Событие июня 2019 года — необычно конкретная демонстрация: один слой мог отклонить именно эти плохие префиксы, а базовая клиентская фильтрация могла отклонить неправдоподобный путь авторизации даже без криптографии.

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

Контроль пути и политики после 2019 года

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

RFC 9234, опубликованный в 2022 году, ввёл роли BGP и атрибут Only-to-Customer (OTC). Соседние сети могут заявлять, является ли отношение отношением провайдера, клиента, пиринга, маршрутного сервера или клиента маршрутного сервера. Соглашение о ролях и обработка OTC позволяют маршрутизаторам обнаруживать некоторые анонсы, пересекающие границу отношений в недопустимом направлении. В упрощённой версии пути 2019 года маршрут, полученный от провайдера и затем отправленный другому провайдеру, должен нести доказательства, несовместимые с экспортом только клиенту. Роли BGP превращают часть знаний о коммерческой топологии из конвенции оператора в видимое состояние протокола.

Peerlock предлагает ещё один подход, ориентированный на путь. Статья 2020 года«Flexsealing BGP Against Route Leaks»изучала механизм, развёрнутый операторами, включая его способность останавливать пути, в которых защищённая крупная сеть появляется там, где её быть не должно. Peerlock существовал до статьи и до события июня 2019 года, но развёртывание зависело от двусторонних знаний и конфигурации. Это доказательство того, что практические фильтры путей были возможны, а не того, что универсальный готовый контроль был доступен.

Авторизация провайдера автономной системы (ASPA) направлена на то, чтобы позволить AS публиковать проверяемые отношения с провайдерами через систему RPKI. Это многообещающе, потому что многие утечки маршрутов — это отказы правдоподобия пути, а не отказы источника. Это также требует осторожного языка: стандарты ASPA и состояние развёртывания развивались, а частичное покрытие создаёт неизвестные пути. К ней следует относиться как к дополнительному сигналу валидации, а не как к ретроспективному доказательству того, что участники 2019 года нарушили тогда обязательный криптографический стандарт пути.

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

Поэтому полезная модель контроля кумулятивна:

1. Публиковать точные маршрутные полномочия через объекты IRR и ROA.
2. Генерировать клиентские импортные фильтры из доверенных данных и безопасно их обновлять.
3. По умолчанию отклонять маршруты, не имеющие явной политики.
4. Обеспечивать ожидания в отношении клиентского конуса, AS-path, длины префикса и максимального числа префиксов.
5. Отклонять недействительные по RPKI анонсы на каждом значимом внешнем входе.
6. Добавлять контроли, учитывающие отношения, такие как роли BGP, OTC, Peerlock и, по мере взросления, валидацию ASPA.
7. Наблюдать за распространением из независимых внешних точек.
8. Поддерживать постоянно протестированные операционные контакты и полномочия на отзыв маршрутов.

Ни один пункт не заменяет остальные. Их ценность — в разных режимах отказов.

Распределение подотчётности без вынесения вердикта об ответственности

Публичная техническая запись поддерживает анализ ответственности, но не содержит судебного решения, предписания регулятора или полного набора контрактов, распределяющих юридическую ответственность между DQE, AS396531, Verizon, Noction, Cloudflare и пострадавшими клиентами. В использованной для этой статьи записи не обнаружен публичный отчёт Verizon о первопричине. Поэтому следующее распределение операционально: кто контролировал какую меру защиты и кто мог снизить какой риск. Это не процентное распределение ущерба.

DQE Communications.DQE контролировала сеть, где генерировались оптимизационные маршруты, и отношения, через которые они достигали AS396531. Её наиболее важными обязанностями были ограничение области действия маршрутов, тестирование внешней видимости, поддержание корректной экспортной политики и остановка анонсов после обращения. Cloudflare приписывает персоналу DQE помощь в отзыве маршрутов. Быстрая кооперация сократила продолжительность; она не устраняет провал превентивного контроля.

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

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

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

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

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

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

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

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

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

Бизнес-подотчётность Cloudflare пережила внешнюю причину

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

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

В заявлении не раскрываются число пострадавших клиентов, общий объём кредитов, возвратов, потерянных транзакций или время простоя на уровне клиента. В нём также обсуждается июньская утечка маршрутов вместе с вызванным внутренними причинами сбоем веб-приложения Cloudflare 2 июля. Эти события не следует смешивать. Июньский инцидент проверяет зависимость от внешней маршрутизации. Июльский инцидент проверяет контроли внутренних изменений ПО. Оба повлияли на доступность, но превентивные владельцы и доказательства разные.

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

Что советы директоров должны спрашивать о пиринговых и транзитных рисках

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

Полезный пакет для совета начинается с подверженности, а не с заявлений о соответствии:

Знаменатель важен в каждой метрике. Утверждение, что RPKI развёрнута на основных маршрутизаторах, не показывает, может ли непроверенный граничный сеанс внедрить маршрут в ту же сеть. Утверждение, что клиентские фильтры автоматизированы, не показывает, полон ли исходный реестр, сохраняются ли аварийные исключения и унаследовала ли новая сессия BGP политику. Утверждение, что контакты есть в базе данных, не доказывает, что кто-то отвечает с полномочиями в 06:30 по местному времени.

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

Устойчивость клиентов без упрощённых советов о нескольких провайдерах

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

Правильный дизайн начинается с сервисного пути. Кто авторитетен для DNS? Где хранятся ключи TLS и политики безопасности? Может ли источник безопасно принимать прямой трафик? Можно ли переключить трафик без создания обхода безопасности? Как быстро меняются DNS-кэши? Сохраняют ли клиенты соединения? Есть ли у вторичного провайдера актуальная конфигурация и мощности? Может ли организация отличить сбой вышестоящей маршрутизации от сбоя источника до перемещения трафика?

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

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

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

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

Событие июня 2019 года произошло в largely voluntary среде безопасности маршрутизации. Лучшие практики не были неизвестны. Фильтрация префиксов и AS-path, данные IRR, контроли максимального числа префиксов, RPKI и реестры операторских контактов существовали. Внедрение и гарантии были неравномерными, особенно там, где одна сеть должна была нести затраты на развёртывание, а выгоды распределялись по интернету.

Эта проблема коллективного действия позже привлекла более явное внимание правительств.Дорожная карта 2024 года «Roadmap to Enhancing Internet Routing Security» U.S. Office of the National Cyber Directorописывает неспособность BGP при обычной эксплуатации проверять подлинность источника, целостность сообщений, удалённую информацию о пути или анонсы, нарушающие деловые политики соседей. Она призывает к более активному внедрению безопасности источников маршрутов, особенно среди крупных провайдеров и услуг, работающих по государственным контрактам. Дорожная карта — это политическое руководство, а не вывод об участниках 2019 года.

Уведомление Federal Communications Commission 2024 года«Secure Internet Routing»предложило планы управления рисками BGP и отчётность для широкополосных провайдеров и запросило комментарии о мерах помимо валидации происхождения RPKI. Оно явно признало, что безопасность путей требует дальнейшей работы. Опять же, это не создаёт ретроспективной ответственности за июнь 2019 года. Это иллюстрирует сдвиг управления от вопроса, поддерживает ли провайдер RPKI в принципе, к требованию поддерживаемого плана, данных о покрытии, аттестации и прогресса.

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

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

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

Доказательства, которых всё ещё не хватает в публичной записи

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

Следующие записи существенно улучшили бы анализ, если бы вовлечённые операторы их опубликовали:

• Конфигурация оптимизатора DQE, политика генерируемых префиксов, экспортные карты, обработка сообществ и внешние тесты распространения до и после развёртывания.
• Политика BGP AS396531, прикреплённая к сеансам DQE и Verizon, хронология отключения и включения сеанса, изменения конфигурации, количество маршрутов и причина, по которой маршруты, полученные от провайдера, были доступны для экспорта.
• Запись подключения клиента Verizon, источник IRR или списка префиксов, политика AS-path, настройка максимального числа префиксов, состояние валидации RPKI, оповещения, хронология реагирования оператора и объяснение глобального распространения.
• Контрольный список развёртывания Noction, средства непрерывного сдерживания, поведение оповещений и изменения продукта после инцидента.
• Первая внутренняя временная метка обнаружения Cloudflare, источник оповещения, рассмотренные меры смягчения, хронология эскалации пиринговых контактов, влияние на клиентов по сетям и регионам и проверка корректирующих действий.
• Количественно оценённые сервисные кредиты, возвраты, нагрузка на поддержку и отток клиентов, относящиеся именно к июньской утечке маршрутов, а не к отдельному июльскому сбою.

Их отсутствие не делает событие непознаваемым. Публичные анонсы BGP — это доказательство того, что сети сообщали друг другу. Измерения трафика — доказательство влияния на сервис. Документы SEC — доказательство корпоративного раскрытия и ожидаемой существенности. Блоги операторов — доказательство атрибутированных объяснений. Дисциплина состоит в том, чтобы держать эти классы доказательств раздельно.

Важно также не путать отсутствующую публичную запись с отсутствующей внутренней записью. Verizon, DQE, AS396531 и Noction могли провести обширные разборы, которые никогда не публиковались. Cloudflare может располагать детальной телеметрией, не включённой в её публикации. Публичная подотчётность слабее, когда доказательства остаются частными, но статья не может сделать вывод, что никакого обучения не произошло.

Устойчивый стандарт подотчётности для устойчивости маршрутизации

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

Событие было предотвратимо с помощью контролей, доступных в то время. DQE могла ограничить оптимизационные маршруты. AS396531 могла экспортировать только авторизованные префиксы. Verizon могла фильтровать клиентские анонсы с помощью данных реестра, пути, числа префиксов и RPKI. Принимающие сети могли отклонить недействительные по RPKI более специфичные маршруты Cloudflare. Лучший мониторинг и готовность контактов могли сократить событие. Более поздние стандарты упрощают передачу некоторых предположений об отношениях, но не превращают операционную дисциплину в необязательное наследие.

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

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

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

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