RPKIのROAを使ったインターネットにおける不正経路への対策ガイドライン

一般社団法人日本ネットワークインフォメーションセンター

目次

1. 1. ガイドラインの趣旨
   1. 1.1 本ガイドラインの活用方法
   2. 1.2 インターネットにおける経路情報
   3. 1.3 不正な経路情報のリスクや損失
   4. 1.4 対策技術 ― RPKIとROA、ROV
2. 2. 技術的情報
   1. 2.1 ROA/IPアドレスの分配を受けた者の実施事項
      1. 2.1.1 ROAとは
      2. 2.1.2 不正経路とIPアドレスに関する考え方
      3. 2.1.3 ROAの作成と運用管理
      4. 2.1.4 BGP経路とROAを一致させる手順
      5. 2.1.5 重要事項：ROAの導入に関わる三つの確認
      6. 2.1.6 例外的な処置
   2. 2.2 ROV/AS運用をしている者の実施事項
      1. 2.2.1 不正経路への対策と考え方とROV
      2. 2.2.2 ROVの導入に関わるコスト
      3. 2.2.3 ROAキャッシュサーバ・ROVの所在
      4. 2.2.4 ROAキャッシュサーバの構築
      5. 2.2.5 ルータにおけるROV設定
      6. 2.2.6 ROVによる経路制御の詳細
      7. 2.2.7 重要事項：ROVの導入に関わる三つの確認
      8. 2.2.8 ROVの設定例
      9. 2.2.9 運用上の注意と懸念点
3. 3. ROA/ROV以外の不正経路対策
   1. 3.1 BGPにおけるセキュリティの要素と考え方
   2. 3.2 ASパス検証の今後と運用について
4. 4. 用語集
5. 5. おわりに

1. ガイドラインの趣旨

本ガイドラインは、国内のISP等、 インターネットの接続性に関わる事業や技術的運用行っている組織の経営者及び技術者の方に向けたもので、 相互接続ネットワークであるインターネットにおける不正な経路情報、 特にRPKIを使った対策の指針を示すものです。

不正な経路情報に起因する様々な不具合、 および不正な経路情報を用いた犯罪等を抑止するにあたり、 RPKI技術を用いた対策技術を各組織や個人において導入する判断に資する事項を示します。

1.1 本ガイドラインの活用方法

第1章は経営的な観点での判断に資する内容になっており、 第2章以降は技術的観点での検討や判断に資する内容になっています。
※個人の場合には、組織を個人として読み替えてください。

• 経営的な観点での本ガイドラインの活用方法
  御組織においてJPNIC等からIPアドレスの割り当てを受けているかどうか、 またASを運用しているかどうかを、技術部門、 もしくはJPNICとの取引を担当している部署で確認してください。 いずれかが該当する場合には、第1章を読んで、 1.5節に記載された項目の実施を検討します。
• 技術的観点での本ガイドラインの活用方法
  御組織においてJPNIC等からIPアドレスの割り当てを受けているかどうか、 またASを運用しているかどうかを確認し、 対応実施事項(1.5節)を確認します。 各々の項目の実施やその判断にあたっては、 第2章の対応する章を参照してください。 御組織における導入形態などを明確化するために役立つ内容になっています。
• 実証実験の結果を受けた「三つの確証」
  実証実験の結果、 本ガイドラインで示される実施項目について、 実験参加者において「導入しても通常は問題ない」「不正から守るために役立つ」「不具合が起きても対処できる」という三点について確証を得る作業が行われました。 三つの確証の観点での記述が2章各節にあります。 導入の判断のために活用ください。

1.2 インターネットにおける経路情報

インターネットは複数のネットワークが相互接続された形で運用されています。 各々のネットワークはIPアドレスを宛先とする通信データをどこに送るのかを決定するために、 BGPと呼ばれるプロトコルを使って経路情報を相互に交換しています。 経路情報の正しさはインターネットを支える重要な要素であると言えます。

1.3 不正な経路情報のリスクや損失

不正な経路情報とは、 インターネットにおける本来の経路とは異なるような、 IPパケットの伝搬経路を誘発する経路情報を意味します。 正常な通信が行えない他、 通信データが誤った宛先に到達することがあります。 この性質を利用して大規模な通信傍受や犯罪が行われることもあります。 不正な経路情報が発生する原因として、 ネットワーク機器であるルータにおける設定ミスや故意に誤った経路情報をルータに設定することが挙げられます。

