Skip to content
Published on

ROVが防いだこと、ASPAがまだ防げないこと — 2026年6月テレグラム・ハイジャックとルーティングセキュリティの次の層

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
シェア
Authors

はじめに — 国内向けの遮断が国境を越えた日

2026年6月16日、インド政府はテレグラムの遮断を命じました。NEET医大入試の再試験を控え、組織的なカンニング用チャンネルが問題視され、IT法69A条に基づき6月22日までに遮断せよという命令が下されました。ここまではルーティングの話ではありません。

問題はその遮断のやり方でした。インドの通信事業者Rcom(AS18101、Reliance Communicationsであり、Reliance Jioではありません)は、テレグラムのIPレンジをBGPで直接広告してトラフィックを引き込み、ブラックホールに捨てる方法を選びました。Kentik社のDoug Madoryが当時のBGPデータを分析した記事によれば、07:17 UTCからAS18101がテレグラムの使う複数のIPブロックをoriginateし始め、その経路がインド国外へ漏れ出しました。

これは非常に見覚えのある失敗パターンです。Madoryの表現では 意図的であると同時に事故でもある 部類 — 国内向けの遮断が国境の内側にとどまらず、グローバルなルーティングテーブルへ流出してしまうパターンで、2008年のパキスタン・テレコムによるYouTubeハイジャックがその原型です。2021年のミャンマー・クーデター時のTwitter、2022年のロシア、ブラジルによるXの遮断(AS263276)、2023年8月のイラクによるテレグラム遮断も、すべて同じ形をしていました。

ところが今回は、一つの数字が残りました。Kentikの計測によれば、テレグラム(AS62041)が通常originateしている91.108.4.0/22のハイジャック経路を 見た自社BGPソースはKentik自社ソースのうちわずか1.6%だけ でした。Madoryはその理由をこう書いています — テレグラムが自社の全経路にROAを設定していたため、各ネットワークがRPKI-invalidな経路を破棄できた 可能性が高い (likely owing to)。

この数値はKentik自社のBGPソースを基準にしたベンダー自身の計測であり、Madory本人が因果関係を断定せず「likely」と書いている点はそのまま伝えておきます。それでも方向性ははっきりしています。RPKI ROVは2026年において実際に機能する防御です。

本稿はこの事件を出発点に、ROVが実際に何を防ぎ、どこで天井にぶつかるのか、そしてその天井の先を狙うASPAが2026年7月時点でどこまで来ているのかを見ていきます。BGP・AS・ピアリング・RPKIの基礎はBGPインターネットルーティング完全ガイドですでに扱ったので、ここでは2026年に新たに起きたことだけを扱います。

ROVが実際に防いだこと、そしてその天井

ROV(Route Origin Validation、RFC 6811)がやることはただ一つです。「このプレフィックスをこのASがoriginateする権限があるか」を、ROA(RFC 9582)に署名された内容と照合すること。AS18101がテレグラムのプレフィックスを自分の名前でoriginateした瞬間にoriginがずれるため、ROVを有効にしたルーターはその経路をinvalidと判定して破棄します。だからこそ伝播は1.6%で止まりました。

何が実際に失敗したのかも公開されています。インドのネットワーク研究者Anurag Bhatiaは事件翌日に書いた分析で、Rcomのミス以外に実際に失敗したのは アップストリームがRPKI ROVを行っていなかったこと だと指摘し、具体的にFLAG(AS15412)とTata Communications(AS4755)を名指ししました。プレフィックスには署名がされていたのだから、ROVが展開されていればこれらの経路は容易にフィルタされ、AS18101とその下流の中に閉じ込められていたはずだ、というのが彼の主張です。

Bhatiaは、91.105.192.0/23が16:14:19 GMT(21:44:19 IST)にAS18101からoriginateされ始めたことを、ロンドンのRIPE RIS RRC01を含む複数のコレクターで確認したと書いています。これはMadoryのタイムラインとも符合します — テレグラムがIP空間を取り戻そうとmore-specificな経路を打ったところ、AS18101が16:14 UTCからそのmore-specificまで追随してハイジャックした、という部分です。互いに独立した二つの分析が同じ時刻を指しています。

