FAQ

注釈

これはAlex Band、Job Snijders、David Monosov、Melchior Aelmansによって書かれたコミュニティ主導のRPKI FAQです。世界中のネットワーク運用者がこれらの質問と回答に貢献しています。このコンテンツは Github 上で公開されており、編集や追加のプルリクエストを送ったり、他の場所で使用するためにコンテンツをフォークしたりすることができます。

RPKIの仕組み

RPKIとは何でしょうか？なぜ開発されたのですか？

インターネットのグローバルルーティングシステムは機能的に独立した多数の主体（Autonomous Systems）で構成されており、各々がBGP（Border Gateway Protocol）を使用してルーティング情報を交換します。このシステムは設計上、非常に動的で柔軟性に富んでいます。接続性とルーティングトポロジはルーティング情報の変更に左右され、その変更というのは僅か数分で世界中に伝播します。このシステムの弱点は、これらの変更をBGPというプロトコルから離れ、その外部に存在する情報で検証出来ない点にあります。

RPKIは、BGPで交換される情報の正当性を検証するために、BGPというプロトコルの外側にデータを定義する手法です。RPKIの標準仕様は、インターネットルーティングやアドレスに関する資源情報の一部を暗号システムに落とし込むことを目的としてIETF（Internet Engineering Task Force）によって開発されました。これらの情報は公開されており、誰もがアクセスして暗号的にその整合性を検証することができます。

経路の広報元を確認するためにIRRを使っていますが、なぜ今更RPKIが必要なのでしょうか？

Default Free Zoneのインターネットエンジニアリングに長く携わっている人なら、1998年に RFC 2280 で定義されたルーティングポリシー仕様言語であるRPSL（Routing Policy Specification Language）をよく知っているでしょう。RPSLはその初期にかなりの熱狂を生み出しある種の牽引力を見せていましたが、当時はインターネットが急速に成長しており、データの信頼性よりもデータの可用性に主眼が置かれていました。当時は誰もが最終的なPINGを果たすために、他人のRPSL解析スクリプトを使って、「とにかく動くように」最低限必要なポリシーをその場しのぎで文書化することに忙しかったのです。

これにより、世界中に何十もの経路情報の登録にまたがって、有効性が不明な陳腐化したデータから成る大規模なリポジトリが時間の経過とともに作成されてきました。加えて、RPSLとそれをサポートするツールは、そのポリシーを矛盾なくルーターの設定言語に変換するには複雑すぎることが分かってきました。結果として、公開されているほとんどのRPSLのデータは、フィルタリングを目的とした場合には正確性や更新度合いが不十分であり、また、ルーター設定のゴールデンマスターとしては十分に包括性でなく精密さに欠けるものとなっています。

RPKIは主にデータの信頼性、適時性、正確性に焦点を当てることで、これまでの取り組みを補完し拡大することを目的としています。RPKIのROAは、厳格な基準に基づいてRIRによって階層的に委任され、暗号化された検証可能なものです。これにより、インターネットコミュニティはインターネット上に最新かつ正確なIPアドレス広報元のデータを構築することが可能となります。

なぜRPKIに投資をするのでしょうか？Internet Routing Registry（IRR）を直すほうが簡単なのではないでしょうか？

IRRの主な弱点は、それがグローバルに展開されたシステムではないこと、また、完璧なシステムにするための認証モデルを欠いていることにあります。その結果、公開されているルーティングの意向に関するすべての情報のうち、何が正当で真正なデータであり、何がそうでないのかを判断することが困難になります。RPKIはこれらの2つの問題を解決するもので、世界中の正当なIPリソース保有者が暗号的に検証可能な申し立てを確実に行うことを可能にします。

BGP4はもう限界というのは本当ですか？

残念ながら今すぐにBGPを置き換えることは事実上不可能です。しかし、壊れている部分を修正し状況を改善する作業を行う必要があります。

RPKIはX.509公開鍵基盤に依存しているので、信頼できないSSL/TLS認証局と同じ問題が繰り返し起こるのではないでしょうか？

ブラウザやOSにプリインストールされている可変の監査基準に従う多数の認証局に依拠するのではなく、RPKIは地域インターネットレジストリ（RIR）によって運営されているわずか5つのトラストアンカーに依拠しています。

これらのは十分に確立したオープンに管理されている組織である。RPKIリソース証明書の取得を希望する各事業者は、すでに一つ以上のRIRと契約関係を結んでいるます。

パス検証を伴わないRPKIベースのオリジン検証の価値とは何でしょうか？

Path Validationの導入は望ましいものですが、それがなかったとしても既存RPKI Origin Validation機能は大部分の問題に対応することができます。

既存の運用上および経済上のインセンティブにより、各ネットワークにとって最も重要な経路は可能な限り最短のAS Pathを経由したものとなります。一つの例として、ネットワーク運用者はIX（インターネットエクスチェンジ）やプライベートピアを通して学習した経路のLocal Preferenceを高く設定することがあります。これにより正しい広報元ASから広報されたかのように偽られた場合でも不正な経路がBGP Best Path Selectionに勝つリスクを低減することができます。

