Zenn
🔥

RFC 6483: リソース証明書公開鍵基盤(PKI)と経路オリジン認証(ROA)を使用した経路発信の検証

2024/02/21に公開
Security
RFC
bgp
tech

要旨

本文書は、ボーダー・ゲートウェイ・プロトコルで広告される経路の発信元を検証するためのリソース公開鍵基盤のアプリケーションの文脈の観点から、経路オリジン認可(ROA)のセマンティクスを定義する。

本文書の位置付け

本文書はインターネット標準化過程の仕様書ではない。情報提供を目的として公開する。

この文書はInternet Engineering Task Force (IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。公開レビューを受けており、Internet Engineering Steering Group (IESG)によって公開が承認されている。インターネット標準の詳細については、RFC 5741のセクション2を参照のこと。

本文書の現在のステータス、正誤表、および文書に対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc6483 で入手できる。

著作権表示

Copyright (c) 2012 IETFトラストおよび文書の著者として特定された人物。無断転載を禁じる。

本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。文書から抽出されたコード・コンポーネントには、トラスト法的条項のセクション4.eに記載されている簡易BSDライセンスのテキストを含まなければならず、簡易BSDライセンスに記載されているように保証なしで提供する。

1. はじめに

本文書は、ボーダー・ゲートウェイ・プロトコル(BGP)[RFC4271]で広告される経路の発信元を検証するためのリソース公開鍵基盤(RPKI)[RFC6480]のアプリケーションの文脈という観点から、経路オリジン認可(ROA)のセマンティクスを定義する。

RPKIは、インターネット番号リソースの割り当て構造に沿ったリソース証明書の階層に基づいている。リソース証明書は、PKIXプロファイル[RFC5280]とIPアドレスとAS識別子の拡張[RFC3779]に準拠するX.509証明書である。リソース証明書は、IPアドレス・ブロックと自律システム(AS)番号のリストを証明書のサブジェクトに結び付ける発行者の行為を記述するものである。サブジェクトの秘密鍵とリソース証明書に含まれる公開鍵との一意のアソシエーションによって識別される。RPKIは、現在の各リソース証明書が現在のリソースの割り振りまたは割り当てに一致するような構造になっている。これについては[RFC6480]で詳しく説明されている。

ROAは、アドレスをAS番号に結び付けるデジタル署名済みオブジェクトであり、アドレス保有者によって署名される。ROAとは、IPアドレス・ブロックの保有者がドメイン間ルーティング環境において、特定のASに経路発信が認可されていることを検証する手段を提供する。ROAは[RFC6482]に記載されている。ROAは、ドメイン間ルーティングにセキュリティを追加するための要件に適合することを目的としている。

本文書では、ROAの意味論的な解釈、特に経路の発信元に関連するドメイン間ルーティングでの活用、およびROAで表現される権限の意図する範囲に関連して説明する。

2. 経路のROA検証結果

「経路」(route)とは、[RFC4271]のセクション1.1で定義されているように、IPアドレス・プレフィックスで記述される宛先セットと、その宛先へのパスの属性セットを関連付ける情報の単位である。

経路の「オリジンAS」は以下のように定義される。AS_PATHの最後のパス・セグメントがAS_SEQUENCEタイプの場合、オリジンASはシーケンスの最初の要素である(つまり、プロトコル・メッセージ内のオクテットの位置に対して右端の位置にあるAS)。AS_PATHに経路が集約であることを示すAS_SETタイプのパス・セグメントが含まれている場合、オリジンASを決定することはできない。ルーティング環境の文脈における経路の検証に関しては、アドレス・プレフィックス値とオリジンASがROA検証操作で使用される。

⚠️ AS_PATH属性について

cfig1

「最後のパス・セグメント」と書かれている点について: 通常、AS_PATH属性は、AS_SEQUENCEタイプのパス・セグメントのみとなるので、1つのパス・セグメントしか存在しない。ところが、AS_SETタイプのパス・セグメントがあると複数パス・セグメントとなる。いわば、最後のパス・セグメントというのは、オリジンASを含むパス・セグメントを指すことになる。例えば、「100000 300 {150,200} 100 {50,20} 10」のようなAS_PATHの場合、以下の通り、5つのパス・セグメントで構成される。

cfig2

下図は試験環境で、擬似的に上記ASパスの経路を広告した際のBGP UPDATEメッセージのパケット(Wireshark)。

cfig2

ここでは、経路検証を実行するときに、リライング・パーティー(RP)が有効なROAの完全セットを持つローカル・キャッシュにアクセスできると仮定する。(有効なROAとは、[RFC6482]に記載されているように、構文的に正しいと判断され、RPKIで検証できる署名を使用して署名されたROAと定義される。) RPは、検証結果を決定するために、経路を1つ以上の有効な候補ROAと照合する必要がある、その検証結果は、経路に対して実行する適切なローカル・アクションを決定するために使用できる。

この経路発信検証のアプローチは、「肯定的」証明(アテステーション)の一般的なモデルを使用している。RPKIフレームワークで検証できない経路は従来、RPによって「無効」と解釈されるという推論に関連付けられている。しかし、RPKIの構造上、有効な広告されたアドレス・プレフィックスの一部のみが関連する公開ROAを持つような、ROAが部分的に採用される環境に対応することを考慮に入れると、この肯定的証明モデルを多少修正する必要がある。経路検証という文脈では、一旦ROAにアドレス・プレフィックスが記述されると、このROAは、ROAに記述されたアドレス・プレフィックスよりMore Specificなアドレス・プレフィックスすべてを包含すると見なす。したがって、有効なROAで記述された経路よりもMore Specificなアドレス・プレフィックスのいかなる経路も、それ自体に一致する有効なROAを持たない経路は「無効」と見なすことができる。しかし、どのROAによっても完全に記述されないアドレス・プレフィックスに対する経路は(つまり、アドレス・プレフィックスが有効なROAに記述されたアドレス・プレフィックスの集約経路である可能性のある経路、または有効なROAと交差しないアドレス・プレフィックスを持つ経路)、部分展開シナリオにおいて確実に「無効」と分類できない。そのようなアドレス・プレフィックスの経路は「不明」という検証結果になる。

この検証手順の結果、経路の抽象属性、つまり「有効性状態」[BGP-PFX]を決定することができる。この有効性状態の決定に単一のROAを使用する場合、上で定義したプレフィックスとオリジンASを持つ経路の有効性状態を次の表にまとめることができる。

fig1
経路の有効性状態

有効なROAのコレクションがある環境では、いずれかのROAが「有効」な結果を提供する場合、経路の有効性状態は「有効」(valid)とみなされる。1つ(または複数)のROAが「無効」(invalid)の結果を提供し、どのROAも「有効」(valid)の結果を提供しない場合、有効性状態は「無効」(invalid)とみなされる。有効なROAが「有効」(valid)または「無効」(invalid)の有効性状態の結果を生成できない場合、その有効性状態は「不明」(unknown)(または同義語として「見当たらない」(not found)[BGP-PFX])とみなされる。

経路の有効性状態は次の手順で定義される。

  1. ROAIPAddress値が経路のアドレス・プレフィックスと一致するか、そのアドレス・プレフィックスをカバーする集約経路である有効なROAをすべて選択する。この選択が、「候補ROA」セットを形成する。

  2. 候補ROAセットが空の場合、「不明」(または、[BGP-PFX]で使用される同義語の「見当たらない」)という結果で手順は停止する。

  3. 経路のオリジンASが確定でき、候補ROAセットのいずれかが、経路のオリジンASと一致するasID値を持ち、経路のアドレス・プレフィックスがROA内のROAIPAddressと一致する場合(ここで「一致」とは、経路のアドレスがROAIPAddressと正確に一致するか、ROAIPAddressがmaxLength要素を含み、経路のアドレス・プレフィックスがROAIPAddressのMore Specificなプレフィックスであり、経路のアドレス・プレフィックス長の値がROAIPAddressのmaxLength値以下である場合)、この手順は「有効」という結果で停止する。

  4. そうでなければ、この手順は「無効」という結果で停止する。

3. 検証結果を経路選択に適用する

BGP[RFC4271]を用いたドメイン間ルーティングの抽象的な動作モデルのフレームワークの中で、ルーティング・ピアから受信したプレフィックス・アナウンスは、他のルーティング・ピアから受信したこのプレフィックスに対するすべてのアナウンスと比較され、この候補セットから「最適な」経路を選択するために経路選択手順が用いられる。

セクション2で説明されている、「有効」、「無効」、「不明」という有効性状態は、ローカル優先度の決定の一環として使用できる。この場合、ローカル優先順位は以下のようになる。

「有効」は、

「不明」よりも優先され、

「無効」よりも優先される

有効性状態が「不明」の経路を処理する際にルーティング・エンティティが取るべき行動は、ローカル・ルーティング・ポリシーの問題である。パブリック・インターネットのような異種環境でROAを部分的に使用することを考慮すると、ローカル・ポリシーの設定によって、「不明」という有効性状態の結果が、ローカルな最善経路としての更なる検討から、経路を完全に拒否する十分な根拠と見なされないようにすることが求められる。

有効性状態が「無効」の経路を、経路選択プロセスでさらに検討する資格がないと見なすかどうかは、ローカル・ルーティング・ポリシーの問題である。ここでは、循環依存(circular dependence)の可能性が考慮される。ROAのリポジトリ、またはアドレス・プレフィックスに関連して使用される証明書の信頼できる公開ポイントが、ROAに記述されたアドレス・プレフィックス内のアドレスにある場合、RPはそのプレフィックスに対する経路がRPのローカル・ルーティング・ドメインで受け入れられた場合のみ、リポジトリにアクセスできる。また、RPKIオブジェクトの伝播時間は経路の伝播時間とは異なる可能性があり、RPのローカルRPKIリポジトリ・キャッシュが関連するROAを取り上げて、RPKI内の有効性状態が「有効」と評価する前に、RPのルーティング・システムが経路を学習する可能性があることにも留意する。

⚠️ コメント

経路受信時に、ROAの検証が間に合わず、無効となってしまう例。

4. ルーティング発信の否認

ROAは、プレフィックス保有者がASに対して、このプレフィックスの経路をドメイン間ルーティング・システムに発信することを認可しているという肯定的証明(アテステーション)である。プレフィックス保有有は、アドレス・プレフィックスの経路を発信する権限を付与されたASが存在しない場合でも、認可を築くことができる。これは、ROAのサブジェクトASがルーティング・コンテキストでも使用してはならないASであるROAを使用することで実現する。具体的には、AS 0は、ルーティングされないネットワークを識別するために使用できるよう、IANAによって予約されている[IANA-AS]。

AS 0をサブジェクトとするROA(AS 0 ROA)は、ROAに記載されたプレフィックスおよびMore Specificプレフィックスが、ルーティングの状況下で使用されるべきではないことをプレフィックス保有者が証明するものである。

⚠️ 経路検証モデルの欠点(Juniper)

Junosのマニュアルには、「経路検証モデルには大きな欠点がある」と記載されている。何が欠点かというと、RPKIはどのASがプレフィックスの正当な保有者であるか(positive updates)を公表できる。しかし、どのASからも発信してはならないプレフィックス(negative update)を公表できないことだという。

その意味で、AS 0 ROAはこの欠点の次善策になっている。

セクション2で説明する経路検証手順は、他の有効なROAが単独で使用された場合に「無効」な検証結果を提供するとしても、アドレス・プレフィックスとオリジンASに一致するROAがあれば、「有効」な結果を提供する。その結果、AS 0 ROAは、ルーティング可能なASをサブジェクトとする他のどのROAよりも相対的な優先度が低くなる。これにより、プレフィックス保有者はAS 0 ROAを使用して、そのプレフィックスと等しいか、そのプレフィックスのMore Specific経路を「無効」と見なすというデフォルト条件を宣言でき、同時に発行された他のROAが、More Specificなプレフィックスに対して、有効な発信許可を記述することもできる。

慣例により、AS 0 ROAは、IPv4アドレスの場合は maxLength値32、IPv6アドレスの場合はmaxLength値128を持つ必要がある。ただし、経路検証の観点からは、どのような有効なmaxLength値を使用しても、またはmaxLength要素がROAから省略された場合でも、同じ結果が得られる。

⚠️ AS 0 ROAのmaxLength値

上記は分かりにくいが、maxLength値に何を書いても、書かなくても、maxLengthが32あるいは128に設定されるという意味。実際のAS 0 ROAはmaxLength値はまちまちである。

また、慣例として、AS 0 ROAは、アドレス・プレフィックスに対して発行される唯一のROAである必要がある。繰り返しになるが、これは厳密な要件ではない。AS 0 ROAは、異なるサブジェクトAS値を持つROAと共存する可能性はあるが、そのような場合、AS 0 ROAの有無によって経路の有効性状態は何ら変わらない。

5. 経路検証の有効期間

検証結果の「有効期間」とは、元の検証結果が引き続き適用できる期間を指す。ここでの暗黙の前提は、検証の有効期間が「期限切れ」になると、経路の有効性を再試験する必要があるということである。

ROAの検証有効期間は、ROAに署名するために使用されるエンド・エンティティ(EE)証明書で指定された有効期間と、EE証明書の検証に使用される証明書パスに含まれる証明書の有効期間よって管理される。ROAの有効期間は、署名するEE証明書のnotAfterフィールド、またはROAを検証できる証明書パスが存在しない時点で期限切れとなる。ROA発行者は、ROAの署名に使用されたEE証明書を失効することで、ROAを早期に無効化することを選択できる。

6. セキュリティに関する考慮事項

ROA発行者は、ROAを発行する際の検証の影響に注意する必要がある。ROAは暗黙のうちに、maxLengthより長いプレフィックス長を持つMore Specificプレフィックスを持つすべての経路と、ROAのコレクションに記載されているAS以外のすべての発信元ASを無効にする。

保守的な運用方法としては、ROAの生成中に有効な経路が誤って無効になるのを避けるために、より大規模なアドレス・ブロックに対してROAを発行する前に、明確な発信元 ASを持つすべてのMore Specificプレフィックスに対してROAを確実に発行することである。

⚠️ ROAの発行方法について

いきなり、大枠のアドレス・ブロックのROAを発行するのではなく、More Specificプレフィックスから順次ROAを発行していくのが安全である。

また、ROA発行者は、1つのオリジンASに対してROAを生成する場合、アドレス・プレフィックス保有者が任意のアドレス・プレフィックスに対する経路発信を複数のASに認可する場合、そのような認可されたASごとにROAを生成する必要があることにも留意する必要がある。

7. 謝辞

この文書を作成するにあたり、ジョン・スカッダーとスティーブン・ケントの有益な貢献に謝意を表したい。また、SIDR WGのセッションでのこの資料が発表された際に、SIDRワーキンググループの多くのメンバーが貢献してくれたことにも感謝したい。また、トニー・ベイツ、ランディ・ブッシュ、トニー・リーおよびヤコフ・レクターによる先行の研究にも謝意を表する。これは、本文書に記載されている検証結果が、[NLRI-ORIG]に記載されているオリジンAS検証の認証結果とセマンティクスを反映しているためである。プラドシュ・モハパトラたちによって編集された[BGP-PFX]で提示された経路の有効性状態に関連する多くの検証概念が、本文書で使用されている。

8. 参考文献

8.1. 引用規格

[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.

[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.

[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.

8.2. 参考規格

[BGP-PFX] Mohapatra, P., Ed., Scudder, J., Ed., Ward, D., Ed., Bush, R., Ed., and R. Austein, Ed., "BGP Prefix Origin Validation", Work in Progress, October 2011.

[IANA-AS] IANA, "Autonomous System (AS) Numbers", http://http://www.iana.org/assignments/as-numbers

[NLRI-ORIG] Bates, T., Bush, R., Li, T., and Y. Rekhter, "DNS-based NLRI origin AS verification in BGP", Work in Progress, January 1998.

著者のアドレス

ジェフ・ヒューストン
APNIC
メール: gih@apnic.net

ジョージ・マイケルソン
APNIC
メール: ggm@apnic.net

変更履歴

  • 2024.2.21
  • 2024.3.1: 経路検証モデルの欠点
  • 2024.3.5
GitHubで編集を提案

Discussion