Internet Engineering Task Force (IETF) P. Mohapatra
Request for Comments: 8097 Sproute Networks
Category: Standards Track K. Patel
ISSN: 2070-1721 Arrcus, Inc.
J. Scudder
Juniper Networks
D. Ward
Cisco
R. Bush
Internet Initiative Japan, Inc.
March 2017
Internet Engineering Task Force (IETF) P. Mohapatra
Request for Comments: 8097 Sproute Networks
Category: Standards Track K. Patel
ISSN: 2070-1721 Arrcus, Inc.
J. Scudder
Juniper Networks
D. Ward
Cisco
R. Bush
Internet Initiative Japan, Inc.
March 2017
BGP Prefix Origin Validation State Extended Community
BGP前缀源验证状态扩展社区
Abstract
摘要
This document defines a new BGP opaque extended community to carry the origination Autonomous System (AS) validation state inside an autonomous system. Internal BGP (IBGP) speakers that receive this validation state can configure local policies that allow it to influence their decision process.
本文档定义了一个新的BGP不透明扩展社区，以在自治系统内携带发起自治系统（AS）验证状态。接收此验证状态的内部BGP（IBGP）发言人可以配置本地策略，使其能够影响其决策过程。
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 http://www.rfc-editor.org/info/rfc8097.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8097.
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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Origin Validation State Extended Community . . . . . . . . . 3
3. Deployment Considerations . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . 5
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Origin Validation State Extended Community . . . . . . . . . 3
3. Deployment Considerations . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . 5
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
This document defines a new BGP opaque extended community to carry the origination AS validation state inside an autonomous system. IBGP speakers that receive this validation state can configure local policies that allow it to influence their decision process.
本文档定义了一个新的BGP不透明扩展社区，以在自治系统内将发起作为验证状态。收到此验证状态的IBGP发言人可以配置本地策略，使其能够影响其决策过程。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The origin validation state extended community is an opaque extended community [RFC4360] with the following encoding:
原始验证状态扩展社区是具有以下编码的不透明扩展社区[RFC4360]：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x43 | 0x00 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |validationstate|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x43 | 0x00 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |validationstate|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value of the high-order octet of the extended Type field is 0x43, which indicates it is non-transitive. The value of the low-order octet of the extended Type field as assigned by IANA is 0x00. The Reserved field MUST be set to 0 and ignored upon the receipt of this community. The last octet of the extended community is an unsigned integer that gives the route's validation state [RFC6811]. It can assume the following values:
扩展类型字段的高阶八位字节的值为0x43，这表示它是不可传递的。IANA分配的扩展类型字段的低阶八位组值为0x00。必须将保留字段设置为0，并在收到此社区后将其忽略。扩展社区的最后一个八位字节是一个无符号整数，它给出路由的验证状态[RFC6811]。它可以假定以下值：
+-------+-----------------------------+
| Value | Meaning |
+-------+-----------------------------+
| 0 | Lookup result = "valid" |
| 1 | Lookup result = "not found" |
| 2 | Lookup result = "invalid" |
+-------+-----------------------------+
+-------+-----------------------------+
| Value | Meaning |
+-------+-----------------------------+
| 0 | Lookup result = "valid" |
| 1 | Lookup result = "not found" |
| 2 | Lookup result = "invalid" |
+-------+-----------------------------+
If the router is configured to support the extensions defined in this document, it SHOULD attach the origin validation state extended community to BGP UPDATE messages sent to IBGP peers by mapping the computed validation state in the last octet of the extended
如果路由器配置为支持本文档中定义的扩展，则它应通过映射扩展社区最后八位字节中的计算验证状态，将源验证状态扩展社区附加到发送给IBGP对等方的BGP更新消息
community. Similarly, a receiving BGP speaker, in the absence of validation state set based on local data, SHOULD derive a validation state from the last octet of the extended community, if present.
社区类似地，在没有基于本地数据的验证状态集的情况下，接收BGP扬声器应该从扩展社区的最后一个八位组（如果存在）中导出验证状态。
An implementation SHOULD NOT send more than one instance of the origin validation state extended community. However, if more than one instance is received, an implementation MUST disregard all instances other than the one with the numerically greatest validation state value. If the value received is greater than the largest specified value (2), the implementation MUST apply a strategy similar to attribute discard [RFC7606] by discarding the erroneous community and logging the error for further analysis.
实现不应发送多个源验证状态扩展社区的实例。但是，如果接收到多个实例，则实现必须忽略除具有数值最大验证状态值的实例之外的所有实例。如果收到的值大于最大指定值（2），则实现必须应用类似于属性discard[RFC7606]的策略，方法是丢弃错误社区并记录错误以供进一步分析。
By default, implementations MUST drop the origin validation state extended community if received from an External BGP (EBGP) peer, without processing it further. Similarly, by default, an implementation SHOULD NOT send the community to EBGP peers. However, it SHOULD be possible to configure an implementation to send or accept the community when warranted. An example of a case where the community would reasonably be received from, or sent to, an EBGP peer is when two adjacent ASes are under control of the same administration. A second example is documented in [SIDR-RPKI].
默认情况下，如果从外部BGP（EBGP）对等方接收到源验证状态扩展社区，则实现必须删除该状态，而无需进一步处理。类似地，默认情况下，实现不应将社区发送给EBGP对等方。但是，在保证的情况下，应该可以将实现配置为发送或接受社区。当两个相邻的ASE处于同一管理的控制之下时，社区将合理地从EBGP对等方接收或发送到EBGP对等方的情况的一个示例。第二个示例记录在[SIDR-RPKI]中。
In deployment scenarios in which not all the speakers in an autonomous system are upgraded to support the extensions defined in this document, it is necessary to define policies that match on the origin validation extended community and set another BGP attribute [RFC6811] that influences selection of the best path in the same way that an implementation of this extension would.
在部署场景中，并非自治系统中的所有扬声器都已升级以支持本文档中定义的扩展，因此有必要定义与源验证扩展社区匹配的策略，并设置另一个BGP属性[RFC6811]这会影响最佳路径的选择，就像实现此扩展一样。
IANA has registered the value 0x00, with the name "BGP Origin Validation State Extended Community", in the "Non-Transitive Opaque Extended Community Sub-Types" registry.
IANA已在“非传递不透明扩展社区子类型”注册表中注册了名为“BGP源验证状态扩展社区”的值0x00。
Security considerations such as those described in [RFC4272] continue to apply. Because this document introduces an extended community that will generally be used to affect route selection, the analysis in Section 4.5 ("Falsification") of [RFC4593] is relevant. These issues are neither new nor unique to the origin validation extended community.
[RFC4272]中描述的安全注意事项继续适用。由于本文件介绍了一个通常用于影响路线选择的扩展社区，[RFC4593]第4.5节（“伪造”）中的分析是相关的。这些问题对于源代码验证扩展社区来说既不是新的，也不是唯一的。
The security considerations provided in [RFC6811] apply equally to this application of origin validation. In addition, this document describes a scheme where router A outsources validation to some router B. If this scheme is used, the participating routers should have the appropriate trust relationship -- B should trust A either because they are under the same administrative control or for some other reason (for example, consider [SIDR-RPKI]). The security properties of the TCP connection between the two routers should also be considered. See Section 5.1 of [RFC7454] for advice regarding protection of the TCP connection.
[RFC6811]中提供的安全注意事项同样适用于本原产地验证应用。此外，该文档描述了路由器A对某些路由器B进行验证的方案。如果使用该方案，参与路由器应该具有适当的信任关系。B应该信任A，因为它们在相同的管理控制之下，或者由于其他原因（例如，考虑[SIDR-RPKI]）。还应考虑两个路由器之间TCP连接的安全属性。有关TCP连接保护的建议，请参见[RFC7454]第5.1节。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, <http://www.rfc-editor.org/info/rfc4360>.
[RFC4360]Sangli，S.，Tappan，D.和Y.Rekhter，“BGP扩展社区属性”，RFC 4360，DOI 10.17487/RFC4360，2006年2月<http://www.rfc-editor.org/info/rfc4360>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, <http://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月<http://www.rfc-editor.org/info/rfc6811>.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, <http://www.rfc-editor.org/info/rfc4272>.
[RFC4272]Murphy，S.，“BGP安全漏洞分析”，RFC 4272，DOI 10.17487/RFC4272，2006年1月<http://www.rfc-editor.org/info/rfc4272>.
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, DOI 10.17487/RFC4593, October 2006, <http://www.rfc-editor.org/info/rfc4593>.
[RFC4593]Barbir，A.，Murphy，S.，和Y.Yang，“路由协议的一般威胁”，RFC 4593，DOI 10.17487/RFC4593，2006年10月<http://www.rfc-editor.org/info/rfc4593>.
[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, February 2015, <http://www.rfc-editor.org/info/rfc7454>.
[RFC7454]Durand，J.，Pepelnjak，I.，和G.Doering，“BGP运营和安全”，BCP 194，RFC 7454，DOI 10.17487/RFC7454，2015年2月<http://www.rfc-editor.org/info/rfc7454>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, <http://www.rfc-editor.org/info/rfc7606>.
[RFC7606]Chen，E.，Ed.，Scudder，J.，Ed.，Mohapatra，P.，和K.Patel，“BGP更新消息的修订错误处理”，RFC 7606，DOI 10.17487/RFC7606，2015年8月<http://www.rfc-editor.org/info/rfc7606>.
[SIDR-RPKI] King, T., Kopp, D., Lambrianidis, A., and A. Fenioux, "Signaling Prefix Origin Validation Results from a Route-Server to Peers", Work in Progress, draft-ietf-sidrops-route-server-rpki-light-01, January 2017.
[SIDR-RPKI]King，T.，Kopp，D.，Lambrianidis，A.，和A.Fenioux，“从路由服务器到对等方的信令前缀源验证结果”，正在进行的工作，草稿-ietf-sidrops-Route-Server-RPKI-light-012017年1月。
Acknowledgements
致谢
The authors would like to acknowledge the valuable review and suggestions from Wesley George, Roque Gagliano, and Bruno Decraene on this document.
作者希望感谢韦斯利·乔治、罗克·加利亚诺和布鲁诺·德雷恩对本文件的宝贵评论和建议。
Authors' Addresses
作者地址
Pradosh Mohapatra Sproute Networks Email: mpradosh@yahoo.com
Pradosh Mohapatra Sproute Networks电子邮件：mpradosh@yahoo.com
Keyur Patel Arrcus, Inc. Email: keyur@arrcus.com
Keyur Patel Arrcus，Inc.电子邮件：keyur@arrcus.com
John Scudder Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 United States of America Email: jgs@juniper.net
John Scudder Juniper Networks 1194 N.Mathilda Ave Sunnyvale，CA 94089美利坚合众国电子邮件：jgs@juniper.net
Dave Ward Cisco 170 W. Tasman Drive San Jose, CA 95124 United States of America Email: dward@cisco.com
Dave Ward Cisco 170 W.Tasman Drive San Jose，CA 95124美利坚合众国电子邮件：dward@cisco.com
Randy Bush Internet Initiative Japan, Inc. 5147 Crystal Springs Bainbridge Island, WA 98110 United States of America Email: randy@psg.com
Randy Bush Internet Initiative Japan，Inc.5147 Crystal Springs Bainbridge Island，WA 98110美利坚合众国电子邮件：randy@psg.com