fbpx

Network-Engineering | 22 min read

Black Hole Routing

March 2021
written by Nigel Wensley
Senior Network Engineer

This article introduces Black Hole routing. ngworx is an elite partner of Arista and Juniper so configuration examples are given for both vendors. You can progress to detailed technical guides in the reference section at the end and find information with a simple web search “remote triggered black hole”.

1. Introduction

In IP routing, a Black Hole (BH) drops traffic. This can mean traffic is unintentionally dropped or “Black Holed” due to missing routing information, but this article is about the Black Hole which is purposefully configured as a useful network tool.

A router creates a Black Hole which drops traffic by forwarding traffic to the Null device. In computing, the Null device is a “bit bucket” which discards any data you send to it. This is useful in programming for example.

This simple static route is a Black Hole for traffic to host 1.1.1.1

ip route 1.1.1.1/32 Null0

A Black Hole can be a single static route, but the concept can expand to a detailed configuration on many routers with automatically triggered BGP updates which Black Hole traffic in response to real time analysis of flow data. The BGP routing protocol allows the Black Hole concept to scale and be coordinated on multiple routers between different network owners.

The need to Black Hole traffic typically only applies to external network connections to the Internet and other networks you do not control, rather than internal connections of your own private network. A Black Hole is therefore ideally located at the network edge to limit processing and conserve your resources. Here, the routing Black Hole acts like a simple stateless firewall filter providing temporary network layer security.

Black Hole routing might be used by any private or public organisation with a large network, for example a bank. Typically, Internet Service Providers and Internet Exchange Points use Black Hole routing and publish detailed instructions to peers and customers on how to trigger the Black Hole remotely.

A Black Hole can form part of your security best practice by dropping IP Bogon routes and address space from unauthorized sources.

More typically, a routing Black Hole is associated with mitigating a Denial of Service (DoS) attack, in which traffic originating from the Internet is directed at a public IPv4 or v6 address with the intention of making the service unavailable for legitimate users by depleting its resources (bandwidth, CPU, disk, memory). A DoS attack can be purchased on the Internet for a trivial sum and offers include a free test proving it works!

A Black Hole can itself create a Denial of Service, in this case, called a Denial of Reachability. In 2008, YouTube was offline for 2 hours when an Internet Service Provider trying to block access in their country created a Black Hole configuration that leaked to the wider Internet. Check out the article here.

Implementing a Black Hole is widely supported as all operating systems include the Null device and enough configuration options to drop IP traffic using it. Discarding data using the Null device consumes almost no system resources and can be implemented effectively anywhere including powerful routers and small PC-engines.

Did you know ngworx are the Managed Support Provider of SwissIX the Switzerland Internet Exchange Point (IXP)? Like many Internet Exchanges around the world SwissIX deploys Black Hole routing to protect the peering fabric. See swissix.ch.

2. Identifying Traffic

The following examples assume a DoS attack scenario to demonstrate Black Hole routing. At minimum, you must identify a source or destination IP address to block. The IP address mask could be any length, e.g. /32, /28, /24.

2.1. Identify Destination IP

Black Hole Routing

MY-NET host 1.1.1.1 is being DoS attacked and the source of the attack cannot be easily identified. The attack traffic is depleting MY-NET Internet bandwidth causing other services to fail so they Black Hole traffic to their host 1.1.1.1. This means the host is unavailable even to legitimate users and therefore, the DoS attack is 100% successful. When the attack traffic stops, MY-NET can remove the Black Hole configuration and bring the Web Server online again.

For MY-NET, the best outcome is to only need to Black Hole one of their IP addresses with a /32 or /128 address mask. However, if more than one host is being attacked or the target addresses belong to multiple networks, the Black Hole targets may be larger subnets, you must find a set of address masks that match the attack targets.

The worst outcome is MY-NET must Black Hole their entire IP address space advertised to the Internet, meaning they lose Internet access.

2.2. Identify Source IP

Black Hole Routing

