Эксперимент RIPE-Duke 2010: стандарты и ответственность за BGP

Кратко

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

27 августа 2010 года сотрудники RIPE NCC, эксплуатирующие службу информации о маршрутизации RIS (Routing Information Service), совместно с исследовательской группой Duke University провели эксперимент с протоколом межсетевой маршрутизации BGP. Исследователи изучали конструкцию безопасной маршрутизации, в которой сертификационная информация переносилась в опциональном транзитивном атрибуте пути. В 08:41 UTC RIPE NCC анонсировал 93.175.144.0/24 от RIS AS12654 через соединения на AMS-IX и GN-IX. Маршрут был планово отозван в 09:08 UTC.[1]

Анонс был необычным, поскольку атрибут был новым для публичного интернета. Однако необычность не означала ошибочность. RIPE NCC и Cisco описывали исходный атрибут как корректный или соответствующий стандартам.[1][2] Это различие определяет, как следует анализировать событие. Эксперимент не просто показал, что маршрутизаторы отвергают некорректный ввод. Он показал, что соответствующий стандартам ввод мог пройти формальные проверки, столкнуться с дефектом в установленном ПО, исказиться при распространении и затем активировать строгую обработку ошибок в другом месте.

Cisco сообщила, что затронутые системы IOS XR неправильно обрабатывали корректный, но нераспознанный транзитивный атрибут при передаче дальше. Соседний маршрутизатор мог получить получившийся искажённый UPDATE и сбросить BGP-сессию пиринга. Поскольку BGP-сессия переносит множество маршрутов, реакция на один дефектный UPDATE могла временно удалить несвязанную корректную информацию о достижимости. Если маршрутизатор, ответственный за исходящее искажение, не обнаруживал собственную ошибку, он мог снова анонсировать проблемную информацию после восстановления сессии, возобновляя нестабильность.[2][3]

Измерения RIPE NCC поддерживают вывод об ограниченном, но материальном воздействии. Скорость обновлений во время события достигала двадцатикратного превышения окружающего базового уровня. RIPE оценил, что дополнительные 0,5 % префиксов становились полностью недостижимыми дольше обычного. Доля нестабильных префиксов достигла пика в 1,4 %, что соответствует почти 4 500 префиксам и примерно девятикратному превышению обычного уровня, наблюдавшегося вокруг события. Результаты различались по коллекторам и местоположениям, при этом особенно интенсивная активность обновлений была видна на коллекторе в Вене.[1]

Эти цифры значимы, но они не дают права утверждать, что известный процент пользователей, маршрутизаторов, сетей или трафика исчез. Наблюдения плоскости управления учитывают поведение маршрутизации, а не людей. Анализ DNSMON в RIPE не обнаружил отказа корневых серверов. Он выявил ограниченные потери запросов для некоторых отслеживаемых доменов и более заметные проблемы на частях авторитетной инфраструктуры.si и.fr, при этом избыточные серверы продолжали отвечать.[1] Современные комментарии операторов упоминали проблемы доступа и изменения трафика на точках обмена, но такие сообщения не образуют полной количественной картины.[4][6]

Урок об ответственности поэтому уже и полезнее, чем история о том, что один актор «сломал интернет». RIPE NCC контролировал, будет ли его измерительная инфраструктура анонсировать видимый в интернете экспериментальный маршрут, а также сроки, уведомление, мониторинг и отзыв. Исследователи Duke контролировали дизайн исследования и реализацию на исследовательской стороне. Cisco контролировала обработку нераспознанного корректного атрибута в IOS XR, тестирование продукта, раскрытие и исправления. Сетевые операторы контролировали установленное ПО, политики маршрутизации, защиты пиров, мониторинг и восстановление в своих сетях.

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

Исправления также принадлежали разным слоям. Cisco выпустила уведомление в день события и подготовила исправляющие обновления.[2] RIPE NCC сохранил доказательства, передал информацию вендору, опубликовал анализ и взял обязательства по более строгим механизмам контроля для будущих совместных экспериментов.[1] Его Исполнительный совет позже поддержал продолжение исследований, подчеркнув при этом надлежащую коммуникацию.[5] Исправление продукта снизило риск реализации; более строгое управление экспериментами снизило риск обнаружения неизвестного взаимодействия через чрезмерно широкую публичную область отказа.

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

RFC 7606 позднее продвинул более узкую обработку некорректных BGP UPDATE, потому что сброс всей сессии может отбросить множество корректных маршрутов.[13] Операционные рекомендации, касающиеся явной внешней политики, предотвращения утечек маршрутов, валидации происхождения, RPKI и BGPsec, освещают смежные механизмы, но ни один из них ретроспективно не устанавливает халатность и ни один сам по себе не исправляет точный дефект исходящего искажения, вскрытый этим событием.[14][15][16][17][18][19][20]

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

1. Почему это событие заслуживает узкого анализа

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

Предмет рассмотрения — только эксперимент RIPE NCC и Duke University от 27 августа 2010 года. Это не рассказ о более поздних утечках маршрутов, более поздних перехватах или любых последующих сбоях BGP. Более поздняя таксономия утечек маршрутов из RFC 7908 полезна для различения категорий, но она не даёт оснований переквалифицировать этот эксперимент в обычную утечку маршрутов без доказательств того, что указанные условия утечки действительно выполнялись.[16]

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

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

Имеющиеся материалы отвечают на первые два вопроса с относительно высокой уверенностью. RIPE NCC и Cisco характеризовали исходный атрибут как корректный или соответствующий стандартам, а Cisco выявила уязвимость IOS XR, связанную с искажением при распространении.[1][2] NVD фиксирует проблему продукта как CVE-2010-3035.[3]

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

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

RIS существует для сбора и раскрытия информации о маршрутизации из множества точек наблюдения.[7][8] Записи RIPEstat и базы данных RIPE дают идентифицирующий контекст для AS12654, но запись об автономной системе не может раскрыть всё поведение ПО, встреченное на пути распространения.[9][10] Системы коллекторов маршрутов, такие как RIS и Route Views, ценны именно потому, что ни одна запись реестра, заявление пиринга или локальный журнал не могут описать всю систему междоменной маршрутизации.[11]

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

2. Хронология: от запланированного анонса до непреднамеренного сбоя

До 08:41 UTC: проектирование и проверка перед анонсом

Исследовательская группа Duke University изучала конструкцию безопасной маршрутизации, в которой сертификационная информация должна передаваться в опциональном транзитивном BGP-атрибуте пути. В рамках исследовательской работы Duke предоставила модифицированную реализацию Quagga. Предварительные проверки установили, что атрибут имеет приемлемую протокольную форму, а второй экземпляр Quagga не воспроизводил поведение, позже наблюдавшееся в затронутом установленном оборудовании.[1]

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

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

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

08:41 UTC: маршрут становится видимым

В 08:41 UTC 27 августа 2010 года RIS AS12654 начал анонсировать 93.175.144.0/24 с экспериментальным опциональным транзитивным атрибутом. Анонс распространялся через соединения RIPE NCC на AMS-IX и GN-IX.[1]

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

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

Во время распространения: корректная информация искажается

Затронутые системы IOS XR получали атрибут, который они не распознавали. Согласно конструкции опциональной транзитивности BGP, отсутствие распознавания само по себе не было основанием для отклонения атрибута. Требуемое поведение состояло в сохранении и передаче атрибута.

В описании Cisco выявлен сбой этого пути распространения: затронутые системы искажали в остальном корректный атрибут при передаче соседу.[2] Имеющиеся доказательства не позволяют выдумывать точную побайтовую мутацию для каждого затронутого пути. Надёжный вывод функционален: корректная незнакомая информация попала в затронутую реализацию, а искажённая информация появилась при распространении.

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

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

Приём нижестоящей системой: один UPDATE угрожает целой сессии

В соответствии с правилами обработки ошибок базового стандарта того периода некорректный атрибут пути мог привести к ошибке сообщения UPDATE (UPDATE Message Error) и закрытию BGP-сессии.[12] Такой ответ был серьёзным по замыслу: маршрутизатор, который не мог безопасно интерпретировать информацию о маршрутизации, защищал себя, завершая сессию.

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

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

