Internet Engineering Task Force (IETF) R. Bush
Request for Comments: 8481 Internet Initiative Japan
Updates: 6811 September 2018
Category: Standards Track
ISSN: 2070-1721
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源验证部署受到以下两个关键领域的供应商错误实施的阻碍：验证哪些路由，以及在配置未指定时是否应用策略。本文件旨在澄清导致这些错误实施的可能误解；因此，它更新了RFC6811，澄清了所有前缀都应设置其验证状态，并且在没有操作员配置的情况下，不得应用策略。
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.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . 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
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.
实现问题似乎不是关于如何验证，即如何确定路由是否未找到、有效或无效。问题似乎是应该评估哪些路由并设置其评估状态，以及是否在没有操作员配置的情况下应用策略。
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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
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]、路由来源授权（ROA）[RFC6482]和基于RPKI的前缀验证[RFC6811]。
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扬声器接收到来自邻居的更新时，它应该对更新消息中的每个路由执行如上所述的查找。查找还应应用于从另一个源（如另一个协议或本地定义的静态路由）重新分发到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_路径以允许对原始自治系统（AS）进行RPKI验证。在这种情况下，路由器必须使用路由器BGP配置的AS。如果由于联盟、AS迁移或其他多AS配置，这是不明确的，那么路由器配置必须提供一种方法，指定要在重新分发上使用的AS，无论是每次重新分发还是全局重新分发。
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]中所述。
This document does not create security considerations beyond those of [RFC6811].
除[RFC6811]的安全注意事项外，本文档不创建其他安全注意事项。
This document has no IANA actions.
本文档没有IANA操作。
[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.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<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.，和S.Hares，Ed.，“边境网关协议4（BGP-4）”，RFC 4271，DOI 10.17487/RFC4271，2006年1月<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.和S.Kent，“支持安全互联网路由的基础设施”，RFC 6480，DOI 10.17487/RFC6480，2012年2月<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.，和D.Kong，“路线原产地授权（ROA）的概要”，RFC 6482，DOI 10.17487/RFC6482，2012年2月<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.，和R.Austein，“BGP前缀来源验证”，RFC 6811，DOI 10.17487/RFC6811，2013年1月<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>.
[RFC8097]Mohapatra，P.，Patel，K.，Scudder，J.，Ward，D.，和R.Bush，“BGP前缀来源验证州扩展社区”，RFC 8097，DOI 10.17487/RFC8097，2017年3月<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.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<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可能需要具体说明。乔治·迈克尔森、杰伊·博肯哈根、约翰·希斯利和马蒂亚斯·韦利希亲切地帮助清理了松散的措辞。
Author's Address
作者地址
Randy Bush Internet Initiative Japan 5147 Crystal Springs Bainbridge Island, Washington 98110 United States of America
兰迪·布什互联网倡议日本5147水晶泉班布里奇岛，华盛顿98110美利坚合众国
Email: randy@psg.com
Email: randy@psg.com