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)
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は、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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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]を参照。）このシステムの一部として、機構は、エンティティはASは、そのブロック内の1つ以上のプレフィックスへのルートをアドバタイズするためにIPアドレスのブロックホルダーによって許可を与えられていることを確認できるようにするために必要とされます。 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は、ROAコンテンツのCrytopgraphicメッセージ構文（CMS）[RFC5652]ラッパーならびにRPKIオブジェクトを締結するための一般的な検証手順を定義RPKIデジタル署名オブジェクト、[RFC6488]のためのテンプレートを利用します。したがって、（[RFC6488]のセクション4を参照）ROAの仕様を完了するために、このドキュメントは、定義します：
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はencapContentInfoオブジェクト内の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].
ROA e-コンテンツ2. ASN.1構文。 （これは、ASが経路ならびにASルートを発信することができるれたプレフィックスを発信することが許可されている指定のペイロードである。）ROA e-コンテンツの識別符号化規則（DER）[X.690]を使用してエンコードASN.1です。
3. An additional step required to validate ROAs (in addition to the validation steps specified in [RFC6488]).
3.（[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アドレスとAS識別子のための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].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、 "推奨NOT"、および「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はencapContentInfoオブジェクト並びにのSignerInfoオブジェクト内のコンテンツタイプの符号付き属性（[RFC6488]を参照）のeContentType内の両方を表示する必要があります。
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:
それがルートを発信するために、アドレス空間の所有者によって承認され、アドバタイズされます1つまたは複数のIPアドレスプレフィックスのリストされているようにROAの内容は、単一を識別します。アドレス空間の所有者が複数のASを承認する必要がある場合は、アドレスのプレフィックスの同じセットを宣伝するために、ホルダーの問題複数の資産収益率、AS番号あたり1。 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]).
（[RFC6488]を参照）、このコンテンツはencapContentInfo内e-コンテンツとして表示されることに留意されたいです。
The version number of the RouteOriginAttestation MUST be 0.
RouteOriginAttestationのバージョン番号は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アドレス委任拡張で使用されるものよりも限定的であることに注意してください。
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をサポートしています。したがって、addressFamilyは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]を参照してください）。存在する場合は、maxLengthのは、（IPv6のIPv4の32および128）のアドレスファミリーのIPアドレスの長さ（ビット単位）の整数より大きいかまたは添付プレフィックスの長さに等しく、かつ以下でなければなりません。存在する場合、maxLengthのは、ASは、広告を掲載することが許可されたIPアドレスのプレフィックスの最大長を指定します。 （例えば、IPアドレスプレフィックスが203.0.113 / 24であり、maxLengthの26である場合、ASは、この例では26の最大長さを有する任意のより具体的なプレフィックスを通知することを許可され、ASは203.0を宣伝することを許可されます/ 24 0.113、203.0.113.128/25、又は203.0.113.0/25はなく203.0.113.0/27。）maxLengthのが存在しない場合、ASのみ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は（別個ROAIPAddress要素内の）別のIPアドレス・プレフィクスに包含される（ROAIPAddress要素内の）IPアドレスプレフィックスを含んでいてもよいことに留意されたいです。例えば、ROAは、（ROAが203.0.113で始まる任意のプレフィックスを通知するように示されている認可になるのmaxLength 26と接頭203.0.113 / 24、ならびにmaxLengthの28と接頭203.0.113.0/28を含んでいてもよいです24と26の最大長さ、ならびに特定のプレフィックス203.0.113.0/28の最小の長さである。）また、ROAは、IPアドレスプレフィックスがどちらの場合も同じ2つのROAIPAddress要素を含んでいてもよいです。このような場合には、短い方のmaxLengthとROAIPAddressが示されているように追加の権限を付与していないため、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.
IPアドレス委譲拡張[RFC3779] O（ROA内に含まれる）エンドエンティティ（EE）証明書に存在し、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のデータの機密性のない仮定はありません。資産収益率はすべてのISPにアクセス可能なリポジトリに格納され、おそらくすべてのインターネットユーザーにされることが予想されます。 ROA検証に使用PKIは、認可ではなく認証を提供するため、ROAに関連した明示的な認証は、ありません。 ROAは、署名された、アプリケーション層のオブジェクトであるが、ROAを介して否認防止を伝達する意図はありません。
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の目的は、ASはROAで接頭語（ES）へのルートを発信するための許可を伝えることです。このように、ROAの整合性が確立されなければなりません。 ROA仕様はRPKI署名されたオブジェクトのフォーマットを利用します。したがって、[RFC6488]ですべてのセキュリティの考慮も資産収益率に適用されます。また、署名済みオブジェクト・プロファイルは、整合性のためのCMS署名されたメッセージの形式を使用しています。したがって、資産収益率は、そのデータ構造に関連付けられたすべてのセキュリティ上の考慮事項を継承します。
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.
接頭語（ES）へのルートを発信するようにターゲットを承認するROA署名者の権利は、アドレス空間の使用を介して、[RFC6480]に記載の番号PKIとして確立されています。具体的には、1本のPKIに基づいて発行されたX.509証明書を使用してROAの署名を検証し、ROAで接頭語（ES）は、証明書のアドレス空間の拡張機能のものと一致していることをチェックしなければなりません。
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.
著者は、彼らの助けと貢献のためにチャールズ・ガーディナーとラスHousleyに感謝したいです。さらに、著者は彼らの慎重な口コミや有益なコメントのためにロブAusteinと、ロケガリアーノ、ダニー・マクファーソン、そしてサム・ワイラーに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]リン、C.、ケント、S.、およびK.ソ、 "IPアドレスとAS識別子のための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]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネット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]ヒューストン、G.、マイケルソン、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.、チー、A.、およびS.ケントは、RFC 6488、2012年2月 "リソースの公開鍵インフラストラクチャ（RPKI）のためのオブジェクト・テンプレートを署名"。
[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）の仕様、Canonicalの符号化規則（CER）、および顕著な符号化規則（DER）。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
[RFC6480] Lepinski、M.とS.ケント、 "安全なインターネットルーティングをサポートするインフラストラクチャ"、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 }
RPKI-ROA {ISO（1）部材本体（2）米国（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
マット・Lepinski BBNテクノロジーズ10モールトンストリートケンブリッジMA 02138 Eメール：mlepinski@bbn.com
Stephen Kent BBN Technologies 10 Moulton Street Cambridge MA 02138 EMail: skent@bbn.com
スティーブン・ケントBBNテクノロジーズ10モールトンストリートケンブリッジMA 02138 Eメール：skent@bbn.com
Derrick Kong BBN Technologies 10 Moulton Street Cambridge MA 02138 EMail: dkong@bbn.com
デリック・香港BBNテクノロジーズ10モールトンストリートケンブリッジMA 02138 Eメール：dkong@bbn.com