Цепочка отказа, таким образом, была шире экспериментального префикса:

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

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

09:08 UTC: плановый отзыв

RIPE NCC отозвал экспериментальный анонс в 09:08 UTC, как и планировалось.[1] Таким образом, маршрут анонсировался примерно двадцать семь минут.

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

RIPE описал непреднамеренное операционное воздействие как продолжавшееся около тридцати минут. Бо́льшая часть нестабильности вернулась к норме примерно через двадцать минут после эксперимента, а не закончилась точно в секунду отзыва.[1] Эти описания следует воспринимать как измеренные операционные интервалы, а не как утверждение, что все затронутые пути восстановились одновременно.

После отзыва: реакция операторов и сбор доказательств

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

RIPE NCC сохранил данные эксперимента и передал собранные доказательства Cisco. Это сохранение имело значение, поскольку событие пересекло организационные границы. Журнал на стороне источника мог показать, что отправлял RIS, но не обязательно то, что выдавала промежуточная реализация. Отчёт вендора мог объяснить дефект, но не дать количественную оценку наблюдений по всему интернету. Достоверная реконструкция требовала доказательств из более чем одной области контроля.

22:00 UTC: уведомление Cisco

Cisco опубликовала уведомление об уязвимости IOS XR в 22:00 UTC 27 августа 2010 года.[2] Проблема была зарегистрирована как CVE-2010-3035, и Cisco подготовила исправляющие обновления ПО.[3]

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

31 августа и позже: публичный анализ и реакция управления

RIPE NCC опубликовал свой анализ инцидента и измерений 31 августа 2010 года.[1] В отчёте описаны эксперимент, взаимодействие реализаций, наблюдаемые эффекты маршрутизации, результаты DNSMON и планируемые изменения в будущих совместных экспериментах.

RIPE NCC сообщил, что будущие эксперименты будут получать более строгую процедуру, включая всестороннюю оценку воздействия, достаточное предварительное уведомление операторов и ответственную работу с уязвимостями.[1] Его Исполнительный совет позже поддержал продолжение исследований, подчеркнув при этом надлежащую коммуникацию.[5]

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

3. Что такое опциональный транзитивный атрибут — и почему «неизвестный» не означало «некорректный»

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

RFC 4271 определяет соответствующее поведение. Неопознанный опциональный нетранзитивный атрибут не нужно пересылать. Неопознанный опциональный транзитивный атрибут — другое дело. Он принимается и передаётся другим BGP-пирам, при этом бит Partial указывает, что промежуточная система не полностью распознала атрибут.[12]

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

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

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

Распознавание.Понимает ли маршрутизатор семантику атрибута?

Принятие.Имеет ли атрибут форму, которую маршрутизатор может безопасно принять по правилам протокола?

Распространение.Должен ли маршрутизатор передавать атрибут дальше или может?

Мутация.Изменяет ли маршрутизатор атрибут, и если да, разрешено ли это изменение и корректно ли оно закодировано?

Событие 2010 года не требовало от затронутых систем IOS XR понимания исследовательской сертификационной схемы. Дефект касался распространения. По описанию Cisco, затронутые системы искажали корректный нераспознанный транзитивный атрибут при передаче дальше.[2]

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

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

Ни один отдельный слой сам по себе не объясняет воздействие:

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

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

Точное описание — цепочный отказ с разными владельцами контроля.

4. От одного искажённого UPDATE к широкой нестабильности маршрутизации

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

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

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

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

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

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

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

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

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

5. Ограниченное воздействие: что поддерживают доказательства

Измерения RIPE дают три основных показателя.

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

Второй: RIPE оценил, что дополнительные 0,5 % префиксов становились полностью недостижимыми дольше обычного.[1] Это мера видимости на уровне префиксов. Её нельзя переводить в 0,5 % пользователей, трафика, маршрутизаторов или экономической активности. Префиксы сильно различаются по размеру, использованию и трафику, а коллекторы маршрутов не наблюдают каждый путь пересылки.

