Утечка BGP Google в 2017 году сделала фильтрацию транзита проверкой подотчётности японской доступности

Резюме

• 25 августа 2017 года Google анонсировал Verizon большой набор маршрутов, которые, согласно публичным анализам, были получены от пиров Google. Затем Verizon распространил эти маршруты дальше. Многие анонсы были более специфичными, чем обычные маршруты к тому же адресному пространству, поэтому обычная маршрутизация по самому длинному префиксу могла притягивать трафик к Google, хотя Google не предоставлял транзит к сетям назначения, представленным этими маршрутами. В результате японские операторы и пользователи наблюдали существенное, но не повсеместное нарушение доступности.[1][2]

• Событие нельзя объяснить как обычный сбой облачного сервиса. Его причинным ядром была цепочка междоменных политик: граница экспорта в Google пропустила неожиданные маршруты, граница импорта и дальнейшего экспорта в Verizon не сдержала их, более специфичные префиксы изменили притяжение трафика, а затем отзывы маршрутов должны были распространяться, пока сети сходились. Google заявил, что исправил ошибку конфигурации в течение восьми минут, а Internet Society описала утечку как длившуюся менее десяти минут.[1][7] Ни одно из этих утверждений не означает, что клиенты повсюду восстановились за тот же интервал.

  NTT Communications сообщила о нестабильности OCN с 12:22 до 12:45 по японскому времени, а уведомление KDDI относит восстановление некоторых клиентов широкополосного доступа к 16:47.[3][4]

• Урок подотчётности носит практический характер. Записи реестров и RPKI позволяют идентифицировать держателей адресов и авторизованные источники, но они не заставляют маршрутизатор применять отношения «пир — клиент». Проверка происхождения маршрута (Route Origin Validation) может оставить утечку, связанную с политикой отношений, валидной, если законный источник остаётся в конце пути.

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

Границы события и вопрос подотчётности

Этот анализ ограничен утечкой маршрутов из Google в Verizon 25 августа 2017 года и зафиксированными вокруг неё последствиями для доступности в Японии. Он не объединяет событие с воздействием утечки MainOne на Google в ноябре 2018 года, более поздними инцидентами в плоскости управления Google Cloud, сбоем BGP Meta в 2021 году или каждым нарушением работы японских сервисов, в цепочке зависимостей которого где-то фигурировал Google. Эти события могут прояснять другие режимы отказов, но их смешение затемнило бы средства контроля, которые имели значение здесь.

Ограниченный вопрос — не просто «Кто допустил ошибку?». Он звучит так: какие субъекты контролировали состояние маршрутов, превратившее кратковременную ошибку конфигурации в более широкую проблему доступности, какие средства контроля могли прервать эту цепочку и какие доказательства показали бы, что эти средства сработали? Публичные данные позволяют уверенно описать распространение анонсов и наблюдаемое операторами воздействие.

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

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

RFC 4271 определяет этот базовый обмен и схему принятия решений, но протокол не может вывести частное намерение пирингового отношения только из корпоративной идентичности.[13] Позже RFC 7908 предложил таксономию утечек маршрутов: распространение может быть технически корректным, но нарушать ожидаемые рамки отношений между автономными системами.[14]

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

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

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

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

Доказательства также не устанавливают намерение. «Утечка» описывает распространение за пределами ожидаемых рамок отношений; сама по себе она не является доказательством преднамеренного перехвата. Google описал ошибку конфигурации и извинился за нарушение работы.[7] Ни один публичный путь маршрута не может установить преступное намерение, противоправность, халатность, нарушение нераскрытого договора или конкретного владельца решения.

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

Причинная цепочка, записанная в политике маршрутизации

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

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

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

Второй границей было обращение Verizon с этими анонсами. Событие стало глобально значимым лишь потому, что маршруты, полученные от Google, вышли за пределы этой сессии. Публичные описания указывают Verizon в пути распространения и описывают, что он принял и повторно распространил анонсы.[1][2][9] Это обосновывает внимание к импортным средствам контроля Verizon и средствам контроля дальнейшего экспорта. Это не устанавливает точное значение локального предпочтения, назначенного маршрутам, точные фильтры, установленные в тот момент, формулировки пирингового соглашения или то, что каждый маршрутизатор или пир Verizon получил каждый анонс.

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

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

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

