📑

RFC 6482: 経路オリジン認可(ROA)のプロファイル

2024/02/16に公開

RFC

bgp

tech

要旨

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

本文書の位置付け

本文書はインターネット標準化過程の文書である。

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

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

著作権表示

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

1. はじめに

リソース公開鍵基盤(RPKI)の主な目的は、ルーティングのセキュリティを向上させることである。(詳細は、[RFC6480]を参照。) このシステムの一環として、ASがIPアドレス・ブロックの保有者から、そのブロック内の1つ以上のプレフィックスの経路を広告する認可を与えられていることを、エンティティが検証できるようにする仕組みが必要である。ROAはこの機能を提供する。

ROAは、RPKIデジタル署名オブジェクトのテンプレート[RFC6488]を利用する。このテンプレートは、ROAの内容のために暗号メッセージ構文(CMS)[RFC5652]ラッパーと、RPK署名オブジェクトの一般的な検証手順を定義している。それで、ROAの仕様を完成させるために([RFC6488]のセクション4を参照)、この文書は以下を定義する。

署名済みオブジェクトがROAであることを識別するOID。(このOIDは、signerInfoオブジェクトのcontent-type signed属性と同様に、encapContentInfoオブジェクトのeContentType内に現れる)。
ROA eContentのASN.1構文。(これは、経路を発信することを認可されたASと、ASが経路の発信先となるプレフィックスを指定するペイロードである。) ROA eContentは、Distinguished Encoding Rules (DER)[X.690]を使用してASN.1符号化される。
ROAを検証するために必要な追加のステップ([RFC6488]で規定された検証ステップに加えて)。

1.1. 用語

