RFC 5635
Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)
RFC 5635: Remote Triggered Black Hole Filtering with uRPF 🦋
okay bestie, let's get into it 💅 This is RFC 5635, written by W. Kumari (Google) and D. McPherson (Arbor Networks) in August 2009. It's Informational, so it's sharing knowledge with the Internet community, not setting a standard 🎀 It doesn't list anything it obsoletes or updates, so it's a solo main character 👑
Abstract ✨
Remote Triggered Black Hole (RTBH) filtering is a super popular and effective way to stop denial-of-service attacks 🔥 This doc builds on destination-based RTBH filtering and shows how to filter by source address too 🌸
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.
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.
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 ...............................141. Introduction 💖
okay so this doc takes the technique from "Configuring BGP to Block Denial-of-Service Attacks" [RFC3882] and levels it up 🚀 It shows a way to filter by source address(es) 😭
Network operators have a whole bag of tricks for handling DoS attacks 🧰 Each one has its own strengths and weaknesses, so from an implementation perspective, picking the right method for each kind of attack means weighing the tradeoffs of every option 💅
A classic DoS move is aimed at a customer of a service provider. The attacker sends way more attack traffic at the target than the links from the service provider(s) to the victim (customer) can carry 💀 That traffic "starves out" the legit stuff, and it often causes collateral damage or other bad effects for other customers or the network infrastructure too 🙈 Instead of letting every destination on their network get hit, the customer can ask their service provider to filter traffic going to the target IP address(es). Or the service provider can decide that's necessary on their own to keep the network available 🫶
One way a service provider can do this filtering is by deploying access control lists on the edge of their network ✨ That's flexible, but it hits scalability issues, both in how many entries the filter can hold and in the packet rate 😩
Most routers can forward traffic way faster than they can filter it, and they can hold many more forwarding table entries and routes than filter entries 🏎️ RTBH filtering takes advantage of that forwarding speed, so it can filter more entries and at a higher rate than access control lists would normally allow 🔥
Now the catch: with destination-based RTBH filtering, the impact on the target is complete 😭 Destination-based RTBH injects a discard route into the forwarding table for the target prefix. Then every packet headed to that destination, attack traffic AND legit traffic, gets dropped by the participating routers, and the target is totally offline 💔 The upside is that collateral damage to other systems or to network availability at the customer location or in the ISP network is limited. The downside is that the hit to the target itself is arguably bigger 🥺
Here's where it gets fun 🦋 By pairing unicast Reverse Path Forwarding (uRPF) [RFC3704] with RTBH filtering, BGP can distribute discard routes based not on destination or target addresses, but on the source addresses of unwanted traffic 🎀 Heads up though: this drops all traffic to/from the address, not just the traffic going to the victim ⚠️
⚠️ Note: dropping by source means all traffic to and from that address gets dropped, not only the traffic aimed at the victim.
This doc is split into three logical parts 🍓 The first explains how to configure destination-based RTBH, the second covers source-based RTBH, and the third has examples and a history of the technique 📚
2. Terminology 🎀
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].
3. Destination Address RTBH Filtering 🌸
3.1. Overview 🧁
okay so a discard route gets installed on each edge router in the network, with the destination set to the discard (or null) interface 🕳️ To use RTBH filtering for a single IP address (or prefix), you announce a BGP route for the address you want filtered, with the next-hop set as the discard route. Then traffic going to the announced prefix gets forwarded to the discard interface 🗑️ It never transits the network, which saves resources and stops collateral damage to other stuff along the path toward the target 🙌
Yes, this "completes" the attack in the sense that the target address(es) become unreachable 😭 But the collateral damage is kept to a minimum 💅 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 🧚 iykyk, it's giving resilience 💜
3.2. Detail
okay bestie, before you turn on RTBH filtering you gotta do some prep and planning 📋✨ there are some decisions you need to make first:
- What are the discard addresses?
- What are the discard BGP communities?
- What is the largest prefix that can be black-holed?
- What is the smallest advertisement that your provider will accept?
Here's how to set up destination-based RTBH filtering, step by step 🎀
Step 1. Select Your Discard Address Schema
So you pick an address to be the "discard address" 🦋 people usually grab one from 192.0.2.0/24 (TEST-NET [RFC3330]) or from RFC 1918 [RFC1918] space. Using multiple addresses lets you set up multiple static routes, one for each incident:
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 #5Customer #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 the router can do it, it can then count the drops for each one 📊 which gives you some telemetry on how much is being dropped and how an ongoing attack is going. A consistent address schema makes operations so much easier 💅
Step 2. Configure the Discard Route(s) on Each Router
A route for the "discard address" gets installed on the routers that form the edge/perimeter of the network 🌸 that's 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 shows that it's really valuable to configure each ingress router with the ability to drop traffic via RTBH filtering 🔥
Step 3. Configure the RTBH BGP Policy on Each Router
A BGP policy gets configured on every router that has 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 host addresses get accepted. Basically, you typically only need specific /32s. Shorter prefix blocks may also be required or desirable, for example, if larger numbers of attack targets are located within a single prefix, or if the point of this mechanism is to drop traffic bound for specific networks. When you filter based on shorter prefixes, extreme caution should be used to avoid collateral damage to other hosts that live in 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. Main character planning, honestly 👑
Step 4. Configure the Safety Egress Prefix Filters
There's always a chance that the triggering BGP update could leak out of the network, so egress prefix filters are strongly recommended 😭 These egress prefix filter details may vary, but experience has shown that the following works:
- 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 adds a safe measure in case the NO_EXPORT community does not work.
- Deny all communities used for triggering RTBH filtering. This is also a "safety" measure in case the NO_EXPORT community does not work.
Step 5: Configure the Trigger Router
Set up 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 lets you use a low-cost router/workstation as the trigger router. Budget-friendly and iconic 💖
Using the RTBH filtering:
1: When you want RTBH filtering for a specific address, that address gets 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 and set the next-hop to be the discard route, which results in a Forwarding Information Base (FIB) entry pointing to a discard address 🎯
2: Traffic entering the network will now be forwarded to the discard interface on all edge routers, so it gets dropped right at the edge of the network, saving resources 🍓
2.1: Multiple Discard Addresses for Incident Granularity. This technique can be expanded by having multiple discard addresses, routes, and communities, so you can monitor the discarded traffic volume on devices that support multiple discard interfaces. As mentioned earlier, each router can have a discard address schema that lets the operator tell multiple incidents apart from each other -- making it way easier to monitor the life-cycle of each incident 🦋
2.2: Multiple "Trigger Communities" for Network-Wide Granularity. The network can be sectioned into multiple communities, giving the operator the ability to drop traffic 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):
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:604 RTBH filtering on all customers (to see how many
customers are being used by the attacker)Some diligent thinking is required to develop a community schema that's flexible while still reflecting topological considerations 🧠💜
2.3: "Customer-Triggered" RTBH filtering. This technique can also be expanded by relaxing the Autonomous System (AS) path rule, so customers of a service provider can 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. That way the customer can't accidentally (or intentionally) black-hole space they aren't allowed to advertise 🚫
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.
Extreme caution should be used to avoid leaking any more specifics beyond the local routing domain, unless policy explicitly aims at doing just that ⚠️
4. Source Address RTBH Filtering ✨
In many instances, denial-of-service attacks sourced from botnets are configured to "follow DNS" 💀 (The attacking machines are instructed to attack www.example.com and re-resolve it periodically. Historically, the attacks were aimed simply at an IP address, so renumbering www.example.com to a new address was an effective mitigation.) This makes it desirable to use a technique that lets black-holing be based on source address 🦋
By combining traditional RTBH filtering with unicast Reverse Path Forwarding (uRPF), a network operator can filter based on the source address. uRPF performs a route lookup of the source address of the packet and checks whether the ingress interface of the packet is a valid egress interface for the packet source address (strict mode), or whether 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 is what allows source-based RTBH filtering to be deployed in networks that 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:
- 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.
- Loose mode causes the router to check whether 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.
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 the ingress edge) of their network, based on source address 🎯
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 so that peers can only announce source-based RTBH routes for prefixes that they originate 👑
4.1. Steps to Deploy RTBH Filtering with uRPF for Source Filtering
The same steps 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 causes the route to be installed with a next-hop of the discard interface, which makes the uRPF check fail so the packets get 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 💅
The BGP policy will need to be relaxed to accept announcements tagged with this community, even though they contain addresses not controlled by the network announcing them. These announcements must NOT be propagated outside the local AS, and they should carry the NO_EXPORT community 🔒
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 🫶💖
5. Security Considerations 🔐
okay bestie, this part is SERIOUS 😭 the techniques here have enough power to cause significant traffic forwarding loss if they're deployed incorrectly 💀 so it is imperative that the announcements that trigger the black-holing get carefully checked ✅, and that the BGP policy accepting them is set up so the announcements:
- Are not propagated outside the AS (NO_EXPORT). 🚫
- Are not accepted from outside the AS (except from customers). 🙅♀️
- Except where source-based filtering is deployed, cover a network that falls within the address ranges controlled by the announcing AS (i.e., for customers, the address falls within their space). 🗺️
6. Acknowledgments 🫶
okay so the authors wanna thank Joe Abley, Ron Bonica, Rodney Dunn, Alfred Hoenes, Donald Smith, Joel Jaeggli, and Steve Williams for their help, feedback, and for not laughing too much at the quality of the initial versions 😭🎀
they also thank all the regular contributors to the OPSEC Working Group and Google for 20% time :-) 🌈
and the authors would also like to thank Steven L Johnson and Barry Greene for getting this implemented 🔥, plus Chris Morrow for publicizing the technique in multiple talks 🎤✨
7. References 📚
7.1. Normative References 💜
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,
G., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September
2002.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3882] Turk, D., "Configuring BGP to Block Denial-of-Service
Attacks", RFC 3882, September 2004.7.2. Informative References 🦋
[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.Appendix A. Cisco Router Configuration Sample 🍓
okay so this section gives a partial config for RTBH filtering on a Cisco router 🧚 it is NOT complete, so customize it before using it 💅
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
!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
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 anyAppendix B. Juniper Configuration Sample 🧸
okay this section is also a partial config, this time for a Juniper router 🎀 again, NOT complete, so customize before using 💖
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;
}
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;
}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;
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;
}
}
}
}Appendix C. A Brief History of RTBH Filtering 🕰️
okay so understanding the history and motivation behind a technique helps you figure out how to best use it 🧠 so let's go back in time, bestie ✨ we're gonna look at the history of unicast RPF and RTBH filtering 💫
this section was provided by Barry Raveendran 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 tool came from a post mortem conversation after the February 2000 attacks on several big content hosting companies 😱 the summary of the requirement became the "Exodus Requirement", which said:
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.
a bunch of options were looked at to meet this, from reviving Common Open Policy Service (COPS), to pushing out Access Control Lists (ACLs) with BGP, to creating a brand new protocol 🤯 in 2000, the quickest way to meet the "Exodus requirement" was to marry two functions 💍 first, modify unicast RPF so the interface check was no longer required, and make sure 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 got dusted off and documented ✨ combining these two was deemed a fast way to put a distributed capability to drop packets out into the industry 🚀
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 are a secondary benefit, not the primary goal for its creation 🙃
to help with adoption across 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]. 💅
Authors' Addresses 📮
Warren Kumari
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
EMail: warren@kumari.net
Danny McPherson
Arbor Networks, Inc.
EMail: danny@arbor.net📦 where this page comes from
- ietf: rfc5635 2009-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms