インターネットをよりロバストに。RPKIはじめます

はじめまして。IIJでバックボーンの設計や運用をしているhoriです。

この秋(2020/11予定)、IIJ/AS2497としてRPKIで広報元検証(Origin Validation)を始めることにしました。

RPKIとはIPアドレスやAS番号の割り振りを電子証明書で検証できるようにする仕組みで、これを利用することで経路(≒IPアドレス)の不正な乗っ取りを防ぐことができます。

この記事ではRPKIが必要とされる背景や仕組み、現状などを説明します。

背景 (インターネットの実情)

言うまでもなくインターネットは今や欠かせない社会基盤であり、それが停止したときの社会的影響は計り知れません。

そのようにたいへん重要なものですから、さぞ厳密に管理、運営されているものと思いきや、中央集権的な管理組織は存在せず、それぞれ異なる運用ポリシーを持った独立・自律したネットワーク(AS:Autonomous System という番号で識別される)がBGP(Border Gateway Protocol)というルーティングプロトコルで相互に接続し合いできた寄り合い所帯のようなものです。
(これ自体悪いことではなく、逆にこのような状況だったからこそ、ここまでインターネットが発展したのだと思っています)

IPアドレスはIANA(Internet Assigned Numbers Authority)機能を頂点とし、地域ごとに委任されたRIR(Regional Internet Registry)、さらに国ごとのNIR(National Internet Registry)により厳密に管理されています。NIRからIPアドレスの割り振りを受けた各ASは自分が利用するIPアドレスの塊(以下、経路)をBGPで他のASに通知(広告)し、それが世界中のASに伝搬することで通信が成り立ちますが、このときに各ASがどのような経路を広告するかは各ASに委ねられています。

当然、NIRから割り振りを受けたIPアドレスのみを広告すべきですが、故意か過失かはわかりませんが誤った経路を広告してしまう場合があります。このとき、受け取る側のASも相手が本来広告すべき経路のみに限定して受け取れば良いのですが、無数にあるASの日々変化する割り振り状況を厳密に把握することは非常に困難です。そのため、現在のインターネットは基本的に相手のASが広告する経路はほぼノーガードで受け入れています。

その結果、どうなるでしょう? 例えば、IIJのホームページ www.iij.ad.jpのIPアドレス 2001:240:bb81::10:1、202.232.2.164 は本来IIJが広告すべきですが、全く関係ないASがこの経路を広告してしまうと本来IIJに届くべき通信が誤ったAS(通信先)に吸い込まれてしまうことになります。これを一般に経路ハイジャックと呼びますが、このようなことは現在のインターネットでは日常的に発生しています。例えば、2008年にはGoogleの動画サービス YoutubeのアドレスをパキスタンのASが吸い込む事件が、2018年にはAmazonのクラウドサービス AWSのDNSサーバアドレスを何者かがハイジャックし仮想通貨サービスの通信を乗っ取り、実際に通貨が盗まれたと言われる事件が起きています。つい先日(9/30頃)にも、オーストラリアの大手ASが誤ったIPアドレスを広告する事故が発生していました。^(※1)

経路ハイジャックの他にも、本来自身のIPアドレスのみ広告すべきところ、他ASから受け取った経路を別の他ASにも広告してしまい、AS aと AS bが直接通信すべきところをAS a->c->bという経路で通信してしまう事故も頻繁に発生しています(これを経路リークと言います)。AS cを経由しても通信が成立すれば良いのですが、想定しない通信が流れることで帯域不足や遅延により通信が不安定になる場合もあります。2017年には日本の大手ISPが巻き込まれ、ニュースにもなるほどの事故も起きました。

このように、現在のインターネットはある意味非常に危うい状態にあると言えます。

RPKIとは?

このような状況を改善すべく、考案されたのがRPKI(Resource Public-Key Infrastructure)です。そのアイデアは1998年頃に生まれたといいますから、考案した人の先見の明には驚くばかりです。

ここでは、RPKIとそれを使ったBGPルーティングについて簡単に説明します。

まずRPKIですが、一言で言えばリソース(IPアドレスやAS番号といったインターネット番号資源)の正当性を電子証明書(X.509)により証明・検証する仕組みです。IPアドレスの割り振りを管理しているのはIANA機能、RIR、NIRですから、これらの運営組織がツリー構造(正確には5つのRIRを頂点とするツリー)になり、リソースが正しいことを電子証明書で担保します。その情報を使う利用者は電子証明書を用いて、リソースが正しいことを認知します。

RPKI自体はBGPルーティングに限定せずリソースの管理に利用できる仕組みですが、ここではBGPルーティングに限定して具体的に説明します。

IPアドレスの割り振りを受けた組織は、自身がBGP広告するつもりの経路とその最大経路長、および広告元になるASの組をNIRが管理するRPKIシステムに登録、RPKIシステムはこれに対する電子証明書を作成します。^(※2) これをROA(Route Origination Authorization、「あーるおーえー」でも良いですが「ろぉあー」と言うとちょっと通っぽくなります;-P )と言います。

利用者はツリー構造の頂点を示すTAL(Trust Anchor Locator)と呼ばれる情報を頼りに、RIR、NIRと辿りながらROAを取得、検証し、手元に検証済みデータ(VRP: Validate ROA Payload)を保持します。この検証済みデータを保持するのがキャッシュサーバで、キャッシュサーバはRPKI-RTR(RPKI to Router Protocol)というプロトコルを介してBGPルータに情報を供給します。BGPルータはこの情報をもとに、BGP広告を受けた際にその内容がROA情報に照らして正しいかを検証します。これをROV(Route Origin Validation)と言いますが、こうすることで相手のASが広告する経路が正当かどうかを判断することができるという仕組みです。なお、検証した結果をどう扱うかはASの運用ポリシーに委ねられますが、一般的には不正と判断される場合に限って破棄します(理由は後述します)。

ROAを使ったROVはBGPを安全にする仕組みの1つです。他にも、現在より厳密にBGPのAS_PATHを検証可能にする技術も標準化に向けて検討されていますが、ここでは割愛します。

RIRは全てが、JPNICを始めとするNIRの多くでもRPKIの提供を始めており、CiscoやJuniperと言った通信事業者向けのルータには随分前からRPKI-RTRやROVの機能が実装されています。また、キャッシュサーバも複数のOSS実装が開発されていますので、いつでも始められる状況にあります。

ROA/ROVの現状

我々IIJも今から始めるところですので偉そうなことは全く言えませんが、ROA/ROVの普及状況はまさにこれからと言ったところです。

NIST(National Institute of Standards and Technology)の調査では、2020/9現在、インターネットで広告されているBGP経路およそ85万経路のうち76%は該当するROAが存在しません。つまり、ROVで検証することができない状態にあります。前章で、現状では不正と判定されているときのみ破棄するのが一般的と説明しましたが、その理由がこれで、大半の経路は正当か不正かの判定ができない状態にあるため、不明なものは受け入れるしかない状況です。(受けれないとそのIPアドレスへの到達性がなくなってしまいます) 日本に限って言えば、JPNICが管轄するおよそ700ASのうち、60ASが少なくとも1つ以上ROAを作成しています。(IIJも試験的に1つだけ作成しています)

さらに、同調査によると85万経路のうち0.65%、数にして約5,700経路がROAに照らして不正な経路です。まさかこんなに多いなんて! 私の通信は大丈夫なの!?と心配されるかもしれませんが、これが偽らざるインターネットの現状です。

ただし、これらすべてが故意というわけではなく、設定ミス等によるものも多数あると思われます。例えば、あるASが 192.0.2.0/24 の割り振りを受けているとして、この /24 だけをBGP広告するつもりでROAを作ったにもかかわらず、実際にはこの /24 に加えて、それらのサブネットである 192.0.2.0/25 や 192.0.2.128/25 も広告してしまうときがあります。この場合、/25 はROVで不正と判断されます。また、あるASに割り振られたIPアドレスのうち一部を別のASから広告するパンチングホールと呼ばれる状態の場合、別ASを広告元にするROAも作成しないと不正となりますが、これができておらず不正と判定されている場合も多々あります。この約5,700経路の意図は当事者しか知り得ず、全てを聞いて回ることはできませんので、ROVする側は一律破棄するしかありません。

一方、ROVは外部から見ると導入有無を判定することが難しいのですが、海外を中心に大手ASが導入を進めているようです。特にここ1年くらいは、経路ハイジャックに類する事件があるたびにネットワークオペレータのコミュニティでRPKIが話題に上がるほど導入が盛んになっています。

いくら自分が保有するIPアドレスに対してROAを作っても他のASがROVをしてくれないと自分たちのIPアドレスが経路ハイジャックされるのを防ぐことはできませんし、他のASがROAを作ってくれないといくら自分たちがROVをしても不正な経路の流入を防ぐことはできませんので、これらはセットになって拡がるべきものです。

IIJの取り組み

このような状況のROA/ROVですが、IIJも長らく準備を進めており、やっと導入できるところまで漕ぎ着けました。

ROAに関しては、IIJが保有するIPアドレスに対してROAを作り、経路ハイジャックされることを抑制します。ROVに関しては、ROAに照らして不正と判断される経路のみを破棄し、不正な経路がIIJ内に流入することを抑止します。ROVの最初の導入ではピアリングと呼ばれるAS間の相互接続にのみ適用しますが、ASを保有し法人向けインターネット接続サービス(いわゆるトランジット)をご利用のお客様にもそう遠くない将来ROVを適用していく予定です。なお、IIJがピアリングにROVを導入することで、IIJから同じくトランジットをご利用いただいているお客様に不正と判断された経路を広告することはなくなり、お客様ネットワークにそのような経路が流入しなくなる効果もあります。いずれもIIJの各サービスをご利用のお客様およびインターネット全体の信頼性向上に寄与する取り組みですが、一歩間違えれば本来できるべき通信を阻害することになりかねませんので慎重に導入を進めていきます。

経路ハイジャック抑止に効果があるROA/ROVですが、仮に世界の全ASが導入したとしても、現在インターネットで発生している経路に関する問題が全てなくなるわけはありません。冒頭で説明した経路リークは防げませんし、様々な設定ミスや機器の不具合でも問題は起こり得ます。残念ながら、経路ハイジャックに関しても全ての場合に効果があるわけではありません。それでも今より良くなるのは確実ですし、よりロバストにしていくため、経路の伝搬が正しく行われているかを検証する仕組み(AS Path Validation)の標準化、実装も進んでいますし、一部のAS間では経路リークによる障害を防ぐ仕組み(Peer Locking)の議論も進んでいます。

IIJは今後もインターネットをより良いものにしていくため、インターネットコミュニティと共に様々なことに取り組んでいきます。