インターネットに接続するユーザや組織にとって、 不正な経路情報は、経済活動の機会損失だけでなく、 資産を第三者に奪われることにつながる恐れのあるものであり、 国際的な範囲において、 特定のネットワークへの到達性を損なわせられるようなリスクもあります。 また、 RPKIを使った対策技術があるにもかかわらず対策を取っていないことが、 不正な経路情報の影響を受けた後に発覚すると組織における十分な対策が取られていなかった点が第三者によって指摘される可能性があります。

インターネットが国民生活や国際社会において重要な位置を占めるようになった現代においては、 不正な経路情報による通信の不具合や犯罪等が起きることを防止することが重要です。 またこれはインターネット全体へのセキュリティにも寄与します。 IPアドレスの分配を受けているすべての組織やインターネットに接続するASを運用している組織は、 適切な対策を取ることが必要です。

1.4 対策技術 ― RPKIとROA、ROV

RPKI (Resource Public Key Infrastructure)はIPアドレスなどの番号資源の分配を証明する証明書、 リソース証明書の発行に使われる公開鍵認証基盤です。 これは不正な経路情報を判別するために「正しい経路情報」を示すデータ、 ROA (Route Origin Authorization)の作成に使われます。

ROAはIPアドレスの分配を受けた者が作成するもので、 経路広告するIPアドレスのプレフィックス(以下、プレフィックスと呼ぶ)と最大プレフィックス長、 経路広告する組織(AS番号)を指定します。 ROAはリソース証明書で検証可能な電子署名が施されています。

ROV (Route Origin Validation)は、ROAを用いて、 経路情報が正しいかどうかを判定することです。 ROVの導入にはいくつかの方式が挙げられます。

1.5 実施事項

■JPNICやAPNICからIPアドレスの分配を受けているすべての組織や個人

○ROAを作成します(必須事項)。 管理下にあるIPアドレスに関するROAを必ず作成してください。 これを行わないとそのIPアドレスに関するROVを行うことができず、 インターネットにおいて不正な経路情報への対策を取ることができません。 ⇒ 「2.1. ROA/IPアドレスの分配を受けた者の実施事項」を参照してください。 ○ROAが実際の経路情報と一致するように保ちます(必須事項)。 作成したROAと経路情報が一致するように保ってください。 これを行わないと正常な経路情報であるにもかかわらず、 ROVを行っているルータにおいて不正な経路情報と判定されてしまうことがあります。 ⇒ 「2.1. ROA/IPアドレスの分配を受けた者の実施事項」を参照してください。

■インターネットに接続するASを運用している組織や個人

○ROVを行う等の処置を行います(推奨事項)。 これによってROAに基づいた不正な経路情報への対策を行うことができるようになります。 処置の方式として以下の三つが挙げられます。 適するものを特定して、それを実施することが推奨されます。 方式A ROAキャッシュサーバを自組織で運用してROVを実施する。 方式B IXP等で提供されるROAキャッシュサーバを利用してROVを実施する。 方式C ROVが行われているトランジット経路を利用する。 ※これ以外の方式の採用を妨げるものではありません。 ⇒ 詳しくは「2.2. ROV/AS運用をしている者の実施事項」を参照してください。

推奨される事項を実施している組織および個人は、 不正な経路情報への対策を取っているとしてその旨を公に示すことができます。 またその実施に関して民間において認定され、今後、 各種調達においてその認定状況が参照されることがあります。 確実な実施のためには、 試験から運用に至るまでに時間を要することがあります。

以降では、推奨される事項の実施に資する技術的情報を示します。

2. 技術的情報

この章ではRPKIを用いた不正経路対策の技術的情報について述べます。

本節では、現時点での技術的情報をまとめますが、 今後も最新の技術的な情報を参照できるようにするために本章の内容を含む技術情報が掲載されるサイトを以下に示します。 情報の正確性や最新性はサイトの運営者に寄りますが、 RPKIを用いた不正経路対策は多岐にわたる技術であるため、 読者および有識者は国内における最新技術情報の共有に協力することが望まれます。

当センターにおけるRPKIに関する情報をまとめたサイトは以下の通りです。

• リソースPKI (RPKI)

2.1 ROA/IPアドレスの分配を受けた者の実施事項

本節ではROAの作成について述べます。 主にIPアドレスの分配を受けている組織の管理者および技術者に向けた情報です。

2.1.1 ROAとは

ROAとはIPアドレスの分配を受けた者が、 そのIPアドレスの範囲に含まれる経路情報をAS運用者から広告することを認めた(認可した)ことを示すものです。 IRからIPアドレスの分配を受けた組織は、 BGPによって広告される経路情報とその最大プレフィックス長、 および広告元になるASの組を持つROAを作成します。 ROAを間違って作成すると、 インターネットの接続性に直ちに影響を及ぼす可能性があるため、 作成は慎重に実施する必要があります。

• インターネット用語1分解説～ROAとは～ - JPNIC

2.1.2 不正経路とIPアドレスに関する考え方

IPアドレスの分配を受けた者がROAを作成することで経路情報の発信元の検証(ROV)を行うことが可能になり、 不正経路への対策につながります。

ここでは次の図に示すA〜Eについて説明します。

2.1.3 ROAの作成と運用管理

ROAを作成できるのはIPアドレスの分配を受けている組織や個人です。 ROAはIPアドレスの分配元である各IRが提供するシステムを利用して作成します。 JPNICからIPアドレスの分配を受けている場合には、 JPNICのRPKIシステムを使ってROAを作成します。 利用方法の詳細は下記のページを参照してください。

• RPKI - JPNIC
• ROAの作成と管理の方法 - JPNIC

2.1.4 BGP経路とROAを一致させる手順

ROAの作成と維持にあたり、 ROVが行われるルータにおいてBGP経路がInvalidと判定されることを避けるためには以下の手順が考えられます。

1. BGP経路を変更する業務フローの中にROAの状態を確認する項目を入れておきます。 ROAの状態を確認するには次の2を参照してください。
2. ROAの状態が確認できるインターフェース(IRの提供しているWebサイト等)にアクセスし、 作成したROAに関連する経路情報がValidになっていることを複数のサイトで確認します。 サイトの例を以下に示します。
   • Routinaror - RIPE NCC
   • NetOX - APNIC

2.1.5 重要事項：ROAの導入に関わる三つの確認

ROAの作成にあたり、次に示す三点の確認により判断を行います。 ROAの作成において下記を留意せずに作成すると、 BGP経路との差異ができる等により、 そのBGP経路が国際的にInvalidと判定されてしまうリスクがあります。 三点の確認を通じてROAの導入がリスクとならないように判断することが重要です。

考え方	ROAに関する確認事項	実施事項
導入しても通常は問題ない。	〇 ROAを作成しても通常は問題ない。	〇 BGP経路を変更したときには必ずROAが一致するような運用フローにする。
導入することで不正から守られる。	〇 ROAを作成することでROVされた際に不正なBGP経路から守られる状態である。	〇 ROA作成もしくは修正を行ったときに、国際的にいくつかのサイト(下記)でROVの結果を確認する。
導入による不具合が起きても対処できる。	〇 ROAとBGP経路に不一致が起きてもROAを修正してValidな状態に戻すことができる。	〇 BGP経路に対するROV結果を定期的に確認および監視する。 〇 適切な人員がROAを修正できる状態であることを確認する。

2.1.6 例外的な処置

ROAの導入に関する例外的な処置について以下に示します。

• 隣接組織間でトラヒックコントロールなどのためにROAで指定されているものより長いプレフィックスの経路情報の交換を要する場合は、 適切な配慮を行なう必要があります。
• ROV導入時に、 組織内部でプライベートASを利用している等で網内にROAで指定されている以外のオリジンASの経路情報がある場合は、 意図的にROVの設定を適用しない、 BGPルータにおける経路フィルタで除外する、 ROAキャッシュサーバにおいてSLURMを設定する等、 別途対処を検討する必要があります。

■運用上の注意

指定する最大プレフィックス長は、 実際に広告する経路情報のプレフィックス長と一致させておきます。 プレフィックス長が/19なのにもかかわらず/24まで許可した場合、 サブプレフィックス攻撃と呼ばれる方法によって、 より長いプレフィックス長を持つ不正な経路情報の影響を受ける可能性があります。 ただ、最大プレフィックス長の指定が禁止されているわけではなく最小限にすることが推奨されています[RFC9319]。

• サブプレフィックス攻撃とは攻撃者のBGPルータがROAに記載されたオリジンASを使って不正な経路情報を広告するものです。 運用上の条件が限定されている他、 これまでの報告例はまだありません。

経路情報が変更になる、 もしくはオリジンASが変更になる際には、 ROAの変更が必要になります。 経路広告する数日前にROAを適切に追加作成し、 経路広告後に古い情報を削除します。

