Утечка маршрутов China Telecom 2010: проверка подотчётности

Резюме

Границы события конкретны:В этой статье рассматриваются аномальные анонсы AS23724, наблюдавшиеся через AS4134 8 апреля 2010 года. Это событие не объединяется с утечкой Safe Host 2019 года, перехватом Pakistan Telecom–YouTube 2008 года или более поздними обвинениями в адрес China Telecom.
Наиболее надёжная публичная цифра — это атрибутированное наблюдение:BGPMon сообщил, что AS23724, которая обычно анонсировала около 40 префиксов, объявила примерно 37 000 уникальных префиксов в течение примерно пятнадцати минут. Разные коллекторы и определения могут давать разные подсчёты.
Доля префиксов не была долей трафика:Позже BGPMon подчеркнул, что показатель, составляющий около одиннадцати процентов таблицы маршрутизации, не означает, что одиннадцать или пятнадцать процентов мирового интернет-трафика прошло через China Telecom.
Доказательства уровня управления имеют ограничения:Коллектор BGP может показать, что анонс маршрута был виден и выбран одним из его пиров. Сам по себе он не может доказать объём пакетов, их перехват, один физический путь, универсальное распространение или злонамеренность.
Ответственность следовала за разными уровнями контроля:AS23724 контролировала аномальный экспорт. AS4134 контролировала первую видимую точку импорта и границу дальнейшего распространения. Другие сети контролировали собственные правила приёма, предпочтения, фильтрации и экспорта.
Ни один отдельный механизм безопасности маршрутизации не был полным решением:Префикс-фильтры, ограничения максимального числа префиксов, явная политика отношений, валидация происхождения RPKI, роли BGP и мониторинг аномалий решают разные виды сбоев.
Реестровые данные имели значение, но не обеспечивали достижимость:Записи ASN, префиксов, IRR, ROA и контактов помогали атрибуции и генерации политик. Фактическая конфигурация маршрутизатора определяла, что сеть принимала и распространяла.
Надёжное исправление должно быть проверяемым:Операторы должны привязывать авторизованные данные о маршрутах к сгенерированной политике и рабочему состоянию, воспроизводить класс сбоя, сохранять записи оповещений и решений, а также подтверждать отзыв с помощью независимых наблюдений уровня управления и уровня данных.

Зафиксируйте событие, прежде чем интерпретировать заголовок

8 апреля 2010 года BGPMon сообщил об аномальном наборе анонсов протокола пограничного шлюза, связанных с AS23724. Публичная идентичность маршрутизации в отчёте описывала AS23724 как сеть дата-центра China Telecom. Согласно BGPMon, обычно эта автономная система анонсировала около 40 префиксов, но во время события анонсировала примерно 37 000 уникальных префиксов, которые ей не были назначены. [1]

BGPMon зафиксировал общий сегмент пути4134 23724 23724. AS4134 — это магистральная автономная система China Telecom. В отчёте говорилось, что сети, пирингующиеся с AS4134, получали и в некоторых случаях распространяли аномальные анонсы своим клиентам. Первый анонс BGPMon наблюдал в 17:54:31 UTC, последний — в 18:10:14 UTC. Эти отметки времени определяют окно наблюдения в этом отчёте. Они не устанавливают первое или последнее аномальное состояние на каждом маршрутизаторе. [1]

Событие не было глобально однородным. BGPMon оценил, что лишь около десяти процентов аномальных префиксов распространились за пределы китайских сетей. Также сообщалось, что 28 процентов коллекторов RIPE Routing Information Service из набора мониторинга обнаружили хотя бы часть события. Некоторые префиксы появлялись во многих точках наблюдения; другие появлялись только через небольшое число пиров или стран. [1]

Эти детали важны, потому что фраза «перехватил интернет» сжимает несколько разных утверждений. Одно утверждение — что AS23724 анонсировала префиксы, для которых она не была обычным источником. Другое — что AS4134 и другие сети приняли и экспортировали хотя бы часть этих маршрутов. Третье — что маршрутизаторы выбрали эти маршруты вместо альтернативных. Четвёртое — что пакеты пошли по выбранным путям. Пятое — что пользователи испытали задержки, потери или неожиданный транзит. Шестое — что кто-то намеревался добиться такого результата.

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

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

Позднейшее разъяснение BGPMon отвергло такое сжатие. Там говорилось, что примерно 37 000 префиксов составляли около одиннадцати процентов общего числа префиксов на тот момент, но префиксы не равны трафику. Также говорилось, что намерения остались неизвестными и что неизвестно, что произошло, если что-то произошло, с перенаправленными данными. [2]

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

