Кратко

  • ARTEMIS — система с открытым исходным кодом, которую разворачивает сам оператор. Она сопоставляет текущие наблюдения BGP с локально заданным маршрутизационным замыслом и добавляет контекст, недоступный одним лишь публичным коллекторам.
  • В исследовании FORTH и CAIDA 2018 года сообщалось об обнаружении за секунды и нейтрализации менее чем за минуту в проверенных условиях; это не универсальная гарантия для промышленной эксплуатации.
  • Для смягчения ARTEMIS может объявлять более специфичные маршруты или запускать собственные процедуры, однако фильтры, устаревшая политика, неполная видимость и широкие полномочия способны превратить быстрый ответ во второй инцидент.
  • Теперь жизнеспособность проекта зависит от дисциплины релизов, убедительных данных о внедрении и прозрачной границы с Code BGP: коммерческое сопровождение может поддержать открытый код, не подменяя историю исследовательского проекта.

Реальное изменение маршрута показало, почему секунды — только начало

В годовом отчёте CAIDA за 2019 год говорится, что ARTEMIS за несколько секунд обнаружил реальный перехват маршрута, затронувший префикс Internet2 /30. Этот случай важен потому, что выводит доказательства за пределы синтетических объявлений, подготовленных самими исследователями. В сети, участвовавшей во внедрении, действительно изменился маршрут, и система достаточно быстро распознала отклонение, чтобы поддержать расследование.

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

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

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

ARTEMIS создавался именно для промежутка между обнаружением и действием. Название расшифровывается как Automatic and Real-Time dEtection and MItigation System, но необычный регистр букв не должен заслонять рабочую модель. Это не центральная служба, которая видит весь интернет и издалека ремонтирует чужие сети. Организация разворачивает программу в подконтрольной инфраструктуре, определяет состояние маршрутизации, которое считает легитимным, подключает публичные и частные наблюдения и решает, насколько далеко система может зайти, когда фактические данные расходятся с политикой.

Обещание проекта — скорость с учётом контекста; ограничение — и контекст, и полномочия остаются локальными.

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

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

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

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

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

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

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

Событие с подпрефиксом обычно сильнее притягивает трафик, потому что правило самого длинного префикса отдаёт приоритет более узкому маршруту. Если сеть обычно объявляет /20, а другой источник объявляет находящийся внутри него /24, маршрутизаторы, принявшие /24, как правило, направят адресованный туда трафик к подпрефиксу. Деагрегация служит и распространённой защитой: легитимный оператор объявляет такие же или ещё более специфичные маршруты, чтобы вернуть предпочтение. Но у этого метода есть жёсткий предел: многие сети фильтруют IPv4-маршруты длиннее /24 и IPv6-маршруты длиннее /48.

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

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

ARTEMIS помещает собственный маршрутизационный замысел оператора внутрь детектора

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

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

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

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

Преимущество надёжно лишь настолько, насколько надёжно само заявление. Сети меняют провайдеров, добавляют anycast-площадки, переносят исходные AS, создают временные резервные пути и выпускают аварийные объявления во время сбоев. Политика, точная в январе, к июню может устареть. Если изменение дошло до маршрутизаторов, но не до ARTEMIS, детектор способен выдать ложное срабатывание высокой серьёзности. Если правила чрезмерно расширили ради подавления шума, настоящее нарушение может оказаться «разрешённым» на бумаге.

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

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

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

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

FORTH и CAIDA превратили исследовательский вопрос в рабочий процесс оператора

Проект возник в сотрудничестве исследователей Foundation for Research and Technology-Hellas в экосистеме Университета Крита и CAIDA при Калифорнийском университете в Сан-Диего. FORTH внёс знания по защите маршрутизации и системной инженерии. CAIDA добавила инфраструктуру измерения интернета, опыт BGPStream и связи, которые помогли перенести разработку в сети науки и образования. Поэтому ARTEMIS с самого начала был не только алгоритмом обнаружения: он соединял знание протокола, измерительные системы и доступ к операторам.

Финансирование следовало той же смешанной институциональной модели. В истории проекта фигурируют европейские и американские исследовательские программы, Community Projects Fund RIPE NCC, проект внедрения NSF EAGER, Министерство внутренней безопасности США и Comcast Innovation Fund. Поддержка RIPE в 2017 году помогла превратить прототип в инструмент для оператора, а грант в 50 000 евро в 2019 году финансировал проверку плоскости передачи данных с использованием RIPE Atlas.

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

