RFC 2267, Source Address Assurance

RFC 2267, "Source Address Assurance"

RFC 2267, "Source Address Assurance," was published in January 1998 with the intent of defeating certain types of DoS attacks in IP-based networks. As you learned in the preceding section, DoS attacks are insidious threats to the stability of any network or networked computer. Logically, then, anything you can do to defend against the DoS attack is a good thing. Or is it? In the case of Source Address Assurance, the cure might be worse than the disease. Curiously, many "experts" cite RFC 2267 as the best defense against a DoS attackdistributed or otherwise.

Defending Against DoS

Knowing what a DoS attack is and knowing what to do about it are two very different things. The trick is getting the spurious traffic to stop without causing further harm to the attempts of legitimate users to gain access to the resource being attacked. Discriminating between legitimate users and an attack is a complicated affair, particularly when your attempts to troubleshoot are conducted under duress. Remember, a portion of your networked computing environment is under attack. That attack might well overload either the systems or the network you must use to collect information before diagnosing the problem.

In theory, anyone who intends to cause such a disruption of service on an internetwork likely wants to cover his tracks. In other words, he won't launch an attack from his own desktop, because that would make it easy to trace the attack back to him. So the goal is to obfuscate the source of the attack by using someone else's IP address. Spoofing an IP address is a relatively trivial endeavor. Without going into detail (if I tell you exactly how to do this, all I would accomplish is to make spoofing easier), spoofing an IP address results in a fictitious address being used as the source address of each IP packet generated. Logically, if that source address is fictitious, return packets can't reach their destinations. That too is useful, because it tends to increase the overall amount of traffic generated as the result of an attack.

It's important to recognize that spoofing an address doesn't change an attack's point of origin; it just hides it with a fictitious source IP address. Thus, examining all the packets generated from within a network should reveal an interesting trend. All those packets should bear a source address that was created from the network address assigned to that network. A spoofed address would differ. This is the basis of Source Address Assurance. By examining source IP addresses relative to the network address assigned to a network, you can easily detect a spoofed address. Quite simply, it wouldn't match. Figure 12-5 shows how this works.

Figure 12-5. A Spoofed IP Address Doesn't Match the Network Address

If someone within the customer network shown in Figure 12-5 wanted to launch an attack using a spoofed address, the routers in that network would make their forwarding decisions based on the spoofed packets' destination address. No sanity check on the source address would be made. So the packets would be routed to their destination properly despite the obviously mismatched source address relative to the network to which it was connected.

The actual type of attack propagated in this manner almost doesn't matter. The important thing to note is that spoofing lets the attack be carried out with relative anonymity. RFC 2267 was not intended as a panacea against all types of attacks. Instead, Source Address Assurance was a specific tool developed to protect against just those DoS attacks that were initiated by a forged or spoofed source IP address. It worked by preempting the possibility of a spoofed address getting beyond the network from whence it originated.

A Flawed Assumption

It is important to recognize that RFC 2267 was published as an informational RFC. Thus, ISPs were not compelled to enforce its recommendations. Some did, and some didn't. The important thing to recognize is that, because it was just an informational RFC, it didn't attract the attention that a standards-track document would. Consequently, many end-user organizations don't even know it exists and never ask about it when shopping for Internet connectivity.

The ongoing evolution of the Internet, in conjunction with the ever-increasing sophistication of its user community, rendered RFC 2267 obsolete in just four short years. In retrospect, it should be obvious why it was just an informational RFC: Right from the start it was based on a flawed assumption. That assumption was that you could reliably determine a "forged" IP address in a packet by examining the address of the network from which the packet originated.

On the surface, that seems reasonable enough. If an IP packet bears a different address than the network it came from, you should be suspicious of its authenticityor should you? When RFC 2267 was first published, this assumption was already well on its way to obsolescence! Yet the need for some means of defending against DoS attacks from spoofed addresses was urgent enough that an RFC was put forth. What wasn't mentioned in the RFC, however, was that multihomed customers could be effectively denied service by the recommended filtering!

The Problem with Source Address Assurance

