Утечка маршрутов TTNet 2004: тест на подотчётность

Резюме

Замороженная граница инцидента:Эта статья охватывает утечку таблицы маршрутизации AS9121/TTNet, наблюдавшуюся 24 декабря 2004 года. Она не объединяет это событие с более поздними инцидентами связности в Турции, не связанными захватами маршрутов или другими утечками с участием других автономных систем.
Масштаб должен быть атрибутирован:Реконструкция NANOG и последующие исследования описывают утечку, затронувшую более 100 000 префиксов, что составляло подавляющее большинство видимой на тот момент глобальной таблицы маршрутизации с некоторых точек измерения. Точное количество зависит от коллектора, интервала, обработки дубликатов и определения события. Это свидетельство, а не универсальный журнал оператора.
Сбой пересёк границы отношений:Маршруты, полученные в одном контексте, были анонсированы там, где они не должны были появляться. Другие сети приняли и распространили их в соответствии со своей локальной политикой. Результатом стало не просто нарушение обслуживания TTNet; это было распределённое изменение глобального состояния маршрутов.
Ответственность следует за контролем:AS9121 контролировала импорт, экспорт, генерацию маршрутов, развёртывание, мониторинг и отзыв. Непосредственные провайдеры и пиры контролировали фильтры клиентских префиксов, ограничения по AS-path, лимиты максимального числа префиксов, оповещение и дальнейший экспорт. Последующие импортёры контролировали собственное принятие и сдерживание.
Реестр — это доказательство, а не принуждение:Записи ASN, адресов, IRR и более поздние записи RPKI могут описывать ожидаемых отправителей и держателей ресурсов. Они сами по себе не настраивают политику маршрутизатора. Работающий код и загруженная политика определяют, какой маршрут принимается и распространяется.
Современные меры контроля взаимодополняемы:Явная политика eBGP, фильтры авторизованных префиксов, лимиты максимального числа префиксов, валидация происхождения маршрутов, роли BGP и OTC, проверка клиентской конусности, обнаружение аномалий и проверенный откат решают различные виды сбоев. Ни один из них не является полным ретроспективным решением.
Восстановление требует внешних доказательств:Исправление конфигурации маршрутизатора или сброс сессии не являются достаточным подтверждением. Подотчётная запись восстановления показывает отзывы, заменяющие пути, остаточные устаревшие маршруты, координацию с пирами, сходимость и восстановленную доступность с независимых точек наблюдения.

Граница события — 24 декабря 2004 года

Первое правило при рассмотрении инцидента в инфраструктуре — заморозить событие. 24 декабря 2004 года операторы наблюдали аномальный набор маршрутов, связанных с TTNet, автономная система 9121. Событие обсуждалось в NANOG в то время и позже было реконструировано в презентации NANOG с использованием публичных данных BGP от коллекторов RouteViews и RIPE. [1][2] Позднейшие академические исследования использовали инцидент как яркий пример или маркированный случай для анализа утечек маршрутов и аномалий маршрутизации. [3][4][5]

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

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

Цифры требуют особой осторожности. Реконструкция NANOG и более поздняя литература обычно описывают более 100 000 затронутых префиксов и характеризуют этот набор как большинство видимой на тот момент глобальной таблицы. [1][3][4] Эти утверждения значимы, но они являются заявлениями о измерениях. Коллектор видит маршруты, экспортированные по подключённым к нему сессиям. Разные коллекторы могут получать разные пути, записывать обновления в разное время, по-разному подавлять дубликаты и оставаться слепыми к маршрутам, отфильтрованным до достижения.

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

Дата также имеет значение. Меры контроля, стандартизированные годы спустя, следует использовать для сравнения, а не как ретроспективные тесты на соответствие. Таксономия утечек маршрутов RFC 7908 была опубликована в 2016 году. [12] Поведение по умолчанию для явной политики в RFC 8212 — в 2017 году. [13] Механизм ролей BGP и Only-to-Customer в RFC 9234 появился в 2022 году. [14] Эти документы помогают определить проблему контроля, но не доказывают, что AS9121 или его соседи имели такие развёртывания в 2004 году.

Разумный вопрос не в том, «Почему сеть 2004 года не соответствовала стандарту 2022 года?», а в том, «Какие операционные инварианты должны были ограничить то, что мог анонсировать клиент или пир, какие организации контролировали эти инварианты и какие доказательства показали бы, что состояние маршрутов вернулось в норму?»

Утечка маршрута — это сбой политики отношений

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

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

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

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

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

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

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

Данные обновлений BGP — это не универсальный журнал пересылки

Публичные коллекторы маршрутов делают историческую подотчётность возможной. RouteViews архивирует обновления BGP и информационные базы маршрутизации от участвующих пиров. Его архив обновлений за декабрь 2004 года сохраняет данные, которые исследователи могут использовать для реконструкции изменений вокруг события с TTNet. [9] Сервис маршрутной информации RIPE предоставляет другую распределённую поверхность измерений и документацию о том, что коллекторы могут и не могут наблюдать. [10]

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

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

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

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

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

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

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

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

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

«Утечка» точнее, чем «захват»

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

Запись о TTNet поддерживает «утечку маршрута» как основной термин. Маршруты вышли за пределы предполагаемых отношений. Событие, по-видимому, связано с серьёзным сбоем политики или конфигурации. Нет необходимости утверждать, что TTNet намеревалась выдать себя за каждый затронутый источник или намеренно перехватывать трафик.

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

Валидация источника маршрута решает первый вопрос: авторизован ли ASN источника для этого префикса в соответствии с авторизацией источника маршрута? RFC 6811 определяет, как маршрутизатор может классифицировать маршруты с использованием данных RPKI. [15] Он не кодирует каждое отношение клиент-провайдер и не определяет, прошёл ли маршрут с действительным источником через недопустимую долину.

Механизмы, учитывающие отношения, решают другой вопрос: учитывая, где был изучен этот маршрут, следует ли его экспортировать или принимать на этой сессии? RFC 9234 формализует роли BGP и атрибут Only-to-Customer для класса предотвращения и обнаружения утечек маршрутов. [14] Подходы на основе клиентской конусности или ASPA решают вопрос авторизации пути с другой стороны.

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

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

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

Авторизация клиентских префиксов должна быть исполняемой

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

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

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

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

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

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

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

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

Проверки AS-path и политика отношений охватывают разные доказательства

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

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

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

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

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

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

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

Лимиты максимального числа префиксов — это предохранитель по объёму

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

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

Концептуально это простой механизм, но деликатный в эксплуатации.

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

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

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

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

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

Явная политика импорта и экспорта снижает неоднозначность умолчаний

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

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

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

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

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

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

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

RPKI улучшает доказательства происхождения, но не кодирует каждую утечку

RPKI позволяет держателям адресных ресурсов создавать криптографически проверяемые авторизации происхождения маршрутов (ROA). Доверяющий маршрутизатор может сравнить префикс и ASN источника BGP-маршрута с проверенными данными ROA и классифицировать маршрут как Valid, Invalid или NotFound в соответствии с соответствующей семантикой. RFC 6811 определяет валидацию происхождения префикса. [15]

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

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

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

NIST SP 800-189 рекомендует многоуровневую защиту междоменной маршрутизации, включая валидацию происхождения на основе RPKI и фильтрацию префиксов. [18] Его более широкая концепция полезна: устойчивая маршрутизация требует множества механизмов, потому что безопасность происхождения, политика пути, спуфинг, реакция на отказ в обслуживании и операционный мониторинг — это разные проблемы.

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

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

Мониторинг должен сравнивать работающие маршруты с предполагаемыми

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

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

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

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

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

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

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

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

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

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

Ответственность между AS9121, провайдерами, пирами и импортёрами

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

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

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

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

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

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

Конечные пользователи не контролировали почти ничего, связанного с BGP. Они испытывали медленные соединения, «чёрные дыры» или сбои обслуживания. Их отчёты могут помочь обнаружить воздействие, но они не могут валидировать AS-пути или инициировать отзывы.

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

Восстановление — это переход состояния маршрутов, а не декларация

Остановка триггера необходима, но недостаточна. BGP распределён, и состояние маршрутов сходится со временем.

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

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

Подотчётная запись восстановления должна отвечать на следующие вопросы:

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

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

Доказательства восстановления также должны сохранять неопределённость. Если один коллектор нормализовался в 10:00, а другой — в 10:07, отчёт не должен придумывать единую глобальную секунду восстановления. Он может сообщить интервал сходимости и описать точки наблюдения.

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

Без этого теста изменение политики остаётся обещанием.

Современный стек контроля многоуровневый

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

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

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

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

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

Валидация происхождения маршрута RPKI:Маршрутизаторы должны использовать проверенные доказательства происхождения в рамках операционной политики, которая учитывает Invalid, NotFound, сбой кэша и исключения. [15]

Роли BGP и OTC:Там, где поддерживается и уместно, взаимно подтверждённые роли и обработка Only-to-Customer могут кодировать и применять ожидаемые отношения. [14]

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

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

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

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

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

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

MANRS определяет фильтрацию, координацию, защиту от спуфинга и глобальную валидацию как действия оператора. [17] NIST SP 800-189 также рассматривает безопасность маршрутизации как набор взаимодополняющих мер, а не одно устройство. [18] Ценность этих фреймворков заключается в операционном внедрении и верификации.

Доказательства реестра и примат работающего кода

Событие с TTNet находится непосредственно на поверхности подотчётности Heng.lu: маршрутизация BGP, доказательства из реестров ASN и IP, а также отношения пиринга/транзита.

Запись ASN может идентифицировать AS9121. Адресные реестры могут идентифицировать распределения и назначения. Реестры маршрутизации могут публиковать объекты маршрутов и политику. RPKI может предоставить подписанную авторизацию происхождения. Эти записи уменьшают неоднозначность и создают цепочку доказательств.

Они не пересылают пакеты.

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

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

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

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

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

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

Что должно содержать убедительное описание исправления

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

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

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

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

Он должен включать репрезентативные обновления BGP от внутренних мониторов, непосредственных пиров, RouteViews и RIPE RIS. Он должен объяснить ограничения коллекторов и методологию подсчёта.

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

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

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

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

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

Этот пакет не сделает интернет безрисковым. Он сделает заявление оператора о контроле фальсифицируемым.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Современное исправление также многоуровневое. Фильтры авторизованных префиксов, ограничения AS-path, лимиты максимального числа префиксов, явная политика, валидация RPKI, роли BGP, тестирование политик, независимый мониторинг, скоординированное реагирование и верификация сходимости решают разные части цепочки отказа.

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

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

Во-первых, он знает, что клиент или пир авторизован анонсировать.

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

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

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

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

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