| Internet-Draft | Remote Measurement of IP Spoofing | April 2024 |
| Wang, et al. | Expires 13 October 2024 | [Page] |
This document summarizes and standardizes methods for remotely measuring a network's IP spoofing capability. For outbound spoofing capability measurement, i.e., whether the network allows IP spoofing traffic to be sent from inside the network to the outside of the network, DNS traceroute can be used to check whether spoofed packets are generated in the network and sent to outside of the network. For inbound spoofing capability measurment, i.e., whether the network allows IP spoofing traffic from the outside the network to arrive inside, DNS resolver and ICMPv6 rate limiting mechanism can be utilized to check whether spoofed packets are received by devices in the network.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 13 October 2024.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Traditionally, routers only forward packets based on the destination IP address without checking the packet's source IP address. Source IP address spoofing, or IP spoofing, referring to a packet with a forged source IP address, can be used to hide the identity of the sender, or to pretend to be another host. IP spoofing can be exploited by malicious users to launch attacks, such as reflective DDoS attacks and DNS cache poisoning.¶
There are two kinds of IP spoofing, i.e., outbound spoofing and inbound spoofing. If a network allows outbound spoofing, a packet with source address different than those assigned to that network can be sent outside the network. In contrast, if a network suffers from inbound spoofing, a packet with source address assigned to that network can enter the network from the outside. In order to prevent from IP spoofing, source address validation (SAV) should be deployed to filtering spoofed packets. Corresponding to the two kinds of IP spoofing, there are also two kinds of SAV deployments. Outbound SAV (OSAV) is deployed to discard outbound spoofing traffic, and inbound SAV (ISAV) is deployed to discard inbound spoofing traffic.¶
While deploying SAVs can help discard spoofing traffic, network operators have little incentive to deploy SAVs because they worry about validation accuracy and operational overhead, and even accidental dropping of valid traffic [inter-domain-ps]. Furthermore, deploying OSAV only helps other networks but brings no benefits to the deployer. Even so, network operators are encouraged to deploy OSAV so that when OSAV is widely deployed, every network can benefit.¶
Identifying networks that allow IP spoofing, i.e., measuring IP spoofing capabilities, is important to characterize the threats faced by the Internet and help improve the security of the Internet. To measure whether a network can filter spoofing traffic, one can send spoofed packets and observe if the spoofed packets will be received. Figure 1 and Figure 2 illustrate the basic ideas of outbound spoofing capability and inbound spoofing capability measurements, respectively. For outbound spoofing capability measurement, spoofed packets with source addresses in prefix P1 are sent from the audited network AS 3, and if a host in AS 2 can receive the spoofed packets, then AS 3 allows outbound spoofing. For inbound spoofing capability measurement, spoofed packets with source addresses in prefix P1 are sent to the audited network AS 1, and if a host in AS 1 can receive the spoofed packets, then AS 1 allows inbound spoofing.¶
Spoofed Packets
+-----------+ +--------+ with Source Addresses in P1 +--------+
| AS 1 (P1) #-----# AS 2 #<-------------------------------# AS 3 |
+-----------+ +--------+ +--------+
Prefix P1 belongs to AS1, and AS 3 sends spoofed packets with
source addresses in P1 to AS 2.
If AS 3 allows outbound spoofing, the spoofed packets will be
received by AS 2. Otherwise, they will be dropped by AS 3.
Spoofed Packets
+-------------+ with Source Addresses in P1 +--------+
# AS 1 (P1) #<-------------------------------# AS 2 |
+-------------+ +--------+
Prefix P1 belongs to AS1, and AS 2 sends spoofed packets with
source addresses in P1 to AS 1.
If AS 1 allows inbound spoofing, the spoofed packets will be
received by AS 1. Otherwise, they will be dropped by AS 1.
Obviously, if a client can be deployed in the audited network to actively send spoofed packets to a controlled server and passively receive spoofed packets from a controlled server, the IP spoofing capability of the audited network can be easily measured. Based on the idea of client-based measurement, CAIDA spoofer project has collected data from 11,403 autonomous systems in 219 countries since 2015. However, CAIDA spoofer project heavily relies on volunteers in different networks to improve measurement coverage. This results in two limitations. First, it is quite challenging to involve lots of volunteers, especially new volunteers. For example, hundreds of ASes are measured by CAIDA spoofer project every month, where only tens of them are never measured before every month. Second, volunteers attracted by CAIDA spoofer project are generally more concerned about IP spoofing than others. This may cause biaes when characterising the IP spoofing in the Internet, i.e., underestimating the number of ASes that allow IP spoofing.¶
Therefore, remote measurement of IP spoofing without active cooperations from volunteers in the audited network is critical to improve measurement coverage and randomness. This document describes some methods for remotely measuring IP spoofing capabilities in the Internet. These methods have been proposed publicly before, and the goal of this document is to standlize these remote measurement methods, and exclude false measurement results by imporving these methods.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
A packet with forged source IP address. That is, the source IP address of the packet is not the legitimate IP address assigned to the sender.¶
The behavior where a network does not discard spoofed packets that pass through it.¶
The capability of a network to transmit spoofed packets.¶
The behavior where a network does not discard spoofed packets sent from the network to the outside.¶
The behavior where a network does not discard spoofed packets sent from the outside to the network.¶
The capability of a network to send spoofed packets to the outside of it.¶
The capability of a network to receive spoofed packets from the outside of it.¶
The mechanism that discards spoofed packets sent from a network to the outside of it.¶
The mechanism that discards spoofed packets sent from the outside of a network to it.¶
We can measure outbound spoofing capability remotely by exploiting address rewriters inside the audited network. An address rewriter modifies the destination IP address of packets sent to it to another address but leaves the source IP address unchanged. In this way, the modified packet becomes a spoofed packet because the source IP address of the packet sent by the address rewriter does not belong to it. Marc Kuhrer et al. exploits DNS proxies as address rewriters [dns-proxy]. Specifically, they send DNS queries to DNS proxies in the audit network. If a DNS response is received from a host other than the intended DNS proxy, they assume the DNS proxy is on a network that allows outbound spoofing.¶
+---------------------+ +--------------------+
| +-------------+ | | +------------+ |
| | Scanner IP1 #---|------------------|--># Target IP2 | |
| +------#------+ | From: IP1 | +------#-----+ |
| /\ | To: IP2 | | |
| AS1 | | | AS2 | |
+---------------------+ +--------------------+
| |
From: IP3 | +----------------------+ | From: IP1
To: IP1 | | +--------------+ | | To: IP3
+--------|---# Receiver IP3 #<--|--------+
| +--------------+ |
| AS3 |
+----------------------+
Target IP2 forwards the packet by changing the destination IP address to
IP3 and leaving the source IP address unchanged. This behavior looks like
the target sends spoofed packets directly with the source IP address IP1.
As illustrated in Figure 3, an address rewriter (IP2) forwards the packet by changing the destination IP address and keeping the source IP address unchanged. The address rewriters may be due to the misconfigured destination NAT, which translates the destination IP address of incoming packets to a preset address (IP3). Since the source IP address of the modified packet is the scanner (IP1), the scanner will receive the response from the receiver IP3, even though the scanner has never sent a packet to the receiver. This process can be used to determine whether the target network (AS2) blocks spoofed packets since this behavior looks like the target IP2 is sending spoofed packets directly with the forged source IP address IP1.¶
+---------------------+ +--------------------+
| +-------------+ | | +------------+ |
| | | | | | Target | |
| | Scanner IP1 #---|------------------|-->#IP2 | |
| | | | From: IP1 | | IP3 | |
| +------#-----+ | To: IP2 | +------#-----+ |
| /\ | | | |
| AS1 | | | AS2 | |
+---------------------+ From: IP3 +--------------------+
| To: IP1 |
+----------------------------------------+
Target has two interfaces with source IP addresses of IP2 and IP3. In
this case, the target will receive packets with IP2 but respond to them
with IP3.
From the scanner's perspective, it sends a packet to IP2 but receives the response from IP3. However, this phenomenon does not always indicate an address rewriter. As illustrated in Figure 4, a target with two interfaces can receive packets from one interface but respond with another. The behavior of alias targets does not generate spoofed packets and cannot be used to measure outbound spoofing capability.¶
We can use traceroute to distinguish between address rewriters and alias targets. Traceroute sends packets with increasing Time-To-Live (TTL) values, exploiting ICMP Time Exceeded messages from intermediate routers sequentially revealing the network path between the source and destination. Moreover, we can figure out the network path between an address rewriter and its receiver since address rewriters usually send modified packets without resetting TTL values. With the help of quoted packets in ICMP error messages, we can detect the change of the destination IP address of the packets from the scanner, which indicates an address rewriter.¶
+---------------------+ +--------------------+
| +-------------+ | | +------------+ |
| | Scanner IP1 #---|------------------|--># Target IP2 | |
| +------#------+ | From: IP1 | +------#-----+ |
| AS1 /\ | To: IP2 | AS2 | |
+----------|----------+ +----------|---------+
| From: IP3 | From: IP1
| To: IP1 | To: IP3
+----------|----------+ +----------V---------+
| +------#-------+ | | +------#-----+ |
| | Receiver IP3 #<------------------------# Router IP4 | |
| +--------------+ | From: IP1 | +------------+ |
| AS3 | To: IP3 | AS4 |
+---------------------+ +--------------------+
The spoofed packets generated by the target are not blocked, and the
scanner performing a traceroute to the target can receive both the ICMP
Time Exceeded message from IP4 and the response packet from IP3.
When an address rewriter in the target network is identified, we can measure whether the target network blocks spoofed packets. As illustrated in Figure 5, if the target network does not block spoofed packets, the spoofed packets will be transmitted outside the target network. Then, the scanner may receive the response from the receiver (IP3) and/or receive ICMP Time Exceeded messages from routers (e.g., IP4) outside the target network. As long as the scanner receives packets from outside the target network, we know that the spoofed packets do arrive outside the target network. Therefore, the target network does not block spoofed packets.¶
+---------------------+ +---------------------+
| +-------------+ | | +------------+ |
| | Scanner IP1 #---|------------------|--># Target IP2 | |
| +-------------+ | From: IP1 | +------#-----+ |
| | To: IP2 | |From: IP1 |
| | | |To: IP3 |
| AS1 | | AS2 V |
+---------------------+ +----------x----------+
blocked
+----------------------+
| +--------------+ |
| | Receiver IP3 | |
| +--------------+ |
| AS3 |
+----------------------+
The spoofed packet generated by the target is blocked, and the
scanner will never receive responses from IP3.
On the other hand, as illustrated in Figure 6, if the target network blocks spoofed packets, the spoofed packets will never be transmitted to the receiver. As a result, the scanner will never receive any response from the receiver. However, there are two cases where the scanner can not receive any response from the receiver: one is that the spoofed packet is blocked, and the other is that the receiver does not respond to packets from the scanner. To distinguish between the two cases, we send a regular packet from the scanner to the receiver to check whether the receiver responds to packets from the scanner. If the receiver can respond to packets coming directly from the scanner, but the spoofed packets fail to trigger a response from the receiver, we assume that the target network blocks the spoofed packets.¶
The key idea of inbound spoofing capability measurement is to first send some spoofed packets to the target network and then observe whether the spoofed packets arrive inside of the target network. To this end, DNS resolvers [dns-resolver] and Customer Premises Equipment (CPE) devices [ICMPv6] can be leveraged for the observation.¶
+-----------------+ +------------------------------------+
| AS1 | | AS2 |
| | | +--------------+ +-----------+ |
| +-------------+ | DNS query | | DNS resolver | | Host | |
| | Scanner IP1 #-|---------------|-># IP2 #--># IP3 | |
| +-------------+ | From:IP3 | +------+-------+ +-----------+ |
| | To:IP2 | | |
+-----------------+ +------------------------------------+
|
V
+------#------------+
| Authoritative DNS |
| nameserver (ADNS) |
+-------------------+
Figure 7 shows the scanning setup for AS2. The scanner in AS1 sends a DNS query with forged IP addresses IP3, which belongs to the audited network (AS2), to a DNS resolver in AS2. If the audited network allows inbound spoofing, the DNS resolver will receive the spoofed DNS query. Next, the DNS resolver will send another DNS query to our controlled authoritative DNS nameserver to resolve. Therefore, if the controlled authoritative DNS namesever receives the DNS query from the DNS resolver in the audited network, the audited network AS2 does not filter the spoofed packets from outside.¶
However, if the controlled authoritative DNS nameserver does not receive the DNS query, we can not assume that the audited network filters the spoofed packets, since there may be no DNS resolver in the audited network. To futher identify networks that filter inbound spoofing traffic, we send a non-spoofed DNS query from the scanner to the same target IP address. If the controlled authoritative DNS nameserver receives a DNS query triggered by the non-spoofed DNS query, a DNS resolver exists in the audited network. As a result, if the DNS resolver does not resolve the spoofed query, we can conclude that the audited network does not allow inbound spoofing.¶
SPOOFED DNS QUERY
N ADNS receives no query ADNS receives a query
O D +---------------------------------------------------+
N N ADNS receives | | |
| S a query | block inbound spoofing | allow inbound spoofing |
S | | |
P Q -----------------------------------------------------
O U ADNS receives | | |
O E no query | unknown | allow inbound spoofing |
F R | | |
E Y +---------------------------------------------------+
D
As illustrated in Figure 8, there are four cases when combining spoofed DNS query and non-spoofed DNS query.¶
First, the authoritative nameserver receives DNS requests in both spoofing scan and non-spoofing scan, suggesting that the audited network allows inbound spoofing, and the DNS resolver is open.¶
Second, the authoritative server receives the DNS request only in spoofing scan, suggesting that the audited network allows inbound spoofing, and the DNS resolver is closed.¶
Third, the authoritative server receives the DNS request only in non-spoofing scan, suggesting that the audited network does not allow inbound spoofing.¶
Fourth, the authoritative namesever does not receive any DNS request. This suggests that no DNS resolver in the audited network can be leveraged to measure inbound spoofing capability. Therefore, the ability of the network to filter inbound spoofing traffic is unknown.¶
As suggested by RFC 4443 [RFC4443], in order to limit the bandwidth and forwarding costs incurred by originating ICMPv6 error messages, an IPv6 node MUST limit the rate of ICMPv6 error messages it originates. This provides an opportunity to infer whether the spoofed packets arrive inside of the audited network based on the state of ICMPv6 rate limiting.Since most of IPv6 addresses are inactive, an ICMP error message will be fed back from CPE devices when we send an ICMP echo request to a random IP address in the audited network. If the CPE device limits the rate of ICMPv6 error messages it originates, it can be utilized as a remote vantage point (RVP).¶
Figure 9 illustrates the ICMPv6-based measurement method. We have a local scanner P1 in AS1, and AS2 is the audited network. Three rounds of testing with N and N+M ICMP echo requests packets are conducted in the measurement, and thus three values rcv1, rcv2, and rcv3 can be obtained respectively. Based on this, we can infer whether the audited network filters the spoofed packets by comparing rcv1, rcv2, and rcv3.¶
+------------------+ +-----------------------------+
| AS1 | | AS2 +------------+ |
| +-----------+ | | +-----+ |Unreachable | |
| |Scanner(P1)| | | | RVP | |IP address T| |
| +---+-------+ | | +---#-+ +--#---------+ |
| | | | | | |
+------------------+ +-----------------------------+
| | |
+--------+ N ICMP echo requests +--------------------->+
| src:P1 dst:T | |
round 1| | |
+<-------+ rcv1 ICMP Error Messages +---------+ |
| | |
| | |
+--------+ N ICMP echo requests +---------------------->+
| src:P1 dst:T | |
round 2| | |
+--------+ M ICMP echo requests +---------------------->+
| src:arbitrary IP in AS1,dst:T | |
| | |
+<-------+ rcv2 ICMP Error Messages +---------+ |
| | |
| | |
|XXXXXXXXXXXXXXXXX SCENARIO 1 XXXXXXXXXXXXXXXXXXXXXXXXXX|
| | |
+--------+ N ICMP echo requests +---------------------->+
| src:P1, dst:T | |
| | |
+--------+ M ICMP echo requests +---------------------->+
| src:arbitrary IP in AS2,dst:T | |
| | |
|XXXXXXXXXXXXXXXXX SCENARIO 2 XXXXXXXXXXXXXXXXXXXXXXXXXX|
round 3| | |
+--------+ N ICMP echo requests +--------------------->+
| src:P1 dst:T | |
| XX | |
+--------+ M ICMP echo requests +-------->XX | |
| src:arbitrary IP in AS2,dst:T XX | |
| XX | |
|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX|
| | |
+<-------+ rcv3 ICMP Error Messages +---------+ |
As illustrated in Figure 9, in the first round test, N ICMP echo requests are sent to a target with inactive IPv6 address in the audited network, and then RVP will resposnd with rcv1 ICMP error messages to the scanner. In the second round test, besides the same N probe packets, extra M ICMP echo requests with forged source address that belongs to AS1 (noise packets) are sent to the target simultaneously. The number of ICMP error messages in the second round test are defined as rcv2. Similar to the second round test, in the third round test, M ICMP echo requests with forged source address that belongs to AS2 (spoofed packets) are sent to the target. The number of ICMP error messages in the third round test are defined as rcv3.¶
Comparing rcv1 and rcv3, if rcv1 > rcv3, it can be considered that the spoofed packets are not filtered in the third round test, suggesting that the audited network allows inbound spoofing. Comparing rcv2 and rcv3, if rcv2 < rcv3, it can be inferred that the target network has filtered the spoofed packet in the third round test, and thus is able to filter inbound spoofing traffic. The ability of filtering inbound spoofing traffic can be inferred according to the following rules.¶
If rcv3 < a*rcv1, then the network allow inbound spoofing;¶
Else if rcv2 < a*rcv3, then the network does not allow inbound spoofing;¶
Else, the ability of filtering inbound spoofing traffic cannot be determined.¶
where a is a factor to avoid potential interference from fast-changing network environments, satisfying 0 < a < 1.¶
+----------------------------------+-----------------+ | Type | # ASes | +----------------------------------+-----------------+ | IPv4 Outbound Spoofing Blocked | 373 | +----------------------------------+-----------------+ | IPv4 Outbound Spoofing Unblocked | 5,309 | +----------------------------------+-----------------+ | IPv4 Inbound Spoofing Unblocked | 35,163 | +----------------------------------+-----------------+ | IPv6 Inbound Spoofing Blocked | 3,677 | +----------------------------------+-----------------+ | IPv6 Inbound Spoofing Unblocked | 8,174 | +----------------------------------+-----------------+
As shown in Figure 10, with the address rewriter-based method, we found spoofed packets sent from 373 IPv4 ASes are blocked, and 5,309 IPv4 ASes are not. With the DNS resolver-based method, we found 35,163 IPv4 ASes did not block spoofed packets from outside. Combining DNS resolver-based method and ICMPv6-based method, we found that 8,174 IPv6 ASes did not block spoofed packets from outside, and 3,677 IPv6 ASes blocked spoofed packets from outside.¶
This document has no IANA requirements.¶