JPNIC Blog JPNIC

RPKIとは何か ~起源といま~

tech_team 

はじめに

国内では2015年に試験提供が始まったリソースPKI(Resource Public Key Infrastructure; RPKI)は、徐々にその利用が広まり、RPKIを使って作成されるROA(Route Origin Authorization)による、JPNICから分配されたIPアドレスに対するカバー率は、IPv4が45.6%、IPv6は57.1%になりました(*1)。本稿では、RPKIの起源やデザインコンセプト、そして最近の話題を紹介します。

RPKIとは

RPKIは、IPsecの考案者として知られるステファン・ケント(Stephen Kent)氏によって1997年頃に考案されたもので(*2)、IPアドレスやAS番号といった番号資源が分配されると、それを証明する電子証明書が発行される仕組みです。当時は、Secure BGP(S-BGP)と呼ばれる、従来のBGPに修正を加えたもので使われることが想定されていました(*3)。現在、よく使われるRoute Origination Authorization(ROA)の概念はまだなく、BGPにおいて経路情報の伝達に使われるUPDATEメッセージにアテステーション(attestation)と呼ばれる署名付きの情報を含めることで、ASパスや経路情報として使われるIPアドレスの正しさを検証できるようにした仕組みです。

RPKIの実際

RPKIの実用化に向けた検討が始まるのは、2000年代の半ばです。IPv4アドレスの在庫枯渇を前にして、正当な分配先以外の第三者がIPv4アドレスを勝手に使ってしまわないように、その分配を証明するRPKIが必要であるとして、2008年頃にはAPNICRIPE NCCによるリソース証明書の試験的な提供が始まりました。この頃から、RPKIのルート認証局(Certificate Authority; CA)は五つの地域インターネットレジストリ(RIR)が担っていました。ICANNのIANA機能がルートとなって、各RIRにリソース証明書を発行する構想は何度か上がったものの、RIRの中で調整がつかないなどの理由で、いまだに実現していません。

またRPKIは元来、番号資源の分配を受けた者は、その一部をさらに分配する際に、リソース証明書を発行するためCAを運用するモデルです。しかし、番号資源の分配を受けるために、RPKIのCAを運用しなければリソース証明書の利用ができないことは、言わば導入障壁となってしまいました。代替案として考えられた、RIRや国別インターネットレジストリ(NIR)でローカルインターネットレジストリ(LIR)のCAを運用するモデルが現在は主流になっています。例えば、JPNICでは「ROAWeb」という専用のWebサイトを使って、ROAを管理する仕組みを導入しています(図1)。一連のリソース証明書を見てみると、リソース証明書はRIRやNIRごとに設置されたリポジトリに置かれているのみならずファイルで使われている命名規則が各々一律であるなど、RIRやNIRがLIRのCAを代行して運用している様子が伺われます。

ROAWebのモデルとリソース証明書図1 JPNICのROAWebとLIRのリソース証明書

RPKIとBGPセキュリティ

BGPのセキュリティのためにRPKIを利用するアイディアは1997年当初からありましたが、現在利用が広まりつつあるROAのモデルに至るまでには、BGPのセキュリティに関する分析と、要求事項の整理が行われました。それが、RFC4272です。BGPでは長い期間TCPのコネクションが利用されるため、TCPのセキュリティ(MD5オプションなど)が取り上げられるとともに、このRFCにおいて着目されたのはBGPメッセージの生成や書き換えでした。あるIPアドレスの経路を、広告すべきでないASによって勝手に経路公告が行われてしまうことと、BGPメッセージに含まれるASパス属性が書き換えられてしまうことの二つは、攻撃者が他のネットワークの接続性に影響を及ぼし得る要素です。後に、IETF sidr WGで検討が進められるBGPsecは、この二つへの対策技術に位置づけられました。

ROA

ROAは、IPアドレスの分配先組織(アドレスホルダー)が、ASを指定して、経路広告を行うことを認可=オーソライズ(authorize)したことを示すデータです。前述したBGPsecの一つ目の機能である、”経路公告を行うASの指定”が実現されています。指定されたASと異なるASが、あるIPアドレスの経路公告を行っていたら、それは不正な経路であると判別できます。これがROAを使ったオリジン・バリデーション(OV)です。

経路情報の正しさを検査する方法としては、IRR(*4)を使った経路フィルターと対比されます。RADbJPIRRといったIRRには、IPアドレスホルダーによる認可という概念がありませんでした。そのため、IPアドレスの分配とは無関係にIPアドレスを登録オブジェクトに記載することができました。このことは、経路公告にはアドレスホルダーが関与するという、ROAのデザインに繋がっていると考えられます。

ROAの普及状況

国際的なROAの普及状況は、米国国立標準技術研究所(NIST)のRPKI monitorで見ることができます。執筆時点(2022年7月)では、IPv4のBGP経路における38.08%が、IPv6のBGP経路における37.58%が、ROAを使った検証の結果、VALID(ROAと一致している)と判定されています(図2, 図3)。カバー率という意味ではまだまだ普及の余地がありますが、3年前には10%ほど(IPv4)であり継続的な増加傾向が見られます。

2022年7月現在、経路情報におけるROAのカバー率は、IPv4が38.08%となっている。図2 IPv4の経路情報のうちROAでカバーされている(かつValidと判定されている)のは38.08%となっている(NIST RPKI Monitorより)

2022年7月現在、IPv6の経路情報におけるROAのカバー率は37.58%となっている。図3 IPv4の経路情報のうちROAでカバーされている(かつValidと判定されている)のは38.08%となっている(NIST RPKI Monitorより)

日本では、2018年末の段階で3.5%だったIPv4のカバー率が、冒頭で述べたように2022年に45%台になりました。特に、2021年の伸びに著しいものがありました。

