Internet Engineering Task Force (IETF) R. Bush
Request for Comments: 6810 Internet Initiative Japan
Category: Standards Track R. Austein
ISSN: 2070-1721 Dragon Research Labs
January 2013
The Resource Public Key Infrastructure (RPKI) to Router Protocol
资源公钥基础设施（RPKI）到路由器协议
Abstract
摘要
In order to verifiably validate the origin Autonomous Systems of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers.
为了可验证 BGP 公告的起源自治系统，路由器需要一种简单但可靠的机制，以便从可信缓存接收资源公钥基础设施（RFC 6480）前缀起源数据。本文档介绍了一种向路由器传输经过验证的前缀来源数据的协议。
Status of This Memo
本备忘录的地位
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组 (IETF) 的成果。它代表了 IETF 社区的共识。它已接受公众审查，并经互联网工程指导小组 (IESG) 批准发布。有关互联网标准的更多信息，请参见 RFC 5741 第 2 节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6810.
有关本文件的当前状态、任何勘误以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc6810。
Copyright Notice
版权声明
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有 (c) 2013 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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Deployment Structure . . . . . . . . . . . . . . . . . . . . . 4
4. Operational Overview . . . . . . . . . . . . . . . . . . . . . 4
5. Protocol Data Units (PDUs) . . . . . . . . . . . . . . . . . . 6
5.1. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 6
5.2. Serial Notify . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Serial Query . . . . . . . . . . . . . . . . . . . . . . . 8
5.4. Reset Query . . . . . . . . . . . . . . . . . . . . . . . 9
5.5. Cache Response . . . . . . . . . . . . . . . . . . . . . . 9
5.6. IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . . 10
5.7. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 11
5.8. End of Data . . . . . . . . . . . . . . . . . . . . . . . 12
5.9. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 12
5.10. Error Report . . . . . . . . . . . . . . . . . . . . . . . 12
6. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Start or Restart . . . . . . . . . . . . . . . . . . . . . 14
6.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . . 15
6.3. No Incremental Update Available . . . . . . . . . . . . . 15
6.4. Cache Has No Data Available . . . . . . . . . . . . . . . 16
7. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. SSH Transport . . . . . . . . . . . . . . . . . . . . . . 18
7.2. TLS Transport . . . . . . . . . . . . . . . . . . . . . . 18
7.3. TCP MD5 Transport . . . . . . . . . . . . . . . . . . . . 19
7.4. TCP-AO Transport . . . . . . . . . . . . . . . . . . . . . 19
8. Router-Cache Setup . . . . . . . . . . . . . . . . . . . . . . 20
9. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 21
10. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 22
11. Security Considerations . . . . . . . . . . . . . . . . . . . 23
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
14.1. Normative References . . . . . . . . . . . . . . . . . . . 25
14.2. Informative References . . . . . . . . . . . . . . . . . . 26
In order to verifiably validate the origin Autonomous Systems (ASes) of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RPKI) [RFC6480] cryptographically validated prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. The design is intentionally constrained to be usable on much of the current generation of ISP router platforms.
为了可验证 BGP 公告的起源自治系统 (ASes)，路由器需要一种简单而可靠的机制，以便从可信缓存接收资源公钥基础设施 (RPKI) [RFC6480] 加密验证的前缀起源数据。本文档介绍了一种向路由器传输经过验证的前缀来源数据的协议。该设计有意受限，以便能在当前大多数 ISP 路由器平台上使用。
Section 3 describes the deployment structure, and Section 4 then presents an operational overview. The binary payloads of the protocol are formally described in Section 5, and the expected PDU sequences are described in Section 6. The transport protocol options are described in Section 7. Section 8 details how routers and caches are configured to connect and authenticate. Section 9 describes likely deployment scenarios. The traditional security and IANA considerations end the document.
第 3 节描述了部署结构，第 4 节介绍了运行概况。第 5 节正式介绍了协议的二进制有效载荷，第 6 节介绍了预期的 PDU 序列。第 7 节介绍了传输协议选项。第 8 节详细介绍如何配置路由器和缓存以进行连接和验证。第 9 节介绍了可能的部署方案。本文档的最后是传统的安全性和 IANA 注意事项。
The protocol is extensible in order to support new PDUs with new semantics, if deployment experience indicates they are needed. PDUs are versioned should deployment experience call for change.
该协议具有可扩展性，以便在部署经验表明需要时支持具有新语义的新 PDU。如果根据部署经验需要进行更改，PDU 将进行版本控制。
For an implementation (not interoperability) report, see [RTR-IMPL]
有关实施（非互操作性）报告，请参见 [RTR-IMPL] 。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] only when they appear in all upper case. They may also appear in lower or mixed case as English words, without special meaning.
本文档中的关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY "和 "OPTIONAL"，只有在全部大写时，才能按照 RFC 2119 [RFC2119] 中的说明进行解释。它们也可以作为英文单词以小写或混合大小写出现，但无特殊含义。
The following terms are used with special meaning.
以下术语具有特殊含义。
Global RPKI: The authoritative data of the RPKI are published in a distributed set of servers at the IANA, Regional Internet Registries (RIRs), National Internet Registry (NIRs), and ISPs; see [RFC6481].
全球 RPKI：RPKI 的权威数据发布在 IANA、地区互联网注册管理机构 (RIR)、国家互联网注册管理机构 (NIR) 和互联网服务提供商的一组分布式服务器中；参见 [RFC6481]。
Cache: A coalesced copy of the RPKI, which is periodically fetched/ refreshed directly or indirectly from the Global RPKI using the [RFC5781] protocol/tools. Relying party software is used to gather and validate the distributed data of the RPKI into a cache. Trusting this cache further is a matter between the provider of the cache and a relying party.
缓存：RPKI 的聚合副本，使用 [RFC5781] 协议/工具定期直接或间接从全局 RPKI 获取/刷新。依赖方软件用于将 RPKI 的分布式数据收集并验证到缓存中。缓存提供者和依赖方之间需要进一步信任缓存。
Serial Number: A 32-bit strictly increasing unsigned integer that wraps from 2^32-1 to 0. It denotes the logical version of a cache. A cache increments the value when it successfully updates its data from a parent cache or from primary RPKI data. As a cache is receiving, new incoming data and implicit deletes are associated with the new serial but MUST NOT be sent until the fetch is complete. A Serial Number is not commensurate between caches, nor need it be maintained across resets of the cache server. See [RFC1982] on DNS Serial Number Arithmetic for too much detail on the topic.
序列号：一个从 2^32-1 到 0 的 32 位严格递增无符号整数，表示高速缓存的逻辑版本。当高速缓存从父高速缓存或主 RPKI 数据中成功更新数据时，该值就会递增。缓存在接收数据时，新接收的数据和隐式删除的数据都会与新的序列号相关联，但在获取完成之前不得发送。不同缓存之间的序列号不一致，缓存服务器重置时也不需要保留序列号。有关该主题的详细信息，请参阅有关 DNS 序列号运算的 [RFC1982]。
Session ID: When a cache server is started, it generates a session identifier to uniquely identify the instance of the cache and to bind it to the sequence of Serial Numbers that cache instance will generate. This allows the router to restart a failed session knowing that the Serial Number it is using is commensurate with that of the cache.
会话标识符：当缓存服务器启动时，它会生成一个会话标识符来唯一标识缓存实例，并将其绑定到缓存实例将生成的序列号序列上。这样，路由器就能知道它所使用的序列号与高速缓存的序列号一致，从而重新启动失败的会话。
Deployment of the RPKI to reach routers has a three-level structure as follows:
将 RPKI 部署到路由器有如下三级结构：
Global RPKI: The authoritative data of the RPKI are published in a distributed set of servers, RPKI publication repositories, e.g., the IANA, RIRs, NIRs, and ISPs, see [RFC6481].
全球 RPKI：RPKI 的权威数据在一组分布式服务器、RPKI 发布库（如 IANA、RIR、NIR 和 ISP）中发布，参见 [RFC6481]。
Local Caches: A local set of one or more collected and verified caches. A relying party, e.g., router or other client, MUST have a trust relationship with, and a trusted transport channel to, any authoritative cache(s) it uses.
本地缓存：由一个或多个已收集并验证的缓存组成的本地缓存集。可信赖方（如路由器或其他客户端）必须与它所使用的任何权威缓存建立信任关系和可信传输通道。
Routers: A router fetches data from a local cache using the protocol described in this document. It is said to be a client of the cache. There MAY be mechanisms for the router to assure itself of the authenticity of the cache and to authenticate itself to the cache.
路由器：路由器使用本文档中描述的协议从本地缓存中获取数据。路由器是缓存的客户端。路由器可以通过一些机制来确保缓存的真实性，并对缓存进行身份验证。
A router establishes and keeps open a connection to one or more caches with which it has client/server relationships. It is configured with a semi-ordered list of caches, and establishes a connection to the most preferred cache, or set of caches, which accept the connections.
路由器与一个或多个高速缓存建立并保持开放连接，这些高速缓存与路由器有客户/服务器关系。路由器通过半排序的高速缓存列表进行配置，并与接受连接的最优先高速缓存或高速缓存集建立连接。
The router MUST choose the most preferred, by configuration, cache or set of caches so that the operator may control load on their caches and the Global RPKI.
路由器必须根据配置选择最优先的缓存或缓存集，以便操作员控制其缓存和全球 RPKI 的负载。
Periodically, the router sends to the cache the Serial Number of the highest numbered data it has received from that cache, i.e., the router's current Serial Number. When a router establishes a new connection to a cache, or wishes to reset a current relationship, it sends a Reset Query.
路由器会定期向高速缓存发送它从该高速缓存接收到的最高编号数据的序列号，即路由器的当前序列号。当路由器与高速缓存建立新连接或希望重置当前关系时，它会发送重置查询。
The Cache responds with all data records that have Serial Numbers greater than that in the router's query. This may be the null set, in which case the End of Data PDU is still sent. Note that 'greater' must take wrap-around into account, see [RFC1982].
高速缓存会回复所有序列号大于路由器查询中序列号的数据记录。这可能是空集，在这种情况下，仍会发送 "数据结束 PDU"。请注意，"大于 "必须考虑到缠绕，参见 [RFC1982]。
When the router has received all data records from the cache, it sets its current Serial Number to that of the Serial Number in the End of Data PDU.
路由器收到缓存中的所有数据记录后，会将其当前序列号设置为数据结束 PDU 中的序列号。
When the cache updates its database, it sends a Notify message to every currently connected router. This is a hint that now would be a good time for the router to poll for an update, but is only a hint. The protocol requires the router to poll for updates periodically in any case.
缓存更新数据库时，会向当前连接的每个路由器发送一条 "通知 "信息。这是一个提示，表明现在是路由器轮询更新的好时机，但这只是一个提示。协议要求路由器在任何情况下都要定期轮询更新。
Strictly speaking, a router could track a cache simply by asking for a complete data set every time it updates, but this would be very inefficient. The Serial Number based incremental update mechanism allows an efficient transfer of just the data records that have changed since last update. As with any update protocol based on incremental transfers, the router must be prepared to fall back to a full transfer if for any reason the cache is unable to provide the necessary incremental data. Unlike some incremental transfer protocols, this protocol requires the router to make an explicit request to start the fallback process; this is deliberate, as the cache has no way of knowing whether the router has also established sessions with other caches that may be able to provide better service.
严格来说，路由器可以在每次更新时通过请求完整的数据集来跟踪高速缓存，但这样做效率很低。基于序列号的增量更新机制只允许高效传输上次更新后发生变化的数据记录。与任何基于增量传输的更新协议一样，路由器必须做好准备，在高速缓存因任何原因无法提供必要的增量数据时退回到完整传输。与某些增量传输协议不同的是，该协议要求路由器明确请求启动回退过程；这是有意为之，因为高速缓存无法知道路由器是否还与其他能提供更好服务的高速缓存建立了会话。
As a cache server must evaluate certificates and ROAs (Route Origin Attestations; see [RFC6480]), which are time dependent, servers' clocks MUST be correct to a tolerance of approximately an hour.
由于缓存服务器必须评估与时间相关的证书和 ROAs（路由起源证明，见 [RFC6480]），因此服务器的时钟必须精确到大约一小时。
The exchanges between the cache and the router are sequences of exchanges of the following PDUs according to the rules described in Section 6.
高速缓存和路由器之间的交换是根据第 6 节所述规则交换以下 PDU 的序列。
Fields with unspecified content MUST be zero on transmission and MAY be ignored on receipt.
内容未指定的字段在传输时必须为零，在接收时可能会被忽略。
PDUs contain the following data elements:
PDU 包含以下数据元素：
Protocol Version: An eight-bit unsigned integer, currently 0, denoting the version of this protocol.
协议版本：八位无符号整数，目前为 0，表示该协议的版本。
PDU Type: An eight-bit unsigned integer, denoting the type of the PDU, e.g., IPv4 Prefix, etc.
PDU 类型：八位无符号整数，表示 PDU 的类型，如 IPv4 前缀等。
Serial Number: The Serial Number of the RPKI Cache when this set of PDUs was received from an upstream cache server or gathered from the Global RPKI. A cache increments its Serial Number when completing a rigorously validated update from a parent cache or the Global RPKI.
序列号：RPKI 缓存从上游缓存服务器接收到这组 PDU 或从全球 RPKI 收集到这组 PDU 时的序列号。高速缓存从上级高速缓存或全局 RPKI 完成严格验证的更新时，会递增其序列号。
Session ID: When a cache server is started, it generates a Session ID to identify the instance of the cache and to bind it to the sequence of Serial Numbers that cache instance will generate. This allows the router to restart a failed session knowing that the Serial Number it is using is commensurate with that of the cache. If, at any time, either the router or the cache finds the value of the session identifier is not the same as the other's, they MUST completely drop the session and the router MUST flush all data learned from that cache.
会话 ID：当缓存服务器启动时，它会生成一个会话 ID 来识别缓存实例，并将其与该缓存实例将生成的序列号序列绑定。这样，路由器就能知道它使用的序列号与高速缓存的序列号一致，从而重新启动失败的会话。如果在任何时候，路由器或高速缓存发现会话标识符的值与对方的不一致，它们必须完全放弃会话，路由器必须清除从该高速缓存学到的所有数据。
Should a cache erroneously reuse a Session ID so that a router does not realize that the session has changed (old session ID and new session ID have same numeric value), the router may become confused as to the content of the cache. The time it takes the router to discover it is confused will depend on whether the Serial Numbers are also reused. If the Serial Numbers in the old and new sessions are different enough, the cache will respond to the router's Serial Query with a Cache Reset, which will solve the problem. If, however, the Serial Numbers are close, the cache may respond with a Cache Response, which may not be enough to bring the router into sync. In such cases, it's likely but not certain that the router will detect some discrepancy between the state that the cache expects and its own state. For example, the Cache Response may tell the router to drop a record that the router does not hold, or may tell the router to add a record that the router already has. In such cases, a router will detect the error and reset the session. The one case in which the router may stay out of sync is when nothing in the Cache Response contradicts any data currently held by the router.
如果高速缓存错误地重复使用了会话 ID，导致路由器没有意识到会话已发生变化（旧的会话 ID 和新的会话 ID 具有相同的数值），路由器可能会对高速缓存的内容感到困惑。路由器发现自己混淆的时间取决于序列号是否也被重复使用。如果新旧会话中的序列号有足够大的差异，缓存就会响应路由器的序列查询，进行缓存重置，从而解决问题。但是，如果序列号很接近，缓存可能会响应缓存响应，但这可能不足以使路由器同步。在这种情况下，路由器很可能会检测到缓存所期望的状态与其自身状态之间存在某些差异，但这并不确定。例如，"缓存响应 "可能会告诉路由器放弃一条路由器没有的记录，或者告诉路由器添加一条路由器已经有的记录。在这种情况下，路由器会检测到错误并重置会话。路由器可能保持不同步的一种情况是，缓存响应中没有任何内容与路由器当前持有的任何数据相矛盾。
Using persistent storage for the session identifier or a clock-based scheme for generating session identifiers should avoid the risk of session identifier collisions.
使用会话标识符的持久存储或基于时钟的会话标识符生成方案，应能避免会话标识符碰撞的风险。
The Session ID might be a pseudo-random value, a strictly increasing value if the cache has reliable storage, etc.
会话 ID 可以是一个伪随机值，如果缓存有可靠的存储空间，也可以是一个严格递增的值，等等。
Length: A 32-bit unsigned integer that has as its value the count of the bytes in the entire PDU, including the eight bytes of header that end with the length field.
长度（Length）：一个 32 位无符号整数，其值为整个 PDU 中的字节数，包括以长度字段结尾的 8 个字节报头。
Flags: The lowest order bit of the Flags field is 1 for an announcement and 0 for a withdrawal, whether this PDU announces a new right to announce the prefix or withdraws a previously announced right. A withdraw effectively deletes one previously announced IPvX (IPv4 or IPv6) Prefix PDU with the exact same Prefix, Length, Max-Len, and Autonomous System Number (ASN).
标志：无论该 PDU 是宣布新的前缀宣布权还是撤回先前宣布的权利，Flags 字段的最低阶位为 1 表示宣布，为 0 表示撤回。撤回会有效删除先前宣布的具有完全相同的前缀、长度、最大长度和自治系统编号（ASN）的 IPvX（IPv4 或 IPv6）前缀 PDU。
Prefix Length: An 8-bit unsigned integer denoting the shortest prefix allowed for the prefix.
前缀长度：一个 8 位无符号整数，表示前缀允许的最短前缀。
Max Length: An 8-bit unsigned integer denoting the longest prefix allowed by the prefix. This MUST NOT be less than the Prefix Length element.
最大长度：一个 8 位无符号整数，表示前缀允许的最长前缀。该值不得小于前缀长度元素。
Prefix: The IPv4 or IPv6 prefix of the ROA.
前缀：ROA 的 IPv4 或 IPv6 前缀。
Autonomous System Number: ASN allowed to announce this prefix, a 32-bit unsigned integer.
自治系统编号：允许公告此前缀的 ASN，32 位无符号整数。
Zero: Fields shown as zero or reserved MUST be zero. The value of such a field MUST be ignored on receipt.
零：显示为零或保留的字段必须为零。接收时必须忽略此类字段的值。
The cache notifies the router that the cache has new data.
缓存会通知路由器缓存中有新数据。
The Session ID reassures the router that the Serial Numbers are commensurate, i.e., the cache session has not been changed.
会话 ID 可使路由器确信序列号是一致的，即缓存会话未被更改。
Serial Notify is the only message that the cache can send that is not in response to a message from the router.
串行通知是高速缓存可以发送的唯一信息，它不是对路由器信息的回应。
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 0 | 0 | |
+-------------------------------------------+
| |
| Length=12 |
| |
+-------------------------------------------+
| |
| Serial Number |
| |
`-------------------------------------------'
Serial Query: The router sends Serial Query to ask the cache for all payload PDUs that have Serial Numbers higher than the Serial Number in the Serial Query.
串行查询：路由器发送串行查询（Serial Query），向缓存询问所有序列号高于串行查询中的序列号的有效载荷 PDU。
The cache replies to this query with a Cache Response PDU (Section 5.5) if the cache has a, possibly null, record of the changes since the Serial Number specified by the router. If there have been no changes since the router last queried, the cache sends an End Of Data PDU.
如果高速缓存有自路由器指定的序列号（Serial Number）以来的更改记录（可能为空），则高速缓存通过高速缓存响应 PDU（第 5.5 节）回复该查询。如果自路由器上次查询以来没有任何变化，缓存将发送一个 "数据结束 "PDU（End Of Data PDU）。
If the cache does not have the data needed to update the router, perhaps because its records do not go back to the Serial Number in the Serial Query, then it responds with a Cache Reset PDU (Section 5.9).
如果缓存中没有更新路由器所需的数据，可能是因为其记录没有回到序列查询中的序列号，则缓存会响应缓存重置 PDU（第 5.9 节）。
The Session ID tells the cache what instance the router expects to ensure that the Serial Numbers are commensurate, i.e., the cache session has not been changed.
会话 ID 会告诉高速缓存路由器所期望的实例，以确保序列号一致，即高速缓存会话未被更改。
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 0 | 1 | |
+-------------------------------------------+
| |
| Length=12 |
| |
+-------------------------------------------+
| |
| Serial Number |
| |
`-------------------------------------------'
Reset Query: The router tells the cache that it wants to receive the total active, current, non-withdrawn database. The cache responds with a Cache Response PDU (Section 5.5).
重置查询：路由器告诉高速缓存，它想接收全部活动的、当前的、未撤消的数据库。高速缓存通过高速缓存响应 PDU（第 5.5 节）做出响应。
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | reserved = zero |
| 0 | 2 | |
+-------------------------------------------+
| |
| Length=8 |
| |
`-------------------------------------------'
Cache Response: The cache responds with zero or more payload PDUs. When replying to a Serial Query request (Section 5.3), the cache sends the set of all data records it has with Serial Numbers greater than that sent by the client router. When replying to a Reset Query, the cache sends the set of all data records it has; in this case, the withdraw/announce field in the payload PDUs MUST have the value 1 (announce).
高速缓存响应：高速缓存以零或多个有效载荷 PDU 进行响应。在回复 "序列查询"（Serial Query）请求（第 5.3 节）时，高速缓存会发送它所拥有的序列号大于客户端路由器发送的序列号的所有数据记录的集合。在回复重置查询（Reset Query）时，高速缓存会发送它拥有的所有数据记录的集合；在这种情况下，有效载荷 PDU 中的 withdraw/announce 字段的值必须为 1（announce）。
In response to a Reset Query, the new value of the Session ID tells the router the instance of the cache session for future confirmation. In response to a Serial Query, the Session ID being the same reassures the router that the Serial Numbers are commensurate, i.e., the cache session has not changed.
在响应重置查询时，会话 ID 的新值会告诉路由器缓存会话的实例，以便将来确认。在响应序列查询时，会话 ID 相同可使路由器确信序列号是一致的，即缓存会话没有改变。
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 0 | 3 | |
+-------------------------------------------+
| |
| Length=8 |
| |
`-------------------------------------------'
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | reserved = zero |
| 0 | 4 | |
+-------------------------------------------+
| |
| Length=20 |
| |
+-------------------------------------------+
| | Prefix | Max | |
| Flags | Length | Length | zero |
| | 0..32 | 0..32 | |
+-------------------------------------------+
| |
| IPv4 Prefix |
| |
+-------------------------------------------+
| |
| Autonomous System Number |
| |
`-------------------------------------------'
The lowest order bit of the Flags field is 1 for an announcement and 0 for a withdrawal.
Flags 字段的最低阶位为 1 表示宣布，为 0 表示撤回。
In the RPKI, nothing prevents a signing certificate from issuing two identical ROAs. In this case, there would be no semantic difference between the objects, merely a process redundancy.
在 RPKI 中，没有任何规定阻止签名证书签发两个相同的 ROA。在这种情况下，两个对象之间没有语义上的区别，只是程序上的冗余。
In the RPKI, there is also an actual need for what might appear to a router as identical IPvX PDUs. This can occur when an upstream certificate is being reissued or there is an address ownership transfer up the validation chain. The ROA would be identical in the router sense, i.e., have the same {Prefix, Len, Max-Len, ASN}, but a different validation path in the RPKI. This is important to the RPKI, but not to the router.
在 RPKI 中，路由器实际需要的可能是相同的 IPvX PDU。这种情况可能发生在上游证书重新签发或验证链上的地址所有权转移时。ROA 在路由器意义上是相同的，即具有相同的 {前缀、长度、最大长度、ASN}，但在 RPKI 中的验证路径不同。这对 RPKI 很重要，但对路由器并不重要。
The cache server MUST ensure that it has told the router client to have one and only one IPvX PDU for a unique {Prefix, Len, Max-Len, ASN} at any one point in time. Should the router client receive an IPvX PDU with a {Prefix, Len, Max-Len, ASN} identical to one it already has active, it SHOULD raise a Duplicate Announcement Received error.
缓存服务器必须确保它已告知路由器客户端，在任何一个时间点上都只有一个唯一的 {前缀、长度、最大长度、ASN}的 IPvX PDU。如果路由器客户端收到的 IPvX PDU 的 {Prefix, Len, Max-Len, ASN} 与它已激活的 PDU 相同，则应引发 "收到重复公告"（Duplicate Announcement Received）错误。
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | reserved = zero |
| 0 | 6 | |
+-------------------------------------------+
| |
| Length=32 |
| |
+-------------------------------------------+
| | Prefix | Max | |
| Flags | Length | Length | zero |
| | 0..128 | 0..128 | |
+-------------------------------------------+
| |
+--- ---+
| |
+--- IPv6 Prefix ---+
| |
+--- ---+
| |
+-------------------------------------------+
| |
| Autonomous System Number |
| |
`-------------------------------------------'
Analogous to the IPv4 Prefix PDU, it has 96 more bits and no magic.
与 IPv4 前缀 PDU 类似，它多了 96 个比特，没有魔法。
End of Data: The cache tells the router it has no more data for the request.
数据结束：缓存会告诉路由器它没有更多的数据来满足请求。
The Session ID MUST be the same as that of the corresponding Cache Response that began the, possibly null, sequence of data PDUs.
会话 ID 必须与开始数据 PDU（可能为空）序列的相应高速缓存响应的会话 ID 相同。
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 0 | 7 | |
+-------------------------------------------+
| |
| Length=12 |
| |
+-------------------------------------------+
| |
| Serial Number |
| |
`-------------------------------------------'
The cache may respond to a Serial Query informing the router that the cache cannot provide an incremental update starting from the Serial Number specified by the router. The router must decide whether to issue a Reset Query or switch to a different cache.
缓存可能会响应序列查询，通知路由器缓存无法从路由器指定的序列号开始提供增量更新。路由器必须决定是发出重置查询（Reset Query）还是切换到其他缓存。
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | reserved = zero |
| 0 | 8 | |
+-------------------------------------------+
| |
| Length=8 |
| |
`-------------------------------------------'
This PDU is used by either party to report an error to the other.
任何一方使用此 PDU 向另一方报告错误。
Error reports are only sent as responses to other PDUs.
错误报告只作为对其他 PDU 的响应发送。
The Error Code is described in Section 10.
第 10 节介绍了错误代码。
If the error is generic (e.g., "Internal Error") and not associated with the PDU to which it is responding, the Erroneous PDU field MUST be empty and the Length of Encapsulated PDU field MUST be zero.
如果错误是一般错误（如 "内部错误"），且与响应的 PDU 无关，则错误 PDU 字段必须为空，封装 PDU 字段的长度必须为零。
An Error Report PDU MUST NOT be sent for an Error Report PDU. If an erroneous Error Report PDU is received, the session SHOULD be dropped.
不得为错误报告 PDU 发送错误报告 PDU。如果收到错误的错误报告 PDU，则应放弃会话。
If the error is associated with a PDU of excessive length, i.e., too long to be any legal PDU other than another Error Report, or a possibly corrupt length, the Erroneous PDU field MAY be truncated.
如果错误与长度过长的 PDU 相关联，即除了另一个错误报告外，PDU 长度过长而无法成为任何合法的 PDU，或长度可能已损坏，则错误 PDU 字段可能被截断。
The diagnostic text is optional; if not present, the Length of Error Text field MUST be zero. If error text is present, it MUST be a string in UTF-8 encoding (see [RFC3269]).
诊断文本是可选项；如果不存在，错误文本字段的长度必须为零。如果存在错误文本，它必须是 UTF-8 编码的字符串（见 [RFC3269]）。
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Error Code |
| 0 | 10 | |
+-------------------------------------------+
| |
| Length |
| |
+-------------------------------------------+
| |
| Length of Encapsulated PDU |
| |
+-------------------------------------------+
| |
~ Copy of Erroneous PDU ~
| |
+-------------------------------------------+
| |
| Length of Error Text |
| |
+-------------------------------------------+
| |
| Arbitrary Text |
| of |
~ Error Diagnostic Message ~
| |
`-------------------------------------------'
The sequences of PDU transmissions fall into three conversations as follows:
PDU 传输序列分为以下三个会话：
Cache Router
~ ~
| <----- Reset Query -------- | R requests data (or Serial Query)
| |
| ----- Cache Response -----> | C confirms request
| ------- IPvX Prefix ------> | C sends zero or more
| ------- IPvX Prefix ------> | IPv4 and IPv6 Prefix
| ------- IPvX Prefix ------> | Payload PDUs
| ------ End of Data ------> | C sends End of Data
| | and sends new serial
~ ~
When a transport session is first established, the router MAY send a Reset Query and the cache responds with a data sequence of all data it contains.
首次建立传输会话时，路由器可能会发送重置查询，缓存会以包含所有数据的数据序列做出响应。
Alternatively, if the router has significant unexpired data from a broken session with the same cache, it MAY start with a Serial Query containing the Session ID from the previous session to ensure the Serial Numbers are commensurate.
或者，如果路由器有大量未过期的数据，而这些数据来自同一个高速缓存的中断会话，那么路由器可以从包含上一个会话 ID 的序列查询开始，以确保序列号相匹配。
This Reset Query sequence is also used when the router receives a Cache Reset, chooses a new cache, or fears that it has otherwise lost its way.
当路由器收到缓存重置、选择新缓存或担心迷失方向时，也会使用重置查询序列。
To limit the length of time a cache must keep the data necessary to generate incremental updates, a router MUST send either a Serial Query or a Reset Query no less frequently than once an hour. This also acts as a keep-alive at the application layer.
为了限制高速缓存保存生成增量更新所需数据的时间，路由器发送串行查询或重置查询的频率不得少于每小时一次。这也是应用层的保持更新功能。
As the cache MAY not keep updates for little more than one hour, the router MUST have a polling interval of no greater than once an hour.
由于缓存的更新时间可能不会超过一小时，因此路由器的轮询间隔必须不超过每小时一次。
Cache Router
~ ~
| -------- Notify ----------> | (optional)
| |
| <----- Serial Query ------- | R requests data
| |
| ----- Cache Response -----> | C confirms request
| ------- IPvX Prefix ------> | C sends zero or more
| ------- IPvX Prefix ------> | IPv4 and IPv6 Prefix
| ------- IPvX Prefix ------> | Payload PDUs
| ------ End of Data ------> | C sends End of Data
| | and sends new serial
~ ~
The cache server SHOULD send a notify PDU with its current Serial Number when the cache's serial changes, with the expectation that the router MAY then issue a Serial Query earlier than it otherwise might. This is analogous to DNS NOTIFY in [RFC1996]. The cache MUST rate limit Serial Notifies to no more frequently than one per minute.
当高速缓存的序列号发生变化时，高速缓存服务器应发送一个包含其当前序列号的通知 PDU，路由器可能会因此而提前发出序列查询。这类似于 [RFC1996] 中的 DNS NOTIFY。缓存必须限制串行通知的频率，不得超过每分钟一次。
When the transport layer is up and either a timer has gone off in the router, or the cache has sent a Notify, the router queries for new data by sending a Serial Query, and the cache sends all data newer than the serial in the Serial Query.
当传输层启动、路由器中的定时器熄灭或高速缓存发出通知时，路由器会通过发送串行查询来查询新数据，而高速缓存则会发送所有比串行查询中的串行数据更新的数据。
To limit the length of time a cache must keep old withdraws, a router MUST send either a Serial Query or a Reset Query no less frequently than once an hour.
为了限制高速缓存必须保留旧撤回信息的时间，路由器必须每小时发送不少于一次的串行查询或重置查询。
Cache Router
~ ~
| <----- Serial Query ------ | R requests data
| ------- Cache Reset ------> | C cannot supply update
| | from specified serial
| <------ Reset Query ------- | R requests new data
| ----- Cache Response -----> | C confirms request
| ------- IPvX Prefix ------> | C sends zero or more
| ------- IPvX Prefix ------> | IPv4 and IPv6 Prefix
| ------- IPvX Prefix ------> | Payload PDUs
| ------ End of Data ------> | C sends End of Data
| | and sends new serial
~ ~
The cache may respond to a Serial Query with a Cache Reset, informing the router that the cache cannot supply an incremental update from the Serial Number specified by the router. This might be because the cache has lost state, or because the router has waited too long between polls and the cache has cleaned up old data that it no longer believes it needs, or because the cache has run out of storage space and had to expire some old data early. Regardless of how this state arose, the cache replies with a Cache Reset to tell the router that it cannot honor the request. When a router receives this, the router SHOULD attempt to connect to any more preferred caches in its cache list. If there are no more preferred caches, it MUST issue a Reset Query and get an entire new load from the cache.
缓存可能会以 "缓存重置"（Cache Reset）来响应序列查询，通知路由器缓存无法从路由器指定的序列号开始提供增量更新。这可能是因为高速缓存丢失了状态，或者是因为路由器在两次轮询之间等待的时间太长，高速缓存清理了它认为不再需要的旧数据，或者是因为高速缓存用完了存储空间，不得不让一些旧数据提前过期。无论这种状态是如何产生的，高速缓存都会回复一个 "高速缓存重置"（Cache Reset），告诉路由器它无法满足请求。当路由器收到该请求时，路由器应尝试连接其缓存列表中的其他首选缓存。如果没有更多首选高速缓存，路由器必须发出重置查询（Reset Query），并从高速缓存中获取新的负载。
Cache Router
~ ~
| <----- Serial Query ------ | R requests data
| ---- Error Report PDU ----> | C No Data Available
~ ~
Cache Router
~ ~
| <----- Reset Query ------- | R requests data
| ---- Error Report PDU ----> | C No Data Available
~ ~
The cache may respond to either a Serial Query or a Reset Query informing the router that the cache cannot supply any update at all. The most likely cause is that the cache has lost state, perhaps due to a restart, and has not yet recovered. While it is possible that a cache might go into such a state without dropping any of its active sessions, a router is more likely to see this behavior when it initially connects and issues a Reset Query while the cache is still rebuilding its database.
高速缓存可能会响应串行查询或重置查询，告知路由器高速缓存根本无法提供任何更新。最可能的原因是高速缓存丢失了状态，可能是由于重新启动，而且尚未恢复。虽然高速缓存有可能在不丢弃任何活动会话的情况下进入这种状态，但路由器更有可能在高速缓存仍在重建数据库时，通过初始连接和发出重置查询看到这种行为。
When a router receives this kind of error, the router SHOULD attempt to connect to any other caches in its cache list, in preference order. If no other caches are available, the router MUST issue periodic Reset Queries until it gets a new usable load from the cache.
当路由器收到此类错误时，路由器应按优先顺序尝试连接其缓存列表中的任何其他缓存。如果没有其他缓存可用，路由器必须定期发出重置查询，直到从缓存中获得新的可用负载。
The transport-layer session between a router and a cache carries the binary PDUs in a persistent session.
路由器和高速缓存之间的传输层会话以持久会话的方式传输二进制 PDU。
To prevent cache spoofing and DoS attacks by illegitimate routers, it is highly desirable that the router and the cache be authenticated to each other. Integrity protection for payloads is also desirable to protect against monkey-in-the-middle (MITM) attacks. Unfortunately, there is no protocol to do so on all currently used platforms. Therefore, as of the writing of this document, there is no mandatory-to-implement transport that provides authentication and integrity protection.
为防止非法路由器的高速缓存欺骗和 DoS 攻击，路由器和高速缓存最好能相互验证。为防止中间人（MITM）攻击，还需要对有效载荷进行完整性保护。遗憾的是，目前使用的所有平台都没有这样的协议。因此，在撰写本文档时，还没有一种强制实施的传输方式可以提供身份验证和完整性保护。
To reduce exposure to dropped but non-terminated sessions, both caches and routers SHOULD enable keep-alives when available in the chosen transport protocol.
为减少丢失但未终止会话的风险，缓存和路由器都应在所选传输协议可用时启用保持续传功能。
It is expected that, when the TCP Authentication Option (TCP-AO) [RFC5925] is available on all platforms deployed by operators, it will become the mandatory-to-implement transport.
当运营商部署的所有平台都能使用 TCP 验证选项（TCP-AO）[RFC5925]时，预计它将成为强制实施的传输方式。
Caches and routers MUST implement unprotected transport over TCP using a port, rpki-rtr (323); see Section 12. Operators SHOULD use procedural means, e.g., access control lists (ACLs), to reduce the exposure to authentication issues.
缓存和路由器必须使用端口 rpkii-rtr (323) 通过 TCP 实现无保护传输；请参见第 12 节。操作员应使用程序手段（如访问控制列表 (ACL)）来减少身份验证问题的风险。
Caches and routers SHOULD use TCP-AO, SSHv2, TCP MD5, or IPsec transport.
缓存和路由器应使用 TCP-AO、SSHv2、TCP MD5 或 IPsec 传输。
If unprotected TCP is the transport, the cache and routers MUST be on the same trusted and controlled network.
如果使用不受保护的 TCP 传输，高速缓存和路由器必须位于同一个受信任和受控制的网络上。
If available to the operator, caches and routers MUST use one of the following more protected protocols.
如果操作员可以使用，高速缓存和路由器必须使用以下一种更受保护的协议。
Caches and routers SHOULD use TCP-AO transport [RFC5925] over the rpki-rtr port.
缓存和路由器应通过 rpkii-rtr 端口使用 TCP-AO 传输 [RFC5925]。
Caches and routers MAY use SSHv2 transport [RFC4252] using a the normal SSH port. For an example, see Section 7.1.
缓存和路由器可以使用 SSHv2 传输 [RFC4252]，使用正常的 SSH 端口。示例请参见第 7.1 节。
Caches and routers MAY use TCP MD5 transport [RFC2385] using the rpki-rtr port. Note that TCP MD5 has been obsoleted by TCP-AO [RFC5925].
缓存和路由器可以使用 rpkii-rtr 端口进行 TCP MD5 传输 [RFC2385]。请注意，TCP MD5 已被 TCP-AO [RFC5925] 所取代。
Caches and routers MAY use IPsec transport [RFC4301] using the rpki-rtr port.
缓存和路由器可以使用 rpki-rtr 端口进行 IPsec 传输 [RFC4301]。
Caches and routers MAY use TLS transport [RFC5246] using a port, rpki-rtr-tls (324); see Section 12.
缓存和路由器可以使用端口 rpkii-rtr-tls (324) 进行 TLS 传输 [RFC5246]；请参阅第 12 节。
To run over SSH, the client router first establishes an SSH transport connection using the SSHv2 transport protocol, and the client and server exchange keys for message integrity and encryption. The client then invokes the "ssh-userauth" service to authenticate the application, as described in the SSH authentication protocol [RFC4252]. Once the application has been successfully authenticated, the client invokes the "ssh-connection" service, also known as the SSH connection protocol.
要通过 SSH 运行，客户端路由器首先要使用 SSHv2 传输协议建立 SSH 传输连接，然后客户端和服务器交换密钥，以确保信息的完整性和加密。然后，客户端调用 "ssh-userauth "服务对应用程序进行身份验证，如 SSH 身份验证协议 [RFC4252] 所述。一旦应用程序认证成功，客户端就会调用 "ssh-connection "服务（也称为 SSH 连接协议）。
After the ssh-connection service is established, the client opens a channel of type "session", which results in an SSH session.
ssh 连接服务建立后，客户端会打开一个 "会话 "类型的通道，从而形成 SSH 会话。
Once the SSH session has been established, the application invokes the application transport as an SSH subsystem called "rpki-rtr". Subsystem support is a feature of SSH version 2 (SSHv2) and is not included in SSHv1. Running this protocol as an SSH subsystem avoids the need for the application to recognize shell prompts or skip over extraneous information, such as a system message that is sent at shell start-up.
SSH 会话一旦建立，应用程序就会以名为 "rpki-rtr "的 SSH 子系统的形式调用应用程序传输。子系统支持是 SSH 第 2 版（SSHv2）的一项功能，不包括在 SSHv1 中。 作为 SSH 子系统运行此协议，应用程序就无需识别 shell 提示或跳过无关信息，如 shell 启动时发送的系统信息。
It is assumed that the router and cache have exchanged keys out of band by some reasonably secured means.
假设路由器和高速缓存已通过某种合理安全的方式在带外交换了密钥。
Cache servers supporting SSH transport MUST accept RSA and Digital Signature Algorithm (DSA) authentication and SHOULD accept Elliptic Curve Digital Signature Algorithm (ECDSA) authentication. User authentication MUST be supported; host authentication MAY be supported. Implementations MAY support password authentication. Client routers SHOULD verify the public key of the cache to avoid monkey-in-the-middle attacks.
支持 SSH 传输的缓存服务器必须接受 RSA 和数字签名算法 (DSA) 身份验证，并应接受椭圆曲线数字签名算法 (ECDSA) 身份验证。必须支持用户身份验证；可以支持主机身份验证。实施可能支持密码验证。客户端路由器应验证缓存的公钥，以避免中间人攻击。
Client routers using TLS transport MUST present client-side certificates to authenticate themselves to the cache in order to allow the cache to manage the load by rejecting connections from unauthorized routers. In principle, any type of certificate and certificate authority (CA) may be used; however, in general, cache operators will wish to create their own small-scale CA and issue certificates to each authorized router. This simplifies credential rollover; any unrevoked, unexpired certificate from the proper CA may be used.
使用 TLS 传输的客户端路由器必须出示客户端证书，以便向高速缓存进行身份验证，从而使高速缓存能够通过拒绝来自未授权路由器的连接来管理负载。原则上，可以使用任何类型的证书和证书颁发机构（CA）；但一般情况下，高速缓存运营商希望创建自己的小规模 CA，并向每个授权路由器颁发证书。这样可以简化证书的延期；可以使用适当 CA 颁发的任何未撤销、未过期的证书。
Certificates used to authenticate client routers in this protocol MUST include a subjectAltName extension [RFC5280] containing one or more iPAddress identities; when authenticating the router's certificate, the cache MUST check the IP address of the TLS connection against these iPAddress identities and SHOULD reject the connection if none of the iPAddress identities match the connection.
本协议中用于验证客户端路由器的证书必须包括一个包含一个或多个 iPAddress 标识的 subjectAltName 扩展名 [RFC5280]；验证路由器证书时，缓存必须根据这些 iPAddress 标识检查 TLS 连接的 IP 地址，如果没有一个 iPAddress 标识与连接匹配，则应拒绝该连接。
Routers MUST also verify the cache's TLS server certificate, using subjectAltName dNSName identities as described in [RFC6125], to avoid monkey-in-the-middle attacks. The rules and guidelines defined in [RFC6125] apply here, with the following considerations:
路由器还必须使用 [RFC6125] 中描述的 subjectAltName dNSName 身份验证缓存的 TLS 服务器证书，以避免中间人攻击。此处适用 [RFC6125] 中定义的规则和指南，但需注意以下几点：
Support for DNS-ID identifier type (that is, the dNSName identity in the subjectAltName extension) is REQUIRED in rpki-rtr server and client implementations that use TLS. Certification authorities that issue rpki-rtr server certificates MUST support the DNS-ID identifier type, and the DNS-ID identifier type MUST be present in rpki-rtr server certificates.
使用 TLS 的 rpkii-rtr 服务器和客户端实现必须支持 DNS-ID 标识类型（即 subjectAltName 扩展中的 dNSName 标识）。签发 rpkii-rtr 服务器证书的认证机构必须支持 DNS-ID 标识符类型，并且 rpkii-rtr 服务器证书中必须包含 DNS-ID 标识符类型。
DNS names in rpki-rtr server certificates SHOULD NOT contain the wildcard character "*".
rpkii-rtr 服务器证书中的 DNS 名称不应包含通配符 "*"。
rpki-rtr implementations that use TLS MUST NOT use CN-ID identifiers; a CN field may be present in the server certificate's subject name, but MUST NOT be used for authentication within the rules described in [RFC6125].
使用 TLS 的 rpkii-rtr 实现不得使用 CN-ID 标识符；CN 字段可以出现在服务器证书的主题名称中，但不得用于 [RFC6125] 所述规则中的身份验证。
The client router MUST set its "reference identifier" to the DNS name of the rpki-rtr cache.
客户路由器必须将其 "参考标识符 "设置为 rpkii-rtr 缓存的 DNS 名称。
If TCP MD5 is used, implementations MUST support key lengths of at least 80 printable ASCII bytes, per Section 4.5 of [RFC2385]. Implementations MUST also support hexadecimal sequences of at least 32 characters, i.e., 128 bits.
如果使用 TCP MD5，根据 [RFC2385] 第 4.5 节，实施必须支持至少 80 个可打印 ASCII 字节的密钥长度。实施还必须支持至少 32 个字符的十六进制序列，即 128 位。
Key rollover with TCP MD5 is problematic. Cache servers SHOULD support [RFC4808].
TCP MD5 的密钥翻转存在问题。缓存服务器应支持 [RFC4808]。
Implementations MUST support key lengths of at least 80 printable ASCII bytes. Implementations MUST also support hexadecimal sequences of at least 32 characters, i.e., 128 bits. MAC (Message Authentication Code) lengths of at least 96 bits MUST be supported, per Section 5.1 of [RFC5925].
实施必须支持至少 80 个可打印 ASCII 字节的密钥长度。实施还必须支持至少 32 个字符的十六进制序列，即 128 位。根据 [RFC5925] 第 5.1 节，必须支持至少 96 位的 MAC（信息验证码）长度。
The cryptographic algorithms and associated parameters described in [RFC5926] MUST be supported.
必须支持 [RFC5926] 中描述的加密算法和相关参数。
A cache has the public authentication data for each router it is configured to support.
高速缓存为其配置支持的每个路由器提供公共身份验证数据。
A router may be configured to peer with a selection of caches, and a cache may be configured to support a selection of routers. Each must have the name of, and authentication data for, each peer. In addition, in a router, this list has a non-unique preference value for each server. This preference merely denotes proximity, not trust, preferred belief, etc. The client router attempts to establish a session with each potential serving cache in preference order, and then starts to load data from the most preferred cache to which it can connect and authenticate. The router's list of caches has the following elements:
路由器可配置为与选定的高速缓存对等，高速缓存可配置为支持选定的路由器。每个路由器都必须有每个对等程序的名称和验证数据。此外，在路由器中，该列表对每个服务器都有一个非唯一的偏好值。这种偏好仅表示接近程度，而不是信任度、首选信念等。客户端路由器会尝试按优先级顺序与每个潜在的服务缓存建立会话，然后开始从它可以连接和验证的最优先缓存加载数据。路由器的高速缓存列表包含以下要素：
Preference: An unsigned integer denoting the router's preference to connect to that cache; the lower the value, the more preferred.
首选项：一个无符号整数，表示路由器连接该高速缓存的优先级；值越小，优先级越高。
Name: The IP address or fully qualified domain name of the cache.
名称：缓存的 IP 地址或完全合格域名。
Key: Any needed public key of the cache.
密钥：缓存所需的任何公钥。
MyKey: Any needed private key or certificate of this client.
我的密钥该客户端所需的私人密钥或证书。
Due to the distributed nature of the RPKI, caches simply cannot be rigorously synchronous. A client may hold data from multiple caches but MUST keep the data marked as to source, as later updates MUST affect the correct data.
由于 RPKI 的分布式特性，缓存不可能严格同步。客户端可以持有多个缓存中的数据，但必须保留标明来源的数据，因为以后的更新必须影响正确的数据。
Just as there may be more than one covering ROA from a single cache, there may be multiple covering ROAs from multiple caches. The results are as described in [RFC6811].
就像来自单个高速缓存的覆盖 ROA 可能不止一个一样，来自多个高速缓存的覆盖 ROA 也可能有多个。结果如 [RFC6811] 所述。
If data from multiple caches are held, implementations MUST NOT distinguish between data sources when performing validation.
如果持有来自多个缓存的数据，则在执行验证时，实现不得区分数据源。
When a more preferred cache becomes available, if resources allow, it would be prudent for the client to start fetching from that cache.
在资源允许的情况下，当一个更可取的缓存可用时，客户端最好开始从该缓存获取数据。
The client SHOULD attempt to maintain at least one set of data, regardless of whether it has chosen a different cache or established a new connection to the previous cache.
客户端应尝试维护至少一组数据，无论它是选择了不同的高速缓存，还是与先前的高速缓存建立了新的连接。
A client MAY drop the data from a particular cache when it is fully in sync with one or more other caches.
当某个高速缓存与一个或多个其他高速缓存完全同步时，客户端可以放弃该高速缓存中的数据。
A client SHOULD delete the data from a cache when it has been unable to refresh from that cache for a configurable timer value. The default for that value is twice the polling period for that cache.
当客户端在一个可配置的定时器值内无法从缓存中刷新数据时，客户端应删除缓存中的数据。该值的默认值是该缓存轮询周期的两倍。
If a client loses connectivity to a cache it is using, or otherwise decides to switch to a new cache, it SHOULD retain the data from the previous cache until it has a full set of data from one or more other caches. Note that this may already be true at the point of connection loss if the client has connections to more than one cache.
如果客户端与正在使用的高速缓存失去连接，或决定切换到新的高速缓存，则应保留前一个高速缓存中的数据，直到从一个或多个其他高速缓存中获得全套数据。需要注意的是，如果客户端与不止一个高速缓存有连接，那么在失去连接时可能就已经是这样了。
For illustration, we present three likely deployment scenarios.
为便于说明，我们提出了三种可能的部署方案。
Small End Site: The small multihomed end site may wish to outsource the RPKI cache to one or more of their upstream ISPs. They would exchange authentication material with the ISP using some out-of-band mechanism, and their router(s) would connect to the cache(s) of one or more upstream ISPs. The ISPs would likely deploy caches intended for customer use separately from the caches with which their own BGP speakers peer.
小型终端站点：小型多重组网终端站点可能希望将 RPKI 缓存外包给一个或多个上游 ISP。它们将使用某种带外机制与 ISP 交换验证材料，其路由器将连接到一个或多个上游 ISP 的高速缓存。ISP 可能会将客户使用的高速缓存与自己的 BGP 扬声器对等的高速缓存分开部署。
Large End Site: A larger multihomed end site might run one or more caches, arranging them in a hierarchy of client caches, each fetching from a serving cache that is closer to the Global RPKI. They might configure fall-back peerings to upstream ISP caches.
大型终端站点：大型多用户终端站点可能会运行一个或多个高速缓存，将它们排列成客户高速缓存的层次结构，每个高速缓存都从离全球 RPKI 较近的服务高速缓存获取数据。它们可能会配置与上游 ISP 缓存的回退对等。
ISP Backbone: A large ISP would likely have one or more redundant caches in each major point of presence (PoP), and these caches would fetch from each other in an ISP-dependent topology so as not to place undue load on the Global RPKI.
ISP 主干网：大型 ISP 可能会在每个主要存在点 (PoP) 中设置一个或多个冗余高速缓存，这些高速缓存将以依赖 ISP 的拓扑结构相互获取，以避免给全球 RPKI 带来不必要的负载。
Experience with large DNS cache deployments has shown that complex topologies are ill-advised as it is easy to make errors in the graph, e.g., not maintain a loop-free condition.
大型 DNS 缓存部署的经验表明，复杂的拓扑结构并不可取，因为很容易在图中出现错误，例如无法保持无循环状态。
Of course, these are illustrations and there are other possible deployment strategies. It is expected that minimizing load on the Global RPKI servers will be a major consideration.
当然，这些只是示例，还有其他可能的部署策略。预计最大限度地减少全球 RPKI 服务器的负载将是一个主要考虑因素。
To keep load on Global RPKI services from unnecessary peaks, it is recommended that primary caches that load from the distributed Global RPKI not do so all at the same times, e.g., on the hour. Choose a random time, perhaps the ISP's AS number modulo 60 and jitter the inter-fetch timing.
为避免全局 RPKI 服务的负载出现不必要的峰值，建议从分布式全局 RPKI 加载的主缓存不要在同一时间（如每小时）加载。选择一个随机的时间，也许是 ISP 的 AS 编号取模 60，然后对取数间隔时间进行抖动。
This section contains a preliminary list of error codes. The authors expect additions to the list this section during development of the initial implementations. There is an IANA registry where valid error codes are listed; see Section 12. Errors that are considered fatal SHOULD cause the session to be dropped.
本节包含错误代码的初步列表。作者希望在初步实施的开发过程中对本节列表进行补充。IANA 注册表中列出了有效的错误代码，请参见第 12 节。被认为是致命的错误应导致会话中断。
0: Corrupt Data (fatal): The receiver believes the received PDU to be corrupt in a manner not specified by other error codes.
0：数据损坏（致命）：接收方认为接收到的 PDU 损坏，损坏方式与其他错误代码不同。
1: Internal Error (fatal): The party reporting the error experienced some kind of internal error unrelated to protocol operation (ran out of memory, a coding assertion failed, et cetera).
1：内部错误（致命）：报错方发生了与协议操作无关的内部错误（内存耗尽、编码断言失败等）。
2: No Data Available: The cache believes itself to be in good working order, but is unable to answer either a Serial Query or a Reset Query because it has no useful data available at this time. This is likely to be a temporary error, and most likely indicates that the cache has not yet completed pulling down an initial current data set from the Global RPKI system after some kind of event that invalidated whatever data it might have previously held (reboot, network partition, et cetera).
2：无可用数据：高速缓存认为自己工作正常，但无法回答串行查询或重置查询，因为此时它没有可用的有用数据。这很可能是一个暂时性错误，很可能表明高速缓存在发生了某种事件（重启、网络分区等）后，尚未完成从全局 RPKI 系统中提取初始数据集的工作。
3: Invalid Request (fatal): The cache server believes the client's request to be invalid.
3: 无效请求（致命）：缓存服务器认为客户端的请求无效。
4: Unsupported Protocol Version (fatal): The Protocol Version is not known by the receiver of the PDU.
4: 协议版本不支持（致命）：PDU 接收方不知道协议版本。
5: Unsupported PDU Type (fatal): The PDU Type is not known by the receiver of the PDU.
5：不支持的 PDU 类型（致命）：PDU 接收方不知道 PDU 类型。
6: Withdrawal of Unknown Record (fatal): The received PDU has Flag=0 but a record for the {Prefix, Len, Max-Len, ASN} tuple does not exist in the receiver's database.
6: 撤回未知记录（致命）：接收的 PDU 有 Flag=0，但接收方数据库中不存在 {Prefix, Len, Max-Len, ASN} 元组的记录。
7: Duplicate Announcement Received (fatal): The received PDU has an identical {Prefix, Len, Max-Len, ASN} tuple as a PDU that is still active in the router.
7：收到重复公告（致命）：收到的 PDU 与路由器中仍处于活动状态的 PDU 具有相同的 {Prefix, Len, Max-Len, ASN} 元组。
As this document describes a security protocol, many aspects of security interest are described in the relevant sections. This section points out issues that may not be obvious in other sections.
由于本文档描述的是一个安全协议，因此在相关章节中描述了与安全有关的许多方面。本节指出了其他章节中可能不明显的问题。
Cache Validation: In order for a collection of caches as described in Section 9 to guarantee a consistent view, they need to be given consistent trust anchors to use in their internal validation process. Distribution of a consistent trust anchor is assumed to be out of band.
缓存验证：为了让第 9 节所述的缓存集合保证一致的视图，需要为它们提供一致的信任锚，以便在内部验证过程中使用。一致信任锚的分布被假定为不在频带内。
Cache Peer Identification: The router initiates a transport session to a cache, which it identifies by either IP address or fully qualified domain name. Be aware that a DNS or address spoofing attack could make the correct cache unreachable. No session would be established, as the authorization keys would not match.
高速缓存对等识别：路由器通过 IP 地址或完全合格的域名向高速缓存发起传输会话。请注意，DNS 或地址欺骗攻击会导致无法到达正确的高速缓存。由于授权密钥不匹配，因此无法建立会话。
Transport Security: The RPKI relies on object, not server or transport, trust. That is, the IANA root trust anchor is distributed to all caches through some out-of-band means, and can then be used by each cache to validate certificates and ROAs all the way down the tree. The inter-cache relationships are based on this object security model; hence, the inter-cache transport can be lightly protected.
传输安全：RPKI 依赖的是对象信任，而不是服务器或传输信任。也就是说，IANA 根信任锚是通过某种带外方式分发给所有缓存的，然后每个缓存都可以用它来验证证书和 ROA，并一直向下延伸。高速缓存间的关系就是基于这种对象安全模型；因此，高速缓存间的传输可以受到轻度保护。
But, this protocol document assumes that the routers cannot do the validation cryptography. Hence, the last link, from cache to router, is secured by server authentication and transport-level security. This is dangerous, as server authentication and transport have very different threat models than object security.
但是，本协议文件假定路由器无法进行验证加密。因此，从高速缓存到路由器的最后一环是通过服务器验证和传输级安全来保障的。这是很危险的，因为服务器验证和传输的威胁模型与对象安全的威胁模型截然不同。
So, the strength of the trust relationship and the transport between the router(s) and the cache(s) are critical. You're betting your routing on this.
因此，信任关系的强度以及路由器和高速缓存之间的传输至关重要。路由选择的关键就在于此。
While we cannot say the cache must be on the same LAN, if only due to the issue of an enterprise wanting to off-load the cache task to their upstream ISP(s), locality, trust, and control are very critical issues here. The cache(s) really SHOULD be as close, in the sense of controlled and protected (against DDoS, MITM) transport, to the router(s) as possible. It also SHOULD be topologically close so that a minimum of validated routing data are needed to bootstrap a router's access to a cache.
虽然我们不能说高速缓存必须在同一局域网内，但如果仅仅是由于企业希望将高速缓存任务卸载给上游 ISP 的问题，那么本地性、信任和控制在这里是非常关键的问题。从受控和受保护（防 DDoS、MITM）传输的角度看，高速缓存应尽可能靠近路由器。高速缓存在拓扑结构上也应尽可能靠近路由器，以便路由器访问高速缓存时只需最少的验证路由数据。
The identity of the cache server SHOULD be verified and authenticated by the router client, and vice versa, before any data are exchanged.
在交换任何数据之前，路由器客户端应核实和验证高速缓存服务器的身份，反之亦然。
Transports that cannot provide the necessary authentication and integrity (see Section 7) must rely on network design and operational controls to provide protection against spoofing/ corruption attacks. As pointed out in Section 7, TCP-AO is the long-term plan. Protocols that provide integrity and authenticity SHOULD be used, and if they cannot, i.e., TCP is used as the transport, the router and cache MUST be on the same trusted, controlled network.
无法提供必要的验证和完整性（见第 7 节）的传输必须依靠网络设计和运行控制来防范欺骗/破坏攻击。如第 7 节所述，TCP-AO 是一项长期计划。应使用能提供完整性和真实性的协议，如果不能，即使用 TCP 作为传输，路由器和高速缓存必须位于同一受控可信网络上。
IANA has assigned 'well-known' TCP Port Numbers to the RPKI-Router Protocol for the following, see Section 7:
IANA 已为 RPKI 路由器协议分配了 "知名 "TCP 端口号，请参见第 7 节：
rpki-rtr rpki-rtr-tls
rpkii-rtr rpkii-rtr-tls
IANA has created a registry for tuples of Protocol Version / PDU Type, each of which may range from 0 to 255. The name of the registry is "rpki-rtr-pdu". The policy for adding to the registry is RFC Required per [RFC5226], either Standards Track or Experimental. The initial entries are as follows:
IANA 为协议版本/PDU 类型元组创建了一个注册表，每个元组的范围为 0 至 255。注册表的名称为 "rpki-rtr-pdu"。根据 [RFC5226]，添加到注册表的策略是 RFC Required，即标准轨或实验性。初始条目如下：
Protocol PDU
Version Type Description
-------- ---- ---------------
0 0 Serial Notify
0 1 Serial Query
0 2 Reset Query
0 3 Cache Response
0 4 IPv4 Prefix
0 6 IPv6 Prefix
0 7 End of Data
0 8 Cache Reset
0 10 Error Report
0 255 Reserved
IANA has created a registry for Error Codes 0 to 255. The name of the registry is "rpki-rtr-error". The policy for adding to the registry is Expert Review per [RFC5226], where the responsible IESG Area Director should appoint the Expert Reviewer. The initial entries should be as follows:
IANA 为错误代码 0 至 255 创建了一个注册表。注册表的名称为 "rpki-rtr-error"。根据 [RFC5226]，向注册表添加内容的政策是专家审查，负责的 IESG 地区总监应指定专家审查员。初始条目应如下：
Error
Code Description
----- ----------------
0 Corrupt Data
1 Internal Error
2 No Data Available
3 Invalid Request
4 Unsupported Protocol Version
5 Unsupported PDU Type
6 Withdrawal of Unknown Record
7 Duplicate Announcement Received
255 Reserved
IANA has added an SSH Connection Protocol Subsystem Name, as defined in [RFC4250], of 'rpki-rtr'.
IANA 已根据 [RFC4250] 的定义添加了 SSH 连接协议子系统名称 "rpki-rtr"。
The authors wish to thank Steve Bellovin, Rex Fernando, Paul Hoffman, Russ Housley, Pradosh Mohapatra, Keyur Patel, Sandy Murphy, Robert Raszuk, John Scudder, Ruediger Volk, and David Ward. Particular thanks go to Hannes Gredler for showing us the dangers of unnecessary fields.
作者感谢史蒂夫-贝洛温、雷克斯-费尔南多、保罗-霍夫曼、拉斯-豪斯利、普拉多什-莫哈帕特拉、克尤尔-帕特尔、桑迪-墨菲、罗伯特-拉斯祖克、约翰-斯卡德、吕迪格-沃尔克和戴维-沃德。特别要感谢汉内斯-格雷德勒（Hannes Gredler），他向我们展示了不必要的字段的危险性。
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996.
[RFC1982] Elz、R. 和 R. Bush，"序列号算术"，RFC 1982，1996 年 8 月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
[RFC3269] Kermode, R. 和 L. Vicisano，"可靠多播传输 (RMT) 构件和协议实例化文件的作者指南"，RFC 3269，2002 年 4 月。
[RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006.
[RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006.
[RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006.
[RFC4252] Ylonen, T. 和 C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten, T. 和 H. Alvestrand，"RFC 中 IANA 考虑部分的编写指南"，BCP 26，RFC 5226，2008 年 5 月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T. 和 E. Rescorla，"传输层安全（TLS）协议 1.2 版"，RFC 5246，2008 年 8 月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)", RFC 5926, June 2010.
[RFC5926] Lebovitz, G. 和 E. Rescorla，"TCP 验证选项 (TCP-AO) 的加密算法"，RFC 5926，2010 年 6 月。
[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, March 2011.
[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, March 2011.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, January 2013.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP 前缀起源验证"，RFC 6811, 2013 年 1 月。
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", RFC 4808, March 2007.
[RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5"，RFC 4808，2007 年 3 月。
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, February 2010.
[RFC5781] Weiler, S., Ward, D., and R. Housley, "rsync URI Scheme", RFC 5781, February 2010.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012.
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012.
[RTR-IMPL] Bush, R., Austein, R., Patel, K., Gredler, H., and M. Waehlisch, "RPKI Router Implementation Report", Work in Progress, January 2012.
[RTR-IMPL] Bush, R., Austein, R., Patel, K., Gredler, H., and M. Waehlisch, "RPKI 路由器实施报告"，工作进展，2012 年 1 月。
Authors' Addresses
作者地址
Randy Bush Internet Initiative Japan 5147 Crystal Springs Bainbridge Island, WA 98110 US
Randy Bush Internet Initiative Japan 5147 Crystal Springs Bainbridge Island, WA 98110 US
EMail: [email protected]
Rob Austein Dragon Research Labs
Rob Austein 龙研究实验室
EMail: [email protected]