With troubleshooting, MY-NET can see source IP addresses 3.3.3.3 and 4.4.4.4 are DoS attacking their host 1.1.1.1.

In the MY-NET routing table, the BGP advertisements for these IP addresses belong to the larger networks 3.3.3.0/24 and 4.4.4.0/23. MY-NET decides to Black Hole the entire source networks rather than the individual host addresses, meaning no hosts in those networks can reach any address belonging to MY-NET.

The DoS attack is unsuccessful because legitimate Internet traffic from other networks can still reach host 1.1.1.1.

2.3. Identify with Flow Data

To identify unwanted traffic, the routing table must be inspected but analysis of flow data is likely more helpful. The routing table contains only IP layer 3 information whereas flow data is more precise with layer 4 information including TCP/IP port and protocol.

Using a Black Hole to mitigate a large-scale DoS attack by dropping selected IP addresses lacks precision and can drop legitimate traffic.

Identifying unwanted traffic is greatly improved by the BGP Flow-spec Multi-Protocol extension which advertises IP flow information, meaning layer 3 and 4 information is available to identfy traffic.

Flow-spec defines new BGP address families (NLRI) to advertise flow information including IP source and destination prefix, TCP or UDP source and destination port, TCP flag, and ICMP type. Flow-spec also defines Rules for traffic handling which are signalled by BGP community to trigger an action including drop, police, mark, and redirect. For Flow-spec details see IETF “Dissemination of Flow Specification Rules” tools.ietf.org/html/rfc8955.

You can research how to Black Hole using BGP Flow-spec with a simple web search “flowspec black hole”.

You can also read about the further evolution of controlling DoS attacks by reviewing IETF “DDoS Open Threat Signalling” (dots) datatracker.ietf.org/wg/dots/about, a method to signal DoS attack information using telemetry.

3. Static Routing Black Hole

3.1. Temporary Static Route

3.1.1. Black Hole Destination

Static routes are only destination based. You cannot configure a static route to match a source IP address! But you can match source addresses using Access Lists and Firewall Filters for example.

To Black Hole destination 1.1.1.1 configure a static route with the next-hop set to the Null device e.g. Null0, discard, reject.

Arista

ip route 1.1.1.1/32 Null0

Juniper

set routing-options static route 1.1.1.1/32 discard

3.1.2. Black Hole Source

This requires a static route and Unicast Reverse Path Forwarding (uRPF) enabled on the interface where unwanted traffic is received.

To Black Hole source 1.1.1.1

  • Configure a static route for destination 1.1.1.1 with the next-hop set to the Null device.
  • Enable uRPF in Loose mode on the incoming interface.

Arista

ip route 1.1.1.1/32 Null0 
interface ethernet1/1
ip verify unicast source reachable-via any

Juniper

set routing-options static route 1.1.1.1/32 discard
set interfaces xe-0/0/0 unit 0 family inet rpf-check mode loose
set forwarding-options rpf-loose-mode-discard family inet

Static routes are destination-based so it is confusing in this scenario, the static route destination is the source we want to drop! The intention is the static route must cause the Reverse Path Forwarding check on the incoming interface to fail which triggers the traffic to be dropped. This requires a short explanation of Reverse Path Forwarding.

3.1.3. Reverse Path Forwarding

IP Unicast routing is destination-based. Routers forward data towards destinations and maintain a Routing Information Base (RIB) of destinations. Conversely, IP Multicast routers forward data away from sources and maintain a RIB of sources and groups. This source-based routing is called Reverse Path Forwarding.

Reverse Path Forwarding is also a test, check, or condition, that must be TRUE when multicast data is received on an interface before the data can be forwarded (to a receiver). The test is: the interface multicast packets are received on must also be the forwarding interface used by the route to the source IP address in the received packet. In multicast networks, the reason for the test is to stop routing loops forming back to the source. If the RPF test fails with a FALSE result, the traffic is dropped.