2.2 ROV/AS運用をしている者の実施事項

この章ではRPKIを用いた不正経路対策について、 ROVの実施について述べます。 主にAS運用を行なっている組織の管理者および技術者に向けた情報です。

2.2.1 不正経路への対策と考え方とROV

ROAによって正しい経路広告のAS番号、IPアドレス、 プレフィックス長は把握できますが、一方で、 不正経路の受信や広告を防止するには後述するROVが必要です。 ROAの情報をルータが参照し、 ルータで受信する経路情報が正当なものか、 そうでないのかを判定し、 採用するのかを経路制御ポリシにより判定します。 このROAの情報を参照して経路情報が正しいかどうかを判断する仕組みをROVと呼びます。

電子署名されているROA情報の検証をルータ自身で行うとそのルータに負荷がかかるため、 ROAの署名検証は「ROAキャッシュサーバ」を設置して行われます。 検証済のROAの内容(VRP (Validated ROA Payload)と呼ぶ)が一時的に保持されたものをROAキャッシュと呼びます。 ルータはこのキャッシュを参照して当該経路情報の正当性を判断します。 ROAキャッシュサーバとルータ間はRPKI-RTRプロトコル(RPKI to Router Protocol)で接続が行われます。

なお、自組織内の全てのルータでROVを行なう必要はなく、 基本的には不正経路の流入もしくは流出を防止したい箇所(例えばトランジットを受ける、 他ASとBGP Peerを張る)のルータでのみROVを有効化すればよいでしょう。

• インターネット用語1分解説～ROV (Route Origin Validation)とは～ - JPNIC

ROVでは、ROAに一致する経路情報(Valid)、 ROAが作成されていない経路情報(Not foundあるいはUnknown、以下Not foundと記述する)、 作成されているROAと矛盾する経路情報(Invalid)という状態が存在します。 これらの取り扱いをどうするかを各組織のポリシによって決めることがROVの鍵となります。

運用上の注意

• ROAに一致する経路情報のみを採用するようなポリシにすると、 ROAによる分配済みIPアドレスに対するカバー率が100%に至らない現状では、 ROAが作成されていないIPアドレスの経路情報をも不採用にしてしまう設定になりますので注意が必要です。

2.2.2 ROVの導入に関わるコスト

ROVを実施する上で、ROV実施前と比べ、 次のようなコスト増が挙げられます。 これらを踏まえつつROV導入の判断が必要となります。

• ROA作成依頼のコスト
• ROV可能なルータの設備コストと運用コスト
• CPU負荷やメモリ使用量増
  ROV対応ルータであれば特に問題となる増加量ではありませんが、 RPKI非対応ルータからのリプレースが必要な場合や、 現時点でCPU利用率がかなり高いようなルータについては考慮が必要です。

2.2.3 ROAキャッシュサーバ・ROVの所在

ROVを導入するにあたり、 大きくわけて本節で挙げる3方式が考えられます。 それぞれ、各組織の運用技術や体制、 提供するネットワークサービスと顧客への影響度によってどの方式を選択するかを検討します。

重要なネットワークサービスを提供する組織はインターネットを介した公開ROAキャッシュサーバを利用することにはリスクがあります。 例えば、 ネットワーク障害によってルータがROAキャッシュサーバを参照できなくなった場合についてのリスクがあります。 公開されている組織外のROAキャッシュサーバを利用した場合、 キャッシュサーバのROAキャッシュが改竄されるとこれを検知することは難しく、 当該パブリックROAキャッシュサーバを利用している全ての利用者に影響が及ぶことが考えられます。 また、VRPが平文であるため、 経路上での改竄による影響も考えられます。 ROAキャッシュサーバが自組織における運用が行われるものではない場合、 その利用によって、 ROVの結果が適用している者の意図しないものになる可能性が高まります。 従って、 自社網内などの閉じた環境でROAキャッシュサーバを構築することが望ましいと考えられます。

また、 ROAキャッシュサーバはその冗長性と安全性について考慮が必要となります。 ROAキャッシュサーバは、 組織外部からの接続性は必要ないため、 組織内に外部からの接続性を遮断したキャッシュサーバを複数(ハードウェアおよびROAキャッシュソフトウェア)設置することにより、 上記のリスクを低減できます。

以下ではROAキャッシュサーバの利用方式を示します。

[導入方式A] ROAキャッシュサーバを自組織で構築してROVを実施する方式

構成を以下に示します。

ROAキャッシュサーバを自組織内に複数構築しルータで参照してROVを実施する方式です。

特徴

• ROAキャッシュサーバを自組織で構築運用するため、 ルータとROAキャッシュ間が自組織内に限ることができ、 ルータ起動時に網内の経路情報のみで素早くRTRの接続を確立することができます。 また前述のリスク低減が図れますが、 導入方式BのIX等で提供するROAキャッシュサーバの利用よりも運用コストは高いと言えます。 また、網内で完結するため、 保守等で網外のキャッシュサーバへの到達性が失われる場合でも問題なく利用できます。 ルータとROAキャッシュの距離が近い＝経由箇所が少ないことから耐障害性にも優れます。
• SLURMによる例外処理をROAキャッシュサーバ側で行うことができるため、 多くのルータでROVを行う必要がある場合などではルータ設定の省力化が図れる場合があります。

[導入方式B] IX等で提供するROAキャッシュサーバを利用してROVを実施する方式

構成を以下に示します。

ROAキャッシュサーバを自社で構築せず、 IX等自組織と直接接続性のある事業者が構築提供するROAキャッシュサーバをルータで参照してROVする方式です。

特徴

• 自組織内にROAキャッシュサーバがある方式Aと比べるとROAキャッシュサーバとルータ間で経由するネットワークが増えるため、 耐障害性は下がりますが運用コストが抑えられます。 セキュリティ的にもVRPとルータ間のやりとりはIXや事業者内のネットワークを介するにとどまるため、 インターネット上のパブリックROAキャッシュサーバを利用する場合より好ましいです。

[導入方式C] ROVが行われているトランジット経路を利用する方式

構成を以下に示します。

上記はROVを実施しているトランジットからのみ経路情報を受信する場合の図です。 ピア接続がある場合には、 そこから流入してくる経路情報に対してROVを行うことが考えられます。

特徴

• ROA作成を実施する必要はありますが、 ROAに関わるコスト(ROAキャッシュサーバやROV可能なルータの導入、 運用)を抑えることができます。
• ROVによる経路制御ポリシについてトランジットプロバイダに依存することになります。 例えば、トランジットのミスを自組織で防ぐことはできません。

[その他の方式] パブリックキャッシュサーバを利用する方式

公開ROAキャッシュサーバ(パブリックキャッシュサーバ)を利用してROVを行う方式です。 構成を以下に示します。

この方式は以下の特徴に述べたように導入しやすいというメリットがありますが、 パブリッシュキャッシュサーバへの到達性やRTRの完全性が保証されないため、 止むを得ない場合以外の利用は推奨されません。

特徴

• 自身でROAキャッシュサーバを用意する必要がなく、 キャッシュサーバ導入・運用コストはかかりません。
• パブリックキャッシュサーバを利用する場合には以下のような点に注意する必要があります。
• パブリックキャッシュサーバへの到達性はサーバの問題や途中経路の問題などで保証はされません。
• RTRは暗号化されていないため、 通信経路上で改竄される可能性があります。
• 通信経路上で偽のROAキャッシュサーバに誘導される可能性があります。
• パブリックキャッシュサーバはインターネット公開されているため、 攻撃の対象になるリスクがあり、 侵入され改竄される可能性があります。
• 同様にDDoSを受けるなどにより利用できなくなる可能性があります。

これまでに述べた導入方式の比較表を以下に示します。

方式	セキュリティ	耐障害性	SLURM	設備コスト	構築／運用コスト
A 自網内に構築	◯	◯	◯	高	高
B IX等利用	△	△	×	低	低
C ROV済みトランジット	△	△	×	無	無
他 ROAパブリックサーバ	×	×	×	低	低

2.2.4 ROAキャッシュサーバの構築

オープンソースソフトウェア(OSS)でいくつかROAキャッシュサーバの開発がされています。 現状ではこれらを選択するかもしくは、自社開発を行います。 OSSについては開発が終了しているものもあるので、 注意が必要です。 代表的なROAキャッシュサーバを以下に示します。

• FORT
• Routinator3000
• rpki-client
  VRPを生成する機能は有しますが、 RTRサーバの機能を持っていないため別途準備する必要があります。 RTRサーバ機能の実装としてStayRTR、GoRTRがあります。

2.2.5 ルータにおけるROV設定

