Project

RPKI プロジェクト
ROAキャッシュ
設定サンプル
その他

MF RPKI プロジェクト

技術的背景

経路ハイジャック※1 や経路リーク※2 といった「不正な経路広報」に起因するインターネットルーティングに関するインシデントは日常的に発生しています。世界のどこかで発生したこれらの事象により自身のネットワークやそこに関わる通信が影響を被る可能性が低くないことを考えると、インターネット全体でルーティングセキュリティの向上に努めることは極めて重要です。

BGPには「不正な経路広報」であることを判別する機能は存在しないため、これらの事象から十分に身を守るためには別の仕組みが必要です。そこで、外部の情報を参照し経路のフィルタリングを行うことでセキュリティを高める手法が取られます。代表的な例としてIRR（Internet Routing Registry）を参照し、経路フィルターを生成する運用が多くのネットワークで行われています。一方で普及した手法ではあるものの、IRRの登録内容が適切に維持・管理されていないケースがある、そもそもIRRに登録されている情報の正しさは保証されていない、といった課題があります。

RPKIはBGPやその運用における課題に対し、IPアドレスやAS番号の割り当てを電子署名を用いて証明することで解決を試みる技術です。IPアドレスの正しい保有者が証明されれば、外部のASから受信した経路広報が「正しいかどうか」を判別することが可能となります。RPKIに関する議論は以前から行われてきていましたが、特にここ数年で活発化し、現在では世界中でその導入を進めるASが増加しています。セキュアなインターネットルーティングの実現に向け、今後ますます多くのネットワークでRPKIを導入することが求められています。

RPKIとは

RPKI（Resource Public Key Infrastructure) はインターネットのアドレス資源であるIPアドレスやAS番号の割り当てを電子署名を用いて証明するための公開鍵基盤です。RPKIはアドレス資源の電子証明書であるリソース証明書を発行します。このリソース証明書によりIPアドレスやAS番号の保有に関する正当性が証明されます。

RPKIの公開鍵基盤としての構造は、下図に示すようにアドレス資源の割り振り/割り当てを行うインターネットレジストリから成るツリーになります。これはIANAを最上に据えた インターネットレジストリのツリー構造 とほぼ同形です。

各インターネットレジストリはそれぞれが認証局（CA, Certificate Authority）として上位のレジストリから正当性を保証された上でリソース証明書を発行し、また同時に下位レジストリの正当性を保証します。ツリーの最上位に位置する5つのRIRはTrust Anchorと呼ばれ、署名検証の基点となります。後述するRelying PartyソフトウェアがROAのリソース証明書の検証を行う際にはTAL（Trust Anchor Locator）に示されたTrust Anchorを参照し、上位から下位へ署名ツリーを辿ります。

RPKIはあくまで公開鍵の基盤であり、RPKIで発行したリソース証明書を利用することで、例えばBGPで「不正な経路広報」を判別することができるようになります。

ROA

ROA（Route Origin Authorization） は「IPアドレスとそれを割り当てられているAS番号の正しい組み合わせ」に対してRPKIで発行したリソース証明書で電子署名を付与したデータです。JPNICからアドレス資源の割り当てを受けている事業者は JPNICの解説 を参考にROAを作成・管理することが可能です。

ROAには以下の3つの項目が含まれます。

  • prefix: IPアドレス空間
  • origin AS: "prefix" の割り当てを受けているAS番号
  • maxLength: origin ASがprefixを広報する際の最大のprefix長

例えばあるAS65001が10.0.0.0/24を保有しており、以下のROAを作成したとします。その場合AS65001は10.0.0.0/24という本来のprefix長と一致した経路と、それを2つに分割した10.0.0.0/25、10.0.0.128/25という2つの/25の経路を広報をすることが可能です。

  • prefix: 10.0.0.0/24
  • origin AS: 65001
  • maxLength: 25

ROAとは

