Routing Policy

Routing policy is a broad term covering a lot of information but let's boil it down to basics. Packet forwarding using BGP and an IGP is easy to understand. The complex part of Internet routing, and the part that attackers can influence most directly, is routing policy. How do providers or organizations decide what prefixes to announce to peers? How do they decide what prefixes to accept from peers? How do they decide which prefixes their peers should prefer or which prefixes they should prefer from their peers? All of these questions are answered by developing and following a routing policy. Routing policy is one of the most critical aspects of an ISP's infrastructure and, if not implemented properly and securely, the entire Internet can melt down. There is much room for human error in configuring routing policy, as we will see in an example later in this chapter.

Developing and Configuring Policy

What prefixes should an ISP announce and accept on behalf of other customers or peers? An ISP will obviously announce its corporate prefixes, and any directly connected customers to whom it has allocated prefixes. Next , an ISP must receive and announce any prefixes for customers who pay for transit service. Providing transit simply means carrying traffic to and from customers for specific prefixes that the customer is authorized to announce (as you will see later, authorized is a key word).

The reality of the situation is that not all ISPs or organizations properly filter routing advertisements between themselves and their peers. Policy is still largely based on trust. Over the last decade , there have been efforts by network engineers and ISPs to utilize a database called the Routing Arbiter Database (RADB, http://www.radb.net). The concept behind this commercial project was that all ISPs and organizations that utilize BGP routing would register all routing information and routing policy in the RADB for all ASs, IP prefixes, and downstream networks for which the organization is responsible. Any ISP or organization that wished to peer (exchange routing information) with another entity registered its prefixes, and routing policy for prefixes they would announce to peers, and prefixes they wished to receive from peers. This method could greatly reduce the risk that miscreants will introduce more specific routes to subvert legitimate routing or hijack entire prefixes.

The RADB project met with some success among larger ISPs around the world, but because of the commercial nature, many smaller ISPs and organizations were unwilling or unable to participate. Another project aims to solve that problem by providing a stand-alone software package called the Internet Routing Registry daemon (IRRd) to any entity, free of charge. The entity could build a local routing registry, and communicate with other registries to mirror data, and build proper filtering mechanisms to ensure proper routing between autonomous systems. However, this method requires much greater effort by all parties to share their registry data. In fact, ask smaller ISPs about a routing registry and you'll get a blank stare. Many don't know routing registries exist, nor why they should use them.

Routing policy in the registry databases is defined by the Routing Policy Specification Language (RPSL) or RIPE-81 format. Using additional tools, an organization can extract relevant information from a registry, and build a routing policy appropriate for their router platform. Further details on RPSL and the configuration tools available may be found at http://www.isi.edu/ra/rps/training/.

The fundamental problem with any routing registry database is the issue of authorizing and authenticating the data. Network administrators must be able to trust the data and the routing policies in the database. The issue is beyond the scope of this discussion, but we posit that the benefits of using a routing registry to ensure proper routing policy far outweigh the issue of data integrity.

One shining example of the damage that can be done by misconfigured routing policy, or misplaced trust between peers, happened on April 25, 1997. This was termed the "AS7007 incident." Simply put, AS7007 "leaked" more specific routes for a very large subset of the global routing table. Most backbone routers had enough memory for the global routing table at that time, but the leak from AS7007 increased the table size dramatically, and caused the destination for most global routes to redirect to AS7007. Backbone links became saturated , routers crashed, and chaos ensued. For several hours that day, the entire Internet went into meltdown.

Routing registries are not a silver bullet, due to the issue of authorizing and authenticating the policy information in the database. You must understand that a problem like the "AS7007 incident" can still happen. However, if ISPs properly filter customers at the edge, and use routing registries and communicate policy between their peers, the potential for these problems to occur is greatly reduced.

Note 

In recent interviews with large, global ISPs, we were told that some ISPs are using an "internal, private database of customer prefixes" to build routing policy, and some ISPs are using the public registries to "share" their policy. However, consensus indicates that little validation of the data is performed before configuring policy. Therefore, the potential for prefix hijacking remains relatively high.

Remember that Internet routing is governed by specificity above all other attributes. Therefore, in addition to misconfiguration, a well-studied attacker could redirect every packet destined for an organization's IP prefixes by way of advertising a more specific route destined for the attacker. The existence of a "more specific" route to any portion of an organization's prefix would almost immediately re-route all traffic destined for that prefix toward the more specific routing advertisement before following other relevant protocol directives. For easier visualization of the nature of this attack, "normal" and "compromised" state diagrams are shown in Figure 2-3 to illustrate the direction of traffic flow based on route specificity (using RFC 1918 prefixes as an example, which are not globally routable).

Figure 2-3: Example of a route specificity attack

Just be aware that policy misconfiguration can impact you either directly or indirectly, and can lead to a route specificity attack that impacts you directly if the attacker targets your prefixes.

Nonroutable Prefixes

You've probably heard many times that RFC 1918 prefixes are not routable on the global Internet. Yet, over the last few years , we've seen several major ISPs that are routing these prefixes. RFC 1918 defines the following prefixes for use in private internets :

• 10.0.0.0/8

• 172.16.0.0/12

• 192.168.0.0/16

In one case, a major ISP had acquired a smaller ISP, which had used 10.0.0.0/8 to address critical systems and routers within its network. Therefore, the larger ISP had to route that prefix on its network (of course, they should have renumbered !).

A certain organization was using "default routing" to the ISP for any non-local traffic. This organization happened to traceroute to a network-10 address, which they did not use internally, and saw the packets leave their border and terminate on a device that responded within the ISP's network! Of course, this organization should have had proper egress filtering to stop this type of traffic from leaving its network.

The potential problem is that many organizations use RFC 1918 prefixes for internal systems. If a routing situation occurred such that the organization's packets leaked outside the border to the ISP network, the packets might arrive at an unintended destination. This could cause unintended information disclosure on the end-system where the packets actually arrived.

In addition, RFC 1918 explicitly states that the networks listed therein are reserved and should be nonroutable on the global Internet:

"Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links. Routers in networks not using private address space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information about private networks. If such a router receives such information, the rejection shall not be treated as a routing protocol error."

What's a Bogon?

We just discussed "nonroutable addresses," which some people term "bogons." Other people define bogons as "any prefix that is special-use, unallocated , or unassigned ." Still other definitions exist. This seems like an appropriate place to discuss bogons and other prefixes that are not allocated to an organization or that are otherwise allocated for "special use." RFC 3330 defines "Special-use IPv4 Addresses." Minor portions of the IPv4 address space have been allocated or assigned for global or special purposes. These allocations and assignments have been documented in previous RFCs, and RFC 3330 consolidates this information.

The following table summarizes the special-use IPv4 prefixes from RFC 3330, with reference to appropriate RFCs detailing their use.

Address Block	Present Use	Reference
0.0.0.0/8	"This" network	RFC 1700, page 4
10.0.0.0/8	Private-use networks	RFC 1918
14.0.0.0/8	Public-data networks	RFC 1700, page 181
24.0.0.0/8	Cable television networks
39.0.0.0/8	Reserved but subject to allocation	RFC 1797
127.0.0.0/8	Loopback	RFC 1700, page 5
128.0.0.0/16	Reserved but subject to allocation
169.254.0.0/16	Link local
172.16.0.0/12	Private-use networks	RFC 1918
191.255.0.0/16	Reserved but subject to allocation
192.0.0.0/24	Reserved but subject to allocation
192.0.2.0/24	Test-Net for use in documentation/examples
192.88.99.0/24	6 to 4 relay anycast	RFC 3068
192.168.0.0/16	Private-use networks	RFC 1918
198.18.0.0/15	Network device benchmark testing	RFC 2544
223.255.255.0/24	Reserved but subject to allocation
224.0.0.0/4	Multicast	RFC 3171
240.0.0.0/4	Reserved for future use	RFC 1700, page 4

Arguably, many of the prefixes listed in RFC 3330 should never be routed globally on the Internet. However, as we noted earlier, you cannot necessarily trust that your ISP is properly filtering routes such as these from entering the global routing tables. For up-to-date information on the IANA-assigned prefixes, and prefixes that are available but not yet allocated or assigned, go to http://www.iana.org/assignments/ipv4-address-space.

An ISP or organization could periodically review this data, and build access control lists (ACLs) to filter all of these prefixes from entering or leaving a network. Many ISPs do this today. However, as the IANA or regional registries allocate or assign new prefixes to be routed on the Internet, the ACLs must be updated accordingly . Evidence suggests that ACLs are not updated in a timely manner. Organizations obtain the new prefixes and expect them to be globally routable, only to find that access to or through some ISPs is blocked due to these outdated ACLs.

One method to deal with continually changing prefix allocations is to obtain a "bogon BGP feed" from a volunteer organization known as Cymru (pronounced cum-ree). Cymru tracks current prefix allocations from IANA, and configures BGP peering policies to announce unallocated/unassigned prefixes to peers. The peer receiving the "bogon feed" configures a static route to a "null" interface in the router, and sets the next hop of Cymru-learned prefixes to this static route. In effect, this "black-holes" any traffic transiting the router that is destined for one of the bogon prefixes. Figure 2-4 depicts the bogon feed in action.

Figure 2-4: Packets falling into the bogon black hole

Note 

Information regarding the Cymru bogon feed, and associated router configuration templates, may be found at http://www.cymru.com/Bogons/index.html.

Unicast Reverse Path Forwarding

One additional layer of protection you may utilize to block packets with spoofed source addresses, such as bogons, is unicast Reverse Path Forwarding (uRPF). IP routing is inherently destination-based. An IP router receives a packet on an interface, and matches the destination IP address with the local forwarding table to determine which interface sends the packet out. uRPF provides a "looking backwards " function to check that:

• There is a valid route back to the source address in the forwarding table.

• The return path back to the source is through the same interface where the packet was received.

uRPF may be deployed at the customer-facing edge of an ISP network, or on the customer edge facing the ISP, where routing to and from any given source is symmetric. BGP routing must be used for uRPF to be effective; otherwise, every source address will have a valid path due to the default route. uRPF can deal with multiple paths back to a source, but they must be equal-cost paths (based on local routing metrics) or uRPF will drop the packet.

The value to the ISP on the customer-facing edge is blocking distributed denial of service (DDoS) attacks preventing backscatter . DDoS attacks often originate packets with spoofed source addresses. The goal of the attack is to overwhelm network devices and/or hosts such that the attacker does not want or expect responses to the packets sent. There may be two victims in the DDoS attack: the site being attacked , and the site receiving backscatter traffic ( assuming the spoofed sources are valid, routed IP addresses). If uRPF is deployed at the edge of an ISP network, and a customer network is the source of a DDoS attack wherein source addresses in the packets are spoofed, the packets are dropped at the edge of the ISP network. Thus, the traffic does not impact the ISP network, nor do the packets reach the intended target. In addition, the backscatter traffic that might have been generated because of the DDoS attack is prevented.

The customer may use uRPF in addition to or in place of ACL filters to block spoofed packets from entering the network, but as we mentioned above, this is only useful if the customer is running BGP, as a default route creates a valid return path for any source address, thus nullifying uRPF.