Unicast Reverse Path Forwarding (uRPF) applied in destination-based routing uses the same RPF test. This protects against IP spoofing and DoS attacks where the source address may be un-routable or an IP bogon address. If for example the IP packet source address belongs to your own internal network but you have received the packet on an external connection, it should be dropped.

RPF has 2 modes of operation – Strict and Loose modes. The test condition just described is Strict mode and the RPF default. In Loose mode, the RPF test passes if there is a valid route for the source IP address out any interface, not only the interface where the traffic was received. To Black Hole traffic by source address, we use Loose mode; we want the test to fail when the next-hop is the Null device because this is not a valid forwarding path, so the traffic should be dropped.

What causes the RPF test to fail can vary between different network vendors, platforms, and even between different software versions from the same vendor! Another interesting consideration of whether the RPF test fails is whether there is a default route or not. See: www.juniper.net/documentation/en_US/junos/topics/task/configuration/interfaces-configuring-unicast-rpf.html

Note that the configuration shown above includes the forwarding option “rpf-loose-mode-discard”, the command option is named to tell us that traffic failing the RPF check in Loose Mode will be discarded.

Below, we see a Juniper MX router drops traffic with source address 1.1.1.1 which fails the RPF test because of a static route for 1.1.1.1 to the Null device. The output shows interface counters incrementing for “RPF Failures” and that Loose mode is in use.

juniper> show route 1.1.1.1
 
1.1.1.1/32         *[Static/5] 22:43:57
                      Discard
                    [BGP/170] 22:48:18, localpref 100
                      AS path: 1 I, validation-state: unverified
                    > to 10.0.81.0 via xe-0/0/3.0
 
juniper> show interfaces xe-0/0/3 extensive | match RPF   
      Flags: Sendbcast-pkt-to-re, uRPF, uRPF-loose
      RPF Failures: Packets: 17, Bytes: 1428

In reality the ability to Black Hole by source address is limited as DoS attacks often use spoofed source addresses that change randomly!

3.2. Permanent & Temporary Static Routes

3.2.1. Black Hole Destination

Configure a Black Hole static route to an unused IP address as a permanent part of the router configuration.

Arista

ip route 192.0.2.1/32 Null0

Juniper

set routing-options static route 192.0.2.1/32 discard

A best practice suggestion for the static routes is use address space 192.0.2.0/24 (RFC3330 TEST-NET) or private ranges 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 (RFC1918).

juniper> show route protocol static   
 
192.0.2.1/32       *[Static/5] 00:05:47
                       Discard

To Black Hole destination 1.1.1.1, configure a temporary static route with the next-hop set to a permanent Black Hole static route e.g. 192.0.2.1.

Arista

ip route 1.1.1.1/32 192.0.2.1

Juniper

set routing-options static route 1.1.1.1/32 next-hop 192.0.2.1 resolve

The next-hop of the temporary static route is indirect and resolved recursively through the permanent static route which results in a next-hop of the Null device and the traffic is dropped. Note that Arista static routes are recursive by default but Juniper requires the resolve keyword. Remove the temporary static route once the problem traffic event is over.

juniper> show route 1.1.1.1                                        
 
1.1.1.1/32         *[Static/5] 00:00:08, metric2 0
                      to Discard
                    [IS-IS/18] 00:02:03, metric 16777214
                    >  to 10.0.13.0 via ae13.0
 
juniper> show route 1.1.1.1 detail
 
1.1.1.1/32 (2 entries, 1 announced)
        *Static Preference: 5
                Next hop type: Indirect, Next hop index: 0
                Next hop type: Discard, Next hop index: 0
                Protocol next hop: 192.0.2.1
                ...

3.2.2. Black Hole Source

The configuration is the same as the earlier temporary static route example explaining Reverse Path Forwarding.

  • Configure a Black Hole static route to an unused IP address as a permanent part of the router configuration.
  • Enable uRPF on the interface where unwanted traffic is received.

Arista

ip route 192.0.2.1/32 Null0 
interface ethernet1/1
ip verify unicast source reachable-via any

Juniper

set routing-options static route 192.0.2.1/32 discard
set interfaces xe-0/0/0 unit 0 family inet rpf-check mode loose
set forwarding-options rpf-loose-mode-discard family inet

To Black Hole source 1.1.1.1, configure a temporary static route for destination 1.1.1.1 with the next-hop set to the permanent Black Hole static route.

Arista

ip route 1.1.1.1/32 192.0.2.1

Juniper

set routing-options static route 1.1.1.1/32 next-hop 192.0.2.1 resolve

The uRPF test should fail and the traffic is dropped. Remove the temporary static route once the problem traffic event is over.

4. Remote Trigger Black Hole

A Remote Trigger Black Hole (RTBH) means an address to be dropped (Black Holed) is advertised in BGP from a Trigger router causing a Remote router receiving the unwanted traffic to install in its routing table a best route for the address to be Black Holed with a next-hop of the Null device.

The Remote Trigger Black Hole can be created with a combination of static routes and BGP. Because BGP is used, any number of remote routers can be triggered to Black Hole an address.

The Remote Triggered Black Hole is a centralised solution because the Black Hole is controlled by one point, the trigger device. The trigger can be any BGP speaker which may be a workstation, a router, or a dedicated Route Server.

The traffic is only Black Holed if the router receiving the BGP update is correctly configured to recognise and act upon it, in this case, with a static route to the Null device for the next-hop in the update.

The trigger and remote routers can be internal BGP peers in the same ASN or external BGP peers in a different ASN, if both external peers agree on a configuration to trigger a Black Hole in each other’s network. Some BGP configuration discussed later is required for safety, to limit the Black Hole scope and not affect the wider Internet.

There is slightly different BGP configuration required depending on whether the trigger and remote router are internal or external BGP peers.

4.1. Internal BGP

4.1.1. Black Hole Destination

4.1.1.1 Remote Router

Configure the remote (edge) router with a Black Hole static route to an unused IP address as a permanent part of the router configuration.

If desired, you can configure multiple static routes with different next-hops as shown for use by the trigger router to differentiate Black Holed addresses by next-hop.

Arista

ip route 192.0.2.1/32 Null0
ip route 192.0.2.2/32 Null0
...
ip route 192.0.2.254/32 Null0

Juniper

set routing-options static route 192.0.2.1/32 discard
set routing-options static route 192.0.2.2/32 discard
...
set routing-options static route 192.0.2.254/32 discard
4.1.1.2. Trigger Router

To Black Hole destination 1.1.1.1

  • Configure a temporary static route with the next-hop set to a permanent Black Hole static route.
  • Redistribute the temporary static route into BGP.

Arista

ip route 1.1.1.1/32 Null0 tag 666
router bgp 1
redistribute static route-map RM-IBGP-OUT
route-map RM-IBGP-OUT permit 10 
match source-protocol static
match tag 666
set ip next-hop 192.0.2.1 
set local-preference 4294967295
set origin igp 
set community no-export

Juniper

set routing-options static route 1.1.1.1/32 discard tag 666
set protocols bgp group GRP-IBGP export POL-IBGP-OUT
set policy-options policy-statement POL-IBGP-OUT term TERM-10 from protocol static
set policy-options policy-statement POL-IBGP-OUT term TERM-10 from tag 666
set policy-options policy-statement POL-IBGP-OUT term TERM-10 then next-hop 192.0.2.1
set policy-options policy-statement POL-IBGP-OUT term TERM-10 then local-preference 4294967295
set policy-options policy-statement POL-IBGP-OUT term TERM-10 then origin igp
set policy-options policy-statement POL-IBGP-OUT term TERM-10 then community add COM-NO-EXPORT
set policy-options policy-statement POL-IBGP-OUT term TERM-10 then accept
set policy-options community COM-BLACKHOLE members 1:666
set policy-options community COM-NO-EXPORT members no-export

