Утечка маршрутов Rostelecom 2020 и проверка происхождения

Резюме

По данным мониторинга Qrator, начало инцидента приходится примерно на 19:28 UTC 1 апреля 2020 года, а наблюдение длилось около часа. Это атрибутированное окно внешнего наблюдения, а не полная внутренняя хронология событий в Rostelecom и не доказательство точного начала и завершения в каждой затронутой сети.[1]
Qrator сообщил о 8 870 затронутых префиксах, принадлежащих почти 200 автономным системам. CERT-EU отдельно обобщил более 8 800 маршрутов из более чем 200 сетей. Эти цифры описывают масштаб, видимый с разных точек зрения источников; ни один источник не устанавливает каждый путь передачи данных, каждого затронутого пользователя или совокупный коммерческий ущерб.[1][2]
Qrator наблюдал распространение анонсов AS12389 через Rascom AS20764, Cogent AS174 и Level 3 AS3356. Эта цепочка показывает, что событие пересекло независимо управляемые домены маршрутизации, но не раскрывает точные фильтры импорта, договоры, состояние валидации или конфигурацию маршрутизаторов ни в одной из названных сетей.[1]
Доказательства маршрутизации требуют разделять несколько категорий: изученный маршрут, экспортированный за пределы предусмотренной политикой области; анонс с неавторизованным происхождением; повторно анонсированный более специфичный префикс; и маршрут, у которого авторизованное происхождение сохраняется, хотя путь нарушает ожидаемые деловые отношения. Эти категории по-разному взаимодействуют с фильтрацией и проверкой происхождения RPKI.[4][17]
Отдельный инцидент RIPE NCC произошёл в плоскости управления RPKI. После обновления программного обеспечения реестра 2 669 авторизаций происхождения маршрута (ROA) были удалены, поскольку некоторые независимые от провайдера выделения были классифицированы как не подлежащие сертификации. RIPE NCC восстановил отсутствовавшие ROA 2 апреля.[3][5]
Одновременность событий не означает причинно-следственную связь. Ретроспективный анализ RIPE NCC и независимый анализ Рабочей группы по маршрутизации не выявили прямой связи между удалением ROA и инцидентом маршрутизации Rostelecom.[4][5]
Измеренное пересечение между инцидентами оказалось узким: три держателя независимых от провайдера ресурсов и 12 префиксов. Это пересечение нельзя экстраполировать на все 8 870 префиксов, а открытые данные не позволяют описывать все затронутые маршруты как Invalid по RPKI.[4][5]
Проверка происхождения маршрута (Route Origin Validation) может сопоставить префикс и ASN его происхождения с валидированными данными ROA и классифицировать результат как Valid, Invalid или NotFound. Она не проверяет весь AS-путь, не определяет, соответствовал ли каждый экспорт коммерческим отношениям, не восстанавливает изменение конфигурации и не устанавливает намерения.[13]–[15]
Практический контроль был распределён. Rostelecom контролировал свои анонсы и экспортную политику; принимающие сети контролировали собственные решения по импорту, экспорту и валидации; держатели префиксов контролировали свои записи и ROA; RIPE NCC контролировал сервис сертификации и управления ROA; полагающиеся стороны контролировали актуальность кэшей и применение политик; провайдеры мониторинга контролировали свои системы наблюдения и оповещения.
Важные факты остаются неизвестными: исходная внутренняя последовательность, точное соотношение между утечками изученных маршрутов и повторно анонсированными более специфичными префиксами, представление RPKI в каждой принимающей сети, фильтры, применявшиеся на каждом участке пути, полная хронология реагирования, полное влияние на плоскость данных, а также случайный или намеренный характер начала инцидента.
Поэтому вывод о подотчётности носит операционный, а не обвинительный характер. Записи реестра и ROA давали доказательства о ресурсах и авторизации происхождения, а действующие конфигурации, актуальные кэши, политики соседей, мониторинг и скоординированное восстановление определяли, повлияло ли это доказательство на фактическое поведение маршрутизации.

