Кратко

  • RIPE NCC сообщила, что её RPKI API теперь создаёт сертификаты ключей маршрутизаторов BGPsec и управляет ими.
  • Сертификат разрешает использовать ключ, связанный с ASN. Он не заставит маршрутизатор подписывать объявления, а соседа — проверять путь.

У BGPsec была проблема с оттенком канцелярии: стандарт давно описал сертификат ключа маршрутизатора, но оператору ещё предстояло встроить его выдачу в обычную работу с RPKI. RIPE NCC добавила для этого API. Запросить сертификат и управлять им теперь можно программно. Маршрутизатор, увы, всё ещё не появляется в стойке после нажатия кнопки.

В обновлении для членов от 23 октября RIPE NCC объявила, что RPKI API поддерживает создание сертификатов ключей маршрутизаторов BGPsec и управление ими. Днём ранее Тим Брёйнезелс, главный инженер RIPE NCC, написал в списке RIPE Routing WG, что владелец ASN может разрешить маршрутизатору подписывать BGP-обновления. Публичная документация BGPsec API указывает на пилотную среду RPKI localcert.ripe.net и описывает создание объектов ключей, получение сертификата и его цепочки. Это подтверждает наличие функции выдачи через API. Документы не сообщают, сколько участников уже используют её в производстве и открыт ли общий производственный адрес для всех аккаунтов.

У сертификата чёткая задача. RFC 8209 определяет конечный сертификат RPKI, связывающий открытый ключ с одним или несколькими ASN. Маршрутизатор хранит соответствующий закрытый ключ и, если поддерживает BGPsec, подписывает им информацию о пути при отправке BGPsec UPDATE внешнему соседу. Получатель может проверить подписанный путь с помощью доступных сертификатов и подписей.

Это не та же функция, что у остальных объектов RPKI. ROA указывает, какой AS может объявлять префикс; ASPA фиксирует разрешённых владельцем AS провайдеров; BGPsec несёт подписи вдоль AS-пути. Брёйнезелс прямо называет эти механизмы дополняющими друг друга. Сертификат ключа маршрутизатора — часть подписи пути, а не новое название проверки источника маршрута или обнаружения утечек.

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

Рабочая цепочка выглядит просто: запросить сертификат; защитить и установить закрытый ключ; включить BGPsec на совместимых маршрутизаторах и сессиях; отправить подписанные обновления; проверить их на принимающей стороне. За ступени отвечают разные участки эксплуатации. Успешный ответ API подтверждает только первую. В опубликованных материалах пока нет общего производственного адреса для всех членов и списка реализаций маршрутизаторов, прошедших остальные ступени. Сам инженер RIPE NCC указывает на отставание аппаратной поддержки. Следующее полезное сообщение должно описать именно эту часть.

Для оператора это практический шаг вперёд. Выдача сертификата относится к плоскости управления, а API позволяет автоматизировать её рядом с другими задачами RPKI. Убедительный тест свяжет сертификат с конкретным маршрутизатором, защищённым ключом, соседом на BGPsec-сессии и UPDATE, чьи подписи прошли проверку. Пока API упростил одну часть настройки. Путь всё ещё не подписывает сам себя.

Источники: обновление RIPE NCC для участников, 23 октября 2026; Тим Брёйнезелс, список RIPE Routing WG, 22 октября 2026; документация BGPsec API RIPE NCC; RFC 8209; RFC 8205; RIPE-851, заявление о практике сертификации.