The remote router receives the BGP update for 1.1.1.1 and resolves the next-hop 192.0.2.1 through the Black Hole static route, which results in a next-hop of the Null device and the traffic is dropped.

  • Set the BGP Local Preference high and the Origin low to ensure the Black Hole trigger route is chosen as the best path.
  • Route tag 666 is traditionally used to identify Black Hole routes but any value can be used. Note “tag” is not a BGP attribute!
  • The NO_EXPORT community is attached to stop the update being advertised outside your own ASN which might cause routing issues. If you use a BGP confederation attach NO_ADVERTISE instead.

Before Trigger

There is a valid route for 1.1.1.1

juniper> show route 1.1.1.1
 
1.1.1.1/32         *[BGP/170] 00:00:12, localpref 100, from 10.0.13.1
                      AS path: I, validation-state: unverified
                    >  to 10.0.12.1 via ae12.0

After Trigger

The remote router now discards 1.1.1.1

juniper> show route 1.1.1.1   
 
1.1.1.1/32         *[BGP/170] 00:00:11, localpref 100, from 10.0.13.1
                      AS path: I, validation-state: unverified
                      to Discard
 
juniper> show route 1.1.1.1 detail
 
inet.0: 38 destinations, 38 routes (38 active, 0 holddown, 0 hidden)
1.1.1.1/32 (1 entry, 1 announced)
        *BGP    Preference: 170/-101
                Next hop type: Indirect, Next hop index: 0
                Next-hop reference count: 2
                Source: 10.0.13.1
                Next hop type: Discard, Next hop index: 0
                Protocol next hop: 192.0.2.1
                Indirect next hop: 0xc8bc750 131070 INH Session ID: 0x0
                State: <Active Int Ext>
                Local AS:     1 Peer AS:     1
                Age: 14         Metric2: 0
                Validation State: unverified
                Task: BGP_1.10.0.13.1
                Announcement bits (3): 0-KRT 6-BGP_RT_Background 7-Resolve tree 4
                AS path: I
                Communities: 2:666
                Accepted
                Localpref: 100
                Router ID: 10.0.0.3

4.1.2. Black Hole Source

The configuration is the same as the previous example with the addition of Unicast Reverse Path Forwarding on the remote router interface where the unwanted traffic is received.

Arista

interface ethernet1/1
ip verify unicast source reachable-via any

Juniper

set interfaces xe-0/0/0 unit 0 family inet rpf-check mode loose
set forwarding-options rpf-loose-mode-discard family inet

4.2. External BGP

Unlike the internal BGP example, the trigger router cannot advertise a next-hop matching the remote routers Black Hole static route. By default, the BGP next-hop attribute of an external BGP update is the advertising routers interface address and this cannot be changed to any arbitrary IP address you choose. Instead, the remote router sets the next-hop when it receives the update from the trigger router.

Another important external BGP consideration is the IP prefix length advertised. The Internet best practice is no prefix longer than /24 for IPv4 or /48 for IPv6 should be advertised; most Internet Service Providers reject longer prefixes. Put another way, the Internet routing table does not generally contain address masks longer than /24 or /48, such as host addresses which are /32 or /128.

This is a problem for Black Hole routing, as ideally the most specific prefix possible should be advertised to limit the scope of traffic dropped to only that which is genuinely unwanted e.g. /32 instead of /24.

If you wish to trigger a Black Hole in a remote network by advertising an IP prefix with external BGP, it may not be possible to Black Hole a host with a /32 address mask due to the routing policy of your peer who may not accept advertisements longer than /24 or /48. When Black Holing a source in particular, it is likely you will have to select a larger network range encompassing the host address that matches a BGP advertisement or Local Internet Registry entry.

The IETF RFC 3882 recommends the Black Hole prefix the trigger router advertises should belong to a subnet the network is authorized to advertise. e.g. only advertise Black Hole prefix 1.1.1.1/32 if you own and advertise 1.1.1.0/24.

4.2.1. Black Hole Destination