しかし、Bhatiaの記事で本当に重要な一文は別にあります。彼はこれが故意ではなく「fat finger mistake」だと見ており(これは彼個人の判断です)、その根拠としてこう書いています。

本当に意図的だったなら、origin ASNはそのままにして、テレグラムのAS211157をAS18101の後ろに偽装して付け加えていたはずだ。そうしていれば、transit-freeなtier-1階層や各種バックボーン・IXPをまたぐRPKI ROVフィルタリングは、そもそも一切発動しなかっただろう。

この一文が、ROVの天井を正確に描き出しています。ROVはAS_PATHの末端(origin)しか見ません。攻撃者がorigin の位置に被害者のASNをそのまま残し、自分をその手前に差し込めば、ROA照合は通ってしまいます。経路が完全に偽物であっても、ROVは何も言いません。今回の事件でROVが勝ったのは、攻撃が拙劣でoriginを差し替えてしまったからにすぎません。

ルートリーク — originが正当な攻撃

forged-originのハイジャックよりもはるかにありふれているのがルートリークです。RFC 7908が定義・分類したこの現象は、要約すると 経路が受け取ってはいけない方向へ再伝播されること です。顧客が供給者Aから学んだ経路を別の供給者Bへ流してしまうと、Bはその顧客経由でAへ向かう経路を学んでしまいます。あってはならない経路ですが、originは完全に正当です。

ここが要点です。 ルートリークにおいてoriginは本物です。 プレフィックスは正しく署名されており、originateしたASもROAと一致しています。ROVはこの経路をvalidと判定します。判定が間違っているのではなく、ROVが答えるように設計された問いではないのです。BGPはその経路を受け入れ、トラフィックはその経路をたどり、ルーティングテーブルを見ている運用者には何のシグナルも上がりません。

部分的な防御はすでに存在します。RFC 9234が定義するOTC(Only to Customer)属性は、BGPセッションにroleを付与し「この経路は顧客向けのみ」という印を載せることで、 偶発的な ルートリークを検知・緩和します。しかしOTCは、リークを生むAS自身がルールを守って初めて機能します。悪意のある側が起点であれば何の役にも立たず、それはまさにASPAのスペック自身が冒頭で認めている点です — RFC 9234は偶発的なルートリークを扱い、ROVは偶発的な誤origin化を扱う、と。

ASPAはどう動くか — up-rampとdown-ramp

ASPA(Autonomous System Provider Authorization)の発想はシンプルです。ROAが「このプレフィックスはこのASがoriginateする」に署名するように、ASPAは 「自分の供給者はこれらだけだ」と署名する ものです。オブジェクト自体は最小限で、プロファイルのドラフトのASN.1を見ると、中身はcustomerASID一つとprovider ASのリストだけです。

ASProviderAttestation ::= SEQUENCE {
  version       [0] INTEGER DEFAULT 0,
  customerASID      CAS,
  providers         ProviderASSet }

CAS ::= INTEGER (1..4294967295)
ProviderASSet ::= SEQUENCE (SIZE(1..MAX)) OF PAS
PAS ::= INTEGER (0..4294967295)

検証はvalley-free原則をAS_PATHに適用することです。検証ドラフトは、AS_PATHから連続する重複ASNを取り除いたCOMPRESSED_AS_PATHを置き、正常な経路であればoriginから上がるup-rampと受信側へ下るdown-rampの二区間だけで構成されるべきだと考えます。各ホップはcustomer-to-provider関係でなければなりません。スペックの文をそのまま移せばこうです — up-rampとdown-rampの長さの合計がN以上であればAS_PATHはvalid(ルートリークなし)であり、合計がNより小さければ経路がリークしたか、AS_PATHが不正であるということです。

                 AS(L) ............. AS(K)
                 /                      \
                .                        .
  (down-ramp)  .                          .  (up-ramp)
              .                            .
             /                              \
          AS(N)                             AS(1)
           /                              (Origin AS)
  受信・検証AS (AS(N+1))

  各rampは下から上へ連続するcustomer-to-providerのホップ

