Internet Area Working Group K. Xu
Internet-Draft Tsinghua University & Zhongguancun Laboratory
Intended status: Informational X. Feng
Expires: 30 August 2025 Y. Yang
Tsinghua University
Q. Li
Tsinghua University & Zhongguancun Laboratory
26 February 2025
Enhancing ICMP Error Message Authentication Using Challenge-Confirm
Mechanism
draft-xu-intarea-challenge-icmpv4-00
Abstract
The Internet Control Message Protocol (ICMP) plays a crucial role in
network diagnostics and error reporting. However, it is a challenge
to verify the legitimacy of a received ICMP error message,
particularly when the ICMP error message is embedded with stateless
protocol data. As a result, adversaries can forge ICMP error
messages, leading to potential exploitation and off-path attacks.
This document proposes a novel method to enhance ICMP authentication
by introducing a challenge-confirm mechanism. This mechanism embeds
random numbers in the IP options field to strengthen the
authentication of ICMP error messages. By doing so, it mitigates the
risks associated with forged messages, improves the overall
robustness of the protocol, and enhances network security. The
proposed solution includes details on the challenge-confirm
mechanism, random number generation and management, and integration
with IP options. Additionally, it discusses security and deployment
considerations to ensure its practical implementation.
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."
Xu, et al. Expires 30 August 2025 [Page 1]
Internet-Draft challenge-icmpv4 February 2025
This Internet-Draft will expire on 30 August 2025.
Copyright Notice
Copyright (c) 2025 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Source-Based Blocking Ineffectiveness . . . . . . . . . . 4
3.2. Authentication Evasion based on Embedded Packet State . . 4
3.2.1. Stateful Embedded Packets (e.g., TCP) . . . . . . . . 4
3.2.2. Stateless Embedded Packets (e.g., UDP, ICMPv6) . . . 5
4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Challenge-Confirm Mechanism . . . . . . . . . . . . . . . 5
4.2. Protocol State Machine . . . . . . . . . . . . . . . . . 7
4.3. Random Number Generation and Management . . . . . . . . . 9
4.4. Integration with IP Options . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
The Internet Control Message Protocol (ICMP) [RFC792] is an integral
part of network operations, providing essential feedback on
transmission issues such as unreachable destinations or packet
fragmentation requirements. Despite its importance, ICMP is
susceptible to various attacks, particularly the forgery of error
messages by off-path attackers. Notably, off-path attackers can
forge ICMP error messages embedded with stateless protocol data,
making it difficult for receivers to verify their legitimacy. Unlike
Xu, et al. Expires 30 August 2025 [Page 2]
Internet-Draft challenge-icmpv4 February 2025
stateful protocols such as TCP, where embedded connection-related
details (e.g., sequence numbers) in the ICMP error messages can be
checked by the receiver against an ongoing connection [RFC5927],
stateless protocol data lacks inherent mechanisms for verification.
Consequently, the receiver may erroneously accept the forged message,
enabling off-path attackers to manipulate network behavior. For
example, in an MTU manipulation attack, forged ICMP Packet Too Big
messages with stateless protocols (e.g., UDP, ICMP Echo Reply) force
hosts to reduce their PMTU, degrading throughput and harming latency-
sensitive applications. This can also induce TCP segment
fragmentation [NDSS2022MTU] and enabling IP ID-based TCP session
hijacking [CCS2020IPID]. Moreover, forged ICMP Redirect messages
embedded with stateless protocol data can be used to trick victims
into modifying their routing, facilitating off-path traffic
interception, modification, and credential theft
[USENIXSECURITY2023ICMP], [SP2023MITM].
To enhance ICMP error message authentication, this document presents
a novel method by introducing a challenge-confirm mechanism. This
mechanism embeds random challenges within the IP options field.
Particularly, when a receiver gets an ICMP error message embedded
with a stateless protocol payload (like a UDP/ICMP payload) for the
first time, it ignores the message and sends a subsequent (UDP/ICMP)
packet (i.e., a challenge packet) on the established network session
to the destination, embedding a randomly generated number in the IP
options field. If the prior ignored ICMP error message was
legitimate, this new packet will trigger another ICMP error message
containing the randomly generated number, allowing the receiver to
verify authenticity and respond correctly. This challenge-confirm
mechanism strengthens ICMP security by effectively mitigating off-
path forged error messages, making it more resistant to forgery and
various attacks, thereby enhancing the overall robustness of the
network protocol. It requires minimal changes to the TCP/IP protocol
suite, involving only updates to the ICMP error message verification
code on end hosts while remaining backward compatible and without
modifying intermediate routing devices.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. TCP
terminology should be interpreted as described in [RFC9293].
Xu, et al. Expires 30 August 2025 [Page 3]
Internet-Draft challenge-icmpv4 February 2025
3. Problem Statement
Current ICMP specifications have limitations that enable off-path
attackers to forge ICMP error messages embedded with stateless
protocol data, compromising network security and reliability. The
key issues are as follows:
3.1. Source-Based Blocking Ineffectiveness
Certain ICMP error messages, like the "Fragmentation Needed"
messages, can originate from any intermediate router along the
packet's path. Given this wide range of possible sources, legitimate
messages can come from numerous locations. As a result, source-based
blocking is rendered ineffective because it becomes difficult to
distinguish between legitimate and forged messages based on the
source address alone.
3.2. Authentication Evasion based on Embedded Packet State
Although ICMP requires including as much of the original (offending)
packet as possible in error messages without exceeding the
appropriate MTU limits, the stateful or stateless nature of the
embedded packet protocol directly impacts the authentication
difficulty and security strength of ICMP error messages. According
to ICMP specifications [RFC792], [RFC1122], error messages should
include at least the first 28 octets of the original packet to aid in
identifying the affected process and verifying legitimacy.
3.2.1. Stateful Embedded Packets (e.g., TCP)
When off-path attackers embed stateful protocol packets, such as TCP
segments, in forged ICMP error messages, the receiver has some means
of verification. The TCP protocol uses sequence numbers,
acknowledgment numbers, and ports to establish and maintain a
connection state between communicating parties. This connection-
specific information is difficult for off-path attackers to
accurately guess. Receivers can check if the connection-related
details in the embedded TCP header match the TCP connection state
they maintain. For example, they can verify if the sequence number
in the TCP segment embedded in the ICMP error message aligns with the
expected sequence number for an ongoing TCP connection. This way,
they can make an informed judgment about the authenticity of the ICMP
error message.
Xu, et al. Expires 30 August 2025 [Page 4]
Internet-Draft challenge-icmpv4 February 2025
3.2.2. Stateless Embedded Packets (e.g., UDP, ICMPv6)
In contrast to stateful TCP packets, when off-path attackers embed
stateless protocol packets, like UDP or ICMP packets, in forged ICMP
error messages, receivers face significant challenges in
authenticating the messages. UDP and ICMP are stateless protocols by
design. The source end does not keep track of any session-state
information, and each message is independent. This means that the
UDP or ICMP headers embedded in ICMP error messages lack crucial
state information, such as sequence numbers, that could be used for
context-based verification. Beyond basic protocol-format checks,
receivers have few reliable ways to determine the authenticity of the
ICMP error message based on the embedded stateless packet header.
This lack of state-based verification severely weakens the
authentication of ICMP error messages, enabling attackers to easily
bypass authentication and use forged error messages for malicious
purposes.
These vulnerabilities enable off-path attackers to manipulate network
behavior, exploit protocol weaknesses, and potentially disrupt
communication without being detected or mitigated by existing
security measures.
4. Proposed Solution
4.1. Challenge-Confirm Mechanism
To counteract the vulnerabilities in ICMP error messages validation,
this document presents a Challenge-Confirm Mechanism aimed at
validating the authenticity of ICMP error messages.
The message flow of the challenge - confirm mechanism is depicted in
Figure 1:
Xu, et al. Expires 30 August 2025 [Page 5]
Internet-Draft challenge-icmpv4 February 2025
Host Sender
----- -------
1. Reception of ICMP Error Message <----- ICMP Error Message
(Stateless Embedded Payload)
2. IGNORING
3. ISSUING CHALLENGE PKT -----------> Reception of CHALLENGE PKT
(IP_Options=Random_X)
4. RECV NEW ICMP ERROR <----------------- ICMP Error Message
(IP_Options=Random_X)
5. Verification
(IP_Options=Random_X)
(Verification Success)
Figure 1: Challenge-Confirm Message Flow
The operation of this mechanism is as follows:
1. *Receiving an ICMP Error Message*: When a host receives an ICMP
error message containing a stateless protocol payload (like UDP
or ICMP), it cannot be certain of the message's authenticity due
to the issues previously mentioned. The receiving host, based on
the existing ICMP design, lacks the means to verify whether the
message is from legitimate senders or the message is forged by
off-path attackers.
2. *Ignoring the ICMP Error Message*: The host ignores and discard
the received ICMP error message.
3. *Issuing a Challenge*: To authenticate the received ICMP error
message, the receiving host first ignores the received ICMP
message and then sends a subsequent UDP or ICMP packet (i.e., a
challenge packet) on the established session to the original
sender. This packet embeds a randomly generated number within
the IP options field. The choice of the IP options field allows
for the seamless addition of authentication-related data without
modifying the fundamental structure of the ICMP message, ensuring
compatibility with the existing network setup. This random
number serves as a unique identifier for this particular
authentication attempt.
4. *Response to Challenge*: If the original ICMP error message was
legitimate, the sender will again respond by sending another new
ICMP error message. This response message will carry the same
random number within its IP options field. For instance, a
Xu, et al. Expires 30 August 2025 [Page 6]
Internet-Draft challenge-icmpv4 February 2025
legitimate router that generated the initial ICMP error message
in the normal course of packet-handling will, upon receiving the
challenge packet, extract the random number and incorporate it
into its response ICMP error message as a proof of authenticity.
While the off-path attackers will not be able to catch the
challenge packet and it is hard for them to respond with a new
ICMP error message with the right number.
5. *Verification*: The receiving host then checks for the presence
and correctness of the random number in the response. If the
random number in the response matches the one it initially sent,
the original ICMP error message is confirmed as authentic. This
verification step acts as a crucial defense against forged ICMP
error messages. If the numbers do not match or the random number
is absent, the receiving host can infer that the original message
may be forged. In such a case, it can take appropriate actions,
such as discarding the message, logging the event for security
analysis, or notifying the network administrator.
4.2. Protocol State Machine
To effectively manage the challenge-confirm process, hosts
implementing this specification need to maintain a state machine.
The state machine, as shown in Figure 2, defines the operational
states and state transitions for handling ICMP error messages and
conducting challenge - confirm exchanges.
Xu, et al. Expires 30 August 2025 [Page 7]
Internet-Draft challenge-icmpv4 February 2025
+-----------------+
| Idle State |
+-------+---------+
|
| Receive ICMP Error
| (stateless embedded payload)
|
+-----------------+
| ICMP Received |
+-----------------+
|
|Send Subsequent Packet
v
+-------+---------+
| Challenge Sent |
+-------+---------+
_____/ | \________________
/ | \
(Valid Response) (Invalid Response) (Timeout)
/ | \
v | v
+--------+-------+ +-----------+---------+
|Process & Accept| | Discard & Log |
+--------+-------+ +-----------+---------+
| | |
+------------+---------------------+
|
v
+-------+---------+
| Idle State |
+-----------------+
Figure 2: Protocol State Machine
In the Idle State, the host is in a standby mode, waiting for ICMP
error messages. Once it receives an ICMP error message with a
stateless embedded payload, it enters the ICMP Received tate and wait
for a subsequent packet. Once a subsequent packet with challenge is
sent, it enters the Challenge Sent state. If a valid response (with
the correct random number) is received within the predefined timeout
period, the host transitions to the Process & Accept state. Here, it
acknowledges the original ICMP error message as genuine and processes
it accordingly. If the response is invalid (either the random number
is incorrect or there are other discrepancies) or a timeout occurs,
the host moves to the Discard & Log state. In this state, it
discards the original ICMP error message, considering it potentially
forged, and logs the event. This log can be used later for security
audits and to identify potential attack patterns. After either
Xu, et al. Expires 30 August 2025 [Page 8]
Internet-Draft challenge-icmpv4 February 2025
accepting or discarding the message, the host returns to the Idle
State, prepared to handle new ICMP error messages. This state-
machine-based approach provides a structured and reliable way to
manage the authentication process for ICMP error messages.
4.3. Random Number Generation and Management
* *Generation*: The receiver generates a high-entropy random number
(minimum 128 bits) using a secure pseudorandom number generator
(PRNG) to ensure unpredictability and resistance to guessing
attacks.
* *Management*: Each challenge utilizes a unique random number to
prevent replay attacks. The receiver maintains a cache of pending
challenges, each associated with an expiration timer to manage
resources effectively and avoid indefinite waiting periods.
4.4. Integration with IP Options
To support the Challenge-Confirm mechanism, this document defines a
new Challenge-Confirm Option. The challenge packet for a received
ICMP error message containing a stateless protocol payload includes
the following option (as shown in Figure 3) in the IP header.
Similarly, the ICMP error message triggered in response to this
challenge packet should also include the same option in the header of
the embedded challenge packet (as shown in Figure 4).
Xu, et al. Expires 30 August 2025 [Page 9]
Internet-Draft challenge-icmpv4 February 2025
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Challenge Nonce (128 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Stateless Protocol Data (UDP/ICMP packet) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The Challenge Packet Header with Random Number in IP
Options
The fields in Challenge-Confirm Option are defined as follows:
* *Option Type*: 8-bit identifier for the challenge-confirm option.
The final value requires IANA assignment.
* *Opt Data Len*: 8-bit unsigned integer specifying the length of
the option data field in bytes.
* *Reserved*: 16-bit field reserved for future use. MUST be set to
zero on transmission and ignored on reception.
* *Challenge Nonce*: 128-bit random number generated according to
[RFC4086] requirements.
Xu, et al. Expires 30 August 2025 [Page 10]
Internet-Draft challenge-icmpv4 February 2025
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | IHL | Type of Service | Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification | Flags | Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Challenge Nonce (128 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stateless Protocol Data (UDP/ICMP packet) |
| (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: New ICMP Error Responding to the Challenge Packet
5. Security Considerations
The proposed enhancements aim to bolster ICMP security by addressing
specific vulnerabilities related to message authentication. Key
security aspects include:
* *Authentication Strength*: Utilizing high-entropy random numbers
ensures that challenges are unpredictable and resistant to
forgery, effectively preventing unauthorized ICMP error message
spoofing.
* *Replay Attack Mitigation*: Assigning unique random numbers to
each challenge and implementing expiration timers mitigates the
risk of replay attacks, where attackers attempt to reuse valid
challenges to authenticate malicious messages.
Xu, et al. Expires 30 August 2025 [Page 11]
Internet-Draft challenge-icmpv4 February 2025
* *Denial of Service (DoS) Prevention*: To prevent potential DoS
attacks, where adversaries flood a host with fake challenges, rate
limiting and challenge frequency controls are implemented. These
measures ensure that the system can handle legitimate challenges
without being overwhelmed by malicious traffic.
* *Backward Compatibility*: The proposed mechanism maintains
backward compatibility by requiring updates solely to the ICMP
error message verification on end hosts. Intermediate routing
devices remain unaffected, ensuring seamless integration with
existing network infrastructure.
6. IANA Considerations
The Challenge-Confirm Option Type should be assigned in IANA's "IPv4
Option Type field" registry [RFC2780].
This draft requests the following IP Option Type assignments from the
IP Option Numbers sub-registry of Internet Protocol (IP) Parameters
(https://www.iana.org/assignments/ip-parameters/ip-parameters).
+======+=======+========+=======+======+============+
| Copy | Class | Number | Value | Name | Reference |
+======+=======+========+=======+======+============+
| TBD | TBD | TBD | TBD | TBD | This draft |
+------+-------+--------+-------+------+------------+
Table 1
7. References
7.1. Normative References
[CCS2020IPID]
Feng, X., Fu, C., Li, Q., Sun, K., and K. Xu, "Off-path
TCP exploits of the mixed IPID assignment", ACM Conference
on Computer and Communications Security (CCS) , 2020.
[NDSS2022MTU]
Feng, X., Li, Q., Sun, K., Xu, K., Liu, B., Zheng, X.,
Yang, Q., Duan, H., and Z. Qian, "PMTUD is not Panacea:
Revisiting IP Fragmentation Attacks against TCP", Network
and Distributed System Security Symposium (NDSS) , 2022.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/rfc/rfc1122>.
Xu, et al. Expires 30 August 2025 [Page 12]
Internet-Draft challenge-icmpv4 February 2025
[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>.
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers",
BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000,
<https://www.rfc-editor.org/rfc/rfc2780>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/rfc/rfc4086>.
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/rfc/rfc792>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/rfc/rfc9293>.
[SP2023MITM]
Feng, X., Li, Q., Sun, K., Yang, Y., and K. Xu, "Man-in-
the-middle attacks without rogue AP: When WPAs meet ICMP
redirects", IEEE Symposium on Security and Privacy (SP) ,
2023.
[USENIXSECURITY2023ICMP]
Feng, X., Li, Q., Sun, K., Qian, Z., Fu, C., Zhao, G.,
Kuang, X., and K. Xu, "Off-Path Network Traffic
Manipulation via Revitalized ICMP Redirect Attacks",
USENIX Security Symposium (Security) , 2023.
7.2. Informative References
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927,
DOI 10.17487/RFC5927, July 2010,
<https://www.rfc-editor.org/rfc/rfc5927>.
Acknowledgments
The authors would like to thank the IETF community, particularly
members of the INT-AREA working groups, for their valuable feedback
and insights during the development of this proposal.
Xu, et al. Expires 30 August 2025 [Page 13]
Internet-Draft challenge-icmpv4 February 2025
Authors' Addresses
Ke Xu
Tsinghua University & Zhongguancun Laboratory
Beijing
China
Email: xuke@tsinghua.edu.cn
Xuewei Feng
Tsinghua University
Beijing
China
Email: fengxw06@126.com
Yuxiang Yang
Tsinghua University
Beijing
China
Email: yangyx22@mails.tsinghua.edu.cn
Qi Li
Tsinghua University & Zhongguancun Laboratory
Beijing
China
Email: qli01@tsinghua.edu.cn
Xu, et al. Expires 30 August 2025 [Page 14]