Introduction

The Internet architecture provides no explicit mechanism to prevent packets with forged headers from traversing the network. By forging or "spoofing" the source address of an IP packet, a malicious user or compromised host can send packets toward a victim anonymously. More insidiously, attackers with the ability to spoof can leverage reflectors [1], making distributed denial-of-service attacks difficult to defend against.

A rash of spoofing-based attacks in 2000 and 2001 incapacitated several high-profile web sites. Is spoofing still a relevant issue on the Internet today? The rise of zombie farms, where spoofing provides little additional anonymity, suggests spoofing may not be a useful technique. Further, the proliferation of hosts behind Network Address Translation (NAT) devices renders spoofing attacks useless as the IP header is rewritten by the NAT. Despite these two factors, analysis of backscatter [2] shows spoofing is still widespread and a current concern on the Internet.

Techniques such as ingress and egress address filtering and unicast reverse path forwarding are used in production networks to prevent spoofing, but these are typically useful only at the edge of the network and are often sporadically applied. Finding the source of spoofed packets remains an operationally difficult problem [3].

This work is an Internet-wide active measurement spoofing project. Clients distributed around the world attempt to source a series of spoofed UDP packets to test various filtering policies. In contrast to backscatter work which observes only the result of spoofing and is oblivious to the identity of the true sources, our research is concerned with finding the portion of the network allowing spoofing. Our goal is to quantify the extent and nature of source address filtering and the ability to spoof on the Internet.

Approach

There is no way to coerce random Internet hosts, to which we have no access, to send spoofed packets. Because of this inherent limitation, we make publicly available a "spoofer" application in source and binary formats. This small application allows users to test their own network and records the results on our server. The software as well as continually updated summary statistics are available on the Spoofer Project home page.

The spoofer first attempts to send a series of spoofed UDP packets, to a server on our campus. The source addresses we use are specially chosen to test what various filtering policies are in place. For example, IP address space is allocated by the Internet Assigned Number Authority (IANA) which has yet to delegate the entire space. Some networks employ filters that block traffic originating from unallocated regions of the IP address space. Others may prevent "martians," a colloquial term for traffic originating from IANA reserved portions of the IP address space. The range of addresses that include both unallocated and martian addresses are known as "bogons."

The first source is an unallocated, non-martian address. This address should not appear in any routing tables since IANA has yet to assign it to an organization. Next, the spoofer sends packets with a valid, allocated source address. In contrast to the first packet, this address appears in the global BGP routing table but is allocated to an organization other than the host which is spoofing. Notably, a filtering policy that allows only packets with source IP addresses that are present in the BGP table is easier for providers to implement and does not require continual manual updating. Next is a private RFC1918 address that is reserved for site-local routing. Best common practices dictate that privately addressed packets should be contained within AS boundaries.

Finally, the spoofer attempts to discover the granularity of any applied filtering by successively spoofing addresses from netblocks adjacent to its own. We accomplish this "neighbor spoof" by trying successively larger boundaries until spoofing an adjacent /8. To generate the address, we negate (i.e. flip) a bit at a time in the host's true source address beginning with the least significant bit. Thus, we start by spoofing an adjacent /31 address which corresponds to the host's address +/- 1, i.e. the immediate neighbor's address.

For each source address, the spoofer includes a unique random 14 byte identifier string in the payload of the UDP datagram. As our server receives UDP datagrams, they are recorded in a database for later retrieval. The unique string allows us to later disambiguate which spoofed packets were received and which were blocked.

After sending the spoofed UDP packets, the program establishes a TCP connection with the server to inform it of a new session. A session is defined by the true address of the client. The client informs the server of its operating system and the number of spoofed sources it sent. For each source, the client reports the identifiers of the spoofed packets it tried to send. Based on this transaction, the server records in the database the success or failure of this machine's ability to send spoofed packets. Finally, the spoofer runs a traceroute to our server which is also recorded in the database to determine the complete forward path of any spoofs.

Because UDP does not guarantee reliable delivery, we send five packets for each source address and use a random inter-packet delay between (0,500]ms to avoid incorrect inferences due to loss. To avoid any secondary filtering effects that would cause our test or reporting packets to be dropped for reasons other than source address filtering, we use UDP port 53 for the spoofed packets and TCP port 80 for the test summary report. These ports correspond to the well-known DNS and HTTP ports respectively and should be open in virtually all circumstances.

At the end of the report transaction, the user is provided a unique URL pointing to a web page containing her test results. This page summarizes the spoofing and filtering along the path from the user to our host.

Results

Over the course of a month, between February and March 2005, we received 434 client reports, 346 of which were unique. Our key findings thus far are:

• Approximately 23% of the observed netblocks, corresponding to 24% of the observed autonomous systems, allow spoofing.
• Filtering is frequently applied inconsistently or with automated methods that allow partial spoofing.
• In over 40% of cases, filtering policies are applied exactly on advertised routing boundaries, implying that projecting our results to the entire Internet is a reasonable approximation.

References

[1] V. Paxon. An Analysis of Using Reflectors for Distributed Denial-of-Service Attacks. ACM Computer Communications Review, July 2001.

[2] R. Pang and V. Yegneswaran and P. Barford and V. Paxson. Characteristics of Internet Background Radiation In Proceedings of ACM SIGCOMM/USENIX Internet Measurement Conference October 2004.

[3] B. R. Greene and C. Morrow and B. W. Gemberling. ISP Security: Real World Techniques NANOG 23 October 2001.