[要約] RFC 6482は、ルートオリジン認証（ROA）のためのプロファイルであり、BGPルートの信頼性を向上させるために設計されています。このRFCの目的は、ROAの使用方法と構成を標準化し、インターネットルーティングのセキュリティを強化することです。
Internet Engineering Task Force (IETF) M. Lepinski
Request for Comments: 6482 S. Kent
Category: Standards Track D. Kong
ISSN: 2070-1721 BBN Technologies
February 2012
A Profile for Route Origin Authorizations (ROAs)
ルートオリジン認可（ROA）のプロファイル
Abstract
概要
This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block.
このドキュメントは、ルートオリジン認証（ROA）の標準プロファイルを定義します。ROAは、IPアドレスブロックホルダーがアドレスブロック内の1つ以上のプレフィックスへのルートを発信する自律システム（AS）を許可したことを確認する手段を提供するデジタル署名オブジェクトです。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6482.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6482で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. The ROA Content-Type ............................................3
3. The ROA eContent ................................................3
3.1. version ....................................................4
3.2. asID .......................................................4
3.3. ipAddrBlocks ...............................................4
4. ROA Validation ..................................................5
5. Security Considerations .........................................5
6. Acknowledgments .................................................6
7. References ......................................................6
7.1. Normative References .......................................6
7.2. Informative References .....................................6
Appendix A: ASN.1 Module..........................................8
The primary purpose of the Resource Public Key Infrastructure (RPKI) is to improve routing security. (See [RFC6480] for more information.) As part of this system, a mechanism is needed to allow entities to verify that an AS has been given permission by an IP address block holder to advertise routes to one or more prefixes within that block. A ROA provides this function.
リソース公開キーインフラストラクチャ（RPKI）の主な目的は、ルーティングセキュリティを改善することです。（詳細については[RFC6480]を参照してください。）このシステムの一部として、IPアドレスブロックホルダーからASがそのブロック内の1つ以上のプレフィックスへのルートを宣伝する許可を与えられていることをエンティティが確認できるようにするためにメカニズムが必要です。ROAはこの関数を提供します。
The ROA makes use of the template for RPKI digitally signed objects [RFC6488], which defines a Crytopgraphic Message Syntax (CMS) [RFC5652] wrapper for the ROA content as well as a generic validation procedure for RPKI signed objects. Therefore, to complete the specification of the ROA (see Section 4 of [RFC6488]), this document defines:
ROAは、RPKIデジタル署名されたオブジェクト[RFC6488]のテンプレートを使用します。これは、crytopgraphicメッセージ構文（CMS）[RFC5652] ROAコンテンツのラッパーと、RPKI署名オブジェクトの一般的な検証手順を定義します。したがって、ROAの仕様を完了するため（[RFC6488]のセクション4を参照）、このドキュメントは次のように定義しています。
1. The OID that identifies the signed object as being a ROA. (This OID appears within the eContentType in the encapContentInfo object as well as the content-type signed attribute in the signerInfo object).
1. 署名されたオブジェクトをROAであると識別するOID。（このoidは、ecapcontentinfoオブジェクトのecontenttype内に表示され、Signerinfoオブジェクトにコンテンツタイプの署名された属性に表示されます）。
2. The ASN.1 syntax for the ROA eContent. (This is the payload that specifies the AS being authorized to originate routes as well as the prefixes to which the AS may originate routes.) The ROA eContent is ASN.1 encoded using the Distinguished Encoding Rules (DER) [X.690].
2. ROAエコネントのASN.1構文。（これは、ASがルートを発信することを許可されているASを指定するペイロードと、ASがルートを発信する可能性のある接頭辞を指定します。）ROAエコネントは、著名なエンコードルール（der）[x.690]を使用してエンコードされます。
3. An additional step required to validate ROAs (in addition to the validation steps specified in [RFC6488]).
3. ROASを検証するために必要な追加のステップ（[RFC6488]で指定された検証手順に加えて）。
It is assumed that the reader is familiar with the terms and concepts described in "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280] and "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779].
読者は、「インターネットx.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」[RFC5280]および「IPアドレスおよび識別子としてのX.509拡張機能」[X.509拡張子]に記載されている用語と概念に精通していると想定されています。RFC3779]。
Additionally, this document makes use of the RPKI signed object profile [RFC6488]; thus, familiarity with that document is assumed. Note that the RPKI signed object profile makes use of certificates adhering to the RPKI Resource Certificate Profile [RFC6487]; thus, familiarly with that profile is also assumed.
さらに、このドキュメントでは、RPKI署名されたオブジェクトプロファイル[RFC6488]を使用しています。したがって、そのドキュメントに精通していることが想定されています。RPKI署名されたオブジェクトプロファイルは、RPKIリソース証明書プロファイル[RFC6487]を順守する証明書を使用していることに注意してください。したがって、そのプロファイルに慣れていることも想定されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワードは「必須」、「必要」、「必須」、「shall」、「shall "、" bood "、" low "of" bould "、" becommended "、" bodement "、" may "、" optional「この文書では、RFC 2119 [RFC2119]に記載されているように解釈されます。
The content-type for a ROA is defined as routeOriginAuthz and has the numerical value of 1.2.840.113549.1.9.16.1.24.
ROAのコンテンツタイプはRouteoriginauthzとして定義され、1.2.840.113549.1.9.16.1.24の数値を持っています。
This OID MUST appear both within the eContentType in the encapContentInfo object as well as the content-type signed attribute in the signerInfo object (see [RFC6488]).
このoidは、ecapcontentinfoオブジェクトのecontentType内に表示される必要があります。また、SignerInfoオブジェクトのコンテンツタイプの署名属性（[RFC6488]を参照）の両方で表示する必要があります。
The content of a ROA identifies a single AS that has been authorized by the address space holder to originate routes and a list of one or more IP address prefixes that will be advertised. If the address space holder needs to authorize multiple ASes to advertise the same set of address prefixes, the holder issues multiple ROAs, one per AS number. A ROA is formally defined as:
ROAのコンテンツは、アドレススペースホルダーによって承認された単一を識別し、ルートを発信することと、宣伝される1つ以上のIPアドレスプレフィックスのリストを識別します。アドレススペースホルダーが複数のASEを許可する必要がある場合、同じアドレスプレフィックスを宣伝する必要がある場合、ホルダーは複数の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
Note that this content appears as the eContent within the encapContentInfo (see [RFC6488]).
このコンテンツは、encapcontentinfo内のecontentとして表示されることに注意してください（[rfc6488]を参照）。
The version number of the RouteOriginAttestation MUST be 0.
routeoriginattationのバージョン番号は0でなければなりません。
The asID field contains the AS number that is authorized to originate routes to the given IP address prefixes.
ASIDフィールドには、特定のIPアドレスプレフィックスへのルートを発信することが許可されているAS番号が含まれています。
The ipAddrBlocks field encodes the set of IP address prefixes to which the AS is authorized to originate routes. Note that the syntax here is more restrictive than that used in the IP address delegation extension defined in RFC 3779. That extension can represent arbitrary address ranges, whereas ROAs need to represent only prefixes.
iPaddrblocksフィールドは、ルートを発信することが許可されているASのIPアドレスプレフィックスのセットをエンコードします。ここの構文は、RFC 3779で定義されているIPアドレス委任拡張拡張機能で使用される構文よりも制限的であることに注意してください。その拡張は任意のアドレス範囲を表すことができますが、ROAは接頭辞のみを表す必要があります。
Within the ROAIPAddressFamily structure, addressFamily contains the Address Family Identifier (AFI) of an IP address family. This specification only supports IPv4 and IPv6. Therefore, addressFamily MUST be either 0001 or 0002.
roaipaddressfamily構造内では、addressfamilyには、IPアドレスファミリーの住所ファミリー識別子（AFI）が含まれています。この仕様は、IPv4とIPv6のみをサポートします。したがって、アドレスファミリーは0001または0002のいずれかでなければなりません。
Within a ROAIPAddress structure, the addresses field represents prefixes as a sequence of type IPAddress. (See [RFC3779] for more details). If present, the maxLength MUST be an integer greater than or equal to the length of the accompanying prefix, and less than or equal to the length (in bits) of an IP address in the address family (32 for IPv4 and 128 for IPv6). When present, the maxLength specifies the maximum length of the IP address prefix that the AS is authorized to advertise. (For example, if the IP address prefix is 203.0.113/24 and the maxLength is 26, the AS is authorized to advertise any more specific prefix with a maximum length of 26. In this example, the AS would be authorized to advertise 203.0.113/24, 203.0.113.128/25, or 203.0.113.0/25, but not 203.0.113.0/27.) When the maxLength is not present, the AS is only authorized to advertise the exact prefix specified in the ROA.
roaipAddress構造内では、アドレスフィールドは、iPaddressのタイプのシーケンスとしてプレフィックスを表します。（詳細については[RFC3779]を参照）。存在する場合、最大長は、付随するプレフィックスの長さ以上の整数でなければならず、アドレスファミリーのIPアドレスの長さ（ビット）以下（IPv4の場合は32、IPv6の場合は128）でなければなりません。。存在する場合、MaxLengthは、ASが宣伝することが許可されているIPアドレスプレフィックスの最大長を指定します。（たとえば、IPアドレスのプレフィックスが203.0.113/24の場合、最大長の場合、最大長の26のより具体的なプレフィックスを宣伝することが許可されています。この例では、203.0を宣伝する権限があります。.113/24、203.0.113.128/25、または203.0.113.0/25、しかし203.0.113.0/27ではなく203.0.113.0/27。）最大長が存在しない場合、ROAで指定された正確なプレフィックスを宣伝することが許可されている場合のみ。
Note that a valid ROA may contain an IP address prefix (within a ROAIPAddress element) that is encompassed by another IP address prefix (within a separate ROAIPAddress element). For example, a ROA may contain the prefix 203.0.113/24 with maxLength 26, as well as the prefix 203.0.113.0/28 with maxLength 28. (Such a ROA would authorize the indicated AS to advertise any prefix beginning with 203.0.113 with a minimum length of 24 and a maximum length of 26, as well as the specific prefix 203.0.113.0/28.) Additionally, a ROA MAY contain two ROAIPAddress elements, where the IP address prefix is identical in both cases. However, this is NOT RECOMMENDED as, in such a case, the ROAIPAddress with the shorter maxLength grants no additional privileges to the indicated AS and thus can be omitted without changing the meaning of the ROA.
有効なROAには、別のIPアドレスプレフィックス（別のRoaipAddress要素内）に含まれるIPアドレスプレフィックス（RoaipAddress要素内）が含まれる場合があることに注意してください。たとえば、ROAには、MaxLength 26のプレフィックス203.0.113/24、およびMaxLength 28のプレフィックス203.0.113.0/28が含まれる場合があります。最小長の24と最大長26、および特定のプレフィックス203.0.113.0/28。）さらに、ROAには2つのRoaipAddress要素が含まれる場合があります。ただし、このような場合、最大値が短いroaipAddressは、示されたASに追加の特権を与えないため、ROAの意味を変更せずに省略することができるため、これは推奨されません。
Before a relying party can use a ROA to validate a routing announcement, the relying party MUST first validate the ROA. To validate a ROA, the relying party MUST perform all the validation checks specified in [RFC6488] as well as the following additional ROA-specific validation step.
頼る当事者がROAを使用してルーティングアナウンスを検証する前に、頼る当事者は最初にROAを検証する必要があります。ROAを検証するには、依存者は[RFC6488]で指定されたすべての検証チェックと、次の追加のROA固有の検証ステップを実行する必要があります。
o The IP address delegation extension [RFC3779] is present in the end-entity (EE) certificate (contained within the ROA), and each IP address prefix(es) in the ROA is contained within the set of IP addresses specified by the EE certificate's IP address delegation extension.
o IPアドレス委任拡張[RFC3779]は、エンドエンティティ（EE）証明書（ROA内に含まれる）に存在し、ROAの各IPアドレスプレフィックス（ES）はEE証明書によって指定されたIPアドレスのセットに含まれていますIPアドレス委任拡張機能。
There is no assumption of confidentiality for the data in a ROA; it is anticipated that ROAs will be stored in repositories that are accessible to all ISPs, and perhaps to all Internet users. There is no explicit authentication associated with a ROA, since the PKI used for ROA validation provides authorization but not authentication. Although the ROA is a signed, application-layer object, there is no intent to convey non-repudiation via a ROA.
ROA内のデータの機密性の仮定はありません。RoASは、すべてのISP、およびおそらくすべてのインターネットユーザーがアクセスできるリポジトリに保存されると予想されます。ROA検証に使用されるPKIは認証ではなく、認証を提供するため、ROAに関連する明示的な認証はありません。ROAは署名されたアプリケーションレイヤーオブジェクトですが、ROAを介して非repudiationを伝える意図はありません。
The purpose of a ROA is to convey authorization for an AS to originate a route to the prefix(es) in the ROA. Thus, the integrity of a ROA MUST be established. The ROA specification makes use of the RPKI signed object format; thus, all security considerations in [RFC6488] also apply to ROAs. Additionally, the signed object profile uses the CMS signed message format for integrity; thus, ROAs inherit all security considerations associated with that data structure.
ROAの目的は、ROAのプレフィックス（ES）へのルートを発生するASの許可を伝えることです。したがって、ROAの完全性を確立する必要があります。ROA仕様は、RPKI署名されたオブジェクト形式を使用しています。したがって、[RFC6488]のすべてのセキュリティ上の考慮事項もROASに適用されます。さらに、署名されたオブジェクトプロファイルは、整合性のためにCMS署名されたメッセージ形式を使用します。したがって、ROAはそのデータ構造に関連するすべてのセキュリティ上の考慮事項を継承します。
The right of the ROA signer to authorize the target AS to originate routes to the prefix(es) is established through use of the address space and AS number PKI described in [RFC6480]. Specifically, one MUST verify the signature on the ROA using an X.509 certificate issued under this PKI, and check that the prefix(es) in the ROA match those in the certificate's address space extension.
ROA署名者の権利は、プレフィックスへのルートを発生するターゲットを承認する権利と、アドレス空間の使用と[RFC6480]で説明されている番号PKIとして確立されます。具体的には、このPKIに基づいて発行されたX.509証明書を使用してROAの署名を確認し、ROAのプレフィックスが証明書のアドレススペース拡張機能のプレフィックスと一致することを確認する必要があります。
IANA has registered the following RPKI Signed Object:
IANAは、次のRPKI署名されたオブジェクトを登録しました。
ROA 1.2.840.113549.1.9.16.1.24 [RFC6482]
ROA 1.2.840.113549.1.9.16.1.24 [RFC6482]
The authors wish to thank Charles Gardiner and Russ Housley for their help and contributions. Additionally, the authors would like to thank Rob Austein, Roque Gagliano, Danny McPherson, and Sam Weiler for their careful reviews and helpful comments.
著者は、チャールズガーディナーとラストハウズリーの助けと貢献に感謝したいと考えています。さらに、著者は、慎重なレビューと有益なコメントをしてくれたロブ・オーストイン、ロケ・ガリアーノ、ダニー・マクファーソン、サム・ワイラーに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652] Housley、R。、「暗号化メッセージ構文（CMS）」、STD 70、RFC 5652、2009年9月。
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC3779] Lynn、C.、Kent、S。、およびK. Seo、「IPアドレスおよび識別子としてのX.509拡張」、RFC 3779、2004年6月。
[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.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012.
[RFC6487] Huston、G.、Michaelson、G。、およびR. Loomans、「X.509 PKIXリソース証明書のプロファイル」、RFC 6487、2012年2月。
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, February 2012.
[RFC6488] Lepinski、M.、Chi、A。、およびS. Kent、「リソース公開キーインフラストラクチャ（RPKI）の署名されたオブジェクトテンプレート」、RFC 6488、2012年2月。
[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).
[X.690] ITU-T推奨X.690（2002）|ISO/IEC 8825-1：2002、情報技術-ASN.1エンコーディングルール：基本エンコードルール（BER）、標準エンコーディングルール（CER）、および識別されたエンコードルール（DER）の仕様。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
[RFC6480] Lepinski、M。およびS. Kent、「安全なインターネットルーティングをサポートするインフラストラクチャ」、RFC 6480、2012年2月。
Appendix A: ASN.1 Module
付録A：ASN.1モジュール
This normative appendix provides an ASN.1 module that specifies the ROA content in ASN.1 syntax.
この規範的な付録は、ASN.1構文のROAコンテンツを指定する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
終わり
Authors' Addresses
著者のアドレス
Matt Lepinski BBN Technologies 10 Moulton Street Cambridge MA 02138 EMail: mlepinski@bbn.com
Matt Lepinski BBN Technologies 10 Moulton Street Cambridge MA 02138メール：mlepinski@bbn.com
Stephen Kent BBN Technologies 10 Moulton Street Cambridge MA 02138 EMail: skent@bbn.com
Stephen Kent BBN Technologies 10 Moulton Street Cambridge MA 02138メール：skent@bbn.com
Derrick Kong BBN Technologies 10 Moulton Street Cambridge MA 02138 EMail: dkong@bbn.com
Derrick Kong BBN Technologies 10 Moulton Street Cambridge MA 02138メール：dkong@bbn.com