RPKI(Resource Public Key Infrastructure、リソース公開鍵基盤)

1. 概要

RPKI(Resource Public Key Infrastructure)とは、IPアドレスブロック(prefix)や自律システム番号(ASN)といったインターネット番号資源の所有・委任関係をX.509証明書体系で暗号学的に証明し、それを根拠として「どのASがどのprefixを広告する権限を持つか」を検証可能にする公開鍵基盤である。その上でルータがBGP経路の出所を検査する手続きをROV(Route Origin Validation、経路出所検証)と呼び、RPKIはこのROVの信頼根拠を提供する骨格に当たる。

RPKIが登場した背景には、インターネットのドメイン間ルーティングプロトコルであるBGPが本質的に「信頼(trust-by-default)」に依存しているという構造的弱点がある。BGPは各ASが「私はこのprefixを保有し、この経路で到達できる」と互いに知らせると、隣接ASがその言葉を別途検証せずに受け入れて世界中へ伝播する方式で動作する。1980年代末に数百の機関が互いを知る小規模ネットワークであった頃はこの楽観的信頼で十分機能したが、今日7万を超えるASが匿名的に相互接続する環境では、一事業者の誤設定や悪意ある広告一つが経路ハイジャック(prefix hijacking)へと広がり、特定サービス向けトラフィックを丸ごと誤った場所へ吸い込む事故を生む。2008年にパキスタンテレコムがYouTubeのprefixを誤広告し世界中でYouTubeが数時間麻痺した事件、2018年に攻撃者がAmazon Route53のDNS prefixを乗っ取り暗号通貨ウォレットMyEtherWalletの利用者資金を窃取した事件は、この「検証なき伝播」がなぜ危険かを象徴的に示している。

このような脅威に対応するには、ルータが経路広告を受け取る際に「この広告の出所ASが当該prefixの広告権限を実際に持つか」を暗号学的に確認できなければならない。ところが権限の根は結局、番号資源を分配するIANA→RIR(地域インターネットレジストリ)→ISP/機関へと下る委任階層にあるため、この委任関係をそのまま証明書体系へ移し「資源を持つ者だけが署名できる」構造を作ればよい。RPKIはまさにこの発想から出発し、番号資源の割当階層を公開鍵証明書の信頼階層へ写像(mapping)したPKIである。IETF SIDR/SIDROPSワーキンググループがRFC 6480(アーキテクチャ)を中心に標準化し、経路権限を宣言するROA(Route Origin Authorization)プロファイルはRFC 6482で定義された後RFC 9582へ更新され、ルータの出所検証手続きはRFC 6811、ルータ・検証器間の伝達はRFC 8210(RPKI-to-Router)で規定される。

RPKIの必要性は三つの軸で明確になる。第一は出所の真正性確認であり、「口先だけの所有主張」を「署名で証明される権限」へ変える。第二は誤設定・事故の自動遮断であり、悪意のない単純な打鍵ミス型広告(fat-finger)まで濾し取り、ルーティング事故の多くを事前に防ぐ。第三はエコシステム的信頼の回復であり、個別事業者の善意だけに頼っていたルーティングセキュリティを検証可能な共通基盤の上に載せる。ただし後述のとおりRPKIは「出所(origin)」のみを検証するだけで「経路全体(AS-PATH)」を保証しないため、その境界を正確に知ることが技術士の観点で特に重要である。

RPKIを他のセキュリティ技術と区別する本質的特徴は、資源ベースの信頼、階層型委任、そして検証と執行の分離に要約される。身元ではなく番号資源の所有を証明する点で一般のPKIと異なり、信頼がIANA→RIR→事業者という資源委任経路に沿って流れる点で水平的信頼網(web of trust)とも異なり、重い検証はRPが専任しルータは軽い照会のみを行う点でルータの性能制約を回避する。この三つの特徴が、後述する「出所のみ保証する」という限界と「信頼集中」というガバナンス負担を同時に説明する鍵となる。

2. RPKIの信頼構造と構成要素

RPKIを理解する核心は、「番号資源の委任階層を証明書の信頼階層へそのまま移した」という構造的対応である。すなわちある機関が特定prefixを広告する権限を持つという事実は、そのprefixがRIR→上位事業者→当該機関へと署名されて下りてきた証明書経路で証明される。全体系は大きく「権限を宣言する側(資源保有者がROAを発行・掲載)」と「その宣言を消費する側(RPが検証しルータが執行)」に分かれ、両者の間をリポジトリとRPKI-RTRプロトコルが結ぶ。下の全体構造図は、資源証明書階層(上)と、その上でルータが検証材料を供給される経路(下)を併せて示す。

