Multihoming is a scary word for some reason, conjuring
Multihoming to a single ISP works fine with either
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
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
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
Figure 4-2: Multihoming to a single ISP
If we assume that both connections are equal bandwidth, the routing policy could simply
Another negative aspect of this method is that the ISP may have severe network problems, thereby rendering both gateways useless.
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 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
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.
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
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
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
where routes are continually announced and withdrawn. This oscillation may initiate
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.
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