Methods for Remotely Measuring IP Spoofing Capability
draft-wang-bmwg-measure-meth-ip-spoofing-00
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Shuai Wang , Dan Li , Ruifeng Li , Qian Cao | ||
| Last updated | 2024-04-10 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wang-bmwg-measure-meth-ip-spoofing-00
Internet Engineering Task Force S. Wang
Internet-Draft Zhongguancun Laboratory
Intended status: Standards Track D. Li
Expires: 13 October 2024 Tsinghua University
R. Li
Q. Cao
Zhongguancun Laboratory
11 April 2024
Methods for Remotely Measuring IP Spoofing Capability
draft-wang-bmwg-measure-meth-ip-spoofing-00
Abstract
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.
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 13 October 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wang, et al. Expires 13 October 2024 [Page 1]
Internet-Draft Remote Measurement of IP Spoofing April 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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Outbound Spoofing Capability Measurement Method . . . . . . . 5
4. Inbound Spoofing Capability Measurement Method . . . . . . . 9
4.1. Measurement Method Leveraging DNS Resolvers . . . . . . . 9
4.2. Measurement Method Based on ICMPv6 Rate Limiting . . . . 11
5. Measurement Results . . . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. 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.
Wang, et al. Expires 13 October 2024 [Page 2]
Internet-Draft Remote Measurement of IP Spoofing April 2024
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.
Figure 1: An example for illustrating the basic idea of outbound
spoofing capability measurement.
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.
Figure 2: An example for illustrating the basic idea of inbound
spoofing capability measurement.
Wang, et al. Expires 13 October 2024 [Page 3]
Internet-Draft Remote Measurement of IP Spoofing April 2024
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.
1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. 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.
Wang, et al. Expires 13 October 2024 [Page 4]
Internet-Draft Remote Measurement of IP Spoofing April 2024
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.
3. 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
[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.
Wang, et al. Expires 13 October 2024 [Page 5]
Internet-Draft Remote Measurement of IP Spoofing April 2024
+---------------------+ +--------------------+
| +-------------+ | | +------------+ |
| | 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.
Figure 3: The example of how an address rewriter generates
spoofed packets.
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.
Wang, et al. Expires 13 October 2024 [Page 6]
Internet-Draft Remote Measurement of IP Spoofing April 2024
+---------------------+ +--------------------+
| +-------------+ | | +------------+ |
| | | | | | 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.
Figure 4: The example of how an alias target responds.
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.
Wang, et al. Expires 13 October 2024 [Page 7]
Internet-Draft Remote Measurement of IP Spoofing April 2024
+---------------------+ +--------------------+
| +-------------+ | | +------------+ |
| | 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.
Figure 5: The example of how to identify a network that does not
block spoofed packets.
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.
Wang, et al. Expires 13 October 2024 [Page 8]
Internet-Draft Remote Measurement of IP Spoofing April 2024
+---------------------+ +---------------------+
| +-------------+ | | +------------+ |
| | 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.
Figure 6: The example of how to check whether a network blocks
spoofed packets.
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.
4. 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 [dns-resolver] and Customer Premises
Equipment (CPE) devices [ICMPv6] can be leveraged for the
observation.
4.1. Measurement Method Leveraging DNS Resolvers
Wang, et al. Expires 13 October 2024 [Page 9]
Internet-Draft Remote Measurement of IP Spoofing April 2024
+-----------------+ +------------------------------------+
| AS1 | | AS2 |
| | | +--------------+ +-----------+ |
| +-------------+ | DNS query | | DNS resolver | | Host | |
| | Scanner IP1 #-|---------------|-># IP2 #--># IP3 | |
| +-------------+ | From:IP3 | +------+-------+ +-----------+ |
| | To:IP2 | | |
+-----------------+ +------------------------------------+
|
V
+------#------------+
| Authoritative DNS |
| nameserver (ADNS) |
+-------------------+
Figure 7: The example of sending DNS query with forged source
address.
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.
Wang, et al. Expires 13 October 2024 [Page 10]
Internet-Draft Remote Measurement of IP Spoofing April 2024
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
Figure 8: Classification of results based on DNS resolvers.
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.
4.2. Measurement Method Based on ICMPv6 Rate Limiting
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
Wang, et al. Expires 13 October 2024 [Page 11]
Internet-Draft Remote Measurement of IP Spoofing April 2024
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.
Wang, et al. Expires 13 October 2024 [Page 12]
Internet-Draft Remote Measurement of IP Spoofing April 2024
+------------------+ +-----------------------------+
| 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 +---------+ |
Figure 9: Three round tests of ICMPv6-based measurement method.
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
Wang, et al. Expires 13 October 2024 [Page 13]
Internet-Draft Remote Measurement of IP Spoofing April 2024
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.
5. Measurement Results
+----------------------------------+-----------------+
| 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 |
+----------------------------------+-----------------+
Figure 10: Measurement results for a single month.
Wang, et al. Expires 13 October 2024 [Page 14]
Internet-Draft Remote Measurement of IP Spoofing April 2024
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.
6. IANA Considerations
This document has no IANA requirements.
7. References
7.1. Normative References
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/rfc/rfc4443>.
[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>.
[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>.
7.2. Informative References
[inter-domain-ps]
"Source Address Validation in Inter-domain Networks Gap
Analysis, Problem Statement, and Requirements", 2023,
<https://datatracker.ietf.org/doc/draft-ietf-savnet-inter-
domain-problem-statement/>.
[dns-proxy]
Marc Kuhrer, Thomas Hupperich, Christian Rossow, and
Thorsten Holz, Ruhr-University Bochum, "Exit from hell?
Reducing the impact of amplification DDoS attacks", 2014,
<https://www.usenix.org/system/files/conference/
usenixsecurity14/sec14-paper-kuhrer.pdf>.
Wang, et al. Expires 13 October 2024 [Page 15]
Internet-Draft Remote Measurement of IP Spoofing April 2024
[dns-resolver]
Yevheniya Nosyk, Maciej Korczynski, Qasim Lone, Marcin
Skwarek, Baptiste Jonglez, Andrzej Duda, "The Closed
Resolver Project: Measuring the Deployment of Inbound
Source Address Validation", 2023,
<https://ieeexplore.ieee.org/document/10082958>.
[ICMPv6] Long Pan, Jiahai Yang, Lin He, Zhiliang Wang, Leyao Nie,
Guanglei Song, Yaozhong Liu, "Your Router is My Prober:
Measuring IPv6 Networks via ICMP Rate Limiting Side
Channels", 2023, <https://www.ndss-symposium.org/wp-
content/uploads/2023/02/ndss2023_s49_paper.pdf>.
Authors' Addresses
Shuai Wang
Zhongguancun Laboratory
Beijing
China
Email: wangshuai@zgclab.edu.cn
Dan Li
Tsinghua University
Beijing
China
Email: tolidan@tsinghua.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 13 October 2024 [Page 16]