Третьим механизмом была специфичность префиксов. Агрегированный маршрут покрывает крупный адресный блок; более специфичный маршрут покрывает меньшую часть внутри этого блока. Пересылка использует сопоставление по самому длинному префиксу. Например, маршрут к /24 выбирается для адресов внутри этого /24 вместо доступного /20, который также покрывает их. Это происходит до того, как длина AS-пути решает выбор среди маршрутов одинаковой длины префикса. Поэтому утёкший более специфичный маршрут может притягивать трафик, даже когда обычный агрегированный путь выглядит разумнее и даже когда законная регистрация ресурсов не изменилась.

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

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

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

Трассировка и анализ маршрутов, относящиеся к событию, связали аномальные анонсы с проблемами доступности в Японии.[2] Точная судьба каждого пакета не публична, поэтому «отброшен или направлен неверно» — это ограниченный механизм, а не утверждение, что одна судьба применилась повсеместно.

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

Route flap damping, таймеры, очереди, поведение сессий и локальные политики могут влиять на «хвост», а кэши DNS, повторные попытки транспорта, сессии приложений и состояние сети доступа могут задерживать восстановление пользователей после сходимости плоскости управления. Это разделение существенно для интерпретации четырёх разных часов события.

Количество префиксов — это измерения, а не единый универсальный итог

Событие часто резюмируют одним большим числом префиксов, но публичные анализы считали не один и тот же объект. Отчёт Internet Society о событии упоминал примерно 135 000 утёкших префиксов, а анализ Дуга Мэдори описывал более 160 000 префиксов в аномальном эпизоде маршрутизации.[1][2] Эти цифры следует сохранять с атрибуцией, а не объединять в кажущийся точным итог.

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

Подсчёт всей видимости за окно — не то же самое, что одновременный снимок таблицы маршрутизации.

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

BGPStream предоставляет инфраструктуру для доступа и анализа данных маршрутизации из коллекторных систем, а RouteViews собирает информацию о маршрутах от участвующих пиров для операционных и исследовательских целей.[11][12] Их ценность значительна именно потому, что они сохраняют наблюдаемое состояние маршрутов; их ограничения должны оставаться видимыми при любом подсчёте.

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

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

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

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

Экспортный контроль Google и восьмиминутное исправление

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

Современные японские публикации сохранили заявление Google о том, что ошибка конфигурации была исправлена в течение восьми минут, вместе с извинениями за нарушение работы.[7] Internet Society описала саму утечку как длившуюся менее десяти минут.[1] Эти описания в целом совместимы, но их не следует считать одной и той же метрикой. «Конфигурация исправлена» — это действие у источника. «Утечка длилась» — это характеристика наблюдателем аномальных анонсов маршрутов. Ни то, ни другое не является измерением момента, когда каждый внешний маршрутизатор отозвал маршрут или каждый клиент восстановил стабильный доступ.

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

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

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

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

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

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

Позже Google описал более широкую программу безопасности маршрутизации, включающую данные Internet Routing Registry, валидацию RPKI, автоматизированные средства контроля, координацию и обязательства MANRS.[5] Текущая документация Google Interconnect также излагает ожидания по фильтрации BGP и призывает пиров поддерживать меры защиты на своей стороне.[6] Эти материалы — уместные сравнения того, как крупная сеть может выражать и проверять намерения маршрутизации.

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

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

Импортная граница Verizon и смысл фильтрации транзита

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Более специфичные маршруты также усложняют предотвращение. Оператор не может безопасно отклонять каждый дезагрегированный маршрут; мультихоминг, traffic engineering, смягчение атак и операционные переходы могут делать более специфичные анонсы законными. В частности, IPv4 /24 обычно распространяются. Разумный контроль спрашивает, уполномочен ли этот сосед анонсировать этот конкретный более специфичный маршрут в этих отношениях, уполномочен ли источник для такой длины, соответствует ли анонс ожидаемому клиентскому конусу и является ли его внезапное появление аномальным.

