Network Working Group W. Kumari
Request for Comments: 5635 Google
Category: Informational D. McPherson
Arbor Networks
August 2009
Network Working Group W. Kumari
Request for Comments: 5635 Google
Category: Informational D. McPherson
Arbor Networks
August 2009
Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)
具有单播反向路径转发（uRPF）的远程触发黑洞滤波
Abstract
摘要
Remote Triggered Black Hole (RTBH) filtering is a popular and effective technique for the mitigation of denial-of-service attacks. This document expands upon destination-based RTBH filtering by outlining a method to enable filtering by source address as well.
远程触发黑洞（RTBH）过滤是缓解拒绝服务攻击的一种流行而有效的技术。本文档对基于目的地的RTBH过滤进行了扩展，并概述了一种方法，该方法也支持按源地址进行过滤。
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Destination Address RTBH Filtering ..............................3
3.1. Overview ...................................................3
3.2. Detail .....................................................4
4. Source Address RTBH Filtering ...................................7
4.1. Steps to Deploy RTBH Filtering with uRPF for Source
Filtering ..................................................8
5. Security Considerations .........................................9
6. Acknowledgments .................................................9
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References ....................................10
Appendix A. Cisco Router Configuration Sample .....................11
Appendix B. Juniper Configuration Sample ..........................12
Appendix C. A Brief History of RTBH ...............................14
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Destination Address RTBH Filtering ..............................3
3.1. Overview ...................................................3
3.2. Detail .....................................................4
4. Source Address RTBH Filtering ...................................7
4.1. Steps to Deploy RTBH Filtering with uRPF for Source
Filtering ..................................................8
5. Security Considerations .........................................9
6. Acknowledgments .................................................9
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References ....................................10
Appendix A. Cisco Router Configuration Sample .....................11
Appendix B. Juniper Configuration Sample ..........................12
Appendix C. A Brief History of RTBH ...............................14
This document expands upon the technique outlined in "Configuring BGP to Block Denial-of-Service Attacks" [RFC3882] to demonstrate a method that allows for filtering by source address(es).
本文档扩展了“配置BGP以阻止拒绝服务攻击”[RFC3882]中概述的技术，以演示一种允许按源地址过滤的方法。
Network operators have developed a variety of techniques for mitigating denial-of-service (DoS) attacks. While different techniques have varying strengths and weaknesses, from an implementation perspective, the selection of which method to use for each type of attack involves evaluating the tradeoffs associated with each method.
网络运营商已经开发了各种技术来缓解拒绝服务（DoS）攻击。虽然不同的技术有不同的优点和缺点，但从实现的角度来看，选择用于每种类型攻击的方法需要评估与每种方法相关的权衡。
A common DoS attack directed against a customer of a service provider involves generating a greater volume of attack traffic destined for the target than will fit down the links from the service provider(s) to the victim (customer). This traffic "starves out" legitimate traffic and often results in collateral damage or negative effects to other customers or the network infrastructure as well. Rather than having all destinations on their network be affected by the attack, the customer may ask their service provider to filter traffic destined to the target destination IP address(es), or the service provider may determine that this is necessary themselves, in order to preserve network availability.
针对服务提供商的客户的常见DoS攻击涉及到产生更多的攻击流量，这些攻击流量的目的地是目标，而不是服务提供商与受害者（客户）之间的链接。这种流量会“饿死”合法流量，并经常对其他客户或网络基础设施造成附带损害或负面影响。为了保持网络可用性，客户可以要求其服务提供商过滤目的地为目标目的地IP地址的流量，或者服务提供商自己确定这是必要的，而不是让其网络上的所有目的地都受到攻击的影响。
One method that the service provider can use to implement this filtering is to deploy access control lists on the edge of their network. While this technique provides a large amount of flexibility in the filtering, it runs into scalability issues, both in terms of the number of entries in the filter and the packet rate.
服务提供商可用于实现此过滤的一种方法是在其网络边缘部署访问控制列表。虽然这种技术在过滤中提供了很大的灵活性，但它在过滤器中的条目数和数据包速率方面都会遇到可伸缩性问题。
Most routers are able to forward traffic at a much higher rate than they are able to filter, and they are able to hold many more forwarding table entries and routes than filter entries. RTBH filtering leverages the forwarding performance of modern routers to filter more entries and at a higher rate than access control lists would otherwise allow.
大多数路由器能够以比它们能够过滤的速率高得多的速率转发流量，并且它们能够容纳比过滤条目多得多的转发表条目和路由。RTBH过滤利用现代路由器的转发性能，以比访问控制列表更高的速率过滤更多的条目。
However, with destination-based RTBH filtering, the impact of the attack on the target is complete. That is, destination-based RTBH filtering injects a discard route into the forwarding table for the target prefix. All packets towards that destination, attack traffic AND legitimate traffic, are then dropped by the participating routers,thereby taking the target completely offline. The benefit is that collateral damage to other systems or network availability at the customer location or in the ISP network is limited, but the negative impact to the target itself is arguably increased.
然而，使用基于目的地的RTBH过滤，攻击对目标的影响是完全的。也就是说，基于目的地的RTBH过滤将丢弃路由注入到目标前缀的转发表中。所有指向该目的地的数据包，攻击流量和合法流量，然后由参与路由器丢弃，从而使目标完全离线。其好处是，对客户所在地或ISP网络中的其他系统或网络可用性的附带损害是有限的，但对目标公司本身的负面影响可能会增加。
By coupling unicast Reverse Path Forwarding (uRPF) [RFC3704] techniques with RTBH filtering, BGP can be used to distribute discard routes that are based not on destination or target addresses, but on source addresses of unwanted traffic. Note that this will drop all traffic to/from the address, and not just the traffic to the victim.
通过将单播反向路径转发（uRPF）[RFC3704]技术与RTBH过滤相结合，BGP可用于分发丢弃路由，这些丢弃路由不是基于目的地或目标地址，而是基于不需要流量的源地址。请注意，这将删除该地址的所有通信量，而不仅仅是受害者的通信量。
This document is broken up into three logical parts: the first outlines how to configure destination-based RTBH, the second covers source-based RTBH, and the third part has examples and a history of the technique.
本文档分为三个逻辑部分：第一部分概述了如何配置基于目标的RTBH，第二部分介绍了基于源代码的RTBH，第三部分介绍了该技术的示例和历史。
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]中所述进行解释。
A discard route is installed on each edge router in the network with the destination set to the discard (or null) interface. In order to use RTBH filtering for a single IP address (or prefix), a BGP route for the address to be filtered is announced, with the next-hop set as
丢弃路由安装在网络中的每个边缘路由器上，目的地设置为丢弃（或空）接口。为了对单个IP地址（或前缀）使用RTBH筛选，将宣布要筛选的地址的BGP路由，并将下一跳设置为
the discard route. This causes traffic to the announced network prefix to be forwarded to the discard interface so that it does not transit the network wasting resources or triggering collateral damage to other resources along the path towards the target.
丢弃路线。这将导致发送到已宣布网络前缀的通信量转发到discard接口，这样它就不会传输网络，从而浪费资源或触发沿目标路径的其他资源的附带损害。
While this does "complete" the attack in that the target address(es) are made unreachable, collateral damage is minimized. It may also be possible to move the host or service on the target IP address(es) to another address and keep the service up, for example, by updating associated DNS resource records.
虽然这确实“完成”了攻击，因为目标地址无法访问，但附带损害被最小化。还可以将目标IP地址上的主机或服务移动到另一个地址，并保持服务正常运行，例如，通过更新相关联的DNS资源记录。
Before deploying RTBH filtering, there is some preparation and planning that needs to occur and decisions that need to be made. These include:
在部署RTBH筛选之前，需要进行一些准备和规划，并做出一些决策。这些措施包括：
- What are the discard addresses?
- 丢弃地址是什么？
- What are the discard BGP communities?
- 什么是BGP社区？
- What is the largest prefix that can be black-holed?
- 最大的前缀可以是什么？
- What is the smallest advertisement that your provider will accept?
- 您的提供商将接受的最小广告是什么？
Steps to configure destination-based RTBH filtering:
配置基于目标的RTBH筛选的步骤：
Step 1. Select Your Discard Address Schema
第一步。选择您的丢弃地址模式
An address is chosen to become the "discard address". This is often chosen from 192.0.2.0/24 (TEST-NET [RFC3330]), or from RFC 1918 [RFC1918] space. Multiple addresses allow an operator to configure multiple static routes, one for each incident:
选择一个地址作为“丢弃地址”。这通常从192.0.2.0/24（测试网[RFC3330]）或RFC1918[RFC1918]空间中选择。多个地址允许操作员配置多个静态路由，每个事件一个：
192.0.2.1 = Incident #1
192.0.2.2 = Incident #2
192.0.2.3 = Incident #3
192.0.2.4 = Incident #4
192.0.2.5 = Incident #5
192.0.2.1 = Incident #1
192.0.2.2 = Incident #2
192.0.2.3 = Incident #3
192.0.2.4 = Incident #4
192.0.2.5 = Incident #5
Customer #1, who has a DDoS (Distributed DoS) attack can be pointed to discard route 192.0.2.1. Customer #2 can be pointed to discard route 192.0.2.2. If capable, the router can then count the drops for each, providing some level of telemetry on the volume of drops as well as status of an ongoing attack. A consistent address schema facilitates operations.
具有DDoS（分布式DoS）攻击的客户#1可以被指向放弃路由192.0.2.1。客户#2可以指向丢弃路径192.0.2.2。如果有能力，路由器就可以计算每一次的丢包次数，对丢包量以及正在进行的攻击的状态进行一定程度的遥测。一致的地址模式便于操作。
Step 2. Configure the Discard Route(s) on Each Router
第二步。在每个路由器上配置丢弃路由
A route for the "discard address" is installed on the routers that form the edge/perimeter of the network in all routers in the network or some subset (e.g., peering, but not customer, etc.). The destination of the route is set to the "discard" or "null" interface. This route is called the "discard route". Implementation experience demonstrates the value of configuring each ingress router with a capability for dropping traffic via RTBH filtering.
“丢弃地址”的路由安装在路由器上，这些路由器构成网络中所有路由器或某个子集中的网络边缘/周界（例如，对等，但不是客户等）。路由的目的地设置为“discard”或“null”接口。此路由称为“丢弃路由”。实施经验表明，为每个入口路由器配置通过RTBH过滤丢弃流量的能力是有价值的。
Step 3. Configure the RTBH BGP Policy on Each Router
第三步。在每个路由器上配置RTBH BGP策略
A BGP policy is configured on all routers that have the discard route so that routes announced with a chosen community will have their next-hop set to the discard address. The BGP policy should be made restrictive so that only BGP routes covering a defined number of hosts addresses will be accepted. That is, typically, only specific /32s are necessary. Shorter prefix blocks may also be required or desirable, for example, if larger numbers of attack targets are located within a single prefix, or the employment of this mechanism is to drop traffic bound for specific networks. When filtering based on shorter prefixes, extreme caution should be used as to avoid collateral damage to other hosts that reside within those address blocks. Full implementations will have multiple communities, with each community used for different parts of a provider's network and for different security incidents.
在具有丢弃路由的所有路由器上配置BGP策略，以便使用所选社区宣布的路由将其下一跳设置为丢弃地址。BGP策略应具有限制性，以便只接受覆盖定义数量的主机地址的BGP路由。也就是说，通常只需要特定/32。例如，如果更多攻击目标位于单个前缀内，或者使用该机制是为了降低特定网络的流量限制，则也可能需要或需要更短的前缀块。在基于较短前缀进行过滤时，应格外小心，以避免对驻留在这些地址块中的其他主机造成附带损害。完整的实现将有多个社区，每个社区用于提供商网络的不同部分和不同的安全事件。
Step 4. Configure the Safety Egress Prefix Filters
第四步。配置安全出口前缀过滤器
There is always a chance that the triggering BGP update could leak from the network and so egress prefix filters are strongly recommended. These egress prefix filter details may vary, but experience has demonstrated that the following works:
触发BGP更新总是有可能从网络泄漏，因此强烈建议使用出口前缀过滤器。这些出口前缀过滤器的细节可能会有所不同，但经验表明，以下方法可行：
- Deny all prefixes longer than the longest prefix that you expect to announce. For example, if the longest prefix that you expect to announce is /24, deny all prefixes of length /25 though /32. If your triggering BGP update is only /32s, then this egress prefix filter will add a safe measure in case the NO_EXPORT community does not work.
- 拒绝所有长度超过预期宣布的最长前缀的前缀。例如，如果您希望宣布的最长前缀是/24，请拒绝所有长度为/25到/32的前缀。如果触发BGP更新的时间仅为/32s，则此出口前缀过滤器将添加一个安全措施，以防NO_导出社区不起作用。
- Deny all communities used for triggering RTBH filtering. This is also a "safety" measure in case the NO_EXPORT community does not work.
- 拒绝用于触发RTBH筛选的所有社区。这也是一项“安全”措施，以防禁止出口社区不起作用。
Step 5: Configure the Trigger Router
步骤5：配置触发器路由器
Configure the trigger router, workstation, or other device so that adding and removing the triggers can be done easily and quickly. The BGP update should have the NO_EXPORT community as a mandatory attribute. An egress prefix filter or policy that prevents RTBH filtering prefixes in the /8 to /24 range is also recommended as a safety tool. The trigger router can be set up as an iBGP (Internal BGP) route reflector client that does not receive any prefixes from its BGP peer. This allows a low-cost router/workstation to be used as the trigger router.
配置触发器路由器、工作站或其他设备，以便轻松快速地添加和删除触发器。BGP更新应将NO_导出社区作为强制属性。还建议使用出口前缀过滤器或策略，以防止RTBH过滤/8到/24范围内的前缀。触发器路由器可以设置为iBGP（内部BGP）路由反射器客户端，该客户端不从其BGP对等方接收任何前缀。这允许使用低成本路由器/工作站作为触发路由器。
Using the RTBH filtering:
使用RTBH筛选：
1: When RTBH filtering is desired for a specific address, that address is announced from a trigger router (or route server), tagged with the chosen "RTBH" community and with the NO_EXPORT community, and passed via iBGP. The receiving routers check the BGP policy, set the next-hop to be the discard route, resulting in a Forwarding Information Base (FIB) entry pointing to a discard address.
1：当需要对特定地址进行RTBH过滤时，该地址将从触发器路由器（或路由服务器）宣布，标记为所选的“RTBH”社区和NO_导出社区，并通过iBGP传递。接收路由器检查BGP策略，将下一跳设置为丢弃路由，从而生成指向丢弃地址的转发信息库（FIB）条目。
2: Traffic entering the network will now be forwarded to the discard interface on all edge routers and will therefore be dropped at the edge of the network, saving resources.
2：进入网络的流量现在将转发到所有边缘路由器上的丢弃接口，因此将在网络边缘丢弃，从而节省资源。
2.1: Multiple Discard Addresses for Incident Granularity. This technique can be expanded by having multiple discard addresses, routes, and communities to allow for monitoring of the discarded traffic volume on devices that support multiple discard interfaces. As mentioned earlier, each router can have a discard address schema to allow the operator to distinguish multiple incidents from each other -- making it easier to monitor the life-cycle of the incidents.
2.1：事件粒度的多个丢弃地址。该技术可以通过具有多个丢弃地址、路由和社区来扩展，以允许在支持多个丢弃接口的设备上监视丢弃的通信量。如前所述，每个路由器都可以有一个丢弃地址模式，以允许操作员区分多个事件，从而更容易监控事件的生命周期。
2.2: Multiple "Trigger Communities" for Network-Wide Granularity. The network can be sectioned into multiple communities, providing the operator with an ability to drop in discrete parts of their network. For example, the network can be divided into the following communities (where XXX represents the operator's AS number):
2.2：网络范围粒度的多个“触发社区”。网络可以划分为多个社区，使运营商能够进入其网络的离散部分。例如，网络可分为以下社区（其中XXX代表运营商的AS编号）：
XXX:600 RTBH filtering on all routers XXX:601 RTBH filtering on only peering routers XXX:602 RTBH filtering on only customers who peer BGP XXX:603 RTBH filtering on data centers (to see if the data center is the source of attack)
XXX:600所有路由器上的RTBH过滤XXX:601仅对等路由器上的RTBH过滤XXX:602仅对等BGP的客户上的RTBH过滤XXX:603数据中心上的RTBH过滤（查看数据中心是否是攻击源）
XXX:604 RTBH filtering on all customers (to see how many customers are being used by the attacker)
XXX:604 RTBH对所有客户进行过滤（查看攻击者使用了多少客户）
Some diligent thinking is required to develop a community schema that provides flexibility while reflecting topological considerations.
需要一些勤奋的思考来开发一个社区模式，该模式在反映拓扑考虑的同时提供灵活性。
2.3: "Customer-Triggered" RTBH filtering. The technique can also be expanded by relaxing the Autonomous System (AS) path rule to allow customers of a service provider to enable RTBH filtering without interacting with the service provider's trigger routers. If this is configured, an operator MUST only accept announcements from the customer for prefixes that the customer is authorized to advertise, in order to prevent the customer from accidentally (or intentionally) black-holing space that they are not allowed to advertise.
2.3：“客户触发”RTBH过滤。该技术还可以通过放松自主系统（AS）路径规则来扩展，以允许服务提供商的客户在不与服务提供商的触发路由器交互的情况下启用RTBH过滤。如果配置了此功能，操作员必须只接受客户对其授权发布的前缀的通知，以防止客户意外（或故意）占用不允许发布的黑洞空间。
A common policy for this type of setup would first permit any longer prefix within an authorized prefix only if the black hole communities are attached, append NO_EXPORT, NO_ADVERTISE, or similar communities, and then also accept from the customer the original aggregate prefix that will be advertised as standard policy permits.
这种类型的设置的通用策略将首先允许授权前缀中的任何更长前缀，前提是附加黑洞社区、附加NO_EXPORT、NO_advertised或类似社区，然后还接受客户提供的原始聚合前缀，该前缀将作为标准策略许可进行广告。
Extreme caution should be used in order to avoid leaking any more specifics beyond the local routing domain, unless policy explicitly aims at doing just that.
为了避免泄漏超出本地路由域的更多细节，应特别小心，除非策略明确旨在这样做。
In many instances, denial-of-service attacks sourced from botnets are being configured to "follow DNS". (The attacking machines are instructed to attack www.example.com, and re-resolve this periodically. Historically, the attacks were aimed simply at an IP address and so renumbering www.example.com to a new address was an effective mitigation.) This makes it desirable to employ a technique that allows black-holing to be based on source address.
在许多情况下，源于僵尸网络的拒绝服务攻击被配置为“跟随DNS”。（攻击机器被指示攻击www.example.com，并定期重新解决此问题。从历史上看，攻击仅针对IP地址，因此将www.example.com重新编号为新地址是一种有效的缓解措施。）因此，需要采用一种允许基于源地址的黑洞技术。
By combining traditional RTBH filtering with unicast Reverse Path Forwarding (uRPF), a network operator can filter based upon the source address. uRPF performs a route lookup of the source address of the packet and checks to see if the ingress interface of the packet is a valid egress interface for the packet source address (strict mode) or if any route to the source address of the packet exists (loose mode). If the check fails, the packet is typically dropped. In loose mode, some vendors also verify that the destination route does not point to an invalid next-hop -- this allows source-based RTBH filtering to be deployed in networks that
通过将传统RTBH过滤与单播反向路径转发（uRPF）相结合，网络运营商可以基于源地址进行过滤。uRPF对数据包的源地址执行路由查找，并检查数据包的入口接口是否是数据包源地址的有效出口接口（严格模式），或者是否存在到数据包源地址的任何路由（松散模式）。如果检查失败，数据包通常会被丢弃。在松散模式下，一些供应商还验证目标路由没有指向无效的下一跳——这允许在以下网络中部署基于源的RTBH过滤：
cannot implement strict (or feasible path) mode uRPF. Before enabling uRPF (in any mode), it is vital that you fully understand the implications of doing so:
无法实现严格（或可行路径）模式uRPF。在启用uRPF（在任何模式下）之前，您必须充分了解这样做的含义：
- Strict mode will cause the router to drop all ingress traffic if the best path back to the source address of the traffic is not the interface from which the traffic was received. Asymmetric routing will cause strict mode uRPF to drop legitimate traffic.
- 如果返回流量源地址的最佳路径不是接收流量的接口，则严格模式将导致路由器丢弃所有入口流量。非对称路由将导致严格模式uRPF丢弃合法流量。
- Loose mode causes the router to check if a route for the source address of the traffic exists. This may also cause legitimate traffic to be discarded.
- 松散模式使路由器检查流量源地址的路由是否存在。这也可能导致合法流量被丢弃。
It is hoped that in the future, vendors will implement a "DoS-mitigation" mode in addition to the loose and strict modes -- in this mode, the uRPF check will only fail if the next-hop for the source of the packet is a discard interface.
希望在未来，除了松散和严格模式之外，供应商还将实施“DoS缓解”模式——在这种模式下，只有当数据包源的下一跳是丢弃接口时，uRPF检查才会失败。
By enabling the uRPF feature on interfaces at predetermined points in their network and announcing the source address(es) of attack traffic, a network operator can effectively drop the identified attack traffic at specified devices (ideally ingress edge) of their network based on source address.
通过在其网络中预定点的接口上启用uRPF功能并宣布攻击流量的源地址，网络运营商可以根据源地址有效地在其网络的指定设备（理想情况下是入口边缘）丢弃已识别的攻击流量。
While administrators may choose to drop traffic from any prefix they wish, it is recommended when employing source-based RTBH filtering inter-domain that explicit policy be defined that enables peers to only announce source-based RTBH routes for prefixes that they originate.
虽然管理员可以选择从他们希望的任何前缀删除流量，但在采用基于源的RTBH域间过滤时，建议定义明确的策略，使对等方能够仅为其发起的前缀宣布基于源的RTBH路由。
The same steps that are required to implement destination address RTBH filtering are taken with the additional step of enabling unicast Reverse Path Forwarding on predetermined interfaces. When a source address (or network) needs to be blocked, that address (or network) is announced using BGP tagged with a community. This will cause the route to be installed with a next-hop of the discard interface, causing the uRPF check to fail and the packets to be discarded. The destination-based RTBH filtering community should not be used for source-based RTBH filtering, and the routes tagged with the selected community should be carefully filtered.
实现目标地址RTBH过滤所需的步骤与在预定接口上启用单播反向路径转发的附加步骤相同。当需要阻止源地址（或网络）时，将使用带有社区标记的BGP来宣布该地址（或网络）。这将导致使用discard接口的下一个跃点安装路由，导致uRPF检查失败并丢弃数据包。基于目的地的RTBH筛选社区不应用于基于源的RTBH筛选，并且应仔细筛选使用所选社区标记的路由。
The BGP policy will need to be relaxed to accept announcements tagged with this community to be accepted even though they contain addresses not controlled by the network announcing them. These announcements must NOT be propagated outside the local AS and should carry the NO_EXPORT community.
BGP策略需要放宽，以接受标记有此社区的公告，即使这些公告包含的地址不受发布它们的网络控制。这些公告不得在当地AS之外传播，并应包含禁止出口社区。
As a matter of policy, operators SHOULD NOT accept source-based RTBH announcements from their peers or customers, they should only be installed by local or attack management systems within their administrative domain.
作为一项政策，运营商不应接受来自其同行或客户的基于源代码的RTBH公告，它们只能由其管理域内的本地或攻击管理系统安装。
The techniques presented here provide enough power to cause significant traffic forwarding loss if incorrectly deployed. It is imperative that the announcements that trigger the black-holing are carefully checked and that the BGP policy that accepts these announcements is implemented in such a manner that the announcements:
这里介绍的技术提供了足够的功率，如果部署不当，将导致重大的流量转发损失。必须仔细检查触发黑洞的公告，并且接受这些公告的BGP政策的实施方式应确保公告：
- Are not propagated outside the AS (NO_EXPORT).
- 不会在AS外部传播（无导出）。
- Are not accepted from outside the AS (except from customers).
- 不接受来自AS外部的信息（客户除外）。
- Except where source-based filtering is deployed, that the network contained in the announcement falls within the address ranges controlled by the announcing AS (i.e., for customers that the address falls within their space).
- 除非部署了基于源的筛选，否则公告中包含的网络位于公告AS控制的地址范围内（即，对于地址位于其空间内的客户）。
I would like to thank Joe Abley, Ron Bonica, Rodney Dunn, Alfred Hoenes, Donald Smith, Joel Jaeggli, and Steve Williams for their assistance, feedback and not laughing *too* much at the quality of the initial versions.
我要感谢Joe Abley、Ron Bonica、Rodney Dunn、Alfred Hoenes、Donald Smith、Joel Jaeggli和Steve Williams，感谢他们的帮助、反馈，感谢他们没有对初始版本的质量笑得太多。
I would also like to thank all of the regular contributors to the OPSEC Working Group and Google for 20% time :-)
我还要感谢所有定期向OPSEC工作组和谷歌贡献20%时间的人：-）
The authors would also like to thank Steven L Johnson and Barry Greene for getting this implemented and Chris Morrow for publicizing the technique in multiple talks.
作者还要感谢史蒂文·约翰逊和巴里·格林实施了这项技术，并感谢克里斯·莫罗在多次会谈中宣传了这项技术。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[RFC3330]IANA，“特殊用途IPv4地址”，RFC33302002年9月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 37042004年3月。
[RFC3882] Turk, D., "Configuring BGP to Block Denial-of-Service Attacks", RFC 3882, September 2004.
[RFC3882]Turk，D.，“配置BGP以阻止拒绝服务攻击”，RFC 3882，2004年9月。
[Greene2001] Greene Barry Raveendran and Jarvis Neil, "Unicast Reverse Path Forwarding (uRPF) Enhancements for the ISP-ISP Edge", ftp://ftp-eng.cisco.com/ cons/isp/documents/uRPF_Enhancement.pdf, 2001.
[Greene 2001]Greene Barry Ravendran和Jarvis Neil，“ISP-ISP边缘的单播反向路径转发（uRPF）增强”，ftp://ftp-eng.cisco.com/ cons/isp/documents/uRPF_Enhancement.pdf，2001年。
This section provides a partial configuration for configuring RTBH filtering on a Cisco router. This is not a complete configuration and should be customized before being used.
本节提供在Cisco路由器上配置RTBH过滤的部分配置。这不是一个完整的配置，应在使用前进行自定义。
Announcing router: ! The discard route ip route 192.0.2.1 255.255.255.255 Null0 ! ! Matches and empty AS-PATH only. ip as-path access-list 10 permit ^$ ! ! This route-map matches routes with tag 666 and sets the next-hop ! to be the discard route. route-map remote-trigger-black-hole permit 10 match tag 666 set ip next-hop 192.0.2.1 set local-preference 200 set community no-export ! The community used internally to tag RTBH announcements. set community 65505:666 set origin igp ! route-map remote-trigger-black-hole permit 20 ! router bgp 65505 no synchronization bgp log-neighbor-changes redistribute static route-map remote-trigger-black-hole no auto-summary ! ! An example IP that we are applying RTBH filtering to. ! All traffic destined to 10.0.0.1 will now be dropped! ip route 10.0.0.1 255.255.255.255 null0 tag 666 !
宣布路由器：！丢弃路由ip路由192.0.2.1 255.255.255.255 Null0！仅匹配和空AS-PATH。ip作为路径访问列表10允许^$！此路线图匹配带有标记666的路线，并设置下一跳！这是废弃路线。路线图远程触发黑洞允许10匹配标记666设置ip下一跳192.0.2.1设置本地首选项200设置社区不导出！社区内部用于标记RTBH公告。设置社区65505:666设置原点igp！路线图远程触发黑洞许可证20！路由器bgp 65505无同步bgp日志邻居更改重新分配静态路由图远程触发黑洞无自动摘要！我们正在应用RTBH筛选的示例IP！所有发送到10.0.0.1的流量现在将被丢弃！ip路由10.0.0.1 255.255.255.255空0标记666！
Filtering router: ! ! The discard route ip route 192.0.2.1 255.255.255.255 Null0 ! ! Matches and empty AS-PATH only. ip as-path access-list 10 permit ^$ ! route-map black-hole-filter permit 10 match ip address prefix-list only-host-routes match as-path 10
过滤路由器：！丢弃路由ip路由192.0.2.1 255.255.255.255 Null0！仅匹配和空AS-PATH。ip作为路径访问列表10允许^$！路由映射黑洞筛选器允许10匹配ip地址前缀列表仅主机路由匹配为路径10
match community 65505:666 no-export ! ! Don't accept any other announcements with the RTBH community. route-map black-hole-filter deny 20 match community 65505:666 ! route-map black-hole-filter permit 30 ! ! An interface for source-based RTBH filtering with uRPF loose mode. interface FastEthernet 0/0 ip verify unicast source reachable-via any
匹配社区65505:666不导出！不要接受RTBH社区的任何其他公告。路线图黑洞过滤器拒绝20匹配社区65505:666！路线图黑洞过滤器许可证30！使用uRPF松散模式的源代码RTBH过滤接口。接口FastEthernet 0/0 ip验证单播源是否可通过任何
This section provides a partial configuration for configuring RTBH filtering on a Juniper router. This is not a complete configuration and should be customized before being used.
本节提供了在JUniter路由器上配置RTBH过滤的部分配置。这不是一个完整的配置，应在使用前进行自定义。
Announcing router:
宣布路由器：
routing-options {
static {
/* EXAMPLE ATTACK SOURCE */
route 10.11.12.66/32 {
next-hop 192.0.2.1;
resolve;
tag 666;
}
/* EXAMPLE ATTACK DESTINATION */
route 10.128.0.2/32 {
next-hop 192.0.2.1;
resolve;
tag 666;
}
}
autonomous-system 100;
}
routing-options {
static {
/* EXAMPLE ATTACK SOURCE */
route 10.11.12.66/32 {
next-hop 192.0.2.1;
resolve;
tag 666;
}
/* EXAMPLE ATTACK DESTINATION */
route 10.128.0.2/32 {
next-hop 192.0.2.1;
resolve;
tag 666;
}
}
autonomous-system 100;
}
protocols {
bgp {
group ibgp {
type internal;
export rtbh;
neighbor 172.16.0.2;
}
}
}
protocols {
bgp {
group ibgp {
type internal;
export rtbh;
neighbor 172.16.0.2;
}
}
}
policy-options {
policy-statement rtbh {
term black-hole-filter {
from {
tag 666;
route-filter 0.0.0.0/0 prefix-length-range /32-/32;
}
then {
local-preference 200;
origin igp;
community set black-hole;
community add no-export;
next-hop 192.0.2.1;
accept;
}
}
}
community black-hole members 100:666;
community no-export members no-export;
}
policy-options {
policy-statement rtbh {
term black-hole-filter {
from {
tag 666;
route-filter 0.0.0.0/0 prefix-length-range /32-/32;
}
then {
local-preference 200;
origin igp;
community set black-hole;
community add no-export;
next-hop 192.0.2.1;
accept;
}
}
}
community black-hole members 100:666;
community no-export members no-export;
}
Filtering router:
过滤路由器：
policy-statement black-hole-filter {
from {
protocol bgp;
as-path LocalOnly;
community black-hole;
route-filter 0.0.0.0/0 prefix-length-range /32-/32;
}
then {
community set no-export;
next-hop 192.0.2.1;
}
}
community black-hole members 100:666;
community no-export members no-export;
policy-statement black-hole-filter {
from {
protocol bgp;
as-path LocalOnly;
community black-hole;
route-filter 0.0.0.0/0 prefix-length-range /32-/32;
}
then {
community set no-export;
next-hop 192.0.2.1;
}
}
community black-hole members 100:666;
community no-export members no-export;
routing-options {
forwarding-table {
unicast-reverse-path feasible-paths;
}
static {
route 192.0.2.1/32 discard;
}
}
routing-options {
forwarding-table {
unicast-reverse-path feasible-paths;
}
static {
route 192.0.2.1/32 discard;
}
}
interfaces {
xe-1/0/0 {
vlan-tagging;
mtu 9192;
unit 201 {
vlan-id 201;
family inet {
rpf-check;
address 10.11.12.1/24;
}
}
}
}
interfaces {
xe-1/0/0 {
vlan-tagging;
mtu 9192;
unit 201 {
vlan-id 201;
family inet {
rpf-check;
address 10.11.12.1/24;
}
}
}
}
Understanding the history and motivation behind the development of a technique often helps with understanding how to best utilize the technique. In this spirit, we present a history of unicast RPF and RTBH filtering.
了解技术发展的历史和动机通常有助于了解如何最好地利用该技术。本着这种精神，我们介绍了单播RPF和RTBH过滤的历史。
This section has been provided by Barry Raveendran Greene:
本节由Barry Ravendran Greene提供：
Unicast RPF Loose Check (uRPF Loose Check) was created by Neil Jarvis and Barry Greene to be used with destination-based RTBH as a rapid reaction tool to DDoS attacks. The requirements for this rapid reaction tool was based on post mortem conversation after the February 2000 attacks on several big content hosting companies. The summary of the requirement became the "Exodus Requirement" which stated:
单播RPF松散检查（uRPF松散检查）由Neil Jarvis和Barry Greene创建，用于基于目的地的RTBH，作为DDoS攻击的快速反应工具。这种快速反应工具的需求是基于2000年2月几家大型内容托管公司遭受攻击后的事后对话。该要求的摘要成为“出埃及记要求”，其中规定：
We need a tool to drop packets based on source IP address that can be pushed out to over 60 routers within 60 seconds, be longer than a thousand lines, be modified on the fly, and work in all your platforms filtering at line rate.
我们需要一个工具来丢弃基于源IP地址的数据包，这些数据包可以在60秒内推送到60多个路由器，长度超过1000行，可以动态修改，并在所有平台上以行速率进行过滤。
A variety of options were looked at to meet this requirement, from reviving Common Open Policy Service (COPS), to pushing out Access Control Lists (ACLs) with BGP, creating a new protocol. In 2000, the quickest way to meet the "Exodus requirement" was to marry two functions. First, modify unicast RPF so that the interface check was no longer required and to make sure that a "null" or discard route would drop the packet (i.e., loose check). Second, the technique where BGP is used to trigger a distributed drop is dusted off and documented. Combining these two techniques was deemed a fast way to put a distributed capability to drop packets out into the industry.
为了满足这一要求，人们考虑了多种选择，从恢复公共开放政策服务（COPS），到使用BGP推出访问控制列表（ACL），再到创建新的协议。2000年，满足“人口外流要求”的最快方式是将两个职能结合起来。首先，修改单播RPF，以便不再需要接口检查，并确保“空”或丢弃路由将丢弃数据包（即，松散检查）。其次，使用BGP触发分布式丢包的技术已被清除并记录在案。将这两种技术结合起来被认为是将分布式数据包丢弃到行业中的一种快速方法。
To clarify and restate, uRPF loose check was created as one part of a rapid reaction tool to DDoS attacks that "drop packets based on source IP address that can be pushed out to over 60 routers with in 60 seconds, be longer than a thousand lines, be modified on the fly, and work in all your platforms filtering at line rate". The secondary benefits of using uRPF Loose Check for other functions is a secondary benefit -- not the primary goal for its creation.
为了澄清和重申，uRPF松散检查是针对DDoS攻击的快速反应工具的一部分，该工具“基于源IP地址丢弃数据包，这些数据包可以在60秒内推送到60多个路由器，长度超过1000行，可以动态修改，并在所有平台上以行速率过滤”。对其他函数使用uRPF松散检查的第二个好处是第二个好处，而不是其创建的主要目标。
To facilitate the adoption to the industry, uRPF Loose Check was not patented. It was publicly published and disclosed in "Unicast Reverse PathForwarding (uRPF) Enhancements for the ISP-ISP Edge" [Greene2001].
为了便于行业采用，uRPF松散检查未获得专利。它在“ISP-ISP边缘的单播反向路径转发（uRPF）增强功能”[2001]中公开发布和披露。
Authors' Addresses
作者地址
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043
沃伦·库马里谷歌1600圆形剧场公园道山景，加利福尼亚州94043
EMail: warren@kumari.net
EMail: warren@kumari.net
Danny McPherson Arbor Networks, Inc.
丹尼·麦克弗森阿伯网络公司。
EMail: danny@arbor.net
EMail: danny@arbor.net