Methods for Remotely Measuring IP Spoofing Capability

Introduction 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 . 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. and 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.

An example for illustrating the basic idea of outbound spoofing capability measurement.

An example for illustrating the basic idea of inbound spoofing capability measurement. 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.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Terminology

Spoofed Packet:: 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.
IP Spoofing:: The behavior where a network does not discard spoofed packets that pass through it.
IP Spoofing Capability:: The capability of a network to transmit spoofed packets.
Outbound Spoofing:: The behavior where a network does not discard spoofed packets sent from the network to the outside.
Inbound Spoofing:: The behavior where a network does not discard spoofed packets sent from the outside to the network.
Outbound Spoofing Capability:: The capability of a network to send spoofed packets to the outside of it.
Inbound Spoofing Capability:: The capability of a network to receive spoofed packets from the outside of it.
Outbound Source Address Validation:: The mechanism that discards spoofed packets sent from a network to the outside of it.
Inbound Source Address Validation:: The mechanism that discards spoofed packets sent from the outside of a network to it.

Outbound Spoofing Capability Measurement Method 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 . 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.

The example of how an address rewriter generates spoofed packets. # 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 , 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.

The example of how an alias target responds. #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 , 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.

The example of how to identify a network that does not block spoofed packets. # 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 , 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.

The example of how to check whether a network blocks spoofed packets. # 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 , 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.

Inbound Spoofing Capability Measurement Method 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 and Customer Premises Equipment (CPE) devices can be leveraged for the observation.

Measurement Method Leveraging DNS Resolvers

The example of sending DNS query with forged source address. # IP2 #--># IP3 | | | +-------------+ | From:IP3 | +------+-------+ +-----------+ | | | To:IP2 | | | +-----------------+ +------------------------------------+ | V +------#------------+ | Authoritative DNS | | nameserver (ADNS) | +-------------------+ ]]> 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.

Classification of results based on DNS resolvers. As illustrated in , 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.

Measurement Method Based on ICMPv6 Rate Limiting As suggested by RFC 4443 , 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). 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.

Three round tests of ICMPv6-based measurement method. + | 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 , 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.

Measurement Results

Measurement results for a single month. As shown in , 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.

IANA Considerations This document has no IANA requirements.