Объём префиксов был предупреждающим сигналом, а не измерителем трафика

Цифра примерно в 37 000 префиксов операционно значима. Сеть, которая обычно анонсирует около 40 префиксов, внезапно оказавшаяся источником десятков тысяч других, — это серьёзная аномалия. Одно лишь соотношение должно было вызвать сдерживание, эскалацию и расследование.

Это не делает подсчёт измерением трафика.

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

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

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

Отчёт BGPMon был осторожен в отношении этих ограничений. Там отмечалось, что некоторые анонсы были обнаружены глобально, а другие появились только у нескольких пиров. Из этого делался вывод, что воздействие, вероятно, было больше в Китае и Азии, чем в других регионах. Универсальная реконструкция потоков пакетов не публиковалась. [1]

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

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

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

Этот урок выходит за пределы события 2010 года. Панели безопасности маршрутизации часто отдают предпочтение одному большому числу, потому что его легко сообщать. Оповещение о максимальном числе префиксов может считать маршруты. Панель RPKI может считать состояния valid, invalid и not-found. Коллектор может считать смены источника. Платформа активных измерений может считать неудачные проверки. Каждая метрика описывает свой уровень.

Хорошая подотчётность не отвергает метрики. Она устанавливает для каждой метрики границу утверждения.

Наблюдение уровня управления не доказывало перехват уровня данных

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

Несколько условий отделяют видимый маршрут от доказанного пути уровня данных.

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

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

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

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

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

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

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

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

Первой границей контроля был экспортёр

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

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

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

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

RFC 7454 документирует практики операционной безопасности для BGP, включая фильтрацию и ограничения. [14] RFC 8212 позже стандартизировал более безопасное ожидание по умолчанию: внешние маршруты BGP не должны импортироваться или экспортироваться без явной политики. [15] Эти документы не были отчётами об инцидентах и не доказывают, какие средства контроля использовала AS23724 в 2010 году. Они определяют класс мер, который делает случайный широкий экспорт сложнее.

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

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

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

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

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

Второй границей контроля был прямой сосед

Наблюдаемый общий путь помещал AS4134 между внешними сетями и AS23724. BGPMon сообщил, что пиры AS4134 подхватили и распространили хотя бы часть аномального набора маршрутов. [1]

Это делало AS4134 первой видимой внешней границей сдерживания.

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

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

Эти ограничения говорят в пользу многоуровневого контроля, а не отсутствия контроля.

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

RFC 7908 классифицирует утечки маршрутов по отношениям и паттернам распространения. [13] Он помогает объяснить, почему маршрут может быть создан одной сетью, но стать более широким инцидентом из-за принятия и экспорта другими. RFC был опубликован позже и не может задним числом с уверенностью классифицировать каждое частное отношение. Его ценность аналитическая: подотчётность за утечки маршрутов следует по пути через несколько границ политики.

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

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

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

Другие сети по-прежнему контролировали собственный выбор маршрутов

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

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

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

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

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

Поэтому ответственность должна быть специфичной для маршрута:

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

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

Распределённые системы создают распределённый контроль. Подотчётность всё равно следует за каждой поверхностью контроля.

Реестровые и авторизационные записи были реестрами, а не принуждением

Событие затронуло ресурсы нумерации интернета: номера автономных систем и префиксы IP. Публичные записи помогли идентифицировать AS23724, AS4134 и обычные источники затронутых префиксов. Они поддерживали мониторинг, коммуникацию об инциденте и последующую реконструкцию.

Эти записи не остановили маршрутизатор от принятия анонса.

Это центральный уровень реальности. Реестр может записать выделение или назначение. База данных IRR может записать объект маршрута или намерение политики. RPKI позволяет держателю создать криптографически проверяемую авторизацию происхождения маршрута. Сеть может использовать эти записи для генерации или оценки политики.

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

RFC 6480 описывает инфраструктуру открытых ключей ресурсов, поддерживающую безопасную маршрутизацию. [17] RFC 6811 определяет валидацию происхождения префиксов BGP с использованием проверенных полезных данных ROA. [16] Руководство NIST позже описывало устойчивый междоменный обмен трафиком и практическое развёртывание валидации происхождения маршрутов. [12]

Валидация происхождения отвечает на ограниченный вопрос: авторизован ли ASN-источник применимым ROA для этого префикса и длины? Она не валидирует полный путь AS. Она не доказывает, что источник намеревался экспортировать маршрут через конкретное отношение. Она не доказывает, что каждый маршрутизатор имеет актуальные данные валидации или применяет ту же политику.

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

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

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