Институциональная история важна для корректной атрибуции. ARTEMIS — не отдельно учреждённый фонд, не служба CAIDA и не глобальный детектор, принадлежащий FORTH. Это открытое программное обеспечение под лицензией BSD 3-Clause, с исследовательской родословной и нынешним коммерческим сопровождающим. Его развитие правильнее описывать как последовательность сотрудничеств, а не как собственность одной организации.

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

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

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

Статья 2018 года в IEEE/ACM Transactions on Networking дала ARTEMIS самое запоминающееся утверждение: нейтрализация перехвата BGP в течение минуты. Исследователи проверяли подход в реальных экспериментах и сообщили об обнаружении за секунды и смягчении до истечения минуты в испытанных условиях. Результат был значимым, потому что показал: сети-жертве не обязательно ждать внешнюю службу, цепочку телефонных звонков и вручную собранное встречное объявление.

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

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

Несколько неполных представлений складываются в пригодную картину инцидента

ARTEMIS может использовать несколько публичных источников, потому что ни один коллектор не видит все маршруты. RIPE RIS и проект RouteViews Университета Орегона получают обновления BGP от выбранных партнёров в распределённых точках сбора. CAIDA BGPStream даёт общий механизм доступа и нормализации маршрутизационных данных из нескольких источников. Каждая служба расширяет поле зрения оператора, но одновременно отражает только сети, которые решили соединиться с её коллекторами, географию этих сессий и временные свойства потоков.

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

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

RIPE NCC представил публичный прототип RIS Live в феврале 2019 года, чтобы передавать сообщения BGP с гораздо меньшей задержкой, чем периодическая обработка архивов. ARTEMIS стал одним из примеров того, зачем нужен такой поток. Система безопасности не может реагировать за секунды, если основное наблюдение поступает через много минут, тогда как поток в реальном времени позволяет детектору оценивать обновления по мере их получения коллекторами.

Меньшая задержка не меняет пределы наблюдения. RIS Live по-прежнему отражает партнёров, подключённых к RIPE Routing Information Service, и маршруты, которые эти партнёры экспортируют. Если перехват остаётся локальным, отфильтровывается до коллектора или затрагивает путь, скрытый другим отношением, решающего свидетельства в потоке может не появиться. Важна и надёжность: сбой потока или изменение схемы будут выглядеть как тишина, если мониторинг не различает «подозрительных маршрутов нет» и «данных нет».

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

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

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

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

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

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

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

Приложение разделяет наблюдение, обнаружение и доказательства

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

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

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

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

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

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

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

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

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

Маршрутный шаблон не доказывает ни мотив, ни последствия

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

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

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

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

Эта граница является центральной для ARTEMIS. Детектор способен показать, что маршрут нарушил политику оператора и появился в определённых точках наблюдения. Он не выводит мотив из AS-пути и не гарантирует, что traceroute идёт в том же направлении, что и прикладной трафик. Шифрование, поведение DNS, кэширование, anycast и переключение приложений дополнительно меняют пользовательский опыт. Поэтому предупреждение плоскости управления — свидетельство инцидента, но не весь инцидент.

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

Грант RIPE Community Projects Fund 2019 года поддержал расширение ARTEMIS с измерениями traceroute RIPE Atlas для оценки эффекта обнаруженных событий. Работа признавала ограничение первоначальной петли плоскости управления. Маршрут может выглядеть опасным в BGP и почти не влиять на пользователей, тогда как небольшая область распространения способна затронуть ценную группу клиентов. Пробы плоскости данных добавляют сведения о предполагаемом пути трафика и достижимости конечных точек.

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

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

Деагрегация возвращает трафик лишь тогда, когда её допускает система маршрутизации

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

У деагрегации жёсткие пределы. Многие сети фильтруют IPv4-маршруты длиннее /24 и IPv6-маршруты длиннее /48, чтобы ограничивать рост таблиц и злоупотребления. Жертва, уже объявляющая /24 или /48, может не суметь выпустить более специфичный маршрут, который примет широкий интернет. Провайдеры также ограничивают разрешённые клиенту объявления, а объекты маршрутов, фильтры префиксов или данные RPKI должны допускать аварийное состояние. Распространение не мгновенно и не единообразно, поэтому старые и новые пути могут сосуществовать.

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

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

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

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

RPKI усиливает лишь одно звено цепочки доказательств

