Утечка маршрутов Indosat 2014: тест контроля экспорта

Резюме

Границы события четко очерчены:В статье рассматривается массовое некорректное анонсирование AS4761, зафиксированное 2 апреля 2014 года примерно с 18:26 до 21:15 UTC. Из рассмотрения исключены отдельный инцидент Indosat 2011 года, более поздние аномалии AS4761 и несвязанные инциденты маршрутизации в Индонезии.
Количественные оценки зависят от наблюдателя:BGPMon зафиксировал 417 038 новых анонсов, тогда как RIPE NCC упомянул более 400 000 затронутых префиксов. Эти измерения подтверждают экстраординарный масштаб, зафиксированный с конкретных точек наблюдения, но не доказывают, что каждая сеть установила каждый путь или направила трафик через Indosat.
Истинная причина по-прежнему является лишь предположительной:Современные источники упоминают операционную проблему и неоднократные сообщения о неудачном окне обслуживания или нефильтрованном аплинке. Полная конфигурация Indosat, журнал изменений, состояние генерации политик и внутренний отчет о инциденте не являются публичными.
Ответственность определяется контролем над маршрутизацией:Indosat управлял тем, что AS4761 анонсировала и экспортировала. Непосредственные соседи контролировали фильтры префиксов, происхождения, типов отношений и максимального числа префиксов. Другие автономные системы контролировали принятие, предпочтение, дальнейший экспорт, мониторинг и эскалацию.
Реестры фиксируют полномочия, а маршрутизаторы обеспечивают доступность:Записи о ASN и номерных ресурсах идентифицируют владельцев и ожидаемые источники происхождения. RIS, RouteViews и другие коллекторы сохраняют выборочное текущее состояние. Ни запись в реестре, ни коллектор не блокируют анонс автоматически.
Авторизация происхождения и политики путей — разные вещи:Валидация происхождения маршрута может отклонить анонс, конфликтующий с действительным ROA, при наличии соответствующих записей и валидации. Сама по себе она не доказывает, что путь в отношении или объем маршрутов являются приемлемыми.
Восстановление — это не локальное заявление о конфигурации:Достоверное завершение инцидента демонстрирует отзывы, замену источников, конвергенцию с нескольких независимых точек наблюдения, остаточные исключения, измененные политики, проверенное поведение ограничения максимального числа префиксов и доказательство с помощью воспроизведения, что тот же класс отказов теперь изолирован.
Стандарт подотчетности — это воспроизводимая изоляция:Операторы должны иметь возможность продемонстрировать авторизованный набор маршрутов, сгенерированную и выполняющуюся политику, аномальное отклонение, первую возможность изоляции, временную шкалу действий и независимый тест на повторяемость.

Зафиксируйте инцидент до его интерпретации

Первый принцип подотчетности в маршрутизации — точно определить, какое событие рассматривается. 2 апреля 2014 года публичные системы мониторинга BGP сообщили, что AS4761, связанная с Indosat, начала анонсировать экстраординарное количество префиксов, которые обычно анонсируются другими автономными системами. BGPMon насчитал 417 038 новых префиксов и определил наблюдаемый интервал примерно с 18:26 до 21:15 UTC. Анализ RIPE NCC описал более 400 000 затронутых префиксов и использовал данные RIPE Routing Information Service и визуализации RIPEstat для реконструкции примеров распространения и доступности. [1][2]

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

В этой статье апрельское событие 2014 года не объединяется с более ранним инцидентом маршрутизации Indosat 2011 года. В нее не включены более поздние аномалии AS4761 или другие инциденты с индонезийскими сетями. Из событий, разделенных годами, не делается вывод о непрерывном операционном дефекте. Такое объединение могло бы создать более масштабное повествование, но ослабило бы доказательства, необходимые для определения контроля, оценки корректировки и проверки повторяемости.

Очерченное событие начинается с первых аномальных анонсов AS4761, зафиксированных указанными системами мониторинга около 18:26 UTC. Оно включает их распространение через отдельные сети, изменения доступности, видимые с определенных точек наблюдения, обнаружение и коммуникацию операторов, отзыв аномальных анонсов и возврат к ожидаемому состоянию путей. Оно заканчивается последними значимыми наблюдениями около 21:15 UTC, при этом признается, что разные коллекторы могут фиксировать разное время начала и окончания.

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

