| Internet-Draft | Remote Measurement of OSAV Deployment | October 2024 |
| Wang, et al. | Expires 19 April 2025 | [Page] |
Outbound IP spoofing, where attackers send packets with forged source IP addresses, poses a significant threat to Internet security. Measuring the deployment of outbound source address validation (OSAV) is critical for characterizing the vulnerability to outbound IP spoofing across the global Internet. Remote measurement of OSAV deployment offers a practical method for measuring numerous Autonomous Systems (ASes) efficiently. This document presents a method for remotely measuring the deployment status of OSAV, without cooperations from volunteers in remote networks.¶
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 19 April 2025.¶
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 forward packets based only on the destination IP address without checking the source IP address. IP spoofing, or source IP address spoofing, occurs when packets are sent with forged source IP addresses, hiding the sender's identity or impersonating another host. Outbound IP spoofing happens when a network allows packets with source addresses that do not match its assigned addresses to be sent outside the network. Malicious users often use IP spoofing to carry out attacks like reflective DDoS or DNS cache poisoning. To prevent this, networks should deploy outbound source address validation (OSAV) to block spoofed packets.¶
While deploying OSAV can effectively stop spoofed traffic, network operators are often reluctant to implement it due to concerns about validation accuracy, operational overhead, and the risk of accidentally dropping legitimate traffic [inter-domain-ps]. Moreover, OSAV primarily benefits other networks rather than the deployer, offering little direct incentive. However, widespread OSAV deployment would benefit the entire Internet, and operators are encouraged to adopt it to enhance collective security.¶
Measuring networks that permit IP spoofing is essential for understanding Internet threats and improving security. To measure if a network can send spoofed packets, one can try to send spoofed packets to remote servers and observe whether they are received. Figure 1 illustrates the fundamental concepts of outbound IP spoofing capability measurements: packets spoofed with a source address in AS1 are sent from the tested network AS2. If a host in AS1 receives these spoofed packets, it indicates that AS2 permits outbound spoofing.¶
Spoofed Packets
+-------+ with Source Addresses not in AS2 +-------+
# AS1 #<-----------------------------------# AS2 |
+-------+ +-------+
AS2 sends spoofed packests with source addresses not in AS2.
If AS2 allows outbound spoofing, the spoofed packets will be
received by AS1. Otherwise, they will be dropped by AS2.
If a volunteer in a network can deploy software that actively sends spoofed packets to a remote server, the network's outbound IP spoofing capability can be easily measured, which is how CAIDA's Spoofer tool operates [spoofer]. However, this volunteer-based approach does not scale well because it is difficult to obtain cooperation from a large number of networks. Hence, it is essential to develop methods for remotely measuring outbound IP spoofing without relying on active participation from volunteers in the tested networks. This document describes a method for remotely measuring the deployment status of OSAV, including whether OSAV is present or absent, as well as evaluating the filtering depth and filtering granularity.¶
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 mechanism that discards spoofed packets sent from a network to the outside of it.¶
A SAV mechanism is deployed in the network.¶
No SAV mechanism is deployed in the network.¶
The position where a spoofed packet is discarded when going out of the network.¶
The range of IP addresses that can be spoofed as. For example, if the filtering granularity is /8, addresses within the same /8 prefix as the original IP address will not be discarded.¶
To remotely measure OSAV deployment, we use destination network address translation (DNAT) to trigger remote hosts into sending spoofed packets. When a packet matches DNAT rules, the DNAT device changes the packet's destination to a preset address, while leaving the source address unchanged. This results in a spoofed packet because the source address does not belong to the network. As shown in Figure 2, the scanner sends a packet with source address IP1 to a network device with DNAT configured (IP2). The DNAT device modifies the destination to IP3 but keeps the source address as IP1, creating a spoofed packet. By observing the behavior of these elicited spoofed packets, we can measure OSAV deployment in AS2.¶
+---------------------+ +--------------------+
| +-------------+ | | +------------+ |
| | Scanner IP1 #---|------------------|--># DNAT IP2 | |
| +-------------+ | From: IP1 | +------#-----+ |
| | To: IP2 | | |
| AS1 | | AS2 | |
+---------------------+ +--------------------+
| From: IP1
+----------------------+ | To: IP3
| +--------------+ | | /\
| | Receiver IP3 #<--|--------+ ||
| +--------------+ | ||
| | ||
| AS3 | Detect elicited
+----------------------+ spoofed packets
The scanner sends a packet sourced with IP1 to the DNAT device (IP2).
The packet will elicit a spoofed packet sourced with IP1 and destined
to IP3.
By analyzing the information of elicited spoofed packets, we can infer the deployment status of OSAV: presence/absence of OSAV, filtering depth, and filtering granularity.¶
Intuitively, if the elicited spoofed packets reach the receiver IP3, we can infer that OSAV is not deployed in AS2, i.e., absence of OSAV. In contrast, if the elicited spoofed packets do not reach the receiver IP3, we can infer that OSAV is deployed in AS2, i.e., presence of OSAV. However, we cannot determine whether an IP address is used by a DNAT device, i.e., whether the packet sent from IP1 to IP2 will elicit a spoofed packet. Therefore, if the receiver IP3 does not receive a packet, it could either be because no spoofed packet was generated or because OSAV discarded the spoofed packet.¶
To confirm the generation of a spoofed packet, we leverage the ICMP time exceeded message, which quotes the first 28 bytes of the original packet that triggers time exceeded message. Therefore, we can learn the source IP address and destination IP address of the original packet from the quotation. If the destination IP address has been changed to IP3 while the source IP address remains IP1, we can confirm that a spoofed packet was generated.¶
If the spoofed pakcet reaches the receiver IP3, it is expected that the receiver IP3 will respond to the scanner IP1. However, if the receiver IP3 does not give a response, we can still infer the deployment of OSAV by analyzing the path of the spoofed packet. If OSAV is absent, the spoofed packet will travel beyond AS2. Otherwise, it will be blocked and never leave AS2.¶
To measure filtering depth, we first obtain the path of the spoofed packet, and then take the last responsive hop as the position where filtering happens. Since DNAT devices do not reset the TTL field in packets they receive, we increment the initial TTL value in original packets, similar to how traceroute works. Therefore, by collecting the source IP addresses from the ICMP time exceeded messages, we can trace the path of the spoofed packet.¶
Note that some hops may not respond when TTL expires, leading to a conservative estimate of the filtering depth. In such cases, the actual distance the spoofed packet travels could be farther than the inferred distance.¶
To measure filtering granularity, spoofed packets with various source IP addresses need to be sent from AS2. To this end, the scanner needs to send multiple original packets, using not only IP1 but also other addresses adjacent to IP2 as the source addresses.¶
When other adjacent addresses are used, the scanner will not receive a response, as the source IP seen by the receiver is not IP1. To detect whether these spoofed packets reach the receiver, we use specific protocols. For example, if the receiver is a DNS resolver, and the spoofed packet is a DNS query, the resolver will forward the query to the authoritative DNS server. By querying a domain under our control, we can determine if the spoofed packet reached the receiver. Additionally, methods used for inbound SAV measurement, such as increases in IP-ID, ICMP fragmentation, or ICMP rate limiting, can help confirm whether the spoofed packets arrived.¶
This document has no IANA requirements.¶