RPKI может помочь с компонентом «префикс и источник», когда существует Route Origin Authorization. ROA идентифицирует авторизованный AS происхождения и может ограничивать максимальную длину префикса.[19] Если утёкший более специфичный маршрут превышает максимальную длину ROA, Route Origin Validation может классифицировать его как недействительный. Но если более специфичный маршрут и источник авторизованы — или если покрывающего ROA нет — маршрут может быть валидным или «not found», хотя его распространение нарушает предполагаемые рамки отношения.

RFC 6811 описывает проверку происхождения; он не утверждает, что проверяет весь AS-путь или коммерческую авторизацию одной сети передавать маршрут другой.[18]

Воздействие на трафик дополнительно зависит от плоскости данных. Выбранный маршрут должен быть установлен в состояние пересылки, трафик должен действительно направляться на покрытые адреса, а анонсированный next hop должен не суметь доставить его корректно. Публичные наблюдения traceroute могут поддерживать связь от притяжения маршрута к отказу достижимости, как это делал анализ события.[2] Они остаются выборками. Без flow-телеметрии, захватов пакетов и локальных записей пересылки от соответствующих сетей объём и судьбу всего затронутого трафика нельзя назначить точно.

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

Четыре часа восстановления, а не один восьмиминутный сбой

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

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

Вторые часы — наблюдаемая длительность утечки. Internet Society описала утечку как длившуюся менее десяти минут.[1] Эта оценка отражает аномальный эпизод маршрутизации, как он виден по доступным доказательствам. Его начало и конец могут отличаться от внутренней метки времени конфигурации, поскольку точки наблюдения получают обновления после задержки распространения, а «конец» может означать последний аномальный анонс, первый отзыв или исчезновение из выбранного маршрута у конкретного наблюдателя. Исправление источника и интервал, наблюдаемый коллектором, связаны, но не взаимозаменяемы.

Третьи часы — междоменный отзыв и сходимость. После исправления экспорта отзывы или заменяющие анонсы должны были пройти через Verizon и другие сети. Маршрутизаторы пересчитали пути и анонсировали свой выбор дальше. Некоторые сети могли иметь готовые незатронутые альтернативы; другим пришлось обработать большой всплеск изменений. Внешняя видимость может нормализоваться в разное время у разных пиров. Ни одна глобальная временная отметка сходимости не установлена в публичных данных.

Четвёртые часы — восстановление операторов и клиентов. NTT Communications сообщила, что крупные изменения интернет-маршрутов сделали связь OCN нестабильной с 12:22 до 12:45 по японскому времени, и заявила, что её собственное оборудование OCN не показало аномалий.[4] Современные японские публикации также связывали нестабильность с маршрутным событием.[8] Это 23-минутное окно оператора выходит за пределы восьмиминутного исправления Google и является прямым доказательством того, что откат источника не означал мгновенно стабильный доступ.

KDDI зафиксировала нестабильность, затронувшую некоторых клиентов доступа в Интернет, и сообщила о более длительном окне восстановления, завершившемся в 16:47.[3] Уведомление не даёт оснований считать каждого клиента KDDI затронутым до этого момента, тем более всю Японию. Оно показывает, что часы стабилизации клиентов как минимум одного оператора растянулись на часы за пределы исходного исправления конфигурации.

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

Эти часы поддерживают точную формулировку: Google исправил исходную конфигурацию в течение восьми минут; публичный анализ маршрутизации охарактеризовал саму утечку как длившуюся менее десяти минут; отзывы и выбор маршрутов затем должны были сойтись; NTT наблюдал ограниченное окно нестабильности 12:22–12:45; а уведомление KDDI относит восстановление некоторых затронутых клиентов к 16:47. Ни одно из этих утверждений не доказывает ошибочность остальных. Каждое измеряет другой слой.

Не менее важно не обобщать доказательства операторов. Заявление NTT касалось связи OCN и не перечисляло каждый сервис, префикс или клиента. Уведомление KDDI касалось некоторых пользователей доступа в Интернет. Вторичные публикации называли дополнительные японские сервисы и компании,[8][9] но не дают полной переписи воздействия или проверенного итога потерь. «Существенное нарушение доступности в Японии» подтверждается; «Япония полностью была офлайн» — нет.

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

Доказательства маршрутов сильны — и неполны

Публичные данные маршрутов делают этот инцидент необычно проверяемым. BGP-коллекторы получают маршруты от участвующих сетей и сохраняют снимки таблиц маршрутизации и потоки обновлений. BGPStream предоставляет структурированный доступ к коллекторным проектам,[11] а RouteViews поддерживает инфраструктуру коллекторов и архивы, полезные для исторической реконструкции.[12] Аналитики событий могут использовать эти записи, чтобы определить, когда появился префикс, какой AS-путь сообщил пир коллектора, когда возник более специфичный маршрут и когда маршрут изменился или исчез.

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

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

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

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

Лучшая система доказательств объединяет четыре слоя. Первый — авторитетные записи: ASN, префикс, route-объект и данные ROA, идентифицирующие заявленные отношения ресурсов и источников. Второй — локальные записи плоскости управления: полученные маршруты, политические решения, выбранные маршруты и анонсы. Третий — записи пересылки и трафика: состояние FIB, изменения next hop, объём потока, потери и задержка. Четвёртый — внешние наблюдения: коллекторы, зонды, traceroute и отчёты клиентов. Каждый слой может оспаривать или подтверждать остальные.

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

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

Реестры и записи RPKI — это бухгалтерские книги, а не механизмы принуждения

Записи о номерных ресурсах Интернета незаменимы для подотчётности. Реестры ASN и префиксов идентифицируют признанных держателей и контакты. Объекты Internet Routing Registry могут выражать предполагаемые отношения «маршрут — источник». RPKI добавляет криптографически проверяемую авторизацию через ROA. Эти записи позволяют сравнивать наблюдаемый маршрут с заявленным источником полномочий, расследовать аномалии и генерировать фильтры. Это бухгалтерская книга ожидаемых фактов.

Бухгалтерская книга не исполняет политику маршрутизатора. Корректная запись реестра не может помешать спикеру BGP анонсировать маршрут. Валидный ROA не может заставить принимающую сеть выполнять Route Origin Validation или определять её локальную реакцию. Даже там, где ROV активна, она проверяет, авторизован ли AS происхождения для префикса и длины. Сама по себе она не доказывает, что каждый AS в пути имел полномочия предоставлять транзит через каждое отношение.

Это ограничение центрально для события 2017 года. Публичное описание — утечка политики отношений: Google экспортировал маршруты, полученные от пиров, а Verizon распространил их. Если конечный AS происхождения утёкшего маршрута оставался законным источником, а длина префикса соответствовала ROA, проверка происхождения могла классифицировать анонс как валидный, несмотря на нежелательный путь распространения. Если у маршрута не было покрывающего ROA, он мог быть «not found». Только подмножество с неавторизованным источником или чрезмерной длиной обязательно становилось бы RPKI-недействительным по семантике ROA.[18][19]

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

Фильтры на основе IRR имеют параллельное ограничение. Точные аутентифицированные route-объекты могут помочь провайдеру построить белый список для клиента. Но устаревшие, неполные, чрезмерно широкие или неаутентифицированные данные могут порождать небезопасные фильтры, а route-объект не кодирует каждое ограничение «пир против транзита». Крупная сеть должна соединять данные реестра с явным определением того, что каждый сосед может анонсировать и куда каждый полученный маршрут может быть экспортирован.

Различие можно выразить тремя вопросами. «Кто признан держателем номерного ресурса?» — вопрос реестра. «Какой AS уполномочен анонсировать этот префикс и длину?» — вопрос ROA и ROV. «Может ли этот сосед анонсировать мне этот путь и могу ли я отправить его дальше этому другому соседу?» — вопрос отношений AS и политики маршрутизации. Первые два информируют третий; они не отвечают на него полностью.

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

Это также помещает ответственность в правильные места. Держатели ресурсов должны поддерживать точные данные о префиксах, контактах и ROA. Реестры и репозитории RPKI должны сохранять доступность, целостность и ясную семантику. Операторы сетей должны извлекать, проверять и безопасно преобразовывать эти данные в политику, управляя рисками устаревших данных и режимами fail-open или fail-closed. Ни одна из этих ролей не может перенести политическое решение принимающего маршрутизатора на конечного пользователя.