flowchart TB
  subgraph TRUST["RPKI信頼階層(資源証明書)"]
    TA["トラストアンカー: 5つのRIR(APNIC/RIPE/ARIN/LACNIC/AFRINIC)"]
    ISP["ISP・機関CA(委任された資源)"]
    ROA["ROA: (prefix, maxLength, 出所ASN) 電子署名"]
    TA --> ISP
    ISP --> ROA
  end
  subgraph VAL["検証・伝播体系"]
    PUB["RPKIリポジトリ(repository, RRDP/rsync)"]
    RP["RP検証器(Routinator・rpki-client・FORT)"]
    VRP["VRP(検証済みROA一覧)"]
    RTR["RPKI-RTRプロトコル(RFC 8210)"]
    RTR2["BGPルータ(ROV実行)"]
    ROA -.掲載.-> PUB
    PUB --> RP
    RP --> VRP
    VRP --> RTR
    RTR --> RTR2
  end

A. 資源証明書階層とトラストアンカー

RPKI信頼の根は、5つのRIR(APNIC・RIPE NCC・ARIN・LACNIC・AFRINIC)が運用するトラストアンカー(Trust Anchor)である。各RIRは自らがIANAから委任された住所・AS資源全体を包含する最上位証明書を発行し、その下へ資源を割り当てられたISP・NIR(国家レジストリ)・大型機関にRFC 3779拡張(証明書にIP・ASN資源を記載)を含む下位証明書を署名して下ろす。ここで核心は証明書が「身元」ではなく「資源」を証明する点である。一般のウェブPKIの証明書が「この公開鍵はexample.comのもの」と保証するなら、RPKI証明書は「この公開鍵の所有者は192.0.2.0/24とAS64500を使う権限がある」と保証する。ゆえにRPKIを資源PKIと呼ぶ。

この階層型構造のおかげで権限の偽造は難しい。ある機関が特定prefixに対するROAを作るには、そのprefixが自らの証明書の資源一覧に含まれていなければならず、その証明書は再び上位RIRまで署名チェーンで連結されていなければならない。途中で一つでも資源範囲を外れたり署名が切れたりすれば、検証器は経路全体を無効と判定する。ただしこの構造は、後の深化で扱うとおりRIRという少数主体に信頼が集中するガバナンス的負担も同時に抱えている。

証明書階層はまた資源の再委任(sub-allocation)をそのまま表現できる利点がある。例えばRIRが大型通信社へ/16を割り当て、その通信社が再び傘下機関へ/20を再割当すると、証明書も同じ包含関係でもう一段署名されて下りていく。このように「資源が流れる経路」と「信頼が流れる経路」が一致するよう設計したため、RPKIは別途の身元登録機関なしに番号資源の分配体系そのものをセキュリティの根拠として再利用する。逆に上位証明書が満了・取消されればその下の全下位オブジェクトが一斉に無効となるため、証明書の更新周期管理と満了前再発行(roll-over)が運用上きわめて重要な課題となる。

B. ROA(Route Origin Authorization)

ROAは「ある出所ASがあるprefixを広告してよい」という権限宣言を電子署名したオブジェクトである。一つのROAは(出所ASN、一つ以上のprefix、各prefixのmaxLength)の三要素で構成される。例えばある機関が203.0.113.0/24をAS64500で広告するなら、その機関は(AS64500, 203.0.113.0/24, maxLength 24)というROAを発行する。ここでmaxLengthは「このprefixを何ビットまで細かく分割(subnet)して広告することを許すか」を意味する。maxLengthを24にすれば正確に/24のみ有効だが、例えば/22 prefixにmaxLength 24を与えると/22〜/24の全下位prefix広告が有効と認められる。後述のとおり、このmaxLengthを過度に緩く設定することがかえって攻撃面を広げる典型的な誤りである。

ROAの発行方式は運用責任の境界によりホスティング型(hosted)と委任型(delegated)に分かれる。ホスティング型はRIR・NIRが提供するポータルで資源保有者が数クリックでROAを作り、署名鍵とリポジトリ運用はRIRが代わりに引き受ける方式である。参入障壁が低く大多数の中小事業者が選ぶが、代わりに鍵の統制権がRIRにある点を甘受する。委任型は機関が自らCAとリポジトリを運用し署名鍵を自ら統制する方式で、統制力は大きいがその分、証明書更新・リポジトリ可用性・鍵保護を自ら責任を負う。実務では「統制力対運用負担」という典型的なトレードオフの下、組織規模とセキュリティ要求に合わせて両方式を選ぶ。