先ほど見たAPNICの例(ASPA at APNIC)がこれを具体的に示しています。AS2がAS1とAS3双方の顧客であり、AS1が「自分の供給者はAS5だけ」というASPAを発行しているとします。AS2がAS1から学んだ経路を誤ってAS3に流すと、AS3はAS1のASPAを参照し、AS2がAS1の供給者として登録されていないことを発見します。経路はASPA-invalidとなり、拒否できます。

ここで重要な性質が一つあります — この検証は 経路上のすべてのASが検証を行う必要はありません。 APNICの二つ目の例のように、途中のAS3が検証をせずリークを素通りさせても、その先のAS4が自ら検証すれば「供給者→顧客→再び供給者」と動いた経路であることを発見して捕まえられます。

2026年7月10日、ASPAスタックがラストコールに入った

ここまでが設計で、2026年のニュースはこうです。 2026年7月10日、ASPA関連のドラフト3件が同時にIETFワーキンググループ・ラストコール(WGLC)に入りました。 IETFデータトラッカーの文書イベントを直接照会すると、3件すべてが同じ日の13:20〜13:21に「IETF WG state changed to In WG Last Call from WG Document」に変わったことが確認できます。

ドラフトリビジョン状態
draft-ietf-sidrops-aspa-profile27 (2026-06-19)In WG Last Call (2026-07-10)
draft-ietf-sidrops-aspa-verification26 (2026-07-06)In WG Last Call (2026-07-10)
draft-ietf-sidrops-8210bis (RTR v2)26 (2026-07-09)In WG Last Call (2026-07-10)

3番目が特に重要です。RTR(RPKI-to-Router)プロトコルは、検証器がルーターへRPKIデータを渡す通路であり、ASPAペイロードを運ぶにはRTRバージョン2が必要です。つまりASPAは、オブジェクトのプロファイル・検証手順・伝達プロトコルという3つの層すべてが揃って初めて回るということであり、その3層が同じ日にラストコールへ入ったわけです。

昨年末時点の予測と照らし合わせると、進捗の度合いが見えてきます。Job Snijdersは2026年2月に書いたRPKI 2025年の振り返りで、「ワーキンググループ・ラストコールは近い! 運が良ければ2026年末までにスペックが発行されるかもしれない」と書いていました。ラストコールはそこから5か月後に実際に始まりました。

ただし まだRFCではありません。 データトラッカー上では3文書ともrfcフィールドが空欄で、IESGの状態は「I-D Exists」— IESGが処理を始めてすらいない段階です。ラストコールはワーキンググループ内部の手続きにすぎず、その後にIESGレビューとRFCエディターのキューが控えています。初期レビューはすでに入り始めています — 2026年7月15日にはARTARTレビューが「Ready with Nits」、BGPDIRレビューが「Almost Ready」で閉じました。

そしてRIR側では、発行機能はすでに開かれています。RIPE NCCは2025年12月15日にRPKIダッシュボードへASPAを追加し、ARINは2026年1月20日のリリースノートで「ARIN's implementation of Autonomous System Provider Authorizations (ASPA) is now fully available in ARIN Online」と告知しました。APNICは2026年7月9日にMyAPNICとRegistry APIの対応を発表し、2025年11月以降RIPE NCC・ARIN・APNICが対応を展開しており、 2026年末までに5つのRIR全てがASPAに対応する見通し だと記しています。

で、今日どれだけ普及しているのか — 自分で数えてみた

スペックがラストコールに入り、RIR3か所が発行ボタンを開いたなら、実際の展開はどこまで進んでいるのか。宣伝文句より、数えるほうが確実です。

2026年7月16日時点で、独立した2つのソースを見ました。一つ目は、Job Snijdersが運営するrpki-clientコンソールのASPAダンプを取得して直接パースしたもの(ページ生成時刻 Thu Jul 16 13:14:42 2026)。二つ目は、Hurricane ElectricのRPKI & ASPAレポートを同じ日に取得したものです。

両ソースはほぼ正確に一致します。

項目値出典
ASPAオブジェクト数2,391HE.net
ASPAオブジェクト数2,394rpki-clientコンソール(自分で計数)
ASPAを発行しているルーティングテーブル内のASN2,122HE.net
ルーティングテーブル内の全ASN87,781HE.net
ルーティングテーブル内の全ASN87,595RIPE RIS (2026-07-15)
ASPAカバレッジ2.42 パーセントHE.net
参考: プレフィックスのRPKI(ROA)カバレッジ67.36 パーセントHE.net

独立した2つのツールが、オブジェクト数で3件、ASN総数で200程度の差に収束しています。HE.net内部の算数も合っています — RIR別のASPA保有ASNを足すと(RIPE 1,473 + ARIN 442 + LACNIC 107 + APNIC 100 + AFRINIC 0)ちょうど2,122になり、2,122を87,781で割ると2.42パーセントです。

要点は最後の2行の対比です。 ROAはプレフィックスの67パーセントを覆い、ASPAはASNの2パーセント台しか覆っていません。 桁が違います。

RIR別に分けると、展開の順番がそのまま見えてきます。

RIRASPA保有ASN全ASNカバレッジ
RIPE NCC1,47331,7384.64 パーセント
ARIN44220,4622.16 パーセント
LACNIC10712,6230.85 パーセント
APNIC10020,3070.49 パーセント
AFRINIC02,1240

RIPEが最初に開放したので最も高く、次いでARIN、APNICは今月ようやく開放したので0.49パーセント、AFRINICはまだ未対応のため正確に0です。興味深いのはLACNICの107で、APNICの記事の記述によればLACNICはまだ対応を展開していません。自分がパースした発行ポイント(publication point)を見ると、これらのオブジェクトはrpki-repo.registro.brから出てきています — ブラジルのNIC.brが自前のCAを運営しているためです。RIRのホスティングサービスを待たずに、委任RPKI(delegated RPKI)で直接発行できるということであり、実際に自分が数えた32の異なる発行ホストのかなりの部分は、Krillを動かす個別組織でした。

増加ペースは本物です。Job Snijdersの振り返り記事にある「Uniq ASPA Customer ASIDs」ゲージを見ると、2024年末の 87 個から2025年末には 556 個へ増えています(+539パーセント)。今日自分が数えたユニークなcustomer ASは2,393個です。1年半で87 → 556 → 2,393というわけです。

同時に、よく引用される数値はすでに古びています。「約0.5パーセント」というJobの一文は2026年2月時点のものであり、2026年6月末のRIPE Labsの記事も依然として「well under 1% of the global ASN space」と書いています。今日、2つのソースで測ると2.42パーセントです。方向性は良いものの、97.6パーセントのASNには依然としてASPAがないという事実は変わりません。

オブジェクト自体の形もいくつか見えてきます。自分がパースした2,394個のオブジェクトには、供給者エントリが合計7,941個、オブジェクトあたり平均3.32個、中央値2個でした。ちょうど1個だけを記載したオブジェクトが718個(全体の30パーセント)で最も多く、最大は204個を列挙したAS14789でした。供給者がないと宣言するAS0のASPAは59個ありました。そして検証ドラフトは「ASは単一のASPAオブジェクトを登録すべきである(SHOULD)」と推奨していますが、2,394個のオブジェクトのうちこれに違反したASはたった1つ(AS61574)で、しかもそれは大学の研究用テストベッドでした。この推奨は事実上守られています。

Unknownは実質Validである — 部分展開の算数

では、2.42パーセントのカバレッジでASPAはどれだけ仕事をするのでしょうか。スペックを読めば答えが出ます。そして、この部分が本稿でもっとも重要なところです。

