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) 中使用的依赖方 (RP) 软件的要求提供了单一参考点。它引用了多个 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/rfc8897。
Copyright Notice
版权声明
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2020 IETF Trust 和文件作者。保留所有权利。
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.
本文档受BCP 78以及本文档发布之日有效的IETF信托基金关于IETF文档的法律规定（https://trustee.ietf.org/license-info）的约束。 请仔细阅读这些文档，因为它们描述了您对本文档的权利和限制。 从本文档中提取的代码组件必须包含信托法律条款第 4.e 节中描述的简化 BSD 许可证文本，并且不提供简化 BSD 许可证中描述的担保。
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
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 依赖方 (RP) 软件由网络运营商和其他方用于获取和验证 RPKI 资源库系统中存储的互联网号码资源 (INR) 数据。经过验证的 RPKI 数据允许 RP 验证关于哪些自治系统 (AS) 被授权为 IP 地址前缀的路由来源的断言。RPKI 数据还能在公共密钥和 BGP 路由器之间建立绑定，并指出每个路由器被授权代表的 AS 号码。
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:
为支持安全互联网路由选择 [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.
RPKI RP 要求分布在这 13 份文件中，这使得实施者很难确信他/她已经满足了所有这些要求。此外，良好的软件工程实践可能会要求将 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 软件的要求整合到一份文件中，并指向所有相关的 RFC，本文件概述了对 RP 的一系列基准要求，并为 RPKI 中使用的 RP 软件要求提供了一个单一的参考点。这些要求分为四组：
* 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 的编写而更新，以反映新的或已更改的要求。
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]）从版本库系统下载 RPKI 签名对象，以更新本地缓存。这些机制只下载自 RP 最近一次检查版本库以来添加或替换为新版本的对象。RP 软件会验证 RPKI 数据，并利用它生成经过验证的数据，以确定哪些 AS 经授权可为地址前缀创建路由，以及哪些路由器经授权可代表指定 AS 签署 BGP 更新。
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 选择一组信任锚（TA）。根据现有的 INR 分配层次，IANA 和/或五个区域互联网注册管理机构 (RIR) 显然是 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 不会直接检索 TA。RP 软件使用一组信任锚定位器 (TAL) 来检索和验证每个 TA 的真实性。
TAL configuration and processing are specified in Section 3 of [RFC8630].
[RFC8630] 第 3 节规定了 TAL 配置和处理。
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 资源库系统是一个分布式系统，由多个资源库实例组成。每个资源库实例包含一个或多个资源库发布点。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 节。
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 节。
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].
RFC6916] 第 4 节规定了处理算法转换的 RP 软件要求。
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 节最后一段为本地高速缓存的维护提供了指导。
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] 中建立的配置文件的主要修改是在 RPKI 证书中强制使用 [RFC3779] 中定义的新扩展。
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] 中描述的配置文件。RP 必须验证资源证书是否符合 [RFC6487] 第 4 节规定的配置文件。这意味着，[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 节规定了 RP 软件在验证 [RFC3779] 中描述的扩展时应遵循的程序。
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).
最初，要求签发者证书中的 INR 包括主体证书中的 INR。这是除密码验证（即使用父证书的公开密钥验证每个证书上的签名）外，证书路径验证的必要原则之一。
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].
希望减少操作脆弱性的认证机构（CA）将迁移到新的 OID [RFC8360]，通知 RP 软件使用另一种 RPKI 验证算法。预计 RP 将支持处理意外超额申领的修正程序，该程序在 [RFC8360] 第 4 节中进行了描述。
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.
RFC6487] 第 5 节描述了对 CA 和 RP 的 CRL 处理要求。RPKI 中的 CRL 受到严格限制；只允许使用 AuthorityKeyIdentifier（[RFC6487]第 4.8.3 节）和 CRLNumber（[RFC5280]第 5.2.3 节）扩展，而且要求必须有这两个扩展。不允许使用其他 CRL 扩展，也不允许使用 CRLEntry 扩展。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 中，RP 在处理与 CRL 发布点相关的清单不一致的 CRL 时，应格外注意。
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].
如 [RFC6486] 第 6.6 节第 5 段所述，处理与清单不一致的 CRL 属于本地政策问题。
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 节所述，必须根据签名对象的具体类型执行其他验证检查。
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 软件将当作没有清单。
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.
要验证路由原点授权（ROA），RP 软件必须执行 [RFC6488] 中规定的所有检查以及 ROA 特有的其他验证步骤。终端实体 (EE) 证书（包含在 ROA 中）中的 IP 地址授权扩展 [RFC3779] 必须包含 ROA 中的每个 IP 地址前缀。
More details for ROA validation are specified in Section 4 of [RFC6482].
有关 ROA 验证的更多详情，请参阅 [RFC6482] 第 4 节。
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 至少有一个 Ghostbusters 记录，则 RP 软件必须验证该 Ghostbusters 记录是否符合 [RFC6488] 中定义的签名对象语法。
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 软件需要验证 Ghostbusters 的有效载荷是否符合 [RFC6493] 中描述的格式。
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 CRL 上签名的算法。
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 Records 与存储库管理者联系，然后根据本地（RP）政策做出决定（见 [RFC6486] 第 6.3 和 6.4 节）。
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。注册管理员应使用 "幽灵克星记录 "中的信息，联系遇到过期/过期对象的发布点的维护者。这样做的目的是鼓励相关 CA 和/或资源库管理者更新陈旧或过期对象。
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 数据的（本地）验证缓存中请求更新已验证的源 AS 数据和路由器/ASN 数据。RP 可以直接向 BGP 发言者传输经过验证的数据，也可以将经过验证的数据传输给负责向 BGP 发言者提供此类数据的缓存服务器。向 BGP 发言者传送经过验证的高速缓存数据的协议规范载于 [RFC6810] 和 [RFC8210]。
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].
互联网服务提供商可能希望以本地过滤和添加的形式，对 RPKI 数据的例外情况建立本地视图。例如，网络运营商可能希望利用本地覆盖功能来保护路由免受不利操作的影响 [RFC8211]。为向网络运营商提供这种功能而开发的机制被称为使用 RPKI 的简化本地互联网号码资源管理（SLURM）。如果 ISP 想要实施 SLURM，其 RP 系统可以遵循 [RFC8416] 中指定的指令。
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 供应方和路由系统，为 BGP 发言者建立经过验证的本地全局 RPKI 数据视图。RP 的安全性对交换 BGP 消息至关重要。每个 RP 实施都应提供高速缓存备份管理，以便从中断中恢复。RP 软件还应支持安全传输（如 IPsec [RFC4301]），从而在不安全的环境中保护已验证的缓存传输。本文档重点介绍了应用于 RPKI 签名对象的许多验证操作，这是 RPKI 安全运行的一个基本要素。
This document has no IANA actions.
本文件没有 IANA 操作。
[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., 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>.
[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., 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>.
[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., 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>。
[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., 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>。
[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., 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>。
[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., 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>。
[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., 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>。
[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., 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>。
[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., "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, February 2012, <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. 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>。
[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., 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>。
[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. 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>。
[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., 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>。
[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. 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>。
[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., 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>。
[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] Turner、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., 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>。
[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., and K. Patel, "BGPsec Router Certificate Rollover", BCP 224, RFC 8634, DOI 10.17487/RFC8634, August 2019, <https://www.rfc-editor.org/info/rfc8634>。
[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. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <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. 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>。
[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] 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>。
[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. 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>。
[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., 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>。
[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 Bruijnzeels、George Michaelson 和 Oleg Muravskiy 在编写本文档过程中提供的审阅、反馈和编辑帮助。
Authors' Addresses
作者地址
Di Ma ZDNS 4 South 4th St. Zhongguancun Haidian Beijing, 100190 China
Di Ma ZDNS 4 South 4th St.
Email: [email protected]
Stephen Kent Independent
斯蒂芬-肯特 独立人士
Email: [email protected]