C. RP(Relying Party)検証器とVRP

ROAはRIR・事業者が運用する分散リポジトリ(repository)に掲載され、これを収集・検証する主体がRP(Relying Party)ソフトウェアである。Routinator(NLnet Labs)・rpki-client(OpenBSD)・FORT・OctoRPKIといった検証器が代表的である。RPはトラストアンカーから出発しリポジトリの全証明書・ROAを取得し署名チェーンと資源包含関係を検証した後、有効なものだけ選り分けてVRP(Validated ROA Payload、検証済みROA一覧)を算出する。VRPは結局「(出所ASN, prefix, maxLength)」タプルの集合であり、ルータが実際の検証に使う材料となる。リポジトリ同期は過去のrsync中心から変更分のみを効率的に受け取るRRDP(RFC 8182、HTTPSベース)へ重心が移り、可用性と拡張性が改善された。

RP運用で見落としやすい点は、RP自身がルーティングセキュリティの単一障害点(SPOF)になりうることである。RPが特定RIRリポジトリへアクセスできなかったり検証過程で止まったりすると、当該範囲のVRPが丸ごと抜け、正常経路が突如NotFound・Invalidへ転じうる。ゆえに大型事業者は地域・実装を異にしたRPを複数構成し、リポジトリアクセス失敗時に過去のVRPを一定時間維持するなどグレースフルデグラデーション(graceful degradation)の方針を置く。またRPは署名が誤っていたり資源範囲を外れたオブジェクトを静かに濾し取るため、運用者はRPログで「なぜ特定のROAがVRPに反映されなかったか」を追跡できなければならない。

D. RPKI-RTRプロトコルとルータ

最後にRPが作ったVRPはRPKI-to-Routerプロトコル(RFC 8210)を通じてBGPルータへ伝達される。ルータは重い暗号演算(署名検証)を直接行わず、すでに検証を終えたRPからVRP集合のみを受け取り軽い照会(lookup)の形でROVを実行する。この役割分離が重要で、数十万個のROAの署名検証をルータが毎回行うのは非現実的なので、演算集約的な検証はRPが専任しルータはその結果のみを消費するよう設計したのである。このように「検証(RP)と執行(ルータ)」を分離したことがRPKI運用アーキテクチャの要諦である。

RPKI-RTRセッションはRP(サーバ)とルータ(クライアント)の間で状態を維持し、最初は全VRPを取得し以後は変更分(delta)のみを増分送信してルータのメモリとセッション負荷を減らす。またセッション自体の完全性・機密性のため、TCP-AOやSSH、TLSといった保護チャネル上で運用するよう勧告されるが、これは「検証結果を運ぶ通路」が改竄されればROV全体が無力化されるからである。運用者は通常、一つのルータが複数のRPキャッシュへ同時接続するよう構成し、一つのRPがダウンしても他のRPのVRPでROVを続けられるよう二重化する。

構成要素	役割	代表実装/標準
トラストアンカー	信頼の根(資源最上位証明書)	5つのRIR
資源証明書	番号資源委任の証明(RFC 3779)	RFC 6487
ROA	出所ASの広告権限宣言(署名)	RFC 6482 → RFC 9582
RP検証器	リポジトリ収集・検証 → VRP生成	Routinator・rpki-client・FORT
RPKI-RTR	VRPをルータへ伝達	RFC 8210
BGPルータ	VRPベースのROV・ポリシー執行	RFC 6811

3. ROV(経路出所検証)の動作手続きと検証状態

ルータが隣接ASからBGP経路広告を受け取ると、広告に含まれる出所AS(AS-PATHの最も右のAS)とprefixをVRP集合と照合し三つの状態のうち一つに判定する。下の詳細フロー図は広告受信からポリシー決定までの過程を示す。

flowchart TD
  A["BGP経路広告受信(prefix + AS-PATH)"] --> B["広告の出所AS・prefixを抽出"]
  B --> C{"VRPにこのprefixを覆う項目があるか?"}
  C -->|"なし"| D["NotFound(Unknown): ROA未登録"]
  C -->|"あり"| E{"出所ASN一致 & prefix長 <= maxLength?"}
  E -->|"はい"| F["Valid: 権限ある広告"]
  E -->|"いいえ"| G["Invalid: 出所不一致または過度な分割"]
  D --> H["ポリシー: 通常受容(遮断時に大量断絶のリスク)"]
  F --> I["ポリシー: 受容 + 優先順位上昇も可"]
  G --> J["ポリシー勧告: drop(廃棄)"]

