Кратко

  • Если ограничение затронет больше, чем ресурс из сообщения, пользователи могут потерять доступ к сайту или рабочему сервису, зависящему от этой сети. Проект RIPE 2026-02 признаёт риск для связности, но оставляет сами меры и их пределы отдельному документу.
  • Проект RIPE NCC пока обсуждается и не принят. Он задаёт порог 14 дней за 30 и семь рабочих дней на исправление, но переносит конкретные ограничения в отдельный документ — вместе с вопросом о защите соседних сетей.

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

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

Точно описанный вход в процедуру ещё не делает её законченной, если выход остаётся неясным.

Предложение RIPE NCC 2026-02 опубликовано 13 октября 2026 года и передано рабочей группе RIPE по безопасности. Оно касается устойчивых вредоносных операций на уровне инфраструктуры: систем управления DDoS, системного распространения вредоносного ПО, сетей хостинга фишинга и инфраструктуры автоматизированных спам-ботнетов. Домашние и динамические абонентские пулы исключены; системная инфраструктура отделена от единичного заражённого устройства. Обсуждение открыто до 11 ноября. Это проект, а не действующее правило RIPE. (Предложение 2026-02; текущие предложения)

Для начала процедуры недостаточно жалобы или единственного попадания в список. Пострадавший оператор сети либо национальная команда реагирования могла бы открыть тикет в RIPE NCC. К нему нужно приложить автоматическую телеметрию из утверждённого списка инфраструктуры и временные метки или криптографическую подпись, подтверждающие продолжительность. Предлагаемый триггер — совокупное присутствие IP-адреса в блоке, выделенном или назначенном RIPE NCC, в течение 14 дней внутри скользящего 30-дневного окна. Рабочая группа по безопасности должна ежегодно пересматривать классы угроз и на основе консенсуса вести реестр списков.

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

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

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

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

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

Эта зависимость существенна. Порог не говорит, какую функцию разрешено ограничить, как привязать меру к затронутым ресурсам и как защитить соседних клиентов. «Соразмерность» — это стандарт, но без ограниченного набора мер и правила выбора она не превращается в воспроизводимое решение. Промежуточные меры также нужно отличать от действующих процедур приостановки, удаления ресурсов или прекращения соглашения. RIPE-732 — опубликованное стандартное соглашение об обслуживании; RIPE-858 описывает закрытие LIR и отзыв интернет-ресурсов. Проект не заявляет, что заменяет любой из этих документов. (RIPE-732; RIPE-858)

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

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

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

Институциональный выбор состоит не только в том, должна ли RIPE NCC реагировать на сигналы злоупотребления. Вопрос в том, следует ли превращать сигнал, определённый сообществом, в административные последствия по договору и где провести границы таких последствий. Триггер может быть точным, а мера всё ещё зависеть от усмотрения. Предложение 2026-02 выявило эту асимметрию до принятия; обсуждение ещё может добавить проверяемый перечень мер и столь же проверяемый выход. Материалы о процедуре: процесс разработки политик RIPE (RIPE-781) и официальный архив объявлений о предложениях.