前述の方式(A～C)についてAもしくはBを採用することを決定後のルータ側ROV設定について示します。 なお、その他の(パブリックキャッシュサーバを利用する)方式を止むを得ず採用する場合も同様の設定を行います。

ROVを導入する箇所の検討

先に述べたように自組織内全てのルータでROVする必要はありません。 主に次のような箇所に設置されるルータでの実施を検討します。 それぞれについての必要可否は、 相手組織のリスクを自組織が受容できるのか、 そのリスクが自組織でサービス提供する相手に対しての影響度合いを鑑みて検討します。

• トランジット事業者と接続している箇所(トランジット接続)
• IXやプライベートピアなど他ASと接続している箇所(ピア接続)
• 顧客とBGP接続している場合は、顧客と接続している箇所(カスタマー接続)

ROVをどのピアに適用するかの検討

ASのすべてのBGPピアにおいてROVを設定することが理想的です。 しかしながら、一度にすべてにおいて導入することは、 運用者にとって不安がありリスクを伴う作業になる可能性があります。 従って、 多くのBGPピアがあるASにおいては段階的なROVの導入が行われ、 その導入期間も長くなることが考えられます。 段階的に導入する場合に、 不正経路への対策という意味で効果が高いと考えられる導入の順番とその考え方を以下に示します。

はじめにトランジット接続にROVを導入することが考えられます。 これは国際的な多くの経路情報を受信することから、 不正な経路情報が入り込む可能性が高いと考えられるためです。 次にピア接続に導入します。 不正な経路情報を受信する可能性はトランジット接続よりは低く、 次に述べるカスタマー接続よりも高いと考えられます。 最後にカスタマー接続に導入します。

トランジット接続の先のASが既にROVを導入している場合には、 その接続におけるROVの導入について優先順位を下げることが考えられます。 ただし不正経路への対策として他ASが行っているROVに頼ることになりますので、 その点に留意して導入判断を行うことになります。 またカスタマー接続において、 接続先のASから受信する経路情報に対するプレフィックス・フィルターやASパス・フィルターを導入している場合、 ROVの導入を見送ることも考えられます。 研究目的、経路情報の異常を検知するためのモニタリング、 もしくは不正経路によって被害が発生しないようなケースでもROVの導入を見送ることが考えられます。

2.2.6 ROVによる経路制御の詳細

BGPルータにおいてROVを行うことでBGPを通じて受信した経路情報の一つ一つに対して次に述べる判定を行うことができます。

Valid

当該の経路情報はROAに記載されたプレフィックスおよびオリジンASと一致し、有効である。

Invalid

当該の経路情報はROAに記載されたプレフィックス・最大プレフィックス長およびオリジンASと一致しておらず、有効ではない。

Not Found

当該の経路情報を内包するプレフィックスが記載されたROAは存在しない。ROAが作成されていない状態。

これらの判定を行うか否かは、 経路情報を受信するBGPピアごとに設定します。 また判定を行った結果をどのように扱うかを設定します。 ここでいう扱いとはIPパケットの経路制御のために使われる経路表(FIB等)に入れるかどうか、 もしくはlocal-preference値等を使って優先するかどうかが挙げられます。 一部の機器では明示的に設定を行わなくても既定でInvalidと判定された経路情報を経路表に入れないものがあります。 またBGPの拡張コミュニティ属性を用いて、 ROV処理を行っていない他のBGPルータに判定結果を伝えることができるものがあります。 運用するBGPルータがこれらのうち、 どのような機能を有しているかを確認します。

ROVの判定結果を受けてどのように経路制御を行うかを検討します。 Validと判定された経路情報を採用し、 Invalidと判定された経路情報を不採用にする例を以下に示します。 Not Foundと判定された経路情報は、 いわば従来のインターネットの状態であり、 この経路情報を採用しない設定を行っても問題がないことを、 実施する前に確認する必要があります。 特にROAキャッシュサーバとの接続(RTR接続)が影響を受けないように留意する必要があります。

ROVに関する典型的な例を以下に示します。

(1)	Valid	:許可する
(2)	Invalid	:不許可とする
(3)	Not found	:許可する

これらの処理はBGPの接続先ごとに行われるため、 例えばトランジットや顧客からの経路情報に対して適用しても、 ROVを適用していないピア接続先からの経路情報が意図せずに適用されてしまうことがあります。 ROVは不正な経路情報を受信する可能性のあるすべての接続先に対して適用することが望ましいと言えます。