Source Address Assurance, despite the good intentions on which it was founded, quickly became obsolete. The Internet, and its end-user base, matured quickly after its commercialization. Companies in particular quickly realized that billboards on the Net simply weren't of much value. Thus, they developed increasingly sophisticated ways to directly market and sell goods and services and manage customer relationships using the Internet. Many companies emerged with a new business model that relied exclusively on Internet connectivity. With this increased sophistication came a decreased tolerance for the risk of downtime. Consequently, efforts to eliminate single points of failure ultimately led to companies that connected to the Internet via two or more different ISPs.

Although such multihoming nicely solved the problem of single points of failure, it introduced complexities that simply weren't accounted for in RFC 2267. Take a look at Figure 12-6, and you'll see what I mean.

Figure 12-6. Multihomed Clients Can Defeat the "Logic" of RFC 2267

Figure 12-6 shows that the company has attempted to eliminate a single point of failure via dual homing. Unfortunately, this contradicts the logic of RFC 2267. Suddenly, companies upstream of ISP #2 must accept that 10.240.15.0/24 (a network address alien to ISP #2) enjoys a legitimate path through that provider's network. From the perspective of Source Address Assurance, however, it appears to be a spoofed address. In fact, from the perspective of that ISP, there appear to be lots of spoofed addresses! ISPs that implement Source Address Assurance would, by definition, filter out those foreign addresses, thereby rendering moot the benefits of multihomed end-user organizations.

The net effect is demonstrated in Figure 12-7. The heavy dotted line indicates the point at which the 10.240.15.0/24 route is supported through ISP #2's network. The end-user organization believes that it has eliminated a single point of failure, but it doesn't realize that a provider upstream of its provider has effectively limited the reachability of its address space. Without knowing to ask specifically about Source Address Assurance, a dual-homed Internet customer can be paying a lot for the illusion of redundancy. Connectivity tests such as ping or tracert (or traceroute, depending on which operating system you use) to hosts within the 192.168.0.0/16 network will demonstrate that the connection to ISP #2 is working fine, but routing protocols will select the connection through ISP #1 for all destinations outside 192.168.0.0/16.

Figure 12-7. The Customer's Reachability Is Limited by an Upstream Provider of The Customer's ISP

Therein lies the great debate. Which is the greater good: attempting to ensure network stability by preventing DoS attacks via a spoofed address, or eliminating a single point of failure via multihoming connections to the Internet? The answer depends greatly on your perspective, and how much value you place on customer satisfaction.

Brand Image Versus Customer Satisfaction

RFC 2267's Source Address Assurance is far from being a topic of only academic interest. As a customer of an ISP, you could find yourself victimized by it. Worse, you could be in jeopardy of this happening without even knowing it!

Multihomed customers who connect to second-tier ISPs must accept the fact that their immediate upstream provider is likely multihomed to other upstream service providers. The net effect is that a first-tier service provider might see a network address being advertised via its downstream and also might see that same network address being advertised via a different service provider. Logic used to dictate that there could be only a single valid route for each network. When faced with multiple routes, which one do you accept as valid? Well, a first-tier service provider that implements RFC 2267 would filter inbound packets and accept only packets from its downstreams that are registered to those downstreams. Any other packets (including legitimate packets of that downstream provider's customers) that bear someone else's network address in their source address field are assumed to be spoofed. As such, they get dropped.

At least one globally recognized telecommunications carrier/ISP relies heavily on RFC 2267 as a means of protecting its brand image. This company has acknowledged that enforcing Source Address Assurance can cause legitimate customer routes to be blackholed, particularly those that are multihomed to two or more ISPs. Yet this company has stubbornly insisted that protecting its brand image is far more important than customer satisfaction.

Although I have gone out of my way to protect the identity of that misguided company, you should be asking your ISP if it, or any of its upstreams, enforces RFC 2267 filtering. If so, it might be time to find another service provider. Ideally, you want to find one that recognizes that brand image is a function of customer satisfaction rather than something that must be defended even at the cost of customer satisfaction. Trust me: When you find a provider that believes in Source Address Assurance, you will have also found a provider that cares a great deal less about your satisfaction as a customer than it does about the stability of its own network.