Кратко

  • Siddiqui предложил ограничить допустимые ASN-источники в ROA APNIC и, уже как председатель Routing Security SIG, участвовал в публикации результатов опроса о возможных сервисных функциях.
  • По предложению политики доступны публичные версии, консенсус, публикация руководства и статус внедрения. Опрос зафиксировал предпочтения по уведомлениям о ROA и API, но не распоряжался о выпуске продукта и не доказывал повышение безопасности маршрутизации.

Два институциональных пути — две разные записи

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

Публичная история Aftab Siddiqui в APNIC соединяет оба канала. В 2021 году он предложил ограничить номера автономных систем, которые можно указывать как исходную AS в Route Origin Authorization (ROA). В другой роли — председателя Routing Security Special Interest Group (SIG) — он стал соавтором отчета об опросе уведомлений о ROA и API для их управления. Темы близки технически, но проходят по разным институциональным маршрутам.

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

Полномочия SIG — обсуждать, а не выпускать продукт

В отчете о APNIC 49 за 2020 год описаны выборы председателя и обсуждение названия и устава уже существовавшей Routing Security/RPKI SIG. После поддержки сообщества группа стала называться Routing Security SIG, ее устав согласовали, а председателем избрали Siddiqui. Устав определяет SIG как площадку для обсуждения операционных проблем и лучших практик. Он также предусматривает сбор мнений операторов об услугах APNIC, включая RPKI, IRRd и RRDP, и консультативную роль при рассмотрении технических аспектов предложений по политике безопасности маршрутизации.

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

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

Что видно из процентов — и чего в них нет

В публикации APNIC за сентябрь 2022 года, написанной совместно с Siddiqui, Di Ma и Afifa Abbas, сказано, что опрос провели после открытого заседания в октябре 2021 года. На вопрос об уведомлении по электронной почте при создании ROA 52,4% ответили «да», 33,3% предпочли опцию с добровольным включением, 9,5% опасались слишком большого числа сообщений, а 4,8% запросили продолжение дискуссии. Среди сторонников уведомлений 47,6% выбрали бы webhook, 28,6% считали электронную почту достаточной, 23,8% не определились.

На вопрос о поддержке API для управления ROA — через MyAPNIC или самостоятельно размещенное ПО RPKI, например Krill, — опубликованные ответы составили: 66,7% «да», 19% «нет», 14,3% «возможно».

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

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

Поздний запуск API не доказывает причинную связь

В октябре 2024 года APNIC объявила о доступности Registry API. Он позволяет получать данные о делегировании и управлять объектами Whois, обратной DNS, ROA и маршрутами. APNIC сообщила, что API отвечает на запросы участников и позволяет автоматизировать изменения, которые раньше вручную выполнялись в MyAPNIC. В годовом отчете APNIC за 2022 год уже описывался прототип для открытого тестирования; начало промышленной разработки планировалось на 2023 год.

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

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

У предложения политики был другой след

Предложение Siddiqui prop-138 дает полезное сравнение. В нем указывалось, что система управления ROA APNIC разрешала использовать в качестве источника частные, зарезервированные или нераспределенные ASN; автор предложил ограничить такую практику. Во второй версии ограничение распространилось на объекты route и route6. Публичный трекер APNIC указывает даты версий — август и сентябрь 2021 года, консенсус на открытой политической встрече APNIC 52 от 16 сентября в пользу оформления как руководства, публикацию в декабре и текущий статус «Implemented».

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

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

Что можно сказать о Siddiqui по открытым материалам

В биографии кандидата APNIC от 2012 года Siddiqui описан как руководитель сетевых операций в Пакистане, участвовавший во внедрении IPv6, защите инфраструктуры, работе IPv6 Task Force Pakistan и региональных операторских мероприятиях. Страница APNIC 2022 года сохраняет его описание роли председателя SIG и намерения связать операционные проблемы с поддержкой APNIC. Эти датированные записи помещают его между эксплуатацией сетей, обсуждением политик и обратной связью о сервисах. Они не показывают, что он единолично определял направление группы или принимал решения о системах APNIC.

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

Источники