2.2.7 重要事項：ROVの導入に関わる三つの確認

ROVの適用にあたり、 次に示す三点の確認を行ってからその判断を行います。 ROVの導入にあたり、下記を留意せずに適用すると、 ASの運用上、意図しない結果になることがあります。 三点の確認を通じてROVの導入がリスクにならないように判断することが重要です。

考え方	ROVに関する確認事項	実施事項
導入しても通常は問題ない。	〇 ROVを適用しても通常は問題ない。	〇 Invalidな経路情報でも採用する設定のROVを適用し、BGPルータの負荷やメモリ等の面で正常に稼働することを確認する。 〇 ROVを適用することで不採用となる経路情報に顧客のIPアドレス等、使われるものが含まれていないことを確認する。
導入することで不正から守られる。	〇 ROVを行うことで不正な経路情報から守られる。	〇 Invalidと判定される経路情報を観察して意図通りに採用されないことを確認する。(Invalidとなる経路情報にRouting Beaconがある。情報源を以下に示す。)
導入による不具合が起きても対処できる。	〇 特定のROAが作成者の意図と異なる判定をされてしまう状態が起きても、その採用不採用を制御するなど、対処できる。	〇 ROAキャッシュサーバにおけるROVに関する例外処理SLURM等の設定を行って、Invalidと判定される経路情報を経路表に採用できるようにする。 〇 BGPルータにおいて特定の経路情報については採用・不採用を制御できることを確認する。

■Invalidとなる経路情報の情報

• RIPE Atlas docs | Routing Beacons | Docs

2.2.8 ROVの設定例

本節ではROV設定のシナリオについて述べたあと、そのシナリオに沿った各ベンダの設定例を示します。

■ROV設定のシナリオ

次の要領でROVの設定を行います。 ROVを実施するまでの手順としては1、2のみです。 この他にCPUやメモリの状態をみたり、 意図しないInvalid判定に対処したりする手順を「ケースごとの手順」として記述します。

1. ROAキャッシュサーバを指定し、VRPを受信できることを確認します。
2. ROVの判定結果に従って経路情報を扱うルールを設定します。
3. ケースごとの手順 ― ROV設定前後のCPUやメモリの消費状況をみる。
4. ケースごとの手順 ― ROVの設定を解除して元に戻す。
5. ケースごとの手順 ― ルータを再起動させたときの動作を確認する。
6. ケースごとの手順 ― ROAキャッシュサーバへの再接続時間を確認する。
7. ケースごとの手順 ― 意図しないInvalidに対処する。

■ルータごとの設定例

設定方法が分かっているルータの設定例を、 本ガイドラインのWebサイトにおいて別紙として示します。

1. Arista EOS
2. Cisco IOS-XE
3. Cisco IOS-XR
4. Juniper Junos
5. NOKIA SR OS

2.2.9 運用上の注意と懸念点

[1] ROAキャッシュサーバの構築・維持

現在、入手できるROAキャッシュサーバの実装はOSSによるもののみとなっています。 ソースコードが無償公開されているため利用可能ではありますが、 自組織で構築運用するにあたり問題が生じ、これに対処する場合には、 ソースコードを読んで実装を理解し、 トラブルシューティングを実施する必要があります。

[2] 監視

ROAキャッシュサーバの正常性確認のためには以下の監視を行うことが考えられます。

1. ROAキャッシュサーバの死活監視、プロセス監視、 リソース監視などサーバ自体の監視 ※なお、RTRセッションが落ちても通信影響へは直結しない。
2. ROAキャッシュの転送プロトコル(rsyncやRRDPなど)の失敗検出および回復
3. ROAキャッシュの中身についても可能であれば検証する。 複数のROAキャッシュのデータを1日1回比較し、大幅な変更が発生した場合通知する等

[3] ROAキャッシュサーバと通信できない状態が発生した場合の対応

一般的にはRTRセッションが切断された場合でも直ちに通信に影響することはないが、 通信できない状態が、設定されたhold timeを超える可能性がある場合には以下の対応をする必要がある。

1. BGP neighbor毎もしくはルータごとのROVの停止、 もしくはROAキャッシュサーバにおけるSLURMを利用したVRP結果の変更等、 Invalid / Not Foundとなる経路情報を破棄しないようにする。
   (Invalid / Not Foundとなる経路情報を不許可・破棄といった設定をしている場合)

3. ROA/ROV以外の不正経路対策

3.1 BGPにおけるセキュリティの要素と考え方

ROVは不正経路対策として有効な手段ですが、 全ての場合において不正経路の対策ができるわけではありません。 ROVは特定のアドレスブロックがどのASから広告されるかというオリジン検証を行うための技術であるため、 BGPの経路情報におけるASパス属性へ不正なAS番号が挿入された場合に対処することはできません。

BGPルータにおいては、他にも考慮すべきルーティングセキュリティ事項があります。 参考になるものとして MANRS (Mutually Agreed Norms for Routing Security) があります。 MANRSで設けられたセキュリティ事項を満たし、 確認することによりルーティングにおけるセキュリティを高めることができます。

3.2 ASパス検証の今後と運用について

BGPの経路情報に含まれるASパス属性(AS PATH)が正しいかを検証するASパス検証という仕組みがあり、 ASPA (Autonomous System Provider Authorization)という技術が検討されています。 これをROVと組み合わせることでよりセキュアなBGP運用が可能となります。

ROAとROVは標準化と開発が進み国際的に導入が進んでいる段階です。 一方、ASパス検証は有効性の検証や標準化が進みつつありますが、開発は途上にあって、 国際的な動向を把握し、 今後の適切な導入がROVと同様に望ましい位置づけにあると考えられます。

ASPAを使ったASパス検証を行うためには、 AS番号の割り当てを受けているIRを通じてASPAオブジェクトを作成する必要が出てくるでしょう。

4. 用語集

PKI (Public Key Infrastructure＝公開鍵暗号基盤)

公開鍵暗号方式による暗号通信や電子署名に用いる、 公開鍵とその公開鍵の持ち主の対応関係を保証するための仕組み。

AS (Autonomous System＝自律システム)

インターネットにおいては同一ポリシに基づいたIPネットワークの集合を指す。 本書ではAS番号を割り当てられた組織が管理するネットワークを指す。

BGP (Border Gateway Protocol)

AS間で経路情報を交換するためのプロトコル[RFC4271]。

IR (Internet Registry)

インターネットで使用される番号資源(IPアドレス、AS番号)を管理している組織。 五つの地域IR (ARIN、RIPE NCC、APNIC、LACNIC、AFRINIC)がそれぞれの地域に対してサービスを行なっている。 下部組織として各国のNIR (National Internet Registry、日本においてはJPNIC)が存在する。

SLURM (Simplified Local Internet Number Resource Management with the RPKI)

ROAキャッシュサーバに例外を記述する方式[RFC 8416]

5. おわりに

本ガイドラインは、「1.ガイドラインの趣旨 ■本ガイドラインについて」に記載の通り、 令和4年度総務省事業「ISPにおけるネットワークセキュリティ技術の導入に関する調査」及び令和５年度総務省事業「ISPにおけるネットワークセキュリティ技術の導入及び普及促進に関する調査」の結果として同実証事業へ参加した実証事業者の意見・有識者検討会メンバーの意見を基に案が作成されました。

その後、総務省から当センターがガイドライン案を引き受け、 「ガイドライン」として公開するにあたり、総務省における実証事業時に有識者検討会メンバーとして活躍された次のメンバーに、 引き続き当センターの「RPKIガイドライン専門家チーム」メンバーとしてもご尽力いただき、レビューと改訂を行いました。 そしてここに正式なガイドラインとして公開するに至りました。

• BBIX株式会社 芦田宏之氏
• 大阪大学 猪俣敦夫氏
• 長崎県立大学 岡田雅之氏
• ノキアソリューションズネットワークス合同会社 小川怜氏
• ジュニパーネットワークス株式会社 清水一貴氏
• 株式会社まほろば工房 高田寛氏
• アリスタネットワークスジャパン合同会社 土屋師子生氏
• 慶應義塾大学 中村修氏
• シスコシステムズ合同会社 服部亜希子氏
• 株式会社インターネットイニシアティブ 松崎吉伸氏
• 株式会社まほろば工房 三ツ木絹子氏
• 株式会社インターネットイニシアティブ 蓬田裕一氏
• NTTコミュニケーションズ株式会社 渡辺英一郎氏
• ジュニパーネットワークス株式会社 渡邊貴之氏

本ガイドラインに関するご意見・お問い合わせは、以下のあて先に電子メールにてお願いいたします。
　一般社団法人日本ネットワークインフォメーションセンター(JPNIC)
　RPKI担当：rpki-query@nic.ad.jp