Ошибка BGP Level 3 2017: урок подотчётности для магистралей

Резюме

Границы инцидента:6 ноября 2017 года независимый мониторинг связал крупное нарушение доступности сервисов Comcast с изменениями маршрутизации, связанными с Level 3 Communications и AS3356. ThousandEyes зафиксировала основное воздействие на Comcast в период примерно с 09:45 до 11:25 по тихоокеанскому времени, несоответствия маршрутизации наблюдались примерно с 09:30. [2] Современные сообщения содержали заявление Level 3 о том, что причиной сбоя стала проблема с конфигурацией. [1][5][6] Данная статья не объединяет этот инцидент с отдельным сбоем Level 3 в 2016 году, сбоем CenturyLink в декабре 2018 года, затронувшем службу 911, или инцидентом с AS3356 FlowSpec в августе 2020 года.
Наблюдаемый механизм:ThousandEyes сообщила о более специфичных объявлениях для более чем тысячи префиксов дочерних и клиентских сетей Comcast и зафиксировала, что трафик, ранее проходивший через магистраль Comcast AS7922, направлялся через AS3356 Level 3, что сопровождалось ростом потерь пакетов и задержек. [2] Это убедительное доказательство сбоя политики маршрутизации и его последствий для передачи данных. Оно не раскрывает точную внутреннюю команду, объект политики маршрутизации, процесс развёртывания или полный перечень затронутых пользователей.
Границы ответственности:Level 3 контролировала формирование конфигурации, её утверждение, масштаб развёртывания, политику экспорта BGP, мониторинг маршрутов, полномочия на откат и информирование об инциденте. Пиры и нижестоящие сети контролировали политику импорта, ожидания в отношении клиентской базы, лимиты префиксов, обнаружение аномалий и выбор резервных маршрутов. Comcast контролировала взаимодействие с абонентами и часть процесса восстановления, заметного пользователям. Клиенты и конечные пользователи могли наблюдать сбой, но не могли исправить состояние междоменной маршрутизации.
Урок для контроля:Конфигурация может быть синтаксически корректной и при этом нарушать операционные инварианты. Контроль изменений на магистрали должен тестировать ожидаемую доступность, область экспорта, изменения путей и радиус поражения до развёртывания, а затем сравнивать текущее состояние маршрутов и доступность для пользователей с этими ожиданиями. Batfish использовал этот инцидент как аргумент в пользу проверки модели сети, а не расчёта только на ручной анализ. [3]
Уровень реальности:Реестры и записи ASN помогают идентифицировать ресурсы и ответственных операторов, но они не обеспечивают соблюдение политики BGP. Коллекторы маршрутов показывают, что работающие сети анонсировали и принимали; зонды передачи данных показывают, достигал ли трафик пункта назначения. Подотчётность зависит от связи между запланированной политикой, действующими объявлениями, путями пакетов, записями об откате и наблюдаемым пользователями восстановлением.

Инцидент должен быть ограничен 6 ноября 2017 года

Первое требование к подотчётной реконструкции — определить, какое именно событие рассматривается. Level 3, а впоследствии организация CenturyLink или Lumen, фигурируют в записях о нескольких крупных сбоях. Объединение этих записей позволило бы получить более длинное описание, но ослабило бы выводы, поскольку механизмы, владельцы контроля и доказательства различаются.

Настоящая статья посвящена событию BGP, наблюдавшемуся в понедельник 6 ноября 2017 года. ThousandEyes сообщила, что её сотрудники, использовавшие подключения Comcast, столкнулись со сбоями в работе таких сервисов, как Slack, Gmail и Webex. Её измерения указывают на основное воздействие на Comcast в период примерно с 09:45 до 11:25 по тихоокеанскому времени. Также были выявлены несоответствия BGP примерно с 09:30, ещё до основного наблюдаемого интервала. [2]

Wired сообщила, что ошибка конфигурации Level 3 повлияла на доступ к интернету в некоторых частях США, и провайдер заявил о восстановлении сервиса после устранения проблемы. [1] Другие современные сообщения описывали массовые жалобы среди нескольких провайдеров доступа и приводили объяснение Level 3, сосредоточенное на проблеме с конфигурацией. [5][6] Эти сообщения подтверждают широкий общественный резонанс, однако карты жалоб и одновременные сообщения не доказывают, что все сети отказали по одной и той же технической причине.

