Кратко

  • Предложение 2026-02 обсуждается и пока не является действующей политикой. Порог запуска сочетает подтверждённое уведомление с 14 суммарными днями в одобренном инфраструктурном списке за любой скользящий 30-дневный период.
  • Статья 3.4 допускает первоначальное исправление через исключение префиксов из списка либо подтверждённую административную изоляцию. Для снятия ограничений статья 3.6 предусматривает исключение из списка или удаление «подходящего ROA», если задействована RPKI.
  • ROA показывает, что владелец адресного ресурса разрешил автономной системе анонсировать определённые префиксы. Сам по себе этот объект не доказывает, что прекратилась работа фишинговой, вредоносной, DDoS- или спам-инфраструктуры.

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

Сообщество RIPE начало обсуждать новое предложение о злоупотреблениях сетевой инфраструктурой. Версия 1.0 опубликована 13 октября 2026 года, а официальный календарь отводит на обсуждение время до 11 ноября. На дату подготовки материала в открытых источниках нет сведений о принятии предложения, его реализации или рассмотренном по нему случае. Документ описывает предполагаемые обязанности, а не действующие меры RIPE NCC.

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

Это ограничение сферы действия — важная часть проекта. До введения ограничений предлагается выстроить документируемую цепочку: затронутый оператор сети или национальная группа реагирования на компьютерные инциденты направляет обращение в службу поддержки RIPE NCC; к нему прикладываются проверяемые автоматизированные данные из одобренного инфраструктурного списка, временные метки или криптографические подписи. Статья 3.1 добавляет порог: суммарно 14 дней присутствия в таком списке за любой скользящий период в 30 дней.

Реестр списков должна вести Security Working Group; условия включают объективную автоматизированную телеметрию, исключение жилых и динамических сетей и доступный для публичной проверки архив.

Дальше идут три доказательных этапа. Их нельзя считать взаимозаменяемыми:

Этап Запись или действие в проекте Что это может подтвердить Чего это само по себе не подтверждает
Запуск 14 дней из 30 в одобренном списке и подтверждённое уведомление Что конкретный адрес находился в конкретном списке в течение требуемого периода Что адрес верно сопоставлен владельцу ресурса или какое действие остановило активность
Первичное исправление Удалить указанные префиксы из списков либо подтвердить административную изоляцию Изменение статуса в списке или действие по изоляции в рамках срока на исправление Кто и как проверил изоляцию либо почему запись исчезла
Восстановление Исключение из списка или, если задействована RPKI, удаление «подходящего ROA» Изменение списка или записи об авторизации происхождения маршрута Прекратилась ли заявленная деятельность и почему именно этот ROA является надлежащей мерой

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

ROA отвечает на более узкий вопрос

RFC 9582 определяет назначение Route Origin Authorization: проверяющая сторона может установить, разрешил ли владелец адресного блока автономной системе анонсировать маршруты для перечисленных префиксов. Эта связь важна для безопасности маршрутизации. Но она не описывает службу, работавшую по адресу, созданный трафик, факт компрометации хоста или изоляцию системы оператором после получения сообщения.

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

В проекте остаются без ответа два вопроса. Что именно означает формулировка «если задействована RPKI»? И какой ROA является «подходящим», если владелец управляет несколькими префиксами, источниками маршрутов или авторизациями? Это не терминологические мелочи: от ответа зависит, какое изменение потребуют от оператора и на каком основании RIPE NCC снимет публичный статус несоответствия.

Удаление ROA меняет запись об авторизации. В зависимости от других данных и локальных политик маршрутизации это может повлиять на оценку анонса некоторыми сетями. Источники не подтверждают одинаковый результат во всех случаях. Главное же в том, что ни одно из этих возможных последствий не доказывает прекращение службы, указанной в списке. Система может продолжить работу, маршрут может объявляться иным путём, а владелец может удалить ROA по причинам, не связанным с сообщением. Наличие объекта RPKI не заменяет объяснение конкретного случая.

Политика abuse-c решает другую задачу

RIPE-705 касается контактного слоя: документ предусматривает атрибут abuse-c в соответствующих записях ресурсов, доступный почтовый ящик для сообщений, ежегодную проверку и последующие действия по действующим правилам и процедурам. RIPE NCC описывает такую запись как способ направить сообщения надлежащему владельцу ресурсов.

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

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

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

Квитанция доказательств для каждого уведомления

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

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

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

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

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

Источники