Утечка AS7007 1997 г. — тест на подотчётность фильтрации

Резюме

Зафиксированные границы инцидента:В статье рассматриваются маршруты, анонсированные AS7007 25 апреля 1997 года, и вызванное этим нарушение связности. Инцидент не смешивается с последующими утечками маршрутов, злонамеренными перехватами или несвязанными сбоями на точках обмена с похожими названиями. Современные записи NANOG показывают, что операторы наблюдали собственное адресное пространство в виде более специфичных маршрутов с AS7007 в качестве источника. [3][4]
Ограниченная техническая реконструкция:В более позднем отчёте APNIC описывается, как бесклассовые маршруты eBGP поступали в систему, перераспределялись в RIPv1, теряли информацию о длине префикса и возвращались в BGP в виде деагрегированных маршрутов с переписанной информацией об источнике. [1] Это убедительная объяснительная реконструкция, а не разрешение придумывать точную внутреннюю последовательность команд.
Почему маршруты возобладали:Маршрутизация в интернете основана на выборе самого длинного совпадения префикса. Более специфичный маршрут может привлечь трафик ещё до сравнения многих атрибутов пути BGP. Таким образом, утёкшие маршруты создали операционную реальность, противоречащую принадлежности ресурсов и ожидаемой информации об источнике.
Ответственность следует за контролем:AS7007 контролировал перераспределение, политику экспорта, проверку изменений, мониторинг и отзыв маршрутов. Его вышестоящие провайдеры контролировали фильтры для клиентов, лимиты префиксов и распространение. Принимающие пиры контролировали собственную политику приёма и реагирование на инциденты. Конечные пользователи могли сообщать о сбоях, но не могли исправить состояние междоменных маршрутов.
Реестровые данные не являются принуждением:Записи об ASN, адресных реестрах, IRR и более поздние RPKI могут сохранять информацию об ожидаемых держателях ресурсов и авторизованных источниках. Однако маршрутизаторы действуют на основе маршрутов и политик, загруженных в работающие системы. Таким образом, инцидент служит явным примером приоритета работающего кода: письменные полномочия имеют значение только тогда, когда операционная политика обеспечивает их соблюдение.
Современные средства контроля многослойны:Проверка происхождения маршрутов, явные политики импорта и экспорта, роли BGP, фильтрация клиентской конусности, лимиты префиксов, независимый мониторинг и протестированные процедуры отката направлены на разные пути сбоев. Ни один механизм не следует представлять как универсальное ретроспективное решение.
Восстановление должно быть доказано:Отключение или исправление исходного маршрутизатора не снимает ответственности. Операторам нужны доказательства отзыва маршрутов, очистки устаревших записей, нормализации таблиц маршрутизации, координации с пирами и восстановления пересылки пакетов с нескольких независимых точек наблюдения.

Граница события — 25 апреля 1997 года

Подотчётная техническая история начинается с фиксации события. 25 апреля 1997 года интернет-операторы сообщили о беспрецедентном наборе более специфичных маршрутов, ассоциированных с AS7007, которой управляла компания MAI Network Services. Сообщения в списке рассылки NANOG за тот день предоставляют свидетельства того, что видели операторы: блоки адресов, которые, как они ожидали, должны были анонсироваться из других мест, появлялись в виде более мелких префиксов с AS7007 в качестве источника, и трафик следовал этим анонсам по маршрутам, которые не могли корректно его доставить. [3][4]

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

Поздние технические описания обычно упоминают тысячи маршрутов /24 и острую фазу нарушения связности продолжительностью около двух часов. Ретроспективный анализ APNIC приводит приблизительную цифру в 6000 анонсов /24 и реконструирует, как классовое поведение маршрутизации могло преобразовать большую внешнюю таблицу в более специфичные маршруты. [1] Каталог инцидентов Secure Routing также фиксирует это событие как знаковый сбой маршрутизации.

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

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

Роль Флоридского интернет-обменника (Florida Internet Exchange) также требует осторожности. Поздние повествования иногда связывают событие с инфраструктурой точки обмена или используют её название как удобный географический маркер. Рассмотренные здесь открытые данные не дают оснований приписывать всю ответственность за сбой самой точке обмена. Тезис о подотчётности основан на трансформации маршрутов, экспорте, принятии пирами и восстановлении, и не требует неподтверждённых утверждений о роли конкретного объекта в инциденте.

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

Бесклассовый BGP встретился с классовым внутренним протоколом

