🏛️

RFC 9455: 複数のIPプレフィックスを含む経路オリジン認可(ROA)の回避

2023/12/28に公開

RFC

bcp

tech

要旨

リソース公開鍵基盤(RPKI)を使用する場合、アドレス空間の所有者は、経路オリジン認可(ROA)オブジェクトを発行して、1つ以上の自律システム(AS)がIPアドレス・プレフィックスへのBGP経路をオリジンとして送ることを認可する必要がある。このメモでは、複数のIPプレフィックスを含むROAから生じる可能性のある運用上の問題について説明し、各ROAには1つだけから成るIPプレフィックスを含めることを推奨する。

本文書の位置付け

本文書は、インターネットのベスト・カレント・プラクティスを文書化したものである。

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

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

著作権表示

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

1. はじめに

RPKIにおいて、デジタル署名されたオブジェクトであるROAは、1つのASが、関連するアドレス空間内の1つ以上のIPプレフィックスのBGP経路をオリジンとして送ることをアドレス空間の保有者から認可されていることを識別する[RFC6482]。

各ROAには、asIDフィールドとipAddrBlocksフィールドが含まれている。asID フィールドには、指定されたIPアドレス・プレフィックスへの経路をオリジンとして送ることが許可された1つのAS番号が含まれる。ipAddrBlocksフィールドには、ASが経路のオリジンとして送ることを許可されている1つ以上のIPアドレス・プレフィックスが含まれている。

⚠️ RFC 6482

ROAの定義は以下の通り。

ROAは、IPアドレス・ブロックの保有者が自律システム(AS)にそのアドレス・ブロック内の1つ以上のプレフィックスへの経路を発信することを認可したことを検証する手段を提供するデジタル署名されたオブジェクトである。

ROAの内容は、経路を発信することをアドレス空間保有者に認可された一つのASと、広告される1つ以上のIPアドレス・プレフィックスのリストを識別する。アドレス空間保有者は、複数のASに同じアドレス・プレフィックスを広告することを認可する必要がある場合、AS番号ごとに1つずつ、複数のROAを発行する。
RouteOriginAttestation ::= SEQUENCE {
   version [0] INTEGER DEFAULT 0,
   asID  ASID,
   ipAddrBlocks SEQUENCE (SIZE(1..MAX)) OF ROAIPAddressFamily }

アドレス空間所有者が、複数のASに同じIPプレフィックスを広告することを許可する必要がある場合、複数のROAを発行しなければならない(AS番号ごとに1つ[RFC6480])。この文書が発行される以前、IPプレフィックスごとに個別のROAを発行すること、または複数のIPプレフィックスを含む1つのROAを発行することを推奨するガイダンスはなかった。

⚠️ 実際のリポジトリ

2024.3.18時点のリポジトリの中のROAを調べてみた。リポジトリ内にある*.roaファイルの中に、単一プレフィックスしか含まれていないものを下記の方法で見つける。

% find . -name '*.roa' -print -exec rpki-client -f {} \; > roa-file
% grep -e ^File: -e maxlength: roa-file > interfile
% pcregrep -M "^IP address blocks:.*\nFile:" interfile > single-prefix
% pcregrep -v -M "^IP address blocks:.*\nFile:" interfile > multiple-prefix

結果は以下の通り。ROA全体の85%が単一プレフィックスとなっている。

ROAの数	単一プレフィックス	複数プレフィックス
234,164	199,571	34,593

複数プレフィックスのROAのプレフィックス数の分布を調べてみた。

プレフィックス数	ROAの数
2-10	29,572
11-100	4,607
101-500	355
501-1000	33
1001-2000	14
2001-3000	7
3001-4000	2
4001-5000	2
5001-	1 (6,524)

2. 用語

この文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すように、すべて大文字で表示される場合に限り、 BCP 14 [RFC2119] [RFC8174]の記述に従って解釈される。

3. 問題提起

アドレス空間の保有者は、ルーティング・アナウンスごとに個別のROAを発行できる。もう一つの方法として、asIDが指定された場合、複数のルーティング・アナウンスに対して1つのROAを、あるいはすべてのルーティング・アナウンスに対して、1つのROAを発行することもできる。指定されたROAは有効か無効のどちらかであるため、RPKI検証に関しては、そのROAが発行されたルーティング・アナウンスは「運命を共にする」(share fate)ことになる。現在、プレフィックスごとに1つ、あるいは複数のルーティング・アナウンスに対して1つなど、どのような種類のROAを発行すべきかについて推奨する既存のRFCはない。運命共有(fate-sharing)の問題については議論も対処もされていない。

RPKIのトラストチェーンでは、親CAが一部のリソースの委任先に発行された認証局(CA)証明書は、いつでも親CAによって失効される可能性があり、その結果、[RFC3779]で定義された証明書拡張で指定されているリソースが変更されることになる。a) 新しいCA証明書に完全に含まれていない、または b) リライング・パーティー(RP)ソフトウェアがまだ発見していない新しいCA証明書に含まれるROAオブジェクトは、無効として却下される。ROAの無効性は、そのROAで指定されるすべての経路に影響するため、そのasIDを介して関連付けられた経路を持つ変更されていないリソースを、CA証明書の有効性の変更によって影響を受けるリソースから切り離すことはできない。これらのリソースは、有効性を変更する意図がなくても、無効なROAに該当する。これらのリソースが別のROAにあった場合、発行元のCA証明書に変更はなく、したがってその後も無効になることもない。

