Ошибка маршрутной политики Telia Carrier 2016 года

Резюме

17 июня 2016 года Cloudflare сообщила, что в 08:32 UTC обнаружила значительные потери пакетов в сети Telia Carrier AS1299. 20 июня в 12:10 UTC компания снова зафиксировала массовые потери пакетов и в 12:30 UTC отключила свои порты Telia, чтобы трафик мог перейти на других провайдеров. [1]
Сохранённое Catchpoint уведомление Telia для клиентов описывало более поздний этап 20 июня, начавшийся в 16:00 UTC во время планового обновления маршрутной политики для агрегированных префиксов в IP-ядре Telia Carrier. Согласно уведомлению, трафик к входящим в эти агрегаты префиксам отправлялся в «чёрную дыру», в 17:05 UTC прежняя политика была восстановлена, после чего сервисы постепенно восстановились. [2]
Catchpoint сопоставила уведомление оператора с резким ростом числа анонсов и отзывов маршрутов, которые наблюдались у двух пиров AS1299 на коллекторе RIPE RIS rrc01. Приведённые сведения о количестве маршрутов описывают отдельные наблюдения коллектора, а не число пользователей, пакетов или потерь. [2]
Запись Cloudflare делает границу ответственности необычно наглядной. Telia контролировала свою маршрутную политику, развёртывание, мониторинг, откат и коммуникацию с клиентами. Cloudflare контролировала диверсификацию провайдеров, решение об отключении, резервную ёмкость, мониторинг приложений и коммуникацию с клиентами. [1]
BGP-сессия может оставаться установленной, пока пакеты отбрасываются или уходят в «чёрную дыру». Поэтому видимость маршрута и соседство по протоколу — необходимые свидетельства, но ни то, ни другое не доказывает фактическую доставку пакетов. Операторам нужны независимые измерения пересылки и работы приложений.
В открытых материалах не раскрыты ошибочная конфигурация, лицо, внёсшее или одобрившее изменение, полный набор затронутых устройств, все клиентские маршруты, полное географическое влияние и долговременные меры устранения. Они также не подтверждают злонамеренный перехват.
RFC 7908, RFC 7454, RFC 8212, RFC 9234 и RFC 6811 дают полезный контекст по маршрутной политике и валидации. Ни один из документов не доказывает, какие средства контроля Telia использовала в 2016 году, а одна лишь проверка происхождения маршрута не подтвердила бы, что внутренняя агрегированная политика корректно пересылает трафик. [7][8][9][10][11]
Подотчётность должна следовать за практическим контролем и проверяемыми свидетельствами: ограниченные изменения политики, инварианты для конкретных агрегатов, канареечное развёртывание, обнаружение потерь пакетов за пределами изменённого пути, пороги отключения, пригодная резервная ёмкость, откат по таймеру и независимое подтверждение восстановления.

Событие должно оставаться ограниченным июнем 2016 года

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

Cloudflare описала потери пакетов в сети Telia Carrier AS1299 в пятницу, 17 июня 2016 года. Её системы обнаружили значительные потери между несколькими точками назначения в 08:32 UTC. По словам Cloudflare, потери стали прерывистыми, а затем исчезли, пока инженеры их анализировали. Эта запись подтверждает наблюдаемую проблему с доставкой пакетов у одного крупного транзитного провайдера. Она не устанавливает внутреннюю причину, продолжительность, которую ощутил каждый клиент, или непрерывный сбой, длившийся до следующего понедельника. [1]

В понедельник, 20 июня, Cloudflare обнаружила то, что назвала массовыми потерями пакетов в Telia Carrier, в 12:10 UTC. Компания сообщила, что отбрасывались её пакеты и пакеты других клиентов Telia. В 12:30 UTC Cloudflare отключила свои порты Telia. Поскольку она была соединена с другими провайдерами Tier-1, трафик мог уйти с нарушенного пути. Графики и рассказ Cloudflare связывают состояние вышестоящего оператора с ростом числа ошибок HTTP 522 и с её собственным маршрутным ответом. [1]

