RFC 8481 - Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI) 中文翻译

原文URL : https://datatracker.ietf.org/doc/html/rfc8481
文档标题 : RFC 8481 - 对基于资源公钥基础架构 (RPKI) 的 BGP 起源验证的澄清
翻译方式 : 自动生成

Internet Engineering Task Force (IETF)                           R. Bush
Request for Comments: 8481                     Internet Initiative Japan
Updates: 6811                                             September 2018
Category: Standards Track
ISSN: 2070-1721

Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI)

对基于资源公钥基础架构 (RPKI) 的 BGP 起源验证的澄清

Abstract

摘要

Deployment of BGP origin validation based on Resource Public Key Infrastructure (RPKI) is hampered by, among other things, vendor misimplementations in two critical areas: which routes are validated and whether policy is applied when not specified by configuration. This document is meant to clarify possible misunderstandings causing those misimplementations; it thus updates RFC 6811 by clarifying that all prefixes should have their validation state set and that policy must not be applied without operator configuration.

基于资源公钥基础设施（RPKI）的 BGP 起源验证的部署受阻于供应商在两个关键领域的错误实施：验证哪些路由以及在配置未指定时是否应用策略。本文档旨在澄清导致这些错误实施的可能误解；因此，它更新了 RFC 6811，明确了所有前缀都应设置其验证状态，以及在没有操作员配置的情况下不得应用策略。

Status of This Memo

本备忘录的地位

This is an Internet Standards Track document.

这是一份互联网标准跟踪文件。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

本文件是互联网工程任务组 (IETF) 的成果。它代表了 IETF 社区的共识。它已接受公众审查，并经互联网工程指导小组 (IESG) 批准发布。有关互联网标准的更多信息，请参见 RFC 7841 第 2 节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8481.

有关本文件的当前状态、任何勘误以及如何提供反馈的信息，请访问 https://www.rfc-editor.org/info/rfc8481。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

本文档受BCP 78以及本文档发布之日有效的IETF信托基金关于IETF文档的法律规定（https://trustee.ietf.org/license-info）的约束。请仔细阅读这些文档，因为它们描述了您对本文档的权利和限制。从本文档中提取的代码组件必须包含信托法律条款第 4.e 节中描述的简化 BSD 许可证文本，并且不提供简化 BSD 许可证中描述的担保。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Suggested Reading . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Evaluate ALL Prefixes . . . . . . . . . . . . . . . . . . . .   3
   5.  Set State, Don't Act  . . . . . . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1. Introduction

1. 导言

Deployment of RPKI-based BGP origin validation is hampered by, among other things, vendor misimplementations in two critical areas: which routes are validated and whether policy is applied when not specified by configuration. This document is meant to clarify possible misunderstandings causing those misimplementations.

基于 RPKI 的 BGP 起源验证的部署受到供应商在以下两个关键领域的错误实施等因素的阻碍：验证哪些路由以及在配置未指定时是否应用策略。本文件旨在澄清导致这些错误实施的可能误解。

When a route is distributed into BGP, the origin validation state is set to NotFound, Valid, or Invalid per [RFC6811]. Operational testing has shown that the specifications of that RFC were not sufficient to avoid divergent implementations. This document attempts to clarify two areas which seem to cause confusion.

当路由被分发到 BGP 时，根据 [RFC6811] 的规定，起源验证状态被设置为 NotFound、Valid 或 Invalid。运行测试表明，该 RFC 的规范不足以避免不同的实现。本文件试图澄清似乎引起混淆的两个方面。

The implementation issues seem not to be about how to validate, i.e., how to decide if a route is NotFound, Valid, or Invalid. The issues seem to be which routes should be evaluated and have their evaluation state set, and whether to apply policy without operator configuration.

实施方面的问题似乎与如何验证无关，即如何确定路由是 NotFound、Valid 还是 Invalid。问题似乎在于哪些路由应该被评估并设置其评估状态，以及是否在没有操作员配置的情况下应用策略。

2. Requirements Language

2. 要求语言

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]中描述的一样，当且仅当它们以全大写形式出现时进行解释。

3. Suggested Reading

3. 推荐阅读

It is assumed that the reader understands BGP [RFC4271], the RPKI [RFC6480], Route Origin Authorizations (ROAs) [RFC6482], and RPKI-based Prefix Validation [RFC6811].

假定读者了解 BGP [RFC4271]、RPKI [RFC6480]、路由起源授权 (ROAs) [RFC6482] 和基于 RPKI 的前缀验证 [RFC6811]。

4. Evaluate ALL Prefixes

4. 评估所有前缀

