2 - Participation

1. What can I expect when I run the tester?
   Glad you asked, screenshots are available with example runs.
2. Why would I want to participate in this study?
   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.
3. How does my participation help my network?
   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
4. How does my participation help solve the spoofing problem?
   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.
5. Is there any chance that running this tool can compromise my system?
   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.
6. Will running this tool attract the attention of my ISP and raise security alarms?
   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.
7. I am behind a NAT, will I be able to spoof?

   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.

   In practice, there are two failure modes where a NAT will forward packets with spoofed source addresses. We illustrate these failure modes in Figure 1. In the first failure mode (a), the NAT simply forwards the packets with the spoofed source address (the victim) intact to the amplifier. We hypothesize this occurs when the NAT does not rewrite the source address because the address is not in the local network served by the NAT. In the second failure mode (b), the NAT rewrites the source address to the NAT's publicly routable address, and forwards the packet to the amplifier. When the server replies, the NAT system does the inverse translation of the source address, expecting to deliver the packet to an internal system. However, because the mapping is between two routable addresses external to the NAT, the packet is routed by the NAT towards the victim.

   Figure 1: The two ways a NAT can forward packets with spoofed addresses. First, a NAT may forward packets with a (V)ictim's address towards an (A)mplifier. Second, a NAT may rewrite the source address, but translate the response so the response reaches V.

8. I know my network prevents spoofing, should I run the spoofer anyway?
   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.

3 - Data Collection and Disclosure

1. What information does the tool collect about my network?
   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.
2. How is this information shared?
   Users can 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 for IPv4 and to a /40 for IPv6) results on this web site. We post per AS and per country statistics.
3. What is the purpose of anonymizing to a /24 or /40?
   We are balancing the need for identifying exactly which networks allow this vulnerability, with the need to minimize potential risks to people who could be harmed for having run the test (e.g., on someone else's network they are visiting.) For public reporting, we anonymize IP addresses by concealing at least the last eight bits of the address -- i.e., for IPv4 addresses we publicly provide the first 24 bits of the address. For IPv6 addresses, we publicly provide the first 40 bits, as ISP operators may use DHCP prefix delegation to delegate prefixes between 48 and 64 bits to individual subscribers.
4. Won't this project help people who want to find "spoofable" networks?
   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.
5. Does Spoofer do automated reporting?
   Yes. CAIDA works with network operator groups throughout the world to vet and subscribe ourselves (spoofer-info@caida.org) 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: AONOG (Angola), ArNOG (Argentina), AusNOG (Australia), CLNOG (Chile), DENOG (Germany), ESNOG (Spain), FRnOG (France), GTER (Brazil), GTNOG (Guatemala), INNOG (India), 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), NANOG (United States, Canada), netUK (Great Britain), NLNOG (Netherlands), NOG Bolivia (Bolivia), NOG Colombia (Colombia), NZNOG (New Zealand), 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), PANOG (Panama), RSNOG (Serbia), SANOG (Afghanistan, Bangladesh, Bhutan, Sri Lanka, Maldives, Nepal, Pakistan), SGNOG (Singapore), and VENOG (Vietnam).

4 - Relevance

1. Is spoofing still really a significant attack vector?Don't ISPs deploy uRPF to prevent it?
   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.
2. What about positive uses of spoofing, such as reverse traceroute?
   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.

5 - Client

1. Why do I have to run the spoofer as root?
   Programs that create raw sockets must run as root. If you are concerned about the security of our binaries, we welcome you to examine the provided source code and build your own.
2. What's the difference between versions?
   See the CHANGES file in the source distribution.
3. How do I test IPv6 spoofing?
   Our client will automatically test IPv6 spoofing if it detects an IPv6 address on the host.
4. Can I use your system without the Scheduler or GUI?
   Yes. If installing a binary release, you can prevent the Scheduler from running by disabling the "start now" and "start at boot" options. If building spoofer from source, the Scheduler will not be run automatically; you can prevent it from even being built by passing the "--disable-manager" option to configure. In binary or source installations, you can always run the spoofer-prober manually, or from your own cronjob or script.
5. Can you please explain "tracefilter" and how you're using it?
   Sure, see Rob Beverly's original paper on tracefilter, Tracefilter: A Tool for Locating Network Source Address Validation Filters.

6 - Statistics

1. How do you deal with sample bias?
   Sample bias is an inherent risk of any opt-in measurement method. We have developed an openWRT version of the client, and are trying to get it integrated into that code base. In the meantime, the client runs in the background on OSX, windows, and Linux, whenever it detects a new network. This change has helped with the sparseness of the data, because laptops visit different networks and the tests run automatically.
2. Can you provide addresses of spoofable netblocks/ASes?
   Yes. we now publish netblocks and ASes for any tests marked shareable in the tool configuration.
3. How do you determine what country an address belongs to?
   We use NetAcuity geolocation to map IP addresses to countries.
4. To extend coverage, why not put a Spoofer client on RIPE Atlas probes?
   That question has come up on the relevant RIPE mailing list and our understanding is that RIPE management has said no.