トランジットプロバイダーにとって、直接相互接続とAS Pathの短さという要素は、RPKIに基づいて動作し、再配布のために正当な経路のみを受け入れるという理想状態に位置づけるための重要な特徴です。

さらには運用上の経験から、経路ハイジャックの大部分は悪意のあるものではなく、オペレータが意図せず誤って自分が保有していないprefixを広報してしまう "fat-fingering"が原因であることが分かっています。Origin Validationはこれらの問題の多くを軽減します。

広報元ASを意図的になりすまそうとする攻撃者が、Path Validationがないことを利用しようとする可能性はあるものの、RPKI Origin Validationが普及することによりそのような事例を特定して対処することが容易になります。

ROAとルーターが受信した経路とを比較すると、どのような結果が得られるのでしょうか？

経路はValid、Invalid、NotFound (a.k.a. Unknown) のいずれかの状態を持つことになります。

  • Valid: その経路広報は少なくとも一つのROAの範囲に含まれている。
  • Invalid: prefixが不当なASから経路広報されている、もしくはprefixとASはROAと一致しているが、ROAで設定されたmaximum lengthを超過したprefix長をもつ経路広報である。
  • NotFound: 経路広報されたprefixがROAの範囲に含まれない（あるいは部分的にしか含まれていない）。

詳細については RFC 6811 の第2章を参照してください。

経路リークと経路ハイジャックについて違いは何でしょうか？

経路リークとは意図した範囲を超えて経路広報が伝搬する事象を指します。つまりそれは、BGPで経路を学習したある自律システム（AS）から他のASへの経路広報が、受信者、送信者、またはAS PATHに含まれているASの意図したポリシーに違反しているということになります。

経路ハイジャックとは不当な経路広報を指します。

その原因が偶発的であれ意図的であれ、経路リーク/経路ハイジャックのいずれにおいても結果として通信経路の遠回りやリダイレクト、サービス不能などの影響を引き起こす可能性があります。詳細は RFC 7908 を参照してください。

ROAが暗号的に不正だった場合、ROVによる経路の判定結果はInvalidになるのですか？

暗号的な検証をパスしなかった無効なROAは破棄されます。無効なROAが示す情報はROVのプロセスにおいて考慮されません。一方で、有効なROAによりInvalidと判定された経路とはつまり、不当なASによるprefixの経路広報、もしくはprefixとASはROAと一致しているが、ROAで設定されたmaximum lengthを超過したprefix長をもつ経路広報であると言えます。

オペレーションとそれに対する影響

暗号的な検証をすることによるルーターへの影響はありますか？

ありません。Route Origin Validationを実行するためにルーターで暗号化処理を行う必要はありません。署名はRelying PartyまたはRPKI Validatorと呼ばれる外部ソフトウェアによって検証され、軽量なプロトコルを介して処理済みのデータをルーターに送ります。このアーキテクチャにより、ルーターのオーバーヘッドを最小限にすることが可能です。

ルーターでRPKIを動作させることによってBGPの収束速度は低下しますか？

いいえ、RPKIの検証済みキャッシュに基づくフィルタリングは収束速度にほとんど影響を与えません。RPKIの検証はまだローカルに存在しない新しいprefixに対する経路学習と並行して行われます。それらのprefixが利用可能になった時にValid、Invalid、NotFoundのいずれかでマーキングされ、それに基づく適切なポリシーが適用されます。

Validatorを使うためにrsyncが必要となるのはなぜですか？

当初の標準規格においてrsyncはRPKIのデータを伝搬するための主要な手段として定義されていました。初期の段階ではシステムをうまく機能させていましたが、rsyncにはいくつかの欠点があります。

  • クライアントとして動作させるRPKI Relying Partyソフトウェアはrsyncに対して依存性を持ちます。rsyncのバージョンやサポートするオプション（例えば --contimeout など）が異なる場合には、思わぬ結果を招きます。さらに、そもそもrsyncを呼び出すことは非効率的です。これはRPKIの処理を考えた際には追加のプロセスであると言え、またrsyncによる出力はディスクをスキャンすることでした検証することができません。
  • グローバルでRPKIのデータが増加し、データをダウンロードして検証するオペレーターが増えれば増えるほど、スケーリングに関する問題の深刻さは増します。それはrsyncのみでなく差分を処理するサーバー側についても同様のことが言えます。

これらの制限を克服するためにHTTPSに則ったプロトコルであるRRDPが開発され、RFC 8182 で標準化されました。RRDPは特にスケールすることに重きを置いて設計されており、CDNがグローバルなスケールでRPKIデータセットを提供することが可能になります。さらに、HTTPSはプログラミング言語で十分にサポートされているため、Relying Partyソフトウェアをより容易に、より堅牢に開発することができるようになります。

現在RRDPはARIN、RIPE NCC、APNICのサーバサイドで実装されています。また、ほとんどのRPKI Validator実装で既にRRDPをサポートしているか、短期的なロードマップ上に据えています。

5つのRIRはホスト型RPKIシステムを提供していますが、その代わりに自分自身で委任型RPKIシステムを運用したい理由はなんでしょう？