Valid(有効)は、広告の出所ASとprefixがVRPのいずれかの項目と正確に一致しprefix長もmaxLength以内の場合である。Invalid(無効)は、当該prefixを覆うROAは存在するが出所ASが異なる(権限のないASが広告)か、prefixがmaxLengthを超えて過度に細かく分割された場合で、ハイジャックが疑われる状態である。NotFound(またはUnknown)は、そのprefixに対するROA自体がなく検証の根拠がない状態である。

三つの状態のうち現実で最も多くの比重を占めてきたのは長らくNotFoundであった。世界中のprefixの相当数がまだROAを登録していないためで、まさにこの点が「検証はするが軽々に遮断してはならない」緊張を作る。ルーティングは到達性が生命なので、根拠がないという理由だけでNotFoundを捨てれば健全な目的地への道が断たれる。ゆえにROVの実質的効果は経路全体を白黒に分けることではなく、明白に権限を違反したInvalidのみ外科的に除去することにある。

ここで技術士的に重要な含意は、「Invalidをどう処理するか」がすなわちセキュリティ効果を左右する点である。検証だけしてInvalid経路をそのまま受容すればRPKIは事実上「見物」にすぎない。実際の防御はInvalid経路を廃棄(drop)するポリシーをルータに適用するときに初めて発生する。一方NotFoundはまだROAを作っていない世界の半分以上を占めるため、これを無条件に遮断すれば正常トラフィックが大量に断絶される。ゆえに現実の運用は「Invalidは捨て、NotFoundは受容し、Validは選好する」非対称ポリシーへ収束する。このためROA登録を増やしNotFoundを減らすこと(ROAカバレッジ拡大)と、受け取ったInvalidを実際に捨てること(ROV執行)が異なる二つの課題に分かれ、後の統計が示すとおり両者の間には大きな隔たりがある。

運用現場ではInvalidを直ちに廃棄するよりBGP local-preferenceを下げ後順位に置く段階的移行を経ることもある。突然のdropが誤設定による大規模断絶を招くことを懸念し、まずログ・アラームでInvalidを観察し誤検知の有無を検証し、安定して初めて廃棄ポリシーをオンにするやり方である。このように「検証→観察→後順位→廃棄」の漸進的適用は可用性を守りつつセキュリティを高める典型的な運用パターンである。

4. RPKIの限界と補完技術 — ROV・BGPsec・ASPAの比較

RPKI/ROVの最も根本的な限界は出所(origin)のみを検証するだけで経路全体(AS-PATH)の真正性は保証しないことにある。この差が生じる理由はROAが「誰がこのprefixの出発点になりうるか」のみを宣言するからである。したがって攻撃者が正当な出所ASを経路末尾にそのまま付けて偽造する「偽造出所(forged-origin)ハイジャック」や、経路を受け取ったまま転送せず規則を破って再広告する経路リーク(route leak)はROVをそのまま通過する。すなわちROVは「出発地偽造」は防いでも「中間経路操作」は防げない。実際、過度なmaxLengthで下位prefix広告を広く許しておくと、攻撃者がその範囲内でより長い(more-specific)prefixを正当な出所を付けて広告しトラフィックを引き込む攻撃がValidと判定されうる — maxLengthを必要な値へ絞らねばならない理由である。

偽造出所ハイジャックの危険を具体的な数値で見ればより明確である。正当な保有者が198.51.100.0/22をAS64500で広告しつつROAを(AS64500, 198.51.100.0/22, maxLength 24)と緩く設定したとしよう。攻撃者はこの範囲内のより長いprefixである198.51.100.0/24をAS-PATH末尾に正当なAS64500をそのまま付けて広告できる。ルータはより長いprefix(longest-prefix match)を優先するので攻撃者の/24へトラフィックが集中するが、出所ASがAS64500で長さ24がmaxLength以内なのでROV判定はValidとなる。もしmaxLengthを実際に使う22のみへ絞っていれば長さ24の広告はmaxLength超過で直ちにInvalidとなり防がれたはずである。このようにmaxLength一行の設定が攻撃可能性を分け、これが「maxLengthは必要な最小値へ」という運用原則の根拠である。