ThousandEyes представляет наиболее убедительное связующее звено между состоянием маршрутов и пользовательским опытом. Её анализ описывает потери пакетов на путях внутри Comcast и Level 3, изменения маршрутов для связанных с Comcast направлений и возврат к норме после того, как Level 3 отозвала утекшие маршруты. [2] В более позднем ежегодном обзоре безопасности маршрутизации APNIC также назвал этот инцидент одним из заметных масштабных событий BGP 2017 года. [4]

Необходимы три исключения. Во-первых, этот инцидент не является сбоем Level 3 в 2016 году. Тот отдельный инцидент впоследствии привлёк внимание регуляторов и отрасли и был вызван иным механизмом. [8] Во-вторых, это не сбой CenturyLink в декабре 2018 года, нарушивший транспортную связь и работу службы 911. В-третьих, это не инцидент с AS3356 FlowSpec в августе 2020 года, когда действие по фильтрации трафика распространилось по магистрали и вызвало иной характер сбоя.

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

AS3356 превратил изменение конфигурации в междоменное событие

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

Level 3 управляла AS3356, крупной глобальной транзитной сетью. Записи RIPEstat предоставляют общедоступный обзор ресурсов и маршрутизации для этого номера ASN. [10] Запись ASN помогает идентифицировать оператора, связанного с наблюдениями за маршрутами. Она не показывает каждый частный пиринговый договор, отношения с клиентами или политику маршрутизатора, действовавшую во время инцидента.

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

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

ThousandEyes описала, как Level 3 анонсировала более специфичные маршруты, связанные с дочерними сетями и клиентами Comcast. Трафик, который ранее проходил через магистраль Comcast AS7922, стал идти через AS3356. [2] Более специфичная маршрутизация важна, поскольку передача данных обычно следует наиболее длинному совпадающему префиксу. Объявление, охватывающее более узкий адресный блок, может привлечь трафик, даже если более широкий маршрут остаётся видимым.

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

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

Данные BGP и данные о передаче трафика отвечают на разные вопросы

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

Коллектор маршрутов записывает обновления BGP от участвующих пиров. Архивы RouteViews предоставляют исторические данные обновлений за ноябрь 2017 года. [11] Служба маршрутной информации RIPE NCC аналогично собирает данные о маршрутизации из точек наблюдения по всему миру. [12] CAIDA BGPStream предоставляет инструменты и интерфейсы данных для анализа событий BGP. [13]

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

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

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

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

Доказательства 2017 года убедительны, поскольку наблюдения за маршрутами и передачей указывают в одном направлении. ThousandEyes увидела несоответствия маршрутов и изменённый AS-путь вместе с ростом задержек и потерь пакетов. [2] Провайдер объяснил нарушение проблемой конфигурации. [1][5][6] Такое сочетание подтверждает вывод о некорректной конфигурации BGP, сохраняя при этом неопределённость относительно внутренней реализации.

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

Термин «утечка маршрута» точнее, чем «перехват», но всё равно требует атрибуции

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

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

Перехват часто означает неавторизованный источник или путь, привлекающий трафик, иногда злонамеренно. Публичные данные за 6 ноября 2017 года свидетельствуют о непреднамеренном сбое конфигурации, а не о злом умысле. Современные сообщения описывали проблему с конфигурацией, и ThousandEyes использовала терминологию утечки маршрута. [1][2][5][6]

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

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

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

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

Синтаксически корректная конфигурация всё ещё может быть операционно ошибочной

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

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

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

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

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

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

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

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

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

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

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

Оценка радиуса поражения до развёртывания должна задавать вопросы:

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

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

ThousandEyes сообщила о более чем тысяче более специфичных маршрутов в событии 2017 года. [2] Ежегодный обзор APNIC поместил инцидент в число крупных инцидентов безопасности маршрутизации, затронувших тысячи автономных систем. [4] Эти цифры — наблюдения из названных анализов, а не полный внутренний подсчёт. Тем не менее, они показывают, почему количество маршрутов и внешнее распространение должны были стать условиями остановки.

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

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

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

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

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

Публичные данные указывают, что Level 3 исправила проблему конфигурации, а ThousandEyes зафиксировала отзыв утекших маршрутов примерно к 11:25 по тихоокеанскому времени. [1][2] Они не раскрывают, кто санкционировал откат, была ли предыдущая конфигурация восстановлена атомарно, как прошло схождение устройств и какие внешние сигналы использовались для подтверждения восстановления.

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

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

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

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

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

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

У пиров были собственные средства сдерживания

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

RFC 7454 описывает практики эксплуатационной безопасности BGP, включая фильтрацию префиксов, фильтрацию AS-пути, лимиты и политику, учитывающую отношения. [15] MANRS аналогично устанавливает ожидания по фильтрации, координации, глобальной валидации и предотвращению спуфинга среди сетевых операторов. [18]

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

Тем не менее, сеть, принимающая маршруты, должна быть в состоянии объяснить свою модель доверия:

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

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

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

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

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

RPKI помогает с авторизацией источника, но не со всеми утечками

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

Это важное средство контроля, но его область должна быть описана точно.

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

Публичные данные по Level 3 не устанавливают состояние ROA для каждого затронутого префикса в ноябре 2017 года, политику ROV каждого пира или контрфактический сценарий, в котором одно средство контроля предотвратило бы инцидент. Поэтому статья не утверждает, что RPKI остановила бы событие.

RPKI входит в систему мер по устранению как один из слоёв:

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

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

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

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

Реестровые записи — это доказательства, а не принуждение к соблюдению маршрутов

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

Они не пересылают пакеты и не обеспечивают соблюдение политики каждого пира простым декларированием.

RIPEstat помогает исследователю идентифицировать AS3356 и просматривать публичные данные маршрутизации. [10] RouteViews, RIPE RIS и BGPStream показывают объявления, наблюдаемые коллекторами. [11][12][13] Эти записи — часть бухгалтерской книги подотчётности. Принятый работающей сетью маршрут и путь пересылки, выбранный для пакетов, остаются уровнем реальности.

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

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

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

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

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

Коммуникация об инциденте должна называть отказавший уровень

Пользователи, столкнувшиеся с нарушением 2017 года, видели, как приложения отказывали или замедлялись. Они, как правило, не видели объект политики BGP, AS-путь или маршрут, перенаправивший трафик.

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

Подотчётное уведомление может сообщать:

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

Публичные сообщения содержали объяснение Level 3 о проблеме с конфигурацией. [1][5][6] Это было более информативно, чем необъяснённое уведомление о деградации сервиса. Публичные данные не показывают подробный постмортем провайдера с полной внутренней последовательностью и изменениями средств контроля.

У провайдеров доступа также была обязанность коммуникации. Пользователи Comcast столкнулись со сбоями сервисов, и анализ ThousandEyes сосредоточился на путях Comcast. [2] Comcast контролировала отношения с клиентами и могла описать влияние на абонентов, хотя и не контролировала конфигурацию Level 3.

Коммуникация должна сохранять неопределённость. Сообщения о перебоях у AT&T, Verizon, Spectrum и других сетей в примерно то же время не доказывают общую техническую причину. [5][6] Провайдер должен отделять подтверждённое общее влияние от коррелированных жалоб, всё ещё находящихся на расследовании.

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

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

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

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

Оценка влияния должна различать:

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

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

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

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

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

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

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

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

RouteViews и RIPE RIS видят маршруты, отправленные их коллекторам участвующими пирами. [11][12] BGPStream помогает исследователям обрабатывать и сравнивать эти наблюдения. [13] RIPEstat объединяет представления ресурсов и маршрутизации. [10] ThousandEyes добавляет тесты передачи и сервисов с распределённых точек наблюдения. [2]

Вместе эти источники могут установить:

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

Они, как правило, не могут установить:

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

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

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

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

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

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

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

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

Генерация и проверка конфигурации

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

Поэтапное развёртывание и условия остановки

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

Фильтрация у пиров и клиентов

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

Откат и восстановление

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

Раскрытие и верификация

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

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

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

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

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

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

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

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

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

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

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

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

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

Нерешённые вопросы — часть вывода

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

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

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

Данные подтверждают класс корневой причины: Level 3 объяснила нарушение проблемой конфигурации, в то время как независимые аналитики наблюдали утечку маршрута и ухудшение передачи с участием AS3356. [1][2][3][4][5][6]

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

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

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

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

Стандарт подотчётности — это доказательство запланированной политики в работающем состоянии

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

Наиболее убедительные публичные доказательства ограничены. ThousandEyes сообщила об изменениях маршрутов и передачи, более специфичных объявлениях, связанных с сетями Comcast, росте потерь пакетов и задержек и отзыве примерно к 11:25 по тихоокеанскому времени. [2] Level 3 объяснила нарушение проблемой с конфигурацией. [1][5][6] Batfish использовал это событие, чтобы показать, почему замысел политики должен моделироваться до развёртывания. [3] APNIC поместил его в число крупных инцидентов безопасности маршрутизации 2017 года. [4]

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

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

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

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

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

Инцидент Level 3 2017: как ошибка BGP превратила контроль изменений магистрали в проверку ответственности