Internet Engineering Task Force (IETF) Y. Gilad
Request for Comments: 9319 Hebrew University of Jerusalem
BCP: 185 S. Goldberg
Category: Best Current Practice Boston University
ISSN: 2070-1721 K. Sriram
USA NIST
J. Snijders
Fastly
B. Maddison
Workonline Communications
October 2022
The Use of maxLength in the Resource Public Key Infrastructure (RPKI)
资源公钥基础架构 (RPKI) 中 maxLength 的使用
Abstract
摘要
This document recommends ways to reduce the forged-origin hijack attack surface by prudently limiting the set of IP prefixes that are included in a Route Origin Authorization (ROA). One recommendation is to avoid using the maxLength attribute in ROAs except in some specific cases. The recommendations complement and extend those in RFC 7115. This document also discusses the creation of ROAs for facilitating the use of Distributed Denial of Service (DDoS) mitigation services. Considerations related to ROAs and RPKI-based Route Origin Validation (RPKI-ROV) in the context of destination-based Remotely Triggered Discard Route (RTDR) (elsewhere referred to as "Remotely Triggered Black Hole") filtering are also highlighted.
本文档推荐了通过谨慎限制路由起源授权（ROA）中包含的 IP 前缀集来减少伪造起源劫持攻击面的方法。其中一项建议是，除某些特殊情况外，避免在 ROA 中使用 maxLength 属性。这些建议补充并扩展了 RFC 7115 中的建议。本文档还讨论了创建 ROA 以促进分布式拒绝服务 (DDoS) 缓解服务的使用。还强调了在基于目的地的远程触发丢弃路由 (RTDR)（在其他地方称为 "远程触发黑洞"）过滤中与 ROA 和基于 RPKI 的路由起源验证 (RPKI-ROV) 相关的注意事项。
Status of This Memo
本备忘录的地位
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网当前最佳做法。
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 BCPs is available in Section 2 of RFC 7841.
本文件是互联网工程任务组 (IETF) 的成果。它代表了 IETF 社区的共识。它已接受公众审查，并经互联网工程指导小组 (IESG) 批准发布。有关 BCP 的更多信息，请参阅 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/rfc9319.
有关本文件的当前状态、任何勘误以及如何提供反馈的信息，请访问 https://www.rfc-editor.org/info/rfc9319。
Copyright Notice
版权声明
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2022 IETF Trust 和文件作者。保留所有权利。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
本文档受 BCP 78 和本文档发布之日有效的 IETF 信托基金《与 IETF 文档有关的法律规定》 (https://trustee.ietf.org/license-info) 的约束。请仔细阅读这些文件，因为它们描述了您对本文档的权利和限制。从本文档中提取的代码组件必须包含信托法律条款第 4.e 节所述的修订版 BSD 许可文本，并且不提供修订版 BSD 许可中所述的担保。
Table of Contents
目录
1. Introduction
1.1. Requirements
1.2. Documentation Prefixes
2. Suggested Reading
3. Forged-Origin Sub-Prefix Hijack
4. Measurements of the RPKI
5. Recommendations about Minimal ROAs and maxLength
5.1. Facilitating Ad Hoc Routing Changes and DDoS Mitigation
5.2. Defensive De-aggregation in Response to Prefix Hijacks
6. Considerations for RTDR Filtering Scenarios
7. User Interface Design Recommendations
8. Operational Considerations
9. Security Considerations
10. IANA Considerations
11. References
11.1. Normative References
11.2. Informative References
Acknowledgments
Authors' Addresses
The Resource Public Key Infrastructure (RPKI) [RFC6480] uses Route Origin Authorizations (ROAs) to create a cryptographically verifiable mapping from an IP prefix to a set of Autonomous Systems (ASes) that are authorized to originate that prefix. Each ROA contains a set of IP prefixes and the AS number of one of the ASes authorized to originate all the IP prefixes in the set [RFC6482]. The ROA is cryptographically signed by the party that holds a certificate for the set of IP prefixes.
资源公钥基础设施（RPKI）[RFC6480] 使用路由起源授权（ROA）创建一个可加密验证的映射，从 IP 前缀到一组被授权起源该前缀的自治系统（AS）。每个 ROA 都包含一组 IP 前缀和其中一个被授权发端该组 IP 前缀的 AS 的 AS 号 [RFC6482]。ROA 由持有 IP 前缀集证书的一方加密签名。
The ROA format also supports a maxLength attribute. According to [RFC6482], "When present, the maxLength specifies the maximum length of the IP address prefix that the AS is authorized to advertise." Thus, rather than requiring the ROA to list each prefix that the AS is authorized to originate, the maxLength attribute provides a shorthand that authorizes an AS to originate a set of IP prefixes.
ROA 格式还支持 maxLength 属性。根据 [RFC6482]，"当存在时，maxLength 指定 AS 被授权宣传的 IP 地址前缀的最大长度"。因此，maxLength 属性并不要求 ROA 列出 AS 被授权发起的每个前缀，而是提供了一个授权 AS 发起一组 IP 前缀的快捷方式。
However, measurements of RPKI deployments have found that the use of the maxLength attribute in ROAs tends to lead to security problems. In particular, measurements taken in June 2017 showed that of the prefixes specified in ROAs that use the maxLength attribute, 84% were vulnerable to a forged-origin sub-prefix hijack [GSG17]. The forged-origin prefix or sub-prefix hijack involves inserting the legitimate AS as specified in the ROA as the origin AS in the AS_PATH; the hijack can be launched against any IP prefix/sub-prefix that has a ROA. Consider a prefix/sub-prefix that has a ROA that is unused (i.e., not announced in BGP by a legitimate AS). A forged-origin hijack involving such a prefix/sub-prefix can propagate widely throughout the Internet. On the other hand, if the prefix/sub-prefix were announced by the legitimate AS, then the propagation of the forged-origin hijack is somewhat limited because of its increased AS_PATH length relative to the legitimate announcement. Of course, forged-origin hijacks are harmful in both cases, but the extent of harm is greater for unannounced prefixes. See Section 3 for detailed discussion.
然而，对 RPKI 部署的测量发现，在 ROA 中使用 maxLength 属性往往会导致安全问题。特别是，2017 年 6 月进行的测量显示，在使用 maxLength 属性的 ROA 中指定的前缀中，有 84% 容易受到伪造的源子前缀劫持 [GSG17]。伪造原生前缀或子前缀劫持包括在 AS_PATH 中插入 ROA 中指定的合法 AS 作为原生 AS；这种劫持可以针对任何具有 ROA 的 IP 前缀/子前缀发起。考虑一个具有未使用 ROA 的前缀/子前缀（即未由合法 AS 在 BGP 中公布）。涉及此类前缀/子前缀的伪造原点劫持会在整个互联网上广泛传播。另一方面，如果该前缀/子前缀是由合法 AS 公布的，那么伪造原点劫持的传播范围就会受到一定限制，因为相对于合法公布的前缀/子前缀，伪造原点劫持的 AS_PATH 长度会增加。当然，伪造源劫持在这两种情况下都是有害的，但对于未宣布的前缀来说，危害程度更大。详细讨论见第 3 节。
For this reason, this document recommends that, whenever possible, operators SHOULD use "minimal ROAs" that authorize only those IP prefixes that are actually originated in BGP, and no other prefixes. Further, it recommends ways to reduce the forged-origin attack surface by prudently limiting the address space that is included in ROAs. One recommendation is to avoid using the maxLength attribute in ROAs except in some specific cases. The recommendations complement and extend those in [RFC7115]. The document also discusses the creation of ROAs for facilitating the use of DDoS mitigation services. Considerations related to ROAs and RPKI-ROV in the context of destination-based Remotely Triggered Discard Route (RTDR) (elsewhere referred to as "Remotely Triggered Black Hole") filtering are also highlighted.
因此，本文档建议运营商应尽可能使用 "最小 ROA"，即只授权那些实际源自 BGP 的 IP 前缀，而不授权其他前缀。此外，它还推荐了通过谨慎限制 ROA 中包含的地址空间来减少伪造源攻击面的方法。其中一项建议是避免在 ROAs 中使用 maxLength 属性，某些特殊情况除外。这些建议补充并扩展了 [RFC7115] 中的建议。本文档还讨论了如何创建 ROA 以促进 DDoS 缓解服务的使用。还强调了在基于目的地的远程触发丢弃路由 (RTDR)（在其他地方称为 "远程触发黑洞"）过滤中与 ROA 和 RPKI-ROV 相关的注意事项。
Please note that the term "RPKI-based Route Origin Validation" and the corresponding acronym "RPKI-ROV" that are used in this document mean the same as the term "Prefix Origin Validation" used in [RFC6811].
请注意，本文档中使用的术语 "基于 RPKI 的路由起源验证 "和相应的缩写词 "RPKI-ROV "与 [RFC6811] 中使用的术语 "前缀起源验证 "含义相同。
One ideal place to implement the ROA-related recommendations is in the user interfaces for configuring ROAs. Recommendations for implementors of such user interfaces are provided in Section 7.
实施 ROA 相关建议的一个理想场所是配置 ROA 的用户界面。第 7 节提供了对此类用户界面实施者的建议。
The practices described in this document require no changes to the RPKI specifications and will not increase the number of signed ROAs in the RPKI because ROAs already support lists of IP prefixes [RFC6482].
本文档中描述的做法无需修改 RPKI 规范，也不会增加 RPKI 中已签名 ROA 的数量，因为 ROA 已经支持 IP 前缀列表 [RFC6482]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 以及 "OPTIONAL" 应按照BCP 14 [RFC2119] [RFC8174]中描述的一样，当且仅当它们以全大写形式出现时进行解释。
The documentation prefixes recommended in [RFC5737] are insufficient for use as example prefixes in this document. Therefore, this document uses the address space defined in [RFC1918] for constructing example prefixes.
RFC5737] 中推荐的文档前缀不足以用作本文档中的示例前缀。因此，本文档使用 [RFC1918] 中定义的地址空间来构建示例前缀。
Note that although the examples in this document are presented using IPv4 prefixes, all the analysis thereof and the recommendations made are equally valid for the equivalent IPv6 cases.
请注意，尽管本文档中的示例使用的是 IPv4 前缀，但其中的所有分析和建议同样适用于同等的 IPv6 情况。
It is assumed that the reader understands BGP [RFC4271], RPKI [RFC6480], ROAs [RFC6482], RPKI-ROV [RFC6811], and BGPsec [RFC8205].
假定读者了解 BGP [RFC4271]、RPKI [RFC6480]、ROAs [RFC6482]、RPKI-ROV [RFC6811] 和 BGPsec [RFC8205]。
A detailed description and discussion of forged-origin sub-prefix hijacks are presented here, especially considering the case when the sub-prefix is not announced in BGP. The forged-origin sub-prefix hijack is relevant to a scenario in which:
本文详细介绍并讨论了伪造原生子前缀劫持，特别是考虑到子前缀未在 BGP 中公布的情况。伪造原生子前缀劫持与以下情况有关：
(1) the RPKI [RFC6480] is deployed, and
(1) 部署 RPKI [RFC6480]，以及
(2) routers use RPKI-ROV to drop invalid routes [RFC6811], but
(2) 路由器使用 RPKI-ROV 来放弃无效路由 [RFC6811]，但
(3) BGPsec [RFC8205] (or any similar method to validate the truthfulness of the BGP AS_PATH attribute) is not deployed.
(3) 未部署 BGPsec [RFC8205]（或任何验证 BGP AS_PATH 属性真实性的类似方法）。
Note that this set of assumptions accurately describes a substantial and growing number of large Internet networks at the time of writing.
请注意，在撰写本报告时，这组假设准确地描述了数量可观且不断增长的大型互联网网络。
The forged-origin sub-prefix hijack [RFC7115] [GCHSS] is described here using a running example.
这里用一个运行示例来描述伪造的原生子前缀劫持 [RFC7115] [GCHSS]。
Consider the IP prefix 192.168.0.0/16, which is allocated to an organization that also operates AS 64496. In BGP, AS 64496 originates the IP prefix 192.168.0.0/16 as well as its sub-prefix 192.168.225.0/24. Therefore, the RPKI should contain a ROA authorizing AS 64496 to originate these two IP prefixes.
考虑将 IP 前缀 192.168.0.0/16 分配给同时运行 AS 64496 的组织。在 BGP 中，AS 64496 发起 IP 前缀 192.168.0.0/16 及其子前缀 192.168.225.0/24。因此，RPKI 应包含授权 AS 64496 发起这两个 IP 前缀的 ROA。
Suppose, however, the organization issues and publishes a ROA including a maxLength value of 24:
但是，假设该组织发布了 ROA，其中的 maxLength 值为 24：
ROA:(192.168.0.0/16-24, AS 64496)
ROA:(192.168.0.0/16-24, as 64496)
We refer to the above as a "loose ROA" since it authorizes AS 64496 to originate any sub-prefix of 192.168.0.0/16 up to and including length /24, rather than only those prefixes that are intended to be announced in BGP.
我们将上述内容称为 "宽松 ROA"，因为它授权 AS 64496 发端 192.168.0.0/16 的任何子前缀，长度不超过并包括 /24，而不仅仅是那些打算在 BGP 中公布的前缀。
Because AS 64496 only originates two prefixes in BGP (192.168.0.0/16 and 192.168.225.0/24), all other prefixes authorized by the loose ROA (for instance, 192.168.0.0/24) are vulnerable to the following forged-origin sub-prefix hijack [RFC7115] [GCHSS]:
由于 AS 64496 在 BGP 中只发起了两个前缀（192.168.0.0/16 和 192.168.225.0/24），因此经松散 ROA 授权的所有其他前缀（例如 192.168.0.0/24）都容易受到以下伪造-发起子前缀劫持 [RFC7115] [GCHSS]：
The hijacker AS 64511 sends a BGP announcement "192.168.0.0/24: AS 64511, AS 64496", falsely claiming that AS 64511 is a neighbor of AS 64496 and that AS 64496 originates the IP prefix 192.168.0.0/24. In fact, the IP prefix 192.168.0.0/24 is not originated by AS 64496.
劫持者 AS 64511 发送 BGP 公告 "192.168.0.0/24: AS 64511, AS 64496"，谎称 AS 64511 是 AS 64496 的邻居，AS 64496 起源于 IP 前缀 192.168.0.0/24。事实上，IP 前缀 192.168.0.0/24 并非由 AS 64496 发起。
The hijacker's BGP announcement is valid according to the RPKI since the ROA (192.168.0.0/16-24, AS 64496) authorizes AS 64496 to originate BGP routes for 192.168.0.0/24.
根据 RPKI，劫持者的 BGP 公告是有效的，因为 ROA（192.168.0.0/16-24，AS 64496）授权 AS 64496 为 192.168.0.0/24 发起 BGP 路由。
Because AS 64496 does not actually originate a route for 192.168.0.0/24, the hijacker's route is the only route for 192.168.0.0/24. Longest-prefix-match routing ensures that the hijacker's route to the sub-prefix 192.168.0.0/24 is always preferred over the legitimate route to 192.168.0.0/16 originated by AS 64496.
由于 AS 64496 实际上没有为 192.168.0.0/24 发起路由，因此劫持者的路由是 192.168.0.0/24 的唯一路由。最长前缀匹配路由可确保劫持者指向子前缀 192.168.0.0/24 的路由始终优先于 AS 64496 指向 192.168.0.0/16 的合法路由。
Thus, the hijacker's route propagates through the Internet, and traffic destined for IP addresses in 192.168.0.0/24 will be delivered to the hijacker.
这样，劫持者的路由就会在互联网上传播，指向 192.168.0.0/24 IP 地址的流量就会被传送到劫持者那里。
The forged-origin sub-prefix hijack would have failed if a minimal ROA as described in Section 5 was used instead of the loose ROA. In this example, a minimal ROA would be:
如果使用第 5 节所述的最小 ROA 而不是松散 ROA，伪造源代码子前缀劫持就会失败。在本例中，最小的 ROA 应该是
ROA:(192.168.0.0/16, 192.168.225.0/24, AS 64496)
ROA:(192.168.0.0/16, 192.168.225.0/24, as 64496)
This ROA is "minimal" because it includes only those IP prefixes that AS 64496 originates in BGP, but no other IP prefixes [RFC6907].
该 ROA 是 "最小 "的，因为它只包括 AS 64496 在 BGP 中发起的 IP 前缀，而不包括其他 IP 前缀 [RFC6907]。
The minimal ROA renders AS 64511's BGP announcement invalid because:
最小 ROA 使 AS 64511 的 BGP 公告无效，因为
(1) this ROA "covers" the attacker's announcement (since 192.168.0.0/24 is a sub-prefix of 192.168.0.0/16), and
(1) 该 ROA "覆盖 "了攻击者的公告（因为 192.168.0.0/24 是 192.168.0.0/16 的子前缀），并且
(2) there is no ROA "matching" the attacker's announcement (there is no ROA for AS 64511 and IP prefix 192.168.0.0/24) [RFC6811].
(2) 没有 "匹配 "攻击者公告的 ROA（AS 64511 和 IP 前缀 192.168.0.0/24 没有 ROA）[RFC6811]。
If routers ignore invalid BGP announcements, the minimal ROA above ensures that the sub-prefix hijack will fail.
如果路由器忽略无效的 BGP 公告，上述最小 ROA 就能确保子前缀劫持失败。
Thus, if a minimal ROA had been used, the attacker would be forced to launch a forged-origin prefix hijack in order to attract traffic as follows:
因此，如果使用的是最小 ROA，攻击者将不得不发起伪造源前缀劫持，以吸引如下流量：
The hijacker AS 64511 sends a BGP announcement "192.168.0.0/16: AS 64511, AS 64496", falsely claiming that AS 64511 is a neighbor of AS 64496.
劫持者 AS 64511 发送 BGP 公告 "192.168.0.0/16: AS 64511, AS 64496"，谎称 AS 64511 是 AS 64496 的邻居。
This forged-origin prefix hijack is significantly less damaging than the forged-origin sub-prefix hijack:
这种伪造来源前缀劫持的破坏性要比伪造来源子前缀劫持小得多：
AS 64496 legitimately originates 192.168.0.0/16 in BGP, so the hijacker AS 64511 is not presenting the only route to 192.168.0.0/16.
AS 64496 在 BGP 中合法发源于 192.168.0.0/16，因此劫持者 AS 64511 并未展示通往 192.168.0.0/16 的唯一路由。
Moreover, the path originated by AS 64511 is one hop longer than the path originated by the legitimate origin AS 64496.
此外，由 AS 64511 发起的路径比由合法发起方 AS 64496 发起的路径长一跳。
As discussed in [LSG16], this means that the hijacker will attract less traffic than it would have in the forged-origin sub-prefix hijack where the hijacker presents the only route to the hijacked sub-prefix.
如 [LSG16] 所述，这意味着劫持者吸引的流量将少于伪造源子前缀劫持时的流量，因为在伪造源子前缀劫持时，劫持者提供了通往被劫持子前缀的唯一路由。
In summary, a forged-origin sub-prefix hijack has the same impact as a regular sub-prefix hijack, despite the increased AS_PATH length of the illegitimate route. A forged-origin sub-prefix hijack is also more damaging than the forged-origin prefix hijack.
总之，尽管非法路由的 AS_PATH 长度增加了，但伪造的起始子前缀劫持与普通子前缀劫持的影响相同。伪造的起始子前缀劫持也比伪造的起始前缀劫持更具破坏性。
Network measurements taken in June 2017 showed that 12% of the IP prefixes authorized in ROAs have a maxLength value longer than their prefix length. Of these, the vast majority (84%) were non-minimal, as they included sub-prefixes that are not announced in BGP by the legitimate AS and were thus vulnerable to forged-origin sub-prefix hijacks. See [GSG17] for details.
2017 年 6 月进行的网络测量显示，在 ROA 中授权的 IP 前缀中，有 12% 的 maxLength 值大于其前缀长度。其中，绝大多数（84%）都是非最小前缀，因为它们包含了合法 AS 未在 BGP 中公布的子前缀，因此很容易受到伪造原生子前缀劫持的攻击。详见 [GSG17]。
These measurements suggest that operators commonly misconfigure the maxLength attribute and unwittingly open themselves up to forged-origin sub-prefix hijacks. That is, they are exposing a much larger attack surface for forged-origin hijacks than necessary.
这些测量结果表明，操作员通常会错误配置 maxLength 属性，并在不知情的情况下将自己暴露在伪造的原属子前缀劫持面前。也就是说，他们暴露的伪造源代码劫持攻击面比必要的要大得多。
Operators SHOULD use minimal ROAs whenever possible. A minimal ROA contains only those IP prefixes that are actually originated by an AS in BGP and no other IP prefixes. See Section 3 for an example.
运营商应尽可能使用最小 ROA。最小 ROA 仅包含 BGP 中实际由 AS 发起的 IP 前缀，不包含其他 IP 前缀。有关示例，请参见第 3 节。
In general, operators SHOULD avoid using the maxLength attribute in their ROAs, since its inclusion will usually make the ROA non-minimal.
一般来说，操作员应避免在其 ROA 中使用 maxLength 属性，因为包含该属性通常会使 ROA 变得非最小。
One such exception may be when all more specific prefixes permitted by the maxLength value are actually announced by the AS in the ROA. Another exception is where: (a) the maxLength value is substantially larger compared to the specified prefix length in the ROA, and (b) a large number of more specific prefixes in that range are announced by the AS in the ROA. In practice, this case should occur rarely (if at all). Operator discretion is necessary in this case.
其中一个例外情况可能是，AS 在 ROA 中实际公布了 maxLength 值允许的所有更具体的前缀。另一种例外情况是(a) maxLength 值远远大于 ROA 中指定的前缀长度，以及 (b) ROA 中的 AS 宣布了该范围内大量更具体的前缀。实际上，这种情况很少发生（如果有的话）。在这种情况下，运营商有必要谨慎处理。
This practice requires no changes to the RPKI specifications and need not increase the number of signed ROAs in the RPKI because ROAs already support lists of IP prefixes [RFC6482]. See [GSG17] for further discussion of why this practice will have minimal impact on the performance of the RPKI ecosystem.
这种做法无需修改 RPKI 规范，也无需增加 RPKI 中已签名 ROA 的数量，因为 ROA 已经支持 IP 前缀列表 [RFC6482]。请参阅 [GSG17]，进一步讨论为什么这种做法对 RPKI 生态系统的性能影响最小。
Operators that implement these recommendations and have existing ROAs published in the RPKI system MUST perform a review of such objects, especially where they make use of the maxLength attribute, to ensure that the set of included prefixes is "minimal" with respect to the current BGP origination and routing policies. Published ROAs MUST be replaced as necessary. Such an exercise MUST be repeated whenever the operator makes changes to either policy.
实施这些建议并在 RPKI 系统中发布了现有 ROA 的运营商必须对此类对象（尤其是使用 maxLength 属性的对象）进行审查，以确保所包含的前缀集是当前 BGP 起源和路由策略的 "最小 "前缀集。必要时必须替换已发布的 ROA。每当运营商对任一策略进行更改时，都必须重复上述操作。
Operational requirements may require that a route for an IP prefix be originated on an ad hoc basis, with little or no prior warning. An example of such a situation arises when an operator wishes to make use of DDoS mitigation services that use BGP to redirect traffic via a "scrubbing center".
业务需求可能要求在几乎没有或根本没有事先警告的情况下临时为 IP 前缀创建路由。这种情况的一个例子是，运营商希望使用 DDoS 缓解服务，利用 BGP 通过 "清洗中心 "重定向流量。
In order to ensure that such ad hoc routing changes are effective, a ROA validating the new route should exist. However, a difficulty arises due to the fact that newly created objects in the RPKI are made visible to relying parties considerably more slowly than routing updates in BGP.
为了确保这种临时路由更改的有效性，应该存在一个验证新路由的 ROA。然而，由于 RPKI 中新建对象对依赖方的可见度比 BGP 中的路由更新慢得多，因此出现了一个难题。
Ideally, it would not be necessary to pre-create the ROA, which validates the ad hoc route, and instead create it "on the fly" as required. However, this is practical only if the latency imposed by the propagation of RPKI data is guaranteed to be within acceptable limits in the circumstances. For time-critical interventions such as responding to a DDoS attack, this is unlikely to be the case.
理想情况下，无需预先创建验证临时路由的 ROA，而是根据需要 "即时 "创建。不过，这只有在 RPKI 数据传播造成的延迟保证在可接受范围内的情况下才可行。对于时间紧迫的干预，如应对 DDoS 攻击，这种情况不太可能发生。
Thus, the ROA in question will usually need to be created well in advance of the routing intervention, but such a ROA will be non-minimal, since it includes an IP prefix that is sometimes (but not always) originated in BGP.
因此，有关 ROA 通常需要在路由干预之前创建，但这种 ROA 将是非最小的，因为它包括一个有时（但不总是）源自 BGP 的 IP 前缀。
In this case, the ROA SHOULD only include:
在这种情况下，ROA 只应包括：
(1) the set of IP prefixes that are always originated in BGP, and
(1) 总是源自 BGP 的 IP 前缀集，以及
(2) the set of IP prefixes that are sometimes, but not always, originated in BGP.
(2) 有时（但不总是）源自 BGP 的 IP 前缀集。
The ROA SHOULD NOT include any IP prefixes that the operator knows will not be originated in BGP. In general, the ROA SHOULD NOT make use of the maxLength attribute unless doing so has no impact on the set of included prefixes.
ROA 不应包含运营商已知不会在 BGP 中发端的任何 IP 前缀。一般来说，ROA 不应使用 maxLength 属性，除非这样做对所包含的前缀集没有影响。
The running example is now extended to illustrate one situation where it is not possible to issue a minimal ROA.
现在扩展一下运行示例，以说明不可能发布最低 ROA 的一种情况。
Consider the following scenario prior to the deployment of RPKI. Suppose AS 64496 announced 192.168.0.0/16 and has a contract with a DDoS mitigation service provider that holds AS 64500. Further, assume that the DDoS mitigation service contract applies to all IP addresses covered by 192.168.0.0/22. When a DDoS attack is detected and reported by AS 64496, AS 64500 immediately originates 192.168.0.0/22, thus attracting all the DDoS traffic to itself. The traffic is scrubbed at AS 64500 and then sent back to AS 64496 over a backhaul link. Notice that, during a DDoS attack, the DDoS mitigation service provider AS 64500 originates a /22 prefix that is longer than AS 64496's /16 prefix, so all the traffic (destined to addresses in 192.168.0.0/22) that normally goes to AS 64496 goes to AS 64500 instead. In some deployments, the origination of the /22 route is performed by AS 64496 and announced only to AS 64500, which then announces transit for that prefix. This variation does not change the properties considered here.
在部署 RPKI 之前，请考虑以下情况。假设 AS 64496 公布了 192.168.0.0/16，并与持有 AS 64500 的 DDoS 缓解服务提供商签订了合同。此外，假设 DDoS 缓解服务合同适用于 192.168.0.0/22 覆盖的所有 IP 地址。当 AS 64496 检测到并报告 DDoS 攻击时，AS 64500 立即从 192.168.0.0/22 发起攻击，从而将所有 DDoS 流量吸引到自身。这些流量在 AS 64500 处被清除，然后通过回程链路发送回 AS 64496。请注意，在 DDoS 攻击期间，DDoS 缓解服务提供商 AS 64500 产生的 /22 前缀比 AS 64496 的 /16 前缀长，因此，通常流向 AS 64496 的所有流量（指向 192.168.0.0/22 中的地址）都会流向 AS 64500。在某些部署中，/22 路由的发起由 AS 64496 执行，并只向 AS 64500 宣布，然后由 AS 64500 宣布该前缀的转接。这种变化不会改变此处考虑的属性。
First, suppose the RPKI only had the minimal ROA for AS 64496, as described in Section 3. However, if there is no ROA authorizing AS 64500 to announce the /22 prefix, then the DDoS mitigation (and traffic scrubbing) scheme would not work. That is, if AS 64500 originates the /22 prefix in BGP during DDoS attacks, the announcement would be invalid [RFC6811].
首先，假设 RPKI 只有 AS 64496 的最小 ROA，如第 3 节所述。但是，如果没有授权 AS 64500 公告 /22 前缀的 ROA，那么 DDoS 缓解（和流量擦除）方案将不起作用。也就是说，如果 AS 64500 在 DDoS 攻击期间在 BGP 中发布 /22 前缀，则该公告将无效 [RFC6811]。
Therefore, the RPKI should have two ROAs: one for AS 64496 and one for AS 64500.
因此，RPKI 应有两个 ROA：一个用于 AS 64496，一个用于 AS 64500。
ROA:(192.168.0.0/16, 192.168.225.0/24, AS 64496)
ROA:(192.168.0.0/16, 192.168.225.0/24, as 64496)
ROA:(192.168.0.0/22, AS 64500)
ROA:(192.168.0.0/22, as 64500)
Neither ROA uses the maxLength attribute, but the second ROA is not "minimal" because it contains a /22 prefix that is not originated by anyone in BGP during normal operations. The /22 prefix is only originated by AS 64500 as part of its DDoS mitigation service during a DDoS attack.
两个 ROA 均未使用 maxLength 属性，但第二个 ROA 并非 "最小"，因为它包含一个 /22 前缀，在正常运行期间，BGP 中的任何人都不会使用该前缀。只有 AS 64500 才会在 DDoS 攻击期间作为其 DDoS 缓解服务的一部分发起 /22 前缀。
Notice, however, that this scheme does not come without risks. Namely, all IP addresses in 192.168.0.0/22 are vulnerable to a forged-origin sub-prefix hijack during normal operations when the /22 prefix is not originated. (The hijacker AS 64511 would send the BGP announcement "192.168.0.0/22: AS 64511, AS 64500", falsely claiming that AS 64511 is a neighbor of AS 64500 and falsely claiming that AS 64500 originates 192.168.0.0/22.)
但请注意，这种方案并非没有风险。也就是说，192.168.0.0/22 中的所有 IP 地址在正常运行时都很容易受到伪造发源子前缀的劫持，因为 /22 前缀不是发源的。(劫持者 AS 64511 将发送 BGP 公告 "192.168.0.0/22: AS 64511, AS 64500"，谎称 AS 64511 是 AS 64500 的邻居，并谎称 AS 64500 起源于 192.168.0.0/22）。
In some situations, the DDoS mitigation service at AS 64500 might want to limit the amount of DDoS traffic that it attracts and scrubs. Suppose that a DDoS attack only targets IP addresses in 192.168.0.0/24. Then, the DDoS mitigation service at AS 64500 only wants to attract the traffic designated for the /24 prefix that is under attack, but not the entire /22 prefix. To allow for this, the RPKI should have two ROAs: one for AS 64496 and one for AS 64500.
在某些情况下，AS 64500 的 DDoS 缓解服务可能希望限制其吸引和清除的 DDoS 流量。假设 DDoS 攻击只针对 192.168.0.0/24 中的 IP 地址。那么，AS 64500 的 DDoS 缓解服务只想吸引指定给受攻击的 /24 前缀的流量，而不想吸引整个 /22 前缀的流量。为此，RPKI 应具有两个 ROA：一个用于 AS 64496，另一个用于 AS 64500。
ROA:(192.168.0.0/16, 192.168.225.0/24, AS 64496)
ROA:(192.168.0.0/16, 192.168.225.0/24, as 64496)
ROA:(192.168.0.0/22-24, AS 64500)
区域网络：（192.168.0.0/22-24，作为 64500）
The second ROA uses the maxLength attribute because it is designed to explicitly enable AS 64500 to originate any /24 sub-prefix of 192.168.0.0/22.
第二个 ROA 使用 maxLength 属性，因为它旨在明确允许 AS 64500 发端 192.168.0.0/22 的任何 /24 子前缀。
As before, the second ROA is not "minimal" because it contains prefixes that are not originated by anyone in BGP during normal operations. Also, all IP addresses in 192.168.0.0/22 are vulnerable to a forged-origin sub-prefix hijack during normal operations when the /22 prefix is not originated.
如前所述，第二个 ROA 并非 "最小"，因为它包含的前缀在正常运行期间并非由 BGP 中的任何人发起。此外，当 /22 前缀不是由 BGP 发起时，192.168.0.0/22 中的所有 IP 地址在正常运行时都容易受到伪造发起子前缀劫持的攻击。
The use of the maxLength attribute in this second ROA also comes with additional risk. While it permits the DDoS mitigation service at AS 64500 to originate prefix 192.168.0.0/24 during a DDoS attack in that space, it also makes the other /24 prefixes covered by the /22 prefix (i.e., 192.168.1.0/24, 192.168.2.0/24, and 192.168.3.0/24) vulnerable to forged-origin sub-prefix attacks.
在第二个 ROA 中使用 maxLength 属性还会带来额外风险。虽然它允许 AS 64500 的 DDoS 缓解服务在该空间的 DDoS 攻击中以 192.168.0.0/24 为前缀，但它也使 /22 前缀所覆盖的其他 /24 前缀（即 192.168.1.0/24、192.168.2.0/24 和 192.168.3.0/24）容易受到伪造原点子前缀攻击。
When responding to certain classes of prefix hijack (in particular, the forged-origin sub-prefix hijack described above), it may be desirable for the victim to perform "defensive de-aggregation", i.e., to begin originating more-specific prefixes in order to compete with the hijack routes for selection as the best path in networks that are not performing RPKI-ROV [RFC6811].
在应对某些类别的前缀劫持（特别是上述伪造起始子前缀劫持）时，受害者可能需要执行 "防御性去聚合"，即开始起始更具体的前缀，以便与劫持路由竞争，在不执行 RPKI-ROV [RFC6811] 的网络中被选为最佳路径。
In topologies where at least one AS on every path between the victim and hijacker filters RPKI-ROV invalid prefixes, it may be the case that the existence of a minimal ROA issued by the victim prevents the defensive more-specific prefixes from being propagated to the networks topologically close to the attacker, thus hampering the effectiveness of this response.
在受害者和劫持者之间的每条路径上都至少有一个 AS 过滤 RPKI-ROV 无效前缀的拓扑结构中，可能会出现这样的情况，即受害者发布的最小 ROA 的存在会阻止防御性更强的特定前缀传播到拓扑结构上靠近攻击者的网络，从而影响这种响应的有效性。
Nevertheless, this document recommends that, where possible, network operators publish minimal ROAs even in the face of this risk. This is because:
尽管如此，本文件还是建议网络运营商在可能的情况下，即使面临这种风险，也要公布最低的 ROA。这是因为
* Minimal ROAs offer the best possible protection against the immediate impact of such an attack, rendering the need for such a response less likely;
* 最低限度的 ROA 可以提供最佳保护，防止此类攻击的直接影响，从而降低采取此类应对措施的可能性；
* Increasing RPKI-ROV adoption by network operators will, over time, decrease the size of the neighborhoods in which this risk exists; and
* 随着时间的推移，网络运营商越来越多地采用 RPKI-ROV 技术，将缩小存在这种风险的邻区范围；以及
* Other methods for reducing the size of such neighborhoods are available to potential victims, such as establishing direct External BGP (EBGP) adjacencies with networks from whom the defensive routes would otherwise be hidden.
* 潜在受害者还可以采用其他方法来缩小此类邻域的规模，例如与网络建立直接的外部 BGP（EBGP）邻接关系，否则防御路由就会被隐藏起来。
Considerations related to ROAs and RPKI-ROV [RFC6811] for the case of destination-based RTDR (elsewhere referred to as "Remotely Triggered Black Hole") filtering are addressed here. In RTDR filtering, highly specific prefixes (greater than /24 in IPv4 and greater than /48 in IPv6, or possibly even /32 in IPv4 and /128 in IPv6) are announced in BGP. These announcements are tagged with the well-known BGP community defined by [RFC7999]. For the reasons set out above, it is obviously not desirable to use a large maxLength value or include any such highly specific prefixes in the ROAs to accommodate destination-based RTDR filtering.
这里讨论的是基于目的地的 RTDR（其他地方称为 "远程触发黑洞"）过滤情况下与 ROA 和 RPKI-ROV [RFC6811] 相关的考虑因素。在 RTDR 过滤中，高度特定的前缀（在 IPv4 中大于/24，在 IPv6 中大于/48，甚至可能在 IPv4 中大于/32，在 IPv6 中大于/128）会在 BGP 中公布。这些公告使用[RFC7999]定义的著名 BGP 社区进行标记。由于上述原因，使用较大的 maxLength 值或在 ROA 中包含任何此类高度特定的前缀来适应基于目的地的 RTDR 过滤显然是不可取的。
As a result, RPKI-ROV [RFC6811] is a poor fit for the validation of RTDR routes. Specification of new procedures to address this use case through the use of the RPKI is outside the scope of this document.
因此，RPKI-ROV [RFC6811] 并不适合 RTDR 路由的验证。通过使用 RPKI 来解决此用例的新程序规范不属于本文档的范围。
Therefore:
因此
* Operators SHOULD NOT create non-minimal ROAs (by either creating additional ROAs or using the maxLength attribute) for the purpose of advertising RTDR routes; and
* 运营商不应（通过创建附加 ROA 或使用 maxLength 属性）创建非最小 ROA，以宣传 RTDR 路由；以及
* Operators providing a means for operators of neighboring autonomous systems to advertise RTDR routes via BGP MUST NOT make the creation of non-minimal ROAs a pre-requisite for its use.
* 为相邻自治系统操作员提供通过 BGP 公告 RTDR 路由的方法的操作员不得将创建非最小 ROA 作为使用该方法的前提条件。
Most operator interaction with the RPKI system when creating or modifying ROAs will occur via a user interface that abstracts the underlying encoding, signing, and publishing operations.
在创建或修改 ROA 时，操作员与 RPKI 系统的大部分交互都将通过一个用户界面进行，该界面抽象了底层编码、签名和发布操作。
This document recommends that designers and/or providers of such user interfaces SHOULD provide warnings to draw the user's attention to the risks of creating non-minimal ROAs in general and using the maxLength attribute in particular.
本文档建议，此类用户界面的设计者和/或提供者应提供警告，提醒用户注意创建非最小 ROA 的风险，特别是使用 maxLength 属性的风险。
Warnings provided by such a system may vary in nature from generic warnings based purely on the inclusion of the maxLength attribute to customised guidance based on the observable BGP routing policy of the operator in question. The choices made in this respect are expected to be dependent on the target user audience of the implementation.
此类系统提供的警告在性质上可能各不相同，既有纯粹基于 maxLength 属性的通用警告，也有基于相关运营商可观察到的 BGP 路由策略的定制指导。这方面的选择预计将取决于实施的目标用户群。
The recommendations specified in this document (in particular, those in Section 5) involve trade-offs between operational agility and security.
本文件提出的建议（特别是第 5 节中的建议）涉及操作灵活性和安全性之间的权衡。
Operators adopting the recommended practice of issuing minimal ROAs will, by definition, need to make changes to their existing set of issued ROAs in order to effect changes to the set of prefixes that are originated in BGP.
根据定义，采用所建议的签发最小 ROA 的做法的运营商需要对其现有的已签发 ROA 进行更改，以便对 BGP 起源的前缀集进行更改。
Even in the case of routing changes that are planned in advance, existing procedures may need to be updated to incorporate changes to issued ROAs and may require additional time allowed for those changes to propagate.
即使是事先计划好的路由变更，也可能需要更新现有程序，以纳入对已发布的 ROA 的变更，并可能需要额外的时间来传播这些变更。
Operators are encouraged to carefully review the issues highlighted (especially those in Sections 5.1 and 5.2) in light of their specific operational requirements. Failure to do so could, in the worst case, result in a self-inflicted denial of service.
我们鼓励操作员根据自己的具体操作要求，仔细审查所强调的问题（尤其是第 5.1 和 5.2 节中的问题）。否则，在最坏的情况下，可能会导致自我造成的拒绝服务。
The recommendations made in Section 5 are likely to be more onerous for operators utilising large IP address space allocations from which many more-specific advertisements are made in BGP. Operators of such networks are encouraged to seek opportunities to automate the required procedures in order to minimise manual operational burden.
第 5 节中提出的建议对于使用大型 IP 地址空间分配的运营商来说可能更为繁琐，因为 BGP 中的许多特定广告都是从大型 IP 地址空间分配的。我们鼓励这类网络的运营商寻找机会实现所需程序的自动化，以尽量减轻人工操作负担。
This document makes recommendations regarding the use of RPKI-ROV as defined in [RFC6811] and, as such, introduces no additional security considerations beyond those specified therein.
本文件就 [RFC6811] 中定义的 RPKI-ROV 的使用提出了建议，因此除了其中规定的安全考虑因素外，没有引入其他安全考虑因素。
This document has no IANA actions.
本文件没有 IANA 操作。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.
[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>。
[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>。
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, <https://www.rfc-editor.org/info/rfc6811>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, <https://www.rfc-editor.org/info/rfc6811>。
[RFC7115] Bush, R., "Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)", BCP 185, RFC 7115, DOI 10.17487/RFC7115, January 2014, <https://www.rfc-editor.org/info/rfc7115>.
[RFC7115] Bush, R., "Origin Validation Operation Based on Resource Public Key Infrastructure (RPKI)", BCP 185, RFC 7115, DOI 10.17487/RFC7115, January 2014, <https://www.rfc-editor.org/info/rfc7115>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>。
[GCHSS] Gilad, Y., Cohen, A., Herzberg, A., Schapira, M., and H. Shulman, "Are We There Yet? On RPKI's Deployment and Security", NDSS 2017, February 2017, <https://eprint.iacr.org/2016/1010.pdf>.
[GCHSS] Gilad, Y., Cohen, A., Herzberg, A., Schapira, M., and H. Shulman, "Are We There Yet?关于 RPKI 的部署和安全性"，NDSS 2017，2017 年 2 月，<https://eprint.iacr.org/2016/1010.pdf>。
[GSG17] Gilad, Y., Sagga, O., and S. Goldberg, "MaxLength Considered Harmful to the RPKI", CoNEXT '17, DOI 10.1145/3143361.3143363, December 2017, <https://eprint.iacr.org/2016/1015.pdf>.
[GSG17] Gilad, Y., Sagga, O., and S. Goldberg, "MaxLength Considered Harmful to the RPKI", CoNEXT '17, DOI 10.1145/3143361.3143363, December 2017, <https://eprint.iacr.org/2016/1015.pdf>。
[LSG16] Lychev, R., Shapira, M., and S. Goldberg, "Rethinking security for internet routing", Communications of the ACM, DOI 10.1145/2896817, October 2016, <http://cacm.acm.org/ magazines/2016/10/207763-rethinking-security-for-internet-routing/>.
[LSG16] Lychev, R., Shapira, M., and S. Goldberg, "Rethinking security for internet routing", Communications of the ACM, DOI 10.1145/2896817, October 2016, <http://cacm.acm.org/ magazines/2016/10/207763-rethinking-security-for-internet-routing/>.
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, DOI 10.17487/RFC5737, January 2010, <https://www.rfc-editor.org/info/rfc5737>.
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, DOI 10.17487/RFC5737, January 2010, <https://www.rfc-editor.org/info/rfc5737>。
[RFC6907] Manderson, T., Sriram, K., and R. White, "Use Cases and Interpretations of Resource Public Key Infrastructure (RPKI) Objects for Issuers and Relying Parties", RFC 6907, DOI 10.17487/RFC6907, March 2013, <https://www.rfc-editor.org/info/rfc6907>.
[RFC6907] Manderson, T., Sriram, K., and R. White, "Use Cases and Interpretations of Resource Public Key Infrastructure (RPKI) Objects for Issuers and Relying Parties", RFC 6907, DOI 10.17487/RFC6907, March 2013, <https://www.rfc-editor.org/info/rfc6907>。
[RFC7999] King, T., Dietzel, C., Snijders, J., Doering, G., and G. Hankins, "BLACKHOLE Community", RFC 7999, DOI 10.17487/RFC7999, October 2016, <https://www.rfc-editor.org/info/rfc7999>.
[RFC7999] King, T., Dietzel, C., Snijders, J., Doering, G., and G. Hankins, "BLACKHOLE Community", RFC 7999, DOI 10.17487/RFC7999, October 2016, <https://www.rfc-editor.org/info/rfc7999>。
[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>。
Acknowledgments
致谢
The authors would like to thank the following people for their review and contributions to this document: Omar Sagga and Aris Lambrianidis. Thanks are also due to Matthias Waehlisch, Ties de Kock, Amreesh Phokeer, ric Vyncke, Alvaro Retana, John Scudder, Roman Danyliw, Andrew Alston, and Murray Kucherawy for comments and suggestions, to Roni Even for the Gen-ART review, to Jean Mahoney for the ART-ART review, to Acee Lindem for the Routing Area Directorate review, and to Sean Turner for the Security Area Directorate review.
作者感谢以下人员对本文件的审阅和贡献：Omar Sagga 和 Aris Lambrianidis。此外，还要感谢 Matthias Waehlisch、Ties de Kock、Amreesh Phokeer、ric Vyncke、Alvaro Retana、John Scudder、Roman Danyliw、Andrew Alston 和 Murray Kucherawy 提出的意见和建议，感谢 Roni Even 对 Gen-ART 的审核，感谢 Jean Mahoney 对 ART-ART 的审核，感谢 Acee Lindem 对路由区域局的审核，感谢 Sean Turner 对安全区域局的审核。
Authors' Addresses
作者地址
Yossi Gilad Hebrew University of Jerusalem Rothburg Family Buildings Edmond J. Safra Campus Jerusalem 9190416 Israel Email: [email protected]
Yossi Gilad 耶路撒冷希伯来大学 罗斯堡家族大楼 Edmond J. Safra 校区 耶路撒冷 9190416 以色列 电子邮件：[email protected]
Sharon Goldberg Boston University 111 Cummington St, MCS135 Boston, MA 02215 United States of America Email: [email protected]
Sharon Goldberg Boston University 111 Cummington St, MCS135 Boston, MA 02215 United States of America Email: [email protected]
Kotikalapudi Sriram USA National Institute of Standards and Technology 100 Bureau Drive Gaithersburg, MD 20899 United States of America Email: [email protected]
Kotikalapudi Sriram 美国国家标准与技术研究院 100 Bureau Drive Gaithersburg, MD 20899 United States of America Email: [email protected]
Job Snijders Fastly Amsterdam Netherlands Email: [email protected]
Job Snijders Fastly 阿姆斯特丹 荷兰 电子邮件：[email protected]
Ben Maddison Workonline Communications 114 West St Johannesburg 2196 South Africa Email: [email protected]
Ben Maddison Workonline Communications 114 West St Johannesburg 2196 South Africa Email: [email protected]