ROAとは、Route Origin Authorizationの略で、BGPの経路情報に記述されているPrefix情報とAS番号の正しい組み合わせを一定期間証明するデータです。例えばMFが提供するROAパブリックキャッシュ情報とは、MFからパブリックに提供されるこのROA情報のことを表します。ROAには複数のPrefixを記述することが可能で、このROAをルータが参照することにより、インターネットから広告されてきたBGP経路情報が本当に正しい経路情報か否かを判別することが可能となります。
またROAには maxlen(maximum prefix length)という概念が存在します。通常のBGP経路情報に記述されているPrefixとOriginASに加えて、どのPrefix長まで経路広告を許可するかを記述した情報です。これにより、longer-prefixについても1つのROAデータで記述することが可能となります。

maxLengthについて

maxLengthの取り扱いについて RFC7115 では「長いmaxLengthを使う代わりに実際に経路広報するprefix長を持つROAを複数登録すべき」としています。これは可能な限りROAのprefix長とmaxLengthを一致させよ、ということを意味します。このように述べられている理由は、悪意のあるASがmaxLengthを悪用して不正に経路広報を行った際に、後述するRPKI ROVで当該の経路広報が「正当である」と判定されることを回避するためです。具体的にはAS65001が通常/24のprefixのみ広報する状況において、悪意のあるAS65111が自身はAS65001と謳い/25のprefixを広報した場合、その経路広報はRPKI ROVで「正当である」と見なされます。結果としてLongest Prefix Matchにより本来AS65001宛の通信がAS65111に流入する可能性があります。しかし、実際には経路広報の方針やROAの登録・管理方法は各ASのポリシーに従うため、本指摘はあくまで推奨という扱いに留まります。

RPKI ROVとは

RPKI ROV（Route Origin Validation） とは、ROAとBGPで受信した経路情報とを照合し、「prefixが正しいorigin ASから広報されているか」を検証する技術です。イメージとして仮にRPKIをデータベース、ROAをそこに登録されたデータであるとすると、ROVはデータベースに登録されたデータを活用しBGPで経路の正当性を確かめる機能の実装であると言えます。

ルーターでROVを行うためには、まず各インターネットレジストリが蓄積するROAを収集し、RPKIの署名ツリーを用いてROAに付与された電子署名の正当性を検証する必要があります。この作業は依拠当事者（RP, Relying Party）の役割を担うソフトウェアで行います。また、RPソフトウェアは署名の検証に成功したROAをキャッシュとして保持することが可能です。ルーターはRPのROAキャッシュに対してRTR（RPKI to Router）というプロトコルで接続し、署名検証済みのROAをローカルにダウンロードします。

ROVでは、RPからダウンロードしたROAの内容とBGPで受信した経路のprefix及びorigin ASを検証（Validation）し、3つのうちいずれかの判定結果（Validity）を得ます。Validationの詳細やアルゴリズムについては RFC6811 第2章 を参照してください。

  • Valid
    • prefixが一致するROAが存在しorigin ASが一致する
  • NotFound
    • prefixが一致するROAが存在しない
  • Invalid
    • prefixが一致するROAが存在するがorigin ASが異なる、またはprefix長がmaxLengthを超過している

ルーターではROVで得たValidityを元に当該の経路を受け入れる（accept）か、破棄する（reject）かを決定します。Valid、NotFoundの経路はacceptし、Invalidな経路はそれを示すBGP Communityを付与した上でacceptすることも可能ですが、最近ではInvalidな経路をrejectするASも増えてきています。最終的にはRPKI ROVを導入する全てのASでInvalidと判定された「不正な」経路をrejectすることで、よりセキュアなインターネットルーティングが実現できます。

RPKI ROVで何を防ぐことができるのか

RPKI ROVを利用することで、設定誤りやオペレーションミスに起因する経路ハイジャックを防ぐことができます。多くの経路ハイジャックはこれらの意図しない要因で発生していると言われており、多くのASがROVを導入することでグローバルなルーティングインシデントを回避できる可能性が高くなります。

