Резюме

  • Cloudflare сообщила, что около 10:30 UTC 24 июня 2019 года небольшая сеть в Пенсильвании стала предпочтительным путём для многих маршрутов интернета через Verizon AS701, и среди затронутых анонсов были префиксы Cloudflare [1].
  • Позднейший анализ Cloudflare связал сбой с путём, выбранным маршрутным оптимизатором, и с распространением крупным транзитным провайдером. Это делает контуром контроля политику импорта и экспорта BGP, а не обычный облачный или программный инцидент [2].
  • Noction публично отреагировала на инцидент, поскольку её продукт оптимизации маршрутов участвовал в публичном обсуждении. Этот ответ полезен, потому что отделяет замысел продукта от контроля внедрения: автоматизация может оптимизировать пути только в пределах маршрутных ограничений, которые обеспечивают операторы [3].
  • ThousandEyes/Catchpoint зафиксировали внешние эффекты доступности для пользователей Cloudflare во время наложения маршрутов, что закрепляет границу ущерба в измеренной производительности интернета, а не в приватных журналах операторов [4].
  • RFC 7908 и RFC 9234 объясняют, почему важен класс события. Утечка маршрутов — это нарушение предусмотренного распространения отношений BGP, а BGP Roles/Only-to-Customer предназначены для того, чтобы сделать эти допущения об отношениях явными [6][7].

Почему это был случай подотчётности в маршрутизации

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

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

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

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

Ответ Noction добавляет ещё одну границу. Компания не представила инцидент как повод полностью отказаться от оптимизации маршрутов. Она описала свой взгляд на инцидент и контекст контроля продукта. Этот ответ важен, потому что вопрос подотчётности не в том, является ли оптимизация маршрутов по своей сути незаконной. Вопрос в том, дали ли продукт, его внедрение у клиента и правила приёма у вышестоящего оператора проверяемые ограничения вокруг того, какие маршруты можно оптимизировать и экспортировать [3].

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

Публичные коллекторы маршрутов и внешние измерения достаточно сильны, чтобы доказать, что маршрутное событие произошло. Они недостаточно сильны, чтобы доказать каждое частное конфигурационное решение. Cloudflare могла описать затронутые префиксы, пути маршрутизации и наблюдаемое распространение. ThousandEyes/Catchpoint могли описать видимые пользователям симптомы и внешние измерения. Kentik мог поместить инцидент в более широкую историю значимых сбоев BGP.

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

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

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

Контуром контроля были доказательства отношений

BGP основан на политике в той же мере, что и на доступности. Маршрут, полученный от клиента, обычно можно передавать провайдеру или пиру, потому что ожидается, что клиент анонсирует свои собственные сети и сети своих нижестоящих клиентов. Маршрут, полученный от одного провайдера, обычно не следует экспортировать другому провайдеру так, будто анонсирующая сеть является транзитным путём для остального интернета. RFC 7908 описывает это семейство нарушений отношений как утечки маршрутов [6].

Событие 2019 года относится к этому семейству. Находился ли первый неверный выбор в карте маршрутов клиента, в политике маршрутного оптимизатора или в правиле импорта вышестоящего оператора, критическим недостающим доказательством были доказательства отношений. Какие маршруты DQE была уполномочена анонсировать? Какие маршруты оптимизатор пометил как экспортируемые? Какую политику принятия маршрутов применял Verizon на границе клиента? Какие проверки максимального числа префиксов, AS-пути, IRR, RPKI, списков префиксов или ролей существовали?

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

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

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

У кого был практический контроль

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

Noction имела практический контроль над поведением продукта, настройками по умолчанию, документацией и извлечением уроков из инцидента. Маршрутный оптимизатор, способный влиять на анонсы BGP, должен рассматриваться как маршрутная инфраструктура, а не как нейтральный аналитический аксессуар. Релевантное доказательство — не маркетинговое намерение. Это то, делал ли продукт опасный экспорт трудным, предупреждались ли клиентские развёртывания о риске транзитного распространения и снизили ли изменения после инцидента вероятность повторения [3].

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

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

Каким должен был быть ремонт

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

Следующий уровень — предотвращение повторения. Операторы должны быть в состоянии показать лимиты максимального числа префиксов, генерацию списков префиксов из доверенных объектов маршрутов, дисциплину проверки IRR, проверку происхождения RPKI, где применимо, фильтры AS-пути для клиентских сессий и обнаружение утечек маршрутов, настроенное на нарушения отношений. Там, где поддерживается, BGP Roles и Only-to-Customer предоставляют более сильный способ сделать роли клиента, провайдера и пира явными [7].

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

Тест на подотчётность

Утечка DQE/Noction/Verizon 2019 года полезна не потому, что позволяет наблюдателям назначить простого злодея. Она полезна потому, что показывает, как маршрутизация интернета превращает небольшие отказы контроля в события общей зависимости. Источник маршрута на стороне клиента, оптимизатор, транзитный провайдер и удалённые сети — каждый держал часть практического контроля. Если любой уровень относился к допущениям об отношениях как к чужой проблеме, утечка могла пройти дальше, чем следовало.

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

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