SAVNET S. Wang
Internet-Draft Zhongguancun Laboratory
Intended status: Informational D. Li
Expires: 19 April 2025 Tsinghua University
L. Chen
R. Li
Q. Cao
Zhongguancun Laboratory
16 October 2024
Remote Measurement of Outbound Source Address Validation Deployment
draft-wang-savnet-remote-measurement-osav-00
Abstract
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.
Status of This Memo
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 Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wang, et al. Expires 19 April 2025 [Page 1]
Internet-Draft Remote Measurement of OSAV Deployment October 2024
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in this Document . . . . . . . . . . . . . . 3
2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
3. Basic Setup . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Criteria for Identification . . . . . . . . . . . . . . . . . 5
4.1. Presence/Absence of OSAV . . . . . . . . . . . . . . . . 5
4.2. Filtering Depth . . . . . . . . . . . . . . . . . . . . . 6
4.3. Filtering Granularity . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
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.
Wang, et al. Expires 19 April 2025 [Page 2]
Internet-Draft Remote Measurement of OSAV Deployment October 2024
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.
Figure 1: An example for illustrating the basic idea of outbound
spoofing capability measurement.
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.
2. Conventions Used in this Document
2.1. Key Words
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.
2.2. Definitions
Spoofed Packet:
Wang, et al. Expires 19 April 2025 [Page 3]
Internet-Draft Remote Measurement of OSAV Deployment October 2024
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.
Outbound Source Address Validation:
The mechanism that discards spoofed packets sent from a network to
the outside of it.
Prensence of SAV:
A SAV mechanism is deployed in the network.
Absence of SAV:
No SAV mechanism is deployed in the network.
Filtering Depth:
The position where a spoofed packet is discarded when going out of
the network.
Filtering Granularity:
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.
2.3. Abbreviations
OSAV: Outbound Source Address Validation
DNS: Domain Name System
AS: Autonomous System
DNAT: Destination Network Address Translation
3. Basic Setup
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
Wang, et al. Expires 19 April 2025 [Page 4]
Internet-Draft Remote Measurement of OSAV Deployment October 2024
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.
Figure 2: The setup of OSAV measurement
4. Criteria for Identification
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.
4.1. Presence/Absence of OSAV
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.
Wang, et al. Expires 19 April 2025 [Page 5]
Internet-Draft Remote Measurement of OSAV Deployment October 2024
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.
4.2. Filtering Depth
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.
4.3. Filtering Granularity
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.
Wang, et al. Expires 19 April 2025 [Page 6]
Internet-Draft Remote Measurement of OSAV Deployment October 2024
5. IANA Considerations
This document has no IANA requirements.
6. References
6.1. Normative References
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
6.2. Informative References
[spoofer] "Spoofer", 2024,
<https://www.caida.org/projects/spoofer/>.
[inter-domain-ps]
"Source Address Validation in Inter-domain Networks Gap
Analysis, Problem Statement, and Requirements", 2024,
<https://datatracker.ietf.org/doc/draft-ietf-savnet-inter-
domain-problem-statement/>.
Authors' Addresses
Shuai Wang
Zhongguancun Laboratory
Beijing
China
Email: wangshuai@zgclab.edu.cn
Dan Li
Tsinghua University
Beijing
China
Email: tolidan@tsinghua.edu.cn
Li Chen
Zhongguancun Laboratory
Beijing
China
Wang, et al. Expires 19 April 2025 [Page 7]
Internet-Draft Remote Measurement of OSAV Deployment October 2024
Email: lichen@zgclab.edu.cn
Ruifeng Li
Zhongguancun Laboratory
Beijing
China
Email: lirf@zgclab.edu.cn
Qian Cao
Zhongguancun Laboratory
Beijing
China
Email: caoqian@zgclab.edu.cn
Wang, et al. Expires 19 April 2025 [Page 8]