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.



  • Glad you asked, screenshots are available with example runs.

  • Participation is completely voluntary. That said, the more reports we receive, the better our network coverage is and hence the more accurate our understanding of the extent to which spoofing is possible. In addition, networks may install or remove anti-spoofing mechanisms over time, an effect we monitor as well. To improve user incentives to deploy the tool, we added support to the Spoofer client to test if the network has appropriate ingress filtering in place; specifically, we test if the client is able to receive traffic from our server with spoofed source IP addresses in the same /31 subnet as the client (IPv4) and the same /120 subnet as the client (IPv6). The tested network should filter such addresses at the edge of their network, per IETF Best Current Practice 84. This feature will also help operators detect weaknesses in their network that could be exploited by attacks such as triangular spamming.

  • Running the spoofer client helps identify inappropriate packets to filter coming into your network as well as protects the internet from inappropriate packets coming from your network (i.e., it aids in the health of your local network and the global Internet. As described above, we added support to the Spoofer client to test if the network has appropriate ingress filtering in place and test if the client is able to receive traffic from our server with spoofed source IP addresses in the same /30 subnet as the client (IPv4) and the same /120 subnet as the client (IPv6). The tested network should filter such addresses at the edge of their network

  • This project will collect sharable, actionable measurements of this vulnerability in networks around the world, and inform policy-making attempts to ameliorate the global security risk.

  • Our spoofer client does not alter files on your system, install backdoors or abuse its privilege. We provide complete, open source code for examination and use, in addition to pre-compiled binaries. We also provide SHA checksums on the web site as an additional measure of authenticity.

  • It is unlikely. Intrusion detection systems are bombarded with suspicious events continually. The small number of spoofed packets our client sends is unlikely to attract any attention. We have yet to hear of any reports that our spoofer raised a security alarm. That being said, always follow the rules and laws governing your network and do not run our tester if its use is in question.

  • Possibly. Some NATs do not rewrite the source address of packets if it is not within the NAT's internal prefix, and forward those packets. Our client test will detect and report these classes of spoofing.

  • Yes, please. We also maintain a count of netblocks that cannot spoof, due to proper filtering being in place.. Running the spoofer tool, even when the spoof is blocked, gives us valuable data.

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.
    We also send various sequences of spoofed packets to determine whether or not they can successfully enter your network and reach the client (ingress spoofing) when the tool is not being used from behind a NAT. We test using source addresses in the destination network itself -- internal addresses within the same IPv4 /31 or IPv6 /120 as the client). As with egress tests, we also test using source addresses intended for private networks: RFC 1918 addresses for IPv4, and unique local addresses (ULA) for IPv6. We do not make the results of ingress spoofing public, but we do notify a technical contact within the AS of our results when a technical contact is listed in WHOIS or PeeringDB.

  • 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 country's CERT agency. We also publish aggregated, anonymized (to a /24) results on this web site. We post 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.

  • Yes. CAIDA works with network operator groups throughout the world to vet and subscribe ourselves ( to regional operator community mailing lists. Each report we send, provided there is something to report, is geographically scoped and sent in a region-appropriate language. We currently subscribe to the following NOG mailing lists: AusNOG (Australia), DENOG (Germany), ESNOG (Spain), FRnOG (France), GTER (Brazil), ITNOG (Italy), JANOG (Japan), LUNOG (Luxembourg), MENOG (Bahrain, Egypt, Iran, Iraq, Jordan, Kuwait, Lebanon, Oman, Palestinian Territory, Qatar, Saudi Arabia, Syria, Turkey, United Arab Emirates, and Yemen), PacNOG (American Samoa, Cook Islands, Fiji, Micronesia, Fed. Sts., Guam, Kiribati, Marshall Islands, Northern Mariana Islands, New Caledonia, Niue, Nauru, Palau, Papua New Guinea, French Polynesia, Solomon Islands, Tokelau, Tonga, Tuvalu, Vanuatu, Wallis and Futura Islands, Samoa), NANOG (United States, Canada), NOG Bolivia (Bolivia), (Chile), NLNOG (Netherlands), NZNOG (New Zealand), SANOG (Afghanistan, Bangladesh, Bhutan, India, Sri Lanka, Maldives, Nepal, Pakistan), SGNOG (Singapore), and UKNOF (Great Britain).


  • For nearly 30 years we have know about source IP address spoofing vulnerabilities, and despite many efforts to mitigate or even 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 March 2018 during a 1.7 Tbps DDoS attack against Github. That particular attack used an amplification vector in Memcached; previous attacks against Cloudflare and Spamhaus in 2013 achieved 300+ Gbps using amplification vectors in NTP and DNS. In all of these cases, the attacks exploited the ability of (many) publicly accessible networks to spoof IP packets. While some application-layer patches can mitigate these vulnerabilities, attackers continuously search for new vectors. To defeat spoofed-source DDoS attacks requires operators to ensure their networks filter packets with spoofed source IP addresses, a best current practice (BCP) known as source address validation (SAV). However, a network's deployment of SAV primarily helps other networks, and is categorically incentive-incompatible, since a mistake configuring SAV or failure to keep it current could accidentally discard valid customer packets. SAV represents a classic tragedy of the commons in the Internet. Testing a network's SAV compliance requires a measurement vantage point inside (or immediately upstream of) that network, because the origin network of arbitrary spoofed packets cannot be determined. During the past three years, we built a production-quality software client that volunteers across the Internet could download and run from their networks, testing their own network's ability to send various types of spoofed packets to our server, which collected, aggregated, and publicly reported test results.
    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 Mar-27-2019 22:23:19 PDT
  Page URL: