RFC 8897 - Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc8897.html
タイトル : RFC 8897 - リソース公開鍵インフラストラクチャ（RPKI）の要件
翻訳編集 : 自動生成

[要約] RFC 8897は、RPKIを利用する側の要件を定義する。このRFCの目的は、RPKIリソースを信頼できる方法で利用するためのガイドラインを提供することである。

Internet Engineering Task Force (IETF)                             D. Ma
Request for Comments: 8897                                          ZDNS
Category: Informational                                          S. Kent
ISSN: 2070-1721                                              Independent
                                                          September 2020

Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties

リソース公開鍵インフラストラクチャ（RPKI）の要件

Abstract

概要

This document provides a single reference point for requirements for Relying Party (RP) software for use in the Resource Public Key Infrastructure (RPKI). It cites requirements that appear in several RPKI RFCs, making it easier for implementers to become aware of these requirements. Over time, this RFC will be updated to reflect changes to the requirements and guidance specified in the RFCs discussed herein.

この文書は、リリースパーティ（RPKI）で使用するためのReliing Party（RP）ソフトウェアの要件のための単一の基準点を提供します（RPKI）。それはいくつかのRPKI RFCに現れる要件を引用し、実装者がこれらの要件を認識するのを容易にします。時間の経過とともに、このRFCは、本明細書で説明されているRFCで指定された要件およびガイダンスの変更を反映するように更新されます。

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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.

この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。IESGによって承認されたすべての文書がすべてのレベルのインターネット規格の候補者ではありません。RFC 7841のセクション2を参照してください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8897.

この文書の現在のステータス、エラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc8897で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.

この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。この文書から抽出されたコードコンポーネントには、信頼法の法的規定のセクション4。

Table of Contents

   1.  Introduction
   2.  Fetching and Caching RPKI Repository Objects
     2.1.  TAL Configuration and Processing
     2.2.  Locating RPKI Objects Using Authority and Subject
           Information Extensions
     2.3.  Dealing with Key Rollover
     2.4.  Dealing with Algorithm Transition
     2.5.  Strategies for Efficient Cache Maintenance
   3.  Certificate and CRL Processing
     3.1.  Verifying Resource Certificate and Syntax
     3.2.  Certificate Path Validation
     3.3.  CRL Processing
   4.  Processing RPKI Repository Signed Objects
     4.1.  Basic Signed Object Syntax Checks
     4.2.  Syntax and Validation for Each Type of Signed Object
       4.2.1.  Manifest
       4.2.2.  ROA
       4.2.3.  Ghostbusters
       4.2.4.  Verifying BGPsec Router Certificate
     4.3.  How to Make Use of Manifest Data
     4.4.  What To Do with Ghostbusters Information
   5.  Distributing Validated Cache
   6.  Local Control
   7.  Security Considerations
   8.  IANA Considerations
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Acknowledgements
   Authors' Addresses

1. Introduction

1. はじめに

RPKI Relying Party (RP) software is used by network operators and others to acquire and verify Internet Number Resource (INR) data stored in the RPKI repository system. RPKI data, when verified, allows an RP to verify assertions about which Autonomous Systems (ASes) are authorized to originate routes for IP address prefixes. RPKI data also establishes a binding between public keys and BGP routers and indicates the AS numbers that each router is authorized to represent.

RPKI Reling Party（RP）ソフトウェアは、RPKIリポジトリシステムに格納されているインターネット番号リソース（INR）データを取得して検証するために、ネットワーク事業者などで使用されています。RPKIデータは、検証されると、RPがIPアドレスのプレフィックスのルートを発信することを許可されているかに関するアサーションを検証できます。RPKIデータは、公開鍵とBGPルータ間のバインドを確立し、各ルータが表す権限があるとおりに示す数字を示します。

The essential requirements imposed on RP software to support secure Internet routing [RFC6480] are scattered throughout numerous protocol-specific RFCs and Best Current Practice RFCs. The following RFCs define these requirements:

Secure Internet Routing [RFC6480]をサポートするためのRPソフトウェアに課された本質的な要件は、多数のプロトコル固有のRFCと最良の現在の実践RFCを通して点在しています。次のRFCはこれらの要件を定義します。

RFC 6481 (Repository Structure) RFC 6482 (ROA format) RFC 6486 (Manifests) RFC 6487 (Certificate and CRL profile) RFC 6488 (RPKI Signed Objects) RFC 6489 (Key Rollover) RFC 6810 (RPKI to Router Protocol) RFC 6916 (Algorithm Agility) RFC 7935 (Algorithms) RFC 8209 (Router Certificates) RFC 8210 (RPKI to Router Protocol, Version 1) RFC 8360 (Certificate Validation Procedure) RFC 8630 (Trust Anchor Locator)

RFC 6481（リポジトリ構造）RFC 6482（ROA形式）RFC 6486（マニフェスト）RFC 6487（証明書とCRLプロファイル）RFC 6488（RPKI署名オブジェクト）RFC 6489（キーロールオーバー）RFC 6810（RPKIからルータプロトコル）RFC 6916（アルゴリズム敏捷性）RFC 7935（アルゴリズム）RFC 8209（ルータ証明書）RFC 8210（RPKIからルータプロトコル、バージョン1）RFC 8360（証明書検証手順）RFC 8630（信頼アンカーロケータ）

The distribution of RPKI RP requirements across these 13 documents makes it hard for an implementer to be confident that he/she has addressed all of these requirements. Additionally, good software engineering practice may call for segmenting the RP system into components with orthogonal functionalities so that those components may be distributed. A taxonomy of the collected RP software requirements can help clarify the role of the RP.

これらの13の文書にまたがるRPKI RP要件の分布は、実装者がこれらの要件のすべてに取り組んでいると確信していることを困難にします。さらに、優れたソフトウェアエンジニアリング慣行は、RPシステムを直交機能を有するコンポーネントにセグメント化することができるので、それらの構成要素が分散され得る。収集されたRPソフトウェア要件の分類法は、RPの役割を明確にするのに役立ちます。

To consolidate RP software requirements in one document, with pointers to all the relevant RFCs, this document outlines a set of baseline requirements imposed on RPs and provides a single reference point for requirements for RP software for use in the RPKI. The requirements are organized into four groups:

RPソフトウェア要件を1つの文書に統合するには、すべての関連RFCへのポインタで、このドキュメントではRPSに課された一連のベースライン要件とRPKIで使用するためのRPソフトウェアの要件のための単一の基準点を提供します。要件は4つのグループに編成されています。

* Fetching and Caching RPKI Repository Objects

* RPKIリポジトリオブジェクトのフェッチとキャッシュ

* Processing Certificates and Certificate Revocation Lists (CRLs)

* 証明書と証明書の失効リスト（CRL）の処理

* Processing RPKI Repository Signed Objects

* RPKIリポジトリ署名されたオブジェクトの処理

* Distributing Validated Cache of the RPKI Data

* RPKIデータの検証されたキャッシュを配布します

This document will be updated to reflect new or changed requirements as these RFCs are updated or additional RFCs are written.

この文書は、これらのRFCが更新されているか追加のRFCが書き込まれているため、新規または変更された要件を反映するように更新されます。

2. Fetching and Caching RPKI Repository Objects

2. RPKIリポジトリオブジェクトのフェッチとキャッシュ

RP software uses synchronization mechanisms supported by targeted repositories (e.g., [rsync] or RRDP [RFC8182]) to download RPKI signed objects from the repository system in order to update a local cache. These mechanisms download only those objects that have been added or replaced with new versions since the time when the RP most recently checked the repository. RP software validates the RPKI data and uses it to generate authenticated data identifying which ASes are authorized to originate routes for address prefixes and which routers are authorized to sign BGP updates on behalf of specified ASes.

RPソフトウェアは、ローカルキャッシュを更新するために、ターゲットリポジトリ（例えば[rsync]またはrrdp [rfc8182]）によってサポートされている同期メカニズムを使用します。これらのメカニズムは、RPが最後にリポジトリをチェックしてから、追加または新しいバージョンに置き換えられたオブジェクトだけをダウンロードします。RP SoftwareはRPKIデータを検証し、それを使用して、どのASがアドレスプレフィックスのルートの原因となる認証された認証データを生成し、指定されたASESに代わってBGPアップデートに署名する権限があるかを識別します。

2.1. TAL Configuration and Processing

2.1. タール構成と処理

In the RPKI, each RP chooses a set of trust anchors (TAs). Consistent with the extant INR allocation hierarchy, the IANA and/or the five Regional Internet Registries (RIRs) are obvious candidates to be default TAs for the RP.

RPKIでは、各RPは一連の信頼アンカー（TAS）を選択します。Extant INR割り当て階層と一致して、IANAおよび/または5つの地域インターネットレジストリ（RIRS）は、RPのデフォルトのTAとなる明らかな候補です。

An RP does not retrieve TAs directly. A set of Trust Anchor Locators (TALs) is used by RP software to retrieve and verify the authenticity of each TA.

RPはTASを直接取得しません。一連の信頼アンカーロケータ（TAL）は、各TAの信頼性を検索し検証するためにRPソフトウェアによって使用されます。

TAL configuration and processing are specified in Section 3 of [RFC8630].

TALの設定と処理は[RFC8630]のセクション3で指定されています。

2.2. Locating RPKI Objects Using Authority and Subject Information Extensions

2.2. 権限と件名の情報拡張を使用してRPKIオブジェクトを見つける

The RPKI repository system is a distributed one, consisting of multiple repository instances. Each repository instance contains one or more repository publication points. RP software discovers publication points using the Subject Information Access (SIA) and the Authority Information Access (AIA) extensions from (validated) certificates.

RPKIリポジトリシステムは、複数のリポジトリインスタンスからなる分散型のものです。各リポジトリインスタンスには、1つ以上のリポジトリ出版物ポイントが含まれています。RPソフトウェアは、（検証済み）証明書からの件名情報アクセス（SIA）および権限情報アクセス（AIA）拡張機能を使用して出版物を検出します。