一方で、ROAの項目で述べた通り悪意を持って行う経路ハイジャックに対してROVは効果を発揮しません。ROVでは「経路のorigin ASそのものが本当に正しいかどうか」を検証することはできないため、origin ASを偽装された経路や乗っ取られたASから広報された経路をValidと判定する可能性があります。また、ROVで経路リークを防ぐことはできません。経路が経由してきたASの連なり（つまりはAS_PATHを指す）が正しいかを検証するためには後述するPath Validationが必要となります。

概要図

図 : RPKI ROV概略図を用いてRPKI ROVの全体像について説明します。

1-ROAの作成

AS65001はJPNICからIPv4アドレス10.0.0.0/20の割り当てを受け、インターネットに広報しているとします。AS65001のROA作成はJPNICが運営するRPKIシステムを通して行うことが可能です。

多くの場合はこのように自身がアドレス資源の割り当てを受けているインターネットレジストリのRPKIシステムを利用してROAの作成を行います。一方でRPKIシステムを自前で運用したい場合には、図2の署名ツリーで "ISP" として示されるようにCA（Certificate Authority）ソフトウェアを運用しRPKI署名ツリーに接続することも可能です。

作成されたROAは各インターネットレジストリや自前のCAを運用するISP等が管理するリポジトリに保存されます。

2-Relying PartyによるROAの取得

前述の通りRP（Relying Party）はリポジトリからROAを取得し、ROAに付与された電子署名を暗号的に検証（Validation）します。RPはTAL（Trust Anchor Locator）という、Trust AnchorのURLと公開鍵が書かれたファイルを元にRIRのリポジトリに接続し、署名ツリーを辿りながら配下のリポジトリに登録されたものも含めROAを取得し、検証します。例えばAPNICのTALは こちら で公開されています。ROAの転送にはrsyncや RRDP といったプロトコルが用いられます。

RPは検証に成功したROAをキャッシュすることが可能です。そのキャッシュを公開し、RTRプロトコル で接続してきたBGPルーターに対してROAの情報をインプットします。

なお実際にROVを実施する際には、インターネットで公開されているRP（例えば 弊社が運営するRP など）を利用するのではなく、自身のネットワークの内部にRPを動作させ利用することが推奨されます。その理由としては、rsyncは通信の暗号化を行わないことや（RPソフトウェアによっては暗号化のサポートあり）、外部のネットワークの影響を受けない環境で安定的にROAキャッシュを提供する必要性があることなどが挙げられます。

3-ROVの実施

AS65002はASの境界に位置するBGPルーターでRPKI ROVを有効にしています。ルーターはRTRプロトコルでRPからROAの情報を取得します。前述の通りAS65002がROVを実施するため、本来RPはAS65002の内部（図の雲の中）で動作させるべきです。

AS65002は2つのASからそれぞれ10.0.0.0/20とそのsub prefixを持つ経路を受信しています。AS65001は10.0.0.0/20の正当な保有者であり、RPKI署名ツリーを通してROAを作成しています。一方でAS65111は、よりprefix長の長い10.0.0.0/21を不正に広報しており、経路ハイジャックを引き起こしていると言えます。この時AS65002のルーターでROVを実施した結果は、AS65001から受信した経路はValid、AS65111から受信した経路はInvalidとなります。AS65002がInvalidと判定された経路をrejectする経路フィルターを実装している場合、ハイジャックされた経路ではなく、正しい保有者が広報した10.0.0.0/20のみをルーティングテーブルにインストールすることができます。

ルートサーバーにおけるRPKI ROV

ルートサーバーはIXにおいてお客様から受信した経路を他のお客様に広く広報する役割を担うため、適切に経路をフィルタリングすることが求められます。特にInvalidと判定された経路の拡散を防止することは、ルートサーバーの重要な責務であると言えます。