CAは、ROAの更新とリソース証明書の更新を慎重に調整しなければならない。1つ組織(エンティティ)が親CAとROAを発行するCAの両方を管理する場合、このプロセスは自動化されるかもしれない([RFC8211]のセクション3.4のシナリオD)。しかし、他の導入シナリオでは、この調整はより複雑になる。

ROA全体の有効期限は1つであるため、有効期限切れはROA内のすべてのプレフィックスに影響する。したがって、いずれかのプレフィックスに対するROAの変更は、他のプレフィックスに対する変更と同期させる必要がある。特にプレフィックスの認可に時間制限がある場合はそうだ。これらのプレフィックスが個別に発行されたROAに含まれていた場合、有効期間は各ROAに固有となり、無効は特定の発行元の親CA証明書の再発行によってのみ影響を受ける。

プレフィックスは、例えばIPプレフィックスを一時的に貸し出す場合など、特定の期間のみ、あるASからの発信を許可することができる。複数のIPプレフィックスを持つROAを使用する場合、管理がより難しくなり、エラーが発生しやすくなる。同様に、より複雑なルーティングでは、プレフィックスのサブセットのasIDまたは経路の変更が必要になるかもしれない。ROAを再発行すると、ROAのプレフィックスでカバーされる以前に受信したBGP経路の有効性が変更されるかもしれない。a) 時間制限のあるリソースが別のROAにある場合、またはb) より複雑なルーティングの場合、asIDの各変更または特定のプレフィックスの経路の変更が、個別のROAへの変更に反映される場合、影響を受けない経路の有効性は変更されない。

1つしかIPプレフィックスを持たないROAの使用は、このような副作用を最小限に抑えることができる。これにより、各ROAを発行する親CAが有効なままであり、各ROA自体が有効なままであるため、原因の如何に関わらず、運命共有を避けることができる。

⚠️ 要するに

あるISPが次のようなリソースを持っていたとする

ASNs:64500-64505
IPプレフィックス: 192.0.2.128/27, 198.51.100.128/27, 203.0.113.128/27

そこで、次のようなROAを作ったとする。

ROA1: 64500 -> 192.0.2.128/28, 204.0.113.128/28(間違い)
ROA2: 64501 -> 198.51.100.128/28, 203.0.113.128/28

すると、ROA1全体が無効となり、正規のBGP経路が「Not Found」になってしまう。

1つのROAに複数のプレフィックスを記述すると、設定ミスが原因で正当なROAオブジェクトが無効とされてしまう可能性がある。この設定ミスが、ルーティングに深刻な影響をもたらす可能性があるため、ROAにはプレフィックスは1つのみとすることが推奨される。また、複数プレフィックスのROAは更新頻度が多くなる可能性があり、これもルーティングに影響を与える可能性がある。

4. 推奨事項

CAに反する正当な理由がない限り、発行されたROAにIPプレフィックスを1つ含める必要がある(SHOULD)。

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

独立したIPプレフィックスに対して別々のROAを発行すると、検証時にRPのファイル取得の負担が増加する可能性がある。

6. IANA に関する考慮事項

本文書にはIANAのアクションはない。

7. 参考文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, DOI 10.17487/RFC3779, June 2004, <https://www.rfc-editor.org/info/rfc3779>.

[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <https://www.rfc-editor.org/info/rfc6480>.

[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, <https://www.rfc-editor.org/info/rfc6482>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8211] Kent, S. and D. Ma, "Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI)", RFC 8211, DOI 10.17487/RFC8211, September 2017, <https://www.rfc-editor.org/info/rfc8211>.

謝辞

本文書の執筆にあたり、レビューと貢献をしていただいた次の方々に感謝の意を表す: ジョージ・ミケルソン、ティム・ブランジール、ジョブ・スナイダース、ディ・マ、ジェフ・ヒューストン、トム・ハリソン、ロブ・オースチン、ステファン・ケント、クリストファー・マロウ、ラス・ハウスリー、チン・ヘン・クー、ケユール・パテル、カリング・チャン、ケジュン・ドン。また、セキュリティ分野理事会のレビューを担当したショーン・ターナーにも感謝する。

本研究は、北京ノヴァ科学技術プログラムの助成金Z191100001119113の支援を受けた。

著者の住所

ヤン・ジーウェイ
CNNIC
No.4 South 4th Street, Zhongguancun
北京
100190
中国
メール: yanzhiwei@cnnic.cn

ランディ・ブッシュ
IIJ総合研究所 & 株式会社アーカス
5147 クリスタル・スプリングス
ベインブリッジ島、ワシントン州 98110
アメリカ合衆国
メール: randy@psg.com

グァンガン・ゲン
済南大学
No.601, West Huangpu Avenue
広州
510632
中国
メール: gggeng@jnu.edu.cn

タイズ・デ・コック
RIPE NCC
ステーションスプレイン 11
アムステルダム
オランダ
メール: tdekock@ripe.net

ヤオ・ジャンカン
CNNIC
No.4 South 4th Street, Zhongguancun
北京
100190
中国
メール: yaojk@cnnic.cn

変更履歴

2023.12.28
2024.1.8
2024.1.25
2024.1.31
2024.3.18

GitHubで編集を提案

要旨