Более поздние средства контроля проясняют пробел, не создавая ретроактивных обязанностей

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

RFC 8212 задаёт более безопасное значение по умолчанию для внешнего BGP: без явной импортной и экспортной политики маршруты не должны приниматься или анонсироваться.[16] Принцип снижает случайную опору на разрешительные значения по умолчанию. В зрелой конструкции каждое внешнее отношение имеет намеренную политику в обоих направлениях. Применительно к анализу подотчётности здесь он спрашивает, имела ли сессия Google — Verizon явные политики и были ли эти политики корректно сгенерированы, прикреплены и протестированы.

Он не раскрывает, какая конфигурация существовала во время инцидента, и не гарантирует, что явная, но неверная политика заблокировала бы утечку.

RFC 9234 позже стандартизировал BGP Roles и атрибут Only-to-Customer как инструменты для сообщения и принудительного применения ожиданий отношений.[17] BGP Roles позволяют соседям заявлять типы отношений, а OTC помогает выявлять пути, пересекшие границу способом, несовместимым с valley-free распространением. Это затрагивает больше измерений отношений утечки, чем проверка только происхождения. Развёртывание остаётся двусторонним или зависящим от экосистемы, а исключения политик по-прежнему требуют осторожности. RFC — это более позднее сравнение, а не ретроактивная обязанность, наложенная на субъектов 2017 года.

Peerlock — ещё одна техника, учитывающая отношения. Оператор создаёт фильтры, призванные останавливать пути, содержащие защищённый AS пира в позициях, где этот пир не должен появляться, снижая определённые паттерны утечек. Она может быть эффективной для избранных высокоценных отношений, но зависит от корректной конфигурации, покрытия и сопровождения. Это не универсальная система проверки путей. Более поздний обзор APNIC обсуждает Peerlock и зарождающиеся подходы ASPA среди механизмов безопасности междоменной маршрутизации.[21]

ASPA — Autonomous System Provider Authorization — стремится позволить AS заявлять своих авторизованных провайдеров, чтобы полагающиеся сети могли оценивать, правдоподобны ли наблюдаемые отношения провайдеров в пути. Она предлагает более масштабируемую основу для обнаружения некоторых valley-нарушений, чем поддерживаемые вручную двусторонние фильтры. Её ценность для безопасности зависит от внедрения, точных авторизаций, правил проверки путей и операционного развёртывания. Её не следует проецировать назад как средство контроля, которое стороны уже были обязаны или могли использовать в 2017 году.

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

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

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

Route Origin Validation дополняет эти средства контроля. Она может отклонять или понижать приоритет недействительных заявлений об источнике, если у оператора есть надёжные данные RPKI и определённая политика. Но средства контроля политики отношений должны стоять рядом с ней. Инцидент показывает, почему «валидный источник» нельзя трактовать как «валидный путь» или «авторизованный транзит».

MANRS формулирует фильтрацию, координацию, глобальную информацию о валидации и анти-спуфинг как операционные обязанности, а его измерительная система стремится получить наблюдаемые доказательства действий по безопасности маршрутизации.[20] Более поздние публичные обязательства Google и работа по безопасности маршрутизации могут сравниваться с этой системой.[5] Такие обязательства полезны, когда они дают измеримое поведение маршрутов, опубликованный охват и независимое наблюдение. Они не заменяют доказательства по конкретному инциденту или подтверждение того, что каждая внутренняя мера защиты была независимо проверена.

Правильная стратегия предотвращения многослойна, потому что каждое средство контроля отказывает по-разному. Точность реестра и ROA может быть неполной. Фильтры отношений могут устаревать. Max-prefix может пропускать малые утечки или вызывать потерю сессии. Roles и OTC требуют развёртывания. Peerlock покрывает избранные паттерны. ASPA зависит от экосистемы авторизаций. Мониторинг обнаруживает уже после того, как состояние начало двигаться. Вместе с поэтапным контролем изменений и протестированным откатом они создают несколько возможностей остановить или сократить утечку.