JPNAP RouteFEEDサービスのフィルタリングポリシー

RPKI対応ルートサーバーではROVのValidityに基づき、以下のポリシーで経路をフィルタリングします。

  • Valid, NotFound
    • 当該経路は他の経路フィルターを通過した場合、acceptされ他のお客様に広報される
  • Invalid
    • 当該経路はrejectされる

JPNAPの経路フィルター仕様に関しては こちら をご覧ください。（JPNAPユーザ限り）

Path Validation

前述の通りRPKI ROVは経路リークに対して効果を発揮しません。経路リークの被害に遭わないためにはAS_PATHの正しさを検証するPath Validationが必要となります。

Path Validationの文脈で散見される技術として BGPsec が挙げられますが、BGPsecは経路リークを防止することを目的としません。BGPsecはAS_PATHが偽装されていないことを証明する技術であり、AS_PATHを不正に操作する攻撃を防止することが可能です。しかし、署名検証に伴うBGPルーターの負荷増、インターネット全体で高い導入率を必要とすること、またBGPでpeerを確立する際のネゴシエーションでBGPsecを回避できるダウングレード攻撃に対するリスクなど、実現に向けて解決すべき課題が多く残されています。

ASPA（Autonomous System Provider Authorization）は近年IETFで議論されている技術です。BGPsecとは異なり、明確に経路リークを防止することを目的としています。ASPAでは2つのASの経路広報の関係性（送信と受信）を表すASPAオブジェクトに対してRPKIで発行したリソース証明書で署名を施し、ROAと同様にリポジトリで公開します。経路を受信したルーターはROVのようにASPAオブジェクトをもとにAS_PATHの検証を行います。シンプルでスケーラビリティがあること、ROVと類似の仕組みであることなどから注目を集めています。詳細は draft-ietf-sidrops-aspa-profile 及び draft-ietf-sidrops-aspa-verification を参照ください。

今後これらの技術により、さらにセキュアなインターネットルーティングが実現できることを期待しましょう。

インターネットマルチフィードにおけるRPKIへの取り組み

インターネットにおけるBGP経路情報の交換では、AS運用者の設定ミスや悪意のある不正な経路広告によって、正しい宛先ネットワークに到達出来なくなる可能性があります。2008年に発生した、YouTubeが世界中から参照できなくなった事例のように、不正な経路情報がインターネット全体に蔓延し、世界中の通信に悪影響が及ぼされる事例も多く発生しています。

このような状況の中、インターネットマルチフィードでは、これまでJPNICや大手ルータベンダ各社等と連携し、インターネットの経路制御の信頼性向上を目指し、将来ISPの皆様が利用されるRPKI技術に関して、2012年よりROAキャッシュサーバの構築およびそれを参照するルータの動作検証を実施し、業界へフィードバックして参りました。

2014年10月1日より、日本のISPの皆様が今後RPKIの運用を本格化することを念頭に、ROAキャッシュサーバの運用を開始し、本格的にRPKI運用技術の習得およびインターネット全体の信頼性向上を目指し、より安心・安全なネットワーク環境を提供できるよう、インターネットの発展に貢献して参ります。

注釈

※1 本来そのIPアドレスを広報すべきでないASが経路広報する事象を指します。本来のASを宛先にしたトラフィックが、経路ハイジャックを起こしたASに吸い込まれ消失する可能性があります。悪意を持って行われることは少数で、大半の要因は設定やオペレーションのミスによるヒューマンエラーだと言われています。

※2 広報された経路が元々意図した範囲を超えて伝搬する事象を指します。例えばマルチホームでトランジット接続している事業者が、片方のトランジットASから受信した経路を誤ってもう一方のトランジットASに広報し、更に広報を受けたトランジットASが顧客からの経路を適切にフィルタリングせずインターネットに広報するケースなどが考えられます。詳しくは RFC7908 をご参照ください。