RFC 3882

1. Existing BGP-Triggered Black-holing Techniques ✨

okay so the old-school way of doing BGP-triggered black-holing 🕳️ works by changing the BGP next hop address of the network being attacked, and that change gets passed around the whole iBGP network 📡. A router in the attacked AS makes a custom iBGP advertisement where the next hop for the targeted network or host points to an RFC 1918 [RFC1918] (private internet) address 🎀. Most routers on the Internet, especially edge routers, have static routes that send RFC 1918 addresses to the null interface, so all the traffic headed to the attacked network gets pulled into the null interface 🗑️.

When an iBGP-speaking router inside the destination AS gets that iBGP update, the advertised prefix goes into its routing table with an RFC 1918 network as the next hop 🧭. The router then tries to resolve that RFC 1918 next hop to qualify the route and figure out which forwarding interface to use. That lookup comes back with the null interface as a valid next hop 💅. As long as the router is set up to send RFC 1918 traffic to a null interface, the traffic aimed at the attacked network gets dropped, and that network becomes unreachable for the attacker and everyone else too 🙈.

Here's the catch, though 😭. This technique does keep the internal infrastructure safe from the attack, which protects a ton of devices, but it also means the targeted network becomes unreachable across the entire destination AS. Even if the static route pointing RFC 1918 addresses to a null interface isn't on every router in the destination AS, the changed next hop still makes the traffic unroutable to its legit destination. It's a whole mess, bestie.

Network operators usually only keep these BGP-triggered black holes up for a short period of time ⏳. The technique drops traffic at every ingress point of the AS for anything headed to the attacked network. By default, routers that drop traffic into a null interface should send an "ICMP unreachable" message to the source address belonging to the origin/attacking AS 📨.

Once things get to this point, one of the source addresses of the attack traffic gets hijacked 🪝, by bringing in a device that uses the same source IP address inside the BGP domain of the destination/attacked AS. That device collects the ICMP unreachable packets 🕵️‍♀️. The source addresses on those ICMP unreachable packets reveal which edge routers within the destination/attacked AS the attack is coming in through 🔍. After that, the network operator may choose to manually stop the traffic on the routers where the attack traffic is entering 🛑.

---

2. Enhanced BGP-Triggered Black-holing Technique 👑

This part describes a technique that was built to tell a selected set of routers to change the next hop address of a particular prefix using the BGP protocol 🦋. The next hop can be either a null interface or, as we'll get into later in this paper, a sinkhole tunnel interface 🧚. This technique doesn't use an access list or a rate limiting statement to deal with attack traffic, and it doesn't change the next hop of the attacked prefix across the whole network 🙅‍♀️. The next hop only gets changed on a selection of routers, with the help of BGP communities inside the destination/attacked AS 💜.

To get the network ready for this technique, the network operator needs to define a unique community value for each destination AS border router that could possibly send attack traffic to the victim 🎀. For example, say a network with BGP autonomous system number 65001 has two border routers, R1 and R2. Community value 65001:1 identifies R1, community value 65001:2 identifies R2, and community value 65001:666 identifies both R1 and R2 at the same time 🌈.

After the BGP community assignments are done, R1 and R2 must be configured with the following:

1. Static route pointing an RFC 1918 network to a null interface.
2. AS-Path access list that matches local BGP prefix advertisement.
3. BGP community access list to match the community value assigned by the network operator for the particular router (i.e., 65001:1 for R1).
4. BGP community access list to match the community value assigned by the network operator for all routers (i.e., 65001:666 for R1 and R2).
5. Under the BGP process, an iBGP import route policy should be applied on received iBGP advertisements to do the following logic. (Statements are in a logical AND order.)
   • a. A policy statement to permit routes that match the following criteria and apply the following changes.
     • i. Match for a community specific to that router (i.e., 65001:1, for R1).
     • ii. Match the AS-Path to locally generated BGP advertisements.
     • iii. Set the BGP next hop to an RFC 1918 network.
     • iv. Overwrite the BGP community with the well-known community (no-advertise).
   • b. A policy statement to permit routes that match the following criteria and apply the following changes.
     • i. Match for a community that covers all routers (i.e., 65001:666).
     • ii. Match the AS-Path to locally generated BGP advertisements.
     • iii. Set the BGP next hop to an RFC 1918 network.
     • iv. Overwrite the BGP community with the well-known community (no-advertise).

Once those policies are set up on R1 and R2, the network operator can, if there's an attack, advertise the targeted network into iBGP of the destination/attacked AS 🚨. That network could be one or more /32 "host" routes. The advertisement must include the community value tied to the router(s) where the attack is arriving, plus the well-known community (no-export) 🫶. Because BGP communities are used, the original next hop address of the targeted network is kept on every router that doesn't have the special route policy configured ✨. iBGP then carries the prefix advertisement to all routers in the destination/attacked AS 🌸. Every router in the destination AS, except the ones matching the community stamped on the prefix, won't even notice the community value and will install the network route with its legit next hop address 🙆‍♀️. The routers that do match the community will also install the network route in their routing table, but they'll change the next hop to an RFC 1918 network and then to a null interface, based on the route policy configuration and a recursive route lookup 💀.

The reason for matching locally announced networks is to make sure no eBGP peer can misuse this community to send any network to a null interface 🔐. Black-holing the targeted/attacked hosts is recommended, but not the whole address block they belong to, so the blackhole has the smallest possible impact on the attacked network 🍓.

This technique stops traffic from being forwarded on to its legit destination on the routers that are identified as transit routers for attack traffic and that have route map matches for the community value tied to the network advertisement 🛑. All the other traffic on the network still gets forwarded to its legit destination, which keeps the impact on the targeted network as small as possible 💖.

3. Sinkhole Tunnels ✨