Вопрос подотчётности

Инцидент 1 апреля 2020 года важен потому, что он выявил разрыв между зафиксированными полномочиями и реально действующим контролем. База данных RIPE могла определить административный объект, связанный с AS12389, а RPKI мог выразить авторизации происхождения некоторых держателей префиксов.[8][10] Ни одна из этих систем сама по себе не диктовала, что каждый маршрутизатор примет, предпочтёт или распространит.

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

Такая структура исключает простое объяснение, при котором одна запись реестра, один механизм безопасности или одна организация управляла всем исходом. Описанное Qrator распространение через AS20764, AS174 и AS3356 включило в наблюдаемую цепочку несколько операционных плоскостей управления.[1] Поведение Rostelecom было центральным, поскольку AS12389 фигурировал в рассматриваемых анонсах. Однако охват этих анонсов зависел также от того, какие соседи их принимали, какие маршруты эти соседи экспортировали дальше и что выбирали нижестоящие сети.

Именно поэтому событие стало проверкой пределов проверки происхождения. Если анонс использовал неавторизованное происхождение или недопустимую длину префикса, на которую распространяется ROA, оператор со свежими валидированными данными и применяемой политикой мог классифицировать его как Invalid и отклонить. Если маршрут сохранял авторизованное происхождение, но передавался по неподходящему AS-пути, та же проверка происхождения могла вернуть Valid. Если покрывающего ROA не было, результат обычно был бы NotFound, а не Invalid. Поэтому технические средства контроля имели разное влияние на разные части наблюдаемого события.

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

Подотчётность здесь означает определение того, кто имел практический контроль над измеримым решением и какие доказательства могут подтвердить это решение. Она не означает выводов о халатности, преступном характере, вине конкретных лиц, нарушении, правовой ответственности или мотиве перехвата на основе внешних наблюдений за маршрутизацией. CERT-EU отметил, что неясно, был ли инцидент случайным.[2] Доступные данные не снимают эту неопределённость, поэтому анализ не должен снимать её утверждением.

Хронология для технического расследования

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

Время	Событие с точки зрения доказательств
До 19:28 UTC 1 апреля	Открытые данные не позволяют установить исходное изменение конфигурации Rostelecom, маршрутизатор, команду, сотрудника или внутреннюю последовательность согласования. Они также не устанавливают точное состояние фильтров и RPKI до инцидента в каждой сети, которая позже приняла анонс.
Примерно 19:28 UTC	Qrator относит начало своего наблюдения примерно к 19:28 UTC. Платформа сообщила, что AS12389 анонсирует маршруты, связанные с большим набором других сетей.[1] Эта временная метка относится к данным мониторинга Qrator; она не доказывает, что каждый затронутый маршрутизатор получил своё первое обновление именно в этот момент.
Во время последующего распространения	Qrator сообщил, что анонсы распространились через Rascom AS20764, Cogent AS174 и Level 3 AS3356.[1] Наблюдение подтверждает видимое дальнейшее распространение через эти автономные системы, но не каждое решение на уровне сессий, оценку route-map или коммерческие отношения, стоящие за этим.
В течение примерно часового окна	Qrator насчитал 8 870 затронутых префиксов, принадлежащих почти 200 автономным системам.[1] CERT-EU позже обобщил данные о более чем 8 800 маршрутах из более чем 200 сетей.[2] Это атрибутированные измерения, а не доказательство того, что каждый маршрут имел одинаковое состояние проверки происхождения или одинаковые последствия в плоскости данных.
Во время реагирования на инцидент	Qrator сообщил, что Rostelecom получил предупреждение в реальном времени и работал с Qrator над диагностикой и восстановлением.[1] CERT-EU также отметил сотрудничество с сообщившей об инциденте компанией.[2] Точная последовательность эскалации, локализации и отката в Rostelecom не раскрыта.
Примерно через час после первого наблюдения	Qrator описал событие как продолжавшееся примерно час.[1] Открытые данные подтверждают восстановление в пределах этого наблюдаемого интервала, но не позволяют установить, какое изменение конфигурации или какой отзыв завершил каждый затронутый маршрут и произошла ли конвергенция одновременно во всех сетях.
Параллельный инцидент RPKI	Отдельно обновление программного обеспечения реестра RIPE NCC привело к тому, что некоторые независимые от провайдера выделения были классифицированы как не подлежащие сертификации, что вызвало удаление 2 669 ROA.[3][5] Это был сбой управления записями в плоскости управления, отличный от поведения маршрутизации AS12389.
2 апреля	RIPE NCC восстановил отсутствовавшие ROA.[3][5] Это восстановление относится к независимой хронологии восстановления сервиса RPKI и не должно представляться как механизм, завершивший событие Rostelecom.
Последующий анализ	Анализ Рабочей группы по маршрутизации и более поздний ретроспективный анализ RIPE NCC не выявили прямой связи между двумя инцидентами. Они обнаружили пересечение с участием трёх держателей PI-ресурсов и 12 префиксов.[4][5]

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

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

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