4.2.1.1. Remote Router
  • Configure the remote (edge) router with a Black Hole static route to an unused IP address as a permanent part of the router configuration.
  • Configure a Route Map to match the Black Hole community and set the next-hop to the permanent static route.

Arista

ip route 192.0.2.1/32 Null0 tag 666
ip community-list BLACKHOLE permit 1:666
router bgp 2
redistribute static route-map RM-EBGP-IN
route-map RM-EBGP-IN permit 10 
match community BLACKHOLE
set ip next-hop 192.0.2.1

Juniper

set routing-options static route 192.0.2.1/32 discard
set protocols bgp group GRP-EBGP import POL-EBGP-IN
set policy-options policy-statement POL-EBGP-IN term BLACKHOLE from community COM-BLACKHOLE
set policy-options policy-statement POL-EBGP-IN term BLACKHOLE then next-hop 192.0.2.1/32
set policy-options community COM-BLACKHOLE members 1:666
4.2.1.2. Trigger Router

To Black Hole destination 1.1.1.1

  • Configure a temporary static route with the next-hop set to a permanent Black Hole static route.
  • Redistribute the temporary static route into BGP.

Arista

ip route 1.1.1.1/32 Null0 tag 666
router bgp 1
redistribute static route-map RM-EBGP-OUT
route-map RM-EBGP-OUT permit 10 
match source-protocol static
match tag 666
set origin igp 
set community 1:666
set community no-export

Juniper

set routing-options static route 1.1.1.1/32 discard tag 666
set protocols bgp group GRP-EBGP export POL-EBGP-OUT
set policy-options policy-statement POL-EBGP-OUT term TERM-10 from protocol static 
set policy-options policy-statement POL-EBGP-OUT term TERM-10 from tag 666
set policy-options policy-statement POL-EBGP-OUT term TERM-10 then origin igp 
set policy-options policy-statement POL-EBGP-OUT term TERM-10 then community add COM-BLACKHOLE
set policy-options policy-statement POL-EBGP-OUT term TERM-10 then community add COM-NO-EXPORT
set policy-options policy-statement POL-EBGP-OUT term TERM-10 then accept
set policy-options community COM-BLACKHOLE members 1:666
set policy-options community COM-NO-EXPORT members no-export

The remote router receives the BGP update for 1.1.1.1 and resolves the next-hop 192.0.2.1 through the Black Hole static route, which results in a next-hop of the Null device and the traffic is dropped.

juniper> show route 1.1.1.1           
 
1.1.1.1/32         *[BGP/170] 02:36:00, localpref 100, from 10.0.81.0
                      AS path: 1 I, validation-state: unverified
                      Discard
 
juniper> show route 1.1.1.1 detail
 
inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
1.1.1.1/32 (1 entry, 1 announced)
        *BGP    Preference: 170/-101
                Next hop type: Discard, Next hop index: 0
                Address: 0x283fccc
                Next-hop reference count: 4
                State: <Active Ext>
                Local AS:     2 Peer AS:     1
                Age: 2:36:06
                Validation State: unverified
                Task: BGP_1.10.0.81.0
                Announcement bits (1): 0-KRT
                AS path: 1 I
                Communities: 1:666 no-export
                Accepted
                Localpref: 100
                Router ID: 10.0.0.1

The BGP community 666 BLACKHOLE is assigned by the IANA. This community is Well Known, Optional, Transitive, and therefore, can be advertised to external BGP peers to trigger a Black Hole action. See IANA and IETF RFC.

4.2.1.3. Remote Router Alternative

We continue to use static routes in this scenario but many configurations are possible depending on the network device.

For example, in Juniper Junos the remote router receiving the Black Hole trigger route can set the next-hop to the Null device directly instead of matching a static route to the Null device.

Example Remote Router BGP Inbound Policy

set policy-options policy-statement EXT-IN term BH from community COM-BLACKHOLE
set policy-options policy-statement EXT-IN term BH then next-hop discard
set policy-options community COM-BLACKHOLE members 1:666