RPKI応用のこれから – ASパス検証の技術

ROAは、ASパスの検証には利用できません。これは、ROAが経路の広告元ASに注目したもので、その経路情報が経由したASパスをカバーするものではないためです。いわゆるルート・リークのように想定とは異なるASパスを検知するには、ASパスを検証する仕組みが必要になります。

前述のBGPsecには、BGPを拡張し、ASパスの並び一つ一つに電子署名を付与した”BGPsecパス”があります。しかし、2013年に発表された論文「部分的なデプロイメントにおけるBGPセキュリティ:そのジュースは絞る価値があるのか?(Security in Partial Deployment: Is the Juice Worth the Squeeze?)(*5)によって、その導入効果が普及率に対して高くないことが示されました。これはシミュレーションに基づく結果ですが、それ以降、RPKIを使ったASパスの検証技術を検討してきたIETF sidrops WGでは、BGPsecパスに代わる方式が検討されてきました。それが、Autonomous System Provider Authorization(ASPA)です。

ASPAは、指定したASがUpstreamプロバイダーであること、つまり自らのAS番号を含めた経路情報を広告することを認可したことを示すデータです。つまり、ASパスのうちの一つの隣接関係を示しています。ASPAでは、BGPsecにおけるBGPsecパスのように一連のASパスをチェックするではなく一つ一つの隣接関係を確認していきます。すべての隣接関係にASPAで示された関係が認められれば正しいASパスであることが分かります(図4)。Upstreamプロバイダーとして複数のASを指定することが可能です。

2022年2月にJPNICで行われたRPKIワークショップで発表された大阪大学の学生による研究(*6)では、部分的な普及を前提としたとしても、ASPAを使ったASパス検証の方式は不正なASパスの検知のために十分広い範囲のネットワークに効果を発揮することが分かっています。

ASPAの示す内容とASパス検証
図4 ASPAの示す内容と意味

 

RPKI応用のこれから – BYOIP

RPKIは、さらに応用範囲を広げようとしています。元来の、IPアドレスの分配を証明する仕組みの応用です。一部のクラウド事業者は、アドレスホルダーがIPアドレスを持ち込んで、そのクラウド事業者のサービスのために使う”Bring Your Own IP – BYOIP”ができるようになっています。その際に、クラウド事業者が、顧客に対してIPアドレスホルダーであるかどうかを確認する必要が出てきます。そのような用途に使えるものとして、IETFで議論されているのがRSC(RPKI Signed Checklist)です。RSCは、RPKIのリソース証明書を使って任意のデータに署名できる書式で、これにクラウド事業者のユーザーを示す値を入れるなどすることで、クラウド事業者が特定のユーザーがアドレスホルダーであることを確認することが想定されます。現在、提案と議論、そしてクラウド事業者との相談が行われている段階であり、将来どうなるかは分かりませんが、RPKIを応用する仕組みの一つの方向性として捉えることができます。

おわりに – ROAを使った経路検証の普及に向けて

2022年6月現在、国内においてROAの作成は広まりつつありますが、ROAを使ったBGP経路の検証(ROV)を行う国内のASはまだまだ少ない状況です。なお、国際的にはAmazon Web Services(AWS)社、Google社、Cloudflare社といったクラウド事業者の他、大手通信事業者において導入されています。国内でも、本来と異なるBGP経路の検知を行い、不正なBGP経路が伝搬してくるようなことが起きても対策が取れるようにすることが重要だと考えられます。しかしROVの導入は、Invalidと判定されたBGP経路が使えなくなることから、導入に敷居を感じているAS運用者はいるのではないでしょうか。

そこでJPNICと有識者とで、ROVの導入に資する実験を企画しています。この実験ではAS運用をされている方々が、

  1. ROVで不正経路から守られること
  2. ROVを導入しても通常は問題ないこと
  3. 問題が起きても対処できること

の三つの”確証”を得ることを目的として、仮想環境や実際の機材を使った体験ができるような企画です。これらの活動が、日本のインターネットのルーティング、すなわち基幹部分を担う方々による状態の把握や、技術的に有効性のあるものとして、運用の質をさらに高めていく一助になればと考えております。

ご参考までに、ROAを使ったROVを行うようにすると、どのような効果が得られるのかをわかりやすく示したデモを下記の動画でご覧いただけますので、ぜひ導入のご参考になさってください。

 


(*1) IPv4はアドレス数、IPv6は/48の個数として算出しています。

(*2) BBN Report 8217, “An Architecture for BGP Countermeasures”, November, 1997

(*3) そのため、IPアドレスやAS番号が記載される電子証明書の拡張フィールドの名称に”sbgp”という文字列が入っています。

(*4) Internet Routing Registryは、ルーティングに関する情報を登録・検索できる情報共有用のオンラインデータベースです。IPアドレスの経路情報やその管理組織(メンテナー)に関する情報を相互にリンクできる”オブジェクト”として扱い、また各オブジェクトの書式を定めておくことで、プログラムで処理しやすくなっています。書式と言語はRPSLと呼ばれ、1990年代から、BGPルータに設定される経路フィルターを生成するなど、広く利用されてきました。

(*5) “BGP Security in Partial Deployment: Is the Juice Worth the Squeeze?”, Lychev, Robert and Goldberg, Sharon and Schapira, Michael, 2013, ACM, SIGCOMM Computer Communication Review, 171-182

(*6) “ASPAの仕組みと効果”, 梅田直希, 大阪大学
              

この記事を評価してください

この記事は役に立ちましたか?
記事の改善点等がございましたら自由にご記入ください。

このフォームをご利用した場合、ご連絡先の記入がないと、 回答を差し上げられません。 回答が必要な場合は、 お問い合わせ先 をご利用ください。