Internet Engineering Task Force (IETF) T. Bruijnzeels
Request for Comments: 8182 O. Muravskiy
Category: Standards Track RIPE NCC
ISSN: 2070-1721 B. Weber
Cobenian
R. Austein
Dragon Research Labs
July 2017
The RPKI Repository Delta Protocol (RRDP)
RPKI 资源库三角洲协议（RRDP）
Abstract
摘要
In the Resource Public Key Infrastructure (RPKI), Certificate Authorities (CAs) publish certificates, including end-entity certificates, Certificate Revocation Lists (CRLs), and RPKI signed objects to repositories. Relying Parties retrieve the published information from those repositories. This document specifies a new RPKI Repository Delta Protocol (RRDP) for this purpose. RRDP was specifically designed for scaling. It relies on an Update Notification File which lists the current Snapshot and Delta Files that can be retrieved using HTTPS (HTTP over Transport Layer Security (TLS)), and it enables the use of Content Distribution Networks (CDNs) or other caching infrastructures for the retrieval of these files.
在资源公钥基础设施（RPKI）中，证书颁发机构（CA）向存储库发布证书，包括终端实体证书、证书吊销列表（CRL）和 RPKI 签名对象。依赖方从这些存储库中检索已发布的信息。本文档为此规定了新的 RPKI 资源库三角协议 (RRDP)。RRDP 专为扩展而设计。它依赖于一个更新通知文件，该文件列出了可使用 HTTPS（通过传输层安全（TLS）的 HTTP）检索的当前快照和三角洲文件，并支持使用内容分发网络（CDN）或其他缓存基础设施来检索这些文件。
Status of This Memo
本备忘录的地位
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组 (IETF) 的成果。它代表了 IETF 社区的共识。它已接受公众审查，并经互联网工程指导小组 (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 http://www.rfc-editor.org/info/rfc8182.
有关本文件的当前状态、任何勘误以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc8182。
Copyright Notice
版权声明
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有 (c) 2017 IETF 信托基金会和文件作者。保留所有权利。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文档受 BCP 78 和本文档发布之日有效的 IETF 信托基金《与 IETF 文档有关的法律规定》 (http://trustee.ietf.org/license-info) 的约束。请仔细阅读这些文件，因为它们描述了您对本文档的权利和限制。从本文档中提取的代码组件必须包含信托法律条款第 4.e 节中所述的简化 BSD 许可文本，并且不提供简化 BSD 许可中所述的担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. RPKI Repository Delta Protocol Implementation . . . . . . . . 4
3.1. Informal Overview . . . . . . . . . . . . . . . . . . . . 4
3.2. Certificate Authority Use . . . . . . . . . . . . . . . . 5
3.3. Repository Server Use . . . . . . . . . . . . . . . . . . 6
3.3.1. Initialization . . . . . . . . . . . . . . . . . . . 6
3.3.2. Publishing Updates . . . . . . . . . . . . . . . . . 6
3.4. Relying Party Use . . . . . . . . . . . . . . . . . . . . 7
3.4.1. Processing the Update Notification File . . . . . . . 7
3.4.2. Processing Delta Files . . . . . . . . . . . . . . . 9
3.4.3. Processing a Snapshot File . . . . . . . . . . . . . 10
3.4.4. Polling the Update Notification File . . . . . . . . 10
3.4.5. Considerations Regarding Operational Failures in RRDP 11
3.5. File Definitions . . . . . . . . . . . . . . . . . . . . 11
3.5.1. Update Notification File . . . . . . . . . . . . . . 11
3.5.2. Snapshot File . . . . . . . . . . . . . . . . . . . . 13
3.5.3. Delta File . . . . . . . . . . . . . . . . . . . . . 15
3.5.4. XML Schema . . . . . . . . . . . . . . . . . . . . . 17
4. Operational Considerations . . . . . . . . . . . . . . . . . 18
4.1. Compatibility with previous standards . . . . . . . . . . 18
4.2. Distribution Considerations . . . . . . . . . . . . . . . 19
4.3. HTTPS Considerations . . . . . . . . . . . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Normative References . . . . . . . . . . . . . . . . . . 22
7.2. Informative References . . . . . . . . . . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
In the Resource Public Key Infrastructure (RPKI), Certificate Authorities publish certificates [RFC6487], RPKI signed objects [RFC6488], manifests [RFC6486], and CRLs to repositories. CAs may have an embedded mechanism to publish to these repositories, or they may use a separate Repository Server and publication protocol. RPKI repositories are currently accessible using the rsync protocol [RSYNC], allowing Relying Parties to synchronize a local copy of the RPKI repository used for validation with the remote repositories [RFC6481].
在资源公钥基础设施（RPKI）中，证书颁发机构向存储库发布证书 [RFC6487]、RPKI 签名对象 [RFC6488]、清单 [RFC6486] 和 CRL。CA 可以使用嵌入式机制向这些资源库发布，也可以使用单独的资源库服务器和发布协议。RPKI 资源库目前可使用 rsync 协议 [RSYNC]，允许依赖方将用于验证的 RPKI 资源库本地副本与远程资源库同步 [RFC6481]。
rsync [RSYNC] has proven valuable in the early deployment of RPKI, because it allowed operators to gain experience without the need to invent a custom protocol. However, operational experience has brought concerns to light that we wish to address here:
rsync [RSYNC]在 RPKI 的早期部署中被证明是非常有价值的，因为它可以让操作员获得经验，而不需要发明一个自定义协议。不过，运行经验也带来了一些问题，我们希望在此加以解决：
o rsync [RSYNC] is designed to limit the amount of data that needs to be transferred between client and server. However, the server needs to spend significant resources in terms of CPU and memory for every connection. This is a problem in an envisioned RPKI deployment where thousands of Relying Parties query a small number of central repositories, and it makes these repositories weak to denial-of-service attacks.
o rsync [RSYNC]旨在限制客户端和服务器之间需要传输的数据量。但是，服务器需要为每次连接花费大量的 CPU 和内存资源。在设想的 RPKI 部署中，成千上万的依赖方会查询少量的中央资源库，这就造成了一个问题，使这些资源库很容易受到拒绝服务攻击。
o A secondary concern is the lack of supported rsync server and client libraries. In practice, all implementations have to make system calls to an rsync binary. This is inefficient; it introduces fragility with regards to updates of this binary, makes it difficult to catch and report problems to operators, and complicates software development and testing.
o 另一个问题是缺乏受支持的 rsync 服务器和客户端库。在实践中，所有实现都必须对 rsync 二进制文件进行系统调用。这样做效率很低；它会导致二进制文件的更新不稳定，使操作员难以发现和报告问题，并使软件开发和测试复杂化。
This document specifies an alternative repository access protocol based on Update Notification, Snapshot, and Delta Files that a Relying Party can retrieve over the HTTPS protocol. This allows Relying Parties to either perform a full (re-)synchronization of their local copy of the repository using Snapshot Files or use Delta Files to keep their local repository updated after initial synchronization. We call this the RPKI Repository Delta Protocol, or RRDP in short.
本文件规定了一种基于更新通知、快照和 Delta 文件的替代版本库访问协议，依赖方可通过 HTTPS 协议检索这些文件。这样，依赖方就可以使用快照文件对其本地版本库副本进行全面（重新）同步，或使用 Delta 文件在初始同步后对其本地版本库进行更新。我们称之为 RPKI 资源库三角协议，简称 RRDP。
RRDP was designed to support scaling in RPKI's asymmetric deployment. It is consistent (in terms of data structures) with the publication protocol [RFC8181] and treats publication events of one or more repository objects as discrete events that can be communicated to Relying Parties. This approach helps to minimize the amount of data that traverses the network and thus helps minimize the amount of time until repository convergence occurs. RRDP also provides a standards- based way to obtain consistent, point-in-time views of a single repository, eliminating a number of consistency-related issues. Finally, this approach allows these discrete events to be communicated as immutable files. This enables Repository Servers to pre-calculate these files only once for all clients, thus limiting the CPU and memory investments required, and enables the use of a caching infrastructure to reduce the load on a Repository Server when a large number of Relying Parties are querying it.
RRDP 的设计旨在支持 RPKI 非对称部署中的扩展。它（在数据结构方面）与发布协议[RFC8181]一致，并将一个或多个资源库对象的发布事件视为可与依赖方通信的离散事件。这种方法有助于最大限度地减少穿越网络的数据量，从而有助于最大限度地减少资源库收敛所需的时间。RRDP 还提供了一种基于标准的方法来获取单个存储库的一致的时间点视图，从而消除了许多与一致性相关的问题。最后，这种方法允许将这些离散事件作为不可变文件进行通信。这样，存储库服务器只需为所有客户预计算这些文件一次，从而限制了所需的 CPU 和内存投资，并可在大量依赖方查询存储库服务器时使用缓存基础设施来减少存储库服务器的负载。
This document allows the use of RRDP as an additional repository distribution mechanism for RPKI. In time, RRDP may replace rsync [RSYNC] as the only mandatory-to-implement repository distribution mechanism. However, this transition is outside of the scope of this document.
本文档允许使用 RRDP 作为 RPKI 的附加版本库分发机制。随着时间的推移，RRDP 可能会取代 rsync [RSYNC]，成为唯一强制实施的版本库分发机制。不过，这一过渡不在本文档的讨论范围之内。
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 以及 "OPTIONAL" 应按照BCP 14 [RFC2119] [RFC8174]中描述的一样，当且仅当它们以全大写形式出现时进行解释。
Certification Authorities in the RPKI use a Repository Server to publish their RPKI products, such as manifests, CRLs, signed certificates, and RPKI-signed objects. This Repository Server may be remote or embedded in the Certificate Authority engine itself. Certificates in the RPKI that use a Repository Server that supports RRDP include a special Subject Information Access (SIA) pointer referring to an Update Notification File.
RPKI 中的证书颁发机构使用存储库服务器发布其 RPKI 产品，如清单、证书废止列表、签名证书和 RPKI 签名对象。存储库服务器可以是远程的，也可以嵌入证书颁发机构引擎本身。使用支持 RRDP 的存储服务器的 RPKI 证书包括一个指向更新通知文件的特殊主题信息访问 (SIA) 指针。
The Update Notification File includes a globally unique session_id in the form of a version 4 Universally Unique IDentifier (UUID) [RFC4122] and serial number that can be used by the Relying Party to determine if it and the repository are synchronized. Furthermore, it includes a link to the most recent complete snapshot of current objects that are published by the Repository Server, and a list of links to Delta Files, for each revision starting at a point determined by the Repository Server, up to the current revision of the repository.
更新通知文件包括以第 4 版通用唯一标识符（UUID）[RFC4122] 和序列号为形式的全球唯一会话标识符，依赖方可利用该标识符确定其与版本库是否同步。此外，它还包括一个指向版本库服务器发布的当前对象最新完整快照的链接，以及一个指向 Delta 文件的链接列表，每个版本从版本库服务器确定的点开始，直到版本库的当前版本。
A Relying Party that learns about an Update Notification File location for the first time can download it and then proceed to download the latest Snapshot File, thus creating a local copy of the repository that is in sync with the Repository Server. The Relying Party records the location of this Update Notification File, the session_id, and the current serial number.
首次获知更新通知文件位置的依赖方可下载该文件，然后继续下载最新的快照文件，从而创建与版本库服务器同步的版本库本地副本。依赖方记录该更新通知文件的位置、会话 ID 和当前序列号。
Relying Parties are encouraged to re-fetch this Update Notification File at regular intervals, but not more often than once per minute. After re-fetching the Update Notification File, the Relying Party may find that there are one or more Delta Files available that allow it to synchronize its local repository with the current state of the Repository Server. If no contiguous chain of deltas from the Relying Party's serial to the latest repository serial is available, or if the session_id has changed, the Relying Party performs a full resynchronization instead.
鼓励依赖方定期重新获取该更新通知文件，但频率不得超过每分钟一次。重新获取更新通知文件后，依赖方可能会发现有一个或多个可用的 Delta 文件，允许其将本地版本库与版本库服务器的当前状态同步。如果从依赖方序列到最新版本库序列之间没有连续的 Delta 文件链可用，或者 session_id 已发生变化，依赖方将执行全面的重新同步。
As soon as the Relying Party fetches new content in this way, it could start a validation process. An example of a reason why a Relying Party may not choose to do this immediately is because it has learned of more than one notification location, and it prefers to complete all its updates before validating.
一旦依赖方以这种方式获取了新内容，就可以启动验证程序。依赖方可能不会立即这样做的一个原因是，它已得知不止一个通知位置，而且它更希望在验证之前完成所有更新。
The Repository Server could use a caching infrastructure to reduce its load, particularly because snapshots and deltas for any given session_id and serial number contain an immutable record of the state of the Repository Server at a certain point in time. For this reason, these files can be cached indefinitely. Update Notification Files are polled by Relying Parties to discover if updates exist; for this reason, Update Notification Files may not be cached for longer than one minute.
版本库服务器可以使用缓存基础设施来减少负载，特别是因为任何给定会话标识和序列号的快照和延迟都包含版本库服务器在某个时间点的状态的不可更改记录。因此，这些文件可以无限期缓存。依赖方会对更新通知文件进行轮询，以发现是否存在更新；因此，更新通知文件的缓存时间可能不会超过一分钟。
Certificate Authorities that use RRDP MUST include an instance of an SIA AccessDescription extension in resource certificates they produce, in addition to the ones defined in [RFC6487]:
除 [RFC6487] 中定义的扩展外，使用 RRDP 的证书颁发机构必须在其颁发的资源证书中包含一个 SIA AccessDescription 扩展实例：
AccessDescription ::= SEQUENCE {
accessMethod OBJECT IDENTIFIER,
accessLocation GeneralName }
This extension MUST use an accessMethod of id-ad-rpkiNotify; see Section 6:
该扩展必须使用 id-ad-rpkiNotify 的 accessMethod；参见第 6 节：
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
id-ad-rpkiNotify OBJECT IDENTIFIER ::= { id-ad 13 }
The accessLocation MUST be an HTTPS URI as defined in [RFC7230] that will point to the Update Notification File for the Repository Server that publishes the products of this Certificate Authority certificate.
accessLocation 必须是 [RFC7230] 中定义的 HTTPS URI，指向发布证书颁发机构证书产品的存储库服务器的更新通知文件。
When the Repository Server initializes, it performs the following actions:
版本库服务器初始化时，会执行以下操作：
o The server MUST generate a new random version 4 UUID (see Section 4.1.3 of [RFC4122]) to be used as the session_id.
o 服务器必须生成一个新的随机第 4 版 UUID（见 [RFC4122] 第 4.1.3 节），用作会话标识。
o The server MUST then generate a Snapshot File for serial number ONE for this new session that includes all currently known published objects that the Repository Server is responsible for. Note that this Snapshot File may contain zero publish elements at this point if no objects have been submitted for publication yet.
o 然后，服务器必须为这个新会话生成序列号为 ONE 的快照文件，其中包括版本库服务器负责的所有当前已知的已发布对象。请注意，如果尚未提交要发布的对象，该快照文件此时可能不包含任何发布元素。
o This Snapshot File MUST be made available at a URL that is unique to this session_id and serial number, so that it can be cached indefinitely. The format and caching concerns for Snapshot Files are explained in more detail in Section 3.5.2.
o 该快照文件必须在该会话标识和序列号唯一的 URL 上提供，以便可以无限期缓存。快照文件的格式和缓存问题将在第 3.5.2 节中详细说明。
o After the Snapshot File has been published, the Repository Server MUST publish a new Update Notification File that contains the new session_id, has serial number ONE, has one reference to the Snapshot File that was just published, and contains no delta references. The format and caching concerns for Update Notification Files are explained in more detail in Section 3.5.1.
o 发布快照文件后，版本库服务器必须发布一个新的更新通知文件，其中包含新的会话 ID、序列号 ONE、对刚刚发布的快照文件的一次引用，并且不包含 delta 引用。更新通知文件的格式和缓存问题在第 3.5.1 节中有更详细的解释。
Whenever the Repository Server receives updates from a Certificate Authority, it MUST generate new snapshot and Delta Files within one minute. If a Repository Server services a large number of Certificate Authorities, it MAY choose to combine updates from multiple CAs. If a Repository Server combines updates in this way, it MUST ensure that publication never postponed for longer than one minute for any of the CAs involved.
每当存储库服务器收到证书颁发机构的更新时，它必须在一分钟内生成新的快照和 Delta 文件。如果版本库服务器为大量证书颁发机构提供服务，它可以选择合并来自多个颁发机构的更新。如果存储库服务器以这种方式合并更新，则必须确保所涉及的任何 CA 的发布时间均不得推迟超过一分钟。
Updates are processed as follows:
更新处理如下
o The new repository serial number MUST be one greater than the current repository serial number.
o 新版本库序列号必须比当前版本库序列号大一个。
o A new Delta File MUST be generated for this new serial. This Delta File MUST include all new, replaced, and withdrawn objects for multiple CAs, if applicable, as a single change set.
o 必须为该新序列生成一个新的 Delta 文件。该 Delta 文件必须包括多个 CA 的所有新对象、被替换对象和撤销对象（如适用），作为一个单一的变更集。
o This Delta File MUST be made available at a URL that is unique to the current session_id and serial number, so that it can be cached indefinitely.
o 该 Delta 文件必须通过与当前会话 ID 和序列号唯一的 URL 提供，以便可以无限期缓存。
o The format and caching concerns for Delta Files are explained in more detail in Section 3.5.3.
o 有关 Delta 文件的格式和缓存问题，请参见第 3.5.3 节。
o The Repository Server MUST also generate a new Snapshot File for this new serial. This file MUST contain all "publish" elements for all current objects.
o 版本库服务器还必须为这个新序列生成一个新的快照文件。该文件必须包含所有当前对象的所有 "发布 "元素。
o The Snapshot File MUST be made available at a URL that is unique to this session and new serial, so that it can be cached indefinitely.
o 快照文件必须在一个 URL 上提供，该 URL 对于此会话和新序列是唯一的，以便可以无限期缓存。
o The format and caching concerns for Snapshot Files are explained in more detail in Section 3.5.2.
o 快照文件的格式和缓存问题将在第 3.5.2 节中详细说明。
o Any older Delta Files that, when combined with all more recent Delta Files, will result in the total size of deltas exceeding the size of the snapshot MUST be excluded to avoid that Relying Parties download more data than necessary.
o 任何较旧的 Delta 文件，如果与所有较新的 Delta 文件结合在一起，将导致 Delta 文件的总大小超过快照的大小，则必须排除在外，以避免依赖方下载超过必要的数据。
o A new Update Notification File MUST now be created by the Repository Server. This new Update Notification File MUST include a reference to the new Snapshot File and all Delta Files selected in the previous steps.
o 版本库服务器现在必须创建一个新的更新通知文件。这个新的更新通知文件必须包括对新快照文件和前面步骤中选择的所有 Delta 文件的引用。
o The format and caching concerns for Update Notification Files are explained in more detail in Section 3.5.1.
o 更新通知文件的格式和缓存问题将在第 3.5.1 节中详细说明。
If the Repository Server is not capable of performing the above for some reason, then it MUST perform a full re-initialization, as explained above in Section 3.3.1.
如果版本库服务器由于某种原因无法执行上述操作，则必须执行全面的重新初始化，如第 3.3.1 节所述。
When a Relying Party performs RPKI validation and learns about a valid certificate with an SIA entry for the RRDP protocol, it SHOULD use this protocol as follows.
当依赖方执行 RPKI 验证并得知有效证书上有 RRDP 协议的 SIA 条目时，依赖方应按以下方式使用该协议。
The Relying Party MUST download the Update Notification File, unless an Update Notification File was already downloaded and processed from the same location in this validation run or a polling strategy was used (see Section 3.4.4).
依赖方必须下载更新通知文件，除非在本次验证运行中已从同一位置下载并处理了更新通知文件或使用了轮询策略（见第 3.4.4 节）。
It is RECOMMENDED that the Relying Party uses a "User-Agent" header explained in Section 5.5.3. of [RFC7231] to identify the name and version of the Relying Party software used. It is useful to track capabilities of Relying Parties in the event of changes to the RPKI standards.
建议依赖方使用[RFC7231]第 5.5.3 节中解释的 "User-Agent "标头来标识所使用的依赖方软件的名称和版本。这有助于在 RPKI 标准发生变化时跟踪依赖方的能力。
When the Relying Party downloads an Update Notification File, it MUST verify the file format and validation steps described in Section 3.5.1.3. If this verification fails, the file MUST be rejected and RRDP cannot be used. See Section 3.4.5 for considerations.
依赖方下载更新通知文件时，必须验证文件格式和第 3.5.1.3 节所述的验证步骤。如果验证失败，则必须拒绝该文件，并且不能使用 RRDP。有关注意事项，请参阅第 3.4.5 节。
The Relying Party MUST verify whether the session_id matches the last known session_id for this Update Notification File location. Note that even though the session_id is a random UUID value, it alone MUST NOT be used by a Relying Party as a unique identifier of a session but always together with the location of the Update Notification File. The reason for this is that a malicious server can use an existing session_id from another Repository Server.
依赖方必须验证会话标识（session_id）是否与该更新通知文件位置的最后已知会话标识（session_id）相匹配。请注意，即使 session_id 是随机 UUID 值，依赖方也不得将其单独用作会话的唯一标识符，而应始终与更新通知文件的位置一起使用。这样做的原因是，恶意服务器可以使用另一个版本库服务器的现有会话 ID。
If the session_id matches the last known session_id, then a Relying Party MAY download and process missing Delta Files as described in Section 3.4.2, provided that all Delta Files for serial numbers between the last processed serial number and the current serial number in the Update Notification File can be processed this way.
如果会话标识（session_id）与最后已知的会话标识（session_id）相匹配，那么依赖方可以按照第 3.4.2 节所述下载和处理缺失的 Delta 文件，前提是更新通知文件中所有序列号介于最后处理的序列号和当前序列号之间的 Delta 文件都能以这种方式处理。
If the session_id matches the last known session_id, but Delta Files were not used, then the Relying Party MUST download and process the Snapshot File on the Update Notification File as described in Section 3.4.3.
如果会话标识（session_id）与最后已知的会话标识（session_id）匹配，但未使用 Delta 文件，则依赖方必须按照第 3.4.3 节所述下载和处理更新通知文件上的快照文件。
If the session_id does not match the last known session_id, the Relying Party MUST update its last known session_id to the value specified in the downloaded Update Notification File. The Relying Party MUST then download and process the Snapshot File specified in the downloaded Update Notification File as described in Section 3.4.3.
如果会话标识（session_id）与最后已知的会话标识（session_id）不匹配，依赖方必须将其最后已知的会话标识（session_id）更新为下载的更新通知文件中指定的值。然后，依赖方必须按照第 3.4.3 节所述下载并处理下载的更新通知文件中指定的快照文件。
If an Update Notification File contains a contiguous chain of links to Delta Files from the last processed serial number to the current serial number, then Relying Parties MUST attempt to download and process all Delta Files in order of serial number as follows.
如果更新通知文件包含从最后处理的序列号到当前序列号的 Delta 文件连续链接链，则依赖方必须按以下序列号顺序尝试下载和处理所有 Delta 文件。
When the Relying Party downloads a Delta File, it MUST verify the file format and perform validation steps described in Section 3.5.3.3. If this verification fails, the file MUST be rejected.
依赖方下载 Delta 文件时，必须验证文件格式并执行第 3.5.3.3 节所述的验证步骤。如果验证失败，则必须拒绝该文件。
Furthermore, the Relying Party MUST verify that the hash of the contents of this file matches the hash on the Update Notification File that referenced it. In case of a mismatch of this hash, the file MUST be rejected.
此外，依赖方必须验证该文件内容的哈希值是否与引用该文件的更新通知文件上的哈希值一致。如果哈希值不匹配，则必须拒绝该文件。
If a Relying Party retrieved a Delta File that is valid according to the above criteria, it performs the following actions:
如果依赖方根据上述标准检索到有效的 Delta 文件，它将执行以下操作：
o The Relying Party MUST verify that the session_id matches the session_id of the Update Notification File. If the session_id values do not match, the file MUST be rejected.
o 依赖方必须验证 session_id 是否与更新通知文件的 session_id 匹配。如果会话 ID 值不匹配，则必须拒绝该文件。
o The Relying Party MUST verify that the serial number of this Delta File is exactly one greater than the last processed serial number for this session_id, and if not, this file MUST be rejected.
o 依赖方必须验证此 Delta 文件的序列号是否比此 session_id 上一次处理的序列号多一个，如果不是，则必须拒绝此文件。
o The Relying Party SHOULD add all publish elements to a local storage and update its last processed serial number to the serial number of this Delta File.
o 依赖方应将所有发布元素添加到本地存储中，并将其最后处理的序列号更新为该 Delta 文件的序列号。
o When a Relying Party encounters a "withdraw" element, or a "publish" element where an object is replaced, in a delta that it retrieves from a Repository Server, it MUST verify that the object to be withdrawn or replaced was retrieved from this same Repository Server before applying the appropriate action. Failing to do so will leave the Relying Party vulnerable to malicious Repository Servers instructing it to delete or change arbitrary objects.
o 当依赖方在从版本库服务器检索的 delta 中遇到 "撤回 "元素或对象被替换的 "发布 "元素时，必须在应用适当的操作之前验证要撤回或替换的对象是从同一版本库服务器检索的。如果不这样做，依赖方就很容易受到恶意版本库服务器的攻击，它们会指示依赖方删除或更改任意对象。
If any Delta File is rejected, Relying Parties MUST process the current Snapshot File instead, as described in Section 3.4.3.
如果任何 Delta 文件被拒绝，依赖方必须按照第 3.4.3 节所述处理当前快照文件。
Snapshot Files MUST only be used if Delta Files are unavailable or were rejected; for a description of the process, see Section 3.4.1.
只有在 Delta 文件不可用或被拒绝时，才必须使用快照文件；有关过程的说明，请参见第 3.4.1 节。
When the Relying Party downloads a Snapshot File, it MUST verify the file format and validation steps described in Section 3.5.2.3. If this verification fails, the file MUST be rejected.
依赖方下载快照文件时，必须验证文件格式和第 3.5.2.3 节所述的验证步骤。如果验证失败，则必须拒绝该文件。
Furthermore, the Relying Party MUST verify that the hash of the contents of this file matches the hash on the Update Notification File that referenced it. In case of a mismatch of this hash, the file MUST be rejected.
此外，依赖方必须验证该文件内容的哈希值是否与引用该文件的更新通知文件上的哈希值一致。如果哈希值不匹配，则必须拒绝该文件。
If a Relying Party retrieved a Snapshot File that is valid according to the above criteria, it performs the following actions:
如果依赖方根据上述标准检索到有效的快照文件，则会执行以下操作：
o The Relying Party MUST verify that the session_id matches the session_id of the Update Notification File. If the session_id values do not match, the file MUST be rejected.
o 依赖方必须验证 session_id 是否与更新通知文件的 session_id 匹配。如果会话 ID 值不匹配，则必须拒绝该文件。
o The Relying Party MUST verify that the serial number of this Snapshot File is greater than the last processed serial number for this session_id. If this fails, the file MUST be rejected.
o 依赖方必须验证此快照文件的序列号大于此会话标识号的最后处理序列号。如果验证失败，则必须拒绝该文件。
o The Relying Party SHOULD then add all publish elements to a local storage and update its last processed serial number to the serial number of this Snapshot File.
o 然后，依赖方应将所有发布元素添加到本地存储中，并将其最后处理的序列号更新为该快照文件的序列号。
If a Snapshot File is rejected, it means that RRDP cannot be used. See Section 3.4.5 for considerations.
如果快照文件被拒绝，则意味着无法使用 RRDP。有关注意事项，请参见第 3.4.5 节。
Once a Relying Party has learned about the location, session_id, and last processed serial number of the repository that uses the RRDP protocol, the Relying Party MAY start polling the Repository Server for updates. However, the Relying Party MUST NOT poll for updates more often than once every 1 minute, and in order to reduce data usage, Relying Parties MUST use the "If-Modified-Since" header explained in Section 3.3 of [RFC7232] in requests.
一旦依赖方了解了使用 RRDP 协议的版本库的位置、会话 ID 和最后处理序列号，依赖方就可以开始轮询版本库服务器以获取更新。但是，依赖方轮询更新的频率不得超过每 1 分钟一次，而且为了减少数据使用量，依赖方必须在请求中使用 [RFC7232] 第 3.3 节中解释的 "If-Modified-Since"（如果已修改）标头。
If a Relying Party finds that updates are available, it SHOULD download and process the file as described in Section 3.4.1 and initiate a new RPKI object validation process. However, a detailed description of the RPKI object validation process itself is out of scope of this document.
如果依赖方发现更新可用，则应按照第 3.4.1 节所述下载和处理文件，并启动新的 RPKI 对象验证流程。不过，对 RPKI 对象验证流程本身的详细说明不在本文档的讨论范围之内。
If a Relying Party experiences any issues with retrieving or processing any of the files used in this protocol, it will be unable to retrieve new RPKI data from the affected Repository Server.
如果依赖方在检索或处理本协议中使用的任何文件时遇到任何问题，它将无法从受影响的存储库服务器检索新的 RPKI 数据。
Relying Parties could attempt to use alternative repository access mechanisms, if they are available, according to the accessMethod element value(s) specified in the SIA of the associated certificate (see Section 4.8.8 of [RFC6487]).
依赖方可根据相关证书 SIA 中指定的 accessMethod 元素值（见 [RFC6487] 第 4.8.8 节），尝试使用其他存储库访问机制（如果有的话）。
Furthermore, Relying Parties may wish to employ re-try strategies while fetching RRDP files. Relying Parties are also advised to keep old objects in their local cache so that validation can be done using old objects.
此外，依赖方在获取 RRDP 文件时不妨采用重试策略。还建议依赖方在本地缓存中保留旧对象，以便使用旧对象进行验证。
It is also recommendable that re-validation and retrieval is performed pro-actively before manifests or CRLs go stale, or certificates expire, to ensure that problems on the side of the Relying Party can be identified and resolved before they cause major concerns.
此外，还建议在清单或 CRL 过期或证书过期之前主动进行重新验证和检索，以确保依赖方方面的问题在引起重大问题之前就能被发现和解决。
The Update Notification File is used by Relying Parties to discover whether any changes exist between the state of the repository and the Relying Party's cache. It describes the location of the files containing the snapshot and incremental deltas, which can be used by the Relying Party to synchronize with the repository.
依赖方使用更新通知文件来发现版本库状态与依赖方缓存之间是否存在任何变化。它描述了包含快照和增量延迟的文件位置，依赖方可使用这些文件与存储库同步。
A Repository Server MAY use caching infrastructure to cache the Update Notification File and reduce the load of HTTPS requests. However, since this file is used by Relying Parties to determine whether any updates are available, the Repository Server SHOULD ensure that this file is not cached for longer than 1 minute. An exception to this rule is that it is better to serve a stale Update Notification File rather than no Update Notification File.
版本库服务器可以使用缓存基础设施来缓存更新通知文件，以减少 HTTPS 请求的负载。但是，由于依赖方使用该文件来确定是否有可用的更新，因此版本库服务器应确保该文件的缓存时间不超过 1 分钟。此规则的例外情况是，提供过期的更新通知文件比不提供更新通知文件要好。
How this is achieved exactly depends on the caching infrastructure used. In general, a Repository Server may find certain HTTP headers to be useful, such as: "Cache-Control: max-age=60" (see Section 5.2 of [RFC7234]). Another approach can be to have the Repository Server push out new versions of the Update Notification File to the caching infrastructure when appropriate.
具体如何实现这一点，取决于所使用的缓存基础设施。一般来说，版本库服务器可能会发现某些 HTTP 标头是有用的，比如 "Cache-Control: max-age=60" （参见 [RFC7234] 第 5.2 节）："Cache-Control:max-age=60"（参见 [RFC7234] 第 5.2 节）。另一种方法是让版本库服务器在适当的时候向缓存基础设施推送新版本的更新通知文件。
In case of a high load on a Repository Server or its distribution network, the Cache-Control HTTP header, or a similar mechanism, MAY be used to suggest an optimal (for the Repository Server) poll interval for Relying Parties. However, setting it to an interval longer than 1 hour is NOT RECOMMENDED. Relying parties SHOULD align the suggested interval with their operational practices and the expected update frequency of RPKI repository data and MAY discard the suggested value.
在版本库服务器或其分发网络负载较高的情况下，可以使用 Cache-Control HTTP 标头或类似机制来建议依赖方的最佳（版本库服务器的）轮询间隔。但是，不建议将其设置为超过 1 小时的间隔。依赖方应根据其操作实践和 RPKI 资源库数据的预期更新频率调整建议的间隔，并可以放弃建议的值。
Example Update Notification File:
更新通知文件示例：
<notification xmlns="http://www.ripe.net/rpki/rrdp"
version="1"
session_id="9df4b597-af9e-4dca-bdda-719cce2c4e28"
serial="3">
<snapshot uri="https://host/9d-8/3/snapshot.xml" hash="AB"/>
<delta serial="3" uri="https://host/9d-8/3/delta.xml" hash="CD"/>
<delta serial="2" uri="https://host/9d-8/2/delta.xml" hash="EF"/>
</notification>
Note: URIs and hash values in this example are shortened because of formatting.
注：由于格式原因，本示例中的 URI 和哈希值被缩短。
The following validation rules MUST be observed when creating or parsing Update Notification Files:
创建或解析更新通知文件时必须遵守以下验证规则：
o A Relying Party MUST reject any Update Notification File that is not well-formed or does not conform to the RELAX NG schema outlined in Section 3.5.4 of this document.
o 依赖方必须拒绝任何格式不佳或不符合本文档第 3.5.4 节所述 RELAX NG 模式的更新通知文件。
o The XML namespace MUST be "http://www.ripe.net/rpki/rrdp".
o XML 命名空间必须是 "http://www.ripe.net/rpki/rrdp"。
o The encoding MUST be "US-ASCII".
o 编码必须是 "US-ASCII"。
o The version attribute in the notification root element MUST be "1".
o 通知根元素中的版本属性必须为 "1"。
o The session_id attribute MUST be a random version 4 UUID [RFC4122], unique to this session.
o session_id 属性必须是该会话唯一的随机第 4 版 UUID [RFC4122]。
o The serial attribute MUST be an unbounded, unsigned positive integer in decimal format indicating the current version of the repository.
o 序列属性必须是一个十进制格式的无限制、无符号正整数，表示版本库的当前版本。
o The Update Notification File MUST contain exactly one 'snapshot' element for the current repository version.
o 更新通知文件必须正好包含一个当前版本库版本的 "快照 "元素。
o If delta elements are included, they MUST form a contiguous sequence of serial numbers starting at a revision determined by the Repository Server, up to the serial number mentioned in the notification element. Note that the elements may not be ordered.
o 如果包含 delta 元素，它们必须构成一个连续的序列号序列，从版本库服务器确定的修订版开始，直到通知元素中提到的序列号为止。请注意，这些元素不得排序。
o The hash attribute in snapshot and delta elements MUST be the hexadecimal encoding of the SHA-256 [SHS] hash of the referenced file. The Relying Party MUST verify this hash when the file is retrieved and reject the file if the hash does not match.
o 快照和 delta 元素中的哈希属性必须是引用文件的 SHA-256 [SHS] 哈希值的十六进制编码。依赖方必须在检索文件时验证哈希值，如果哈希值不匹配，则拒绝该文件。
A snapshot is intended to reflect the complete and current contents of the repository for a specific session and version. Therefore, it MUST contain all objects from the repository current as of the time of the publication.
快照旨在反映特定会话和版本的版本库完整的当前内容。因此，快照必须包含发布时版本库中的所有对象。
A snapshot reflects the content of the repository at a specific point in time; for that reason, it can be considered immutable data. Snapshot Files MUST be published at a URL that is unique to the specific session and serial.
快照反映了版本库在特定时间点的内容；因此，它可被视为不可变的数据。快照文件必须在特定会话和序列唯一的 URL 上发布。
Because these files never change, they MAY be cached indefinitely. However, in order to prevent these files from using a lot of space in the caching infrastructure, it is RECOMMENDED that a limited interval is used in the order of hours or days.
由于这些文件从不更改，因此可以无限期缓存。不过，为了防止这些文件占用缓存基础设施的大量空间，建议使用有限的时间间隔，以小时或天为单位。
To avoid race conditions where a Relying Party downloads an Update Notification File moments before it's updated, Repository Servers SHOULD retain old Snapshot Files for at least 5 minutes after a new Update Notification File is published.
为避免依赖方在更新前下载更新通知文件时出现竞赛情况，版本库服务器应在发布新的更新通知文件后至少保留旧的快照文件 5 分钟。
Example Snapshot File:
快照文件示例：
<snapshot xmlns="http://www.ripe.net/rpki/rrdp"
version="1"
session_id="9df4b597-af9e-4dca-bdda-719cce2c4e28"
serial="2">
<publish uri="rsync://rpki.ripe.net/Alice/Bob.cer">
ZXhhbXBsZTE=
</publish>
<publish uri="rsync://rpki.ripe.net/Alice/Alice.mft">
ZXhhbXBsZTI=
</publish>
<publish uri="rsync://rpki.ripe.net/Alice/Alice.crl">
ZXhhbXBsZTM=
</publish>
</snapshot>
The following rules MUST be observed when creating or parsing Snapshot Files:
创建或解析快照文件时必须遵守以下规则：
o A Relying Party MUST reject any Snapshot File that is not well-formed or does not conform to the RELAX NG schema outlined in Section 3.5.4 of this document.
o 依赖方必须拒绝任何格式不佳或不符合本文档第 3.5.4 节所述 RELAX NG 模式的快照文件。
o The XML namespace MUST be "http://www.ripe.net/rpki/rrdp".
o XML 命名空间必须是 "http://www.ripe.net/rpki/rrdp"。
o The encoding MUST be "US-ASCII".
o 编码必须是 "US-ASCII"。
o The version attribute in the notification root element MUST be "1".
o 通知根元素中的版本属性必须为 "1"。
o The session_id attribute MUST match the expected session_id in the reference in the Update Notification File.
o session_id 属性必须与更新通知文件中引用的预期 session_id 匹配。
o The serial attribute MUST match the expected serial in the reference in the Update Notification File.
o 序列属性必须与更新通知文件中引用的预期序列相匹配。
o Note that the publish element is similar to the publish element defined in the publication protocol [RFC8181]. However, the "tag" attribute is not used here because it is not relevant to Relying Parties. The "hash" attribute is not used here because this file represents a complete current state of the repository; therefore, it is not relevant to know which existing RPKI object (if any) is updated.
o 请注意，发布元素与发布协议 [RFC8181] 中定义的发布元素类似。不过，这里没有使用 "tag "属性，因为它与依赖方无关。这里不使用 "哈希 "属性，因为该文件代表了存储库的完整当前状态；因此，与了解哪个现有 RPKI 对象（如果有的话）被更新无关。
An incremental Delta File contains all changes for exactly one serial increment of the Repository Server. In other words, a single delta will typically include all the new objects, updated objects, and withdrawn objects that a Certification Authority sent to the Repository Server. In its simplest form, the update could concern only a single object, but it is RECOMMENDED that CAs send all changes for one of their key pairs (updated objects as well as a new manifest and CRL) as one atomic update message.
增量 Delta 文件包含版本库服务器一个序列增量的所有更改。换句话说，单个 Delta 文件通常包括认证机构发送到版本库服务器的所有新对象、更新对象和撤销对象。在最简单的形式中，更新可能只涉及一个对象，但建议 CA 将其一个密钥对的所有更改（更新对象以及新清单和 CRL）作为一个原子更新消息发送。
Deltas reflect the difference between two consecutive versions of a repository for a given session. For that reason, deltas can be considered immutable data. Delta Files MUST be published at a URL that is unique to the specific session and serial.
递减量反映了特定会话中两个连续版本的版本库之间的差异。因此，三角洲可被视为不可变数据。Delta 文件必须发布在特定会话和序列唯一的 URL 上。
Because these files never change, they MAY be cached indefinitely. However, in order to prevent these files from using a lot of space in the caching infrastructure, it is RECOMMENDED that a limited interval is used in the order of hours or days.
由于这些文件从不更改，因此可以无限期缓存。不过，为了防止这些文件占用缓存基础架构的大量空间，建议使用有限的时间间隔，以小时或天为单位。
To avoid race conditions where a Relying Party downloads an Update Notification File moments before it's updated, Repository Servers SHOULD retain old Delta Files for at least 5 minutes after they are no longer included in the latest Update Notification File.
为避免依赖方在更新通知文件之前下载更新通知文件时出现竞赛情况，版本库服务器应在最新更新通知文件中不再包含旧 Delta 文件后至少保留 5 分钟。
Example Delta File:
Delta 文件示例：
<delta xmlns="http://www.ripe.net/rpki/rrdp"
version="1"
session_id="9df4b597-af9e-4dca-bdda-719cce2c4e28"
serial="3">
<publish uri="rsync://rpki.ripe.net/repo/Alice/Alice.mft"
hash="50d8...545c">
ZXhhbXBsZTQ=
</publish>
<publish uri="rsync://rpki.ripe.net/repo/Alice/Alice.crl"
hash="5fb1...6a56">
ZXhhbXBsZTU=
</publish>
<withdraw uri="rsync://rpki.ripe.net/repo/Alice/Bob.cer"
hash="caeb...15c1"/>
</delta>
Note that a formal RELAX NG specification of this file format is included later in this document. A Relying Party MUST NOT process any Delta File that is incomplete or not well-formed.
请注意，本文档稍后将包含该文件格式的正式 RELAX NG 规范。依赖方不得处理任何不完整或格式不规范的 Delta 文件。
The following validation rules MUST be observed when creating or parsing Delta Files:
创建或解析 Delta 文件时必须遵守以下验证规则：
o A Relying Party MUST reject any Delta File that is not well-formed or does not conform to the RELAX NG schema outlined in Section 3.5.4 of this document.
o 依赖方必须拒绝任何格式不佳或不符合本文档第 3.5.4 节所述 RELAX NG 模式的 Delta 文件。
o The XML namespace MUST be "http://www.ripe.net/rpki/rrdp".
o XML 命名空间必须是 "http://www.ripe.net/rpki/rrdp"。
o The encoding MUST be "US-ASCII".
o 编码必须是 "US-ASCII"。
o The version attribute in the delta root element MUST be "1".
o delta 根元素中的版本属性必须是 "1"。
o The session_id attribute MUST be a random version 4 UUID unique to this session.
o session_id 属性必须是该会话独有的随机第 4 版 UUID。
o The session_id attribute MUST match the expected session_id in the reference in the Update Notification File.
o session_id 属性必须与更新通知文件中引用的预期 session_id 匹配。
o The serial attribute MUST match the expected serial in the reference in the Update Notification File.
o 序列属性必须与更新通知文件中引用的预期序列相匹配。
o Note that the publish element is similar to the publish element defined in the publication protocol [RFC8181]. However, the "tag" attribute is not used here because it is not relevant to Relying Parties.
o 请注意，发布元素与发布协议 [RFC8181] 中定义的发布元素类似。不过，这里不使用 "tag "属性，因为它与依赖方无关。
The following is a RELAX NG compact form schema describing version 1 of this protocol.
以下是描述本协议第 1 版的 RELAX NG 简洁格式模式。
# # RELAX NG schema for the RPKI Repository Delta Protocol (RRDP). #
# RPKI 资源库三角协议（RRDP）的 RELAX NG 模式。#
default namespace = "http://www.ripe.net/rpki/rrdp"
默认命名空间 = "http://www.ripe.net/rpki/rrdp"
version = xsd:positiveInteger { maxInclusive="1" }
serial = xsd:positiveInteger
uri = xsd:anyURI
uuid = xsd:string { pattern = "[\-0-9a-fA-F]+" }
hash = xsd:string { pattern = "[0-9a-fA-F]+" }
base64 = xsd:base64Binary
# Notification File: lists current snapshots and deltas.
# 通知文件：列出当前快照和延迟。
start |= element notification {
attribute version { version },
attribute session_id { uuid },
attribute serial { serial },
element snapshot {
attribute uri { uri },
attribute hash { hash }
},
element delta {
attribute serial { serial },
attribute uri { uri },
attribute hash { hash }
}*
}
# Snapshot segment: think DNS AXFR.
# 快照段：认为 DNS AXFR。
start |= element snapshot {
attribute version { version },
attribute session_id { uuid },
attribute serial { serial },
element publish {
attribute uri { uri },
base64
}*
}
# Delta segment: think DNS IXFR.
# Delta 段：考虑 DNS IXFR。
start |= element delta {
attribute version { version },
attribute session_id { uuid },
attribute serial { serial },
delta_element+
}
delta_element |= element publish {
attribute uri { uri },
attribute hash { hash }?,
base64
}
delta_element |= element withdraw {
attribute uri { uri },
attribute hash { hash }
}
# Local Variables: # indent-tabs-mode: nil # comment-start: "# " # comment-start-skip: "#[ \t]*" # End:
# 本地变量：# indent-tabs-mode: nil # comment-start："# " # comment-start-skip："#[ \t]*"# 结束：
This protocol has been designed to replace rsync as a distribution mechanism of an RPKI repository. However, it is also designed to coexist with existing implementations based on rsync, to enable smooth transition from one distribution mechanism to another.
该协议旨在取代 rsync 作为 RPKI 资源库的分发机制。不过，它也可与基于 rsync 的现有实现并存，以实现从一种分发机制到另一种分发机制的平稳过渡。
For every repository object listed in the Snapshot and Delta Files, both the hash of the object's content and the rsync URI [RFC5781] of its location in the repository are listed. This makes it possible to distribute the same RPKI repository, represented by a set of files on a filesystem, using both rsync and RRDP. It also enables Relying Parties tools to query, combine, and consequently validate objects from repositories of different types.
对于快照和 Delta 文件中列出的每个版本库对象，都会列出该对象内容的哈希值及其在版本库中位置的 rsync URI [RFC5781]。这样，就可以同时使用 rsync 和 RRDP 发布由文件系统上的一组文件表示的同一个 RPKI 资源库。它还能让依赖方工具查询、组合和验证来自不同类型资源库的对象。
One of the design goals of RRDP was to minimize load on a Repository Server while serving clients. To achieve this, neither the content nor the URLs of the Snapshot and Delta Files are modified after they have been published in the Update Notification File. This allows their effective distribution by using either a single HTTP server or a CDN.
RRDP 的设计目标之一是在为客户提供服务时尽量减少版本库服务器的负载。为此，在更新通知文件中发布快照和 Delta 文件后，其内容和 URL 都不会被修改。这样就可以通过使用单个 HTTP 服务器或 CDN 有效地分发这些文件。
The RECOMMENDED way for Relying Parties to keep up with the repository updates is to poll the Update Notification File for changes. The content of that file is updated with every new serial version of a repository (while its URL remains stable). To effectively implement distribution of the Update Notification File, an "If-Modified-Since" HTTP request header is required to be present in all requests for the Update Notification File (see Section 3.4.4). Therefore, it is RECOMMENDED that Relying Party tools implement a mechanism to keep track of a previous successful fetch of an Update Notification File.
依赖方跟上版本库更新的推荐方法是轮询更新通知文件以了解变化情况。该文件的内容会随版本库的每个新序列版本而更新（同时其 URL 保持稳定）。为有效分发更新通知文件，所有更新通知文件请求都必须包含 "If-Modified-Since"（如果已修改-自何时起）HTTP 请求标头（见第 3.4.4 节）。因此，建议依赖方工具实施一种机制，以跟踪上一次成功获取更新通知文件的情况。
Implementations of RRDP should also take care of not producing new versions of the repository (and subsequently, new Update Notification, Snapshot, and Delta Files) too often. Usually the maintenance of the RPKI repository includes regular updates of manifest and CRL objects performed on a schedule. This often results in bursts of repository updates during a short period of time. Since the Relying Parties are required to poll for the Update Notification File not more often than once per minute (Section 3.4.4), it is not practical to generate new serial versions of the repository much more often than 1 per minute. It is allowed to combine multiple updates, possibly from different CAs, into a new serial repository version (Section 3.3.2). This will significantly shorten the size of the Update Notification File and total amount of data distributed to all Relying Parties.
实施 RRDP 时还应注意不要过于频繁地生成新版本的资源库（以及随后的新更新通知、快照和 Delta 文件）。RPKI 资源库的维护通常包括按计划定期更新清单和 CRL 对象。这往往会导致在短时间内出现存储库更新的突发情况。由于依赖方被要求轮询更新通知文件的频率不得超过每分钟一次（第 3.4.4 节），因此生成新版本的频率超过每分钟 1 次是不现实的。允许将多个更新（可能来自不同 CA）合并为一个新的版本库序列版本（第 3.3.2 节）。这将大大缩短更新通知文件的大小和分发给所有依赖方的数据总量。
Note that a Man in the Middle (MITM) cannot produce validly signed RPKI data but can perform withhold or replay attacks targeting a Relying Party and keep the Relying Party from learning about changes in the RPKI. Because of this, Relying Parties SHOULD do TLS certificate and host name validation when they fetch from an RRDP Repository Server.
请注意，"中间人"（MITM）无法生成有效签名的 RPKI 数据，但可以针对依赖方实施扣留或重放攻击，使依赖方无法了解 RPKI 的变化。因此，依赖方从 RRDP 资源库服务器获取数据时，应进行 TLS 证书和主机名验证。
Relying Party tools SHOULD log any TLS certificate or host name validation issues found, so that an operator can investigate the cause. However, such validation issues are often due to configuration errors or a lack of a common TLS trust anchor. In these cases, it is better if the Relying Party retrieves the signed RPKI data regardless and performs validation on it. Therefore, the Relying Party MUST continue to retrieve the data in case of errors. The Relying Party MAY choose to log encountered issues only when fetching the Update Notification File, but not when it subsequently fetches Snapshot or Delta Files from the same host. Furthermore, the Relying Party MAY provide a way for operators to accept untrusted connections for a given host, after the cause has been identified.
依赖方工具应记录发现的任何 TLS 证书或主机名验证问题，以便操作员调查原因。不过，此类验证问题通常是由于配置错误或缺乏通用 TLS 信任锚造成的。在这种情况下，依赖方最好能检索已签名的 RPKI 数据并对其进行验证。因此，在出现错误时，依赖方必须继续检索数据。依赖方可以选择仅在获取更新通知文件时记录遇到的问题，而不是在随后从同一主机获取快照或 Delta 文件时记录遇到的问题。此外，依赖方可以提供一种方法，让操作员在查明原因后接受特定主机的不信任连接。
It is RECOMMENDED that Relying Parties and Repository Servers follow the Best Current Practices outlined in [RFC7525] on the use of HTTP over TLS (HTTPS) [RFC7230]. Relying Parties SHOULD do TLS certificate and host name validation using subjectAltName dNSName identities as described in [RFC6125]. The rules and guidelines defined in [RFC6125] apply here, with the following considerations:
建议依赖方和版本库服务器遵循 [RFC7525] 中概述的关于使用 HTTP over TLS (HTTPS) [RFC7230] 的当前最佳做法。依赖方应使用 [RFC6125] 中所述的 subjectAltName dNSName 身份进行 TLS 证书和主机名验证。此处适用 [RFC6125] 中定义的规则和指南，但须考虑以下因素：
o Relying Parties and Repository Servers SHOULD support the DNS-ID identifier type. The DNS-ID identifier type SHOULD be present in Repository Server certificates.
o 依赖方和版本库服务器应支持 DNS-ID 标识符类型。版本库服务器证书中应包含 DNS-ID 标识符类型。
o DNS names in Repository Server certificates SHOULD NOT contain the wildcard character "*".
o 版本库服务器证书中的 DNS 名称不应包含通配符 "*"。
o A Common Name (CN) field may be present in a Repository Server certificate's subject name but SHOULD NOT be used for authentication within the rules described in [RFC6125].
o 在 [RFC6125] 所描述的规则范围内，存储库服务器证书的主题名称中可能会出现通用名 (CN) 字段，但不应将其用于身份验证。
o This protocol does not require the use of SRV-IDs.
o 该协议不需要使用 SRV-ID。
o This protocol does not require the use of URI-IDs.
o 本协议不要求使用 URI-ID。
Note, however, that this validation is done on a best-effort basis and serves to highlight potential issues, but RPKI object security does not depend on this. Therefore, Relying Parties MAY deviate from the validation steps listed above.
但要注意的是，这种验证是在尽力而为的基础上进行的，旨在突出潜在的问题，但 RPKI 对象的安全性并不取决于此。因此，依赖方可以偏离上述验证步骤。
RRDP deals exclusively with the transfer of RPKI objects from a Repository Server to a Relying Party. The trust relation between a Certificate Authority and its Repository Server is out of scope for this document. However, it should be noted that from a Relying Party point of view, all RPKI objects (certificates, CRLs, and objects wrapped in Cryptographic Message Syntax (CMS)) are already covered by object security mechanisms including signed manifests. This allows validation of these objects even though the Repository Server itself is not trusted. This document makes no change to RPKI validation procedures per se.
RRDP 专门处理 RPKI 对象从存储处服务器向依赖方的传输。证书颁发机构与其存储服务器之间的信任关系不属于本文件的讨论范围。不过，需要注意的是，从依赖方的角度来看，所有 RPKI 对象（证书、CRL 和以加密信息语法 (CMS) 封装的对象）都已被对象安全机制（包括已签名的清单）所覆盖。这样，即使版本库服务器本身不受信任，也能对这些对象进行验证。本文件对 RPKI 验证程序本身不作任何更改。
The original RPKI transport protocol is rsync, which offers no channel security mechanism. RRDP replaces the use of rsync by HTTPS; while the channel security mechanism underlying RRDP (HTTPS) is not a cure-all, it does make some forms of denial-of-service attacks more difficult for the attacker. HTTPS issues are discussed in more detail in Section 4.3.
最初的 RPKI 传输协议是 rsync，它不提供通道安全机制。RRDP 以 HTTPS 取代了 rsync；虽然 RRDP 的基础通道安全机制（HTTPS）不是万能的，但它确实增加了攻击者进行某些形式的拒绝服务攻击的难度。HTTPS 问题将在第 4.3 节中详细讨论。
Supporting both RRDP and rsync necessarily increases the number of opportunities for a malicious RPKI Certificate Authority to perform denial-of-service attacks on Relying Parties, by expanding the number of URIs which the Relying Party may need to contact in order to complete a validation run. However, other than the relative cost of HTTPS versus rsync, adding RRDP to the mix does not change this picture significantly: with either RRDP or rsync a malicious Certificate Authority can supply an effectively infinite series of URIs for the Relying Party to follow. The only real solution to this is for the Relying Party to apply some kind of bound to the amount of work it is willing to do. Note also that the attacker in this scenario must be an RPKI Certificate Authority; otherwise, the normal RPKI object security checks would reject the malicious URIs.
同时支持 RRDP 和 rsync 必然会增加恶意 RPKI 证书颁发机构对依赖方进行拒绝服务攻击的机会，因为依赖方可能需要联系更多的 URI 才能完成验证运行。然而，除了 HTTPS 相对于 rsync 的相对成本外，添加 RRDP 并不能显著改变这种情况：无论使用 RRDP 还是 rsync，恶意证书颁发机构都能提供一系列实际上无限的 URI 供依赖方跟踪。唯一真正的解决办法是依赖方对其愿意完成的工作量施加某种限制。还要注意的是，这种情况下的攻击者必须是 RPKI 证书颁发机构；否则，正常的 RPKI 对象安全检查将拒绝恶意 URI。
Processing costs for objects retrieved using RRDP may be somewhat different from the same objects retrieved using rsync: because RRDP treats an entire set of changes as a unit (one "delta"), it may not be practical to start processing any of the objects in the delta until the entire delta has been received. With rsync, by contrast, incremental processing may be easy, but the overall cost of transfer may be higher, as may be the number of corner cases in which the Relying Party retrieves some but not all of the updated objects. Overall, RRDP's behavior is closer to a proper transactional system, which (probably) leads to an overall reliability increase.
使用 RRDP 检索对象的处理成本可能与使用 rsync 检索相同对象的处理成本有些不同：由于 RRDP 将整个变更集视为一个单元（一个 "三角洲"），因此在收到整个三角洲之前开始处理三角洲中的任何对象可能都不切实际。相比之下，使用 rsync 时，增量处理可能很容易，但传输的总成本可能会更高，依赖方检索到部分更新对象而非全部更新对象的情况也会更多。总的来说，RRDP 的行为更接近于适当的事务处理系统，从而（可能）提高了整体可靠性。
RRDP is designed to scale much better than rsync. In particular, RRDP is designed to allow use of an HTTPS caching infrastructure to reduce load on primary Repository Servers and increase resilience against denial-of-service attacks on the RPKI publication service.
RRDP 在设计上比 rsync 有更好的扩展性。特别是，RRDP 的设计允许使用 HTTPS 缓存基础设施，以减少主要版本库服务器的负载，并提高 RPKI 发布服务抵御拒绝服务攻击的能力。
IANA has updated the reference for id-ad-rpkiNotify to point to this document in the "SMI Security for PKIX Access Descriptor" registry [IANA-AD-NUMBERS].
IANA 已更新 id-ad-rpkiNotify 的引用，使其指向 "SMI Security for PKIX Access Descriptor "注册表 [IANA-AD-NUMBERS] 中的本文档。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <http://www.rfc-editor.org/info/rfc4122>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <http://www.rfc-editor.org/info/rfc4122>.
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, <http://www.rfc-editor.org/info/rfc5781>.
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, <http://www.rfc-editor.org/info/rfc5781>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <http://www.rfc-editor.org/info/rfc6125>。
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, <http://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, <http://www.rfc-editor.org/info/rfc6481>。
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, <http://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, <http://www.rfc-editor.org/info/rfc6487>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230] Fielding, R., Ed. 和 J. Reschke, Ed., "超文本传输协议（HTTP/1.1）：消息语法和路由"，RFC 7230，DOI 10.17487/RFC7230，2014 年 6 月，<http://www.rfc-editor.org/info/rfc7230>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231] Fielding, R., Ed. 和 J. Reschke, Ed., "超文本传输协议（HTTP/1.1）：语义和内容"，RFC 7231，DOI 10.17487/RFC7231，2014 年 6 月，<http://www.rfc-editor.org/info/rfc7231>。
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014, <http://www.rfc-editor.org/info/rfc7232>.
[RFC7232] Fielding, R., Ed. 和 J. Reschke, Ed., "超文本传输协议（HTTP/1.1）：条件请求"，RFC 7232，DOI 10.17487/RFC7232，2014 年 6 月，<http://www.rfc-editor.org/info/rfc7232>。
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <http://www.rfc-editor.org/info/rfc7234>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1)：缓存"，RFC 7234，DOI 10.17487/RFC7234，2014 年 6 月，<http://www.rfc-editor.org/info/rfc7234>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>。
[RFC8181] Weiler, S., Sonalker, A., and R. Austein, "A Publication Protocol for the Resource Public Key Infrastructure (RPKI)", DOI 10.17487/RFC8181, July 2017, <http://www.rfc-editor.org/info/rfc8181>.
[RFC8181] Weiler, S., Sonalker, A., and R. Austein, "A Publication Protocol for the Resource Public Key Infrastructure (RPKI)", DOI 10.17487/RFC8181, July 2017, <http://www.rfc-editor.org/info/rfc8181>。
[SHS] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, <http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.180-4.pdf>.
[SHS] 美国国家标准与技术研究院，"安全散列标准（SHS）"，FIPS PUB 180-4，DOI 10.6028/NIST.FIPS.180-4，2015 年 8 月，<http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.180-4.pdf>。
[IANA-AD-NUMBERS] IANA, "Structure of Management Information (SMI) Numbers (MIB Module Registrations)", <http://www.iana.org/assignments/smi-numbers>.
[IANA-AD-NUMBERS] IANA，"管理信息（SMI）编号结构（MIB 模块注册）"，<http://www.iana.org/assignments/smi-numbers>。
[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, <http://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, <http://www.rfc-editor.org/info/rfc6486>。
[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, <http://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, <http://www.rfc-editor.org/info/rfc6488>。
[RSYNC] "rsync", <https://rsync.samba.org>.
[RSYNC] "rsync"，<https://rsync.samba.org>。
Acknowledgements
致谢
The authors would like to thank David Mandelberg for reviewing this document.
作者感谢 David Mandelberg 对本文件的审阅。
Authors' Addresses
作者地址
Tim Bruijnzeels RIPE NCC
Tim Bruijnzeels RIPE NCC
Email: [email protected]
Oleg Muravskiy RIPE NCC
奥列格-穆拉夫斯基 RIPE NCC
Email: [email protected]
Bryan Weber Cobenian
布莱恩-韦伯-科比尼安
Email: [email protected]
Rob Austein Dragon Research Labs
Rob Austein 龙研究实验室
Email: [email protected]