Put simply, a Bogon Network is a bogus or invalid network. These networks are sometimes called martians, as they might as well have come from Mars (where no valid networks exists; At least at the time of writing).

Bogon networks are invalid on the internet, as they are networks that have been reserved for special use, or have not yet been allocated to a customer. These networks should not be seen on the internet.

Some examples of reserved IPv4 networks are:

• Private Networks (10.0.0.0 /8, 172.16.0.0 /12, and 192.168.0.0 /16)
• Loopback Addresses (127.0.0.0 /8, ::1 /128)
• Link-local Addresses (169.254.0.0 /16, FE80:: /10)
• Initialisation Addresses (0.0.0.0 /8)

In addition to these addresses, any blocks of networks that IANA has not yet assigned to RIR’s is considered a bogon network.

The networks outlined above are a small sample of the Bogon List. A much larger list, called Full Bogons, also include IP blocks that have been allocated to an RIR, but have not yet been allocated to a service provider or other end user. These lists are collectively maintained by IANA and the RIRs, and is very dynamic.

Would an unroutable address be of any benefit to an attacker? Consider an example. RFC 2267 outlines a possible DoS attack where the attacker opens many TCP connections to a particular network device. When a SYN packet is received by a host, it reserves some space in memory to track the connection. However, the attacker never sends completes the connection, leaving an embryonic connection (or half-open connection) on the host. One way this can be achieved is by cycling through a number of unroutable source address, so the host is unable to send back the SYN/ACK message. If enough of these messages are sent, the host’s resources are quickly wasted.

But, why spoof Bogon addresses as the source? Why not use a real routable address as the source? Well, either can be used. One reason an attacker may prefer to use bogon addresses is to make it harder to track the real source of the attack.

Is this really a concern though? Clearly an attacker may use a spoofed bogon address, but they don’t have to. Firstly consider the proportion of DDoS attacks that come from Bogon sources. In 2001, Rob Thomas from Team Cymru conducted a study on DDoS attacks, and discovered that 66% of DDoS attacks came from Bogon sources. More recent sources suggest that only 10% are from Bogon sources. Either way, when it comes to DoS and DDoS protection, every little bit helps in a good good defence. Preventing traffic from Bogon networks, both on ingress and egress, helps to keep the internet clean.

Typically, two basic methods are utilized to filter Bogon routes; These are ACLs on a firewall, and creating routing black-holes. The rest of this article is concerned with using BGP to create the black-hole.

Bogon filtering is commonly used by service providers, before it even gets to enterprises. However, sometimes bogon routes can slip through, so it’s good practice for enterprises to filter bogons too. There are two ways to accomplish this; Statically, and dynamically. Remember that Bogon routes change regularly as networks are allocated to customers, so if the static method is used, it should be reviewed regularly.

Static filtering uses a prefix-list to prevent routers from learning bogon routes from peers. A brief example is shown below.

There are some downsides to this method. As already mentioned, the list changes, so there is an administrative overhead to maintaining this configuration. Additionally, the full bogon list is quite large. At the time or writing, there are only 13 prefixes in the regular IPv4 bogon list, but there is a huge 3757 prefixes in the IPv4 full bogon list, and 78058 prefixes in the IPv6 full bogon list. This is a lot of configuration to type in.

An alternative to static configuration is using a service that updates the bogon list dynamically. Here, the Bogon Route Server Project is used.

The Bogon Route Server Project is a free service which is maintained by Team Cymru. Filtering is implemented by peering with their BGP routers to get the list of bogon routes (both IPv4 and IPv6 are supported). A route-map can then be used to set the next-hop for these routes to a black hole.

Configuration code can be found on the Team Cymru BGP Examples page.

As seen in this example, there are two peering sessions with Team Cymru’s servers. Access to these servers have to be requested directly from Team Cymru. EBGP multihop is set very high, as their servers are not directly connected or nearby peers, as would traditionally be used in a BGP config. The route-map sets the next-hop for each learned route to 192.0.2.1, which in turn, points to null0, the black hole.