Internet Engineering Task Force (IETF) S. Kent
Request for Comments: 8211 BBN Technologies
Category: Informational D. Ma
ISSN: 2070-1721 ZDNS
September 2017
Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI)
认证机构（CA）或资源库管理者在资源公钥基础架构（RPKI）中的不利行为
Abstract
摘要
This document analyzes actions by or against a Certification Authority (CA) or an independent repository manager in the RPKI that can adversely affect the Internet Number Resources (INRs) associated with that CA or its subordinate CAs. The analysis is done from the perspective of an affected INR holder. The analysis is based on examination of the data items in the RPKI repository, as controlled by a CA (or an independent repository manager) and fetched by Relying Parties (RPs). The analysis does not purport to be comprehensive; it does represent an orderly way to analyze a number of ways that errors by or attacks against a CA or repository manager can affect the RPKI and routing decisions based on RPKI data.
本文件分析了 RPKI 中由认证机构（CA）或独立存储库管理者采取的或针对其采取的行动，这些行动可能会对与该认证机构或其下属认证机构相关联的互联网号码资源（INR）产生不利影响。分析从受影响的 INR 持有者的角度进行。分析基于对 RPKI 资源库中数据项的检查，这些数据项由 CA（或独立的资源库管理者）控制，并由依赖方（RP）获取。该分析并不全面，但它代表了一种有序的方法，用于分析 CA 或存储库管理器的错误或攻击可能影响 RPKI 和基于 RPKI 数据的路由选择决策的多种方式。
Status of This Memo
本备忘录的地位
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准轨道规范，仅为提供信息而发布。
This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组 (IETF) 的产品。它已获互联网工程指导小组 (IESG) 批准发布。并非所有经 IESG 批准的文件都能成为任何级别的互联网标准候选文件；请参见 RFC 7841 第 2 节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8211.
有关本文件的当前状态、任何勘误以及如何提供反馈的信息，请访问 https://www.rfc-editor.org/info/rfc8211。
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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文档受BCP 78以及本文档发布之日有效的IETF信托基金关于IETF文档的法律规定（https://trustee.ietf.org/license-info）的约束。 请仔细阅读这些文档，因为它们描述了您对本文档的权利和限制。 从本文档中提取的代码组件必须包含信托法律条款第 4.e 节中描述的简化 BSD 许可证文本，并且不提供简化 BSD 许可证中描述的担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Analysis of RPKI Repository Objects . . . . . . . . . . . . . 4
2.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 6
2.2. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Certificate Revocation List . . . . . . . . . . . . . . . 12
2.4. ROA . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5. Ghostbusters Record . . . . . . . . . . . . . . . . . . . 17
2.6. Router Certificates . . . . . . . . . . . . . . . . . . . 18
3. Analysis of Actions Relative to Scenarios . . . . . . . . . . 19
3.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . . 21
3.2. Scenario B . . . . . . . . . . . . . . . . . . . . . . . 21
3.3. Scenario C . . . . . . . . . . . . . . . . . . . . . . . 21
3.4. Scenario D . . . . . . . . . . . . . . . . . . . . . . . 22
4. Security Considerations . . . . . . . . . . . . . . . . . . . 22
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.1. Normative References . . . . . . . . . . . . . . . . . . 23
6.2. Informative References . . . . . . . . . . . . . . . . . 25
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
In the context of this document, any change to the Resource Public Key Infrastructure (RPKI) [RFC6480] that diminishes the set of Internet Number Resources (INRs) associated with an INR holder, and that is contrary to the holder's wishes, is termed "adverse". This analysis is done from the perspective of an affected INR holder. An action that results in an adverse charge (as defined above) may be the result of an attack on a CA [RFC7132], an error by a CA, or an error by or an attack on a repository operator. Note that the CA that allocated the affected INRs may be acting in accordance with established policy; thus, the change may be contractually justified even though viewed as adverse by the INR holder. This document examines the implications of adverse actions within the RPKI with respect to INRs, irrespective of the cause of the actions.
在本文件中，资源公钥基础设施（RPKI）[RFC6480]的任何变更，如果减少了与 INR 持有者相关的互联网号码资源（INR）集，并且违背了持有者的意愿，则被称为 "不利 "变更。这种分析是从受影响 INR 持有者的角度进行的。导致不利收费（如上定义）的行为可能是对 CA 的攻击 [RFC7132]、CA 的错误、存储库操作员的错误或攻击的结果。请注意，分配受影响 INR 的 CA 可能是按照既定政策行事；因此，即使 INR 持有者认为该变更是不利的，该变更在合同上也是合理的。本文件探讨了在 RPKI 内对 INR 采取不利行动的影响，不论行动的起因如何。
Additionally, when a Route Origin Authorization (ROA) or router certificate is created that "competes" with an existing ROA or router certificate (respectively), the creation of the new ROA or router certificate may be adverse. (A newer ROA competes with an older ROA if the newer ROA points to a different Autonomous System Number (ASN), contains the same or a more specific prefix, and is issued by a different CA. A newer router certificate competes with an older router certificate if the newer one contains the same ASN, contains a different public key, and is issued by a different CA.) Note that transferring resources or changing of upstream providers may yield competing ROAs and/or router certificates under some circumstances. Thus, not all instances of competition are adverse actions.
此外，当创建的路由起源授权（ROA）或路由器证书与现有 ROA 或路由器证书（分别）"竞争 "时，新的 ROA 或路由器证书的创建可能是不利的。(如果较新的 ROA 指向不同的自治系统编号 (ASN)，包含相同或更具体的前缀，并且由不同的 CA 签发，则较新的 ROA 与较旧的 ROA 竞争。如果较新的路由器证书包含相同的 ASN、不同的公开密钥，且由不同的 CA 签发，那么较新的路由器证书就会与较旧的路由器证书竞争）。请注意，在某些情况下，转移资源或更换上游提供商可能会产生相互竞争的 ROA 和/或路由器证书。因此，并非所有竞争情况都是不利行为。
As noted above, adverse changes to RPKI data may arise due to several types of causes. A CA may make a mistake in managing the RPKI objects it signs, or it may be subject to an attack. If an attack allows an adversary to use the private key of that CA to sign RPKI objects, then the effect is analogous to the CA making mistakes. There is also the possibility that a CA or repository operator may be subject to legal measures that compel them to make adverse changes to RPKI data. In many cases, such actions may be hard to distinguish from mistakes or attacks, other than with respect to the time required to remedy the adverse action. (Presumably, the CA will take remedial action when a mistake or an attack is detected, so the effects are similar in these cases. If a CA has been legally compelled to effect an adverse change, remediation will likely not be swift.)
如上所述，RPKI 数据的不利变化可能由几种原因造成。CA 在管理其签署的 RPKI 对象时可能出错，也可能受到攻击。如果攻击允许对手使用该 CA 的私人密钥来签署 RPKI 对象，那么其效果就类似于 CA 犯错。CA 或存储库操作员也有可能受到法律措施的制裁，被迫对 RPKI 数据进行不利的修改。在许多情况下，除了补救不利行为所需的时间外，这种行为可能很难与错误或攻击区分开来。(据推测，当发现错误或攻击时，CA 会采取补救措施，因此在这些情况下的影响是相似的。如果 CA 在法律上被迫实施不利的变更，则补救措施可能不会很快）。
This document analyzes the various types of actions by a CA (or an independent repository operator) that can adversely affect the INRs associated with that CA, as well as the INRs of subordinate CAs. The analysis is based on examination of the data items in the RPKI repository, as controlled by a CA (or an independent repository operator) and fetched by RPs.
本文件分析了 CA（或独立存储库操作员）可能对与该 CA 相关的 INR 以及下属 CA 的 INR 产生不利影响的各类操作。该分析基于对 RPKI 资源库中数据项的检查，这些数据项由 CA（或独立资源库操作员）控制并由 RP 获取。
This section enumerates the RPKI repository system objects and examines how changes to them affect Route Origin Authorizations (ROAs) and router certificate validation. Identifiers are assigned to errors for reference by later sections of this document. Note that not all adverse actions may be encompassed by this taxonomy.
本节列举了 RPKI 资源库系统对象，并探讨了对这些对象的更改会如何影响路由起源授权 (ROAs) 和路由器证书验证。为错误指定了标识符，供本文档后面的章节参考。请注意，并非所有不利行为都包含在本分类法中。
The RPKI repository [RFC6481] contains a number of (digitally signed) objects that are fetched and processed by RPs. Until the deployment of BGPsec [RFC8205], the principal goal of the RPKI is to enable an RP to validate ROAs [RFC6482]. A ROA binds address space to an ASN. A ROA can be used to verify BGP announcements with respect to route origin [RFC6483]. The most important objects in the RPKI for origin validation are ROAs; all of the other RPKI objects exist to enable the validation of ROAs in a fashion consistent with the INR allocation system. Thus, errors that result in changes to a ROA, or to RPKI objects needed to validate a ROA, can cause RPs to reach different (from what was intended) conclusions about the validity of the bindings expressed in a ROA.
RPKI 资源库[RFC6481]包含大量（数字签名）对象，由 RP 获取和处理。在部署 BGPsec [RFC8205] 之前，RPKI 的主要目标是使 RP 能够验证 ROA [RFC6482]。ROA 将地址空间与 ASN 绑定。ROA 可用于验证 BGP 公告的路由来源 [RFC6483]。RPKI 中最重要的起源验证对象是 ROA；所有其他 RPKI 对象的存在都是为了以与 INR 分配系统一致的方式验证 ROA。因此，导致 ROA 或验证 ROA 所需的 RPKI 对象发生变化的错误，会使 RP 对 ROA 中表达的绑定的有效性得出不同于预期的结论。
When BGPsec is deployed, router certificates [RFC8209] will be added to repository publication points. These are end entity (EE) certificates used to verify signatures applied to BGP update data and to enable path validation [RFC8205]. Router certificates are as important to path validation as ROAs are to origin validation.
部署 BGPsec 时，路由器证书 [RFC8209] 将被添加到资源库发布点。这些是终端实体（EE）证书，用于验证应用于 BGP 更新数据的签名并启用路径验证 [RFC8205]。路由器证书对路径验证的重要性不亚于 ROA 对原点验证的重要性。
The objects contained in the RPKI repository are of two types: conventional PKI objects (certificates and Certificate Revocation Lists (CRLs)) and RPKI-specific signed objects. The latter make use of a common encapsulation format [RFC6488] based on the Cryptographic Message Syntax (CMS) [RFC5652]. A syntax error in this common format will cause an RP to reject the object, e.g., a ROA or manifest, as invalid.
RPKI 资源库中包含两种类型的对象：传统 PKI 对象（证书和证书废止列表 (CRL)）和 RPKI 特定的签名对象。后者使用基于加密信息语法 (CMS) [RFC5652] 的通用封装格式 [RFC6488]。这种通用格式中的语法错误会导致 RP 将 ROA 或清单等对象视为无效而予以拒绝。
Adverse actions take several forms:
不利行动有多种形式：
* Deletion (D) is defined as removing an object from a publication point, without the permission of the INR holder.
* 删除 (D) 是指未经 INR 持有者许可，从出版点删除对象。
* Suppression (S) is defined as not deleting an object, or not publishing an object, as intended by an INR holder. This action also includes retaining a prior version of an object in a publication point when a newer version is available for publication.
* 压制 (S) 的定义是，不按照 INR 持有者的意图删除对象或不发布对象。这一行为还包括在有更新版本可发布时，在发布点保留对象的先前版本。
* Corruption (C) is defined as modification of a signed object in a fashion not requiring access to the private key used to sign the object. Thus, a corrupted object will not carry a valid signature. Implicitly, the corrupted object replaces the legitimate version.
* 损坏 (C) 的定义是，以不需要访问用于签名对象的私人密钥的方式修改签名对象。因此，损坏的对象不会带有有效的签名。隐含的意思是，被破坏的对象取代了合法版本。
* Modification (M) is defined as publishing a syntactically valid, verifiable version of an object that differs from the (existing) version authorized by the INR holder. Implicitly, the legitimate version of the affected object is deleted and replaced by the modified object.
* 修改 (M) 被定义为发布一个语法上有效、可验证的对象版本，该版本与 INR 持有者授权的（现有）版本不同。隐含的意思是，受影响对象的合法版本被删除，由修改后的对象取代。
* Revocation (R) is defined as revoking a certificate (EE or CA) by placing its Serial Number on the appropriate CRL, without authorization of the INR holder.
* 废止 (R) 的定义是：在未经 INR 持有者授权的情况下，将证书（EE 或 CA）的序列号放在相应的 CRL 上，从而废止该证书。
* Injection (I) is defined as introducing an instance of a signed object into a publication point (without authorization of the INR holder). It assumes that the signature on the object will be viewed as valid by RPs.
* 注入 (I) 的定义是（在未经 INR 持有者授权的情况下）将已签名对象的实例引入发布点。它假定对象上的签名将被 RP 视为有效。
The first three of these actions (deletion, suppression, and corruption) can be effected by any entity that manages the publication point of the affected INR holder. Also, an entity with the ability to act as a man-in-the-middle between an RP and a repository can effect these actions with respect to the RP in question.
管理受影响 INR 持有者发布点的任何实体都可以执行前三种操作（删除、抑制和损坏）。此外，有能力在 RP 和存储库之间充当中间人的实体也可以对相关 RP 执行这些操作。
The latter three actions (modification, revocation, and injection) nominally require access to the private key of the INR holder.
后三种操作（修改、撤销和注入）名义上都需要获取 INR 持有者的私人密钥。
All six of these actions also can be effected by a parent CA. A parent CA could reissue the INR holder's CA certificate, but with a different public key, matching a private key to which the parent CA has access. The CA could generate new signed objects using the private key associated with the reissued certificate and publish these objects at a location of its choosing.
父 CA 也可以执行上述所有六种操作。父 CA 可以重新签发 INR 持有者的 CA 证书，但使用不同的公开密钥，与父 CA 可以访问的私钥相匹配。CA 可以使用与重新签发的证书相关的私钥生成新的签名对象，并在其选择的位置发布这些对象。
Most of these actions may be performed independently or in combination with one another. For example, a ROA may be revoked and deleted or revoked and replaced with a modified ROA. Where appropriate, the analysis of adverse actions will distinguish between individual actions, or combinations thereof, that yield different outcomes for RPs. Recall that the focus of the analysis is the impact on ROAs and router certificates, with respect to RP processing.
这些操作大多可以单独执行，也可以相互组合执行。例如，可以撤销和删除 ROA，也可以撤销 ROA 并用修改后的 ROA 取代。在适当的情况下，对不利行动的分析将对个别行动或行动组合进行区分，因为它们会给正常计划带来不同的结果。请注意，分析的重点是 ROA 和路由器证书对 RP 处理的影响。
The following sections examine how the actions enumerated above affect objects in the RPKI repository system. Each action is addressed in order (deletion, suppression, corruption, modification, revocation, and injection) for each object, making it easy to see how each action has been considered with regard to each object. (For the Ghostbusters Record [RFC6493], we condensed the discussion of the actions because the impact is the same in each case.)
以下各节将探讨上述行为如何影响 RPKI 资源库系统中的对象。每种行为都按顺序（删除、抑制、破坏、修改、撤销和注入）针对每个对象进行了讨论，以便于了解每个行为是如何针对每个对象进行考虑的。(对于《捉鬼敢死队记录》[RFC6493]，我们压缩了对操作的讨论，因为每种操作的影响是相同的）。
Every INR holder is represented by one or more CA certificates. An INR holder has multiple CA certificates if it holds resources acquired from different sources. Also, every INR holder has more than one CA certificate during key rollover [RFC6489] and algorithm rollover [RFC6916].
每个 INR 持有者都有一个或多个 CA 证书。如果一个 INR 持有者持有从不同来源获取的资源，则该 INR 持有者拥有多个 CA 证书。此外，在密钥滚转 [RFC6489] 和算法滚转 [RFC6916] 期间，每个 INR 持有者都拥有一个以上的 CA 证书。
If a publication point is not a "leaf" in the RPKI hierarchy, then the publication point will contain one or more CA certificates, each representing a subordinate CA. Each subordinate CA certificate contains a Subject Information Access (SIA) pointer to the publication point where the signed objects associated with that CA can be found [RFC6487].
如果发布点不是 RPKI 层次结构中的 "叶"，那么发布点将包含一个或多个 CA 证书，每个证书代表一个下属 CA。每个下级 CA 证书都包含一个主题信息访问（SIA）指针，指向可以找到与该 CA 相关的签名对象的发布点 [RFC6487]。
A CA certificate is a complex data structure; thus, errors in that structure may have different implications for RPs depending on the specific data that is in error.
CA 证书是一个复杂的数据结构；因此，该结构中的错误可能会对 RP 产生不同的影响，具体取决于出错的具体数据。
Adverse actions against a CA certificate can cause the following errors:
对 CA 证书的不利操作会导致以下错误：
A-1.1 Deletion
A-1.1 删除
A-1.1.1 Deletion of a CA certificate would cause an RP to not be able to locate signed objects generated by that CA, except those that have been cached by the RP. Thus, an RP would be unaware of changed or new (issued after the cached data) INR bindings asserted in subordinate ROAs, and the RP would be unable to validate new or changed router certificates. If the missed objects were intended to replace ROAs or router certificates prior to expiration, then when those objects expire, RPs may cease to view them as valid. As a result, valid routes may be viewed as NotFound or Invalid.
A-1.1.1 删除 CA 证书将导致 RP 无法找到该 CA 生成的签名对象，RP 缓存的对象除外。因此，RP 将不知道下级 ROA 中断言的已更改或新的（在缓存数据之后签发的）INR 绑定，RP 将无法验证新的或已更改的路由器证书。如果遗漏对象的目的是在过期前替换 ROA 或路由器证书，那么当这些对象过期时，RP 可能不再将其视为有效。因此，有效路由可能会被视为 NotFound 或无效。
A-1.2 Suppression
A-1.2 抑制
A-1.2.1 If publication of a CA certificate is suppressed, the impact depends on what changes appeared in the suppressed certificate. If the SIA value changed, the effect would be the same as in A-1.1 or A-1.4.3. If the [RFC3779] extensions in the suppressed certificate changed, the impact would be the same as in A-1.4.1. If the Authority Information Access (AIA) extension changed in the suppressed certificate, the impact would be the same as in A-1.4.4. Suppression of a renewed/ re-issued certificate may cause an old certificate to expire and thus be rejected by RPs.
A-1.2.1 如果 CA 证书的公布被禁止，其影响取决于被禁止的证书中出现了哪些变化。如果 SIA 值发生变化，其影响与 A-1.1 或 A-1.4.3 相同。如果抑制证书中的 [RFC3779] 扩展名发生变化，影响与 A-1.4.1 中相同。如果被禁止证书中的机构信息访问（AIA）扩展名发生变化，影响与 A-1.4.4 中相同。压制更新/重新签发的证书可能会导致旧证书过期，从而被 RP 拒绝。
A-1.3 Corruption
A-1.3 腐败
A-1.3.1 Corruption of a CA certificate will cause it to be rejected by RPs. In turn, this may cause subordinate signed objects to become invalid. An RP that has cached the subtree under the affected CA certificate may continue to view it as valid, until objects expire. But changed or new objects might not be retrieved, depending on details of the design of the RP software. Thus, this action may be equivalent to suppressing changes to the affected subtree.
A-1.3.1 CA 证书的损坏会导致 RP 拒绝接受该证书。反过来，这可能会导致下级签名对象失效。缓存了受影响 CA 证书下子树的 RP 可能会继续将其视为有效，直到对象过期。但已更改或新的对象可能无法检索，这取决于 RP 软件设计的细节。因此，这一操作可能等同于抑制对受影响子树的更改。
A-1.4 Modification
A-1.4 修改
A-1.4.1 If a CA certificate is modified but still conforms to the RPKI certificate profile [RFC7935], it will be accepted by RPs. If an [RFC3779] extension in this certificate is changed to exclude INRs that were previously present, then subordinate signed objects will become invalid if they rely on the excised INRs. If these objects are CA certificates, their subordinate signed objects will be treated as invalid. If the objects are ROAs, the binding expressed by the affected ROAs will be ignored by RPs. If the objects are router certificates, BGPsec_PATH attributes [RFC8205] verifiable under these certificates will be considered invalid.
A-1.4.1 如果 CA 证书被修改但仍符合 RPKI 证书规范 [RFC7935]，则将被 RP 接受。如果该证书中的[RFC3779]扩展名被修改以排除以前存在的 INR，那么如果下级签名对象依赖于被删除的 INR，它们将变得无效。如果这些对象是 CA 证书，其从属签名对象将被视为无效。如果对象是 ROA，RP 将忽略受影响的 ROA 所表示的绑定。如果这些对象是路由器证书，在这些证书下可验证的 BGPsec_PATH 属性 [RFC8205] 将被视为无效。
A-1.4.2 If the SIA extension of a CA certificate is modified to refer to another publication point, this will cause an RP to look at another location for subordinate objects. This could cause RPs to not acquire the objects that the INR holder intended to be retrieved -- manifests, ROAs, router certificates, Ghostbuster Records, or any subordinate CA certificates associated with that CA. If the objects at this new location contain invalid signatures or appear to be corrupted, they may be rejected. In this case, cached versions of the objects may be viewed as valid by an RP, until they expire. If the objects at the new location have valid signatures and pass path validation checks, they will replace the cached objects, effectively replacing the INR holder's objects.
A-1.4.2 如果 CA 证书的 SIA 扩展名被修改为指向另一个发布点，这将导致 RP 在另一个位置查找下级对象。这可能导致 RP 无法获取 INR 持有者打算检索的对象--清单、ROA、路由器证书、Ghostbuster 记录或与该 CA 相关的任何下属 CA 证书。如果新位置上的对象包含无效签名或似乎已损坏，则可能会被拒绝。在这种情况下，缓存版本的对象可能会被 RP 视为有效，直到过期为止。如果新位置的对象具有有效签名并通过了路径验证检查，它们将取代缓存对象，从而有效取代 INR 持有者的对象。
A-1.4.3 If the AIA extension in a CA certificate is modified, it would point to a different CA certificate, not the parent CA certificate. This extension is used only for path discovery, not path validation. Path discovery in the RPKI is usually performed on a top-down basis, starting with trust anchors (TAs) and recursively descending the RPKI hierarchy. Thus, there may be no impact on the ability of clients to acquire and validate certificates if the AIA is modified.
A-1.4.3 如果 CA 证书中的 AIA 扩展名被修改，它将指向不同的 CA 证书，而不是父 CA 证书。该扩展名只用于路径发现，不用于路径验证。RPKI 中的路径发现通常是自上而下进行的，从信任锚（TA）开始，依次递归到 RPKI 层次结构。因此，如果修改 AIA，可能不会影响客户获取和验证证书的能力。
A-1.4.4 If the Subject Public Key Info (and Subject Key Identifier extension) in a CA certificate is modified to contain a public key corresponding to a private key held by the parent, the parent could sign objects as children of the affected CA certificate. With this capability, the parent could replace the INR holder, issuing new signed objects that would be accepted by RPs (as long as they do not violate the path validation criteria). This would enable the parent to effect modification, revocation, and injection actions against all of the objects under the affected CA certificate, including subordinate CA certificates. (Note that key rollover also yields a new CA certificate. However, the new certificate will coexist with the old one for a while, which may help distinguish this legitimate activity from an adverse action.)
A-1.4.4 如果 CA 证书中的 "主体公钥信息"（和 "主体密钥标识符扩展名"）被修改为包含与父节点持有的私钥相对应的公钥，则父节点可签署对象作为受影响 CA 证书的子节点。有了这种能力，父证书就可以取代 INR 持有者，签发新的已签名对象，这些对象将被 RP 接受（只要不违反路径验证标准）。这样，父节点就能对受影响 CA 证书下的所有对象（包括下级 CA 证书）执行修改、撤销和注入操作。(请注意，密钥翻转也会产生新的 CA 证书。不过，新证书会与旧证书共存一段时间，这可能有助于区分这种合法行为和不利行为）。
A-1.5 Revocation
A-1.5 撤销
A-1.5.1 If a CA certificate is revoked, an RP will treat as invalid all subordinate signed objects, both immediate and transitive. The effects are essentially the same as described in A-3.4.2.
A-1.5.1 如果 CA 证书被废止，RP 将把所有下级签名对象（包括直接对象和传递对象）视为无效。其影响与 A-3.4.2 中描述的基本相同。
A-1.6 Injection
A-1.6 喷射
A-1.6.1 If a CA certificate is injected, the impact will depend on the data contained in the injected certificate. Changes will generally be equivalent to modification actions as described in A-1.4.
A-1.6.1 如果注入 CA 证书，其影响将取决于注入证书中的数据。变化一般等同于 A-1.4 中描述的修改操作。
Each repository publication point contains a manifest [RFC6486]. The RPKI incorporates manifests to enable RPs to detect suppression and/ or substitution of (more recent) publication point objects, as the result of a mistake or attack. A manifest enumerates (by filename) all of the other signed objects at the publication point. The manifest also contains a hash of each enumerated file to enable an RP to determine if the named file content matches what the INR holder identified in the manifest.
每个资源库发布点都包含一个清单[RFC6486]。RPKI 包含清单的目的是使 RP 能够检测因错误或攻击而导致的（较新的）发布点对象被抑制和/或替换的情况。清单（按文件名）列举了发布点的所有其他签名对象。清单还包含每个枚举文件的哈希值，以便 RP 确定命名的文件内容是否与 INR 持有者在清单中确定的内容一致。
A manifest is an RPKI signed object, so it is validated as per [RFC6488]. If a manifest is modified in a way that causes any of these checks to fail, the manifest will be considered invalid. Suppression of a manifest itself (indicated by a stale manifest) can also cause an RP to not detect suppression of other signed objects at the publication point. (Note that if a manifest's EE certificate expires at the time that the manifest is scheduled to be replaced, a delay in publication will cause the manifest to become invalid, not merely stale. This very serious outcome should be avoided, e.g., by making the manifest EE certificate's notAfter value the same as that of the CA certificate under which it was issued). If a signed object at a publication point can be validated (using the rules applicable for that object type), then an RP may accept that object, even if there is no matching entry for it on the manifest. However, it appears that most RP software ignores publication point data that fails to match manifest entries (at the time this document was written).
清单是 RPKI 签名对象，因此要按照 [RFC6488] 进行验证。如果对清单的修改导致上述任何检查失败，清单将被视为无效。清单本身的抑制（由过期清单表示）也会导致 RP 无法在发布点检测到其他签名对象的抑制。(请注意，如果清单的 EE 证书在清单计划被替换时过期，延迟发布将导致清单失效，而不仅仅是过期）。应避免这种非常严重的后果，例如，使清单电子环境证书的 notAfter 值与签发该清单的 CA 证书的 notAfter 值相同）。如果在发布点签名的对象可以通过验证（使用适用于该对象类型的规则），那么即使清单上没有与之匹配的条目，RP 也可以接受该对象。不过，大多数登记册软件似乎都会忽略与清单条目不匹配的公布点数据（在编写本文件时）。
Corruption, suppression, modification, or deletion of a manifest might not affect RP processing of other publication point objects, as specified in [RFC6486]. However, as noted above, many RP implementations ignore objects that are present at a publication point but not listed in a valid manifest. Thus, the following actions against a manifest can impact RP processing:
如 [RFC6486] 所述，清单的损坏、抑制、修改或删除可能不会影响 RP 对其他发布点对象的处理。但是，如上所述，许多 RP 实现都会忽略存在于发布点但未在有效清单中列出的对象。因此，针对清单的以下操作可能会影响 RP 处理：
A-2.1 Deletion
A-2.1 删除
A-2.1.1 A manifest may be deleted from the indicated publication point. In this circumstance, an RP may elect to use the previous manifest (if available) and may ignore any new/changed objects at the publication point. The implications of this action are equivalent to suppression of publication of the objects that are not recognized by RPs because the new objects are not present in the old manifest. For example, a new ROA could be ignored (A-1.2). A newly issued CA certificate might be ignored (A-1.1). A subordinate CA certificate that was revoked might still be viewed as valid by RPs (A-4.1). A new or changed router certificate might be ignored (A-6.2) as would a revised Ghostbusters Record (A-4.1).
A-2.1.1 清单可以从指定的发布点删除。在这种情况下，RP 可以选择使用以前的清单（如果有的话），并忽略公布点上任何新的/变更的对象。这种做法的影响等同于禁止发布 RP 无法识别的对象，因为新对象不在旧清单中。例如，新的 ROA 可能会被忽略（A-1.2）。新签发的 CA 证书可能被忽略（A-1.1）。被撤销的下级 CA 证书可能仍被 RP 视为有效（A-4.1）。新的或已更改的路由器证书可能会被忽略（A-6.2），修订后的 "魔鬼克星记录 "也会被忽略（A-4.1）。
A-2.2 Suppression
A-2.2 抑制
A-2.2.1 Publication of a newer manifest may be suppressed. Suppression of a newer manifest probably will cause an RP to rely on a cached manifest (if available). The older manifest would not enumerate newly added objects; thus, those objects might be ignored by an RP, which is equivalent to deletion of those objects (A-1.1, A-3.1, A-4.1, A-5.1, and A-6.1).
A-2.2.1 较新舱单的发布可能被禁止。抑制更新的清单可能会导致 RP 依赖于缓存的清单（如果有的话）。较旧的清单不会列举新添加的对象；因此，这些对象可能会被注册表忽略，相当于删除了这些对象（A-1.1、A-3.1、A-4.1、A-5.1 和 A-6.1）。
A-2.3 Corruption
A-2.3 腐败
A-2.3.1 A manifest may be corrupted. A corrupted manifest will be rejected by RPs. This may cause RPs to rely on a previous manifest, with the same impact as A-2.2. If an RP does not revert to using a cached manifest, the impact of this action is very severe, i.e., all publication point objects will probably be viewed as invalid, including subordinate tree objects. This is equivalent to revoking or deleting an entire subtree (see A-4.4.2).
A-2.3.1 舱单可能被损坏。损坏的清单将被 RP 拒绝。这可能导致 RP 依赖以前的清单，其影响与 A-2.2 相同。如果 RP 不恢复使用缓存的清单，这一行为的影响将非常严重，即所有发布点对象都可能被视为无效，包括下级树对象。这相当于撤销或删除整个子树（参见 A-4.4.2）。
A-2.4 Modification
A-2.4 修改
A-2.4.1 A manifest may be modified to remove one or more objects. Because the modified manifest is viewed as valid by RPs, any objects that were removed may be ignored by RPs. This is equivalent to deleting these objects from the repository. The impact of this action will vary, depending on which objects are (effectively) removed. However, the impact is equivalent to deletion of the object in question, (A-1.1, A-3.1, A-4.1, A-5.1, and A-6.1).
A-2.4.1 可以修改清单，删除一个或多个对象。由于修改后的清单被 RP 视为有效，因此任何被删除的对象都可能被 RP 忽略。这相当于从版本库中删除这些对象。此操作的影响会有所不同，取决于哪些对象被（有效）删除。不过，其影响等同于删除有关对象（A-1.1、A-3.1、A-4.1、A-5.1 和 A-6.1）。
A-2.4.2 A manifest may be modified to add one or more objects. If an added object has a valid signature (and is not expired), it will be accepted by RPs and processed accordingly. If the added object was previously deleted by the INR holder, this action is equivalent to suppressing deletion of that object. If the object is newly created or modified, it is equivalent to a modification or injection action for the type of object in question and is thus discussed in the relevant section for those actions for the object type.
A-2.4.2 可以修改清单，添加一个或多个对象。如果添加的对象签名有效（且未过期），RP 将接受该对象并进行相应处理。如果所添加的对象之前已被 INR 持有者删除，则该操作等同于禁止删除该对象。如果对象是新创建或修改的，则等同于对相关对象类型的修改或注入操作，因此将在对象类型的相关操作部分进行讨论。
A-2.4.3 A manifest may be modified to list an incorrect hash for one or more objects. An object with an incorrect hash may be ignored by an RP. Thus, the effect may be equivalent to corrupting the object in question, although the error reported by RP software would differ from that reported for a corrupted object. (The manifest specifications do not require an RP to ignore an object that has a valid signature and that is not revoked or expired, but for which the hash doesn't match the object. However, an RP may elect to do so.)
A-2.4.3 清单可能被修改为列出一个或多个对象的错误哈希值。散列值不正确的对象可能会被 RP 忽略。因此，尽管 RP 软件报告的错误与损坏对象报告的错误不同，但其效果可能等同于损坏有关对象。(清单规范并不要求注册表忽略签名有效、未被撤销或过期、但哈希值与对象不匹配的对象。不过，RP 可以选择这样做）。
A-2.5 Revocation
A-2.5 撤销
A-2.5.1 A manifest may be revoked (by including its EE certificate on the CRL for the publication point). A revoked manifest will be ignored by an RP, which probably would revert to an older (cached) manifest. The implications for RPs are equivalent to A-2.1 with regard to new/changed objects.
A-2.5.1 清单可被撤销（在发布点的 CRL 中包含其 EE 证书）。废止的清单将被 RP 忽略，RP 可能会恢复使用旧的（缓存的）清单。这对 RP 的影响等同于 A-2.1 中的新对象/变更对象。
A-2.6 Injection
A-2.6 喷射
A-2.6.1 A manifest representing different objects may be injected into a publication point. The effects are the same as for a modified manifest (see above). The impact will depend on the type of the affected object(s) and is thus discussed in the relevant section(s) for each object type.
A-2.6.1 可以将代表不同对象的清单注入发布点。其影响与修改清单相同（见上文）。影响取决于受影响对象的类型，因此将在每种对象类型的相关章节中讨论。
Each publication point contains a CRL that enumerates revoked (not yet expired) certificates issued by the CA associated with the publication point [RFC6481].
每个发布点都包含一个 CRL，其中列举了与发布点相关的 CA 签发的已撤销（尚未过期）证书 [RFC6481]。
Adverse actions against a CRL can cause the following errors:
针对 CRL 的不利操作可能会导致以下错误：
A-3.1 Deletion
A-3.1 删除
A-3.1.1 If a CRL is deleted, RPs will continue to use an older, previously fetched Certificate Revocation List. As a result, they will not be informed of any changes in revocation status of subordinate CA or router certificates or the EE certificates of signed objects, e.g., ROAs. This action is equivalent to corruption of a CRL, since a corrupted CRL will not be accepted by an RP.
A-3.1.1 如果证书废止列表被删除，RP 将继续使用以前获取的旧证书废止列表。因此，它们将无法获知下级 CA 或路由器证书或已签名对象（如 ROA）的 EE 证书吊销状态的任何变化。这种行为等同于损坏证书废止列表，因为损坏的证书废止列表不会被 RP 接受。
A-3.1.2 Deletion of a CRL could cause an RP to continue to accept a ROA that no longer expresses the intent of an INR holder. As a result, an announcement for the affected prefixes would be viewed as Valid, instead of NotFound or Invalid. In this case, the effect is analogous to A-5.2.
A-3.1.2 删除 CRL 可能会导致 RP 继续接受不再表达 INR 持有者意图的 ROA。因此，受影响前缀的公告将被视为 "有效"，而不是 "未找到 "或 "无效"。在这种情况下，效果类似于 A-5.2。
A-3.1.3 If a router certificate were revoked and the CRL were deleted, RPs would not be aware of the revocation. They might continue to accept the old, revoked router certificate. If the certificate had been revoked due to a compromise of the router's private key, RPs would be vulnerable to accepting routes signed by an unauthorized entity.
A-3.1.3 如果路由器证书被废止，而证书废止列表被删除，RP 不会知道证书被废止。它们可能会继续接受旧的、已废止的路由器证书。如果证书因路由器私钥泄露而被废止，RP 就很容易接受未经授权实体签署的路由。
A-3.1.4 If a subordinate CA certificate were revoked on the deleted CRL, the revocation would not take effect. This could interfere with a transfer of address space from the subordinate CA, adversely affecting routing to the new holder of the space.
A-3.1.4 如果下级 CA 证书在已删除的 CRL 上被废止，废止将不会生效。这可能会干扰从属 CA 地址空间的转移，对地址空间新持有人的路由产生不利影响。
A-3.2 Suppression
A-3.2 抑制
A-3.2.1 If publication of the most recent CRL is suppressed, an RP will not be informed of the most recent revocation status of a subordinate CA or router certificates or the EE certificates of signed objects. If an EE certificate has been revoked and the associated signed object is still present in the publication point, an RP might mistakenly treat that object as valid. (This would happen if the object is still in the manifest or if the RP is configured to process valid objects that are not on the manifest.) This type of action is of special concern if the affected object is a ROA, a router certificate, or a subordinate CA certificate. The effects here are equivalent to CRL deletion (A-3.1), but suppression of a new CRL may not even be reported as an error, i.e., if the suppressed CRL were issued before the NextUpdate time (of the previous CRL).
A-3.2.1 如果禁止公布最新的 CRL，RP 将无法获知下级 CA 或路由器证书或已签名对象的 EE 证书的最新废止状态。如果 EE 证书已被废止，而相关的已签名对象仍存在于发布点中，RP 可能会错误地将该对象视为有效（如果该对象已被废止，RP 可能会错误地将该对象视为有效）。(如果对象仍在清单中，或者如果 RP 被配置为处理清单中没有的有效对象，就会发生这种情况）。如果受影响的对象是 ROA、路由器证书或从属 CA 证书，这类操作就特别值得关注。此处的影响等同于 CRL 删除（A-3.1），但如果被抑制的 CRL 是在 NextUpdate 时间（前一个 CRL 的 NextUpdate 时间）之前发布的，则抑制新的 CRL 甚至可能不会被报告为错误。
A-3.3 Corruption
A-3.3 腐败
A-3.3.1 If a CRL is corrupted, an RP will reject it. If a prior CRL has not yet exceeded its NextUpdate time, an RP will continue to use the prior CRL. Even if the prior CRL has passed the NextUpdate time, an RP may choose to continue to rely on the prior CRL. The effects are essentially equivalent to suppression or deletion of a CRL (A-3.1 and A-3.2).
A-3.3.1 如果 CRL 已损坏，RP 将拒绝接受。如果先前的 CRL 尚未超过 NextUpdate 时间，RP 将继续使用先前的 CRL。即使先前的 CRL 已超过 NextUpdate 时间，RP 仍可选择继续依赖先前的 CRL。其效果基本上等同于抑制或删除 CRL（A-3.1 和 A-3.2）。
A-3.4 Modification
A-3.4 修改
A-3.4.1 If a CRL is modified to erroneously list a signed object's EE certificate as revoked, the corresponding object will be treated as invalid by RPs, even if it is present in a publication point. If this object is a ROA, the (legitimate) binding expressed by the ROA will be ignored by an RP (see A-5.5). If a CRL is modified to erroneously list a router certificate as revoked, a path signature associated with that certificate will be treated as Not Valid by RPs (see A-6.5).
A-3.4.1 如果 CRL 被修改为错误地将已签名对象的 EE 证书列为已撤销，则相应对象将被 RP 视为无效，即使它存在于发布点中。如果该对象是 ROA，ROA 所表达的（合法）绑定将被 RP 忽略（见 A-5.5）。如果 CRL 被修改为错误地将路由器证书列为已撤销，则与该证书相关的路径签名将被 RP 视为无效（见 A-6.5）。
A-3.4.2 If a CRL is modified to erroneously list a CA certificate as revoked, that CA and all subordinate signed objects will be treated as invalid by RPs. Depending on the location of the affected CA in the hierarchy, these effects could be very substantial, causing routes that should be Valid to be treated as NotFound.
A-3.4.2 如果 CRL 被修改为错误地将 CA 证书列为已撤销，则该 CA 及其所有下级签名对象将被 RP 视为无效。根据受影响 CA 在层次结构中的位置，这些影响可能会非常大，导致本应有效的路由被视为未找到。
A-3.4.3 If a CRL is modified to omit a revoked EE, router, or CA certificate, RPs will likely continue to accept the revoked, signed object as valid. This contravenes the intent of the INR holder. If an RP continues to accept a revoked ROA, it may make routing decisions on now-invalid data. This could cause valid routes to be de-preferenced and invalid routes to continue to be accepted.
A-3.4.3 如果修改 CRL 以省略已废止的 EE、路由器或 CA 证书，RP 可能会继续接受已废止的签名对象为有效。这违背了 INR 持有者的意图。如果 RP 继续接受已撤销的 ROA，它可能会根据现在无效的数据做出路由决策。这可能会导致有效路由被取消引用，而无效路由继续被接受。
A-3.5 Revocation
A-3.5 撤销
A-3.5.1 A CRL cannot be revoked per se, but it will fail validation if the CA certificate under which it was issued is revoked. See A-1.5 for a discussion of that action.
A-3.5.1 CRL 本身不能被撤销，但如果签发 CRL 的 CA 证书被撤销，CRL 将无法通过验证。有关该操作的讨论，请参见 A-1.5。
A-3.6 Injection
A-3.6 喷射
A-3.6.1 Insertion of a bogus CRL can have the same effects as listed above for a modified CRL, depending on how the inserted CRL differs from the correct CRL.
A-3.6.1 根据插入的 CRL 与正确 CRL 的不同之处，插入假的 CRL 会产生与上述修改的 CRL 相同的效果。
In addition to the generic RPKI object syntax checks, ROA validation requires that the signature on the ROA can be validated using the public key from the EE certificate embedded in the ROA [RFC6482]. It also requires that the EE certificate be validated consistently with the procedures described in [RFC6482] and [RFC6487]. Adverse actions against a ROA can cause the following errors:
除了一般的 RPKI 对象语法检查外，ROA 验证还要求 ROA 上的签名可使用嵌入 ROA [RFC6482] 的 EE 证书中的公钥进行验证。它还要求根据 [RFC6482] 和 [RFC6487] 中描述的程序对 EE 证书进行验证。针对 ROA 的不利操作会导致以下错误：
A-4.1 Deletion
A-4.1 删除
A-4.1.1 A ROA may be deleted from the indicated publication point. The result is to void the binding between the prefix(es) and the Autonomous System (AS) number in the ROA. An RP that previously viewed this binding as authentic will now not have any evidence about its validity. For origin validation, this means that a legitimate route will be treated as NotFound (if there are no other ROAs for the same prefix) or Invalid (if there is another ROA for the same prefix, but with a different AS number).
A-4.1.1 可以从指定的发布点删除 ROA。其结果是使 ROA 中的前缀与自治系统（AS）号码之间的绑定失效。之前将此绑定视为真实绑定的 RP 现在将无法证明其有效性。对于起源验证，这意味着合法路由将被视为 NotFound（如果相同前缀没有其他 ROA）或无效（如果相同前缀有其他 ROA，但 AS 编号不同）。
A-4.2 Suppression
A-4.2 抑制
A-4.2.1 Publication of a newer ROA may be suppressed. If the INR holder intended to change the binding between the prefix(es) and the AS number in the ROA, this change will not be effected. As a result, RPs may continue to believe an old prefix/ ASN binding that is no longer what the INR holder intended.
A-4.2.1 更新的 ROA 可能被禁止发布。如果 INR 持有者打算更改 ROA 中的前缀和 AS 号之间的绑定，这一更改将不会生效。因此，RP 可能会继续相信旧的前缀/ASN 绑定，而这已不再是 INR 持有者的初衷。
A-4.2.2 If an INR holder intends to issue and publish two (or more) new ROAs for the same address space, one (or more) of the new ROAs may be suppressed while the other is published. In this case, RPs will de-preference the suppressed prefix/ASN binding. Suppression of the new ROA might cause traffic to flow to an ASN other than the one(s) intended by the INR holder.
A-4.2.2 如果 INR 持有者打算为同一地址空间发布和公布两个（或多个）新的 ROA，其中一个（或多个）新的 ROA 可能会被抑制，而另一个则会被公布。在这种情况下，RP 将不再优先选择被抑制的前缀/ASN 绑定。抑制新 ROA 可能会导致流量流向 ASN，而不是 INR 持有者想要的 ASN。
A-4.2.3 If an INR holder intends to delete all ROAs for the same address space, some of them may be retained while the others are deleted. Preventing the deletion of some ROAs can cause traffic to continue to be delivered to the ASNs that were advertised by these ROAs. Deletion of all ROAs is consistent with a transfer of address space to a different INR holder in a phased fashion. Thus, this sort of attack could interfere with the successful transfer of the affected address space (until such time as the prefixes are removed from the previous INR holder's CA certificate).
A-4.2.3 如果 INR 持有者打算删除同一地址空间的所有 ROA，可能会保留部分 ROA，而删除其他 ROA。阻止删除某些 ROA 可能会导致流量继续被传送到这些 ROA 广告的 ASN。删除所有 ROA 与分阶段向不同 INR 持有者转移地址空间是一致的。因此，这种攻击可能会干扰受影响地址空间的成功转移（直到这些前缀从之前 INR 持有者的 CA 证书中删除为止）。
A-4.3 Corruption
A-4.3 腐败
A-4.3.1 A ROA may be corrupted. A corrupted ROA will be ignored by an RP, so the effect is essentially the same as for A-4.1 and A-4.5. A possible difference is that an RP may be alerted to the fact that the ROA was corrupted, which might attract attention to the attack.
A-4.3.1 ROA 可能被破坏。损坏的 ROA 将被 RP 忽略，因此其效果与 A-4.1 和 A-4.5 基本相同。可能的区别是，RP 可能会被告知 ROA 已损坏的事实，这可能会引起对攻击的注意。
A-4.4 Modification
A-4.4 修改
A-4.4.1 A ROA may be modified so that the Autonomous System Number (ASN) or one or more of the address blocks in a ROA is different from the values the INR holder intended for this ROA. (This action assumes that the modified ROA's ASN and address ranges are authorized for use by the INR holder.) This attack will cause RPs to de-preference the legitimate prefix/ASN binding intended by the INR holder.
A-4.4.1 可以修改 ROA，使 ROA 中的自治系统号（ASN）或一个或多个地址块不同于 INR 持有者为该 ROA 设定的值。(此操作假定修改后的 ROA 的 ASN 和地址范围是 INR 持有者授权使用的）。这种攻击会导致 RP 不再优先选择 INR 持有者希望的合法前缀/ASN 绑定。
A-4.5 Revocation
A-4.5 撤销
A-4.5.1 A ROA may be revoked (by placing its EE certificate on the CRL for the publication point). This has the same effect as A-4.1.
A-4.5.1 ROA 可被撤销（将其 EE 证书列入发布点的 CRL）。其效果与 A-4.1 相同。
A-4.6 Injection
A-4.6 喷射
A-4.6.1 A ROA expressing different bindings than those published by the INR holder may be injected into a publication point. This action could authorize an additional ASN to advertise the specified prefix, allowing that ASN to originate routes for the prefix, thus enabling route origin spoofing. In this case, the injected ROA is considered to be in competition with any existing authorized ROAs for the specified prefix.
A-4.6.1 可以向发布点注入与 INR 持有者发布的绑定不同的 ROA。该操作可能会授权一个额外的 ASN 来公布指定的前缀，允许该 ASN 为该前缀创建路由，从而实现路由来源欺骗。在这种情况下，注入的 ROA 将被视为与指定前缀的任何现有授权 ROA 竞争。
A-4.6.2 An injected ROA might express a different prefix for an ASN already authorized to originate a route, e.g., a longer prefix, which could enable that ASN to override other advertisements using shorter prefixes. If there are other ROAs that authorize different ASNs to advertise routes to the injected ROA's prefix, then the injected ROA is in competition with these ROAs.
A-4.6.2 被注入的 ROA 可能会为已被授权发起路由的 ASN 表达不同的前缀，如较长的前缀，这可能会使该 ASN 覆盖其他使用较短前缀的广告。如果有其他 ROA 授权不同的 ASN 为注入 ROA 的前缀发布路由广告，那么注入的 ROA 就会与这些 ROA 竞争。
The Ghostbusters Record [RFC6493] is a signed object that may be included at a publication point, at the discretion of the INR holder or publication point operator. The record is validated according to [RFC6488]. Additionally, the syntax of the record is verified based on the vCard profile from Section 5 of [RFC6493]. Errors in this record do not affect RP processing. However, if an RP encounters a problem with objects at a publication point, the RP may use information from the record to contact the publication point operator.
幽灵记录[RFC6493]是一个签名对象，可由 INR 持有人或发布点操作员自行决定是否将其包含在发布点中。该记录根据 [RFC6488] 进行验证。此外，该记录的语法是根据 [RFC6493] 第 5 节中的 vCard 配置文件验证的。该记录中的错误不会影响 RP 处理。但是，如果 RP 在发布点遇到对象问题，RP 可以使用记录中的信息联系发布点操作员。
Adverse actions against a Ghostbusters Record can cause the following error:
对《捉鬼敢死队记录》的不利操作会导致以下错误：
A-5.1 Deletion, suppression, corruption, or revocation of a Ghostbusters Record could prevent an RP from contacting the appropriate entity when a problem is detected by the RP. Modification or injection of a Ghostbusters Record could cause an RP to contact the wrong entity, thus delaying remediation of a detected anomaly. All of these actions are viewed as equivalent from an RP processing perspective; they do not alter RP validation of ROAs or router certificates. However, these actions can interfere with remediation of a problem when detected by an RP.
A-5.1 当注册管理员发现问题时，删除、压制、损坏或撤销 "魔鬼克星记录 "可能会阻止注册管理员与适当的实体联系。修改或注入 "魔鬼克星记录 "可能会导致 RP 联系错误的实体，从而延误对检测到的异常的修复。从 RP 处理的角度看，所有这些操作都是等价的；它们不会改变 RP 对 ROA 或路由器证书的验证。但是，当 RP 检测到问题时，这些操作可能会干扰问题的修复。
Router certificates are used by RPs to verify signatures on BGPsec_PATH attributes carried in UPDATE messages.
RP 使用路由器证书来验证 UPDATE 消息中携带的 BGPsec_PATH 属性上的签名。
Each AS is free to determine the granularity at which router certificates are managed [RFC8209]. Each participating AS is represented by one or more router certificates. During key or algorithm rollover, multiple router certificates will be present in a publication point, even if the AS is normally represented by just one such certificate.
每个 AS 可自由决定管理路由器证书的粒度 [RFC8209]。每个参与的 AS 由一个或多个路由器证书代表。在密钥或算法滚动期间，即使 AS 通常只由一个路由器证书代表，发布点中也会出现多个路由器证书。
Adverse actions against router certificates can cause the following errors:
对路由器证书的不利操作会导致以下错误：
A-6.1 Deletion
A-6.1 删除
A-6.1.1 Deletion of a router certificate would cause an RP to be unable to verify signatures applied to BGPsec_PATH attributes on behalf of the AS in question. In turn, this would cause the route to be treated with lower preference than competing routes that have valid BGPsec_PATH attribute signatures. (However, if another router certificate for the affected AS is valid and contains the same AS number and public key, and it is in use by that AS, there would be no effect on routing. This scenario will arise if a router certificate is renewed, i.e., issued with a new validity interval.)
A-6.1.1 删除路由器证书会导致 RP 无法验证代表相关 AS 应用于 BGPsec_PATH 属性的签名。反过来，这将导致路由的优先级低于具有有效 BGPsec_PATH 属性签名的竞争路由。(但是，如果受影响 AS 的另一个路由器证书是有效的，并包含相同的 AS 编号和公开密钥，而且该 AS 正在使用该证书，则不会对路由产生任何影响）。如果路由器证书被更新，即以新的有效期间隔签发，就会出现这种情况）。
A-6.2 Suppression
A-6.2 抑制
A-6.2.1 Suppression of a router certificate could have the same impact as deletion of a certificate of this type, i.e., if no router certificate was available, BGPsec attributes that should be verified using the certificate would fail validation. If an older certificate existed and has not expired, it would be used by RPs. If the older certificate contained a different ASN, the impact would be the same as in A-6.4.
A-6.2.1 禁止路由器证书可能会产生与删除此类证书相同的影响，即如果没有路由器证书，应使用证书验证的 BGPsec 属性将无法验证。如果存在旧证书且未过期，则 RP 将使用该证书。如果旧证书包含不同的 ASN，其影响与 A-6.4 中的相同。
A-6.3 Corruption
A-6.3 腐败
A-6.3.1 Corruption of a router certificate will result in the certificate being rejected by RPs. Absent a valid router certificate, BGPsec_PATH attributes associated with that certificate will be unverifiable. In turn, this would cause the route to be treated with lower preference than competing routes that have valid BGPsec_PATH attribute signatures.
A-6.3.1 损坏路由器证书将导致证书被 RP 拒绝。如果没有有效的路由器证书，与该证书相关的 BGPsec_PATH 属性将无法验证。反过来，这将导致路由的优先级低于具有有效 BGPsec_PATH 属性签名的竞争路由。
A-6.4 Modification
A-6.4 修改
A-6.4.1 If a router certificate is modified to represent a different ASN, but it still passes syntax checks, then this action could cause signatures on BGPsec_PATH attributes to be associated with the wrong AS. This could cause signed routes to be inconsistent with the intent of the INR holder, e.g., traffic might be routed via a different AS than intended.
A-6.4.1 如果路由器证书被修改为代表不同的 ASN，但仍通过语法检查，那么此操作可能导致 BGPsec_PATH 属性上的签名与错误的 AS 关联。这可能导致签署的路由与 INR 持有者的意图不一致，例如，流量可能会通过与预期不同的 AS 路由。
A-6.5 Revocation
A-6.5 撤销
A-6.5.1 If a router certificate were revoked, BGPsec_PATH attributes verifiable using that certificate would no longer be considered valid. The impact would be the same as for a deleted certificate, as described in A-6.1.
A-6.5.1 如果路由器证书被撤销，使用该证书验证的 BGPsec_PATH 属性将不再被视为有效。其影响与 A-6.1 中所述的删除证书的影响相同。
A-6.6 Injection
A-6.6 喷射
A-6.6.1 Insertion of a router certificate could authorize additional routers to sign BGPsec traffic for the targeted ASN, and thus undermine fundamental BGPsec security guarantees. If there are existing, authorized router certificates for the same ASN, then the injected router certificate is in competition with these existing certificates.
A-6.6.1 插入路由器证书可能会授权其他路由器签署目标 ASN 的 BGPsec 流量，从而破坏基本的 BGPsec 安全保证。如果同一 ASN 现有授权路由器证书，则注入的路由器证书将与这些现有证书竞争。
This section examines the types of problems that can arise in four scenarios described below. We consider mistakes, (successful) attacks against a CA or a publication point, and situations in which a CA or publication point manager is compelled to take action by a law enforcement authority.
本节将探讨在下述四种情况下可能出现的问题类型。我们考虑了错误、对 CA 或发布点的攻击（成功）以及 CA 或发布点管理者被执法机构强制采取行动的情况。
We explore the following four scenarios:
我们探讨了以下四种情况：
A. An INR holder operates its own CA and manages its own repository publication point.
A.INR 持有者运行自己的 CA 并管理自己的存储库发布点。
B. An INR holder operates its own CA, but outsources management of its repository publication point to its parent or another entity.
B.INR 持有者运营自己的 CA，但将其存储库公布点的管理外包给其母公司或其他实体。
C. An INR holder outsources management of its CA to its parent, but manages its own repository publication point.
C.INR 持有者将其 CA 的管理外包给母公司，但管理自己的存储库发布点。
D. An INR holder outsources management of its CA and its publication point to its parent.
D.INR 持有者将其 CA 及其发布点的管理外包给母公司。
Note that these scenarios focus on the affected INR holder as the party directly affected by an adverse action. The most serious cases arise when the INR holder appears as a high-tier CA in the RPKI hierarchy; in such situations, subordinate INR holders may be affected as a result of an action. A mistake by or an attack against a "leaf" has more limited impact because all of the affected INRs belong to the INR holder itself.
请注意，这些情况的重点是受影响的 INR 持有人，即受不利行动直接影响的一方。当 INR 持有者在 RPKI 层次结构中作为高级 CA 出现时，就会出现最严重的情况；在这种情况下，下级 INR 持有者可能会受到行动的影响。对 "叶子 "的错误或攻击所造成的影响较为有限，因为所有受影响的 INR 都属于 INR 持有者本身。
In Scenario A, actions by the INR holder can adversely affect all of its resources and, transitively, resources of any subordinate CAs. (If the CA is a "leaf" in the RPKI, then it has no subordinate CAs and the damage is limited to its own INRs.)
在方案 A 中，INR 持有者的行为会对其所有资源造成不利影响，并对任何下级 CA 的资源造成不利影响（如果 CA 是 RPKI 中的 "叶"，则没有下级 CA，损害仅限于其自身的 INR。(如果 CA 是 RPKI 中的 "叶子"，则它没有下级 CA，损害仅限于它自己的 INR）。
In Scenario B, actions by the (outsourced) repository operator can also adversely affect the resources of the INR holder and those of any subordinates CAs. (If the CA is a "leaf" in the RPKI, then it has no subordinate CAs and the damage is limited, as in Scenario A.) The range of adverse effects here includes those in Scenario A and adds a new potential source of adverse actions, i.e., the outsourced repository operator.
在情景 B 中，（外包）存储库操作员的行为也会对 INR 持有者的资源和任何下属 CA 的资源造成不利影响（如果 CA 是 RPKI 中的 "叶子"，则它没有下属 CA，损失有限，如情景 A）。(如果 CA 是 RPKI 中的 "叶子"，则它没有下级 CA，损害是有限的，如情景 A。）这里的不利影响范围包括情景 A 中的不利影响，并增加了一个新的不利行动潜在来源，即外包储存库运营商。
In Scenario C, all signed objects associated with the INR holder are generated by the parent CA but are self-hosted. (We expect this scenario to be rare, because an INR holder that elects to outsource CA operation seems unlikely to manage its own repository publication point.) Because that CA has the private key used to sign them, it can generate alternative signed objects -- ones not authorized by the INR holder. However, erroneous objects created by the parent CA will not be published by the INR holder IF the holder checks them first. Because the parent CA is acting on behalf of the INR holder, mistakes by or attacks against that entity are equivalent to ones effected by the INR holder in Scenario A.
在方案 C 中，与 INR 持有者相关的所有签名对象都由父 CA 生成，但都是自托管的。(我们预计这种情况很少见，因为选择外包 CA 操作的 INR 持有者似乎不太可能管理自己的存储库发布点）。由于该 CA 拥有用于签名的私钥，它可以生成替代签名对象--未经 INR 持有者授权的对象。但是，如果 INR 持有者首先检查了父 CA 创建的错误对象，那么 INR 持有者就不会发布这些对象。由于父 CA 代表 INR 持有者行事，因此该实体所犯的错误或受到的攻击等同于方案 A 中 INR 持有者所犯的错误或受到的攻击。
The INR holder is most vulnerable in Scenario D. Actions by the parent CA, acting on behalf of the INR holder, can adversely affect all signed objects associated with that INR holder, including any subordinate CA certificates. These actions will presumably translate directly into publication point changes because the parent CA is managing the publication point for the INR holder. The range of adverse effects here includes those in Scenarios A, B, and C.
父 CA 代表 INR 持有者采取的行动会对与 INR 持有者相关的所有签名对象（包括任何下属 CA 证书）产生不利影响。这些行为可能会直接转化为发布点的变化，因为父 CA 正在为 INR 持有者管理发布点。这里的不利影响范围包括方案 A、B 和 C 中的影响。
In this scenario, the INR holder acts as its own CA and it manages its own publication point. Actions by the INR holder can adversely affect all of its resources and, transitively, resources of any subordinate CAs. (If the CA is a "leaf" in the RPKI, then it has no subordinate CAs and the damage is limited to its own INRs.) Mistakes by the INR holder can cause any of the actions noted in Section 2. A successful attack against this CA can effect all of the modification, revocation, or injection actions noted in that section. (We assume that objects generated by the CA are automatically published). An attack against the publication point can effect all of the deletion, suppression, or corruption actions noted in that section.
在这种情况下，INR 持有者充当自己的 CA，管理自己的发布点。INR 持有者的行为会对其所有资源造成负面影响，并对任何下属 CA 的资源造成负面影响。(如果 CA 是 RPKI 中的 "叶子"，则它没有下级 CA，损害仅限于它自己的 INR）。INR 持有者的错误可能导致第 2 节中提到的任何行动。对该 CA 的成功攻击可导致该节所述的所有修改、撤销或注入操作。(我们假设 CA 生成的对象会自动发布）。对发布点的攻击可导致该节所述的所有删除、抑制或破坏行为。
In this scenario, the INR holder acts as its own CA but it delegates management of it own publication point to a third party. Mistakes by the INR holder can cause any of the modification, revocation, or injection actions described in Section 2. Actions by the repository operator can adversely affect the resources of the INR holder, and those of any subordinate CAs. (If the CA is a "leaf" in the RPKI, then it has no subordinate CAs and the damage is limited, as in Scenario A.) The range of adverse effects here includes those in Scenario A, and adds a new potential source of adverse actions, i.e., the third party repository operator. A successful attack against the CA can effect all of the modification, revocation, or injection actions noted in that section (assuming that objects generated by the CA are automatically published). Here, actions by the publication point manager (or attacks against that entity) can effect all of the deletion, suppression, or corruption actions noted in Section 2.
在这种情况下，INR 持有者充当自己的 CA，但委托第三方管理自己的发布点。INR 持有者的错误可能导致第 2 节所述的任何修改、撤销或注入操作。存储库操作员的行为会对 INR 持有者以及任何下属 CA 的资源产生不利影响。(如果 CA 是 RPKI 中的 "叶子"，则它没有下级 CA，损害有限，如方案 A。）这里的不利影响范围包括方案 A 中的影响，并增加了一个新的潜在不利影响源，即第三方存储库操作员。对 CA 的成功攻击可导致该部分所述的所有修改、撤销或注入操作（假设 CA 生成的对象是自动发布的）。在此，发布点管理器的操作（或针对该实体的攻击）可影响第 2 节中提到的所有删除、抑制或损坏操作。
In this scenario, the INR holder outsources management of its CA to its parent, but manages its own repository publication point. All signed objects associated with the INR holder are generated by the parent CA but are self-hosted. (We expect this scenario to be rare, because an INR holder that elects to outsource CA operation seems unlikely to manage its own repository publication point.) Because that CA has the private key used to sign them, it can generate alternative signed objects -- ones not authorized by the INR holder. However, erroneous objects created by the parent CA will not be published by the INR holder IF the holder checks them first. Because the parent CA is acting on behalf of the INR holder, mistakes by or attacks against that entity are equivalent to ones effected by the INR holder in Scenario A. Mistakes by the INR holder, acted upon by the parent CA, can cause any of the actions noted in Section 2. Actions unilaterally undertaken by the parent CA also can have the same effect, unless the INR holder checks the signed objects before publishing them. A successful attack against the parent CA can effect all of the modification, revocation, or injection actions noted in Section 2, unless the INR holder checks the signed objects before publishing them. An attack against the INR holder (in its role as repository operator) can effect all of the deletion, suppression, or corruption actions noted in Section 2 (because the INR holder is managing its publication point), unless the INR holder checks the signed objects before publishing them. (An attack against the INR holder implies that the path it uses to direct the parent CA to issue and publish objects has been compromised.)
在这种情况下，INR 持有者将其 CA 的管理外包给父 CA，但管理自己的存储库发布点。与 INR 持有者相关的所有签名对象都由父 CA 生成，但都是自托管的。(我们预计这种情况很少见，因为选择外包 CA 运行的 INR 持有者似乎不太可能管理自己的存储库发布点）。由于该 CA 拥有用于签名的私钥，它可以生成替代签名对象--未经 INR 持有者授权的对象。但是，如果 INR 持有者首先检查了父 CA 创建的错误对象，那么 INR 持有者就不会发布这些对象。由于父 CA 代表 INR 持有者行事，因此该实体所犯的错误或受到的攻击等同于方案 A 中 INR 持有者所犯的错误。除非 INR 持有者在发布已签名对象之前对其进行检查，否则父 CA 单方面采取的行动也会产生同样的效果。除非 INR 持有者在发布已签名对象前对其进行检查，否则对父 CA 的成功攻击可导致第 2 节所述的所有修改、撤销或注入操作。对 INR 持有者（作为存储库操作员）的攻击可导致第 2 节中提到的所有删除、抑制或损坏操作（因为 INR 持有者正在管理其发布点），除非 INR 持有者在发布已签名对象之前对其进行检查。(针对 INR 持有者的攻击意味着它用来指导父 CA 发布和公布对象的路径已被破坏）。
In this scenario, an INR holder outsources management of both its CA and its publication point to its parent. The INR holder is most vulnerable in this scenario. Actions by the parent CA, acting on behalf of the INR holder, can adversely affect all signed objects associated with that INR holder, including any subordinate CA certificates. These actions will presumably translate directly into publication point changes, because the parent CA is managing the publication point for the INR holder. The range of adverse effects here includes those in Scenarios A, B, and C. Mistakes by the INR holder, acted upon by the parent CA, can cause any of the actions noted in Section 2. Actions unilaterally undertaken by the parent CA also can have the same effect. A successful attack against the parent CA can effect all of the modification, revocation, or injection actions noted in Section 2. An attack against the parent CA can also effect all of the deletion, suppression, or corruption actions noted in Section 2 (because the parent CA is managing the INR holder's publication point).
在这种情况下，INR 持有者将其 CA 及其发布点的管理外包给其母公司。在这种情况下，INR 持有者最容易受到攻击。父 CA 代表 INR 持有者采取的行动会对与 INR 持有者相关的所有签名对象（包括任何下属 CA 证书）产生不利影响。这些行为可能会直接转化为发布点变化，因为父 CA 正在管理 INR 持有者的发布点。这里的不利影响范围包括方案 A、B 和 C 中的影响。INR 持有者的错误经上级 CA 执行后，可能导致第 2 节中提到的任何行动。母 CA 单方面采取的行动也会产生同样的影响。对父 CA 的成功攻击可导致第 2 节所述的所有修改、撤销或注入操作。对父 CA 的攻击也会影响第 2 节中提到的所有删除、抑制或破坏行为（因为父 CA 正在管理 INR 持有者的发布点）。
This informational document describes a threat model for the RPKI, focusing on mistakes by or attacks against CAs and independent repository managers. It is intended to provide a basis for the design of future RPKI security mechanisms that seek to address the concerns associated with such actions.
本资料性文件描述了 RPKI 的威胁模型，重点是 CA 和独立存储库管理者的错误或攻击。其目的是为设计未来的 RPKI 安全机制提供基础，以解决与此类行为相关的问题。
The analysis in this document identifies a number of circumstances in which attacks or errors can have significant impacts on routing. One ought not interpret this as a condemnation of the RPKI. It is only an attempt to document the implications of a wide range of attacks and errors in the context of the RPKI. The primary alternative mechanism for disseminating routing information is Internet Routing Registry (IRR) technology [RFC2650] [RFC2725], which uses the Routing Policy Specification Language (RPSL) [RFC2622]. IRR technology exhibits its own set of security problems, which are discussed in [RFC7682].
本文件的分析指出了一些攻击或错误可能对路由产生重大影响的情况。我们不应将此理解为对 RPKI 的谴责。本文只是试图记录各种攻击和错误对 RPKI 的影响。传播路由信息的主要替代机制是互联网路由注册（IRR）技术[RFC2650] [RFC2725]，它使用路由策略规范语言（RPSL）[RFC2622]。IRR 技术本身存在一系列安全问题，[RFC7682] 对此进行了讨论。
This document does not require any IANA actions.
本文件无需 IANA 采取任何行动。
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, DOI 10.17487/RFC3779, June 2004, <https://www.rfc-editor.org/info/rfc3779>.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, DOI 10.17487/RFC3779, June 2004, <https://www.rfc-editor.org/info/rfc3779>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <https://www.rfc-editor.org/info/rfc6480>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <https://www.rfc-editor.org/info/rfc6480>。
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, <https://www.rfc-editor.org/info/rfc6481>.
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, <https://www.rfc-editor.org/info/rfc6481>。
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, <https://www.rfc-editor.org/info/rfc6482>.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, <https://www.rfc-editor.org/info/rfc6482>。
[RFC6483] Huston, G. and G. Michaelson, "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012, <https://www.rfc-editor.org/info/rfc6483>.
[RFC6483] Huston, G. and G. Michaelson, "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012, <https://www.rfc-editor.org/info/rfc6483>。
[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, <https://www.rfc-editor.org/info/rfc6486>.
[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, <https://www.rfc-editor.org/info/rfc6486>。
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, <https://www.rfc-editor.org/info/rfc6487>.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, <https://www.rfc-editor.org/info/rfc6487>。
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, <https://www.rfc-editor.org/info/rfc6488>.
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, <https://www.rfc-editor.org/info/rfc6488>。
[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)", BCP 174, RFC 6489, DOI 10.17487/RFC6489, February 2012, <https://www.rfc-editor.org/info/rfc6489>.
[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)", BCP 174, RFC 6489, DOI 10.17487/RFC6489, February 2012, <https://www.rfc-editor.org/info/rfc6489>。
[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, February 2012, <https://www.rfc-editor.org/info/rfc6493>.
[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, February 2012, <https://www.rfc-editor.org/info/rfc6493>。
[RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 2013, <https://www.rfc-editor.org/info/rfc6916>.
[RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 2013, <https://www.rfc-editor.org/info/rfc6916>。
[RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, August 2016, <https://www.rfc-editor.org/info/rfc7935>.
[RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, August 2016, <https://www.rfc-editor.org/info/rfc7935>。
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, <https://www.rfc-editor.org/info/rfc8205>.
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, <https://www.rfc-editor.org/info/rfc8205>。
[RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests", RFC 8209, DOI 10.17487/RFC8209, September 2017, <https://www.rfc-editor.org/info/rfc8209>.
[RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests", RFC 8209, DOI 10.17487/RFC8209, September 2017, <https://www.rfc-editor.org/info/rfc8209>。
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, DOI 10.17487/RFC2622, June 1999, <https://www.rfc-editor.org/info/rfc2622>.
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, DOI 10.17487/RFC2622, June 1999, <https://www.rfc-editor.org/info/rfc2622>.
[RFC2650] Meyer, D., Schmitz, J., Orange, C., Prior, M., and C. Alaettinoglu, "Using RPSL in Practice", RFC 2650, DOI 10.17487/RFC2650, August 1999, <https://www.rfc-editor.org/info/rfc2650>.
[RFC2650] Meyer, D., Schmitz, J., Orange, C., Prior, M., and C. Alaettinoglu, "Using RPSL in Practice", RFC 2650, DOI 10.17487/RFC2650, August 1999, <https://www.rfc-editor.org/info/rfc2650>.
[RFC2725] Villamizar, C., Alaettinoglu, C., Meyer, D., and S. Murphy, "Routing Policy System Security", RFC 2725, DOI 10.17487/RFC2725, December 1999, <https://www.rfc-editor.org/info/rfc2725>.
[RFC2725] Villamizar, C., Alaettinoglu, C., Meyer, D., and S. Murphy, "Routing Policy System Security", RFC 2725, DOI 10.17487/RFC2725, December 1999, <https://www.rfc-editor.org/info/rfc2725>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>。
[RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", RFC 7132, DOI 10.17487/RFC7132, February 2014, <https://www.rfc-editor.org/info/rfc7132>.
[RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", RFC 7132, DOI 10.17487/RFC7132, February 2014, <https://www.rfc-editor.org/info/rfc7132>。
[RFC7682] McPherson, D., Amante, S., Osterweil, E., Blunk, L., and D. Mitchell, "Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration", RFC 7682, DOI 10.17487/RFC7682, December 2015, <https://www.rfc-editor.org/info/rfc7682>.
[RFC7682] McPherson, D., Amante, S., Osterweil, E., Blunk, L., and D. Mitchell, "Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration", RFC 7682, DOI 10.17487/RFC7682, December 2015, <https://www.rfc-editor.org/info/rfc7682>。
Acknowledgements
致谢
The authors thank Richard Hansen and David Mandelberg for their extensive review, feedback, and editorial assistance. Thanks also go to Daiming Li for her editorial assistance.
作者感谢理查德-汉森（Richard Hansen）和大卫-曼德尔伯格（David Mandelberg）的大量审稿、反馈和编辑协助。同时也感谢 Daiming Li 的编辑协助。
Authors' Addresses
作者地址
Stephen Kent BBN Technologies 10 Moulton St Cambridge, MA 02138-1119 United States of America
Stephen Kent BBN Technologies 10 Moulton St Cambridge, MA 02138-1119 美利坚合众国
Email: [email protected]
Di Ma ZDNS 4 South 4th St. Zhongguancun Haidian, Beijing 100190 China
Di Ma ZDNS 北京市海淀区中关村南四街 4 号 邮政编码 100190 中国
Email: [email protected]