Третий: доля нестабильных префиксов достигла пика в 1,4 %. RIPE связал этот пик почти с 4 500 префиксов, что примерно в девять раз выше обычного уровня.[1] «Нестабильный» не тождествен «недостижимый повсеместно». Префикс может испытывать повторные изменения пути, оставаясь достижимым из некоторых мест.

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

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

Географическая вариативность и различия между коллекторами

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

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

Наблюдения DNS

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

Анализ действительно наблюдал ограниченные потери запросов для некоторых отслеживаемых доменов и более заметные трудности на частях авторитетной инфраструктуры.si и.fr. Избыточные серверы продолжали отвечать.[1] Доказательства, таким образом, поддерживают частичные и неравномерные эффекты DNS, а не всеобщий отказ DNS.

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

Сообщения операторов

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

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

Утверждения, которые доказательства не поддерживают

Ограниченный массив данных не устанавливает:

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

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

6. Ответственность через распределение контроля

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

Область контроля	Что контролировал участник	Что участник не контролировал	Какие доказательства нужны для более строгой оценки
RIPE NCC	Использование инфраструктуры RIS, видимое в интернете анонсирование, сроки, коммуникацию, мониторинг, отзыв, сохранение доказательств и будущую политику экспериментов	Поведение ПО на каждом внешнем маршрутизаторе и восстановление каждого оператора	История согласований, оценка рисков, план уведомления, пороги мониторинга, критерии отзыва и сохранённые наблюдения
Исследователи Duke	Дизайн исследования, построение экспериментального атрибута, изменения Quagga на исследовательской стороне и тестирование	Развёрнутый код IOS XR, политики нижестоящих сессий и развёртывание ПО операторами	Тестовые векторы, сгенерированные байты UPDATE, записи исследовательской реализации и охват тестов интероперабельности
Cisco	Разбор, хранение и поведение распространения IOS XR; покрытие тестирования продукта; раскрытие; исправления	Решение анонсировать эксперимент и графики установки у операторов	Анализ дефекта, матрица затронутых версий, результаты регрессионных тестов, доказательства исправленного кода и руководство по развёртыванию
Сетевые операторы	Установленное ПО, обслуживание, политики импорта и экспорта, контроль пиров, фильтрация, мониторинг и восстановление внутри своих сетей	Дизайн эксперимента, код вышестоящего вендора и полный глобальный путь распространения	Журналы устройств, захваты пакетов, конфигурации, версии ПО, история сессий и записи восстановления
Нижестоящие реализации BGP	Локальная обработка некорректного UPDATE по реализованным правилам	Создание исходного корректного атрибута или вышестоящее искажение	Журналы ошибок UPDATE, уведомления о сессиях и доказательства более узкой обработки там, где она поддерживается
Точки обмена	Связность, через которую участвующие сети обменивались маршрутами	По умолчанию — содержание и корректность каждого BGP-анонса участника	Доказательства конкретной роли route server, фильтрации или операционной функции перед назначением большего контроля

Контроль RIPE NCC

RIPE NCC контролировал действие, которое ввело экспериментальный маршрут в публичное распространение. RIS AS12654 был источником, использованным для теста, и анонс прошёл через соединения RIPE NCC на AMS-IX и GN-IX.[1] RIPE NCC также контролировал плановый отзыв, сбор доказательств и будущие правила для подобных совместных исследований.

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

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

Контроль Duke

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

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

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

Контроль Cisco

Cisco контролировала затронутую реализацию IOS XR. Её уведомление идентифицировало искажение корректного нераспознанного транзитивного атрибута при распространении.[2] Это поведение находится в области контроля продукта: разбор, удержание, сериализация, обработка флагов атрибута и регрессионное тестирование.

Cisco также контролировала своё раскрытие и поддерживающий ответ. Уведомление появилось в день инцидента, и были подготовлены исправляющие обновления ПО.[2] CVE-2010-3035 — публичный идентификатор уязвимости.[3]

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

Контроль операторов

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

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

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

