リソース公開鍵基盤

ルート発信元認証（ROA）^{[ 3 ]}は、ルート発信元検証（ROV）に使用される特定のIPプレフィックスを発信する権限を持つ自律システム（AS）を示します。さらに、ASがアドバタイズする権限を持つプレフィックスの最大長を強制することもできます。暗号的に検証されたROAは検証済みROAペイロード（VRP）と呼ばれ、通常はルーティングフィルタリングを実行するためにルータに転送されます。

自律システムプロバイダ認証（ASPA）^{[ 6 ]}は、BGP AS_PATHsにおいて自律システムの直接の上流隣接ネットワークとして表示することを許可するネットワークを規定します。これは、後述するBGPsecと比較して、BGPパス検証のよりシンプルな方法を提供します。

AS オペレーターは、BGP を介して受信した任意の AS_PATH でアップストリームとして表示される可能性のある他の A​​SN を指定するアテステーションを公開します。ASPA 検証には、BGP アナウンスがどこから受信されたかに応じて 2 つのバリアントがあります。^{[ 7 ]}

• 顧客またはラテラルピアからアナウンスを受信しました。ここでは、すべてのAS隣接関係は顧客とプロバイダの関係であると想定されます。指定されたパスで確認された対応するプロバイダASNを含む有効なASPAレコードをすべての顧客ASが公開している場合、アナウンスは有効とみなされます。パスに現れるASのいずれかにASPAレコードがない場合（たとえば、ASPAをまだ展開していない場合）、アナウンスの有効性は不明です。この場合、ルートオリジン検証と同様に、ASPAの段階的な展開をサポートするために、アナウンスは受け入れられるべきです。それ以外の場合、どちらにも該当しない場合は、アナウンスは無効とみなされ、拒否されるべきです。
• アップストリームプロバイダからアナウンスを受信しました。このケースは、AS_PATH に複数のタイプの AS 関係が含まれる可能性があるため、前のケースよりも複雑です。BGP は隣接する 2 つの AS の関係をエンコードしないため、事前情報なしではこれらの関係を判断することは不可能です。そのため、ASPA 検証は、受信した AS_PATH が妥当かどうかを判断するために、認証された情報自体に依存します。検証アルゴリズムは、AS パスの両端から開始し、ASPA データに従って有効な顧客プロバイダ関係である隣接関係の数をカウントします。AS_PATH の最後の発信元 AS から始まる最長の有効なパスはアップランプと呼ばれ、ダウンランプは検証対象の AS から始まります。アップランプとダウンランプが最大 1 つの隣接関係で分離されている場合、AS 階層の最上位で横方向のピアリング接続を示しているため、アナウンスは有効とみなされます (アップランプとダウンランプは重複することもあり、他の AS のいずれかに共通のプロバイダがあることを示しています)。このプロセスにより、BGP パスのバレーフリー特性も満たされます。以前と同様に、いずれかのASにASPAレコードが存在しない場合、発表の有効性は不明であり、どちらにも該当しない場合は、発表は無効となります。

BGP ASパスの先頭への追加は検証プロセスに影響を与えません。なぜなら、AS_PATH内の連続する重複AS番号は、検証プロセスの前に1つに統合されるからです。

ティア1のISPは、単一のエントリを含むASPAレコードを公開しAS0、これらのネットワークにはアップストリームがなく、それとは異なることを示唆するアナウンスは無効であることを示しています。^{[ 8 ]}

Border Gateway Protocol Security (BGPsec) は、 RFC 8205で定義されたBorder Gateway Protocolのセキュリティ拡張であり、2017 年 9 月に公開された追加の RFC 8206 ～ 8209 で定義されています。BGPsec は、BGPsec UPDATE メッセージの受信者が受信した AS パスを暗号的に検証できるようにすることでセキュリティを提供します。^{[ 9 ]} BGPsec は、BGP属性を新しい属性に置き換えます。^{[ 10 ]} AS_PATHBGPsec_Path

BGPsecは、 RFC 8209で定義され、RPKIを通じて公開されるルータ証明書を使用します。検証者はこの証明書を取得し、UPDATEメッセージで受信したBGPsec署名を検証します。署名はルータが自身の秘密鍵を使用して作成し、対応するルータ証明書に含まれる公開鍵を使用して検証できます。 

暗号署名の使用は、BGP アナウンスを送受信する際のルーターのリソースオーバーヘッドを大幅に増加させます。さらに、セキュリティ上の大きなメリットを得るには、BGPsec をルーターの大部分に展開する必要があります。これは、早期展開で即座にセキュリティ上のメリットが得られる ROV や ASPA とは対照的です。これらが、BGPsec がインターネットで実際に使用されていない主な理由であり、その実装がまばらである理由です。^{[ 11 ]} 2026 年 6 月現在、インターネットの RPKI には有効なルーター証明書はゼロ件公開されています。これは、37 万件を超える ROA と数千件の ASPA と比較すると、ASPA がこの時点で完全に標準化されていないにもかかわらずです。

このシステムは、RPKIオブジェクトを公開するために単一のリポジトリ公開ポイントを使用しません。代わりに、RPKIリポジトリシステムは、複数の分散型委任リポジトリ公開ポイントで構成されています。各リポジトリ公開ポイントは、1つ以上のRPKI証明書の公開ポイントに関連付けられています。実際には、これは、認証局を運営する場合、LIRはすべての暗号化資料を自ら公開することも、公開を第三者に委託することもできることを意味します。LIRがRIRが提供するホスト型システムを使用することを選択した場合、原則として公開はRIRリポジトリで行われます。

ROAなどの証明を検証した後、それらをBGPルーティング状態と比較し、ネットワークオペレーターの意思決定プロセスを支援することができます。これは手動で行うこともできますが、検証済みのプレフィックス発信元データは、RPKI to Router Protocol（RFC 6810）を使用してサポートされているルーターに送信することもできます。^{[ 16 ]} Cisco Systemsは、RPKIデータセットを取得してルーター構成で使用するためのネイティブサポートを多くのプラットフォームで提供しています^{。[ 17 ]} Juniperは、バージョン12.2以降を実行するすべてのプラットフォームでサポートを提供しています^。[ 19 ^{] BIRDは、}構成内の「RPKI」プロトコルを介してRPKI-to-Router Protocolをネイティブにサポートしており、これに基づいてROVとASPAを実行できます。Quaggaは、 BGP Secure Routing Extensions（BGP-SRx） ^{[ 20 ]}またはRTRlibに基づく完全にRFCに準拠したRPKI実装^{[ 21 ]}を介してこの機能を取得します。 RTRlib ^{[ 22 ]}は、RTR プロトコルとプレフィックス発信元検証のオープンソース C 実装を提供します。このライブラリは、ルーティング ソフトウェアの開発者だけでなく、ネットワーク オペレーターにも役立ちます。^{[ 23 ]}開発者は、RTRlib を BGP デーモンに統合して、実装を RPKI に拡張できます。ネットワーク オペレーターは、R​​TRlib を使用して監視ツールを開発できます (たとえば、キャッシュの適切な動作を確認したり、パフォーマンスを評価したりするために)。

RFC 6494は、IPv6で使用するためにRPKIを使用する近隣探索プロトコル（ND）のセキュア近隣探索プロトコル（SEND）セキュリティメカニズムの証明書検証方法を更新します。RFC 6494は、RFC 6487 RPKI証明書プロファイルを修正して利用するSEND証明書プロファイルを定義しており、このプロファイルにはRFC 3779 IPアドレス委任拡張機能が1つ含まれている必要があります。