ASPAの検証結果は3つの値を取ります — Valid、Unknown、Invalid。この3つをどう分けるかが決定的です。検証ドラフト5.2節のprovider authorization関数は、(AS x, AS y)というペアに対して3種類の値を返します。AS xのASPAが存在しないか無効であれば 「No Attestation」 、ASPAが存在しAS yがリストに含まれていれば 「Provider+」 、存在するがリストに含まれていなければ 「Not Provider+」 です。

そして5.3節が、ramp長の上限と下限をこう定義します。

  • max_up_ramp: 「Not Provider+」 が最初に現れる地点まで。つまりASPAがないホップは 楽観的に rampに含めます。
  • min_up_ramp: 「No Attestation」 または 「Not Provider+」 が最初に現れる地点まで。つまりASPAがなければそこで打ち切ります(悲観的)。

判定は次のように分かれます。

max_up_ramp + max_down_ramp < N   ->  Invalid
min_up_ramp + min_down_ramp < N   ->  Unknown   (情報不足)
それ以外                          ->  Valid

ここから導かれる結論があります。 Invalidになるには、誰かがASPAを発行しており、そのASPAが問題のホップを明示的に否定していなければなりません。 ASPAが単に存在しなければそれは「No Attestation」であり、max計算には引っかからないためInvalidにはなりえません。結果はUnknownです。

そして5.6節の推奨される緩和ポリシーはこうです — Invalidであれば経路選択から除外する(ただし再評価のためAdj-RIB-Inには保持する)。しかし Unknownと評価された経路はValidと同じ選好レベルで扱うべきである(SHOULD) とされています。

この二つを合わせると、今日の現実が見えてきます。カバレッジが2.42パーセントということは、任意のAS_PATH上でリークが起きたまさにそのホップのASがASPAを発行している確率は低い、ということです。すると判定はUnknownになり、Unknownはvalidと同様に扱われ、何も起きません。RIPE Labsに掲載されたASPA Is Live. Can You See It Working?で著者が実際のRPKIデータでラボを回した結果も同じです — ほとんどの経路がUnknownと表示されるのは、経路が怪しいからではなく、ほとんどの運用者がまだASPAオブジェクトを登録していないからだ、というものです。

これはバグではなく設計です。部分展開において誤検知(false positive)で正常な経路を殺さないためには、これくらい保守的でなければなりません。ROVも同じ道を歩みました。その代わり、代償ははっきりしています — ASPAを有効にすることは、今この瞬間はほとんど何も防いでくれません。 利得はカバレッジが積み上がったあとにやって来ます。

スペック自身が認める限界

ASPAをルートリークの万能薬として売り込む記事は多いものの、スペック自身は自分の限界をかなり正直に書いています。読む価値があります。

供給者が顧客をハイジャックするケースは捕まえられません。 7.3節はこう述べています — 供給者は、forged-origin/forged-segmentなAS_PATHで直接・間接の顧客のプレフィックスをハイジャックでき、顧客宛ての経路のAS_PATHを操作することもでき、 こうした攻撃はASPAでは検知されない可能性がある 。スペックの防御論理は技術的ではなく契約的です — 理論上は可能だが現実的なシナリオには見えず、通常は顧客と供給者の間に署名済みの契約があるため、このようなポリシー違反は法的な結果を招くか、顧客が単に関係を打ち切って該当のASPAレコードを削除すればよい、というものです。説得力があるかどうかは各自の判断ですが、脅威モデルの一部が契約に委ねられている点は知っておいて使うべきです。

AS_PATH prependの操作は捕まえられません。 7.4節 — ASPA検証手順は、AS_PATH内でのAS番号の繰り返しの除去や追加を検知できません。ただしスペックは、この攻撃自体はルートリーク検知能力には影響しないと付け加えています。