Ответственность следует практическому контролю

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

Google контролировал исходную среду генерации и экспорта маршрутов. Это включает классификацию полученных маршрутов, политику, применённую к смежности с Verizon, код и данные route-policy, предразвёртывающие тесты, утверждение изменений, поэтапное развёртывание, внутренний и внешний мониторинг, откат, сохранение доказательств и публичное описание события. Публичные данные поддерживают объяснение случайной ошибкой конфигурации и утверждение о восьмиминутном исправлении.[7] Они не идентифицируют точного владельца решения, вызвавшую команду или полное устранение.

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

Японские сетевые операторы контролировали собственный выбор маршрутов, локальные меры по смягчению, коммуникации с клиентами и доказательства, использованные для объявления сервиса стабильным. Они не создали исходный анонс лишь потому, что их клиенты ощутили его последствия. Уведомление NTT отличало внешние крупные изменения маршрутов от аномалий в собственном оборудовании OCN,[4] а KDDI задокументировала воздействие на некоторых клиентов и более позднее восстановление.[3] Эти уведомления ценны как записи подотчётности, поскольку фиксируют ограниченные наблюдения, не претендуя на реконструкцию всего Интернета.

Держатели ресурсов контролировали точность своей информации в реестрах и ROA. Эта информация могла помочь сетям проверять источники и генерировать фильтры, но держатель ресурса не мог заставить маршрутизаторы Google или Verizon применять правило отношений AS. Операторы реестров и репозиториев RPKI контролировали целостность и доступность слоя записей, а не локальную политику каждого спикера BGP.

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

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

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

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

Доказательства, всё ещё необходимые для полного отчёта

Самое сильное отсутствующее доказательство — точная цепочка состояния маршрутов. От Google сюда вошли бы соответствующая версия политики, классификация отношений, diff route-policy, происхождение Adj-RIB-In, Adj-RIB-Out до и во время события, метки времени оповещений, охват развёртывания и записи отката. Такие доказательства могли бы показать, лежал ли отказ в классификации маршрутов, генерации политики, прикреплении, развёртывании или ином программном пути.

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

От японских операторов изменения локальных RIB и FIB, выровненные с телеметрией сервисов, прояснили бы, почему восстановление клиентов длилось дольше исходной ошибки. Данные о потерях на уровне префиксов, задержке, next hop и объёме трафика могли бы отличить продолжающуюся внешнюю сходимость от локального восстановления сессий, кэшированного состояния, повторных попыток приложений или осторожного подтверждения. Более длительное окно KDDI — свидетельство «хвоста» восстановления клиентов, а не объяснение каждой минуты в этом хвосте.

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

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

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

Наконец, более позднее устранение не имеет полной независимой проверки в замороженной публичной записи. Более поздние публикации Google о безопасности маршрутизации описывают значительные средства контроля,[5][6] а MANRS даёт полезную систему подотчётности,[20] но описание программы — не то же самое, что доказательство того, что каждая соответствующая смежность принудительно применяет намеченную политику при сбое. Проверка потребовала бы текущих, надлежащим образом защищённых результатов тестов и наблюдений маршрутов, а не ретроспективного предположения.

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

Программа предотвращения и проверки

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

Во-первых, поддерживать авторитетный инвентарь отношений и ресурсов. Каждая внешняя BGP-сессия должна иметь владельца, идентичность соседа, класс отношений, ожидаемый диапазон префиксов и путей, контакт для эскалации и утверждённые исключения. Записи о префиксах, ASN, IRR и ROA должны быть точными и отслеживаться на предмет изменений. Этот инвентарь — бухгалтерская книга, из которой можно генерировать политику и с которой можно сверять состояние маршрутов.

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

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

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

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

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

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

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

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

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

Более поздние механизмы могут укрепить эту программу. Явное поведение default-reject по RFC 8212 может снизить число разрешительных сессий.[16] BGP Roles и OTC могут выражать информацию об отношениях, которой не хватает проверке происхождения.[17] Peerlock может защищать избранные отношения, а ASPA может поддерживать более широкую проверку путей провайдеров.[21] ROV может отклонять неавторизованные источники или длины.[18] MANRS может формулировать наблюдаемые обязательства операторов.[20] Ни одно средство не достаточно само по себе, и ни одно не следует использовать для создания ретроактивной правовой обязанности.

