TelegramのインドBGP流出事故に学ぶRPKI経路検証の実装判断

2026年6月16日、インドの通信キャリアRcom（AS18101、旧Reliance Communications）が、BGP（Border Gateway Protocol、経路情報をAS間で交換するインターネットの基幹プロトコル）でTelegramの主要プレフィックスを誤って発信し、経路情報が世界中に漏洩する事故が発生した[1]。国内の裁判所命令に基づきTelegramへの接続をインド国内で遮断する目的だったとみられるが、フィルタリングの不備によって同じ誤発信が国際的なトランジット網に伝播した[1][2]。UAEなど複数の国でTelegramへの接続障害が報告されている[2][3]。

この事故で被害が世界的な断絶に拡大しなかった最大の要因は、Telegram自身がROA（Route Origin Authorization、経路の正当な発信元を宣言する電子証明）を全プレフィックスに設定していたことにある[1]。受信側でROV（Route Origin Validation、受信した経路をROAと照合して正当性を検証する処理）を実施していたネットワークは、Rcomの誤発信をRPKI無効経路として自動的に拒否できた。本記事では、この事故の技術的経緯を整理したうえで、自社のBGP経路広告・受信の両面でRPKI検証をどこまで導入すべきかという運用アーキテクチャの判断材料を示す。

予備知識

• AS（自律システム）: 一つの運用主体が管理するネットワークのまとまり。AS番号で識別され、BGPはAS同士で経路を交換する
• プレフィックス: IPアドレスの範囲を表す表記（例: 91.108.4.0/22）。BGPの経路広告はこの単位で行う
• トランジット: 他のネットワーク宛ての通信を中継してもらう上位接続契約。ここで経路フィルタが甘いと誤発信が世界へ漏れる
• RPKI: 経路情報の正しさを電子証明で担保する枠組み。発信側の宣言がROA、受信側の検証がROV

障害

クラウドアカウント停止という盲点：Railway全面障害に学ぶ隠れ依存

2026年5月19日、PaaS（アプリケーションの実行環境を丸ごと提供するクラウドサービス）大手のRailwayが約8時間の全面障害を起こした。原因はソフトウェアのバグでも攻撃でもない。Google Cloud（GCP）の自動システムが、[…]

何が起きたか：誤発信はどこから漏れたのか

事故の起点は、インド国内向けの遮断措置だった。

インド政府はNTA（National Testing Agency、国家試験機関）の勧告を受け、医学部入試NEETの不正流出対策としてTelegramへのアクセスを国内で遮断する命令を出した[2][3]。この命令に対応する過程で、Rcom（AS18101）がTelegramの主要プレフィックスである91.108.4.0/22の発信元を自ら名乗り、国内トラフィックをブラックホール化しようとしたとみられる[1][2]。

問題は、この経路がRcomの唯一のトランジットプロバイダであるFLAG Telecom（AS15412、旧RCom系）を経由して国際網に漏れ出したことだ[1]。AS15412はRPKI無効と判定できる経路をそのまま転送し、遮断しなかった[1]。国内向けの一時的な措置のつもりが、経路制御のフィルタリング不備によってグローバルな障害に変わった。

障害

Coinbase障害報告で読み解くAWS単一AZ熱障害とMSKサイレント障害

2026年5月7日、米暗号資産取引所のCoinbaseが約8時間にわたり取引停止に陥った。原因はAWS（Amazon Web Services）の米バージニア北部リージョンus-east-1で起きた、1つのアベイラビリティゾーン（AZ、独[…]

なぜ影響は限定的だったのか：1.6%という数字

被害の広がりを実際に抑えたのは、Telegram側のROA設定だった。

Kentik社のDoug Madory氏（Director of Internet Analysis）の分析によると、ハイジャックされた経路を観測したBGPソースは全体のわずか1.6%にとどまった[1]。残る大多数のネットワークは、Telegramが全経路に設定していたROAをもとにROVを実施し、RPKI無効と判定されたRcomの誤発信を自動的に拒否していた[1]。

裏を返せば、AS15412に加えてインドの他のネットワーク（AS9498、AS4755）もROVを適用していれば、事故はインド国内に封じ込められていた可能性が高い[1]。実際に被害が及んだのは、経路の受信側でROVを適用していなかった一部のネットワークに限られる。ネットワーク研究者のAnurag Bhatia氏は、意図的な攻撃ではなく設定ミスとの見方を示している[2]。

障害

交渉最大の障害は「信頼の欠如」――プロスポーツ労使紛争に学ぶ克服法｜MBAファシリテーション＆ネゴシエーション Day6

MBAファシリテーション＆ネゴシエーション講義ノート Day6/全6回（最終回） この記事でわかること 交渉の障害を3つに分類する視点（論理的構造・認知感情・環境） あるプロスポーツリーグのロックアウト――交渉が決裂に至るメカニズム […]

ROV導入の有無で被害範囲はどう変わるか

同じ誤発信でも、受信側の検証体制次第で結果は大きく異なった。

この表が示すのは、発信側のROA設定だけでは被害を防げないという点だ。ROAは「正当な発信元はどのASか」を宣言する証明にすぎず、実際に経路を拒否するのは受信側のROV処理である。今回はTelegramのROA設定と、大多数のネットワークのROV運用が組み合わさって初めて被害が1.6%に抑えられた。

自社インフラでの実装判断

この事故から得られる教訓は、自社のBGP運用設計に具体的な形で落とし込める。

まず、自社が発信する経路について、全プレフィックスにROAを設定しているかを確認する。ROAが未設定のプレフィックスは、今回のRcomのケースのように誤発信や乗っ取りが起きても、受信側での自動的な防御が働かない。次に、受信側のフィルタリングとしてROVを適用しているかを見直す。トランジット契約先やIX（Internet Exchange）でROVがデフォルト有効になっているか、契約前に確認する価値がある。

ROVを自社ルーターで有効化する場合、Router依存のRTR（RPKI-to-Router）プロトコルでキャッシュサーバと接続し、無効経路を拒否またはローカルプリファレンスで低優先度化する設定が一般的だ。ROAの発行はRIR（地域インターネットレジストリ）が提供するホスト型サービスか、自前のCAで運用するかを選ぶ判断になる。既存のトランジット先がROVを実施していない場合、経路制御の設計を見直す優先度は高い。

よくある質問（FAQ）

Q1. ROAとROVの違いは何か。
ROAは経路の正当な発信元ASを宣言する電子証明であり、ROVはその証明をもとに受信した経路の正当性を検証する処理である。ROAだけを設定しても、受信側がROVを実施しなければ効果は発揮されない。

Q2. 今回の事故はTelegram側の設定ミスだったのか。
違う。事故の起点はインド側キャリアRcom（AS18101）の誤発信であり、Telegram側は既にROAを全経路に設定して防御を固めていた側にあたる[1]。

Q3. ROVを導入すれば経路漏洩は完全に防げるのか。
自社と主要な取引先がROVを適用していれば、RPKI無効と判定される誤発信の伝播は大幅に抑えられる。ただし全世界のネットワークがROVを実施しているわけではないため、今回のように一部のネットワークでは被害が残る前提で設計する必要がある。

まとめ

今回の事故は、ROAとROVという二つの仕組みが揃って初めて経路漏洩の被害を局所化できることを示した。Telegramのようにコンシューマー向けサービスを持つ事業者であれば、まず自社発信プレフィックスへのROA設定を優先し、次にトランジット契約先のROV適用状況を確認する順で着手するのが現実的だ。BGP経路制御の設計を「動いているから触らない」対象から外し、RPKI検証の導入予算を今期の見直し項目に加える判断材料として、この事故は具体的な数字を提供している。

出典