Filtering Unallocated Prefix Blocks | Routing Policy and Firewall Filters

Problem

You do not want to accept prefixes from address spaces that have not yet been allocated by IANA.

Solution

Define a policy that rejects routes from unallocated address space:

	[edit policy-options policy-statement no- 
bogons  term 1]
	aviva@router1# set route-filter 1.0.0.0/8 
orlonger reject 
	aviva@router1# set route-filter 2.0.0.0/8 orlonger reject 
	aviva@router1# set route-filter 5.0.0.0/8 orlonger reject 
	aviva@router1# set route-filter 7.0.0.0/8 orlonger reject 
	aviva@router1# set route-filter 23.0.0.0/8 orlonger reject 
	…

Then apply the policy to a BGP group:

	[edit protocols bgp]
	aviva@router1# set group external-group import no-bogons

Discussion

Bogons are prefixes in the IP address space that have not been allocated by IANA or that have been allocated but are marked as being reserved. About 40 percent of the total possible IPv4 address space is bogon. One subset of addresses that are reserved, and thus bogon, are the RFC 1918 private IPv4 addresses 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. Malware, which is malicious software designed to damage or disrupt network equipment, often targets random IP addresses and chooses bogon prefixes to launch or propagate network attacks. Because of this, and because you should never receive legitimate traffic from unallocated prefixes, it is good preventive security practice to put in place routing policies that reject bogon routes so that they are never added to the routing table.

This recipe shows a snippet of a routing policy that uses route lists to identify each unallocated bogon prefix. Each set route-filter command includes a reject action to quickly and immediately reject any matching incoming prefix. The recipe applies this policy to an EBGP group with an import command so that the policy is evaluated when incoming routes are received by the EBGP group.

The bogon filter in this example uses routing policy. Another way to filter them is with firewall filters (see Recipe 9.8), providing bogon filters on the network's ingress and egress interfaces. Firewall filters let you log and syslog traffic (see Recipe 9.13) and maintain SNMP counters about traffic that comes from bogon space (see Recipe 9.12), giving you data to graph network attacks that come from bogon space, which is a very common occurrence, and helping you be more aware of what's happening on your network. With a firewall filter, you can do bogon filtering by referring to bogon prefixes in prefix lists and then counting and discarding any matches.

Over time, the list of bogons changes, mostly because IANA allocates IP prefixes and less often because of changes to reserved addresses. If a configuration includes a policy to filter bogons, you must update it to keep it in sync with current address allocations. Every time a bogon is allocated, many people, including big ISPs, forget to update their filters for some reason or another and they often need specific reminders sent directly to them. If you do not actively monitor for bogon changes on a regular basis, you will be blocking future allocations from functioning properly. One way to update the bogon list automatically is to peer with Team Cymru, which maintains a current list of JUNOS bogon route lists, as well as a list of reserved prefixes. See http://www.cymru.com/BGP/bogon-rs.html for information about the BGP bogon project.

One caveat in using the Team Cymru bogon lists is that you should examine the prefixes to make sure they are not blocking traffic that you want to receive. For example, one of the bogon lists, http://www.cymru.com/Documents/bogon-bn-agg.txt, contains 224.0.0.0/3 as an entry. If you do not specify that your firewall terms are for unicast IPv4 traffic only, using this prefix in a prefix list for a firewall filter will break OSPF, because this is the OSPF multicast address and must be present for OSPF to operate (see Recipe 12.1).