.. title: RPKI と BGP ルート起点の検証
.. スラグ: rpki-bgp-route-origin-validation
.. 日付: 2026-04-07 12:00:00 UTC
.. タグ: rpki、bgp、セキュリティ、ルーティング、ルートハイジャック、roa
.. カテゴリ: 記事
..リンク:
.. 説明: RPKI とルート オリジン検証が BGP をハイジャックやルート リークから保護する方法 — ROA、検証状態、RTR プロトコル、展開統計をカバーします。
.. タイプ: テキスト
<style>
.calc-container { max-width: 860px; margin: 20px auto; padding: 20px; }
.calc-header { margin-bottom: 30px; padding: 25px; background: linear-gradient(135deg, #667eea 0%, #764ba2 100%); border-radius: 12px; box-shadow: 0 4px 6px rgba(0,0,0,0.1); color: white; }
.calc-header h2 { margin-top: 0; color: white; font-size: 28px; margin-bottom: 10px; }
.calc-header p  { margin: 10px 0; opacity: 0.95; font-size: 15px; }
.result-section { background: white; border: 1px solid #e0e0e0; border-radius: 8px; margin-top: 20px; overflow: hidden; box-shadow: 0 2px 4px rgba(0,0,0,0.05); }
.section-content { padding: 20px; background: #fafafa; }
@media (max-width: 768px) { .calc-header h2 { font-size: 22px; } .calc-container { padding: 10px; } }
.article-body { padding: 24px; background: white; line-height: 1.8; font-size: 15px; color: #333; }
.article-body h3 { color: #2d6a2d; border-bottom: 2px solid #4CAF50; padding-bottom: 6px; }
.article-body a { color: #2d6a2d; }
.article-body a:hover { color: #4CAF50; }
.callout { background: #e8f5e9; border-left: 4px solid #4CAF50; padding: 12px 16px; border-radius: 6px; margin: 16px 0; font-size: 14px; }
.callout.warn { background: #fff8e0; border-color: #f0a500; }
pre, .code-block { background: #1e1e2e; color: #cdd6f4; padding: 14px 18px; border-radius: 8px; font-family: 'Courier New', monospace; font-size: 13px; overflow-x: auto; line-height: 1.5; margin: 12px 0; white-space: pre; }
table { width: 100%; border-collapse: collapse; margin: 16px 0; font-size: 14px; }
th { background: #2d6a2d; color: white; padding: 10px 12px; text-align: left; }
td { padding: 8px 12px; border-bottom: 1px solid #e0e0e0; vertical-align: top; }
tr:nth-child(even) td { background: #f5f5f5; }
.state-valid   { color: #276227; font-weight: 600; }
.state-invalid { color: #b91c1c; font-weight: 600; }
.state-unknown { color: #92400e; font-weight: 600; }
</style>
<div class="calc-container">
<div class="calc-header">
<h2>RPKI および BGP ルート起点の検証</h2>
<p>リソース公開キー インフラストラクチャがルート ハイジャックを防ぐ方法 - ROA トラスト チェーン、検証状態、RTR プロトコル、展開の現状をカバーします。</p>
</div>
<div class="result-section">
<div class="section-content article-body">
<h3 id="problem">1. BGP にネイティブオリジン検証がない理由</h3>
<p>BGP は、すべての参加者が信頼される協調的なインターネット向けに設計されました。ルーターは UPDATE メッセージを受け入れ、発信元 AS が実際にそれらの IP プレフィックスをアナウンスする権限を持っているかどうかの暗号検証を行わずにメッセージを伝播します。これは、どの AS も、設定ミスや悪意によって、他人のプレフィックスをアナウンスする可能性があり、そのアナウンスが数分以内に世界中に伝播する可能性があることを意味します。</p>
<p>RPKI の導入を加速した注目すべきインシデント:</p>
<ul>
<li><strong>2008 — パキスタンテレコム:</strong>PTCL は誤って YouTube のアドレス空間のより具体的なプレフィックス (208.65.153.0/24) を発表し、上流プロバイダーがルートを撤回するまでの約 2 時間にわたって YouTube を世界中でブラックホール化しました。</li>
<li><strong>2010 — 中国電信:</strong>China Telecom は、米国の軍、政府、商用ネットワークに属する約 50,000 のプレフィックスを約 18 分間発信しました。偶然か故意かは確認されていない。</li>
<li><strong>2018 — Amazon Route 53 DNS ハイジャック:</strong>攻撃者は BGP を使用して 205.251.196.0/24 (Amazon DNS) をハイジャックし、暗号通貨ウォレットのトラフィックをリダイレクトして資金を盗みました。この攻撃では、eNet の BGP UPDATE (AS10297) が使用されました。</li>
<li><strong>2019 — ヨーロッパのトラフィックはチャイナテレコム経由で再ルーティングされました。</strong>ヨーロッパのモバイル トラフィック (ボーダフォンやスイスのスイスコムを含む) は、BGP ルートの漏洩により、約 2 時間チャイナ テレコム経由で再ルーティングされました。</li>
</ul>
<h3 id="rpki-trust">2. RPKI トラスト階層</h3>
<p>RPKI (<a href="https://www.rfc-editor.org/rfc/rfc6480" target="_blank">RFC6480</a>) IP アドレス空間がどのように委任されるかを反映する X.509 証明書の階層を構築します。</p>
<ol>
<li><strong>イアナ</strong>ルートトラストアンカーを保持します。 5 つの RIR (ARIN、RIPE NCC、APNIC、LACNIC、AFRINIC) にリソース証明書を発行し、それぞれのアドレス空間をカバーします。</li>
<li><strong>RIR</strong>メンバー (ISP、企業) に、メンバーが保持するアドレス空間の証明書を発行します。</li>
<li><strong>メンバー</strong>エンドエンティティ (EE) 証明書を発行し、署名する<em>ルート起点の承認</em>(ROA) - 特定の ASN が特定のプレフィックスを発信することを許可する署名付き証明書。</li>
</ol>
<p>検証者は、この署名付きオブジェクト階層を 5 つの RIR リポジトリ (および委任されたリポジトリ) からダウンロードし、証明書チェーンを検証し、検証済みの ROA ペイロード (VRP) テーブルを構築します。次にルーターは、<em>RTRプロトコル</em> (<a href="https://www.rfc-editor.org/rfc/rfc8210" target="_blank">RFC 8210</a>) このテーブルを取得し、受信する BGP UPDATE に対して発信元の検証を実行します。</p>
<h3 id="roa">3. ルートオリジン認証 (ROA)</h3>
<p>ROA (<a href="https://www.rfc-editor.org/rfc/rfc6482" target="_blank">RFC 6482</a>) は、次の 3 つのフィールドを含む署名付きオブジェクトです。</p>
<ul>
<li><strong>ASN</strong>: 自律システムはプレフィックスを発信する権限を持っています。</li>
<li><strong>プレフィックス</strong>: 認可されている IP プレフィックス (IPv4 または IPv6)。</li>
<li><strong>最大長さ</strong>: ASN がアナウンスすることを許可されている最大プレフィックス長。指定しない場合は、正確なプレフィックスのみが許可されます。たとえば、/20 プレフィックスに対して 24 に設定されている場合、ASN は /20 と /24 の間でより具体的なものをアナウンスすることもあります。</li>
</ul>
<div class="callout warn">
<strong>maxLength は一般的な構成ミス ベクトルです。</strong>ROA で maxLength = 32 (IPv4) または maxLength = 128 (IPv6) を設定すると、ASN はハイジャックに使用される可能性のある /32 ホスト ルートを含む、より具体的なサブネットをアナウンスできるようになります。ベスト プラクティス: maxLength を、実際にアナウンスする最長のプレフィックス (多くの場合、プレフィックスの長さと同じ) に設定します。</div>
<p>1 つの ROA は同じ ASN に対して複数のプレフィックスを承認できますが、1 つの ROA が 1 つのプレフィックスに対して複数の ASN を承認することはできません。セカンダリ ASN (トランジット プロバイダーや CDN など) がプレフィックスを発信できるようにするには、その ASN に対して別の ROA を作成します。</p>
<h3 id="validation-states">4. 検証状態</h3>
<p>ルーターが BGP UPDATE を受信すると、発信元の検証 (<a href="https://www.rfc-editor.org/rfc/rfc6811" target="_blank">RFC 6811</a>) ローカル VRP テーブルに対して:</p>
<table>
<tr><th>州</th><th>状態</th><th>典型的な地域優先の扱い</th></tr>
<tr><td><span class="state-valid">有効</span></td><td>少なくとも 1 つの ROA がプレフィックスをカバーしており (プレフィックス ⊆ ROA プレフィックス AND プレフィックス長 ≤ maxLength)、ROA の ASN が BGP UPDATE の発信元 ASN と一致します。</td><td>+20 または優先 (共通)</td></tr>
<tr><td><span class="state-invalid">無効</span></td><td>少なくとも 1 つの ROA がプレフィックスをカバーしていますが、一致する ASN と maxLength ≥ 発表されたプレフィックス長を持つカバー ROA はありません</td><td>local-pref 0 を設定するか、ドロップします (演算子の選択。RFC 6811 では、許可するがマーキングすることを推奨しています)。</td></tr>
<tr><td><span class="state-unknown">見つかりません</span></td><td>発表されたプレフィックスをカバーする ROA は存在しません</td><td>変更なし (RPKI が存在する前と同様に扱われます)</td></tr>
</table>
<p>重要な洞察:<em>無効</em>～よりも問題の強力な証拠である<em>見つかりません</em>。 NotFound は、単にプレフィックス所有者がまだ ROA を作成していないことを意味します。無効とは、この ASN が次のとおりであるという ROA が存在することを意味します。<em>ない</em>許可済み — 構成ミスまたはハイジャックのいずれかの強い信号。</p>
<h3 id="rtr">5. RTRプロトコル</h3>
<p>ルーターは X.509 証明書チェーン自体を検証しません。これには計算コストがかかり、完全な RPKI キャッシュを保持する必要があります。代わりに、専用の<em>RPKIバリデーター</em>(Routinator、OctoRPKI、Fort、rpki-client) は、完全な RPKI リポジトリをダウンロードして検証し、結果として得られる検証済み ROA ペイロード (VRP) だけを RTR プロトコル経由でルーターにエクスポートします (<a href="https://www.rfc-editor.org/rfc/rfc8210" target="_blank">RFC 8210</a>）。</p>
<p>RTR は、増分同期メカニズムを備えた TCP (IANA によって割り当てられたポート 323、Routinator などのバリデーターは root 権限の要求を回避するためにデフォルトでポート 3323) を使用します。バリデーターはシリアル番号を送信し、ルーターは最後の同期以降の差分のみを要求します。これにより、大規模な VRP テーブルであっても帯域幅が低く抑えられます (現在、世界中で約 400,000+ IPv4 エントリ)。</p>
<h3 id="deployment">6. 導入と統計</h3>
<p>2026 年初頭の時点で、RPKI の導入はかなりの規模に達しています。</p>
<ul>
<li>グローバルにルーティングされる IPv4 プレフィックスの 50% 以上に、ROA をカバーするものが少なくとも 1 つあります (2019 年の最大 10% から増加)。</li>
<li>Tier-1 および Tier-2 ISP の多くは現在、ルート起点の検証を実行し、無効なルートを削除または優先順位を下げています。</li>
<li>MANRS (ルーティング セキュリティのための相互合意規範) は、メンバーシップの前提条件として RPKI ROA の作成を要求し、AS ごとの適合ダッシュボードを公開します。</li>
</ul>
<p>ライブ統計:<a href="https://rpki-monitor.antd.nist.gov/" target="_blank">NIST RPKI モニター</a>, <a href="https://www.rov.rpki.net/" target="_blank">ROV++</a>, <a href="https://stats.labs.apnic.net/rpki" target="_blank">APNIC RPKI 統計</a>.</p>
<h3 id="beyond-rov">7. ROV を超えて: ASPA と BGPsec</h3>
<p>RPKI ルート起点の検証では、<em>発信元ASN</em>プレフィックスをアナウンスする権限を持っています。 AS_PATH は検証されません。攻撃者は、最後に正当な起点 AS を持つ偽の AS_PATH を構築する可能性があります。これに対処する 2 つの IETF 標準があります。</p>
<ul>
<li><strong>BGPsec</strong> (<a href="https://www.rfc-editor.org/rfc/rfc8205" target="_blank">RFC 8205</a>): パス内の各 AS は UPDATE に暗号署名し、解読不可能な管理チェーンを作成します。すべてのトランジット AS が BGPsec をサポートする必要がありますが、これは展開上の大きな障壁となります。 2026 年の時点ではほとんど配備されていません。</li>
<li><strong>アスパ</strong>(自律システムプロバイダーの認可、<a href="https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-profile/" target="_blank">ドラフト-ietf-sidrops-aspa-プロファイル</a>): AS は、承認された上流プロバイダーをリストするオブジェクトに署名します。検証者は、無効なバレーフリー パス (たとえば、顧客がプロバイダであるかのようにルートをアナウンスするなど) を検出できます。 BGPsec よりも導入が簡単で、2025 ～ 2026 年の時点で注目を集めています。</li>
</ul>
<h3 id="references">参考文献</h3>
<ul>
<li><a href="https://www.rfc-editor.org/rfc/rfc6480" target="_blank">RFC6480</a>— 安全なインターネット ルーティングをサポートするインフラストラクチャ (RPKI の概要)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc6482" target="_blank">RFC 6482</a>— ルートオリジン認証 (ROA) のプロファイル</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc6811" target="_blank">RFC 6811</a>— BGP プレフィックス発信元の検証</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8210" target="_blank">RFC 8210</a>— RPKI to Router Protocol、バージョン 1 (RTR)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8416" target="_blank">RFC 8416</a>— RPKI による簡素化されたローカル インターネット番号リソース管理 (SLURM — ローカル オーバーライド)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc9286" target="_blank">RFC 9286</a>— リソース公開キー基盤 (RPKI) のマニフェスト</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8205" target="_blank">RFC 8205</a>— BGPsecプロトコル仕様</li>
<li><a href="https://www.manrs.org/" target="_blank">マンズ</a>— ルーティングのセキュリティに関する相互に合意された規範</li>
<li><a href="https://rpki.cloudflare.com/" target="_blank">Cloudflare RPKI ポータル</a>— ライブ ROA ルックアップ</li>
</ul>
</div>
</div>
</div>