Skip to Content
[CAIDA - Center for Applied Internet Data Analysis logo]
Center for Applied Internet Data Analysis
Spoofer: FAQ
Questions asked and answered about the Spoofer project.
|   Spoofer Project Page    Download    FAQ   |


  • IP spoofing is the practice of forging various portions of the Internet Protocol (IP) header. Because a vast majority of Internet traffic, applications, and servers use IP, IP spoofing has important security implications. Please see the Wikipedia article on IP address spoofing.

  • The Spoofer Project seeks to understand the Internet's vulnerability to different types of spoofed-source IP address attacks. Rob Beverly supported the Spoofer project from 2005-2015, with no dedicated source of funding, and wanted to find a permanent home for the project. The U.S. Department of Homeland Security Science and Technology Directorate funded CAIDA to take on stewardship of the Spoofer project, under Dr. Matthew Luckie's leadership. This contract started August 2015.

  • No, sorry, this project is concerned only with IP source address spoofing. This Wikipedia article on IP address spoofing explains the difference.


Data Collection and Disclosure

  • The tool sends various sequences of spoofed packets to determine whether they can successfully exit your network and reach our server (egress spoofing). For example, we test using source addresses within (internal to) your network, but not assigned to your host, as well as source addresses outside your network altogether. If your host is inside an independently routed /24 prefix, we test addresses in an encompassing /23, /22, ...up to the containing /8. We also test using source addresses intended for private networks: RFC 1918 addresses for IPv4, and unique local addresses (ULA) for IPv6. Finally, we also test if systems that are not behind a NAT device can receive spoofed packets from outside the network (ingress spoofing) using addresses intended for private networks, and using internal addresses in the destination network itself.

  • Users can now explicitly allow their test results to be publicly sharable. We share individual tests with relevant operational security stakeholders, e.g., we will share data about a specific country's networks with that's country CERT agency. We also publish aggregated, anonymized (to a /24) results on this web site. We post per-AS and per-country statistic per AS and per country statistics.

  • We are balancing the need for identifying exactly which networks allow this vulnerability, with the need to minimize potential risks to people who be harmed for having run the test (e.g., on someone else's network they are visiting.)

  • That is the primary ethical consideration that has kept researchers/others from posting such test results over the last 10+ years of available measurements. This also comes down to a balance of risks: helping the bad guys find vantage points for mischief, vs. helping the good guys identify vulnerable parts of the infrastructure to ameliorate. Our understanding, with input from several operational security communities, is that bad guys are not having trouble finding places from which to spoof, but good guys are essentially blind with respect to how/where this particular vulnerability is distributed, in topological, geographic, and jurisdictional terms. So we believe community thinking has shifted over the last ten years in favor of transparency for this particular measurement.


  • Despite source IP address spoofing being a known vulnerability for at least 25 years, and despite many efforts to shed light on the problem (e.g. [Beverly 2005,Beverly 2009,Beverly2013]), spoofing remains a viable attack method for redirection, amplification, and anonymity, as evidenced most recently and publicly in February 2014 during a 400 Gbps DDoS attack against Cloudflare. That particular attack used an amplification vector in some implementations of NTP; a previous attack against Spamhaus in March 2013 achieved 300+ Gbps using an amplification vector in DNS. While some application-layer patches can mitigate these attacks, attackers continuously search for new vectors.
    Our measurements show that spoofing is still prevalent among approximately 25% of the autonomous systems and netblocks we survey. More importantly, a single entry point for spoofed traffic provides attackers a means to send spoofed traffic to the entire Internet. ISPs can employ filtering [RFC2827] to ensure their outbound traffic is not spoofed. But there is currently no way to ensure that inbound traffic is legitimate as long as there exist entry points for spoofed traffic. uRPF [RFC3704] does not work, and is not used, in the core of the network where routing asymmetry renders it useless.

  • There are very few instances of legitimate source spoofing. Even when spoofing is intended for a legitimate purpose, it is almost certainly the wrong architectural response. Clearly there is a tradeoff between the current state of affairs where the semantics of source IP addresses are overloaded, e.g. for authentication, and security. Our stance is that benefit of enforcing packets sent to have the same source address as the sender far outweigh any downside.




Still have a question? Please let us know!
  Last Modified: Wed Jun-13-2018 11:38:21 PDT
  Page URL: