要約

  • RIPE NCCは、RPKI APIでBGPsecルーター鍵証明書を作成・管理できるようにしたと発表した。
  • 証明書はASNに結び付いた鍵を認可する。ルーターに広告を署名させることも、隣接ルーターに経路を検証させることもできない。

BGPsecには、少し事務的なねじれがあった。規格はルーター鍵証明書の形式を決めているのに、運用者はその発行をいつものRPKI作業に組み込む必要があった。RIPE NCCがRPKI APIに新しい経路を加え、証明書の申請と管理をソフトウェアで扱えるようにした。とはいえ、クリック一つでラックにルーターが出現するわけではない。

10月23日の会員向け更新で、RIPE NCCはAPIによるBGPsecルーター鍵証明書の作成・管理への対応を発表した。前日のRIPE Routing WGメーリングリストでは、同センターのPrincipal Engineer、Tim Bruijnzeelsが、AS番号の保有者はルーター鍵を認可し、BGP UPDATEへの署名に使えると説明している。公開されているAPI文書は、BGPsec APIの稼働先としてRPKIの試験環境 localcert.ripe.net を示し、鍵オブジェクトの作成、証明書と証明書チェーンの取得方法を記載している。確認できるのは証明書を扱うAPI機能だ。一般会員向け本番環境の提供範囲や、利用中の会員数は公開資料にない。

証明書の役割は限定的で、だからこそ重要だ。RFC 8209は、公開鍵を一つ以上のASNに結び付けるRPKIエンドエンティティー証明書を定義する。ルーターは対応する秘密鍵を保持し、BGPsecに対応していれば、外部ピアへBGPsec UPDATEを送る際に経路情報へ署名する。受信側は手元の証明書と署名を使って署名付き経路を検証できる。

これは他のRPKIオブジェクトと役割が違う。ROAはどのASがプレフィックスを起源できるかを示し、ASPAはAS保有者が認めたプロバイダーを記録する。BGPsecはASパスに署名を載せる。Bruijnzeelsは三者を補完関係と説明した。ルーター鍵証明書は経路署名の部品であり、起源検証や経路リーク検出の別名ではない。

RIPE NCCの技術者が示した一番大事な課題は、APIの告知ではない。ハードウェアルーターの対応が遅れており、段階的な導入と性能にも課題があるという一文だ。APIはチェーンの一か所から手作業を減らす。ルーターにBGPsecセッションを交渉させることも、筐体内の秘密鍵を守ることも、隣接ASに署名属性を読ませることも、署名経路がない場合の扱いを決めることもできない。

運用の段階は明快だ。証明書を申請する。秘密鍵を保護して設置する。対応ルーターとセッションでBGPsecを有効にする。署名付きUPDATEを送る。受信側が検証する。それぞれ別の運用責任がある。APIの成功応答が示すのは最初の一段だけだ。一般会員向け本番エンドポイントや、残りの段階を実装したルーターは、公開資料から確認できない。RIPE NCC自身がハードウェア対応の遅れを指摘した。次に必要なのは、その先の実装情報だ。

運用者にとって進展はある。証明書の発行はコントロールプレーンの作業であり、APIなら他のRPKI作業と一緒に自動化しやすい。納得できる実証は、証明書、保護された鍵、特定のルーター、BGPsecセッションの相手、そして検証を通ったUPDATEを結び付けるものだ。今のAPIが容易にしたのは、そのうち一つの設定工程である。経路はまだ自分で署名しない。

出典：RIPE NCC会員向け更新、2026年10月23日；Tim Bruijnzeels、RIPE Routing WG、2026年10月22日；RIPE NCC BGPsec API文書；RFC 8209；RFC 8205；RIPE NCC認証実務声明 RIPE-851。