Технический механизм достаточно необычен, чтобы потребовать тщательного объяснения. BGP передаёт информацию о достижимости на сетевом уровне между автономными системами. Современные маршруты BGP включают префикс и длину префикса, например /16 или /24, а также атрибуты пути, которые операторы используют в политиках выбора и экспорта. RFC 4271 описывает базовый протокол и процесс принятия решений. [8]

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

Реконструкция APNIC описывает, как маршруты, полученные через бесклассовый eBGP, перераспределялись в RIPv1. Поскольку RIPv1 не мог сохранить исходные бесклассовые длины префиксов, маршруты были представлены способом, который привёл к деагрегации. Когда эти маршруты перераспределялись обратно в BGP, результирующие анонсы появлялись в виде множества более специфичных префиксов, а исходная информация о пути AS больше не сохранялась как внешняя история. [1]

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

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

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

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

Более специфичные маршруты превратили ошибочную информацию в реальность пересылки

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

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

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

Во время инцидента операторы сообщали о путях для своих сетей, где AS7007 указывался как источник. [3][4] Если трафик следовал по этим более специфичным маршрутам в сторону сети, неспособной доставить его до нужных адресатов, результатом была крупная «чёрная дыра». Некоторые пути могли вести себя иначе, потому что сети применяли фильтры, предпочитали другие маршруты или ещё не получили анонсы. Эта вариативность не ослабляет механизм; она показывает, что масштаб инцидента определялся распределённой политикой.

Слово «утечка» здесь точнее, чем «перехват». Позднее RFC 7908 предложил таксономию утечек маршрутов как распространения за пределы предполагаемой области. [9] Событие 1997 года предшествовало этому стандарту, и его необычную деагрегацию не нужно втискивать в одну современную категорию, чтобы вопрос подотчётности оставался ясным. Маршруты вышли за предполагаемую операционную границу, несли вводящую в заблуждение специфичность и информацию об источнике и были распространены достаточно широко, чтобы нарушить связность.

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

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

Ответственность была распределённой, но не отсутствовала

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

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

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

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

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

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

Разделение контроля подводит к многоуровневому выводу:

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

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

Моделирование экспорта должно проверять генерируемый набор маршрутов

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

Для клиентской или граничной сети модель экспорта может определять:

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

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

Инцидент с AS7007 демонстрирует важный инвариант: процесс маршрутизации не должен экспортировать более специфичный маршрут для внешнего префикса, если только он не авторизован явно. Другой инвариант мог бы ограничивать разницу между ожидаемым и генерируемым количеством маршрутов. Скачок от обычного набора клиентских анонсов до тысяч /24 должен останавливать развёртывание, даже если каждый отдельный маршрут синтаксически корректен.

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

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

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

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

Наиболее весомым доказательством является запись теста: ожидаемый набор маршрутов, сгенерированный набор, решение политики для каждого расхождения, утверждённый список исключений, результат проверки (canary result) и наблюдение за маршрутами в реальной работе после развёртывания.

Доктрина Heng.lu отделяет записи от принуждения

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

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

Уровень реальности — это маршрут, принятый маршрутизатором и установленный для пересылки. 25 апреля 1997 года операционной истиной было не только то, что утверждали реестры. Истиной было то, что более специфичные маршруты с AS7007 в качестве источника были приняты и распространены, и трафик следовал по ним.

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

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

Таким образом, доктрина сводится к трём практическим требованиям:

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

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

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

RPKI, RFC 8212 и роли BGP решают разные проблемы

В современных дискуссиях о безопасности маршрутизации часто задаётся вопрос, предотвратил бы RPKI старый инцидент. Ответственный ответ — условный.

Проверка происхождения маршрута сравнивает наблюдаемый префикс и исходный ASN с авторизациями происхождения маршрутов (ROA). RFC 6811 определяет состояния проверки, используемые маршрутизаторами. [12] Если для префикса существует действительный ROA, авторизующий другой источник, а AS7007 анонсирует конфликтующий более специфичный маршрут, этот маршрут может быть классифицирован как недействительный, в зависимости от покрытия префикса и максимальной длины.

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

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

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

RFC 8212 изменяет поведение по умолчанию для eBGP, требуя явных политик импорта и экспорта. [10] Это уменьшает случайное распространение, вызванное неявным принципом «принимать всё». Однако это не гарантирует, что явная политика корректна. Оператор может написать разрешительную политику, авторизовать небезопасное преобразование или применить неверный объект политики.

