Internet Engineering Task Force (IETF) T. King
Request for Comments: 7999 C. Dietzel
Category: Informational DE-CIX
ISSN: 2070-1721 J. Snijders
NTT
G. Doering
SpaceNet AG
G. Hankins
Nokia
October 2016
Internet Engineering Task Force (IETF) T. King
Request for Comments: 7999 C. Dietzel
Category: Informational DE-CIX
ISSN: 2070-1721 J. Snijders
NTT
G. Doering
SpaceNet AG
G. Hankins
Nokia
October 2016
BLACKHOLE Community
黑洞社区
Abstract
摘要
This document describes the use of a well-known Border Gateway Protocol (BGP) community for destination-based blackholing in IP networks. This well-known advisory transitive BGP community named "BLACKHOLE" allows an origin Autonomous System (AS) to specify that a neighboring network should discard any traffic destined towards the tagged IP prefix.
本文档描述了在IP网络中使用著名的边界网关协议（BGP）社区进行基于目的地的黑洞攻击。这个名为“黑洞”的著名的咨询传递性BGP社区允许一个原始自治系统（AS）指定一个相邻网络应该丢弃任何指向标记IP前缀的流量。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc7999.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7999.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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. BLACKHOLE Community .............................................4
3. Operational Recommendations .....................................4
3.1. IP Prefix Announcements with BLACKHOLE Community Attached ..4
3.2. Local Scope of Blackholes ..................................4
3.3. Accepting Blackholed IP Prefixes ...........................5
4. Vendor Implementation Recommendations ...........................6
5. IANA Considerations .............................................6
6. Security Considerations .........................................6
7. References ......................................................7
7.1. Normative References .......................................7
7.2. Informative References .....................................7
Acknowledgements ...................................................8
Authors' Addresses .................................................9
1. Introduction ....................................................3
1.1. Requirements Language ......................................3
2. BLACKHOLE Community .............................................4
3. Operational Recommendations .....................................4
3.1. IP Prefix Announcements with BLACKHOLE Community Attached ..4
3.2. Local Scope of Blackholes ..................................4
3.3. Accepting Blackholed IP Prefixes ...........................5
4. Vendor Implementation Recommendations ...........................6
5. IANA Considerations .............................................6
6. Security Considerations .........................................6
7. References ......................................................7
7.1. Normative References .......................................7
7.2. Informative References .....................................7
Acknowledgements ...................................................8
Authors' Addresses .................................................9
Network infrastructures have been increasingly hampered by DDoS attacks. In order to dampen the effects of these DDoS attacks, IP networks have offered blackholing with BGP [RFC4271] using various mechanisms such as those described in [RFC3882] and [RFC5635].
网络基础设施日益受到DDoS攻击的阻碍。为了抑制这些DDoS攻击的影响，IP网络使用各种机制（如[RFC3882]和[RFC5635]中所述）提供了BGP[RFC4271]的黑洞攻击。
DDoS attacks targeting a certain IP address may cause congestion of links used to connect to adjacent networks. In order to limit the impact of such a scenario on legitimate traffic, networks adopted a mechanism called "BGP blackholing". A network that wants to trigger blackholing needs to understand the triggering mechanism adopted by its neighboring networks. Different networks provide different mechanisms to trigger blackholing, including but not limited to pre-defined blackhole next-hop IP addresses, specific BGP communities, or out-of-band BGP sessions with a special BGP speaker.
针对特定IP地址的DDoS攻击可能会导致用于连接到相邻网络的链路拥塞。为了限制这种情况对合法流量的影响，网络采用了一种称为“BGP黑洞”的机制。想要触发黑洞的网络需要了解其相邻网络采用的触发机制。不同的网络提供了不同的机制来触发黑洞，包括但不限于预定义的黑洞下一跳IP地址、特定的BGP社区或带外BGP会话（带有特殊BGP扬声器）。
Having several different mechanisms to trigger blackholing in different networks makes it an unnecessarily complex, error-prone, and cumbersome task for network operators. Therefore, a well-known BGP community [RFC1997] is defined for operational ease.
在不同的网络中有几种不同的机制来触发黑洞，这使得网络运营商的任务变得不必要的复杂、容易出错和繁琐。因此，为了便于操作，定义了著名的BGP社区[RFC1997]。
Having such a well-known BGP community for blackholing also further simplifies network operations because:
拥有这样一个著名的黑洞BGP社区还可以进一步简化网络运营，因为：
o Implementing and monitoring blackholing becomes easier when implementation and operational guides do not cover many variations to trigger blackholing.
o 当实施和操作指南没有涵盖触发黑洞的许多变化时，实施和监控黑洞变得更加容易。
o The number of support requests from customers about how to trigger blackholing in a particular neighboring network will be reduced as the codepoint for common blackholing mechanisms is unified and well-known.
o 由于通用黑洞机制的代码点是统一且众所周知的，因此客户关于如何在特定相邻网络中触发黑洞的支持请求数量将减少。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119] only when they appear in all upper case. They may also appear in lower case or mixed case as English words, without normative meaning.
关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”仅当出现在所有大写字母中时，才能按照[RFC2119]中的说明进行解释。它们也可能以小写或混合大写形式出现在英语单词中，没有规范意义。
This document defines the use of a new well-known BGP transitive community, BLACKHOLE.
本文档定义了一个新的著名BGP传递社区BLACKHOLE的使用。
The semantics of this community allow a network to interpret the presence of this community as an advisory qualification to drop any traffic being sent towards this prefix.
此社区的语义允许网络将此社区的存在解释为删除发送到此前缀的任何通信量的咨询资格。
Accepting and honoring the BLACKHOLE community, or ignoring it, is a choice that is made by each operator. This community MAY be used in all bilateral and multilateral BGP deployment scenarios. In a bilateral peering relationship, use of the BLACKHOLE community MUST be agreed upon by the two networks before advertising it. In a multilateral peering relationship, the decision to honor or ignore the BLACKHOLE community is to be made according to the operator's routing policy. The community SHOULD be ignored, if it is received by a network that it not using it.
接受和尊重黑洞社区，或者忽略它，是每个运营商的选择。该社区可用于所有双边和多边BGP部署场景。在双边对等关系中，黑洞社区的使用必须得到两个网络的同意，然后才能进行广告宣传。在多边对等关系中，根据运营商的路由策略决定是否尊重黑洞社区。如果某个网络接收到该社区，而该社区未使用该社区，则应忽略该社区。
When a network is under DDoS duress, it MAY announce an IP prefix covering the victim's IP address(es) for the purpose of signaling to neighboring networks that any traffic destined for these IP address(es) should be discarded. In such a scenario, the network operator SHOULD attach the BLACKHOLE community.
当网络受到DDoS胁迫时，它可能会宣布覆盖受害者IP地址的IP前缀，以便向相邻网络发出信号，表明应该丢弃任何发送到这些IP地址的流量。在这种情况下，网络运营商应该加入黑洞社区。
The BLACKHOLE community MAY also be used as one of the trigger communities in a destination-based Remote Triggered Blackhole (RTBH) [RFC5635] configuration.
黑洞社区也可用作基于目的地的远程触发黑洞（RTBH）[RFC5635]配置中的触发社区之一。
A BGP speaker receiving an announcement tagged with the BLACKHOLE community SHOULD add the NO_ADVERTISE or NO_EXPORT community as defined in [RFC1997], or a similar community, to prevent propagation of the prefix outside the local AS. The community to prevent propagation SHOULD be chosen according to the operator's routing policy.
收到标有黑洞社区的公告的BGP演讲者应添加[RFC1997]中定义的NO_Advertised或NO_EXPORT社区或类似社区，以防止前缀在本地as之外传播。应根据运营商的路由策略选择防止传播的社区。
Unintentional leaking of more specific IP prefixes to neighboring networks can have adverse effects. Extreme caution should be used when purposefully propagating IP prefixes tagged with the BLACKHOLE community outside the local routing domain, unless policy explicitly aims at doing just that.
无意中向相邻网络泄漏更具体的IP前缀可能会产生不利影响。当有目的地在本地路由域之外传播带有黑洞社区标记的IP前缀时，应格外小心，除非政策明确旨在这样做。
It has been observed in provider networks running BGP that announcements of IP prefixes longer than /24 for IPv4 and /48 for IPv6 are usually not accepted on the Internet (see Section 6.1.3 of [RFC7454]). However, blackhole prefix length should be as long as possible in order to limit the impact of discarding traffic for adjacent IP space that is not under DDoS duress. The blackhole prefix length is typically as specific as possible, /32 for IPv4 or /128 for IPv6.
据观察，在运行BGP的提供商网络中，互联网上通常不接受IPv4的IP前缀长度超过/24和IPv6的IP前缀长度超过/48的公告（见[RFC7454]第6.1.3节）。但是，黑洞前缀长度应尽可能长，以限制丢弃未受到DDoS胁迫的相邻IP空间的流量的影响。黑洞前缀长度通常尽可能具体，IPv4为/32，IPv6为/128。
BGP speakers in a bilateral peering relationship using the BLACKHOLE community MUST only accept and honor BGP announcements carrying the BLACKHOLE community under the two following conditions:
在以下两种情况下，使用黑洞社区的双边对等关系中的BGP演讲者只能接受并遵守承载黑洞社区的BGP公告：
o The announced prefix is covered by an equal or shorter prefix that the neighboring network is authorized to advertise.
o 宣布的前缀由相邻网络被授权公布的相等或更短的前缀覆盖。
o The receiving party agreed to honor the BLACKHOLE community on the particular BGP session.
o 接收方同意在特定的BGP会议上向黑洞社区表示敬意。
In topologies with a route server or other multilateral peering relationships, BGP speakers SHOULD accept and honor BGP announcements under the same conditions.
在具有路由服务器或其他多边对等关系的拓扑中，BGP发言人应在相同条件下接受并遵守BGP公告。
An operator MUST ensure that origin validation techniques (such as the one described in [RFC6811]) do not inadvertently block legitimate announcements carrying the BLACKHOLE community.
运营商必须确保原产地验证技术（如[RFC6811]中所述）不会无意中阻止承载黑洞社区的合法公告。
The BLACKHOLE community is not intended to be used with Network Layer Reachability Information (NLRI) [RFC5575] to distribute traffic flow specifications.
黑洞社区不打算与网络层可达性信息（NLRI）[RFC5575]一起用于分发流量规范。
The error handling for this community follows the process in [RFC7606] that causes a malformed community to be treated as withdrawn.
此社区的错误处理遵循[RFC7606]中的过程，该过程会导致将格式错误的社区视为已撤销。
Operators are encouraged to store all BGP updates in their network carrying the BLACKHOLE community for long-term analysis or internal audit purposes.
鼓励运营商将所有BGP更新存储在其承载黑洞社区的网络中，以进行长期分析或内部审计。
Without an explicit configuration directive set by the operator, network elements SHOULD NOT discard traffic destined towards IP prefixes that are tagged with the BLACKHOLE community. The operator is expected to explicitly configure the network element to honor the BLACKHOLE community in a way that is compliant with the operator's routing policy.
如果没有运营商设置的明确配置指令，网络元件不应丢弃指向带有黑洞社区标记的IP前缀的流量。运营商应明确配置网元，以符合运营商路由策略的方式尊重黑洞社区。
Vendors MAY provide a shorthand keyword in their configuration language to reference the well-known BLACKHOLE community attribute value. The suggested string to be used is "blackhole".
供应商可以在其配置语言中提供一个速记关键字，以引用众所周知的黑洞社区属性值。建议使用的字符串是“黑洞”。
The IANA has registered BLACKHOLE in the "BGP Well-known Communities" registry.
IANA已在“BGP知名社区”注册处注册了黑洞。
BLACKHOLE (= 0xFFFF029A)
黑洞（=0xFFFF029A）
The low-order two octets in decimal are 666, a value commonly associated with BGP blackholing among network operators.
十进制的低阶两个八位字节为666，这是一个通常与网络运营商的BGP黑洞有关的值。
BGP contains no specific mechanism to prevent the unauthorized modification of information by the forwarding agent. This allows routing information to be modified or removed; it also allows false information to be added by forwarding agents. Recipients of routing information are not able to detect this modification. BGPsec [BGPSEC] does not resolve this situation. Even when BGPsec is in place, a forwarding agent can alter, add, or remove BGP communities.
BGP不包含防止转发代理未经授权修改信息的特定机制。这允许修改或删除路由信息；它还允许货运代理添加虚假信息。路由信息的收件人无法检测到此修改。BGPsec[BGPsec]无法解决此情况。即使BGPsec就位，转发代理也可以更改、添加或删除BGP社区。
The unauthorized addition of the BLACKHOLE community to an IP prefix by an adversary may cause a denial-of-service attack based on denial of reachability.
对手未经授权将黑洞社区添加到IP前缀可能会导致基于拒绝可达性的拒绝服务攻击。
In order to further limit the impact of unauthorized BGP announcements carrying the BLACKHOLE community, the receiving BGP speaker SHOULD verify by applying strict filtering (see Section 6.2.1.1.2 of [RFC7454]) that the peer announcing the prefix is authorized to do so. If not, the BGP announcement should be filtered.
为了进一步限制未经授权的BGP公告对黑洞社区的影响，接收BGP发言人应通过应用严格过滤（见[RFC7454]第6.2.1.1.2节）验证宣布前缀的对等方是否有权这样做。如果没有，则应过滤BGP公告。
BGP announcements carrying the BLACKHOLE community should only be accepted and honored if the neighboring network is authorized to advertise the prefix. The method of validating announcements is to be chosen according to the operator's routing policy.
只有在授权相邻网络宣传前缀的情况下，才应接受并遵守带有黑洞社区的BGP公告。根据运营商的路由策略选择确认公告的方法。
It is RECOMMENDED that operators use best common practices to protect their BGP sessions, such as the ones in [RFC7454].
建议运营商使用最佳通用做法来保护其BGP会话，如[RFC7454]中所述。
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, <http://www.rfc-editor.org/info/rfc1997>.
[RFC1997]Chandra，R.，Traina，P.，和T.Li，“BGP社区属性”，RFC 1997，DOI 10.17487/RFC1997，1996年8月<http://www.rfc-editor.org/info/rfc1997>.
[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>.
[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, <http://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月<http://www.rfc-editor.org/info/rfc4271>.
[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>.
[BGPSEC] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", Work in Progress, draft-ietf-sidr-bgpsec-protocol-18, August 2016.
[BGPSEC]Lepinski，M.，Ed.和K.Sriram，Ed.，“BGPSEC协议规范”，正在进行的工作，草案-ietf-sidr-BGPSEC-Protocol-18，2016年8月。
[RFC3882] Turk, D., "Configuring BGP to Block Denial-of-Service Attacks", RFC 3882, DOI 10.17487/RFC3882, September 2004, <http://www.rfc-editor.org/info/rfc3882>.
[RFC3882]Turk，D.，“配置BGP以阻止拒绝服务攻击”，RFC 3882，DOI 10.17487/RFC3882，2004年9月<http://www.rfc-editor.org/info/rfc3882>.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., and D. McPherson, "Dissemination of Flow Specification Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, <http://www.rfc-editor.org/info/rfc5575>.
[RFC5575]Marques，P.，Sheth，N.，Raszuk，R.，Greene，B.，Mauch，J.，和D.McPherson，“流量规范规则的传播”，RFC 5575，DOI 10.17487/RFC5575，2009年8月<http://www.rfc-editor.org/info/rfc5575>.
[RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)", RFC 5635, DOI 10.17487/RFC5635, August 2009, <http://www.rfc-editor.org/info/rfc5635>.
[RFC5635]Kumari，W.和D.McPherson，“具有单播反向路径转发（uRPF）的远程触发黑洞滤波”，RFC 5635，DOI 10.17487/RFC5635，2009年8月<http://www.rfc-editor.org/info/rfc5635>.
[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>.
[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>.
Acknowledgements
致谢
The authors would like to gratefully acknowledge many people who have contributed discussions and ideas to the development of this document. They include Petr Jiran, Yordan Kritski, Christian Seitz, Nick Hilliard, Joel Jaeggli, Christopher Morrow, Thomas Mangin, Will Hargrave, Niels Bakker, David Farmer, Jared Mauch, John Heasley, and Terry Manderson.
作者要感谢许多为本文件的编写提供了讨论和想法的人。他们包括彼得·吉兰、约丹·克里茨基、克里斯蒂安·塞茨、尼克·希利亚德、乔尔·杰格利、克里斯托弗·莫罗、托马斯·曼金、威尔·哈格雷夫、尼尔斯·巴克、大卫·法默、杰瑞德·莫奇、约翰·希斯利和特里·曼德森。
Authors' Addresses
作者地址
Thomas King DE-CIX Management GmbH Lichtstrasse 43i Cologne 50825 Germany
Thomas King DE-CIX管理有限公司Lichtstrasse 43i科隆50825德国
Email: thomas.king@de-cix.net
Email: thomas.king@de-cix.net
Christoph Dietzel DE-CIX Management GmbH Lichtstrasse 43i Cologne 50825 Germany
Christoph Dietzel DE-CIX管理有限公司Lichtstrasse 43i科隆50825德国
Email: christoph.dietzel@de-cix.net
Email: christoph.dietzel@de-cix.net
Job Snijders NTT Communications Theodorus Majofskistraat 100 Amsterdam 1065 SZ The Netherlands
Job Snijders NTT Communications Theodorus Majofskistraat 100阿姆斯特丹1065 SZ荷兰
Email: job@ntt.net
Email: job@ntt.net
Gert Doering SpaceNet AG Joseph-Dollinger-Bogen 14 Munich 80807 Germany
Gert Doering SpaceNet AG Joseph Dollinger Bogen 14慕尼黑80807德国
Email: gert@space.net
Email: gert@space.net
Greg Hankins Nokia 777 E. Middlefield Road Mountain View, CA 94043 United States of America
Greg Hankins诺基亚777美国加利福尼亚州米德尔菲尔德路山景大道东94043号
Email: greg.hankins@nokia.com
Email: greg.hankins@nokia.com