自分が始めるリークは防げません。 8.4節が明示しています — ASPAベースの検証は、AS_PATH内でそれより手前に登場したASが作ったルートリークを検知・緩和しますが、 ローカルAS自身が自分の隣接ASへリークを開始することは防げません。 また、経路上に複雑な関係があるとリーク検知に失敗することもあります。そのためスペックは、OTC属性(RFC 9234)がその空白を埋めるとし、ASPA検証を補完するためOTC手順の実装を推奨(RECOMMENDED)しています。 ASPAはOTCの代替物ではなく、対になるものです。

ASPAを間違えると、損害は両方向に及びます。 7.2節 — 供給者を書き漏らすとリーク検知能力が下がり、供給者を誤って書き込むと後で正常な経路がASPA Invalidになりかねません。そのため4節は、DDoS緩和ベンダーのような待機用(standby)の供給者や、非常時専用の供給者を あらかじめ 登録しておくよう推奨しています。ASPAの伝播と経路の伝播の間の競合状態を避けるためです。運用上、これがいちばん痛いところです — 非常時にトラフィックを迂回させようとするまさにその瞬間、登録し忘れた供給者経由の経路がInvalidとして死にます。

IPv4/IPv6の非対称性は、寛容な側へ丸められます。 7.1節 — 供給者集合はIPv4とIPv6をまとめて一つで管理するため、片方のアドレス体系にしか存在しない顧客-供給者関係が、もう片方でも許可されているように見えてしまいます。スペックはこれを、登録・検証が単純になり誤検知が出ないという理由で「合理的な妥協」と呼んでいます。

実装はすでに3年前からある

展開が進まない理由は、コードがないからではありません。

  • OpenBGPD は、検証ドラフトの実装状況の節によれば7.8以降でASPAをサポートしています。GitHubのopenbgpd-portableのタグを確認すると、7.8は 2023年2月3日 に出ています。3年5か月前です。
  • BIRD は自身のNEWSファイルによれば 2.16(2024-12-04) で「ASPA support in filters, Static and RPKI」を追加し、その後2.16.1でパーサーのバグ修正、2.18(2025-12-26)でAS_SET処理、2.19.0(2026-05-25)でdownstream検証を修正しています。活発にメンテナンスされているということです。
  • Routinator (NLnet Labs)は0.13.0でASPAとRTRバージョン2のサポートを追加し、0.14.1(2025-01-22)以降は常にコンパイルに含まれています。ただし今なお--enable-aspaオプションで 明示的に有効化する必要があります — 公式ドキュメントではASPAはいまだ「Advanced Features」の項目であり、「現在IETFの2つのInternet-Draftに記述されている」という注記が付いています。
  • 商用ベンダー はまだです。検証ドラフトが記録しているのは2025年のCiscoによるIOS-XRベースの Early Field Trial 実装で、他にRTRlib、NIST-BGP-SRx(IXP/RS拡張は未対応)、FreeRTRが挙がっています。APNICは「複数の商用ベンダーがサポートをリリース済みか開発中」と書いていますが、どのベンダーかは明かしていません。

一つ付け加えると、ドラフトの実装状況の節はすでに古びています。BIRDの項目は依然として「side branch(mq-aspa)にあり、リリースはRTR v2の確定後を見込む」と書かれていますが、BIRDのNEWSは2.16からリリースに入っていると述べています。これはドラフトを責めるべき話ではありません — その節自体が「ここに記載された情報を独立に検証する労力は一切払っていない」「貢献者から提出された内容である」と明記しており、RFCとして発行される前に削除される節であるとも記しています。ただし、この節をベンダー対応状況の一覧表として読んではいけない、ということでもあります。

まとめるとこうです。 オープンソースのルーターでASPA検証コードは3年前から存在し、カバレッジは2.42パーセントです。 ボトルネックはコードではなく、オブジェクトそのものと、それを実際に強制する決意です。

では今、何をすべきか

