RFC 8097 - BGP Prefix Origin Validation State Extended Community 中文翻译

原文URL : https://datatracker.ietf.org/doc/html/rfc8097
文档标题 : RFC 8097 - BGP 前缀起源验证状态扩展社区
翻译方式 : 自动生成

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。

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

1. 导言

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 不透明扩展社区，用于在自治系统内携带发端 AS 验证状态。收到此验证状态的 IBGP 发言者可配置本地策略，使其能够影响自己的决策过程。

1.1. Requirements Language

1.1. 要求语言

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

本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 以及 "OPTIONAL" 应按照RFC 2119 [RFC2119]中的描述进行解释。

2. Origin Validation State Extended Community

2. 原产地验证状态扩展社区

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|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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"   |
                     +-------+-----------------------------+

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

如果路由器被配置为支持本文档中定义的扩展，它就应该通过在扩展社区的最后一个八位位组中映射计算出的验证状态，将起源验证状态扩展社区附加到发送给 IBGP 对等方的 BGP UPDATE 消息中。同样，接收 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)，实施必须采用与属性丢弃 [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 对等体发送社区。但是，应该可以对实现进行配置，以便在必要时发送或接受社区。从 EBGP 对等体接收或向 EBGP 对等体发送社群的一个合理情况是，两个相邻的 AS 由同一管理机构控制。第二个例子在[SIDR-RPKI]中有记载。

3. Deployment Considerations

3. 部署考虑因素

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]，该属性与该扩展的实现方式相同，会影响最佳路径的选择。

4. IANA Considerations

4. IANA考虑因素

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。

5. Security Considerations

5. 安全考虑因素

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

6. References

6. 参考文献

6.1. Normative References

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

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

[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., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, <http://www.rfc-editor.org/info/rfc6811>。

6.2. Informative References

6.2. 参考性文献

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

[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., and G. Doering, "BGP Operations and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, February 2015, <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>.

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

Acknowledgements

致谢

The authors would like to acknowledge the valuable review and suggestions from Wesley George, Roque Gagliano, and Bruno Decraene on this document.

作者感谢 Wesley George、Roque Gagliano 和 Bruno Decraene 对本文件提出的宝贵意见和建议。

Authors' Addresses

作者地址

Pradosh Mohapatra Sproute Networks Email: [email protected]

Pradosh Mohapatra Sproute Networks 电子邮件：[email protected]

Keyur Patel Arrcus, Inc. Email: [email protected]

Keyur Patel Arrcus, Inc.电子邮件: [email protected]

John Scudder Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 United States of America Email: [email protected]

Dave Ward Cisco 170 W. Tasman Drive San Jose, CA 95124 United States of America Email: [email protected]

Randy Bush Internet Initiative Japan, Inc. 5147 Crystal Springs Bainbridge Island, WA 98110 United States of America Email: [email protected]

Randy Bush Internet Initiative Japan, Inc.5147 Crystal Springs Bainbridge Island, WA 98110 United States of America Email: [email protected]