Цель проверки — не документ о политике. Это набор измеряемых утверждений: ни один маршрут, полученный от пира, не появился в запрещённом Adj-RIB-Out; инъектированный недействительный источник был отклонён; неожиданный более специфичный маршрут вызвал оповещение; всплеск числа маршрутов запустил запланированную реакцию; внешние точки наблюдения не увидели тестовый маршрут; откат восстановил и индикаторы плоскости управления, и индикаторы сервисов в измеренных границах. Управление становится достоверным, когда заявленное правило и текущее состояние маршрутов согласуются.

Заключение: достижимость управляется на границе

Ошибка Google 25 августа 2017 года длилась минуты в исходном контроле, но созданное ею состояние маршрутов пересекло организационные границы и породило более длинный «хвост» восстановления для некоторых японских клиентов. Публичные доказательства поддерживают конкретную последовательность: Google экспортировал Verizon большой набор маршрутов, полученных от пиров; Verizon распространил значимые маршруты дальше; более специфичные анонсы притянули трафик; Google не предоставлял функциональный транзит к представленным сетям назначения; затем отзывы должны были распространяться, пока сети и сервисы стабилизировались.[1][2][3][4]

Различающиеся публичные итоги по числу префиксов не опровергают этот вывод. Они предостерегают от притворства, будто один наблюдатель посчитал весь Интернет. Восьмиминутное исправление, наблюдаемая утечка менее десяти минут, нестабильность NTT с 12:22 до 12:45 и уведомление KDDI о восстановлении к 16:47 также не являются конкурирующими версиями одной длительности. Это измерения разных слоёв: исправление источника, наблюдаемое распространение, сходимость, стабильность оператора и восстановление клиентов.

Центральная проверка подотчётности — было ли намерение закодировано и проверено на обеих сторонах соединения. Google контролировал, какие изученные маршруты он экспортировал. Verizon контролировал, какие маршруты он принял и распространил. Точные записи реестров и ROA могли информировать эти решения, но не могли их исполнить. ROV могла выявить неавторизованный источник или чрезмерную длину префикса, но могла оставить нетронутой утечку отношений с законным источником. Работающие маршрутизаторы, настроенные политики и установленное состояние пересылки определяли, дошли ли пакеты.

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

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

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

Источники

[1]https://www.internetsociety.org/blog/2017/08/google-leaked-prefixes-knocked-japan-off-internet/[2]https://circleid.com/posts/20170831_large_bgp_leak_by_google_disrupts_internet_in_japan[3]https://www.notice.kddi.com/news/mainte/content/syougai/jyouji_00021279.html[4]https://support.ntt.com/supportTopInfo/detail/pid2500000g6q[5]https://cloud.google.com/blog/products/networking/how-google-is-working-to-improve-internet-routing-security[6]https://support.google.com/interconnect/answer/9325705?hl=en[7]https://internet.watch.impress.co.jp/docs/news/1077715.html[8]https://internet.watch.impress.co.jp/docs/news/1077431.html[9]https://www.bleepingcomputer.com/news/technology/google-error-causes-widespread-internet-outage-in-japan/[10]https://www.geekpage.jp/blog/?id=2017-8-29-1[11]https://bgpstream.caida.org/docs/overview[12]https://www.routeviews.org/routeviews/[13]https://www.rfc-editor.org/rfc/rfc4271.html[14]https://www.rfc-editor.org/rfc/rfc7908.html[15]https://www.rfc-editor.org/rfc/rfc7454.html[16]https://www.rfc-editor.org/rfc/rfc8212.html[17]https://www.rfc-editor.org/rfc/rfc9234.html[18]https://www.rfc-editor.org/rfc/rfc6811.html[19]https://www.rfc-editor.org/rfc/rfc6482.html[20]https://manrs.org/manrs-observatory/measurement-framework/[21]https://blog.apnic.net/2021/07/09/a-survey-on-securing-inter-domain-routing-part-2/