この空白を埋める補完技術がBGPsecとASPAである。BGPsec(RFC 8205)はAS-PATHの各ホップ(hop)が次のASへ転送されるたびに経路を署名し経路全体の完全性を暗号学的に保証するが、ホップごとに署名・検証を行わねばならずルータの演算・メモリ負担が大きく全面展開が事実上停滞している。一方ASPA(Autonomous System Provider Authorization)は「このASの上位(provider)は誰か」をRPKIオブジェクトとして宣言させ、経路が顧客・供給者関係の正常な形を外れたか(=経路リーク・一部経路操作)を比較的軽い演算で、かつ部分展開状態でも効果を出すよう設計され、近年最も有望な代替として注目されている。

区分	ROV(RPKI出所検証)	ASPA	BGPsec
検証対象	出所ASのみ	顧客・供給者の経路関係	AS-PATH全体(ホップ別署名)
防ぐ脅威	単純な出所ハイジャック・誤設定	経路リーク・一部経路操作	経路偽造全般
演算負担	低(ルータは照会のみ)	中	高(ホップ別署名・検証)
部分展開効果	あり	あり(相対的に大)	小
成熟度	広く展開中	標準化・初期展開段階	停滞

この比較の実務的含意は明確である。いずれか一つがすべての脅威を防ぐ「銀の弾丸」ではなく、ROVで出所脅威を取り除いた後ASPAで経路リークを補完し、長期的にBGPsecの経路完全性を加える階層的・段階的適用が現実的戦略だということである。

ここで部分展開(partial deployment)効果という概念が戦略選択を分ける。BGPsecは経路上の全ASが署名に参加してこそ意味があり、全世界が同時に移行しなければ保護効果は僅少である — これがBGPsec展開が事実上止まった根本理由である。一方ROVとASPAは一部のASだけ執行してもそのASが受けるハイジャック・リーク経路を直ちに濾し取れるため、「先に導入した者が先に利益を得る」誘因が働く。セキュリティ技術の成否が暗号強度だけでなく展開経済性(deployability)に懸かっていることをRPKIエコシステムは明瞭に示しており、これは技術士が新技術の導入を設計する際に必ず考慮すべき観点である。

5. 深化: 展開状況・実際の事例・国内外の動向

RPKIは「標準は整ったが展開は進行中」の代表的な事例である。2026年半ば時点で世界中のルーティングprefixのうち約2/3(約67%)がROAを保有すると測定され、IPv6(約73%)がIPv4(約66%)よりカバレッジが高い。しかし受け取ったInvalidを実際に廃棄(ROV執行)するASの比重は測定方法により約12〜33%水準とはるかに低い。すなわち「権限を宣言しておいた家(ROA)」は増えたが「戸締まりを実際にする家(ROV drop)」はまだ少数という意味で、このカバレッジ・執行の隔たり(coverage–enforcement gap)が現段階のルーティングセキュリティの核心的課題である。これらの数値は出所・時点・測定方法(APNIC Labs、Hurricane Electricなど)により偏差が大きいので、断定より傾向として読むべきである。

この隔たりがなぜ重要かは単純な算術で明らかになる。たとえ世界中のprefixの100%がROAを登録(カバレッジ100%)しても、トラフィックが通るASがInvalidを廃棄しなければ(ROV執行0%)ハイジャック経路は依然伝播する。逆にROAはまだ少なくとも、核心のトランジットASがROVを執行すれば彼らが濾し取る範囲だけ直ちに保護が発生する。すなわちルーティングセキュリティの体感効果は「ROAを登録した家(被害者側)」と「Invalidを捨てる家(伝播経路側)」の積として現れ、これがカバレッジ・執行の二指標を分離管理すべき理由である。

実際の事例はRPKIの効用と限界を同時に示す。2018年のMyEtherWallet事件はROVがなぜ必要かを、2024年6月にCloudflareの公開DNS(1.1.1.1)がハイジャックと経路リークが重なり世界的にアクセス障害を被った事件はROVだけでは経路リークを防げない限界をそれぞれ露呈した。2025年には攻撃者がRPKIを破る代わりに上位事業者の顧客身元確認手続きの緩い隙を社会工学的に突いてハイジャックASNへトランジットを開かせた事例が報告されたが、これは暗号技術だけでは埋められない運用・プロセスセキュリティの重要性を喚起する。国内でもKISA/KRNICがAPNIC傘下の国家レジストリとして国内資源保有者のためのホスティング型RPKI CAを提供しており、通信事業者のROA登録とROV執行が次第に拡大する趨勢である。このような自律規範の拡散を支える国際イニシアティブがMANRSで、フィルタリング・出発地偽造防止・協調(coordination)・RPKIベースの全域検証という四つの勧告行動を提示する。

動向の面で注目すべき点は、セキュリティの重心が「技術」から「ガバナンス・プロセス」へ拡張されていることである。先の2025年の社会工学事例が示すとおり、RPKIが暗号的に堅牢になるほど攻撃者は暗号を破る代わりに事業者の顧客登録・トランジット開通手続きの隙を狙う。また多くの大型コンテンツ・クラウド事業者(Google・Cloudflare・Netflixなど)が自社prefixにROAを掛け相互接続相手にROV執行を要求することで、RPKIが商業的交渉条件にまで位置付く流れも現れる。標準の面ではROAプロファイルがRFC 9582へ整理されASPAが標準化・初期展開段階へ移ることで、ルーティングセキュリティが単一技術ではなく複数のオブジェクト・手続きの組合せとして成熟していっている。

6. 考慮事項および示唆(技術士の観点)

適用戦略(段階的成熟): RPKI導入は「ROA登録 → RP検証器構築 → Invalid dropポリシー執行 → ASPA等の補完」の段階で設計すべきである。特にROAを作ったからセキュリティが完成するのではなく、Invalidを実際に廃棄するとき効果が発生するので、カバレッジ指標と執行指標を分離して管理(KPI化)することが核心である。
トレードオフ(可用性 vs セキュリティ): Invalidを強く遮断するほどセキュリティは高まるが、ROA・証明書の誤設定やリポジトリ・RP障害で正常経路が誤検知遮断されれば広範なサービス断絶につながりうる。したがってmaxLengthを最小へ絞りつつ、RP多重化・リポジトリ可用性(RRDP)確保・変更前検証など運用安全装置を併せて設計しセキュリティと可用性の均衡を取るべきである。
ガバナンス・信頼集中リスク: 信頼が少数のRIRトラストアンカーへ集中するので、資源回収・紛争・国家的圧力などで上位証明書が変更・取消される際に下位経路が一括無効化されるリスク(いわゆるkill-switch懸念)を制度的に統制せねばならない。これは純粋な技術問題ではなく資源ガバナンス・国際協力の問題として扱うべきである。
展望と連携技術: ルーティングセキュリティは出所検証(ROV)から経路関係検証(ASPA)へ、さらに経路完全性(BGPsec)へ拡張される階層的ロードマップをたどる。中長期的には量子耐性暗号(PQC)への署名アルゴリズム転換、DDoS・経路異常検知との連携、そしてゼロトラストネットワークの観点から「信頼するな、検証せよ」の原則をドメイン間ルーティングまで拡張する方向へ発展すると展望される。
規制・政策との連携: ルーティングセキュリティは個別企業の選択を超え国家基幹通信網の信頼性問題へと格上げされている。米国が通信事業者へルーティングセキュリティ計画の提出を求めるなど規制化の動きが現れ、国内でも重要情報通信基盤保護と通信災害管理の観点からROA登録・ROV執行を点検項目化する流れが予想される。技術士はRPKIを単一の技術課題ではなく調達・契約(相互接続条件)・コンプライアンスまで束ねたルーティングセキュリティガバナンスとして設計できねばならない。

参考資料

IETF, "An Infrastructure to Support Secure Internet Routing" (RFC 6480) — https://www.rfc-editor.org/rfc/rfc6480
IETF, "A Profile for Route Origin Authorizations (ROAs)" (RFC 9582) — https://www.rfc-editor.org/rfc/rfc9582
IETF, "BGP Prefix Origin Validation" (RFC 6811) — https://www.rfc-editor.org/rfc/rfc6811
IETF, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1" (RFC 8210) — https://www.rfc-editor.org/rfc/rfc8210
MANRS, "RPKI ROV Deployment Reaches Major Milestone" — https://manrs.org/2024/05/rpki-rov-deployment-reaches-major-milestone/
APNIC Blog, "RPKI vs social engineering: A case study in route hijacking" — https://blog.apnic.net/2026/03/31/rpki-vs-social-engineering-a-case-study-in-route-hijacking/

一言まとめ: RPKIはIP・AS資源の委任階層を証明書信頼階層へ写像し「権限あるASのみがprefixを広告する」を証明する基盤であり、その上のROVで出所ハイジャック・誤設定を防ぐが経路全体は保証しないため、ASPA・BGPsecとの段階的・階層的適用と「Invalid廃棄」の執行が鍵である。