Result

Upon receiving the trigger update, the route to 1.1.1.1 is no longer installed in BGP with a next-hop to the Null device. Instead, the route is discarded directly “before” installing in BGP.

juniper> show route 1.1.1.1
 
juniper> show route hidden
 
1.1.1.1/32          [BGP/170] 02:35:35, localpref 100, from 10.0.81.0
                      AS path: 1 I, validation-state: unverified
                      Unusable
 
juniper> show route hidden detail
 
inet.0: 11 destinations, 11 routes (10 active, 0 holddown, 1 hidden)
1.1.1.1/32 (1 entry, 0 announced)
         BGP    Preference: 170/-101
                Next hop type: Unusable, Next hop index: 0
                Address: 0x28406f0
                Next-hop reference count: 1
                State: <Hidden Ext>
                Local AS:     2 Peer AS:     1
                Age: 2:36:52
                Validation State: unverified
                Task: BGP_1.10.0.81.0
                AS path: 1 I
                Communities: 1:666 no-export
                Accepted
                Localpref: 100
                Router ID: 10.0.0.1

4.2.2. Black Hole Source

The configuration is the same as the previous example with the addition of Unicast Reverse Path Forwarding on the remote router interface where the unwanted traffic is received.

Arista

interface ethernet1/1
ip verify unicast source reachable-via any

Juniper

set interfaces xe-0/0/0 unit 0 family inet rpf-check mode loose
set forwarding-options rpf-loose-mode-discard family inet

5. Black Hole Security

5.1. BGP

It is recommended to configure external BGP routers to deny advertising any prefix with the Black Hole community as an added protection in case the NO-EXPORT community is mistakenly not also attached.

An excellent reference for BGP security is the IETF RFC 7454 “BGP Operations and Security” https://tools.ietf.org/html/rfc7454.

Also read about Resource Public Key Infrastructure (RPKI), which makes it possible to validate that an IP prefix received in a BGP advertisement belongs to the ASN advertising it, by first checking the Local Internet Registry (LIR) information. If the validation fails, the advertisement can be marked invalid and rejected. See RPKI in Wikipedia.

5.2. Return Traffic

When traffic is dropped by a Black Hole, it is interesting to consider whether the source knows their traffic was dropped. This depends on the router configuration and TCP/IP traffic type.

For example, in Juniper Junos the “discard” action results in no reply (silent) whereas the “reject” action applied to a TCP connection request results in a TCP reset (RST) reply being generated, and for UDP an ICMP “Destination Unreachable, Port Unreachable” reply is sent. Controlling this behaviour may be a security consideration in your network.

Care must be taken tuning the security aspects of a Black Hole configuration. For example, you can stop ICMP replies being generated in response to dropped UDP traffic by disabling IP Unreachable messages on interface, however this is known to cause Path MTU Discovery to fail which may have unintended consequences in your network.

The behaviour of your Black Hole configuration can be tested by port scanning and analysis using the freeware tool NMap. See https://github.com/nmap/nmap.

Try simple tests of your own with static routing and BGP Black Hole configuration. Perhaps you want to implement a more sophisticated solution utilising IP flow data? If you need guidance or advice with Black Hole routing to protect against DoS attacks, or deploy some sensible and best practise protection against IP bogon routes or IP spoofing, ngworx is ready and willing to help. Get in touch! We are waiting for your call (smile)

6. Reference

Wikipedia

Internet Engineering Task Force (IETF) Request For Comment (RFC) standards are essential reading and can be considered best practise guides.

The North American Network Operators Group (NANOG) document archive contains many excellent presentations.

Arista

Cisco

Juniper

March 2021
written by Nigel Wensley
Senior Network Engineer

Most Popular

Network-Engineering | 8 min read

Junos upgrade – filesystem is full

Not enough storage during Junos upgrade (EX2300 and EX3400). An extension of Juniper's article…

Read more