Section 5 of [RFC6481] specifies how RP software locates all RPKI objects by using the SIA and AIA extensions. Detailed specifications of SIA and AIA extensions in a resource certificate are described in Sections 4.8.8 and 4.8.7 of [RFC6487], respectively.

[RFC6481]のセクション5 RPソフトウェアは、SIAおよびAIA拡張機能を使用してすべてのRPKIオブジェクトをどのようにロケートするかを指定します。リソース証明書のSIAおよびAIA拡張の詳細仕様は、それぞれ[RFC6487]のセクション4.8.8および4.8.7に記載されています。

2.3. Dealing with Key Rollover

2.3. キーロールオーバーに対処する

RP software takes the key rollover period into account with regard to its frequency of synchronization with the RPKI repository system.

RPソフトウェアは、RPKIリポジトリシステムとの同期の頻度に関して、キーロールオーバー期間を考慮に入れる。

RP software requirements for dealing with key rollover are described in Section 3 of [RFC6489] and Section 3 of [RFC8634].

キーロールオーバーを扱うためのRPソフトウェア要件は、[RFC6489]のセクション3と[RFC8634]のセクション3で説明されています。

2.4. Dealing with Algorithm Transition

2.4. アルゴリズム遷移への対処

The set of cryptographic algorithms used with the RPKI is expected to change over time. Each RP is expected to be aware of the milestones established for the algorithm transition and what actions are required at every juncture.

RPKIで使用される暗号化アルゴリズムのセットは時間とともに変化すると予想されます。各RPは、アルゴリズムの遷移に確立されたマイルストーンと、あらゆる接合部でどのような行動が必要であると予想されます。

RP software requirements for dealing with algorithm transition are specified in Section 4 of [RFC6916].

アルゴリズム遷移を扱うためのRPソフトウェア要件は[RFC6916]のセクション4で指定されています。

2.5. Strategies for Efficient Cache Maintenance

2.5. 効率的なキャッシュメンテナンスのための戦略

Each RP is expected to maintain a local cache of RPKI objects. The cache needs to be brought up to date and made consistent with the repository publication point data as frequently as allowed by repository publication points and by locally selected RP processing constraints.

各RPはRPKIオブジェクトのローカルキャッシュを維持することが期待されています。キャッシュは、リポジトリ出版物ポイントおよびローカルに選択されたRP処理の制約によって許可されるのと同じくらい頻繁にリポジトリ出版物ポイントデータと一致する必要があります。

The last paragraph of Section 5 of [RFC6481] provides guidance for maintenance of a local cache.

[RFC6481]のセクション5の最後の段落は、ローカルキャッシュのメンテナンスのためのガイダンスを提供します。

3. Certificate and CRL Processing

3. 証明書とCRLの処理

The RPKI makes use of X.509 certificates and CRLs, but it profiles the standard formats described in [RFC6487]. The major change to the profile established in [RFC5280] is the mandatory use of a new extension in RPKI certificates, defined in [RFC3779].

RPKIはX.509証明書とCRLを利用していますが、[RFC6487]に記載されている標準フォーマットをプロファイルします。[RFC5280]で設定されたプロファイルへの大きな変更は、[RFC3779]で定義されているRPKI証明書の新しい拡張子の必須使用です。

3.1. Verifying Resource Certificate and Syntax

3.1. リソース証明書と構文の検証

Certificates in the RPKI are called resource certificates, and they are required to conform to the profile described in [RFC6487]. An RP is required to verify that a resource certificate adheres to the profile established by Section 4 of [RFC6487]. This means that all extensions mandated by Section 4.8 of [RFC6487] must be present and the value of each extension must be within the range specified by [RFC6487]. Moreover, any extension excluded by Section 4.8 of [RFC6487] must be omitted.

RPKIの証明書はリソース証明書と呼ばれ、[RFC6487]に記載されているプロファイルに準拠する必要があります。リソース証明書が[RFC6487]のセクション4によって確立されたプロファイルに準拠していることを確認するためにRPが必要です。つまり、[RFC6487]のセクション4.8で義務付けられているすべての拡張機能が存在し、各拡張子の値は[RFC6487]で指定された範囲内でなければなりません。また、[RFC6487]のセクション4.8によって除外された範囲は省略されている必要があります。

Section 7.1 of [RFC6487] specifies the procedure that RP software follows when verifying extensions described in [RFC3779].

[RFC6487]のセクション7.1は、[RFC3779]に記載されている拡張機能を検証するときにRPソフトウェアが続く手順を指定します。

3.2. Certificate Path Validation

3.2. 証明書パスの検証

Initially, the INRs in the issuer's certificate are required to encompass the INRs in the subject's certificate. This is one of the necessary principles of certificate path validation in addition to cryptographic verification (i.e., verification of the signature on each certificate using the public key of the parent certificate).

最初に、発行者の証明書のINRSは、対象の証明書のINRSを包含する必要があります。これは、暗号検証に加えて、証明書パス検証の必要な原則の1つです（すなわち、親証明書の公開鍵を使用して各証明書の署名の検証）。

Section 7.2 of [RFC6487] specifies the procedure that RP software should follow to perform certificate path validation.

[RFC6487]のセクション7.2は、RPソフトウェアが証明書パスの検証を実行するために従うべき手順を指定します。

Certification Authorities (CAs) that want to reduce aspects of operational fragility will migrate to the new OIDs [RFC8360], informing RP software to use an alternative RPKI validation algorithm. An RP is expected to support the amended procedure to handle accidental overclaiming, which is described in Section 4 of [RFC8360].

Operational Fromilityの側面を減らしたい認証局（CAS）は、代替RPKI検証アルゴリズムを使用するようにRPソフトウェアに知らせる新しいOID [RFC8360]に移行します。RPは、[RFC8360]のセクション4で説明されている偶発的な難算を処理するための修正手順をサポートすると予想されます。

3.3. CRL Processing

3.3. CRL処理

The CRL processing requirements imposed on CAs and RPs are described in Section 5 of [RFC6487]. CRLs in the RPKI are tightly constrained; only the AuthorityKeyIdentifier (Section 4.8.3 of [RFC6487]) and CRLNumber (Section 5.2.3 of [RFC5280]) extensions are allowed, and they are required to be present. No other CRL extensions are allowed, and no CRLEntry extensions are permitted. RP software is required to verify that these constraints have been met. Each CRL in the RPKI must be verified using the public key from the certificate of the CA that issued the CRL.

CASおよびRPSに課されたCRL処理要件は、[RFC6487]のセクション5に記載されている。RPKIのCRLはしっかりと制約されています。AuthorityKeyIdentifier（[RFC6487]のセクション4.8.3）およびCRLNUMBER（[RFC5280]のセクション5.2.3）拡張が許可されており、存在する必要があります。他のCRL拡張機能は許可されておらず、Crleentry拡張機能は許可されていません。RPソフトウェアは、これらの制約が満たされていることを確認するために必要です。RPKIの各CRLは、CRLを発行したCAの証明書から公開鍵を使用して検証する必要があります。

In the RPKI, RPs are expected to pay extra attention when dealing with a CRL that is not consistent with the manifest associated with the publication point associated with the CRL.

RPKIでは、RPSは、CRLに関連付けられている公開ポイントに関連付けられているマニフェストと一致しないCRLを扱うときに、RPSが余分な注意を払うと予想されます。

Processing of a CRL that is not consistent with a manifest is a matter of local policy, as described in the fifth paragraph of Section 6.6 of [RFC6486].

マニフェストと一致しないCRLの処理は、[RFC6486]のセクション6.6の第5項の段落で説明されているように、地域の方針の問題です。

4. Processing RPKI Repository Signed Objects

4. RPKIリポジトリ署名されたオブジェクトの処理

4.1. Basic Signed Object Syntax Checks

4.1. 基本署名付きオブジェクト構文チェック

Before an RP can use a signed object from the RPKI repository, RP software is required to check the signed-object syntax.

RPがRPKIリポジトリから署名されたオブジェクトを使用する前に、符号付きオブジェクト構文を確認するにはRPソフトウェアが必要です。

Section 3 of [RFC6488] lists all the steps that RP software is required to execute in order to validate the top-level syntax of a repository signed object.

[RFC6488]のセクション3リポジトリ署名付きオブジェクトの最上位シンタックスを検証するためにRPソフトウェアが実行する必要があるすべてのステップをリストします。

Note that these checks are necessary but not sufficient. Additional validation checks must be performed based on the specific type of signed object, as described in Section 4.2.

これらのチェックは必要ですが十分ではありません。セクション4.2で説明されているように、追加の検証チェックは、特定のタイプの署名付きオブジェクトに基づいて実行する必要があります。

4.2. Syntax and Validation for Each Type of Signed Object

4.2. 署名付きオブジェクトの種類ごとの構文と検証

4.2.1. Manifest

4.2.1. man man

To determine whether a manifest is valid, RP software is required to perform manifest-specific checks in addition to the generic signed-object checks specified in [RFC6488].

マニフェストが有効かどうかを判断するには、[RFC6488]で指定された汎用署名済みオブジェクトチェックに加えて、マニフェスト固有のチェックを実行するためにRPソフトウェアが必要です。

Specific checks for a manifest are described in Section 4 of [RFC6486]. If any of these checks fail, indicating that the manifest is invalid, then the manifest will be discarded, and RP software will act as though no manifest were present.

マニフェストの特定のチェックは[RFC6486]のセクション4で説明されています。これらのチェックのいずれかが失敗した場合、マニフェストが無効であることを示し、その後、マニフェストは破棄され、RPソフトウェアは存在しないように機能します。

4.2.2. ROA

4.2.2. ぞっとする

To validate a Route Origin Authorization (ROA), RP software is required to perform all the checks specified in [RFC6488] as well as additional, ROA-specific validation steps. The IP Address Delegation extension [RFC3779] present in the end-entity (EE) certificate (contained within the ROA) must encompass each of the IP address prefix(es) in the ROA.

ROUT ORION認証（ROA）を検証するために、[RFC6488]および追加のROA固有の検証手順と同様に[RFC6488]で指定されたすべてのチェックを実行するために必要です。エンドエンティティ（EE）証明書（ROA内に含まれている）に存在するIPアドレス委任拡張[RFC3779]は、ROA内の各IPアドレスプレフィックス（ES）を網羅する必要があります。

More details for ROA validation are specified in Section 4 of [RFC6482].

ROA検証の詳細は[RFC6482]のセクション4で指定されています。

4.2.3. Ghostbusters

4.2.3. ゴーストバスター

The Ghostbusters Record is optional; a publication point in the RPKI can have zero or more associated Ghostbusters Records. If a CA has at least one Ghostbusters Record, RP software is required to verify that this Ghostbusters Record conforms to the syntax of signed objects defined in [RFC6488].

GhostBustersレコードはオプションです。RPKIの公開ポイントは、ゼロ以上のGhostBustersレコードを持つことができます。CAに少なくとも1つのゴーストバスターレコードが記録されている場合、RPソフトウェアは[RFC6488]で定義された署名付きオブジェクトの構文に準拠していることを確認するためにRPソフトウェアが必要です。

The payload of this signed object is a (severely) profiled vCard. RP software is required to verify that the payload of Ghostbusters conforms to format as profiled in [RFC6493].

この署名付きオブジェクトのペイロードは、（重大）プロファイルのvCardです。RPソフトウェアは、ゴーストバスターのペイロードが[RFC6493]でプロファイリングされているフォーマットに準拠していることを確認するために必要です。

4.2.4. Verifying BGPsec Router Certificate

4.2.4. BGPSecルータ証明書の確認

A BGPsec Router Certificate is a resource certificate, so it is required to comply with [RFC6487]. Additionally, the certificate must contain an AS Identifier Delegation extension (Section 4.8.11 of [RFC6487]) and must not contain an IP Address Delegation extension (Section 4.8.10 of [RFC6487]). The validation procedure used for BGPsec Router Certificates is analogous to the validation procedure described in Section 7 of [RFC6487], but it uses the constraints defined in Section 3 of [RFC8209].

BGPSecルーター証明書はリソース証明書であるため、[RFC6487]に準拠する必要があります。さらに、証明書にはAS識別子委任内線番号を含める必要があります（[RFC6487]のセクション4.8.11）、IPアドレスの委任内線番号を含めてはいけません（[RFC6487]のセクション4.8.10）。BGPSecルータ証明書に使用される検証手順は[RFC6487]のセクション7で説明されている検証手順に似ていますが、[RFC8209]のセクション3で定義されている制約を使用します。

Note that the cryptographic algorithms used by BGPsec routers are found in [RFC8608]. Currently, the algorithms specified in [RFC8608] and [RFC7935] are different. BGPsec RP software will need to support algorithms that are used to validate BGPsec signatures as well as the algorithms that are needed to validate signatures on BGPsec certificates, RPKI CA certificates, and RPKI CRLs.

BGPSecルータで使用されている暗号化アルゴリズムは[RFC8608]にあります。現在、[RFC8608]と[RFC7935]で指定されたアルゴリズムは異なります。BGPSec RPソフトウェアは、BGPSecシグネチャを検証するために使用されるアルゴリズムと、BGPSec証明書、RPKI CA証明書、およびRPKI CRLS上の署名を検証するために必要なアルゴリズムをサポートする必要があります。

4.3. How to Make Use of Manifest Data

4.3. マニフェストデータを利用する方法

For a given publication point, RP software ought to perform tests, as specified in Section 6.1 of [RFC6486], to determine the state of the manifest at the publication point. A manifest can be classified as either valid or invalid, and a valid manifest is either current or stale. An RP decides how to make use of a manifest based on its state, according to local (RP) policy.

特定の出版物ポイントの場合、RPソフトウェアは[RFC6486]のセクション6.1で指定されているように、パブリケーションポイントのマニフェストの状態を決定するためにテストを実行する必要があります。マニフェストは有効か無効として分類でき、有効なマニフェストは現在または古いものです。RPは、ローカル（RP）ポリシーに従って、その状態に基づいてマニフェストを利用する方法を決定します。

If there are valid objects in a publication point that are not present on a manifest, [RFC6486] does not mandate specific RP behavior with respect to such objects.

マニフェストに存在しない公開ポイントに有効なオブジェクトがある場合、[RFC6486]はそのようなオブジェクトに関して特定のRPの動作を義務付けません。

In the absence of a manifest, an RP is expected to accept all valid signed objects present in the publication point (see Section 6.2 of [RFC6486]). If a manifest is stale or invalid and an RP has no way to acquire a more recent valid manifest, the RP is expected to contact the repository manager via Ghostbusters Records and thereafter make decisions according to local (RP) policy (see Sections 6.3 and 6.4 of [RFC6486]).

マニフェストがない場合、RPは公開ポイントに存在するすべての有効な署名付きオブジェクトを受け入れると予想されます（[RFC6486]のセクション6.2を参照）。マニフェストが古くなっていて無効で、RPがより最近の有効なマニフェストを取得する方法がない場合、RPはGhostBustersレコードを介してリポジトリマネージャに連絡し、その後ローカル（RP）ポリシーに従って決定を下すことが予想されます（セクション6.3と6.4を参照）。[RFC6486]の。

4.4. What To Do with Ghostbusters Information

4.4. GhostBustersの情報をどうするか

RP software may encounter a stale manifest or CRL, or an expired CA certificate or ROA at a publication point. An RP is expected to use the information from the Ghostbusters Records to contact the maintainer of the publication point where any stale/expired objects were encountered. The intent here is to encourage the relevant CA and/or repository manager to update the stale or expired objects.

RPソフトウェアは、古いマニフェストまたはCRL、または公開ポイントで期限切れのCA証明書またはROAが発生する可能性があります。RPは、ゴーストバスターレコードからの情報を使用して、Stale / Optiredオブジェクトが発生した公開ポイントのメンテナに連絡することが期待されています。ここでのインテントは、関連するCAおよび/またはリポジトリマネージャに古いオブジェクトまたは期限切れのオブジェクトを更新することを奨励することです。

5. Distributing Validated Cache

5. 検証されたキャッシュの配布

On a periodic basis, BGP speakers within an AS request updated validated origin AS data and router/ASN data from the (local) validated cache of RPKI data. The RP may either transfer the validated data to the BGP speakers directly, or it may transfer the validated data to a cache server that is responsible for provisioning such data to BGP speakers. The specifications of the protocol designed to deliver validated cache data to a BGP Speaker are provided in [RFC6810] and [RFC8210].

定期的に、AS要求内のBGPスピーカーは、RPKIデータの（ローカル）検証されたキャッシュからのデータおよびルータ/ ASNデータとして検証された有効な原点を更新しました。RPは、検証されたデータをBGPスピーカーに直接転送するか、または検証済みデータをBGPスピーカーにプロビジョニングする責任があるキャッシュサーバに転送することができます。検証済みキャッシュデータをBGPスピーカーに配信するように設計されたプロトコルの仕様は、[RFC6810]と[RFC8210]に提供されています。

6. Local Control

6. ローカルコントロール

ISPs may want to establish a local view of exceptions to the RPKI data in the form of local filters and additions. For instance, a network operator might wish to make use of a local override capability to protect routes from adverse actions [RFC8211]. The mechanisms developed to provide this capability to network operators are called Simplified Local Internet Number Resource Management with the RPKI (SLURM). If an ISP wants to implement SLURM, its RP system can follow the instruction specified in [RFC8416].

ISPは、ローカルフィルタと追加の形式でRPKIデータの例外のローカルビューを確立することをお勧めします。たとえば、ネットワークオペレータは、有害アクション[RFC8211]からルートを保護するためにローカルオーバーライド機能を利用したい場合があります。この機能をネットワーク事業者に提供するために開発されたメカニズムは、RPKI（SLURM）を使用して、簡易ローカルインターネット番号リソース管理と呼ばれます。ISPがSLURMを実装したい場合、そのRPシステムは[RFC8416]で指定された命令に従うことができます。

7. Security Considerations

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

This document does not introduce any new security considerations; it is a resource for implementers. The RP links the RPKI provisioning side and the routing system, establishing a verified, local view of global RPKI data to BGP speakers. The security of the RP is critical for exchanging BGP messages. Each RP implementation is expected to offer cache backup management to facilitate recovery from outages. RP software should also support secure transport (e.g., IPsec [RFC4301]) that can protect validated cache delivery in an unsafe environment. This document highlights many validation actions applied to RPKI signed objects, an essential element of secure operation of RPKI security.

この文書は新しいセキュリティ上の考慮事項を導入しません。それは実装者のためのリソースです。RPはRPKIプロビジョニング側とルーティングシステムをリンクし、グローバルRPKIデータのBGPスピーカーへの検証されたローカルビューを確立します。RPのセキュリティはBGPメッセージを交換するために重要です。各RP実装は、停止からの回復を容易にするためにキャッシュバックアップ管理を提供すると予想されます。RPソフトウェアは、安全でない環境で検証されたキャッシュ配信を保護することができる安全なトランスポート（例えば、IPsec [RFC4301]）もサポートする必要があります。このドキュメントは、RPKIセキュリティの安全な操作の不可欠な要素であるRPKI署名されたオブジェクトに適用される多くの検証アクションを強調しています。

8. IANA Considerations

8. IANAの考慮事項

This document has no IANA actions.

この文書にはIANAの行動がありません。

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

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

[RFC3779] Lynn、C、Kent、S.、K. SEO、「IPアドレスのX.509拡張機能」、RFC 3779、DOI 10.17487 / RFC3779、2004年6月、<https：//www.rfc-editor.org/info/rfc3779>。

[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, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.

[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW.Polk、 "Internet X.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル「、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。

[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, <https://www.rfc-editor.org/info/rfc6481>.

[RFC6481] Huston、G.、Loomans、R.およびG. Michaelson、「リソース証明書リポジトリ構造のプロファイル」、RFC 6481、DOI 10.17487 / RFC6481、2012年2月、<https：//www.rfc-編集者。ORG / INFO / RFC6481>。

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

[RFC6482] Lepinski、M.、Kent、S.、D.Kong、 "Route Origin承認のプロフィール（ROAS Origin認証のプロフィール（ROAS）、RFC 6482、DOI 10.17487 / RFC6482、2012年2月、<https：///www.rfc-Editor.org/info/rfc6482>。

[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, <https://www.rfc-editor.org/info/rfc6486>.

[RFC6486] Austein、R.、Huston、G.、Kent、S.、およびM.Lepinski、「リソース公開鍵インフラストラクチャ（RPKI）」、RFC 6486、DOI 10.17487 / RFC6486、2012年2月、<https：//www.rfc-editor.org/info/rfc6486>。

[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, <https://www.rfc-editor.org/info/rfc6487>.

[RFC6487] Huston、G.、Michaelson、G.、およびR。貸星、「X.509 PKIXリソース証明書のプロファイル」、RFC 6487、DOI 10.17487 / RFC6487、2012年2月、<https：//www.rfc-editor.org/info/rfc6487>。

[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, <https://www.rfc-editor.org/info/rfc6488>.

[RFC6488] Lepinski、M.、Chi、A。、およびS.Kent、「リソース公開鍵インフラストラクチャのための署名されたオブジェクトテンプレート（RPKI）」、RFC 6488、DOI 10.17487 / RFC6488、2012年2月、<https：// www.rfc-editor.org / info / rfc6488>。

[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)", BCP 174, RFC 6489, DOI 10.17487/RFC6489, February 2012, <https://www.rfc-editor.org/info/rfc6489>.

[RFC6489] Huston、G.、Michaelson、G.、およびS.Kent、「資源公開鍵インフラストラクチャ（RPKI）」、BCP 174、RFC 6489、DOI 10.17487 / RFC6489、2012年2月<https://www.rfc-editor.org/info/rfc6489>。

[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, February 2012, <https://www.rfc-editor.org/info/rfc6493>.

[RFC6493] Bush、R.、「リソース公開鍵インフラストラクチャ（RPKI）GhostBusters Record」、RFC 6493、DOI 10.17487 / RFC6493、2012年2月、<https：//www.rfc-editor.org/info/rfc6493>。

[RFC6810] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol", RFC 6810, DOI 10.17487/RFC6810, January 2013, <https://www.rfc-editor.org/info/rfc6810>.

[RFC6810] Bush、R.およびR.Austein、「リソース公開鍵インフラストラクチャ（RPKI）へのRFC 6810、DOI 10.17487 / RFC6810、2013年1月、<https：//www.rfc-editor.org/情報/ RFC6810>。

[RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 2013, <https://www.rfc-editor.org/info/rfc6916>.

[RFC6916] Gagliano、R.、Kent、S.、S. Turner、 "リソース公開鍵インフラストラクチャ（RPKI）のアルゴリズム俊敏性（RPKI）"、BCP 182、RFC 6916、DOI 10.17487 / RFC6916、2013年4月、<https：//www.rfc-editor.org/info/rfc6916>。

[RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, August 2016, <https://www.rfc-editor.org/info/rfc7935>.

[RFC7935] Huston、G.およびG. Michaelson、ED。、「アルゴリズムのプロファイルとリソース公開鍵インフラストラクチャで使用するための主要サイズ」、RFC 7935、DOI 10.17487 / RFC7935、2016年8月、<https：// www.rfc-editor.org / info / rfc7935>。

[RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests", RFC 8209, DOI 10.17487/RFC8209, September 2017, <https://www.rfc-editor.org/info/rfc8209>.

[RFC8209] Reynolds、M.、Turner、S.、S.Kent、「BGPSecルーター証明書、証明書失効リスト、および認証要求のプロファイル」、RFC 8209、DOI 10.17487 / RFC8209、2017年9月、<https：//www.rfc-editor.org/info/rfc8209>。

[RFC8210] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1", RFC 8210, DOI 10.17487/RFC8210, September 2017, <https://www.rfc-editor.org/info/rfc8210>.

[RFC8210] Bush、R.およびR.Austein、 "リソース公開鍵インフラストラクチャ（RPKI）へ、RFC 8210、DOI 10.17487 / RFC8210、2017年9月、<https：//www.rfc-編集者.org / info / rfc8210>。

[RFC8360] Huston, G., Michaelson, G., Martinez, C., Bruijnzeels, T., Newton, A., and D. Shaw, "Resource Public Key Infrastructure (RPKI) Validation Reconsidered", RFC 8360, DOI 10.17487/RFC8360, April 2018, <https://www.rfc-editor.org/info/rfc8360>.

[RFC8360] Huston、G.、Michaelson、G.、Martinez、C.、Bruijnzels、T.、Newton、A.、およびD. Shaw、「リソース公開鍵インフラ（RPKI）検証再考」、RFC 8360、DOI 10.17487/ RFC8360、2018年4月、<https://www.rfc-editor.org/info/rfc8360>。

[RFC8608] Turner, S. and O. Borchert, "BGPsec Algorithms, Key Formats, and Signature Formats", RFC 8608, DOI 10.17487/RFC8608, June 2019, <https://www.rfc-editor.org/info/rfc8608>.

[RFC8608]ターナー、S.およびO.Borchert、「BGPSecアルゴリズム、キーフォーマット、および署名フォーマット」、RFC 8608、DOI 10.17487 / RFC8608、2019年6月、<https：//www.rfc-editor.org/info/RFC8608>。

[RFC8630] Huston, G., Weiler, S., Michaelson, G., Kent, S., and T. Bruijnzeels, "Resource Public Key Infrastructure (RPKI) Trust Anchor Locator", RFC 8630, DOI 10.17487/RFC8630, August 2019, <https://www.rfc-editor.org/info/rfc8630>.

[RFC8630] Huston、G.、Weiler、S.、Michaelson、G.、Kent、S.、およびT. Bruijnzels、「資源公開鍵インフラ（RPKI）信託アンカーロケーター」、RFC 8630、DOI 10.17487 / RFC8630、8月2019年、<https：//www.rfc-editor.org/info/rfc8630>。

[RFC8634] Weis, B., Gagliano, R., and K. Patel, "BGPsec Router Certificate Rollover", BCP 224, RFC 8634, DOI 10.17487/RFC8634, August 2019, <https://www.rfc-editor.org/info/rfc8634>.

[RFC8634] Weis、B.、Gagliano、R.、K. Patel、「BGPSecルータ証明書ロールオーバー」、BCP 224、RFC 8634、DOI 10.17487 / RFC8634、2019年8月、<https：//www.rfc-編集者。org / info / rfc8634>。

9.2. Informative References

9.2. 参考引用

[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.

[RFC4301] Kent、S.およびK.SEO、「インターネットプロトコルのためのセキュリティアーキテクチャ」、RFC 4301、DOI 10.17487 / RFC4301、2005年12月、<https：//www.rfc-editor.org/info/rfc4301>。

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

[RFC6480] Lepinski、M.およびS. Kent、「安全なインターネットルーティングをサポートするためのインフラストラクチャ」、RFC 6480、DOI 10.17487 / RFC6480、2012年2月、<https：//www.rfc-editor.org/info/rfc6480>。

[RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, DOI 10.17487/RFC8182, July 2017, <https://www.rfc-editor.org/info/rfc8182>.

[RFC8182] Bruijnzels、T.、Muravskiy、O.、Weber、B.、およびR.Austein、「RPKIリポジトリデルタプロトコル（RRDP）」、RFC 8182、DOI 10.17487 / RFC8182、2017年7月、<https：//www.rfc-editor.org/info/rfc8182>。

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

[RFC8211] Kent、S.およびD. MA、「資源公開鍵インフラストラクチャ（RPKI）」、RFC 8211、DOI 10.17487 / RFC8211、2017年9月、<https：//www.rfc-editor.org/info/rfc8211>。

[RFC8416] Ma, D., Mandelberg, D., and T. Bruijnzeels, "Simplified Local Internet Number Resource Management with the RPKI (SLURM)", RFC 8416, DOI 10.17487/RFC8416, August 2018, <https://www.rfc-editor.org/info/rfc8416>.

[RFC8416] MA、D.、MandelBerg、D.、およびT.Bruijnzels、「RPKI（SLURM）」、RFC 8416、DOI 10.17487 / RFC8416、2018年8月、<https：// www.rfc-editor.org / info / rfc8416>。

[rsync] "rsync", <http://rsync.samba.org/>.

[rsync] "rsync"、<http://rsync.samba.org/>。

Acknowledgements

謝辞

The authors thank David Mandelberg, Wei Wang, Tim Bruijnzeels, George Michaelson, and Oleg Muravskiy for their review, feedback, and editorial assistance in preparing this document.

著者らは、David Mandelberg、Wei Wang、Tim Bruijnzels、George Michaelson、およびOleg Muichaelson、およびこの文書の準備のための編集援助について。

Authors' Addresses

著者の住所

Di Ma ZDNS 4 South 4th St. Zhongguancun Haidian Beijing, 100190 China

Di Ma ZDNS 4南4thセントZhongguancun Haidian Beijing、100190中国

   Email: madi@zdns.cn

Stephen Kent Independent

スティーブンケント独立

   Email: kent@alum.mit.edu