Что подтверждает наблюдаемое распространение

Наблюдения за AS-путем подтверждают, что неожиданная информация о достижимости не осталась в пределах одной сети. BGP — распределённый протокол: UPDATE, принятый одной автономной системой, может стать входными данными для процесса принятия решений другой системы и, при соблюдении политики, анонсом для дополнительных соседей.[12] Поэтому зафиксированное распространение AS12389–AS20764–AS174–AS3356 отмечает последовательность операционных решений в разных административных доменах.[1]

Эта последовательность не доказывает, что каждая названная сеть приняла каждый из 8 870 префиксов или что один и тот же путь достиг всего интернета. Она также не раскрывает, почему конкретная политика импорта приняла маршрут. Оператор мог полагаться на фильтры префиксов клиентов, данные Internet Routing Registry, валидацию RPKI, поддерживаемые вручную исключения, широкие лимиты, договорные допущения или их сочетание. Зафиксированные данные не раскрывают конфигурацию какой-либо названной вышестоящей или пиринговой сети на апрель 2020 года.

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

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

Четыре категории маршрутизации, которые нельзя смешивать

Слово «утечка» часто употребляется неточно, но этот инцидент нельзя корректно интерпретировать без разделения четырёх состояний маршрутизации. RFC 7908 определяет утечки маршрутов как распространение маршрутных анонсов за пределы предусмотренной области, особенно когда получившийся путь нарушает ожидаемый порядок отношений «клиент — провайдер — пиринг».[17] Это понятие отличается от авторизации происхождения.

Утечка политики изученного маршрута.Сеть получает легитимный маршрут от одного соседа и экспортирует его другому соседу за пределами предусмотренной политикой области. Авторизованное происхождение держателя префикса может оставаться в конце AS-пути. Ошибка заключается в области экспорта: промежуточная сеть выполняет транзит там, где политика этого не предусматривала. Поскольку исходный ASN происхождения и длина префикса могут по-прежнему совпадать с ROA, обычная проверка происхождения маршрута может классифицировать его как Valid, хотя путь коммерчески или операционно неприемлем.
Анонс с неавторизованным происхождением.ASN анонсирует префикс, который соответствующий держатель ресурсов не разрешал ему анонсировать. Если покрывающий ROA авторизует другой ASN, а у полагающейся стороны есть актуальные валидированные данные, анонс можно классифицировать как Invalid из-за несовпадения происхождения.[13]–[15] К этому состоянию иногда применяют технический термин «перехват происхождения» (origin hijack), но сам по себе ярлык не устанавливает злонамеренность, перехват трафика, преступное поведение или юридическую принадлежность.
Повторно анонсированный более специфичный префикс.ASN анонсирует более длинный префикс внутри агрегата другой сети и представляет себя в качестве источника. Покрывающий ROA может сделать более специфичный префикс Invalid либо потому, что ASN происхождения отличается, либо потому, что объявленная длина превышаетmaxLengthиз ROA. Более специфичный префикс может привлекать выбор маршрута, поскольку сопоставление наиболее длинного префикса выполняется до обычного сравнения путей BGP. Тем не менее открытые данные не устанавливают цель каждого повторного анонса или влияние каждого префикса на плоскость данных.
Утечка политики с корректным происхождением.Префикс, ASN происхождения и длина авторизованы, но AS-путь или экспортное отношение нарушают предусмотренную политику. Это самый наглядный пример границы ROV. Проверка происхождения отвечает, авторизовано ли происхождение по доступным данным ROA. Она не отвечает, имела ли промежуточная AS право предоставлять транзит, следовал ли путь разрешённым отношениям и следовало ли экспортировать маршрут этому соседу.