Поэтому цепочка подотчётности должна связывать:

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

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

Ни один отдельный контроль не следует продавать как полный ответ

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

Фильтры авторизованных префиксов

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

Ограничения максимального числа префиксов

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

Валидация происхождения маршрутов RPKI

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

Контроль путей с учётом отношений

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

Политика отклонения по умолчанию

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

Мониторинг и оповещения

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

Поэтапные изменения и откат

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

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

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

Обнаружение должно приводить к принадлежащему решению

BGPMon обнаружил событие, потому что его пользователи и коллекторы наблюдали аномальные анонсы источников. Это демонстрирует ценность внешнего мониторинга. [1]

Одного обнаружения недостаточно.

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

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

План реагирования должен определять:

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

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

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

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

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

Отзыв должен быть доказан более чем на одном уровне

Конец утечки маршрута — это не одна отметка времени.

Маршрутизатор-источник может прекратить анонсировать маршрут. Его прямой сосед может получить отзыв или замену. Сосед может обновить свой выбранный путь. Дальнейшие сети могут сходиться в разное время. Коллекторы маршрутов могут наблюдать исчезновение аномального пути от своих пиров. Пути пересылки и пользовательские сервисы могут нормализоваться позже.

Последний аномальный анонс, наблюдавшийся BGPMon в 18:10:14 UTC, — полезное доказательство для его набора мониторинга. [1] Это не универсальный сертификат сходимости.

Надёжная запись о восстановлении включала бы:

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

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

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

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

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

Тест на повторение должен воспроизводить класс сбоя

Самое убедительное исправление — контролируемое воспроизведение.

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

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

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

Тест также должен проверять отказ самих средств контроля. Что произойдёт, если валидатор RPKI недоступен? Что произойдёт, если лента IRR устарела? Что произойдёт, если генерация политики провалится на полпути? Что произойдёт, если сессия мониторинга пропадёт? Что произойдёт, если жёсткое действие по максимальному числу префиксов удалит законного клиента?

Выборы fail-open и fail-closed должны быть явными. Критическая сеть может выбрать сохранить существующее валидированное состояние во время сбоя валидатора, а не принимать невалидированные изменения. Клиентская сессия может предупреждать перед отключением, чтобы избежать ненужного вреда. Правильный выбор зависит от критичности сервиса и известных режимов отказа.

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

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

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

Вопросы клиентов и советов директоров должны следовать маршруту

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

Клиент, покупающий транзит или критическую достижимость, может спросить:

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

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

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

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

Публичные отчёты об инцидентах должны разделять:

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

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

Стандарт доказательств так же важен, как фильтр

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

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

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

Защитимая середина точна:

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

Этот стандарт сохраняет серьёзность сбоя без изобретения фактов.

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

Цель — не устранить неопределённость из распределённой системы. Цель — не дать неопределённости стать ни оправданием, ни заголовком.

Ограниченная модель подотчётности для междоменной маршрутизации

Событие поддерживает пятичастную модель подотчётности.

1. Полномочия

Кто был уполномочен создавать префикс и какая запись поддерживала это полномочие? Сюда относятся доказательства реестров и RPKI.

2. Отношение

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

3. Работающая политика

Какая конфигурация импортировала, выбирала и экспортировала маршрут? Сюда относятся политика маршрутизатора, ограничения и состояние валидации.

4. Наблюдение

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

5. Восстановление

Что изменилось, кто это одобрил и какие независимые доказательства показали нормализацию? Сюда относятся записи отзыва, хеши конфигурации, активные тесты и закрытие.

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

Пятичастная модель сохраняет ответственность распределённой, но конкретной.

Тест подотчётности — это ограниченное распространение и проверяемый отзыв

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

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

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

Реестровые и авторизационные системы были важными реестрами. Они идентифицировали ресурсы и поддерживали политику. Они не принуждали маршрут. Работающий код определял достижимость.

Надёжный оператор теперь должен быть способен доказать четыре вещи:

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

Это тест подотчётности, выявленный утечкой маршрутов China Telecom 2010 года. Стандарт — не совершенная глобальная система маршрутизации. Это ограниченное распространение, дисциплина измерений, назначенный контроль и исправление, которое можно опровергнуть.

Утечка маршрутов China Telecom в 2010 году сделала утверждения об объёме префиксов проверкой подотчётности

Почему это важно