Significant Clarification: A router MUST evaluate and set the validation state of all routes in BGP coming from any source (e.g., eBGP, iBGP, or redistribution from static or connected routes), unless specifically configured otherwise by the operator. Otherwise, the operator does not have the ability to drop Invalid routes coming from every potential source and is therefore liable to complaints from neighbors about propagation of Invalid routes. For this reason, [RFC6811] says:

重要说明：路由器必须对 BGP 中来自任何来源（如 eBGP、iBGP 或来自静态或连接路由的重新分配）的所有路由进行评估并设置验证状态，除非运营商另有特别配置。否则，运营商就没有能力丢弃来自每个潜在来源的无效路由，因此很容易受到邻居关于无效路由传播的投诉。为此，[RFC6811] 指出：

When a BGP speaker receives an UPDATE from a neighbor, it SHOULD perform a lookup as described above for each of the Routes in the UPDATE message. The lookup SHOULD also be applied to routes that are redistributed into BGP from another source, such as another protocol or a locally defined static route.

当 BGP 发言者从邻居接收到 UPDATE 时，它应针对 UPDATE 消息中的每条路由执行上述查找。查询也应适用于从其他来源（如其他协议或本地定义的静态路由）重新分配到 BGP 的路由。

[RFC6811] goes on to say, "An implementation MAY provide configuration options to control which routes the lookup is applied to."

[RFC6811]接着说："实施方案可以提供配置选项，以控制查询应用于哪些路由"。

When redistributing into BGP from any source (e.g., IGP, iBGP, or from static or connected routes), there is no AS_PATH in the input to allow RPKI validation of the originating Autonomous System (AS). In such cases, the router MUST use the AS of the router's BGP configuration. If that is ambiguous because of confederation, AS migration, or other multi-AS configuration, then the router configuration MUST provide a means of specifying the AS to be used on the redistribution, either per redistribution or globally.

当从任何来源（如 IGP、iBGP 或静态或连接路由）重新分配到 BGP 时，输入中没有 AS_PATH，因此无法对来源自治系统 (AS) 进行 RPKI 验证。在这种情况下，路由器必须使用路由器 BGP 配置中的 AS。如果由于邦联、AS 迁移或其他多 AS 配置而导致 AS 含糊不清，那么路由器配置必须提供一种方法来指定在每次重新分配或全局重新分配中使用的 AS。

5. Set State, Don't Act

5. 设定状态，不要行动

Significant Clarification: Once routes are evaluated and have their state set, the operator should be in complete control of any policy applied based on the evaluation state. Absent specific operator configuration, policy MUST NOT be applied.

重要说明：一旦路由经过评估并设定了状态，操作员应完全控制根据评估状态应用的任何策略。如果没有特定的操作员配置，则不得应用策略。

Automatic origin validation policy actions such as those described in "BGP Prefix Origin Validation State Extended Community" [RFC8097] MUST NOT be carried out or otherwise applied unless specifically configured by the operator.

除非操作员特别配置，否则不得执行或以其他方式应用自动起源验证策略操作，如 "BGP 前缀起源验证状态扩展社区"[RFC8097] 中描述的操作。

6. Security Considerations

6. 安全考虑因素

This document does not create security considerations beyond those of [RFC6811].

除 [RFC6811] 的安全考虑因素外，本文件不涉及其他安全考虑因素。

7. IANA Considerations

7. IANA考虑因素

This document has no IANA actions.

本文件没有 IANA 操作。

8. Normative References

8. 规范性文献

[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>.

[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>。

[RFC8097] Mohapatra, P., Patel, K., Scudder, J., Ward, D., and R. Bush, "BGP Prefix Origin Validation State Extended Community", RFC 8097, DOI 10.17487/RFC8097, March 2017, <https://www.rfc-editor.org/info/rfc8097>.

[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>。

Acknowledgments

致谢

Many thanks to John Scudder, who had the patience to give constructive review multiple times, and Keyur Patel, who noted that the AS might have to be specified. George Michaelson, Jay Borkenhagen, John Heasley, and Matthias Waehlisch kindly helped clean up loose wording.

非常感谢约翰-斯卡德（John Scudder），他耐心地多次提出了建设性意见；感谢凯尔-帕特尔（Keyur Patel），他指出 AS 可能需要具体说明。乔治-迈克尔逊（George Michaelson）、杰伊-博肯哈根（Jay Borkenhagen）、约翰-希斯利（John Heasley）和马蒂亚斯-瓦赫利什（Matthias Waehlisch）热心地帮助清理了松散的措辞。

Author's Address

作者地址

Randy Bush Internet Initiative Japan 5147 Crystal Springs Bainbridge Island, Washington 98110 United States of America

   Email: [email protected]