Despite being a known vulnerability for at least 25 years, source IP address spoofing remains a popular attack method for redirection, amplification and anonymity. Preventing these attacks requires that operators implement Source Address Validation (SAV) to ensure their networks filter packets with spoofed source IP addresses.
In this post, we provide an introduction/refresher on what SAV is and discuss methods to detect non-compliant networks and the incentives that the industry must enact to make deployment of SAV attractive.
IP spoofing invokes a variety of attacks
IP spoofing is the act of using forged source IP addresses assigned to other machines. Malicious actors use IP spoofing to invoke a variety of attacks including Distributed Denial of Service (DDoS) attacks, policy evasion, and a range of application-level attacks.
Adversaries take advantage of public services prone to amplification, such as open DNS resolvers or NTP servers, to which they send requests on behalf of their victims by spoofing their source IP addresses. As a result, the victim receives a large number of responses that congest its network or system, making it unavailable for incoming and outgoing traffic.
A prime example of a successful IP spoofing attack occurred in 2018, when attackers spoofed the IP address of GitHub, a popular code hosting platform. They sent requests to open memcached servers, which returned 50 times the data of the requests back to the victim, resulting in traffic of 1.35Tbps. As a consequence, GitHub services were unavailable for about 20 minutes.
Similarly, in a study, ‘Weaponizing Middleboxes for TCP Reflected Amplification‘, the authors presented a methodology for TCP-based amplification compared with well-known UDP-based techniques. Their methodology uses TCP noncompliance in network middleboxes to create reflective amplification attacks. In March of 2022, Akamai reported that they had uncovered an attack with traffic volumes of up to 11Gbps at 1.5M packets per second (Mpps).
Whether it is traditional UDP-based or TCP-based attacks, IP spoofing enables attackers to generate malicious traffic that can affect ISPs, hosting providers, education and healthcare providers, and other service providers. Having more network providers implementing SAV in their network can significantly reduce the number of potential attack vantage points from which DDoS attacks based on IP spoofing are launched.
SAV is a two-step process
Network operators can implement filtering anywhere within their network. However, best current practices (BCPs) recommend they perform it close to the edge of the network. To this end, most equipment vendors support ingress filtering in some form and MANRS provides an extensive guide for network operators to implement SAV in their network. This includes:
- Outbound SAV (oSAV) — filtering applied at the network edge to traffic coming from inside the customer network to the outside.
- Inbound SAV (iSAV) — filtering applied at the network edge to traffic coming from the outside to the customer network.
Network operators must implement both of these best practices to mitigate IP spoofing attacks.
If they implement oSAV — filtering outgoing packets with spoofed IP addresses — but not iSAV, adversaries can impersonate another host on the victims network, bypassing host-based authentication, among other attack vectors. For example, an authoritative DNS server for a given domain may be configured to accept non-secure DNS dynamic updates from hosts (a DHCP server) on the same network. Therefore, sending a single spoofed UDP packet from the outside with that host’s IP address will modify the zone file’s content. The attack vector can be used to hijack the domain name. The zone poisoning research paper further explains the attack vector.
Best practices for deploying SAV
RFCs 2827 and 3704 — better known in the network operations and research communities as BCP 38 and 84 — describe how to implement SAV to prevent DDoS attacks.
BCP 38 presents the idea of checking source IPs of all the packets at the network periphery against a set of permitted addresses. Depending on the network type, this could be done in different locations:
- At the point of interconnection with a single customer (access network).
- At the edge routers connected to neighbors (enterprise network).
- At the provider-edge router connected to customers (transit provider).
Technically, SAV can be performed using Strict or Feasible Reverse Path Forwarding (sRPF/fRPF). A router configured with sRPF will drop a packet if it arrives on a different interface than the router would choose when forwarding a packet to the packet’s source address. In contrast, fRPF will consider all paths it could use to reach the source address.
For single-homed customers, a transit provider may simply discard packets with source IPs outside the set of customer-announced prefixes. BCP 84 further discusses the case of multi-homed networks. It may be the case that neither sRPF nor fRPF are feasible if a customer does not announce all its prefixes to each neighbor router (for example, traffic engineering). Instead, an operator might define an ingress ACL with prefixes that the router will forward. BCP 84 states that while ingress ACLs require manual maintenance if a neighbor acquires additional address space, they are “the most bulletproof solution when done properly”, and the “best fit … when the configuration is not too dynamic, …if the number of used prefixes is low.”
Detecting non-compliant networks
Numerous initiatives enumerate networks that do not deploy SAV (Table 1).
| Method | SAV direction | Presence/ absence | Remote | Relies on misconfigurations |
| Spoofer project | oSAV/iSAV | Both | No | No |
| Open resolver method | oSAV | Absence | Yes | Yes |
| Traceroute method | oSAV | Absence | Yes | Yes |
| IXP based method | oSAV | Both | No | No |
| Closed resolver method | iSAV | Both | Yes | No |
They differ in terms of:
- The filtering direction:
- For traffic coming from inside the customer network to the outside (outbound SAV or oSAV).
- For traffic coming from the outside to the customer network (inbound SAV or iSAV).
- Whether they infer the presence or absence of SAV.
- Whether doing measurements remotely or on a vantage point inside the tested network is required.
- If the method relies on existing network misconfigurations.
The Spoofer project
The Spoofer project is a state-of-the-art, crowd-sourced platform that measures SAV compliance. It allows volunteers to run a client program sending spoofed packets to the server, which in turn, inspects the traffic and concludes on filtering policies in both directions (iSAV and oSAV).
Network operators can use the tool on Windows, MacOS, or UNIX-like systems to test their network’s compliance. The results on their website are aggregated per /24 IPv4 (/40 IPv6) network blocks keeping account of the latest measurement results. They are reported publicly on the Spoofer project website and via the API but can also remain private.
Figure 2 shows the percentage of networks not deploying SAV to all those tested per economy. Keep in mind that although some economies, such as Tunisia, have a high ratio of non-compliant networks, only 14 were tested (contrary to 1,900 in the USA). Moreover, multiple network blocks can belong to the same Autonomous System (AS).
Open resolvers method
Misconfigured DNS forwarders can also be used to test BCP 38 compliance. Figure 3 summarizes the idea:
In the first scenario (3a), the scanner 192.0.2.3 requests the forwarder 203.0.113.54 to resolve example.com. The forwarder relays the request to 8.8.8.8 located outside as is, that is without rewriting the original source IP of 192.0.2.3. If such a query leaves the tested network, it means that no oSAV is enforced.
The scenario in 3b is slightly different, where the response from 8.8.8.8 is forwarded to 192.0.2.3 without modifying its source IP. The scope of this method is limited to networks hosting misconfigured DNS forwarders.
Traceroute method
The traceroute can show the absence of ingress filtering by providers of stub AS. When the traceroute path reaches the stub AS and then exits, traceroute packets contain the source address belonging to the vantage point launching the traceroute. If the provider’s border router is performing SAV, it should filter the traceroute packet when it arrives from the stub AS, as the packet has a source address not belonging to the stub AS. If the provider’s router does not perform SAV and forwards the packet, then the traceroute will show an apparent IP-level forwarding loop as the provider’s router returns subsequent packets to the stub AS.
Figure 4 illustrates a simple point-to-point loop that reveals an absence of oSAV for the provider AS at the provider-customer interconnect. We can extend the same methodology to observe a lack of SAV for traceroute loops that traverses multiple providers.
IXP-based methods
Internet Exchange Points (IXPs) form a central point of communication between ASes. As such, they offer unique vantage points to passively detect spoofed packets in traffic exchanged between networks in the inter-domain Internet.
A very simplistic overview of the methodology would be to analyse the flow of traffic passing IXPs and classify packets with a spoofed IP address if the source IP address cannot originate from the ASes in the path.
A 2017 study proposed a way for IXPs to determine source addresses that should not be sourced by individual networks based on BGP routing information — if the member AS sends a packet into the IXP switching fabric with a source address not belonging to legitimate prefixes, the AS in question does not deploy SAV. The authors applied the method to classify the traffic exchanged between more than 700 networks at a large European IXP. They found that most of the connected networks do not filter their outgoing traffic.
A follow up study proposed two fundamental improvements to the existing method:
- Take into account the type of relationship between neighbors.
- Consider asymmetric routing and traffic engineering that includes addresses that may be valid source addresses for an AS to transit.
These two additional changes remove false positives from the first method.
The Closed Resolver method
The Closed Resolver project relies on DNS resolvers to infer the deployment of iSAV. The scanner sends DNS A requests with spoofed source IP addresses for which the destination is every host of every routing prefix, and the source is the next host in the same prefix.
The setup also includes an authoritative name server for the queried domains. The server infers that the network does not filter inbound packets with its own IP space if it receives a request from the resolver in the network.
The method is fast, remote, and does not rely on any misconfigurations. Moreover, if coupled with open resolver scans, it can also detect the presence of iSAV (when the resolver processes only non-spoofed DNS requests). More details about this method can be found in this blog post.
How do we incentivize operators to use SAV?
The lack of visibility into whether or not a network operator deploys SAV presents a significant challenge for incentivizing compliance. Without a clear benefit to adopting this good practice, many operators may choose not to invest the time and resources required to implement it. Conversely, there is no clear negative impact for non-compliance, as the information is not readily available to the public or other providers who might use it in peering decisions.
To address this challenge, a responsible and visible organization is needed to host and notify operators that are not SAV compliant. Currently, the Center for Applied Internet Data Analysis (CAIDA) is the only organization hosting the Spoofer tool and data on network operator compliance. While the project is well-maintained, its visibility needs to be improved. Network operators are unlikely to visit the Spoofer page without intervention or notification about their non-compliance.
To enhance visibility and encourage compliance, involving prominent organizations in the operator community, such as MANRS or RIRs, can be an effective approach. These organizations can keep track of compliance at various levels, including IP, prefix, ASN, and economy, and provide vital training and educational resources to network operators. In addition to this, their involvement can offer the much-needed visibility for both compliant and non-compliant networks.
Moreover, as in most academic research, the methodologies to detect compliant/non-compliant networks have remained mostly in the proof-of-concept stage. While there have been some promising developments in recent years, there is still a lack of practical implementations of these methodologies in real-world networks. This has resulted in scant follow-up studies and a lack of data collected longitudinally, making it difficult to assess the effectiveness of SAV measures over time.
To increase visibility and incentivize organizations to adopt SAV, community-driven initiatives can play a crucial role. These initiatives can implement the methodologies mentioned above and collect data longitudinally. The results can be hosted at organizations such as MANRS or RIRs, which can increase the visibility of compliant/non-compliant networks and incentivize organizations to adopt SAV. In this regard, we must conclude that collective action by the community is needed if we hope to increase SAV compliance in the coming years.
Qasim Lone is a research engineer in the R&D department at RIPE NCC, interested in Internet measurement, outages, data analysis, and cybersecurity.
Adapted from the original at RIPE Labs.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
in 2013 or so I got the bcp38 package accepted into openwrt. I do not know in how many places it ultimately went, but I have a bit a guilt in that in the last release, it stopped working.
My larger point however, is that you need to incentivize *vendors* to make available the tools to make SAV easy to deploy. Few have.