RFC 9234 вводит роли BGP и атрибут OTC, предназначенные для помощи сетям в идентификации и предотвращении определённых утечек маршрутов на основе ролей отношений. [11] Он решает задачу распространения с учётом отношений, но не заменяет авторизацию источников, тестирование генерируемых политик, лимиты префиксов или откат.

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

Многослойный урок таков:

RPKI и проверка происхождения маршрутов решают задачу авторизованного источника.
Данные IRR и реестров поддерживают ожидаемые записи о префиксах и политиках.
RFC 8212 требует явной политики.
Роли BGP и OTC решают задачу предотвращения утечек с учётом отношений.
Фильтры клиентской конусности и путей ограничивают распространение.
Лимиты префиксов ограничивают объём.
Моделирование конфигурации выявляет дефекты генерируемой политики.
Независимый мониторинг обнаруживает отклонения в работающем состоянии.
Откат и координация восстанавливают сервис.

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

Восстановление не завершилось, когда исходный маршрутизатор был отключён

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

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

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

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

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

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

BGPStream от CAIDA делает исторические и текущие данные маршрутизации доступными для анализа. [18] Коллекторы маршрутов ценны для независимого подтверждения, но они являются выборками. Зрелый процесс восстановления объединяет внутренние данные RIB и FIB, прямые отчёты пиров, открытые коллекторы и зонды пересылки.

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

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

Открытые данные о маршрутах весомы, но неполны

Открытые данные о событии маршрутизации 1997 года необычайно полезны, но всё же имеют ограничения. Сообщения NANOG предоставляют прямые наблюдения операторов и извинения. [3][4] Современные репортажи передают масштаб и неожиданность сбоя. [5] Более поздние технические описания объясняют взаимодействие протоколов. [1][2][6] Стандарты и руководства описывают средства контроля, которые могут применять операторы. [8]–[17]

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

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

Современные стандарты — это уроки для проектирования текущих средств контроля, а не ретроактивные требования соответствия. RFC 4271 был опубликован позже события, хотя и документирует зрелую модель BGP-4. RFC 7908, RFC 8212 и RFC 9234 появились значительно позже. [8]–[11] Они помогают объяснить классы сбоев и уровни предотвращения, но не доказывают, что AS7007 или его вышестоящие провайдеры были обязаны по контракту внедрить их в 1997 году.

Данные подтверждают несколько выводов с высокой степенью уверенности:

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

Данные подтверждают несколько выводов со средней степенью уверенности:

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

Остаются важные неизвестные:

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

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

Проверяемая программа исправления

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

1. Зафиксировать ожидаемые экспорты

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

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

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

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

Доказательства: репрезентативные входные маршруты, сгенерированные выходные маршруты, результаты проверки инвариантов и негативные тесты.

3. Сравнивать сгенерированные и ожидаемые анонсы

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

Доказательства: diff до развёртывания и результат условия остановки.

4. Обеспечить соблюдение фильтров для прямых клиентов

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

Доказательства: активное применение политики, тестовые анонсы (принятые и отклонённые), история обновлений и список исключений.

5. Внедрить явную политику на основе отношений

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

Доказательства: инвентаризация сессий, сопоставление ролей, применение политик и тест на соответствие.

6. Мониторить извне сети

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

Доказательства: запросы к коллекторам, хронология оповещений, результаты зондов и привязка к инциденту.

7. Установить автоматические остановки развёртывания

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

Доказательства: канареечная политика, порог, триггер и осуществлённая остановка.

8. Отрабатывать отзыв и очистку

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

Доказательства: временные метки отзыва источника, получения пиром, нормализации таблицы и восстановления пересылки.

9. Сохранять доказательства инцидента

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

Доказательства: неизменяемый пакет инцидента с хешами и контролем доступа.

10. Проверять исправление относительно исходного класса сбоя

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

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

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

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

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

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

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

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

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

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

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

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

Тест на подотчётность — это наблюдаемое принуждение

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

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

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

Современные механизмы улучшают среду контроля, но только тогда, когда их ограничения явно обозначены. RPKI может помочь отклонять неавторизованные источники. RFC 8212 может устранить неявную политику eBGP. Роли BGP и OTC могут помочь ограничить утечки, связанные с отношениями. Лимиты префиксов могут отлавливать аномальный объём. Клиентские фильтры могут ограничивать ожидаемые маршруты. Моделирование может сравнивать генерируемые экспорты с намерениями. Мониторинг и откат могут сдерживать и исправлять сбои.

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

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

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

Утечка AS7007 1997 года: почему фильтрация маршрутов стала тестом на подотчётность интернета

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