今すぐやる価値があること: ASPAオブジェクトを発行すること。 これは非対称に安い行動です。自分がASPAを発行して得をするのは自分ではなく、自分の経路を検証する他者です(そして自分のプレフィックスがリークしたときにそれを捕まえるのも、他者の検証器です)。自分のルーターで何かを有効化する必要もなく、自分のトラフィックへの影響もありません。RIPE NCC・ARIN・APNICの会員であれば、ダッシュボードから発行できます。この3つの会員でなくても、上記のregistro.brの事例が示すように、委任RPKIで発行することができます。注意点は上記の通りです — 待機用・非常用の供給者を書き漏らさないこと、ASあたりオブジェクトは1つに保つこと、そして供給者関係が変わったら更新する運用ルーチンを作ることです。更新を忘れたASPAは、後で自分の経路を殺します。

まだ急ぐ必要のないこと: ASPA Invalidを拒否するよう有効化すること。 カバレッジが2.42パーセントの今、有効化して得られる防御はほとんどなく、誤って登録されたASPAのせいで正常な経路を殺してしまうリスクは現実に存在します。しかもスペックはまだRFCではなく、ラストコールのレビューでは「Almost Ready」判定が出たばかりです。RTR v2も同じキューに並んでいます。ロギングモードで観察しながら(6.6節がロギングを別途扱っています)カバレッジが上がっていくのを見るのが、今の段階には合っています。

依然として優先度が高いこと: ROV。 その根拠は本稿の出発点そのものです。テレグラム事件で実際に被害を生んだのはROVを行っていなかったアップストリームであり、被害を防いだのはROVを行っていた残りの側です。ROAカバレッジは67パーセント、ASPAは2パーセント台です。ROVをまだ強制していないなら、ASPAを検討する前にまずそちらをやるべきです。 そしてRFC 9234のOTCも一緒に見てください — ASPAのスペック自身がOTCを補完策として推奨しており、OTCはすでにRFCであり、自分が他者へリークを開始することを防いでくれる唯一の層です。

ASPAはあなたの問題ではないかもしれません。 アップストリームが1つだけのスタブASであれば、発行は数分で終わり(供給者1つだけのASPA — 今日、全体の30パーセントがこの形です)、検証を自ら回す理由はあまりありません。検証が価値を発揮するのは、複数のピアと複数のトランジットから経路を受け取るネットワークです。

おわりに

2026年6月のテレグラム事件は、RPKI ROVが実際に機能しているという証拠です。Kentikの計測では、ハイジャック経路は自社ソースのわずか1.6パーセントにしか届かず、MadoryもBhatiaも共に、その理由としてテレグラムのROAと上流でのフィルタリングを挙げています。2008年のパキスタン・YouTube事件と比べれば、インターネットは明らかに良くなっています。

同時に、同じ事件が天井を見せてもいます。Bhatiaが指摘した通り、今回ROVが勝ったのは、攻撃がoriginを差し替えてしまう拙劣な方式だったからです。originをそのままにして自分を手前に差し込んでいれば、ROVは沈黙していたはずですし、そもそもルートリークはoriginが正当であるがゆえに、ROVの問い自体に引っかかりません。

ASPAはその空白を狙う次の層であり、2026年はその層が形を成した年です — 7月10日に3つのドラフトがラストコールに入り、RIR3か所が発行を開放し、年末までに5か所全てが開く見通しです。実装はOpenBGPDに3年前から存在しています。

しかし今日数えると2.42パーセントです。そして検証アルゴリズムの構造上、カバレッジが低ければ判定はUnknownになり、UnknownはValidと同じ扱いを受けます。つまり ASPAは、今この瞬間有効にしていても、まだほとんど何も防いでいません。 これは失敗ではなく、この種の技術が展開されるときのやり方そのものです — ROAも87個から始まり、今ではプレフィックスの67パーセントを覆っています。

だから結論はありきたりですが、はっきりしています。発行は今すぐ、強制はまだせず、ROVとOTCを先に整えてください。そして何らかの数字を引用する前に、その日付時点で自分で数えてみてください — 「well under 1%」という一文が2026年下半期の記事にもなお載り続けている一方で、独立した2つのソースで今日測った値は2.42パーセントでした。

参考資料

Discuss on Twitter • View on GitHub