RPKIは分散型システムとして設計されており、各組織が独自のCAを運営し、証明書とROAを自ら発行できるようになっています。RIRが提供するホスト型RPKIシステムは参入障壁を下げ、オペレータが独自のCAを運営するかどうかを決める前に運用経験を積むことを可能にします。

多くのオペレータにとっては長期的に見てホスト型RPKIシステムで十分であると言えます。しかし例えば、管理のためのWebインターフェースに依存したくない、複数のRIRリージョンに跨るアドレス空間を管理している、またはROA管理と統合したBGPの自動化を行っているなどの組織は、独自のシステム上でCAを運用する選択をすることができます。

インターネット上で外部のデータソースを見つけたとしても、自分自身でValidatorを動作させるべきなのでしょうか？

リソース保有者が資源保有の正当性を主張することに対して署名を施すことの価値は、データが本物であり、いかなる方法でも改竄されていないことを検証できることに由来しています。

署名の検証を第三者に委託することで、データの正確性と真正性が失われます。概念的にはDNSSECの検証に似ており、ローカルの信頼できるリゾルバーで検証を行うのがベストです。

RFC 7115 の第3章では、このトピックについて網羅的に説明されています。

どのくらいの頻度でRPKIリポジトリからデータを取得するべきですか？

RFC 7115 の第3章によると、4〜6時間毎に新しいデータを取得すべきです。現時点で最も大きなリポジトリからROAを取得するのに約10～15分かかります。つまり、システムに不要な負荷をかけずに、15分から30分ごとに取得するのが合理的であると言えます。

RPKIシステムが利用できなくなったり大きな障害が発生した場合、私が広報する署名済みのprefixは他の人にとって到達不能になるのでしょうか？また私のルーターがBGPで学習したprefix宛の通信は到達できなくなるのでしょうか？

RPKIはルーティングに関する意図を肯定的に表現します。もしも全てのRPKI Validatorが使用不能になったり、全ての証明書やROAが失効したりしたとしても、ROVによる経路の検証結果はRPKIを使用しなかった場合と同様のNotFoundに戻るだけです。RFC 7115 の第5章によると、NotFoundと判定された経路はacceptするべきと記載されています。なお、現状多くの経路は残念ながらNotFoundと判定されています。

Validatorがクラッシュしルーターがデータを受信できなくなった場合、ルーターがBGPで学習したprefixはどうなりますか？

Route Origin Validationをサポートするすべてのルーターでは、冗長性のために複数のバリデーターを指定することができます。復数のValidatorインスタンスを、できれば異なるサブネット上で独立して動作させることが推奨されます。この方法により復数のキャッシュに依存する形になります。

仮に全てのValidatorが動作不能に陥ったとしても、全ての経路はRoute Origin Validationを実施しなかった時と同じようにNotFoundと判定されます。

RPKIデータに頼らずに特定の経路に対してのみ特別な操作をしたい場合どうすればよいのでしょうか？

特定のprefixや経路広報に対して独自のポリシーを適用し、リポジトリから受信したRPKIデータを上書きすることが可能です。オーバーライドの方法は、RFC 8416 “Simplified Local Internet Number Resource Management with the RPKI (SLURM)” で標準化されています。

ROVによる検証を実施せずに、経路に署名を施しROAを作成することに意味はあるのでしょうか？

経路に署名を施してROAを作成することは良い試みであると言えます。もし仮にあなたがROVを実施しなかったとしても、他の誰かがあなたの作成したROAに基づいてROVを実施するでしょう。また一方で、最悪のケースでは誰かがあなたのprefixをハイジャックしようとする可能性もあります。そうなった時にROAを作っていなかったとしたら...

Miscellaneous

What is the global adoption and data quality of RPKI like?

There are several initiatives that measure the adoption and data quality of RPKI:

I want to use the RPKI services from a specific RIR that I'm not currently a member of. Can I transfer my resources?

The RPKI services that each RIR offers differ in conditions, terms of service, availability and usability. Most RIRs have a transfer policy that allow their members to transfer their resources from one RIR region to another. Organisations may wish to do this so that they bring all resources under one entity, simplifying management. Others may do this because they are are looking for a specific set of terms with regards to the holdership of their resources. Please check with your RIR for the possibilities and conditions for resource transfers.

Will RPKI be used as a censorship mechanism allowing governments to make arbitrary prefixes unroutable on a whim?

Unlikely. In order to suppress a prefix, it would be necessary to both revoke the existing ROA (if one is present) and publish a conflicting ROA with a different origin.

These characteristics make using RPKI as a mechanism for censorship a rather convoluted and uncertain way of achieving this goal, and has broad visibility (as the conflicting ROA, as well as the Regional Internet Registry under which it was issued, will be immediately accessible to everyone). A government would be much better off walking into the data center and confiscate your equipment.

What are the long-term plans for RPKI?

With RPKI Route Origin Validation being deployed in more and more places, there are several efforts to build upon this to offer out-of-band Path Validation. Autonomous System Provider Authorisation (ASPA) currently has the most traction in the IETF, defined in these drafts: draft-azimov-sidrops-aspa-profile and draft-azimov-sidrops-aspa-verification.