Открытые анализы показывают, что наблюдения апреля 2020 года включали смесь изученных маршрутов и повторно анонсированных более специфичных префиксов.[4] Точное соотношение неизвестно. Поэтому было бы неверно описывать все 8 870 маршрутов как анонсы с неавторизованным происхождением, все — как утечки политики с авторизованным происхождением или все — как Invalid по RPKI. Каждое такое описание заменяло бы невыясненное распределение однородной категорией, не подтверждённой доказательствами.

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

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

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

RPKI предоставляет криптографически защищённую структуру, с помощью которой держатели адресных ресурсов могут создавать авторизации происхождения маршрута. ROA показывает, что указанный ASN авторизован анонсировать префикс при соблюдении максимальной длины префикса.[13] Полагающаяся сторона получает и валидирует материалы RPKI, формирует валидированные данные ROA и делает эту информацию доступной для систем маршрутизации или механизмов политик. RIPE NCC управляет сервисами сертификации и ROA для ресурсов в своём регионе обслуживания, но не программирует централизованно маршрутизаторы каждой участвующей сети.[10]

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

Это уточнение важно во время инцидента с управлением записями. Две полагающиеся сети могли временно иметь разные валидированные представления из-за различий во времени синхронизации с репозиториями, состоянии кэшей, поведении при истечении срока действия или операционных действиях. RFC 7115 обсуждает операционную важность обработки полагающейся стороной и валидированной информации.[15] Зафиксированные доказательства не раскрывают точное содержимое кэшей, которое каждая сеть видела в течение часового наблюдения за Rostelecom.

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

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

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

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

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

Удаление RIPE NCC иллюстрирует это различие. Удаление 2 669 ROA могло после синхронизации изменить в представлениях полагающихся сторон статус некоторых маршрутов с Valid или Invalid на NotFound в зависимости от оставшихся покрывающих записей и времени обновления кэшей.[3][5] Оно не создало BGP-анонсы AS12389, не вынудило промежуточные сети экспортировать их и не изменило полные AS-пути. Для события Rostelecom задокументированное пересечение составило лишь трёх держателей PI-ресурсов и 12 префиксов, а последующий анализ не выявил прямой связи между инцидентами.[4][5]

Поэтому нельзя утверждать, что повсеместный ROV предотвратил бы весь этот инцидент. Он мог бы ограничить подмножество анонсов, которые были Invalid при доступных актуальных данных ROA и применяемой политике оператора. Он не отклонил бы сам по себе утечку политики изученного маршрута, у которой авторизованное происхождение не изменилось. Он также не валидировал бы весь AS-путь. Эта граница — не слабость доказательств, а корректное описание того, на какой вопрос был рассчитан механизм.

Первопричина

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

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