Okay so, bestie, this is where things get spicy 🌶️. Once you've done the Enhanced BGP-Triggered Black-holing Technique, sometimes you need to actually look at the attack traffic to figure out what's going on 🕵️‍♀️. That makes everything way more complicated, ngl. Usually, on broadcast interfaces, network operators plug a network sniffer into a spanned port of a switch so they can analyze traffic 🔍. Another option is to announce a network prefix covering the attack host address into iBGP and change the next hop to a sinkhole device that logs traffic for analysis. The catch? That second method takes down the services running on the targeted/attacked IP addresses 💀. Inter-AS traffic gets sucked into the sinkhole, and so does the Intra-AS traffic 😭. Packet-level analysis means redirecting traffic away from the destination host to a sniffer or a router. So if the traffic being examined includes legitimate traffic, that legit traffic never makes it to the destination host, and that's a full denial of service for it 🙈.

Okay, so here's the upgrade: a sinkhole tunnel 🦋. A sinkhole tunnel is set up at every possible entry point that attacks could come through into the destination/attacked AS. Using the BGP community technique, traffic headed for the attacked/targeted host can get re-routed onto a special path (a tunnel) where a sniffer can capture it for analysis 🎀. Once it's been analyzed, the traffic exits the tunnel and gets routed normally to the destination host. In other words, the traffic passes through the network to a sniffer without altering the next hop information of the destination network 💅. All routers inside the destination/attacked AS iBGP domain keep the proper next hop address. Only the entry point router gets the altered next hop info 🌸.

Let's walk through the setup, lol 🧚. A sinkhole router, with an optional sniffer attached to its interface, gets installed and configured to participate in the IGP and iBGP of the attacked AS. Next up, a tunnel gets created (MPLS Traffic Engineering is the example here 💜) from every border router attacks could enter from (Inter-AS traffic) to the sinkhole router. When a host or network is under attack, a customized iBGP advertisement gets sent to announce the network address of the attacked host(s), with the proper next hop so traffic still reaches those hosts or networks 🍓. That advertisement also carries a community string value matching the set of border routers the attack is coming in from, as described in section 2 🔥. The new next hop address configured in the route policy section of all border routers should be the sinkhole IP address 👑. That IP address belongs to the /30 subnet assigned to the tunnel connecting the border router to the sinkhole router 🌈.

Routers that don't have a match for the community string just do regular routing 💖. Not matching the community means the special route policy doesn't change the next hop address on them ✨. Traffic entering from border routers without a match on the special community passes through regular router interfaces to the legit destination 🫶. It might also be necessary to let the traffic reach its destination after it's been captured 🦋. In that case, a default network route gets configured to point to any interface attached and configured on the iBGP network. That includes the same physical interface the tunnel is built on 💅. Since the next hop address doesn't change on the sinkhole device, traffic coming in from the tunnel gets sent back into the network thanks to the default route 🎀. Then the routing protocols take care of routing it properly to its original destination (the attacked network) ⭐.

Honestly, this technique is useful for more than just analyzing attack traffic 😭. Legit traffic can also be pulled out of normal routing into a tunnel and then reinserted into the backbone, without changing the next hop addressing scheme across the whole iBGP network 💜.

MPLS Traffic Engineering, with all its features, is a great way to slide traffic over to the sinkhole device 🧚. Features like QoS policies can be applied to the attack traffic, which stops it from fighting over resources with the legitimate traffic 👑.

To change the next hop on the border router, a subnet of an RFC 1918 network gets statically routed to the tunnel interface 🌸. Here's an example of the static route:

ip route 192.168.0.12 255.255.255.255 Tunnel0

Setting the next hop of the target IP address to 192.168.0.12/32 forces the traffic through the tunnel 🦋.

Traffic arrives at the sinkhole interface via the TE tunnel 🌈. Then three methods can be installed: rate-limiting policies, QoS policies, and access lists 💅. These policies can rate limit or drop traffic classified as attack traffic 🔥. All of this happens on the interface of the sinkhole device 🎀. Another useful trick for a sinkhole router is to pull traffic in through tunnels to an inbound interface, with a default route statement forwarding it out to an Ethernet interface 🍓. That Ethernet interface connects to the iBGP network, guarantees proper delivery, and still lets you use a packet sniffer to dig into the attack traffic 🕵️‍♀️.

This gets super useful when you can't apply an access list or rate limiting statement on the BGP border router or last hop router before the attacked host or network, because of hardware or software limitations 😭. So instead of upgrading interfaces at the point of entry for the attack traffic, you can pull that traffic into the sinkhole and deal with it there 💖. If the sinkhole router is a powerful device, operational costs can stay minimal 🫶.

---

4. Security Considerations 🔐

Okay, this part is seriously important, bestie 😤. It is very important to keep tight control over eBGP peering points before you implement any of the techniques described in this paper 🚨. eBGP customers might be able to blackhole a particular subnet using the Blackhole communities 💀. To eliminate that risk, you must not skip the match for locally generated BGP advertisements in the special route policy 🙅‍♀️.

Seriously, don't skip that match. Anyone who can blackhole your subnets is a whole disaster 😭.

5. Acknowledgments 🫶

The author of this document wants to shout out the developers of the remotely triggered black-holing technique 🙌, and the developers of the backscatter technique for collecting backscatter traffic 🌈. The author also wants to thank all the members of the IP Engineering department for helping verify that this technique actually works 💜.

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

7. Author's Addresses 🎀

Doughan Turk Bell Canada 100 Wynford Drive

EMail: doughan.turk@bell.ca

8. Full Copyright Statement ©️

Copyright (C) The Internet Society (2004).

This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🧠

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.

Acknowledgement 💖

Funding for the RFC Editor function is currently provided by the Internet Society.