Таким образом, подотчетный анализ начинается с того, что показала работающая сеть: AS4761 выступила как источник для сотен тысяч префиксов; аномальные анонсы были видны за пределами сети-источника; некоторые пути и доступность изменились; и позже анонсы были отозваны. Намерения, внутренняя причина и полное устранение последствий считаются неизвестными, если они не подтверждены дополнительными доказательствами.

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

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

Число 417 038 занимает центральное место в публичных источниках, поскольку оно передает экстраординарный масштаб события. Это число также должно оставаться привязанным к своему источнику и методу. BGPMon сообщил это количество как число новых анонсов, связанных с AS4761. RIPE NCC использовал более общую формулировку — более 400 000 затронутых префиксов. [1][2] Эти цифры достаточно близки, чтобы подтвердить аномалию масштаба полной таблицы, но ни одна из них не должна представляться как универсальное значение, принятое каждой автономной системой.

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

При сообщении об инцидентах часто смешиваются несколько величин:

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

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

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

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

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

Некорректное анонсирование видно; намерения — нет

При обычной работе исходная автономная система сигнализирует, что она может доставить трафик для анонсированного префикса. Во время апрельского события 2014 года AS4761 выглядела как источник для префиксов, обычно связанных со многими другими сетями. Такое поведение часто описывают как захват, потому что источник изменился на автономную систему, от которой не ожидалось анонсирования этого адресного пространства. BGPMon использовал термин «захват» в своем современном отчете. [2]

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

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

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

Контрольные вопросы о доказательствах конкретны:

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

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

Исходная сеть контролирует первую границу экспорта

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

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

Экспортный контракт должен отвечать на четыре разных вопроса:

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

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

Явные политики по умолчанию снижают этот риск. RFC 8212, опубликованный спустя годы после инцидента, предписывает, что маршруты eBGP не должны импортироваться или экспортироваться без явной политики. [8] Его не следует проецировать назад как доказательство реализации Indosat в 2014 году. Он полезен как устойчивое сравнение: сессия должна разрываться с состоянием «закрыто», когда заданная политика отсутствует, а не обмениваться всем, пока не будет добавлен фильтр.

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

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

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

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

Непосредственные соседи имеют первую внешнюю возможность изоляции

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

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

Там могут действовать несколько средств защиты.

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

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

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

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

Явные импортные политики по умолчаниюне позволяют новой или неверно классифицированной сессии принимать всё из-за отсутствующей карты маршрутов.

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

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

Вопрос к непосредственному соседу — не «почему Интернет доверяет BGP?», а «почему действующая двусторонняя политика приняла этот набор и какие доказательства теперь показывают, что тот же набор будет отвергнут или помещен в карантин?»

Контроль максимального числа префиксов необходим, но одно лишь число — еще не политика

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

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

Зрелый дизайн имеет как минимум три состояния:

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

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

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

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

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

Авторизация происхождения и авторизация путей решают разные проблемы

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

RFC 6811 определяет валидацию происхождения префиксов BGP с использованием RPKI. RFC 6483 содержит руководство по операциям валидации происхождения. [10][11] Эти документы объясняют механизм, но не доказывают соответствующее покрытие 2014 года, состояние ROA, доступность валидаторов или политику маршрутизации соседей Indosat.

Необходимо явно указать три ограничения.

Во-первых, покрытие RPKI в 2014 году было ограниченным. Маршрут без покрывающего ROA не является автоматически недействительным; обычно он «не найден». Текущее состояние ROA не должно проецироваться назад на событие.

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

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

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

Обоснованная архитектура выстраивает уровни контроля:

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

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

Реестры — это журналы подотчетности, а не суверены доступности

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

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

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

Точны ли записи о ресурсах и контактах?
Фиксируются ли изменения и можно ли установить их авторство?
Могут ли операторы воспроизводимо получать фильтры?
Видны ли исключения?
Актуальны ли метаданные безопасности?
Может ли другая сеть проверить ожидаемое происхождение?

Маршрутизаторы и системы политик должны оцениваться как действующее принудительное исполнение:

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

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

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

Данные коллекторов доказывают выборочные наблюдения, а не универсальную конвергенцию

RIPE RIS и RouteViews сохраняют исторические данные BGP, что делает возможной независимую реконструкцию. RIPE описывает RIS как систему измерений, которая собирает и хранит данные маршрутизации в Интернете. RouteViews архивирует обновления за апрель 2014 года. [5][6] BGPStream от CAIDA предоставляет фреймворк для обработки данных BGP из крупных проектов сбора. [18]

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

Их ограничения должны быть частью каждого утверждения.

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

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

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

Исследовательские системы, такие как BGPInspector, показывают, как исторические события могут быть изучены через множество измерений и представлений доказательств. [15] Более поздние академические работы по утечкам маршрутов и их обнаружению далее демонстрируют, что классификация зависит от топологии, отношений и наблюдения. [16] Эти инструменты не заменяют операторскую телеметрию, но делают возможной независимую проверку.

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

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

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

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

Влияние должно измеряться слоями:

Видимость на плоскости управления:Какие коллекторы и пиры видели AS4761 как неожиданный источник?

Выбор маршрута:Какие сети выбрали этот путь, там, где эта информация наблюдаема?

Доказательства пересылки:С каких исходных точек данные traceroute, looking glass или потоков показали следование трафика по измененному пути?

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

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

Последствия для безопасности:Было ли свидетельство доступа к пакетам, инспекции или изменения? Одних лишь публичных записей о маршрутах недостаточно, чтобы установить это.

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

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

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

Мониторинг имеет ценность только тогда, когда он привязан к действию

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

Мониторинг должен связывать четыре элемента:

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

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

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

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

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

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

Отзыв начинает восстановление; он не доказывает его завершение

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

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

Достоверная запись о восстановлении должна показывать:

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

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

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

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

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

Тест на повторяемость должен воспроизводить класс отказа, не экспортируя его

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

Тест должен начинаться с зафиксированного ожидаемого набора для отношений AS4761. Затем он должен ввести:

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

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

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

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

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

Такой подход изменяет вопрос подотчетности с «обещал ли оператор быть осторожным?» на «может ли оператор воспроизвести отказ и показать, что его текущие действующие средства контроля сдерживают его?»

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

Ряд стандартов и операционных документов, опубликованных до или после 2014 года, дают полезную карту контроля.

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

RFC 8212 пропагандирует явные политики импорта и экспорта eBGP. [8] Он адресует опасное поведение по умолчанию, при котором маршруты текут при отсутствии заданной политики.

RFC 7454 описывает практики безопасности BGP, включая фильтры, максимальное число префиксов, обработку богонов и операционные меры защиты. [9]

RFC 6811 и RFC 6483 касаются валидации происхождения маршрутов через RPKI. [10][11] Они помогают проверить, авторизован ли источник, но не устанавливают полную приемлемость пути.

RFC 9234 добавляет BGP Roles и OTC для поддержки предотвращения утечек маршрутов через сигнализацию отношений. [12]

NIST SP 800-189 формулирует устойчивый междоменный обмен трафиком вокруг фильтрации, RPKI, мониторинга, безопасности и координации. [13]

MANRS идентифицирует действия операторов по фильтрации, предотвращению спуфинга, координации и глобальной валидации. [14]

Исследовательские и измерительные инструменты добавляют независимый анализ. BGPInspector иллюстрирует многомерную инспекцию инцидентов, более поздние исследования утечек маршрутов изучают обнаружение и классификацию, RIPEstat связывает регистрационные и маршрутные представления, а BGPStream поддерживает воспроизводимую обработку. [15][16][17][18]

Крайне важно соблюдать историческую дисциплину: эти документы не доказывают, что Indosat или его соседи внедрили 2 апреля 2014 года. Некоторые средства контроля были незрелыми, редкими или еще не стандартизированными. Современное сравнение может определить, что снизит вероятность повторения сейчас, не переписывая историю.

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

Подотчетность должна распределяться по границам, а не размываться по всему Интернету

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

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

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

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

Реестры номерных ресурсов и маршрутизацииконтролировали точность, доступность и аудируемость записей о ресурсах и политике в пределах своей компетенции. Они не контролировали принудительное исполнение на маршрутизаторах.

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

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

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

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

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

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

Управление должно требовать доказательств, не делая вид, что частная топология является публичной

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

Операторы могут публиковать или предоставлять ограниченные аттестации:

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

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

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

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

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

Апрельское событие 2014 года было контрольным тестом экспорта полной таблицы

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

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

Публичные доказательства устанавливают, что более 400 000 неожиданных анонсов, связанных с AS4761, стали видны 2 апреля 2014 года и были отозваны через несколько часов. Они подтверждают неравномерное распространение и влияние на доступность. Они не устанавливают злого умысла, универсальной пересылки, одной полной внутренней причины или публично проверяемой программы исправления.

Подотчетный ответ оператора закрыл бы эти пробелы с помощью:

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

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

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