Black Hole Routing as a Packet Filter Forwarding to NullO

Another way of implementing destination-based packet filtering on a router is to create a specific list of static host routes and point them to the pseudo-interface NullO. This technique commonly is referred to as black-hole routing. Null0 is a pseudo-interface, which functions similarly to the null devices available on most operating systems. This interface is always up and can never forward or receive traffic. Although Null0 is a pseudo-interface, within CEF it is not a valid interface. Hence, whenever a route is pointed to Null0, it will be dropped through CEF and dCEF's forwarding process with no processor overhead.

The null interface provides an alternative method of filtering traffic. You can avoid the overhead involved with using access lists by directing undesired network traffic to the null interface. The following example configures a null interface for IP route and the specific host (subnet mask

interface Null0 no icmp unreachables

ip route null 0 ip route null 0

The no icmp unreachables command is used to prevent unnecessary replies whenever traffic is passed to the NullO interface. Note that rate limiting should be applied to the icmp-unreachables option so that the router CPU does not get bogged down dealing with responses to discarded traffic. Consensus from ISPs using icmp-unreachables recommends the following configuration:

ip icmp rate-limit unreachable DF 2000 !

interface Null0 no icmp unreachables

This rate-limits the icmp-unreachables response to one every two seconds, with the DF bit set (the IOS Software default is 500 ms).

Figure 4-19 gives a graphic example of how this black-list filtering technique works, comparing the packet paths with using an access list. By using the black-hole routing technique to implement black-list filtering (no pun intended), the strength of the router is utilized to drop packets bound for forbidden sites. A router's primary function is to forward packets, not filter packets. The black-hole routing technique uses the packet-forwarding power to drop all packets bound for sites on the black list.

Figure 4-19. Using Static Host Routes to NullO for Black-List Filtering

Figure 4-19. Using Static Host Routes to NullO for Black-List Filtering

Two main drawbacks to this technique exist. First, access to all services at a given site must be restricted. The attraction of extended ACLs is the fine granularity given to filter at the application level. Black-hole routing does not have this granularity. It filters access for all packets bound to a specific host or subnet. Second, it is hard to bypass the black-hole routing technique. Any organization that wants to bypass the black list actually must find a way to bypass the filtering router's forwarding table. Compensating for either limitation is a nontrivial task.

BCP 38 Using Unicast RPF riQ!

BCP 38/RFC 2827 provides a proactive step to prevent problems caused by packets with malformed or forged IP source addresses passing through a router. It is a wonderful security concept and will prevent many security problems on today's Internet. However, ISPs still have not widely adopted BCP 38, mostly because of concerns about scalability and the impact of the technique on the management of their routers.

Consider an ISP that would like to do BCP 38 with ACLs but is aggregating 10,000 leased-line customers onto its backbone. This means that 10,000 separate ACLs need to be created, maintained, and updated as new addresses are allocated to the ISP. Now consider an ISP with 100,000 leased-line customers, 500,000 leased-line customers, and so on. You can easily see the scalability problem posed when trying to implement BCP 38. Even scripted as part of configuration-management tools, implementing BCP 38 using ACLs adds scalability burdens for an overworked ISP operations and deployment team. Some way to automatically perform the BCP 38 check without the headache of ACLs is needed. This is where unicast reverse path forwarding (uRPF) provides the perfect solution.

uRPF originally was created to automatically achieve the BCP 38 packet filtering without the headaches of ACLs. It is a one-line interface configuration that can be placed in an ISP's deployment scripts. Hence, any installation engineer can apply BCP 38 filtering as soon as the leased line is installed to the site of the new customer. No ACLs, no need to maintain ACLs, and no need to change ACLs whenever new prefixes are allocated to the customer.

Was this article helpful?

0 0

Post a comment