Catchpoint сохранила уведомление Telia для клиентов, описывающее событие маршрутной политики в 16:00 UTC того же дня. Согласно уведомлению, изменение касалось агрегированных префиксов в IP-ядре Telia Carrier и отправляло в «чёрную дыру» трафик для префиксов, входящих в эти агрегаты. Telia сообщила, что в 17:05 UTC откатилась к более ранней рабочей политике и наблюдала постепенное восстановление. Catchpoint сообщила о соответствующем росте числа BGP-анонсов и отзывов у двух пиров AS1299 на коллекторе RIPE RIS. [2]

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

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

Более поздние сбои с участием AS1299, Twelve99 или Arelion исключены. Не связанные с ними инциденты в сетях доступа Telia тоже. Текущая история компании может помочь корректно привязать сущность в справочнике при загрузке, но её нельзя использовать для импорта более поздних фактов в событие 2016 года.

Услуга транзита Tier-1 — это цепочка операционных обещаний

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

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

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

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

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

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

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

Агрегированные префиксы создают точный риск «чёрной дыры»

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

Сохранённое Catchpoint уведомление Telia говорило, что плановое обновление касалось маршрутной политики для агрегированных префиксов. Оно сообщало, что обновление отправило трафик для входящих в эти агрегаты префиксов в «чёрную дыру». Такая формулировка указывает на разрыв между достижимостью в плоскости управления и реальностью пересылки. Агрегат мог продолжать привлекать трафик, хотя сеть не имела корректного пути для части покрываемых точек назначения. [2]

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

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

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

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

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

Наблюдения BGP и измерения пакетов отвечают на разные вопросы

Catchpoint изучила наблюдения RIPE RIS с коллектора rrc01 на London Internet Exchange. Компания сообщила, что у двух пиров AS1299 наблюдался резкий рост числа анонсов и отзывов примерно в момент из уведомления Telia. Она оценила события, затрагивающие около 500 000 сетей IPv4 и 32 000 сетей IPv6, и описала более половины маршрутов IPv4 и более 30 процентов маршрутов IPv6, которые передавали эти пиры. [2]

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

RouteViews и RIPE RIS сохраняют данные о маршрутизации из множества точек наблюдения. Их ценность — историческая и сравнительная. Аналитики могут спросить, когда появились анонсы или отзывы, какие пути были видны и совпало ли возмущение с хронологией оператора. Они не могут восстановить каждый путь пакета без дополнительных доказательств. [15][16]

Разбор Cloudflare добавляет этот дополнительный уровень. Он описывает потери пакетов, ошибки HTTP 522 и перемещение трафика после отключения портов Telia. Измерения на уровне приложений и пересылки показывают последствия, которые одна лишь запись плоскости управления доказать не может. [1]

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

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

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

Ярлык утечки маршрутов не должен опережать факты

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

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

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

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

Это ограничение не делает событие менее значимым для безопасности маршрутизации. Оно меняет набор рассматриваемых средств контроля. Валидация происхождения по RFC 6811 спрашивает, авторизовано ли происхождение маршрута данными RPKI. Маршрут может быть валиден по происхождению и всё же операционно неверен, потому что неверны агрегированная политика, путь, следующий переход или решение об экспорте. [11]

RFC 8212 закрывает другой класс риска, требуя по умолчанию явные политики импорта и экспорта для eBGP. RFC 9234 добавляет роли BGP и атрибут Only-to-Customer, призванные ограничивать распространение утечек маршрутов. Эти механизмы помогают сделать политику отношений явной. Они не являются ретроактивным доказательством того, что проблема агрегированной политики Telia 2016 года была бы предотвращена. [9][10]

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

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

Маршрутную политику часто представляют как текст конфигурации, сгенерированные объекты, шаблоны или код. Проверка может подтвердить синтаксис, ссылки и форматирование, но пропустить поведение, которое возникнет после развёртывания. Уведомление Telia описывает плановое обновление, которое всё же отправило трафик в «чёрную дыру». Это признак пробела в поведенческой валидации. [2]

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

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

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

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

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