Событие RIPE NCC имело другую задокументированную техническую последовательность. Обновление программного обеспечения реестра классифицировало некоторые независимые от провайдера выделения как не подлежащие сертификации и удалило 2 669 ROA.[3][5] Этот сбой программного обеспечения и управления записями изменил данные RPKI, тогда как инцидент Rostelecom изменил действующие BGP-анонсы. Последующий анализ не выявил прямой причинно-следственной связи между ними.[4][5] Объединение этих двух событий в одну первопричину противоречило бы задокументированным данным.

Способствующие условия

Первым способствующим условием была зависимость BGP от локальной политики на каждой границе сети. BGP распространяет информацию о достижимости, но операторы определяют, что принимать, что предпочитать и что анонсировать.[12] Маршрут, который должен был остаться в рамках одного политического отношения, может распространиться, когда последовательные конфигурации это допускают. Наблюдаемое прохождение через AS20764, AS174 и AS3356 демонстрирует несколько точек приёма и экспорта, хотя и не раскрывает конкретную политику ни в одной из них.[1]

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

Третьим условием была зависимость от актуальных операционных данных. Корректно созданный ROA не влияет на маршрутизацию, пока полагающиеся стороны не получат и не валидируют его, кэши не останутся актуальными, маршрутизаторы не получат результат, а локальная политика не отреагирует на него. Удаление RIPE NCC временно затронуло уровень записей; синхронизация кэшей и локальное применение определяли, когда и повлияло ли это изменение на решения сети.[3][10][15]

Четвёртым условием была распределённая фильтрация. Фильтры клиентских префиксов, лимиты максимального числа префиксов, реестры маршрутов, валидация RPKI и проверки экспортной политики могут дополнять друг друга.[11][16] Открытые данные не устанавливают, какие из этих средств присутствовали, отсутствовали, были обойдены или неправильно настроены в Rostelecom или сетях распространения в апреле 2020 года. Это релевантные категории средств контроля, а не выводы о недокументированных конфигурациях.

Пятым условием была фрагментированная видимость. Провайдеры мониторинга могут видеть аномальные анонсы с отдельных точек наблюдения и предупреждать операторов, но у них нет Adj-RIB-In каждого маршрутизатора, локальной базы маршрутной информации, таблицы пересылки или истории конфигураций. Оповещение Qrator дало полезные внешние доказательства.[1] Оно не могло самостоятельно восстановить исходный внутренний сбой и не гарантировало, что все затронутые сети завершили конвергенцию одновременно.

Спусковое событие

Непосредственный спусковой механизм внутри Rostelecom остаётся неустановленным. На основе открытых доказательств его нельзя ответственно приписать конкретному лицу, команде, маршрутизатору, договору или мотиву. Первым обоснованным внешним событием является появление соответствующих анонсов AS12389 в точках наблюдения Qrator примерно в 19:28 UTC.[1]

«Спусковой механизм» не следует путать с «условием». Разрешительная политика соседей, неполное покрытие ROA, устаревшие данные или ограниченный мониторинг могут позволить событию распространиться или задержать его локализацию, но ни одно из этих условий не доказывает, что именно инициировало анонсы. Аналогично отдельное удаление ROA было одновременным, но не является задокументированным спусковым механизмом поведения маршрутизации AS12389.[4][5]

Обнаружение

Qrator сообщил об обнаружении события в реальном времени и предупреждении Rostelecom.[1] Его измерения дали примерное время начала, продолжительность, масштаб и видимую цепочку распространения, на которых основана открытая реконструкция. CERT-EU позже обобщил данные о событии и отметил как неопределённость относительно его случайного характера, так и сотрудничество Rostelecom с сообщившей об инциденте компанией.[2]

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

Реагирование

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

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

Реагирование RIPE NCC шло по собственной хронологии. Организация расследовала отсутствие ROA, восстановила их 2 апреля и позже описала улучшения мониторинга.[3][5] Это реагирование решало вопросы целостности и доступности записей RPKI. Оно не было тем механизмом реагирования на маршрутизацию, с помощью которого были исправлены анонсы AS12389.