読者は、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile」(インターネットX.509公開鍵基盤証明書および証明書失効リスト(CRL)プロファイル)[RFC5280]および「X.509 Extensions for IP Addresses and AS Identifiers」(IPアドレスおよびAS識別子のX.509拡張」[RFC3779]に記載されている用語と概念に精通しているものとする。

さらに、本文書はRPKI署名済みオブジェクト・プロファイル[RFC6488]を利用している。そのため、その文書に精通していることが前提となる。RPKI署名済みオブジェクト・プロファイルは、RPKIリソース証明書プロファイル[RFC6487]に準拠する証明書を使用することに留意する。したがって、そのプロファイルにも精通していることが前提となる。

本文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、[RFC2119]の記述にしたがって解釈される。

2. ROAのContent-Type

ROAのcontent-typeは、routeOriginAuthzと定義され、1.2.840.113549.1.9.16.1.2の数値を持つ。

このOIDは、encapContentInfoオブジェクトのeContentTypeと、signerInfoオブジェクトのcontent-type signed属性の両方に現れなければならない(MUST)([RFC6488]参照)。

3. ROA eContent

ROAの内容は、経路を発信することをアドレス空間保有者に認可された一つのASと、広告される1つ以上のIPアドレス・プレフィックスのリストを識別する。アドレス空間保有者は、複数のASに同じアドレス・プレフィックスを広告することを認可する必要がある場合、AS番号ごとに1つずつ、複数のROAを発行する。ROAは正式には以下のように定義される。

RouteOriginAttestation ::= SEQUENCE {
   version [0] INTEGER DEFAULT 0,
   asID  ASID,
   ipAddrBlocks SEQUENCE (SIZE(1..MAX)) OF ROAIPAddressFamily }

ASID ::= INTEGER

ROAIPAddressFamily ::= SEQUENCE {
   addressFamily OCTET STRING (SIZE (2..3)),
   addresses SEQUENCE (SIZE (1..MAX)) OF ROAIPAddress }

ROAIPAddress ::= SEQUENCE {
   address IPAddress,
   maxLength INTEGER OPTIONAL }

IPAddress ::= BIT STRING

この内容はencapContentInfo内のeContentとして表示されることに留意すること([RFC6488]参照)。

3.1. version

RouteOriginAttestationのバージョン番号は0でなければならない(MUST)。

3.2. asID

asIDフィールドは、指定されたIPアドレス・プレフィックスの経路を発信することを認可されているAS番号を含む。

3.3. ipAddrBlocks

ipAddrBlocksフィールドは、ASが経路発信を認可されているIPアドレス・プレフィックスを符号化する。ここでの構文は、RFC 3779で定義しているIPアドレス委任拡張の構文よりも制限が厳しいことに留意する。この拡張は任意のアドレス範囲を表せるが、ROAではプレフィックスのみを表す必要がある。

ROAIPAddressFamily構造体の中で、addressFamilyはIPアドレス・ファミリーのアドレス・ファミリー識別子(AFI)を含む。本仕様はIPv4とIPv6のみをサポートする。したがって、addressFamilyは0001または0002でなければならない(MUST)。

ROAIPAddress構造体の中で、アドレス・フィールドはプレフィックスをIPAddress型シーケンスとして表す。(詳細については[RFC3779]を参照)。maxLengthが存在する場合、その値は、付随するプレフィックスの長さ以上で、アドレス・ファミリーのIPアドレスの長さ(ビット単位)以下の整数でなければならない(MUST)(IPv4の場合は32、IPv6の場合は128)。maxLengthが存在する場合、ASが広告することを認可されているIPアドレス・プレフィックスの最大長を指定する。(例えば、IPアドレス・プレフィックスが203.0.113/24で、maxLengthが26の場合、ASは最大長26のMore Specificプレフィックスを広告することが許可される。この例では、ASは203.0.113/24、203.0.113.128/25、203.0.113.0/25の広告は許可されるが、203.0.113.0/27は許可されない。) maxLengthが存在しない場合、ASはROAで指定された正確なプレフィックスを広告する権限しか与えられない。

有効なROAには、別のIPアドレス・プレフィックス(別のROAIPAddress要素内)に包含されるIPアドレス・プレフィックス(ROAIPAddress要素内)が含まれる場合があることに留意する。例えば、ROAには、maxLength 26のプレフィックス203.0.113/24と、maxLength 28のプレフィックス203.0.113.0/28を含めることができる。(このようなROAは、特定のプレフィックス203.0.113.0/28だけでなく、最小長 24、最大長26の203.0.113で始まるプレフィックスを広告することを、指定されたASに許可することになる。) さらに、1つのROAに2つのROAIPAddress要素を含めてもよい(MAY)。この場合、IPアドレス・プレフィックスはどちらも同じである。しかし、このような場合、より短いmaxLengthのROAIPAddressは、指定されたASに追加の権限を与えないことから、ROAの意味を変えることなく省略できるため、これは推奨されない(NOT RECOMMENDED)。

4. ROAの検証

リライング・パーティーはROAを使用してルーティング・アナウンスを検証する前に、まずROAを検証しなければならない (MUST)。ROAを検証するには、リライング・パーティーは、[RFC6488]で規定されているすべての検証チェックと、以下の追加のROA固有の検証ステップを実行しなければならない(MUST)。

エンド・エンティティ(EE)証明書(ROAに含まれる)に、IPアドレス委任拡張 [RFC3779]が存在し、ROAに含まれる各IPアドレス・プレフィックスは、EE証明書のIPアドレス委任拡張で指定するIPアドレス・セットに含まれる。

Errata

「...EE証明書のIPアドレス委任拡張で指定するIPアドレス・セットに含まれる。」は、「EE証明書のIPアドレス委任拡張で指定するIPアドレス・セットに含まれる。そのEE証明書は、[RFC 3779]に記載されている「inherit」要素を使用してはならない(MUST NOT)。」とする。

注記:

著者らに話を聞いたところ、著者らの意図は、ROAの検証を簡素化するために、ROA EE証明書では「inherit」を禁止することだった。実装者はこれに同意しており、2012年3月の時点で、3つのパブリック・バリデータの実装がすでにこれを実施している。

この正誤表は単にそれを明示的に述べているだけだが、原文は「inherit」によって間接的に指定されたリソースのための余地を残していると誤解される可能性がある。

この正誤表はWGで議論された、SIDRリストのアーカイブを参照のこと。

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

ROAのデータには機密性は想定されていない。ROAは、すべてのISP、そしておそらくすべてのインターネット・ユーザがアクセスできるリポジトリに保存されることが予想される。ROAの検証に使用されるPKIは認可を提供するが、認証は提供しないため、ROAに関連付けられた明示的な認証は存在しない。ROAは署名されたアプリケーション層のオブジェクトではあるが、ROAを介して否認防止(non-repudiation)を伝える意図はない。

ROAの目的は、ASがROAに含まれるプレフィックスへの経路を発信する認可を伝えることである。したがって、ROAの完全性は確立されなければならない(MUST)。ROAの仕様は、RPKI署名済みオブジェクト形式を使用する。そのため、[RFC6488]のすべてのセキュリティに関する考慮事項もROAに適用される。さらに、署名済みオブジェクト・プロファイルは、完全性を保つためにCMS署名済みメッセージ形式を使用する。したがって、ROAはそのデータ構造に関連するすべてのセキュリティ上の考慮事項を継承する。

ROAの署名者が、ターゲットASにプレフィックスの経路発信を認可する権利は、[RFC6480]に記載されているアドレス空間とAS番号のPKIを使用することで確立される。具体的には、このPKIに基づいて発行されたX.509証明書を使用して、ROAの署名を検証し、ROA内のプレフィックスが証明書のアドレス空間拡張のプレフィックスと一致することを確認しなければならない(MUST)。

6. IANA に関する考慮事項

IANAは以下のRPKI署名済みオブジェクトを登録した。

ROA    1.2.840.113549.1.9.16.1.24    [RFC6482]

7. 謝辞

著者らは、チャールズ・ガーディナーとラス・ハウスリーの支援と貢献に感謝の意を表する。さらに、ロブ・オースティン、ロキ・ガグリアーノ、ダニー・マクファーソン、サム・ウェイラーの丁寧なレビューと有益なコメントに感謝する。

8. 参考文献

8.1. 引用規格

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.

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

[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.

[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012.

[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, February 2012.

[X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).

8.2. 参考規格

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

付録A: ASN.1モジュール

この規範的付録は、ROAの内容をASN.1構文で規定するASN.1モジュールを提供する。

RPKI-ROA { iso(1) member-body(2) us(840) rsadsi(113549)
   pkcs(1) pkcs9(9) smime(16) mod(0) 61 }

DEFINITIONS EXPLICIT TAGS ::= BEGIN

RouteOriginAttestation ::= SEQUENCE {
   version [0] INTEGER DEFAULT 0,
   asID  ASID,
   ipAddrBlocks SEQUENCE (SIZE(1..MAX)) OF ROAIPAddressFamily }

ASID ::= INTEGER

ROAIPAddressFamily ::= SEQUENCE {
   addressFamily OCTET STRING (SIZE (2..3)),
   addresses SEQUENCE (SIZE (1..MAX)) OF ROAIPAddress }

ROAIPAddress ::= SEQUENCE {
   address IPAddress,
   maxLength INTEGER OPTIONAL }

IPAddress ::= BIT STRING

END