[要約] RFC 6480は、セキュアなインターネットルーティングをサポートするためのインフラストラクチャに関するものです。その目的は、信頼性の高いルーティング情報の配信と、不正なルーティング情報の検出と防止を実現することです。
Internet Engineering Task Force (IETF) M. Lepinski
Request for Comments: 6480 S. Kent
Category: Informational BBN Technologies
ISSN: 2070-1721 February 2012
An Infrastructure to Support Secure Internet Routing
安全なインターネットルーティングをサポートするインフラストラクチャ
Abstract
概要
This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters.
このドキュメントでは、インターネットルーティングのセキュリティの改善をサポートするインフラストラクチャのアーキテクチャについて説明しています。このアーキテクチャの基礎は、IPアドレススペースと自律システム（AS）番号の割り当て階層を表すリソース公開キーインフラストラクチャ（RPKI）です。RPKIを構成するデータオブジェクトを保存および配布するための分散リポジトリシステム、およびルーティングセキュリティの改善に必要なその他の署名されたオブジェクト。このアーキテクチャの最初のアプリケーションとして、ドキュメントは、IPアドレス空間の正当な保有者が、そのアドレス空間へのルートを発信することを1つ以上のASESが明示的かつ検証する方法を説明しています。このような検証可能な承認は、たとえば、BGPルートフィルターをより安全に構築するために使用できます。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc6480.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6480で取得できます。
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 ....................................................3
1.1. Terminology ................................................4
2. Public Key Infrastructure for Internet Number Resources .........4
2.1. Role in the Overall Architecture ...........................5
2.2. CA Certificates ............................................6
2.3. End-Entity (EE) Certificates ...............................7
2.4. Trust Anchors ..............................................8
3. Route Origination Authorizations ................................9
3.1. Role in the Overall Architecture ...........................9
3.2. Syntax and Semantics ......................................10
4. Repositories ...................................................11
4.1. Role in the Overall Architecture ..........................12
4.2. Contents and Structure ....................................12
4.3. Access Protocols ..........................................14
4.4. Access Control ............................................15
5. Manifests ......................................................15
5.1. Syntax and Semantics ......................................15
6. Local Cache Maintenance ........................................16
7. Common Operations ..............................................17
7.1. Certificate Issuance ......................................17
7.2. CA Key Rollover ...........................................18
7.3. ROA Management ............................................19
7.3.1. Single-Homed Subscribers ...........................20
7.3.2. Multi-Homed Subscribers ............................20
7.3.3. Provider-Independent Address Space .................21
8. Security Considerations ........................................21
9. IANA Considerations ............................................21
10. Acknowledgments ...............................................22
11. References ....................................................22
11.1. Normative References .....................................22
11.2. Informative References ...................................23
This document describes an architecture for an infrastructure to support improved security for BGP routing [RFC4271] for the Internet. The architecture encompasses three principle elements:
このドキュメントは、インターネットのBGPルーティング[RFC4271]のセキュリティの改善をサポートするインフラストラクチャのアーキテクチャについて説明しています。アーキテクチャには、3つの主要な要素が含まれます。
o Resource Public Key Infrastructure (RPKI)
o リソース公開キーインフラストラクチャ（RPKI）
o digitally signed routing objects to support routing security
o ルーティングセキュリティをサポートするために、デジタルで署名されたルーティングオブジェクト
o a distributed repository system to hold the PKI objects and the signed routing objects
o PKIオブジェクトと署名されたルーティングオブジェクトを保持するための分散リポジトリシステム
The architecture described by this document enables an entity to verifiably assert that it is the legitimate holder of a set of IP addresses or a set of Autonomous System (AS) numbers. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. In addition to this initial application, the infrastructure defined by this architecture also is intended to provide future support for security protocols such as Secure BGP [S-BGP] or Secure Origin BGP [soBGP]. This architecture is applicable to the routing of both IPv4 and IPv6 datagrams. IPv4 and IPv6 are currently the only address families supported by this architecture. Thus, for example, use of this architecture with MPLS labels is beyond the scope of this document.
このドキュメントで説明されているアーキテクチャにより、エンティティは、IPアドレスのセットまたは一連の自律システム（AS）番号の正当な保有者であると主張することができます。このアーキテクチャの最初のアプリケーションとして、ドキュメントは、IPアドレス空間の正当な保有者が、そのアドレス空間へのルートを発信することを1つ以上のASESが明示的かつ検証する方法を説明しています。このような検証可能な承認は、たとえば、BGPルートフィルターをより安全に構築するために使用できます。この最初のアプリケーションに加えて、このアーキテクチャで定義されたインフラストラクチャは、Secure BGP [S-BGP]やSecure Origin BGP [SOBGP]などのセキュリティプロトコルの将来のサポートを提供することも目的としています。このアーキテクチャは、IPv4データグラムとIPv6データグラムの両方のルーティングに適用できます。IPv4とIPv6は現在、このアーキテクチャでサポートされている唯一の住所ファミリです。したがって、たとえば、MPLSラベルでこのアーキテクチャを使用することは、このドキュメントの範囲を超えています。
In order to facilitate deployment, the architecture takes advantage of existing technologies and practices. The structure of the PKI element of the architecture corresponds to the existing resource allocation structure. Thus management of this PKI is a natural extension of the resource-management functions of the organizations that are already responsible for IP address and AS number resource allocation. Likewise, existing resource allocation and revocation practices have well-defined correspondents in this architecture. Note that while the initial focus of this architecture is routing security applications, the PKI described in this document could be used to support other applications that make use of attestations of IP address or AS number resource holdings.
展開を促進するために、アーキテクチャは既存のテクノロジーと実践を活用します。アーキテクチャのPKI要素の構造は、既存のリソース割り当て構造に対応しています。したがって、このPKIの管理は、IPアドレスを既に担当している組織および数のリソース割り当てとして、リソース管理機能の自然な拡張です。同様に、既存のリソースの割り当ておよび取り消し慣行には、このアーキテクチャに明確に定義された特派員がいます。このアーキテクチャの最初の焦点はセキュリティアプリケーションのルーティングですが、このドキュメントで説明されているPKIを使用して、IPアドレスの証明または番号リソース保有を使用する他のアプリケーションをサポートできることに注意してください。
To ease implementation, existing IETF standards are used wherever possible; for example, extensive use is made of the X.509 certificate profile defined by the Public Key Infrastructure using X.509 (PKIX) [RFC5280] working group and the extensions for IP addresses and AS numbers representation defined in RFC 3779 [RFC3779]. Also, Cryptographic Message Syntax (CMS) [RFC5652] is used as the syntax
実装を容易にするために、可能な限り既存のIETF標準が使用されます。たとえば、X.509（PKIX）[RFC5280]ワーキンググループとIPアドレスの拡張機能、およびRFC 3779 [RFC3779]で定義されている数値表現として、X.509インフラストラクチャによって定義されたX.509証明書プロファイルで広範な使用が行われます。また、暗号化メッセージ構文（CMS）[RFC5652]は構文として使用されます
for the newly defined signed objects [RFC6488] required by this infrastructure.
このインフラストラクチャで必要な新しく定義された署名されたオブジェクト[RFC6488]の場合。
As noted above, the architecture is comprised of three main components: an X.509 PKI in which certificates attest to holdings of IP address space and AS numbers; non-certificate signed objects (including route origination authorizations and manifests) used by the infrastructure; and a distributed repository system that makes all of these signed objects available for use by ISPs in making routing decisions. These three basic components enable several security functions; most notably the cryptographic validation that an autonomous system is authorized to originate routes to a given prefix [RFC6483].
上記のように、アーキテクチャは3つの主要なコンポーネントで構成されています。X.509 PKIでは、証明書がIPアドレススペースの保有と数字として証明されています。インフラストラクチャで使用される非認証署名されたオブジェクト（ルートオリジネーション認可およびマニフェストを含む）。また、これらの署名されたオブジェクトのすべてを、ルーティング決定を行う際にISPが使用できるようにする分散リポジトリシステム。これらの3つの基本コンポーネントは、いくつかのセキュリティ関数を有効にします。最も顕著なのは、自律システムが特定のプレフィックスへのルートを発信することが許可されているという暗号化の検証[RFC6483]です。
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]。
Throughout this document, we use the terms "address space holder" or "holder of IP address space" interchangeably to refer to a legitimate holder of IP address space who has received this address space through the standard IP address allocation hierarchy. That is, the address space holder has either directly received the address space as an allocation from a Regional Internet Registry (RIR) or IANA; or else the address space holder has received the address space as a sub-allocation from a National Internet Registry (NIR) or Local Internet Registry (LIR). We use the term "resource holder" to refer to a legitimate holder of either IP address or AS number resources.
このドキュメント全体を通して、「アドレススペースホルダー」または「IPアドレススペースのホルダー」という用語を使用して、標準のIPアドレス割り当て階層を通じてこのアドレススペースを受け取ったIPアドレススペースの正当な保有者を参照します。つまり、アドレススペースホルダーは、地域のインターネットレジストリ（RIR）またはIANAからの割り当てとしてアドレススペースを直接受信しました。または、アドレススペースホルダーは、National Internet Registry（NIR）またはローカルインターネットレジストリ（LIR）からのサブアロケーションとしてアドレススペースを受け取りました。「リソースホルダー」という用語を使用して、IPアドレスの正当な所有者または数値リソースを参照します。
Throughout this document, we use the terms "registry" and "ISP" to refer to an entity that has an IP address space and/or AS number allocation that it is permitted to sub-allocate.
このドキュメント全体を通して、「レジストリ」と「ISP」という用語を使用して、IPアドレススペースを持つエンティティおよび/またはサブアロッケートが許可されている数値割り当てとして参照します。
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]に記載されているように解釈されます。
Because the holder of a block of IP address space is entitled to define the topological destination of IP datagrams whose destinations fall within that block, decisions about inter-domain routing are inherently based on knowledge of the allocation of the IP address space. Thus, a basic function of this architecture is to provide
IPアドレススペースのブロックの所有者は、そのブロック内にあるIPデータグラムのトポロジートの目的地を定義する権利があるため、ドメイン間ルーティングに関する決定は、本質的にIPアドレススペースの割り当ての知識に基づいています。したがって、このアーキテクチャの基本的な機能は
cryptographically verifiable attestations as to these allocations. In current practice, the allocation of IP addresses is hierarchical. The root of the hierarchy is IANA. Below IANA are five Regional Internet Registries (RIRs), each of which manages address and AS number allocation within a defined geopolitical region. In some regions, the third tier of the hierarchy includes National Internet Registries (NIRs) as well as Local Internet Registries (LIRs) and subscribers with so-called provider-independent ("portable") allocations. (The term "LIR" is used in some regions to refer to what other regions define as an ISP. Throughout the rest of this document, we will use the term "LIR/ISP" to simplify references to these entities.) In other regions, the third tier consists only of LIRs/ISPs and subscribers with provider-independent allocations.
これらの割り当てに関する暗号化的に検証可能な証明。現在の実践では、IPアドレスの割り当ては階層的です。階層のルートはIANAです。IANAの下には、5つの地域インターネットレジストリ（RIR）があり、それぞれがアドレスを管理し、定義された地政学的地域内の数値割り当てとして管理しています。一部の地域では、階層の3番目の層には、国家インターネットレジストリ（NIRS）、ローカルインターネットレジストリ（LIR）と、いわゆるプロバイダーに依存しない（「ポータブル」）割り当てを備えた加入者が含まれます。（「LIR」という用語は、他の地域がISPと定義するものを参照するために使用されています。このドキュメントの残りの部分を通して、これらのエンティティへの参照を簡素化するために「LIR/ISP」という用語を使用します。）、3番目の層は、LIRS/ISPとプロバイダーに依存しない割り当てを備えた加入者のみで構成されています。
In general, the holder of a block of IP address space may sub-allocate portions of that block, either to itself (e.g., to a particular unit of the same organization), or to another organization, subject to contractual constraints established by the registries. Because of this structure, IP address allocations can be described naturally by a hierarchic public key infrastructure, in which each certificate attests to an allocation of IP addresses, and issuance of subordinate certificates corresponds to sub-allocation of IP addresses. The above reasoning holds true for AS number resources as well, with the difference that, by convention, AS numbers may not be sub-allocated except by RIRs or NIRs. Thus, allocations of both IP addresses and AS numbers can be expressed by the same PKI. Such a PKI, which is henceforth referred to as the "Resource Public Key Infrastructure (RPKI)", is a central component of this architecture.
一般に、IPアドレス空間のブロックの所有者は、そのブロックの部分をそれ自体（例えば、同じ組織の特定のユニット）、またはレジストリによって確立された契約上の制約を条件として、そのブロックの部分をサブアロッカ化することができます。。この構造のため、IPアドレスの割り当ては、各証明書がIPアドレスの割り当てを証明し、下位証明書の発行を証明する階層的な公開キーインフラストラクチャによって自然に説明できます。上記の推論は、数字のリソースにも当てはまります。これは、慣習により、RIRSまたはNIRSを除いて数字がサブアロックされない可能性があるためです。したがって、両方のIPアドレスとAS番号の割り当ては、同じPKIで表現できます。このようなPKIは、今後「リソース公開キーインフラストラクチャ（RPKI）」と呼ばれ、このアーキテクチャの中心的なコンポーネントです。
Certificates in this PKI are called resource certificates, and conform to the certificate profile for such certificates [RFC6487]. Resource certificates attest to the allocation by the (certificate) issuer of IP addresses or AS numbers to the subject. They do this by binding the public key contained in the resource certificate to the IP addresses or AS numbers included in the certificate's IP Address Delegation or AS Identifier Delegation extensions, respectively, as defined in RFC 3779 [RFC3779].
このPKIの証明書はリソース証明書と呼ばれ、そのような証明書の証明書プロファイルに準拠しています[RFC6487]。リソース証明書は、IPアドレスの（証明書）発行者による割り当て、または主題への番号として証明されています。これらは、RFC 3779 [RFC3779]で定義されているように、リソース証明書に含まれる公開キーをIPアドレスに拘束するか、証明書のIPアドレス代表団または識別子委任拡張機能としてそれぞれ識別子委任拡張機能としてバインドすることにより、これを行います。
An important property of this PKI is that certificates do not attest to the identity of the subject. Therefore, the subject names used in certificates are not intended to be "descriptive". That is, the resource PKI is intended to provide authorization, but not authentication. This is in contrast to most PKIs where the issuer ensures that the descriptive subject name in a certificate is properly associated with the entity that holds the private key corresponding to the public key in the certificate. Because issuers
このPKIの重要な特性は、証明書が主題の身元を証明していないことです。したがって、証明書で使用される主題名は「記述的」であることを意図していません。つまり、リソースPKIは認証ではなく承認を提供することを目的としています。これは、発行者が証明書の記述的な件名名が、証明書の公開鍵に対応する秘密鍵を保持するエンティティに適切に関連付けられていることを保証するほとんどのPKIとは対照的です。発行者だから
need not verify the right of an entity to use a subject name in a certificate, they avoid the costs and liabilities of such verification. This makes it easier for these entities to take on the additional role of Certification Authority (CA).
証明書で主題名を使用するエンティティの権利を確認する必要はありません。彼らは、そのような検証の費用と負債を回避します。これにより、これらのエンティティが認証機関（CA）の追加の役割を引き受けることが容易になります。
Most of the certificates in the PKI assert the basic facts on which the rest of the infrastructure operates. CA certificates within the PKI attest to IP address space and AS number holdings. End-entity (EE) certificates are issued by resource holder CAs to delegate the authority attested by their allocation certificates. The primary use for EE certificates is the validation of Route Origination Authorizations (ROAs), signed objects which provide an explicit authorization by an address holder that a given AS is permitted to originate routes to a set of addresses (see Section 3). End-entity certificates are also used to verify other signed objects, such as manifests, which will be used to help ensure the integrity of the repository system (see Section 5).
PKIの証明書のほとんどは、残りのインフラストラクチャが動作する基本的な事実を主張しています。PKI内のCA証明書は、IPアドレススペースと数の保有を証明しています。エンドエンティティ（EE）証明書は、リソースホルダーCASによって発行され、割り当て証明書によって証明された当局を委任します。EE証明書の主な用途は、ルートオリジネーション認可（ROA）の検証であり、署名されたオブジェクトであり、アドレス保有者による明示的な承認を提供します。エンドエンティティ証明書は、リポジトリシステムの完全性を確保するために使用されるマニフェストなどの他の署名されたオブジェクトを検証するためにも使用されます（セクション5を参照）。
Any resource holder who is authorized to sub-allocate these resources must be able to issue resource certificates to correspond to these sub-allocations. Thus, for example, CA certificates will be associated with IANA and each of the RIRs, NIRs, and LIRs/ISPs. Also, a CA certificate is required to enable a resource holder to issue ROAs, because it must issue the corresponding end-entity certificate used to validate each ROA. Thus, some entities that do not sub-allocate their resources also will need to have CA certificates for their allocations, e.g., a multi-homed subscriber with a provider-independent allocation, to enable them to issue ROAs. (A subscriber who is not multi-homed, whose allocation comes from an LIR/ISP, and who has not moved to a different LIR/ISP, need not be represented in the PKI. Moreover, a multi-homed subscriber with an allocation from an LIR/ISP may or may not need to be explicitly represented, as discussed in Section 7.3.2).
これらのリソースをサブアロッカ化することを許可されているリソースホルダーは、これらのサブアロケーションに対応するためにリソース証明書を発行できる必要があります。したがって、たとえば、CA証明書は、IANAおよび各RIR、NIRS、およびLIRS/ISPのそれぞれに関連付けられます。また、各ROAを検証するために使用される対応するエンドエンティティ証明書を発行する必要があるため、リソースホルダーがROASを発行できるようにするには、CA証明書が必要です。したがって、リソースをサブアロッカ化しない一部のエンティティは、割り当てのためにCA証明書を持つ必要があります。（マルチホームされていないサブスクライバー、LIR/ISPからの割り当ては、別のLIR/ISPに移動していない場合は、PKIで表現する必要はありません。さらに、セクション7.3.2で説明したように、LIR/ISPを明示的に表現する必要がある場合とそうでない場合があります。
Unlike in most PKIs, the distinguished name of the subject in a CA certificate is chosen by the certificate issuer. The subject's distinguished name must not attempt to convey the identity of the subject in a descriptive fashion. The subject's distinguished name must include the CommonName attribute and may additionally include the serial attribute.
ほとんどのPKIとは異なり、CA証明書の主題の著名な名前は証明書発行者によって選択されます。被験者の著名な名前は、被験者の身元を説明的に伝えようとしてはなりません。被験者の著名な名前には、CommonName属性を含める必要があり、さらにシリアル属性を含めることができます。
In this PKI, the certificate issuer, being an RIR, NIR, or LIR/ISP, is not in the business of verifying the legal right of the subject to assert a particular identity. Therefore, selecting a distinguished name that does not convey the identity of the subject in a descriptive fashion minimizes the opportunity for the subject to
このPKIでは、RIR、NIR、またはLIR/ISPである証明書発行者は、特定のIDを主張する被験者の法的権利を検証するビジネスではありません。したがって、説明的な方法で主題の身元を伝えない著名な名前を選択すると、被験者の機会が最小限に抑えられます
misuse the certificate to assert an identity, and thus minimizes the legal liability of the issuer. Since all CA certificates are issued to subjects with whom the issuer has an existing relationship, it is recommended that the issuer select a subject name that enables the issuer to easily link the certificate to existing database records associated with the subject. For example, an authority may use internal database keys or subscriber IDs as the subject's common name in issued certificates.
証明書を誤用してアイデンティティを主張するため、発行者の法的責任を最小限に抑えます。すべてのCA証明書は、発行者が既存の関係を持っている被験者に発行されるため、発行者は、発行者が証明書を主題に関連付けられた既存のデータベースレコードに簡単にリンクできるようにするサブジェクト名を選択することをお勧めします。たとえば、当局は、発行された証明書における被験者の共通名として内部データベースキーまたはサブスクライバーIDを使用する場合があります。
Although the subject's common name in a certificate does not convey identity, it is still the case that the common name must be unique among all subjects to whom a certification authority issues certificates. That is, a CA must not issue certificates to two different entities that use the same common name for the subject.
証明書に含まれる被験者の共通名はIDを伝えませんが、認定機関が証明書を発行するすべての被験者の間で共通名が一意でなければならない場合があります。つまり、CAは、主題に同じ共通名を使用する2つの異なるエンティティに証明書を発行してはなりません。
Each resource certificate attests to an allocation of resources to a resource holder, so entities that have allocations from multiple sources will have multiple CA certificates. Note that when an entity receives multiple certificates from different issuers, the subject names in these certificates will generally be different. A CA also may issue distinct certificates for each distinct allocation to the same entity, if the CA and the resource holder agree that such an arrangement will facilitate management and use of the certificates. For example, an LIR/ISP may have several certificates issued to it by one registry, each describing a distinct set of address blocks, because the LIR/ISP desires to treat the allocations as separate.
各リソース証明書は、リソースホルダーへのリソースの割り当てを証明しているため、複数のソースからの割り当てがあるエンティティには複数のCA証明書があります。エンティティが異なる発行者から複数の証明書を受け取った場合、これらの証明書の主題名は一般に異なることに注意してください。CAとリソースホルダーが、そのような取り決めが証明書の管理と使用を促進することに同意した場合、CAは同じエンティティへの異なる割り当てごとに異なる証明書を発行する場合があります。たとえば、LIR/ISPには、1つのレジストリによっていくつかの証明書が発行されている場合があり、それぞれが別々のアドレスブロックセットを記述しています。LIR/ISPは、割り当てを個別として扱うことを望んでいるためです。
The private key corresponding to a public key contained in an EE certificate is not used to sign other certificates in a PKI. The primary function of end-entity certificates in this PKI is the verification of signed objects that relate to the usage of the resources described in the certificate, e.g., ROAs and manifests.
EE証明書に含まれる公開キーに対応する秘密鍵は、PKIで他の証明書に署名するために使用されません。このPKIにおけるエンドエンティティ証明書の主な機能は、証明書に記載されているリソースの使用に関連する署名されたオブジェクトの検証です。
For ROAs and manifests, there will be a one-to-one correspondence between end-entity certificates and signed objects, i.e., the private key corresponding to each end-entity certificate is used to sign exactly one object, and each object is signed with only one key. This property allows the PKI to be used to revoke these signed objects, rather than creating a new revocation mechanism. When the end-entity certificate used to sign an object has been revoked, the signature on that object (and any corresponding assertions) will be considered invalid, so a signed object can be effectively revoked by revoking the end-entity certificate used to sign it.
ROASおよびマニフェストの場合、エンドエンティティ証明書と署名されたオブジェクトの間に1対1の対応があります。つまり、各エンドエンティティ証明書に対応する秘密鍵は、正確に1つのオブジェクトに署名するために使用され、各オブジェクトはで署名されますキーは1つだけです。このプロパティにより、PKIを使用して、新しい取り消しメカニズムを作成するのではなく、これらの署名されたオブジェクトを取り消すことができます。オブジェクトに署名するために使用されるエンドエンティティ証明書が取り消された場合、そのオブジェクトの署名（および対応するアサーション）は無効と見なされるため、署名に使用されるエンドエンティティ証明書を取り消すことで署名されたオブジェクトを効果的に取り消すことができます。
A secondary advantage to this one-to-one correspondence is that the private key corresponding to the public key in a certificate is used
この1対1の通信に対する二次的な利点は、証明書の公開鍵に対応する秘密鍵が使用されていることです
exactly once in its lifetime, and thus can be destroyed after it has been used to sign its one object. This fact should simplify key management, since there is no requirement to protect these private keys for an extended period of time.
一生に一度に1回、したがって、1つのオブジェクトに署名するために使用された後に破壊される可能性があります。これらのプライベートキーを長期間保護するための要件がないため、この事実は主要な管理を簡素化するはずです。
The EE certificate used to verify a signed object appears in the Cryptographic Message Syntax (CMS) wrapper (see [RFC6488]) of the signed object. Therefore, it is not necessary to transmit the EE certificate separately from the signed object. Likewise, it is not necessary for the EE certificate to appear in the RPKI repository system except as part of the corresponding signed object.
署名されたオブジェクトを確認するために使用されるEE証明書は、署名されたオブジェクトの暗号化メッセージ構文（CMS）ラッパー（[RFC6488]を参照）に表示されます。したがって、EE証明書を署名されたオブジェクトとは別に送信する必要はありません。同様に、対応する署名されたオブジェクトの一部を除き、EE証明書がRPKIリポジトリシステムに表示される必要はありません。
Although this document describes only two uses for end-entity certificates, additional uses will likely be defined in the future. For example, end-entity certificates could be used as a more general authorization for their subjects to act on behalf of the specified resource holder. This could facilitate authentication of inter-ISP interactions, or authentication of interactions with the repository system. These additional uses for end-entity certificates may require retention of the corresponding private keys, even though such retention is not required for keys used to sign ROAs and manifests.
このドキュメントでは、エンドエンティティ証明書の2つの使用のみを説明していますが、追加の用途は将来定義される可能性があります。たとえば、エンドエンティティ証明書は、指定されたリソースホルダーに代わって行動するためのより一般的な許可として使用できます。これにより、ISP間相互作用の認証、またはリポジトリシステムとの相互作用の認証が容易になります。エンドエンティティ証明書のこれらの追加の使用は、ROASとマニフェストに署名するために使用されるキーにそのような保持は必要ありませんが、対応するプライベートキーの保持が必要になる場合があります。
In any PKI, each relying party (RP) chooses its own set of trust anchors (TAs). This general property of PKIs applies here as well. There is an extant IP address space and AS number allocation hierarchy, and thus IANA and/or the five RIRs are obvious candidates to be default TAs here. Nonetheless, each RP ultimately chooses the set of trust anchors it will use for certificate validation.
任意のPKIでは、それぞれの依存パーティー（RP）が独自の信頼アンカー（TA）を選択します。PKISのこの一般的な特性もここにも適用されます。現存するIPアドレススペースがあり、数の割り当て階層としてあり、したがって、IANAおよび/または5つのRIRがここでデフォルトのTASであることの明らかな候補です。それにもかかわらず、各RPは最終的に、証明書の検証に使用する信頼のアンカーのセットを選択します。
For example, an RP (e.g., an LIR/ISP) could create a trust anchor to which all address space and/or all AS numbers are assigned, and for which the RP knows the corresponding private key. The RP could then issue certificates under this trust anchor to whatever entities in the PKI it wishes, with the result that the certification paths terminating at this locally installed trust anchor will satisfy the validation requirements specified in RFC 3779. A large ISP that uses private IP address space (i.e., RFC 1918) and runs BGP internally will need to create this sort of trust anchor to accommodate a CA to which all private address space is assigned. The RP could then issue certificates under this CA that correspond to the RP's internal use of private address space.
たとえば、RP（例：LIR/ISP）は、すべてのアドレススペースおよび/またはすべてが割り当てられ、RPが対応する秘密鍵を知っている信頼アンカーを作成できます。その後、RPはこのトラストアンカーに基づいて、希望するPKIのあらゆるエンティティに証明書を発行することができます。その結果、このローカルにインストールされたトラストアンカーで終了する認定パスは、RFC 3779で指定された検証要件を満たします。プライベートIPを使用する大規模なISP住所スペース（つまり、RFC 1918）および内部でBGPを実行すると、すべてのプライベートアドレススペースが割り当てられるCAに対応するために、この種の信頼アンカーを作成する必要があります。RPは、RPのプライベートアドレススペースの内部使用に対応するこのCAに基づいて証明書を発行できます。
Note that an RP who elects to create and manage its own set of trust anchors may fail to detect allocation errors that arise under such circumstances, but the resulting vulnerability is local to the RP.
独自の信頼アンカーのセットを作成および管理することを選択したRPは、そのような状況下で発生する割り当てエラーを検出できない場合がありますが、結果として生じる脆弱性はRPにローカルであることに注意してください。
It is expected that some parties within the extant IP address space and AS number allocation hierarchy may wish to publish trust anchor material for possible use by relying parties. A standard profile for the publication of trust anchor material for this public key infrastructure can be found in [RFC6490].
現存するIPアドレススペース内および数の割り当て階層としての一部の当事者は、当事者に依存することで使用可能な使用のために信頼のアンカー資料を公開したい場合があることが期待されています。この公開キーインフラストラクチャのトラストアンカー資料の公開に関する標準プロファイルは、[RFC6490]に記載されています。
The information on IP address allocation provided by the PKI is not, in itself, sufficient to guide routing decisions. In particular, BGP is based on the assumption that the AS that originates routes for a particular prefix is authorized to do so by the holder of that prefix (or an address block encompassing the prefix); the PKI contains no information about these authorizations. A Route Origination Authorization (ROA) makes such authorization explicit, allowing a holder of IP address space to create an object that explicitly and verifiably asserts that an AS is authorized to originate routes to a given set of prefixes.
PKIによって提供されるIPアドレス割り当てに関する情報は、それ自体がルーティングの決定をガイドするのに十分ではありません。特に、BGPは、特定のプレフィックスのルートを起源とするASがそのプレフィックスの所有者（またはプレフィックスを含むアドレスブロック）によってそうすることが許可されているという仮定に基づいています。PKIには、これらの承認に関する情報が含まれていません。Route Origination Authorization（ROA）は、そのような承認を明示的にし、IPアドレススペースの保有者が、特定のプレフィックスセットへのルートを発信することが許可されていることを明示的かつ検証するオブジェクトを作成できるようにします。
A ROA is an attestation that the holder of a set of prefixes has authorized an autonomous system to originate routes for those prefixes. A ROA is structured according to the format described in [RFC6482]. The validity of this authorization depends on the signer of the ROA being the holder of the prefix(es) in the ROA; this fact is asserted by an end-entity certificate from the PKI, whose corresponding private key is used to sign the ROA.
ROAは、プレフィックスのセットの所有者が、これらのプレフィックスのルートを発生させる自律システムを承認したことを証明しています。ROAは、[RFC6482]で説明されている形式に従って構成されています。この承認の妥当性は、ROAがROAのプレフィックス（ES）の所有者であるという署名者に依存します。この事実は、PKIのエンドエンティティ証明書によって主張されています。PKIの対応する秘密鍵は、ROAに署名するために使用されます。
ROAs may be used by relying parties to verify that the AS that originates a route for a given IP address prefix is authorized by the holder of that prefix to originate such a route. For example, an ISP might use validated ROAs as inputs to route filter construction for use by its BGP routers. (See [RFC6483] for information on the use of ROAs to validate the origination of BGP routes.)
ROASは、当事者に依存して使用され、特定のIPアドレスプレフィックスのルートが発生するASがそのプレフィックスの所有者によってそのようなルートを発信することを許可されていることを確認することができます。たとえば、ISPは、検証済みのROAを入力として使用して、BGPルーターで使用するためにフィルター構造をルーティングする場合があります。（BGPルートの起源を検証するためのROASの使用に関する情報については、[RFC6483]を参照してください。）
Initially, the repository system will be the primary mechanism for disseminating ROAs, since these repositories will hold the certificates and CRLs needed to verify ROAs. In addition, ROAs also could be distributed in BGP UPDATE messages or via other communication paths, if needed to meet timeliness requirements.
当初、リポジトリシステムは、ROASを検証するために必要な証明書とCRLを保持するため、ROASを広めるための主要なメカニズムになります。さらに、適時の要件を満たすために必要な場合、ROAはBGP更新メッセージまたは他の通信パスを介して配布することもできます。
A ROA constitutes an explicit authorization for a single AS to originate routes to one or more prefixes, and is signed by the holder of those prefixes. Conceptually, the ROA syntax consists of two parts, a general CMS template common to all RPKI signed objects
ROAは、1つ以上のプレフィックスへのルートを発信するという単一の明示的な承認を構成し、それらのプレフィックスの所有者によって署名されます。概念的には、ROA構文は2つの部分で構成されています。すべてのRPKI署名されたオブジェクトに共通の一般的なCMSテンプレート
[RFC6488] and an encapsulated content specific to the ROA that expresses the authorization [RFC6482].
[RFC6488]および認証を表すROAに固有のカプセル化されたコンテンツ[RFC6482]。
At a high level, the ROA's content contains (1) an AS number; (2) a list of IP address prefixes; and, optionally, (3) for each prefix, the maximum length of more specific (longer) prefixes that the AS is also authorized to advertise. (This last element facilitates a compact authorization to advertise, for example, any prefixes of length 20 to 24 bits contained within a given length 20 prefix.)
高いレベルでは、ROAのコンテンツには（1）AS数が含まれています。（2）IPアドレスプレフィックスのリスト。そして、オプションでは、（3）プレフィックスごとに、ASが宣伝することも許可されているより具体的な（より長い）プレフィックスの最大長さ。（この最後の要素は、特定の長さ20プレフィックス内に含まれる長さ20〜24ビットのプレフィックスなど、宣伝するコンパクトな承認を容易にします。）
Note that a ROA contains only a single AS number. Thus, if an ISP has multiple AS numbers that will be authorized to originate routes to the prefix(es) in the ROA, an address space holder will need to issue multiple ROAs to authorize the ISP to originate routes from any of these ASes.
ROAには単一のAs番号のみが含まれていることに注意してください。したがって、ISPには、ROAのプレフィックス（ES）へのルートを発信することを許可される数値として複数のAS番号がある場合、アドレススペース保有者は、これらのASEのいずれかからルートを発信するISPを許可するために複数のROAを発行する必要があります。
A ROA is signed using the private key corresponding to the public key in an end-entity (EE) certificate in the PKI. In order for a ROA to be valid, its corresponding end-entity certificate must be valid, and the IP address prefixes of the ROA must exactly match the IP address prefix(es) specified in the EE certificate's RFC 3779 extension. Therefore, the validity interval of the ROA is implicitly the validity interval of its corresponding certificate. A ROA is revoked by revoking the corresponding EE certificate. There is no independent method of revoking a ROA. One might worry that this revocation model could lead to long CRLs for the CA certification that is signing the EE certificates. However, routing announcements on the public Internet are generally quite long lived. Therefore, as long as the EE certificates used to verify a ROA are given a validity interval of several months, the likelihood that many ROAs would need to be revoked within that time is quite low.
ROAは、PKIのエンドエンティティ（EE）証明書の公開キーに対応する秘密鍵を使用して署名されます。ROAを有効にするために、対応するエンドエンティティ証明書が有効でなければならず、ROAのIPアドレスプレフィックスは、EE証明書のRFC 3779拡張機能で指定されたIPアドレスプレフィックス（ES）と正確に一致する必要があります。したがって、ROAの妥当性間隔は、暗黙的に対応する証明書の妥当性間隔です。ROAは、対応するEE証明書を取り消すことにより取り消されます。ROAを取り消す独立した方法はありません。この取り消しモデルが、EE証明書に署名しているCA認定の長いCRLにつながる可能性があることを心配するかもしれません。ただし、パブリックインターネットでのルーティングアナウンスは、一般的に非常に長生きしています。したがって、ROAの検証に使用されるEE証明書に数か月の有効期間が与えられている限り、その時間内に多くのROAを取り消す必要がある可能性は非常に低くなります。
--------- ---------
| RIR | | NIR |
| CA | | CA |
--------- ---------
| |
| |
| |
--------- ---------
| ISP | | ISP |
| CA 1 | | CA 2 |
--------- ---------
| \ |
| ----- |
| \ |
---------- ---------- ----------
| ISP | | ISP | | ISP |
| EE 1a | | EE 1b | | EE 2 |
---------- ---------- ----------
| | |
| | |
| | |
---------- ---------- ----------
| ROA 1a | | ROA 1b | | ROA 2 |
---------- ---------- ----------
Figure 1: This figure illustrates an ISP with allocations from two sources (an RIR and an NIR). It needs two CA certificates due to the rules defined in RFC 3779.
図1：この図は、2つのソース（RIRとNIR）からの割り当てのあるISPを示しています。RFC 3779で定義されているルールのため、2つのCA証明書が必要です。
Because each ROA is associated with a single end-entity certificate, the set of IP prefixes contained in a ROA must be drawn from an allocation by a single source, i.e., a ROA cannot combine allocations from multiple sources. Address space holders who have allocations from multiple sources, and who wish to authorize an AS to originate routes for these allocations, must issue multiple ROAs to the AS.
各ROAは単一のエンドエンティティ証明書に関連付けられているため、ROAに含まれるIPプレフィックスのセットは、単一のソースによる割り当てから描画する必要があります。つまり、ROAは複数のソースからの割り当てを組み合わせることはできません。複数のソースからの割り当てを持ち、これらの割り当てのルートを起源とするASを許可したいと考えているスペースホルダーは、ASに複数のROAを発行する必要があります。
Initially, an LIR/ISP will make use of the resource PKI by acquiring and validating every ROA, to create a table of the prefixes for which each AS is authorized to originate routes. To validate all ROAs, an LIR/ISP needs to acquire all the certificates and CRLs. The primary function of the distributed repository system described here is to store these signed objects and to make them available for download by LIRs/ISPs. Note that this repository system provides a mechanism by which relying parties can pull fresh data at whatever frequency they deem appropriate. However, it does not provide a mechanism for pushing fresh data to relying parties (e.g., by including resource
当初、LIR/ISPは、すべてのROAを取得および検証することにより、リソースPKIを利用して、それぞれがルートを発信することを許可されているプレフィックスのテーブルを作成します。すべてのRoASを検証するには、LIR/ISPがすべての証明書とCRLを取得する必要があります。ここで説明する分散リポジトリシステムの主な機能は、これらの署名されたオブジェクトを保存し、LIRS/ISPによってダウンロードできるようにすることです。このリポジトリシステムは、依存する当事者が適切と思われる頻度で新鮮なデータを引き出すことができるメカニズムを提供することに注意してください。ただし、依存関係者に新鮮なデータをプッシュするメカニズムは提供されません（例：リソースを含めることによって
PKI objects in BGP or other protocol messages) and such a mechanism is beyond the scope of the current document.
BGPまたはその他のプロトコルメッセージのPKIオブジェクト）およびそのようなメカニズムは、現在のドキュメントの範囲を超えています。
The digital signatures on all objects in the repository ensure that unauthorized modification of valid objects is detectable by relying parties. Additionally, the repository system uses manifests (see Section 5) to ensure that relying parties can detect the deletion of valid objects and the insertion of out-of-date, valid signed objects.
リポジトリ内のすべてのオブジェクトのデジタル署名により、有効なオブジェクトの不正な変更が当事者に依存することで検出可能であることが保証されます。さらに、リポジトリシステムはマニフェスト（セクション5を参照）を使用して、依存する当事者が有効なオブジェクトの削除と、時代遅れの有効な署名されたオブジェクトの挿入を検出できるようにします。
The repository system is also a point of enforcement for access controls for the signed objects stored in it, e.g., ensuring that records related to an allocation of resources can be manipulated only by authorized parties. The use of access controls prevents denial-of-service attacks based on deletion of or tampering with repository objects. Indeed, although relying parties can detect tampering with objects in the repository, it is preferable that the repository system prevent such unauthorized modifications to the greatest extent possible.
リポジトリシステムは、リソースの割り当てに関連するレコードが認可された当事者によってのみ操作できるようにすることを保証することを保証することを保証することを保証することを保証することができるように、リポジトリシステムは署名されたオブジェクトのアクセス制御の執行ポイントでもあります。アクセス制御を使用すると、リポジトリオブジェクトの削除または改ざんに基づいて、サービス拒否攻撃を防ぎます。実際、当事者はリポジトリ内のオブジェクトの改ざんを検出できますが、リポジトリシステムがそのような不正な変更を可能な限り最大限に防ぐことが望ましいです。
The repository system is the untrusted clearing-house for all signed objects that must be globally accessible to relying parties. When certificates and CRLs are created, they are uploaded to this repository, and then downloaded for use by relying parties (primarily LIRs/ISPs). ROAs and manifests are additional examples of such objects, but other types of signed objects may be added to this architecture in the future. This document briefly describes the way signed objects (certificates, CRLs, ROAs, and manifests) are managed in the repository system. As other types of signed objects are added to the repository system, it will be necessary to modify the description, but it is anticipated that most of the design principles will still apply. The repository system is described in detail in [RFC6481].
リポジトリシステムは、依存関係者がグローバルにアクセスできる必要があるすべての署名されたオブジェクトの信頼されていないクリアリングハウスです。証明書とCRLが作成されると、それらはこのリポジトリにアップロードされ、頼る当事者（主にLIRS/ISP）によって使用されるためにダウンロードされます。RoasとManifestはそのようなオブジェクトの追加の例ですが、将来このアーキテクチャに他のタイプの署名されたオブジェクトが追加される場合があります。このドキュメントは、署名されたオブジェクト（証明書、CRL、ROA、およびマニフェスト）がリポジトリシステムで管理される方法について簡単に説明します。他のタイプの署名されたオブジェクトがリポジトリシステムに追加されるため、説明を変更する必要がありますが、ほとんどの設計原則がまだ適用されると予想されます。リポジトリシステムは[RFC6481]で詳細に説明されています。
Although there is a single repository system that is accessed by relying parties, it is comprised of multiple databases. These databases will be distributed among registries (RIRs, NIRs, LIRs/ISPs). At a minimum, the database operated by each registry will contain all CA and EE certificates, CRLs, and manifests signed by the CA(s) associated with that registry. Repositories operated by LIRs/ISPs also will contain ROAs. Registries are encouraged to maintain copies of repository data from their customers, and their customer's customers (etc.), to facilitate retrieval of the whole repository contents by relying parties. Ideally, each RIR will hold PKI data from all entities within its geopolitical scope.
依存関係者によってアクセスされる単一のリポジトリシステムがありますが、複数のデータベースで構成されています。これらのデータベースは、レジストリ（RIRS、NIRS、LIRS/ISP）に配布されます。少なくとも、各レジストリによって操作されるデータベースには、そのレジストリに関連付けられたCA（S）によって署名されたすべてのCAおよびEE証明書、CRL、およびマニフェストが含まれます。LIRS/ISPが運営するリポジトリには、ROAも含まれます。レジストリは、当事者に依存することにより、リポジトリ全体のコンテンツ全体の取得を促進するために、顧客および顧客の顧客（など）からのリポジトリデータのコピーを維持することをお勧めします。理想的には、各RIRは、地政学的範囲内のすべてのエンティティからPKIデータを保持します。
For every certificate in the PKI, there will be a corresponding file system directory in the repository that is the authoritative publication point for all objects (certificates, CRLs, ROAs, and manifests) verifiable via this certificate. A certificate's Subject Information Access (SIA) extension [RFC5280] contains a URI that references this directory. Additionally, a certificate's Authority Information Access (AIA) extension [RFC5280] contains a URI that references the authoritative location for the CA certificate under which the given certificate was issued. That is, if certificate A is used to verify certificate B, then the AIA extension of certificate B points to certificate A, and the SIA extension of certificate A points to a directory containing certificate B (see Figure 2).
PKI内のすべての証明書について、リポジトリには、この証明書を介して検証可能なすべてのオブジェクト（証明書、CRLS、ROA、およびマニフェスト）の権威ある公開ポイントである対応するファイルシステムディレクトリがあります。証明書の主題情報アクセス（SIA）拡張[RFC5280]には、このディレクトリを参照するURIが含まれています。さらに、証明書の権限情報アクセス（AIA）拡張[RFC5280]には、特定の証明書が発行されたCA証明書の権威ある場所を参照するURIが含まれています。つまり、証明書Aを使用して証明書Bを検証する場合、証明書BのAIA拡張は証明書Aを指し、証明書AのSIA拡張は証明書Bを含むディレクトリをポイントします（図2を参照）。
+--------+
+--------->| Cert A |<----+
| | CRLDP | |
| | AIA | |
| +--------- SIA | |
| | +--------+ |
| | |
| | |
| | |
| | +-------------------|------------------+
| | | | |
| +->| +--------+ | +--------+ |
| | | Cert B | | | Cert C | |
| | | CRLDP ----+ | | CRLDP -+-+ |
+----------- AIA | | +----- AIA | | |
| | SIA | | | SIA | | |
| +--------+ | +--------+ | |
| V | |
| +---------+ | |
| | A's CRL |<-----------+ |
| +---------+ |
| A's Repository Publication Directory |
+--------------------------------------+
Figure 2: Use of SIA and AIA extensions in the RPKI
図2：RPKIでのSIAおよびAIA拡張機能の使用
In Figure 2, certificates B and C are issued by CA A. Therefore, the AIA extensions of certificates B and C point to (certificate) A, and the SIA extension of certificate A points to the repository publication point of CA A's subordinate products, which includes certificates B and C, as well as the CRL issued by A. The CRL Distribution Points (CRLDP) extension in certificates B and C both point to the CRL issued by A.
図2では、証明書BとCはCa Aによって発行されます。したがって、証明書BとCのAIA拡張は（証明書）Aを指し、証明書のSIA拡張は、Ca Aの従属製品のリポジトリ出版ポイントのポイントAポイントです。これには、証明書BとC、およびAによって発行されたCRLが含まれます。CRL分布ポイント（CRLDP）証明書BとCの拡張は両方ともAが発行したCRLをポイントします。
If a CA certificate is reissued with the same public key, it should not be necessary to reissue (with an updated AIA URI) all certificates signed by the certificate being reissued. Therefore, a certification authority SHOULD use a persistent URI naming scheme for issued certificates. That is, reissued certificates should use the same publication point as previously issued certificates having the same subject and public key, and should overwrite such certificates.
CA証明書が同じ公開キーで再発行されている場合、再発行される証明書によって署名されたすべての証明書を再発行する必要はありません（更新されたAIA URIで）。したがって、認定当局は、発行された証明書に永続的なURI命名スキームを使用する必要があります。つまり、再発行された証明書は、以前に発行された証明書と同じ主題と公開鍵を持つ証明書と同じ出版点を使用し、そのような証明書を上書きする必要があります。
Repository operators will choose one or more access protocols that relying parties can use to access the repository system. These protocols will be used by numerous participants in the infrastructure (e.g., all registries, ISPs, and multi-homed subscribers) to maintain their respective portions of it. In order to support these activities, certain basic functionality is required of the suite of access protocols, as described below. No single access protocol needs to implement all of these functions (although that may be the case), but each function MUST be implemented by at least one access protocol deployed by a repository operator.
リポジトリオペレーターは、依存している当事者がリポジトリシステムにアクセスするために使用できる1つ以上のアクセスプロトコルを選択します。これらのプロトコルは、インフラストラクチャの多数の参加者（たとえば、すべてのレジストリ、ISP、およびマルチホームのサブスクライバー）によって使用され、それぞれの部分を維持します。これらのアクティビティをサポートするために、以下で説明するように、一連のアクセスプロトコルに特定の基本機能が必要です。これらのすべての機能を実装するための単一アクセスプロトコルは必要ありませんが（そうかもしれませんが）、各関数は、リポジトリオペレーターによって展開された少なくとも1つのアクセスプロトコルによって実装する必要があります。
Download: Access protocols must support the bulk download of repository contents and subsequent download of changes to the downloaded contents, since this will be the most common way in which relying parties interact with the repository system. Other types of download interactions (e.g., download of a single object) may also be supported.
ダウンロード：アクセスプロトコルは、リポジトリコンテンツのバルクダウンロードと、ダウンロードされたコンテンツの変更のダウンロードをサポートする必要があります。他のタイプのダウンロードインタラクション（単一のオブジェクトのダウンロードなど）もサポートされる場合があります。
Upload/change/delete: Access protocols must also support mechanisms for the issuers of certificates, CRLs, and other signed objects to add them to the repository, and to remove them. Mechanisms for modifying objects in the repository may also be provided. All access protocols that allow modification to the repository (through addition, deletion, or modification of its contents) must support verification of the authorization of the entity performing the modification, so that appropriate access controls can be applied (see Section 4.4).
アップロード/変更/削除：アクセスプロトコルは、証明書、CRL、およびその他の署名されたオブジェクトの発行者のメカニズムをサポートして、リポジトリに追加し、それらを削除する必要があります。リポジトリ内のオブジェクトを変更するメカニズムも提供される場合があります。リポジトリの変更を可能にするすべてのアクセスプロトコル（コンテンツの追加、削除、または変更を通じて）は、適切なアクセス制御を適用できるように、変更を実行するエンティティの承認の検証をサポートする必要があります（セクション4.4を参照）。
To ensure all relying parties are able to acquire all RPKI signed objects, all publication points MUST be accessible via rsync (see [RFC5781] and [RSYNC]), although other download protocols MAY also be supported. A repository publication point may provide update/change/delete functionality via (set of) access protocols that it desires, provided that the supported protocols are clearly communicated to all certification authorities publishing data at a given publication point.
すべての依存関係者がすべてのRPKI署名されたオブジェクトを取得できるようにするには、RSYNCを介してすべての出版ポイントにアクセスできる必要があります（[RFC5781]および[RSYNC]を参照）。他のダウンロードプロトコルもサポートできます。リポジトリの発行ポイントは、サポートされているプロトコルが特定の出版ポイントでデータを公開するすべての認証当局に明確に伝えられている場合、それが望むアクセスプロトコルを介して（セットの）機能を介して更新/変更/削除を提供する場合があります。
In order to maintain the integrity of information in the repository, controls must be put in place to prevent the addition, deletion, or modification of objects in the repository by unauthorized parties. The identities of parties attempting to make such changes can be authenticated through the relevant access protocols. Although specific access control policies are subject to the local control of repository operators, it is RECOMMENDED that repositories allow only the issuers of signed objects to add, delete, or modify them. Alternatively, it may be advantageous in the future to define a formal delegation mechanism to allow resource holders to authorize other parties to act on their behalf, as suggested in Section 2.3.
リポジトリ内の情報の整合性を維持するには、不正な当事者によるリポジトリ内のオブジェクトの追加、削除、または変更を防ぐために、コントロールを導入する必要があります。そのような変更を加えようとする当事者のアイデンティティは、関連するアクセスプロトコルを介して認証できます。特定のアクセス制御ポリシーはリポジトリオペレーターのローカル制御の対象となりますが、リポジトリは、署名されたオブジェクトの発行者のみがそれらを追加、削除、または変更することを許可することをお勧めします。あるいは、セクション2.3で示唆されているように、リソース保有者が他の当事者に代わって行動することを許可できるようにするために、将来的には正式な委任メカニズムを定義することが有利かもしれません。
A manifest is a signed object listing of all of the signed objects (except for the manifest itself) issued by an authority responsible for a publication in the repository system. For each unexpired certificate, CRL, or ROA issued by the authority, the manifest contains both the name of the file containing the object, and a hash of the file content.
マニフェストは、リポジトリシステムでの出版を担当する当局によって発行されたすべての署名されたオブジェクト（マニフェスト自体を除く）の署名されたオブジェクトリストです。当局によって発行された期限切れのない証明書、CRL、またはROAごとに、マニフェストには、オブジェクトを含むファイルの名前とファイルコンテンツのハッシュの両方が含まれています。
As with ROAs, a manifest is signed by a private key, for which the corresponding public key appears in an end-entity certificate. This EE certificate, in turn, is signed by the CA in question. Since the private key in an EE certificate is used to sign only a single manifest, then the manifest can be revoked by revoking the EE certificate. In such a case, to avoid needless CRL growth, the EE certificate used to validate a manifest SHOULD expire at the same time that the manifest expires.
Roasと同様に、マニフェストは秘密鍵によって署名され、対応する公開キーはエンドエンティティ証明書に表示されます。このEE証明書は、問題のCAによって署名されます。EE証明書の秘密鍵は単一のマニフェストのみに署名するために使用されるため、EE証明書を取り消すことでマニフェストを取り消すことができます。そのような場合、不必要なCRLの成長を避けるために、マニフェストの検証に使用されるEE証明書は、マニフェストが期限切れになると同時に期限切れになるはずです。
Manifests may be used by relying parties when constructing a local cache (see Section 6) to mitigate the risk of an attacker who deletes files from a repository or replaces current signed objects with stale versions of the same object. Such protection is needed because, although all objects in the repository system are signed, the repository system itself is untrusted.
マニフェストは、ローカルキャッシュを構築する際に当事者に依存することで使用できます（セクション6を参照）。リポジトリからファイルを削除する攻撃者のリスクを軽減したり、現在の署名されたオブジェクトを同じオブジェクトの古いバージョンに置き換えたりすることができます。このような保護が必要です。なぜなら、リポジトリシステム内のすべてのオブジェクトが署名されているが、リポジトリシステム自体が信頼されていないからです。
A manifest constitutes a list of (the hashes of) all the files in a repository point at a particular point in time. A detailed specification of the manifest's content is provided in [RFC6486] but, at a high level, a manifest consists of (1) a manifest number; (2) the time the manifest was issued; (3) the time of the next planned update; and (4) a list of filename and hash value pairs.
マニフェストは、特定の時点でリポジトリポイント内のすべてのファイルの（ハッシュ）のリストを構成します。マニフェストのコンテンツの詳細な仕様は[RFC6486]で提供されていますが、高レベルでは、マニフェストは（1）マニフェスト数で構成されています。（2）マニフェストが発行された時。（3）次の計画的な更新の時間。（4）ファイル名とハッシュ値のペアのリスト。
The manifest number is a sequence number that is incremented each time a manifest is issued by the authority. An authority is REQUIRED to issue a new manifest any time it alters any of its items in the repository, or when the specified time of the next update is reached. A manifest is thus valid until the specified time of the next update or until a manifest is issued with a greater manifest number, whichever comes first. (Note that when an EE certificate is used to sign only a single manifest, whenever the authority issues the new manifest, the CA MUST also issue a new CRL that includes the EE certificate corresponding to the old manifest. The revoked EE certificate for the old manifest will be removed from the CRL when it expires; thus, this procedure ought not to result in significant CRL growth.)
マニフェスト番号は、マニフェストが当局によって発行されるたびに増加するシーケンス番号です。当局は、リポジトリ内のアイテムのいずれかを変更するとき、または次の更新の指定された時間に到達したときに、新しいマニフェストを発行する必要があります。したがって、マニフェストは、次のアップデートの指定された時間まで、またはマニフェストがより大きなマニフェスト番号で発行されるまで有効です。（EE証明書が単一のマニフェストのみに署名するために使用される場合、当局が新しいマニフェストを発行するたびに、CAは古いマニフェストに対応するEE証明書を含む新しいCRLも発行する必要があることに注意してください。マニフェストは、有効期限が切れるとCRLから削除されます。したがって、この手順はCRLの大幅な成長をもたらすべきではありません。）
In order to utilize signed objects issued under this PKI, a relying party must first obtain a local copy of the valid EE certificates for the PKI. To do so, the relying party performs the following steps:
このPKIに基づいて発行された署名済みオブジェクトを利用するには、頼る当事者は最初にPKIの有効なEE証明書のローカルコピーを取得する必要があります。そうするために、頼る当事者は次の手順を実行します。
1. Query the repository system to obtain a copy of all certificates, manifests, and CRLs issued under the PKI.
1. リポジトリシステムを照会して、PKIに基づいて発行されたすべての証明書、マニフェスト、およびCRLのコピーを取得します。
2. For each CA certificate in the PKI, verify the signature on the corresponding manifest. Additionally, verify that the current time is earlier than the time indicated in the nextUpdate field of the manifest.
2. PKIの各CA証明書について、対応するマニフェストの署名を確認します。さらに、現在の時刻がマニフェストの次のアップデートフィールドに示されている時間よりも早いことを確認します。
3. For each manifest, verify that certificates and CRLs issued under the corresponding CA certificate match the hash values contained in the manifest. Additionally, verify that no certificate or manifest listed on the manifest is missing from the repository. If the hash values do not match, or if any certificate or CRL is missing, notify the appropriate repository administrator that the repository data has been corrupted.
3. 各マニフェストについて、対応するCA証明書に基づいて発行された証明書とCRLがマニフェストに含まれるハッシュ値と一致することを確認します。さらに、マニフェストにリストされている証明書またはマニフェストがリポジトリに欠落していないことを確認します。ハッシュ値が一致しない場合、または証明書またはCRLが欠落している場合は、適切なリポジトリ管理者にリポジトリデータが破損していることを通知します。
4. Validate each EE certificate by constructing and verifying a certification path for the certificate (including checking relevant CRLs) to the locally configured set of TAs. (See [RFC6487] for more details.)
4. 証明書の認定パス（関連するCRLのチェックを含む）をローカルに構成されたTASセットに検証して検証することにより、各EE証明書を検証します。（詳細については[RFC6487]を参照してください。）
Note that since relying parties will perform these operations regularly, it is more efficient for the relying party to request from the repository system only those objects that have changed since the relying party last updated its local cache.
頼る当事者はこれらの操作を定期的に実行するため、依存している当事者がリポジトリシステムに要求する方が、頼っている当事者が最後にローカルキャッシュを更新してから変更されたオブジェクトのみを要求する方が効率的であることに注意してください。
Note also that by checking all issued objects against the appropriate manifest, the relying party can be certain that it is not missing an updated version of any object.
また、適切なマニフェストに対してすべての発行されたオブジェクトをチェックすることにより、頼る当事者は、すべてのオブジェクトの更新バージョンが欠落していないことを確認できることに注意してください。
Creating and maintaining the infrastructure described above will entail additional operations as "side effects" of normal resource allocation and routing authorization procedures. For example, a subscriber with provider-independent ("portable") address space who enters a relationship with an ISP will need to issue one or more ROAs identifying that ISP, in addition to conducting any other necessary technical or business procedures. The current primary use of this infrastructure is for route filter construction; using ROAs, route filters can be constructed in an automated fashion with high assurance that the holder of the advertised prefix has authorized the origin AS to originate an advertised route.
上記のインフラストラクチャの作成と維持は、通常のリソース割り当ておよびルーティング許可手順の「副作用」として追加の操作を伴います。たとえば、ISPとの関係に入るプロバイダーに依存しない（「ポータブル」）アドレススペースを持つサブスクライバーは、他の必要な技術的またはビジネス手順を実施することに加えて、そのISPを識別する1つ以上のROAを発行する必要があります。このインフラストラクチャの現在の主要な使用は、ルートフィルターの構築です。ROASを使用して、ルートフィルターは、広告されたプレフィックスの所有者が広告されたルートを発生するように起源を許可したことを高い保証で自動化した方法で構築できます。
There are several operational scenarios that require certificates to be issued. Any allocation that may be sub-allocated requires a CA certificate, e.g., so that certificates can be issued as necessary for the sub-allocations. Holders of provider-independent IP address space allocations also must have certificates, so that a ROA can be issued to each ISP that is authorized to originate a route to the allocation (since the allocation does not come from any ISP). Additionally, multi-homed subscribers may require certificates for their allocations if they intend to issue the ROAs for their allocations (see Section 7.3.2). Other resource holders need not be issued CA certificates within the PKI.
証明書を発行する必要があるいくつかの運用シナリオがあります。サブアロークされる可能性のある割り当てには、例えば、サブアロケーションに必要に応じて証明書を発行できるようにCA証明書が必要です。プロバイダーに依存しないIPアドレススペース割り当ての所有者には証明書も必要なため、各ISPにROAを発行することができます。これは、割り当てへのルートを発生することが許可されていることがあります（割り当てはどのISPからも含まれていないため）。さらに、マルチホームのサブスクライバーは、割り当てのためにROAを発行する場合、割り当ての証明書を必要とする場合があります（セクション7.3.2を参照）。他のリソース保有者は、PKI内でCA証明書を発行する必要はありません。
In the long run, a resource holder will not request resource certificates, but rather receive a certificate as a side effect of the allocation process for the resource. However, initial deployment of the RPKI will entail issuance of certificates to existing resource holders as an explicit event. Note that in all cases, the authority issuing a CA certificate will be the entity who allocates resources to the subject. This differs from most PKIs in which a subject can request a certificate from any certification authority.
長期的には、リソースホルダーはリソース証明書を要求せず、リソースの割り当てプロセスの副作用として証明書を受け取ります。ただし、RPKIの初期展開は、明示的なイベントとして既存のリソース保有者に証明書の発行を伴います。すべての場合において、CA証明書を発行する当局は、主題にリソースを割り当てるエンティティになることに注意してください。これは、被験者が任意の認証機関から証明書を要求できるほとんどのPKIとは異なります。
If a resource holder receives multiple allocations over time, it may accrue a collection of resource certificates to attest to them. If a resource holder receives multiple allocations from the same source, the set of resource certificates may be combined into a single resource certificate, if both the issuer and the resource holder agree. This is accomplished by consolidating the IP Address Delegation and AS Identifier Delegation extensions into a single
リソースホルダーが時間の経過とともに複数の割り当てを受信した場合、リソース証明書のコレクションがそれらを証明するためにアコレートされる場合があります。リソースホルダーが同じソースから複数の割り当てを受信した場合、発行者とリソース保有者の両方が同意する場合、リソース証明書のセットを単一のリソース証明書に結合することができます。これは、IPアドレスの委任を統合し、識別子委任拡張機能を単一に統合することによって達成されます
extension (of each type) in a new certificate. However, if these certificates attest to allocations that are valid for different periods of time, creating a certificate that combines them might create problems, as the combined certificate can express only a single validity interval.
新しい証明書の（各タイプの）拡張機能。ただし、これらの証明書が異なる期間に有効な割り当てを証明している場合、それらを組み合わせた証明書を作成すると問題が発生する可能性があります。
If a resource holder's allocations come from different sources, they will be signed by different CAs and cannot be combined. When a set of resources is no longer allocated to a resource holder, any certificates attesting to such an allocation MUST be revoked. A resource holder SHOULD NOT use the same public key in multiple CA certificates that are issued by the same or differing authorities, as reuse of a key pair complicates path construction. Note that since the subject's distinguished name is chosen by the issuer, a subject who receives allocations from two sources generally will receive certificates with different subject names.
リソースホルダーの割り当てが異なるソースから来る場合、それらは異なるCASによって署名され、組み合わせることができません。リソースのセットがリソースホルダーに割り当てられなくなった場合、そのような割り当てを証明する証明書を取り消す必要があります。リソースホルダーは、キーペアの再利用がパス構造を複雑にするため、同じまたは異なる当局によって発行される複数のCA証明書で同じ公開キーを使用しないでください。被験者の著名な名前は発行者によって選択されるため、2つのソースから割り当てを受け取る被験者は、一般に異なるサブジェクト名の証明書を受け取ることに注意してください。
Whenever a certification authority wishes to change the public key (and corresponding private key) associated with its RPKI CA certificate, it MUST perform a key rollover procedure. Key rollover is typically performed on a periodic basis, where the frequency of key rollovers is specified in the certification practice statement of the given CA. Additionally, unscheduled rollovers may be required in the event of suspected key compromises.
認定機関がRPKI CA証明書に関連付けられた公開キー（および対応する秘密鍵）を変更することを希望する場合はいつでも、キーロールオーバー手順を実行する必要があります。キーロールオーバーは通常、定期的に実行されます。ここで、キーロールオーバーの頻度が指定されたCAの認定慣行ステートメントで指定されています。さらに、重要な妥協が疑われた場合には、予定外のロールオーバーが必要になる場合があります。
Note that rollover is only required when the CA's key actually changes; it is not required in cases where a new CA certificate is issued with the same key as the previous certificate for this CA. For example, a new CA certificate must be issued if the CA gains or relinquishes a resource, or if the validity period of the resource allocation is extended. However, in such cases, the new certificate will generally use the same public (and private) key as the previous certificate; thus, key rollover is not required.
CAのキーが実際に変更された場合にのみ、ロールオーバーが必要であることに注意してください。このCAの前の証明書と同じキーで新しいCA証明書が発行された場合、それは必要ありません。たとえば、CAがリソースを獲得または放棄する場合、またはリソース割り当ての有効期間が延長された場合、新しいCA証明書を発行する必要があります。ただし、そのような場合、新しい証明書は通常、前の証明書と同じパブリック（およびプライベート）キーを使用します。したがって、キーロールオーバーは必要ありません。
The document [RFC6489] specifies a conservative key rollover procedure that should be used by a certification authority when it changes the public (and private) keys associated with its RPKI CA certificate. At a high level, the two key properties of the rollover procedure are as follows. First, as data from RPKI signed objects may be used in routing operations, the procedure ensures that at any point in the rollover procedure, a relying party will never reach incorrect conclusions about the validity of a signed object. Note in particular, that the CA cannot assume that a relying party will use any particular algorithm for constructing a certificate path from an EE certificate to (one of) the relying party's trust anchor(s); therefore, the key rollover procedure is designed to preserve the
ドキュメント[RFC6489]は、RPKI CA証明書に関連付けられた公共（およびプライベート）キーを変更したときに認証機関が使用する必要がある保守的なキーロールオーバー手順を指定します。高いレベルでは、ロールオーバー手順の2つの重要な特性は次のとおりです。第一に、RPKI署名されたオブジェクトからのデータがルーティング操作に使用される可能性があるため、手順により、ロールオーバー手順の任意の時点で、依存者が署名されたオブジェクトの有効性に関する誤った結論に達することはありません。特に、CAは、頼る当事者が特定のアルゴリズムを使用して、EE証明書から（1つの1つ）依存者の信頼アンカーに証明書パスを構築するために使用すると想定できないことに注意してください。したがって、主要なロールオーバー手順は、
integrity of the SIA and AIA points within the RPKI hierarchy to the greatest extent possible. Second, the key rollover procedure is designed so that the reissuance of all certificates below the CA in the RPKI hierarchy is not required. Of course, it is necessary to re-sign all certificates issued directly under the CA whose key is changing. However, the SIA and AIA pointers within the certificates are populated so that no further reissuance is required.
SIAとAIAの整合性は、RPKI階層内の可能な限り最大限の範囲で指しています。第二に、主要なロールオーバー手順は、RPKI階層のCA以下のすべての証明書の再発行が必要ないように設計されています。もちろん、キーが変更されているCAに基づいて直接発行されたすべての証明書に再署名する必要があります。ただし、証明書内のSIAとAIAのポインターが入力されているため、さらなる再発行は必要ありません。
Whenever a holder of IP address space wants to authorize an AS to originate routes for a prefix within his holdings, he MUST issue an end-entity certificate containing that prefix in an IP Address Delegation extension. He then uses the corresponding private key to sign a ROA containing the designated prefix and the AS number for the AS. The resource holder MAY include more than one prefix in the EE certificate and corresponding ROA if desired. As a prerequisite, then, any address space holder that issues ROAs for a prefix must have a resource certificate for an allocation containing that prefix. The standard procedure for issuing a ROA is as follows:
IPアドレススペースの所有者が、保有株内の接頭辞のルートを発生するように承認したい場合はいつでも、IPアドレス委任拡張機能にそのプレフィックスを含むエンドエンティティ証明書を発行する必要があります。次に、対応する秘密鍵を使用して、指定されたプレフィックスを含むROAとASのAS番号を含むROAに署名します。リソースホルダーには、EE証明書に複数のプレフィックスを含めることができ、必要に応じて対応するROAが含まれます。前提条件として、プレフィックスのROASを発行するアドレススペースホルダーには、そのプレフィックスを含む割り当てのリソース証明書が必要です。ROAを発行するための標準的な手順は次のとおりです。
1. Create an end-entity certificate containing the prefix(es) to be authorized in the ROA.
1. ROAで許可されるプレフィックス（ES）を含むエンドエンティティ証明書を作成します。
2. Construct the payload of the ROA, including the prefixes in the end-entity certificate and the AS number to be authorized.
2. End-Entity証明書のプレフィックスと、承認されるAS番号を含むROAのペイロードを作成します。
3. Sign the ROA using the private key corresponding to the end-entity certificate (the ROA is comprised of the payload encapsulated in a CMS signed message [RFC5652]).
3. エンドエンティティ証明書に対応する秘密鍵を使用してROAに署名します（ROAは、CMS署名されたメッセージ[RFC5652]にカプセル化されたペイロードで構成されています）。
4. Upload the end-entity certificate and the ROA to the repository system.
4. エンドエンティティ証明書とROAをリポジトリシステムにアップロードします。
The standard procedure for revoking a ROA is to revoke the corresponding end-entity certificate by creating an appropriate CRL and uploading it to the repository system. The revoked ROA and end-entity certificate SHOULD be removed from the repository system.
ROAを取り消すための標準的な手順は、適切なCRLを作成し、リポジトリシステムにアップロードすることにより、対応するエンドエンティティ証明書を取り消すことです。取り消されたROAおよびエンドエンティティ証明書は、リポジトリシステムから削除する必要があります。
Care must be taken when revoking ROAs in that revoking a ROA may cause a relying party to treat routing advertisements corresponding to the prefixes and origin AS number in the ROA as unauthorized (and potentially even change routing behavior to no longer forward packets based on those advertisements). In particular, resource holders should adhere to the principle of "make before break" as follows. Before revoking a ROA corresponding to a prefix that the resource holder wishes to be routable on the Internet, it is very important for the resource holder to ensure that there exists another valid
ROAを取り消すことでROAを取り消すときは注意が必要です。なぜなら、ROAに対応するルーティング広告とROAの数字としてのルーティング広告を不正として扱う可能性があるからです（そして、それらの広告に基づいてルーティング動作を変更することさえ潜在的にルーティング動作を変更します。）。特に、リソース保有者は、次のように「休憩前に作る」という原則を遵守する必要があります。リソースホルダーがインターネット上でルーティング可能であることを望んでいるプレフィックスに対応するROAを取り消す前に、リソースホルダーが別の有効な存在を確認することが非常に重要です
alternative ROA that lists the same prefix (possibly indicating a different AS number). Additionally, the resource holder should ensure that the AS indicated in the valid alternative ROA is actually originating routing advertisements to the prefixes in question. Furthermore, a relying party must fetch new ROAs from the repository system before taking any routing action in response to a ROA revocation.
同じプレフィックスをリストする代替ROA（おそらく異なる数字を示す）。さらに、リソースホルダーは、有効な代替ROAに示されているように、問題のプレフィックスへのルーティング広告を実際に発信していることを確認する必要があります。さらに、頼る当事者は、ROAの取り消しに応じてルーティングアクションを実行する前に、リポジトリシステムから新しいRoasを取得する必要があります。
In BGP, a single-homed subscriber with Provider Aggregatable (PA) address space does not need to explicitly authorize routes to be originated for the prefix(es) it is using, since its ISP will already advertise a more general prefix and route traffic for the subscriber's prefix as an internal function. Since no routes are originated specifically for prefixes held by these subscribers, no ROAs need to be issued under their allocations; rather, the subscriber's ISP will issue any necessary ROAs for its more general prefixes under resource certificates from its own allocation. Thus, a single-homed subscriber with an IP address allocation from his service provider is not included in the RPKI, i.e., it does not receive a CA certificate, nor issue EE certificates or ROAs.
BGPでは、プロバイダーの集約可能な（PA）アドレススペースを備えたシングルホームのサブスクライバーが、使用しているプレフィックス（ES）のルートを明示的に許可する必要はありません。ISPはすでにより一般的なプレフィックスとルートトラフィックを宣伝しているためサブスクライバーのプレフィックスは内部関数として。これらのサブスクライバーが保有する接頭辞専用のルートはないため、割り当ての下でROAを発行する必要はありません。むしろ、サブスクライバーのISPは、独自の割り当てからリソース証明書の下で、より一般的なプレフィックスに必要なROAを発行します。したがって、彼のサービスプロバイダーからのIPアドレス割り当てを備えた単一拠点のサブスクライバーは、RPKIに含まれていません。つまり、CA証明書もEE証明書もROAも発行しません。
Here we consider a subscriber who receives Provider Aggregatable (PA) IP address space from a primary ISP (i.e., the IP addresses used by the subscriber are a subset of ISP A's IP address space allocation) and receives redundant upstream connectivity from one or more secondary ISPs, in addition to the primary ISP. The preferred option for such a multi-homed subscriber is for the subscriber to obtain an AS number and run BGP with each of its upstream providers. In such a case, there are two RECOMMENDED ways for ROA management to be handled. The first is that the primary ISP issues a CA certificate to the subscriber, and the subscriber issues a ROA to containing the subscriber's AS number and the subscriber's IP address prefixes. The second possibility is that the primary ISP does not issue a CA certificate to the subscriber, and instead issues a ROA on the subscriber's behalf that contains the subscriber's AS number and the subscriber's IP address prefixes.
ここでは、プライマリISPからプロバイダーの集約可能な（PA）IPアドレススペースを受信するサブスクライバーを検討します（つまり、サブスクライバーが使用するIPアドレスはISP AのIPアドレススペース割り当てのサブセットです）、1つまたは複数のセカンダリから冗長なアップストリーム接続を受信しますISP、プライマリISPに加えて。このようなマルチホームのサブスクライバーの優先オプションは、サブスクライバーがAS数を取得し、各アップストリームプロバイダーでBGPを実行することです。そのような場合、ROA管理が処理される2つの推奨方法があります。1つ目は、プライマリISPがサブスクライバーにCA証明書を発行し、サブスクライバーはサブスクライバーAS番号とサブスクライバーのIPアドレスプレフィックスを含むROAを発行することです。2番目の可能性は、プライマリISPがサブスクライバーにCA証明書を発行せず、代わりにサブスクライバーのAS番号とサブスクライバーのIPアドレスプレフィックスを含むサブスクライバーに代わってROAを発行することです。
If the subscriber is unable or unwilling to obtain an AS number and run BGP, the another option is that the multi-homed subscriber can request that the primary ISP create a ROA for each secondary ISP that authorizes the secondary ISP to originate routes to the subscriber's prefixes. The primary ISP will also create a ROA containing its own AS number and the subscriber's prefixes, as it is likely in such a case that the primary ISP wishes to advertise precisely the
サブスクライバーがAS番号を取得してBGPを実行できないか、BGPを実行することを嫌がる場合、別のオプションは、マルチホームのサブスクライバーが、プライマリISPがセカンダリISPを認可する各セカンダリISPのROAを作成することを要求できることです。プレフィックス。プライマリISPは、プライマリISPが正確に宣伝したい場合にある可能性が高いため、独自のAS数とサブスクライバーのプレフィックスを含むROAも作成します。
subscriber's prefixes and not an encompassing aggregate. Note that this approach results in inconsistent origin AS numbers for the subscriber's prefixes that are considered undesirable on the public Internet; thus, this approach is NOT RECOMMENDED.
サブスクライバーのプレフィックスは、包括的な凝集体ではありません。このアプローチは、パブリックインターネット上で望ましくないと見なされるサブスクライバーのプレフィックスの数値として一貫性のない起源をもたらすことに注意してください。したがって、このアプローチは推奨されません。
A resource holder is said to have provider-independent (portable) address space if the resource holder received its allocation directly from a RIR or NIR. Because the prefixes represented in such allocations are not taken from an allocation held by an ISP, there is no ISP that holds and advertises a more general prefix. A holder of a portable IP address space allocation MUST authorize one or more ASes to originate routes to these prefixes. Thus, the resource holder MUST generate one or more EE certificates and associated ROAs to enable the AS(es) to originate routes for the prefix(es) in question. This ROA is required because none of the ISP's existing ROAs authorize it to originate routes to the subscriber's provider-independent allocation.
リソースホルダーは、リソースホルダーがRIRまたはNIRから直接割り当てを受け取った場合、プロバイダーに依存しない（ポータブル）アドレススペースを持つと言われています。このような割り当てで表される接頭辞は、ISPが保持する割り当てから取られていないため、より一般的なプレフィックスを保持および宣伝するISPはありません。ポータブルIPアドレススペース割り当ての所有者は、これらのプレフィックスへのルートを発信するように1つ以上のASESを許可する必要があります。したがって、リソースホルダーは、1つ以上のEE証明書と関連するROAを生成して、AS（ES）が問題のプレフィックス（ES）のルートを発信できるようにする必要があります。このROAは、ISPの既存のROAのいずれも、サブスクライバーのプロバイダーに依存しない割り当てへのルートを発信することを許可しないため、必要です。
The focus of this document is security; hence, security considerations permeate this specification.
このドキュメントの焦点はセキュリティです。したがって、セキュリティ上の考慮事項はこの仕様に浸透します。
The security mechanisms provided by and enabled by this architecture depend on the integrity and availability of the infrastructure it describes. The integrity of objects within the infrastructure is ensured by appropriate controls on the repository system, as described in Section 4.4. Likewise, because the repository system is structured as a distributed database, it should be inherently resistant to denial-of-service attacks; nonetheless, appropriate precautions should also be taken, both through replication and backup of the constituent databases and through the physical security of database servers.
このアーキテクチャによって提供され、有効になっているセキュリティメカニズムは、それが説明するインフラストラクチャの整合性と可用性に依存します。インフラストラクチャ内のオブジェクトの整合性は、セクション4.4で説明されているように、リポジトリシステムの適切な制御によって保証されます。同様に、リポジトリシステムは分散データベースとして構成されているため、サービス拒否攻撃に対して本質的に耐性があるはずです。それにもかかわらず、構成要素データベースの複製とバックアップ、およびデータベースサーバーの物理的セキュリティの両方を通じて、適切な予防措置も取られるべきです。
Instructions for IANA's participation in the RPKI are provided in [RFC6491].
IANAのRPKIへの参加の指示は、[RFC6491]に記載されています。
The architecture described in this document is derived from the collective ideas and work of a large group of individuals. This work would not have been possible without the intellectual contributions of George Michaelson, Robert Loomans, Sanjaya and Geoff Huston of APNIC, Robert Kisteleki and Henk Uijterwaal of the RIPE NCC, Tim Christensen and Cathy Murphy of ARIN, Rob Austein of ISC, and Randy Bush of IIJ.
このドキュメントで説明されているアーキテクチャは、個人の大規模なグループの集合的なアイデアと仕事に由来しています。この作品は、ジョージ・マイケルソン、ロバート・ルーマン、サンジャヤ、アプニック、ロバート・キステレキ、熟したNCCのヘンク・ウイジェルワル、ティム・クリステンセンとアリンのキャシー・マーフィー、ロブ・オーストインのティム・クリステンセンとイシュ、ランディー、ランディーの知的貢献がなければ、不可能だったでしょう。IIJの茂み。
Although we are indebted to everyone who has contributed to this architecture, we would like to especially thank Rob Austein for the concept of a manifest, Geoff Huston for the concept of managing object validity through single-use EE certificate key pairs, and Richard Barnes for help in preparing an early version of this document.
私たちはこのアーキテクチャに貢献したすべての人に感謝していますが、特にマニフェストの概念についてはロブ・オーストイン、ジェフ・ヒューストンが、使い捨てEE証明書キーペアを通じてオブジェクトの有効性を管理するという概念、そしてリチャード・バーンズの概念に感謝したいと思います。このドキュメントの初期バージョンの準備に役立ちます。
[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月。
[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月。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、Ed。、Li、T.、ed。、およびS. Hares、ed。、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[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月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652] Housley、R。、「暗号化メッセージ構文（CMS）」、STD 70、RFC 5652、2009年9月。
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, February 2010.
[RFC5781] Weiler、S.、Ward、D。、およびR. Housley、「Rsync URIスキーム」、RFC 5781、2010年2月。
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012.
[RFC6481] Huston、G.、Loomans、R。、およびG. Michaelson、「リソース証明書リポジトリ構造のプロファイル」、RFC 6481、2012年2月。
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.
[RFC6482] Lepinski、M.、Kent、S。、およびD. Kong、「Route Origin Authorizations（ROAS）のプロファイル」、RFC 6482、2012年2月。
[RFC6486] Austein, R., Huston., G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure", RFC 6486, February 2012.
[RFC6486] Austein、R.、Huston。、G.、Kent、S。、およびM. Lepinski、「リソース公開キーインフラストラクチャのマニフェスト」、RFC 6486、2012年2月。
[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", RFC 6488, February 2012.
[RFC6488] Lepinski、M.、Chi、A。、およびS. Kent、「リソース公開キーインフラストラクチャの署名されたオブジェクトテンプレート」、RFC 6488、2012年2月。
[RFC6491] Manderson, T., Vegoda, L., and S. Kent, "Resource Public Key Infrastructure (RPKI) Objects Issued by IANA", RFC 6491, February 2012.
[RFC6491] Manderson、T.、Vegoda、L。、およびS. Kent、「Ianaが発行したResource公開キーインフラストラクチャ（RPKI）オブジェクト」、RFC 6491、2012年2月。
[RFC6483] Huston, G. and G. Michaelson, "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)", RFC 6483, February 2012.
[RFC6483] Huston、G。およびG. Michaelson、「リソース証明書公開キーインフラストラクチャ（PKI）およびルートオリジン認可（ROA）を使用したルートオリジネーションの検証」、RFC 6483、2012年2月。
[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)", BCP 174, RFC 6489, February 2012.
[RFC6489] Huston、G.、Michaelson、G.、およびS. Kent、「認定局（CA）リソース公開キーインフラストラクチャ（RPKI）のキーロールオーバー」、BCP 174、RFC 6489、2012年2月。
[RFC6490] Huston, G., Weiler, S., Michaelson, G., and S. Kent, "Resource Public Key Infrastructure (RPKI) Trust Anchor Locator", RFC 6490, February 2012.
[RFC6490] Huston、G.、Weiler、S.、Michaelson、G。、およびS. Kent、「リソース公開キーインフラストラクチャ（RPKI）Trust Anchor Locator」、RFC 6490、2012年2月。
[RSYNC] rsync web pages, <http://rsync.samba.org/>.
[rsync] rsync webページ、<http://rsync.samba.org/>。
[S-BGP] Kent, S., Lynn, C., and Seo, K., "Secure Border Gateway Protocol (Secure-BGP)", IEEE Journal on Selected Areas in Communications Vol. 18, No. 4, April 2000.
[S-BGP] Kent、S.、Lynn、C。、およびSEO、K。、「Secure Border Gateway Protocol（Secure-BGP）」、IEEE Journal on Communications Vol。18、No。4、2000年4月。
[soBGP] White, R., "soBGP", May 2005,
<ftp://ftp-eng.cisco.com/sobgp/index.html>
Authors' Addresses
著者のアドレス
Matt Lepinski BBN Technologies 10 Moulton St. Cambridge, MA 02138
Matt Lepinski BBN Technologies 10 Moulton St. Cambridge、MA 02138
EMail: mlepinski@bbn.com
Stephen Kent BBN Technologies 10 Moulton St. Cambridge, MA 02138
Stephen Kent BBN Technologies 10 Moulton St. Cambridge、MA 02138
EMail: kent@bbn.com