Восстановление

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

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

Восстановление сервиса RPKI было отдельным: RIPE NCC восстановил удалённые ROA 2 апреля.[3][5] Полагающиеся стороны после этого зависели от собственных процессов синхронизации и валидации, чтобы получить исправленное состояние. Восстановление в репозитории и конвергенция в каждой полагающейся сети — связанные, но не идентичные события.

Распределение практического контроля

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

Субъект	Практический контроль	Граница доказательств
Rostelecom / AS12389	Анонсирование маршрутов и экспортная политика, фильтры для отдельных соседей, инвентари префиксов, проверка конфигурации, развёртывание изменений, мониторинг, эскалация и откат	Исходная конфигурация и внутренняя последовательность реагирования не раскрыты
Rascom AS20764, Cogent AS174, Level 3 AS3356 и другие сети распространения	Собственные фильтры импорта и экспорта, политика взаимоотношений, лимиты префиксов, использование ROV, исключения, реагирование на аномалии и дальнейшие анонсы	Конфигурации, состояние кэшей и договоры на апрель 2020 года неизвестны
Держатели префиксов	Точность записей о ресурсах, создание ROA, выбор ASN происхождения и`maxLength`, операционные контакты и независимый мониторинг маршрутов	Их отдельные решения нельзя единообразно вывести для почти 200 затронутых автономных систем
RIPE NCC	Системы сертификации и управления ROA, тестирование ПО, мониторинг сервиса, откат, восстановление и раскрытие инцидентов в рамках своей роли	Организация не выбирала и не принудительно применяла пути, используемые независимо управляемыми маршрутизаторами
Операторы полагающейся стороны	Синхронизация с репозиториями, актуальность кэшей, доставка результатов валидации, локальная политика Invalid/NotFound, исключения и итоговые решения по маршрутизации	Ни один глобальный наблюдатель не может вывести представление о валидации каждой полагающейся стороны в каждый момент
Провайдеры мониторинга маршрутов	Сбор данных с точек наблюдения, анализ аномалий, доставка оповещений, доказательства координации и отчётность после инцидента	Они наблюдают отдельные представления маршрутизации, не контролируют анонсы и не восстанавливают каждое внутреннее действие

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

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

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

Доказательства первопричины и способствующие доказательства

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

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

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

Измеримые меры по устранению

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

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

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

В-третьих, работу RPKI можно измерять сквозным образом. К релевантным показателям относятся возраст синхронизации с репозиторием, прогресс серийного номера кэша, доступность потока валидации, количество маршрутов Valid, Invalid и NotFound на сессию, исключения политики и оповещения о резких изменениях покрытия ROA. Существование записи в выпускающей системе недостаточно, если устаревший кэш или отключённый механизм политик не даёт ей влиять на текущие решения.[10][15]

В-четвёртых, держатели префиксов могут проверять, отражают ли ROA текущие происхождения и не шире лиmaxLength, чем требуется для эксплуатации. Более узкая авторизация может сделать некоторые неавторизованные более специфичные префиксы Invalid, но чрезмерно строгое значение может также лишить легитимности обоснованные анонсы для управления трафиком. Правильная настройка зависит от реальных планов маршрутизации, а более поздний анализmaxLengthи подверженности подделке происхождения супрефиксов подчёркивает необходимость рассматривать её как точное эксплуатационное решение.[20]

В-пятых, реагирование на инцидент можно оценивать с помощью временных показателей: время от первого аномального обновления до внутреннего оповещения; время до внешнего подтверждающего наблюдения; время до связи с соответствующим соседом; время до выявления затронутой политики; время до остановки нового распространения; и время до подтверждения восстановления на нескольких точках наблюдения. Материалы Qrator демонстрируют ценность предупреждения в реальном времени и координации, не раскрывая все эти интервалы.[1]

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

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

Данные реестра и действующая реальность