Почему точкам обмена не следует назначать выдуманную роль

Эксперимент использовал соединения на AMS-IX и GN-IX.[1] Этот факт устанавливает путь распространения. Он не устанавливает без дополнительных доказательств, что какая-либо из точек обмена разработала эксперимент, одобрила атрибут, эксплуатировала затронутый маршрутизатор или контролировала экспортные политики участников.

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

7. Исправление продукта и исправление управления экспериментом — это разные вещи

Полный ответ требовал двух направлений исправлений.

Исправление продукта

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

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

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

Уведомление Cisco и обновления ПО были немедленными публичными действиями на этом уровне.[2] Уведомление сообщает о дефекте; обновление меняет реализацию. Они связаны, но не взаимозаменяемы.

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

Исправление управления экспериментом

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

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

Достоверное исправление управления включало бы:

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

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

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

Если бы Cisco исправил IOS XR, а механизмы эксперимента остались неизменными, более поздний эксперимент мог бы выявить другой неизвестный дефект в другой реализации. Конкретный риск продукта снизился бы, а риск обнаружения остался.

Если бы RIPE NCC усилил механизмы эксперимента, но затронутое ПО осталось неисправленным, обычный интернет-трафик, переносящий другой корректный незнакомый транзитивный атрибут, всё равно мог бы столкнуться с латентным дефектом. Риск публичного теста снизился бы, а риск продукта остался.

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

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

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

8. Более поздние стандарты как аналитический контекст — а не ретроспективное суждение

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

RFC 4271: исторический базовый уровень

RFC 4271 описывает BGP-4, включая опциональные транзитивные атрибуты и обработку ошибок.[12] Его правила распространения объясняют, почему нераспознанный транзитивный атрибут должен передаваться дальше. Его обработка ошибок UPDATE также помогает объяснить, почему некорректный атрибут мог привести к завершению сессии.

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

RFC 7606: сужение области отказа

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

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

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

RFC 7454 и RFC 8212: явная внешняя политика

RFC 7454 собирает операционные рекомендации по безопасности BGP, а RFC 8212 устанавливает ожидание явной политики для внешних BGP-анонсов и их приёма.[14][15] Вместе они усиливают базовый принцип контроля: внешние маршруты не должны обмениваться лишь потому, что сессия существует.

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

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

RFC 7908: таксономия утечек маршрутов

RFC 7908 описывает типы утечек маршрутов.[16] Здесь он полезен в основном как граница против небрежной терминологии. Событие 2010 года включало намеренно анонсированный экспериментальный маршрут и дефект реализации, затрагивающий опциональный транзитивный атрибут. Имеющиеся доказательства не следует растягивать, чтобы поместить его в более позднюю категорию утечек без сопоставления с условиями категории.

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

Валидация происхождения RPKI

RFC 6480 описывает архитектуру инфраструктуры открытых ключей ресурсов (Resource Public Key Infrastructure), а RFC 6811 определяет валидацию происхождения BGP-префиксов.[17][18] Валидация происхождения проверяет, уполномочена ли исходная автономная система соответствующей авторизацией происхождения маршрута (Route Origin Authorization) для префикса.

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

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

BGPsec

RFC 8205 определяет валидацию пути BGPsec.[19] BGPsec занимается криптографической защитой информации пути в определённой архитектуре. Это связано с более широкой целью безопасной маршрутизации, которую изучала группа Duke, но не является доказательством того, что было развёрнуто во время этого эксперимента 2010 года.

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

Руководство NIST по безопасности маршрутизации

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

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

9. Контрфактические сценарии: какое изменённое обстоятельство снизило бы воздействие?

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

Контрфактический сценарий 1: IOS XR корректно сохраняет атрибут

Изменим один факт: затронутые системы IOS XR получают корректный нераспознанный транзитивный атрибут и передают его без искажения.

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

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

Контрфактический сценарий 2: гетерогенное тестирование воспроизводит развёрнутое поведение

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

Дефект можно исследовать до того, как маршрут попадёт в широкое публичное распространение. Cisco может получить тестовый пример, а RIPE NCC и Duke могут решить, отложить, ограничить или перепроектировать эксперимент.

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

Контрфактический сценарий 3: эксперимент проводится в ограниченной среде маршрутизации

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

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

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

Контрфактический сценарий 4: нижестоящие маршрутизаторы используют более узкую обработку ошибок UPDATE

Изменим один факт: нижестоящий маршрутизатор сдерживает некорректный анонс без закрытия всей BGP-сессии там, где применима более поздняя узкая реакция.

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

Этот сценарий отражает направление, позже формализованное в RFC 7606.[13] Он должен оставаться аналитическим, поскольку этот RFC появился после события, а точная обработка зависит от класса ошибки и реализации.

Контрфактический сценарий 5: предварительное уведомление достигает затронутых операторов

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

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

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

Контрфактический сценарий 6: количественные критерии остановки вызывают более ранний отзыв

Изменим один факт: мониторинг выявляет аномальные скорости обновлений или сбросы сессий достаточно рано, чтобы пересечь заданный порог остановки до 09:08 UTC.

RIPE NCC отзывает маршрут раньше. Продолжение анонсирования заканчивается раньше, потенциально уменьшая повторения и время экспозиции.

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

Контрфактический сценарий 7: политика ограничивает распространение выбранными пирами

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

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

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

Контрфактический сценарий 8: коллекторы маршрутов и сервисные зонды обеспечивают немедленные коррелированные тревоги

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

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

Это не предотвращает первое искажение. Это улучшает обнаружение и сокращает интервал, в котором сохраняется неопределённость.

Контрфактический сценарий 9: эксперимент никогда не происходит

Изменим один факт: публичный анонс не делается.

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

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

10. Как выглядело бы проверяемое исправление

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

Доказательства продукта

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

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

Публичные CVE и уведомление идентифицируют проблему и ответ.[2][3] Они — начало проверяемости, а не полное доказательство закрытия в поле.

Доказательства эксперимента

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

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

RIS и Route Views иллюстрируют ценность множества точек наблюдения за маршрутизацией.[7][11] Они не заменяют журналы устройств или захваты пакетов, но могут независимо показать, распространялся ли анонс, умножались ли отзывы и различались ли эффекты по точкам наблюдения.

Доказательства операторов

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

присутствует ли (или присутствовало ли) затронутое ПО IOS XR;
какая исправляющая версия установлена;
как определена внешняя политика маршрутов;
как текущее ПО обрабатывает некорректные UPDATE;
как обнаруживаются сбросы сессий;
как измеряется потеря несвязанных маршрутов;
какие защиты пиров включены;
как фиксируются решения о восстановлении; и
завершён ли контролируемый регрессионный тест.

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

Критерии закрытия

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

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

11. Доказательства, которые изменили бы вывод

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

Захваты пакетов, показывающие, что исходный атрибут был некорректным

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

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

Журналы устройств, идентифицирующие другую точку искажения

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

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

Данные коллекторов, существенно пересматривающие оценки воздействия

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

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

Записи согласований и рисков, показывающие дополнительные механизмы

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

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

Записи продукта, показывающие более раннюю идентификацию и эффективный контроль

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

Текущий массив данных не устанавливает такого более раннего обнаружения.

Доказательства более широкого или более узкого воздействия на службы

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

Такие доказательства изменили бы раздел о воздействии, но не дали бы оснований переписать корректность исходного UPDATE без доказательств на уровне пакетов.

12. Сдержанный вывод

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

Это был живой эксперимент по маршрутизации, в котором корректный незнакомый опциональный транзитивный атрибут встретил затронутую реализацию IOS XR. Эта реализация исказила атрибут при его передаче. Нижестоящий маршрутизатор затем мог ответить на некорректный UPDATE сбросом BGP-сессии, отзывом несвязанных корректных маршрутов и вкладом в повторную сходимость. Измерения RIPE зафиксировали ограниченное, но материальное возмущение: исключительную скорость обновлений, дополнительную невидимость префиксов и пик почти в 4 500 нестабильных префиксов.[1][2]

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

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

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

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