Internet Gateways and Multihoming

Multihoming is a scary word for some reason, conjuring visions of routing wizards dressed in black, mumbling arcane incantations, and waving a staff in the air to enable multihoming to work. There are many complex examples of multihoming, which is more detail than can be adequately covered in this chapter. For most organizations, a few simple scenarios exist that provide robust, fault-tolerant routing for multiple Internet gateways.

Multihoming to a single ISP works fine with either reassigned or directly allocated prefixes (see Chapter 1). Multihoming to two or more ISPs works best if you have a direct prefix allocation from your regional registry (these are called "provider independent" addresses). While some ISPs are willing to disaggregate their larger prefixes to enable more specific routing through another provider, this is generally discouraged by ISPs, so it's best to obtain a direct allocation from your regional registry and avoid any potential issues.

In this section, we will cover two basic multihoming examples:

• Dual gateway, same ISP, reassigned/direct IP prefix assignment

• Dual gateway, different ISPs, direct IP prefix assignment

Multihoming to a Single ISP

Single ISP multihoming is very common for organizations today (see Figure 4-2). The organization has multiple locations, with a common internal network between them. This organization may utilize either a prefix reassigned from the provider or a directly assigned prefix from a regional registry. In addition, the organization may ask the ISP to manage the routing policy or it may decide to run BGP and manage its own routing policy. The easiest method in this case is to allow the ISP to manage routing policy for the organization. The ISP would statically route the organization's respective prefix(es) to each gateway, and carry the prefixes in its BGP tables.

Figure 4-2: Multihoming to a single ISP

If we assume that both connections are equal bandwidth, the routing policy could simply dictate that when the primary connection is unavailable, routing fails over to the secondary connection and all traffic is carried through that link. One negative aspect of this configuration is that the secondary connection sits idle until the primary fails. This may be cost prohibitive for some organizations. Another common alternative is for the organization to utilize a unique prefix in each location, and share the traffic load between the two sites via internal routing. Both gateways are actively routing traffic, and each site utilizes its nearest gateway for outbound traffic. If one gateway fails, the internal network is notified via routing protocols, and traffic is rerouted to the other gateway. This configuration is more complex and beyond the scope of this chapter.

Another negative aspect of this method is that the ISP may have severe network problems, thereby rendering both gateways useless.

Note 

When multihoming to a single ISP, request that each of your circuits terminates on different physical routers, if possible, to avoid an ISP router as a single point of failure.

Multihoming to Different ISPs

Multihoming with different ISPs is becoming more common to solve the problem mentioned in the previous section regarding ISP network failures (see Figure 4-3). Again, the organization has two Internet gateways, with a common internal network between them, but each gateway connects to two different ISPs. Using this method, an organization may obtain a prefix directly from a regional registrar, but may also obtain unique prefixes as a reassignment from the respective ISPs.

Figure 4-3: Multihoming to multiple ISPs

Routing policies for this example are similar to policies for single ISP multihoming. Each site may use internal routing to use its local Internet gateway, both of which are actively routing traffic. If one gateway fails, the internal network learns that the gateway is unavailable, and internal hosts route through the secondary gateway.

These examples are greatly simplified in order to focus on how multihoming can increase reliability. Attackers may impact reliability by flooding or denial-of-service attacks, which multihoming (when implemented properly) can help mitigate. Another major attack vector is a route specificity attack, which is discussed in Chapter 2.

Securing BGP

If you are running BGP, you need to think about securing the protocol to the extent that is possible. On April 20, 2004, the public was made aware of a method to exploit a well-known "feature" of TCP implementations (as originally defined in RFC 793), whereby an attacker could reset persistent TCP connections terminating on a device (such as a server, router, or switch). The consequences to global BGP peering sessions were considered the most critical vulnerability.

RFC 793 states that an established TCP connection can be reset by sending a packet with the RST or SYN flag set. For a reset to occur, an attacker must know the source and destination address, source and destination port, and sequence number. Theoretically, the source/destination address and port may be easy to obtain, but the sequence number would be nearly impossible to guess. The flaw in most TCP implementations was that the sequence number did not have to be an exact match, but rather fall within a "window" (range). The larger the window, the easier for an attacker to guess a number in the range.

The danger of this vulnerability with BGP is that resetting a BGP session causes all routes to be flushed from the router, and the session to reestablish. Repeated attacks cause route flap, where routes are continually announced and withdrawn. This oscillation may initiate flap dampening (typically only configured in ISP networks), where the router will refuse to accept announcements for a short time (such as 45 minutes) in order to stabilize routing. This can have severe impacts on large networks, from degraded performance to complete routing outages.

A method to mitigate this risk (aside from fixing the TCP sequence prediction vulnerability) is the use of MD5 checksums between BGP peers. The peers agree on a pre-shared password and run the password through an MD5 hashing function, which produces a 128-bit number (hash). This number is used for transactions between peers. The MD5 hash is never negotiated in the clear as plaintext passwords are, so danger of sniffing is mitigated.

This method also helps protect peers against spoofing and unauthorized route injection. The MD5 password should be changed periodically, just as with host and router-based passwords.

Note 

If you are running BGP, you may wish to utilize uRPF to block packets with spoofed source addresses from entering your network. Any source IP address for which you have no valid return path will be dropped (usually bogons, RFC 1918 addresses, and so on). For details on uRPF, see Chapter 2.