Записи реестра и ROA — важнейшие доказательства. Запись в базе данных связывает административную информацию с сетевым ресурсом, а ROA выражает авторизацию происхождения держателя ресурса.[8][13] Точность, уникальность и актуальные метаданные безопасности делают эти записи полезными для операторов и исследователей. Они помогают ответить, кто зафиксирован для ресурса и какому ASN разрешено анонсировать префикс.

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

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

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

Более поздний проектный контекст, а не требования с обратной силой

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

RFC 9234 позже определил BGP Roles и механизм Only-to-Customer, предоставив протокольные сигналы, призванные помочь выявлять и предотвращать определённые утечки маршрутов на основе структуры взаимоотношений.[19] Эта работа касается информации, которую ROV не несёт: соответствует ли распространение пути заявленным ролям. Её не следует описывать как требование апреля 2020 года, доказательство причины события или механизм, о котором известно, что он был доступен на наблюдавшихся сессиях.

RFC 9319 позже проанализировал операционные соображения, связанные сmaxLengthRPKI и подверженностью подделке происхождения супрефиксов.[20] Документ помогает объяснить, как покрывающая авторизация может или не может ограничивать более специфичный анонс. Он не устанавливает точную конфигурацию ROA для каждого затронутого префикса в 2020 году и не может превратить число 8 870 префиксов в количество маршрутов Invalid.

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

Что в этой статье не смешивается

Событие 2020 года отличается от аномалии финансовых маршрутов Rostelecom 2017 года. Более ранний инцидент имел другое время, другой набор затронутых маршрутов, продолжительность и вопрос атрибуции. Здесь он не пересказывается, а доказательства из того эпизода не могут использоваться для вывода о намерениях, повторяющейся причинности или ответственности за инцидент 1 апреля 2020 года. Этот анализ ограничен наблюдаемой цепочкой распространения AS12389, примерно часовым наблюдением и средствами контроля, относящимися к этому конкретному событию.

Статья также отличается от общего анализа неправильной настройки ROA и зависимости от общего механизма. Удаление RIPE NCC важно здесь только как отдельный одновременный инцидент с измеренным пересечением в три держателя PI-ресурсов и 12 префиксов.[4][5] Более широкая теория ошибок создания ROA заслонила бы конкретный вопрос: какие части этого смешанного события маршрутизации могла выявить проверка происхождения, а какие требовали политики с учётом путей и фильтрации на границе?

Это различие сохраняет доказательный центр события. Проверка подотчётности 2020 года зависит от анонсов AS12389, распространения через AS20764, AS174 и AS3356, разделения категорий маршрутов, зависящего от времени состояния ROA и независимо контролируемых решений маршрутизации. Без этих элементов анализ превращается либо в пересказ другого события Rostelecom, либо в абстрактное эссе об RPKI.

Ключевые неопределённости

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

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

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

Вывод

Инцидент Rostelecom 1 апреля 2020 года показал, что доказательства происхождения и доказательства маршрутной политики отвечают на разные вопросы. Qrator наблюдал крупное событие AS12389, начавшееся около 19:28 UTC, продолжавшееся примерно час и распространившееся через Rascom, Cogent и Level 3. Платформа насчитала 8 870 префиксов, связанных почти с 200 автономными системами, и сообщила о координации в реальном времени с Rostelecom.[1] Эти наблюдения устанавливают масштаб, распространение и реагирование, но не полную внутреннюю причину.

Одновременное удаление 2 669 ROA RIPE NCC было отдельным операционным сбоем. Последующий анализ не выявил прямой связи с утечкой Rostelecom и обнаружил лишь пересечение по трём держателям PI-ресурсов и 12 префиксам.[3]–[5] Эти доказательства исключают как смешение причин, так и утверждение, что все затронутые маршруты были Invalid.

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

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

Утечка маршрутов Rostelecom 2020 года: пределы проверки происхождения как тест на подотчётность