Resource Public Key Infrastructure позволяет держателям адресов создавать Route Origin Authorisations, указывающие, какие автономные системы могут объявлять заданные префиксы и максимальные длины. Маршрутизаторы или системы политики выполняют Route Origin Validation и классифицируют маршрут как действительный, недействительный или отсутствующий в записях. Это добавляет криптографическое свидетельство к той части BGP, которая иначе опирается на распределённое доверие. Контроль проактивен: другие сети могут отвергнуть или понизить приоритет неразрешённого источника до того, как по нему пойдёт трафик.

ARTEMIS работает на другом уровне инцидента. Он может использовать состояние проверки RPKI как доказательство, но также сравнивает маршруты с частными правилами оператора, записывает событие, объединяет публичные и локальные потоки и связывает обнаружение с реакцией. RPKI не проверяет весь AS-путь, а политика внедрения не универсальна. Маршрут может быть действительным по RPKI и всё же нарушать ожидаемое отношение соседства или утечь по нежелательному пути. И наоборот, законное изменение будет недействительным, если его не внесли в ROA.

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

Пилотные проекты вывели ARTEMIS из лаборатории, но не доказали масштаб рынка

CAIDA сообщила об экспериментальном внедрении ARTEMIS при поддержке NSF совместно с Internet2, Great Plains Network и Merit в 2018–2019 годах. Эти пилоты важны, потому что сети науки и образования имеют реальные префиксы, провайдеров, процессы изменений и обязательства по сервису. Операторы могли проверить, вписывается ли программа в существующий мониторинг, отражают ли правила их маршрутизационный замысел и как тревоги входят в реагирование.

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

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

Контроль оператора означает нагрузку по интеграции и защите программной цепочки поставок

ARTEMIS распространяется по лицензии BSD 3-Clause. Оператор может изучить код, запустить его в контролируемой инфраструктуре, изменить интеграции и не передавать чувствительную политику единственному обязательному центральному провайдеру. Такая модель соответствует главному преимуществу проекта: наиболее ценная эталонная информация должна оставаться внутри самой сети. Лицензия допускает и коммерческое использование, и форки, поэтому Code BGP и другие участники могут строить услуги вокруг открытой основы.

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

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

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

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

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

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

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

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

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

Релизы и Code BGP определяют нынешнюю проверку сопровождения

Последний формально помеченный релиз, указанный в исследовательском пакете, — версия 2.3.0 Cadmus от 24 ноября 2022 года. На дату отсечения 5 августа 2026 года живая демонстрация показывала более позднюю сборку по коммиту, а сайт проекта оставался активным. Это подтверждает, что работа продолжалась после последнего формального выпуска, но одновременно поднимает правомерный производственный вопрос: какая версия проверена, поддерживается и пригодна для обновления?

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

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

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

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

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

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

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

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

ARTEMIS занимает требовательную середину в защите маршрутизации

В поле защиты маршрутизации входят публичные коллекторы, исследовательские системы вывода, открытые инструменты тревог, валидаторы RPKI и коммерческие платформы мониторинга. RIPE RIS, RouteViews и BGPStream предоставляют данные, а не рабочий процесс инцидента, настроенный под конкретного оператора. BGPalerter предлагает другую открытую модель мониторинга. MANRS задаёт операционные нормы, но не обнаруживает события в реальном времени. Коммерческие службы могут дать широкое наблюдение и поддержку аналитиков, однако без интеграции с клиентом им часто недостаёт частного локального контекста.

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

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

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

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

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

Настоящий продукт — управляемая петля обратной связи

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

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

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

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

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

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

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

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

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

Источники

  • Сайт проекта ARTEMIS
  • Архитектура ARTEMIS с открытым исходным кодом на RIPE Labs
  • Исходный репозиторий и документация ARTEMIS
  • «ARTEMIS: Neutralizing BGP Hijacking within a Minute»
  • Эксплуатационное объяснение ARTEMIS на RIPE Labs
  • Демонстрационная статья ARTEMIS на ACM SIGCOMM 2016
  • Релизы ARTEMIS
  • Годовой отчёт CAIDA за 2019 год
  • Поток сообщений BGP RIPE RIS Live
  • RouteViews Университета Орегона
  • CAIDA BGPStream
  • Репозиторий ExaBGP
  • Route Origin Validation, RFC 6811
  • Получатели RIPE Community Projects Fund 2019
  • Code BGP
  • Экспериментальное внедрение ARTEMIS у CAIDA
  • Живая демонстрация ARTEMIS
  • BGP Monitoring Protocol, RFC 7854
  • RIPE Atlas