Откат нужно подготовить до изменения. Уведомление Telia говорит, что в 17:05 UTC была восстановлена прежняя рабочая политика. Запись об откате должна называть восстановленную версию, время завершения команды или развёртывания, охваченные устройства и доказательства, использованные для объявления восстановления. «Откатились» — это действие; «сервис восстановлен» — измеренный результат.

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

Аварийное переключение клиента — это операционная способность, а не галочка

Cloudflare смогла отключить свои порты Telia и перенести трафик на других провайдеров. Это действие ограничило время, в течение которого она продолжала отправлять трафик в теряющую пакеты магистраль. Оно также показывает, почему фраза «мультихоминг» может скрывать большие различия в реальной отказоустойчивости. [1]

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

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

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

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

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

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

Коммуникация — часть восстановления сети

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

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

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

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

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

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

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

Стандарты определяют средства контроля, но не доказывают их внедрение

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

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

RFC 8212 меняет ожидание по умолчанию для eBGP, чтобы маршруты не импортировались и не экспортировались без явной политики. Цель — снизить случайный обмен маршрутами, создаваемый разрешительными настройками. Это может устранить один класс неоднозначности, но не проверяет, что явная политика корректна. [9]

RFC 9234 описывает роли BGP и поведение Only-to-Customer, призванные помогать обнаруживать и предотвращать утечки, не согласующиеся с отношениями клиент-провайдер-пир. Документ касается ограничений распространения между автономными системами. Внутренняя «чёрная дыра» агрегата может существовать, не нарушая авторизацию происхождения или внешнюю роль. [10]

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

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

RIPEstat, RIPE RIS и RouteViews предоставляют записи и наблюдения, а не принуждение. Запись ASN помогает идентифицировать AS1299. Данные коллекторов помогают восстановить анонсы, видимые от выбранных пиров. Ни один из этих сервисов не управляет маршрутизаторами Telia и не гарантирует пересылку. [14][15][16]

Более позднее исследование Peerlock изучает механизмы ограничения отдельных утечек маршрутов между крупными сетями. Это релевантное сравнительное исследование, а не доказательство конфигурации Telia или гарантированный контрфакт. [17]

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

Реестр подотчётности следует за способностью контроля

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

Telia Carrier контролировала источник маршрутной политики, одобрение изменений, масштаб развёртывания, поведение агрегатов, внутреннее состояние маршрутов, состояние пересылки, откат и уведомление клиентов. Необходимые от Telia доказательства включали бы diff политики, затронутые объекты, тесты до развёртывания, масштаб канареечного запуска, историю алертов, точную хронологию отката, измерения восстановления и долговременные меры устранения.

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

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

Пиры и вышестоящие операторы контролировали собственные политики импорта и экспорта. Открытые данные не устанавливают, что их политика вызвала или усилила «чёрную дыру» агрегата. Им не следует приписывать вину лишь за то, что они обменивались маршрутами с AS1299.

RIPE NCC и RouteViews управляли инфраструктурой наблюдения. Их коллекторы сохранили частичные виды, помогающие восстановить плоскость управления. Они не контролировали политику Telia, и отсутствие в одном коллекторе не доказывало бы отсутствие повсюду.

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

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

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

Доказательства восстановления должны пережить зелёную панель мониторинга

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

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

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

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

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

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

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

Уровень реальности — это работающий маршрут и доставленный пакет

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

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

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

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

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

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

Чего инцидент не доказывает

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

Оно не доказывает один непрерывный сбой с 17 по 20 июня. Cloudflare описала отдельные наблюдения, а у более позднего уведомления о маршрутной политике собственная хронология. [1][2]

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

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

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

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

Оно не доказывает текущее состояние Arelion/Twelve99. Статья рассматривает историческое событие Telia Carrier. Текущая корпоративная идентичность и привязка в справочнике — вопросы метаданных публикации, а не доказательство нынешней работы.

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

Стандарт подотчётности

Подотчётность транзита Tier-1 начинается с простого правила: анонсируемая достижимость — не то же самое, что оказанная услуга. Операторы должны проверять и то, и другое.

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

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

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

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

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

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

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

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

Ошибка маршрутной политики Telia Carrier 2016 года превратила отказоустойчивость Tier-1-транзита в проверку подотчётности

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