Internet Area Working Group K. Xu
Internet-Draft Tsinghua University & Zhongguancun Laboratory
Intended status: Informational X. Feng
Expires: 30 August 2025 Tsinghua University
A. Wang
Southeast University
26 February 2025
Enhancing ICMPv6 Error Message Authentication Using Challenge-Confirm
Mechanism
draft-xu-intarea-challenge-icmpv6-00
Abstract
As well as the Internet Control Message Protocol for IPv4 (ICMPv4),
the Internet Control Message Protocol for IPv6 (ICMPv6) is
significant for network diagnostics and error reporting. However,
like ICMPv4, ICMPv6 is also vulnerable to off-path forgery, making it
difficult for the receiver to verify the legitimacy of a received
ICMPv6 error message, particularly when the message contains
stateless protocol data (e.g., the message includes a UDP/ICMPv6
packet). Consequently, adversaries on the Internet can forge ICMPv6
error messages carrying stateless protocol data, leading the receiver
to erroneously accept the forged message and respond to it. This
document proposes enhancement to ICMPv6 by introducing a challenge-
confirm mechanism that leverages random numbers embedded in the IPv6
Extension Headers. The enhancement aims to strengthen the
authentication of ICMPv6 error messages, thereby mitigating the risks
associated with forged messages and improving the overall robustness
of the protocol.
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 30 August 2025.
Xu, et al. Expires 30 August 2025 [Page 1]
Internet-Draft challenge-icmpv6 February 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) . . . 4
4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Challenge-Confirm Mechanism . . . . . . . . . . . . . . . 5
4.2. State Machine . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Random Number Generation and Management . . . . . . . . . 8
4.4. Challenge-Confirm Option . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
The Internet Control Message Protocol for IPv6 (ICMPv6) serves as the
cornerstone of operational signaling in IPv6 networks. It performs
critical functions such as Path MTU Discovery [RFC8201], Neighbor
Discovery [RFC4861], and reporting errors encountered during packet
processing [RFC4443]. However, the legitimate verification of ICMPv6
error messages is inherently vulnerable by design. To enable senders
to correlate error reports with the original packets for effective
network diagnostics, ICMPv6 error messages, as specified in
[RFC4443], MUST include the header information and a portion of the
payload of the original message that triggered the error. When the
Xu, et al. Expires 30 August 2025 [Page 2]
Internet-Draft challenge-icmpv6 February 2025
original message originates from stateless protocols like UDP or
ICMPv6, the embedded original message header lacks contextual
information (e.g., sequence numbers, acknowledgement numbers, and
ports in stateful protocols like TCP). This makes it difficult for
the receiver to effectively verify the legitimacy of the error
messages. Consequently, attackers can forge ICMPv6 error messages
embedded with stateless protocol payloads to bypass the legitimate
verification of the receiver, tricking the receiver into erroneously
accepting and responding to the message, which can lead to malicious
activities.
For example, off-path attackers can forge ICMPv6 "Packet Too Big"
messages, embedding stateless protocols like UDP or ICMP Echo Reply,
to lower hosts' Path MTU to the IPv6 minimum of 1280 bytes [RFC8200],
disrupting network throughput and latency-sensitive applications like
video conferencing. This manipulation also simplifies off-path TCP
hijacking [Feng2021]. Additionally, attackers can exploit forged
ICMPv6 Redirect messages to tamper with a victim's gateway, enabling
Man-in-the-Middle (MitM) attacks. Even with WPA/WPA2/WPA3 security,
attackers can impersonate legitimate APs, bypass encryption, and
hijack traffic [Feng2023]. These diverse attack vectors starkly
underscore the critical and urgent necessity for robust
authentication mechanisms in ICMPv6 for error message processing.
To address the vulnerability in ICMPv6 error message legitimacy
verification, this document proposes a Challenge-Confirm mechanism.
Specifically, when an IPv6 host receives an ICMPv6 error message
carrying a stateless protocol payload (e.g., embedded with a UDP or
ICMPv6 packet), the host first ignores the error message and issues a
challenge by sending a subsequent UDP or ICMPv6 packet (the challenge
packet) on the established session. Specifically, the challenge
packet contains a randomly generated number embedded in an IPv6
Option. If the previously ignored ICMPv6 error message was
legitimate, the sender will respond with another ICMPv6 error message
to the challenge packet, reflecting the random number. The IPv6 host
then verifies the response, and a valid match on the random number
confirms the message's authenticity. This mechanism ensures only
legitimate sources can correctly respond, preventing off-path
attackers from forging ICMPv6 error messages, while remaining
backward compatible with residual 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-icmpv6 February 2025
3. Problem Statement
Current ICMPv6 specifications have inherent limitations that allow
off-path attackers to forge ICMPv6 error messages, undermining
network security and reliability. The primary issues are:
3.1. Source-Based Blocking Ineffectiveness
Certain ICMPv6 error messages, such as Packet Too Big messages, can
originate from any intermediate router along the packet's path. This
ubiquity makes source-based blocking ineffective, as legitimate
messages can come from multiple sources.
3.2. Authentication Evasion based on Embedded Packet State
Although [RFC4443] stipulates that "Every ICMPv6 error message (type
< 128) MUST include as much of the IPv6 offending (invoking) packet
(the packet that caused the error) as possible without making the
error message packet exceed the minimum IPv6 MTU", the inherent
characteristics of the embedded packet protocol directly influence
the difficulty of authenticating ICMPv6 error messages and their
overall security strength.
3.2.1. Stateful Embedded Packets (e.g., TCP)
When attackers embed stateful protocol packets, such as TCP segments,
in forged ICMPv6 error messages, receivers can theoretically utilize
the inherent state information of the TCP protocol for a certain
degree of verification. The TCP protocol establishes and maintains
state between communicating parties through sequence numbers,
acknowledgment numbers, and ports. These connection-based TCP state
information are difficult for attackers to accurately guess.
Receivers can attempt to verify whether these connection-specific
secret information in the embedded TCP header matches their
maintained TCP connection state, thereby judging the authenticity of
the ICMPv6 error message [RFC5927].
3.2.2. Stateless Embedded Packets (e.g., UDP, ICMPv6)
In contrast to stateful TCP, when attackers embed stateless protocol
packets, such as UDP or ICMPv6 messages, in forged ICMPv6 error
messages, receivers lose the ability to perform effective state
verification. UDP and ICMPv6 protocols are inherently designed as
stateless protocols, where the source does not maintain any session
state information. The UDP or ICMPv6 messages embedded in ICMPv6
error messages contain almost no state information that can be used
for context verification. In addition to performing some basic
protocol format checks, receivers have virtually no way to determine
Xu, et al. Expires 30 August 2025 [Page 4]
Internet-Draft challenge-icmpv6 February 2025
the authenticity of ICMPv6 error messages based on the embedded
stateless packet header. This lack of state verification greatly
reduces the authentication strength of ICMPv6 error messages, making
it easier for attackers to implement authentication evasion and use
forged error messages for malicious attacks.
4. Proposed Solution
4.1. Challenge-Confirm Mechanism
To mitigate the vulnerabilities described in Section 2, this document
proposes a Challenge-Confirm mechanism to verify the authenticity of
ICMPv6 error messages. The message flow of the Challenge-Confirm
mechanism is depicted in Figure 1:
IPv6 Host Sender
----- -------
1. Reception of ICMPv6 Error Message <----- ICMPv6 Error Message
(Stateless Embedded Payload)
2. IGNORING
3. ISSUING CHALLENGE PKT -----------> Reception of CHALLENGE PKT
(IPv6_Options=Random_X)
4. RECV NEW ICMPv6 ERROR <----------------- ICMPv6 Error Message
(IPv6_Options=Random_X)
5. Verification
(IPv6_Options=Random_X)
(Verification Success)
Figure 1: Challenge-Confirm Message Flow
The details are described below:
1. *Reception of ICMPv6 Error Message*: When a IPv6 host receives an
ICMPv6 error message embedded with a stateless protocol payload
(e.g., UDP or ICMPv6), it cannot reliably verify the message's
authenticity due to the aforementioned limitations.
2. *Ignoring the ICMPv6 Error Message*: The IPv6 host ignores and
discard the received ICMPv6 error message.
Xu, et al. Expires 30 August 2025 [Page 5]
Internet-Draft challenge-icmpv6 February 2025
3. *Issuing a Challenge*: To authenticate the received ICMPv6 error
message, the receiver sends a subsequent UDP or ICMPv6 packet on
the established session (i.e., a challenge packet).
Particularly, this packet includes a randomly generated number
embedded within an IPv6 Option.
4. *Response to Challenge*: If the previously ignored ICMPv6 error
message was legitimate, the sender will respond to the challenge
packet by sending another ICMPv6 error message containing the
embedded random number within an IPv6 Option.
5. *Verification*: The receiver verifies the presence and
correctness of the random number in the response. A valid match
confirms the authenticity of the original ICMPv6 error message.
This mechanism ensures that only legitimate sources can respond
correctly to the challenge, thereby preventing off-path attackers
from successfully forging ICMPv6 error messages.
4.2. State Machine
To manage the Challenge-Confirm process, hosts implementing this
specification should maintain a state machine. This state machine,
as depicted in Figure 2, defines the operational states and state
transitions for handling ICMPv6 error messages and conducting
Challenge-Confirm exchanges.
Xu, et al. Expires 30 August 2025 [Page 6]
Internet-Draft challenge-icmpv6 February 2025
+-----------------+
| Idle State |
+-------+---------+
|
| Receive ICMPv6 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 IPv6 host is in a standby mode, waiting for
ICMPv6 error messages. Once it receives an ICMPv6 error message with
a stateless embedded payload, it enters the ICMP Received state 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 ICMPv6 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 ICMPv6 error message,
considering it potentially forged, and logs the event. This log can
be used later for security audits and to identify potential attack
Xu, et al. Expires 30 August 2025 [Page 7]
Internet-Draft challenge-icmpv6 February 2025
patterns. After either accepting or discarding the message, the host
returns to the Idle State, prepared to handle new ICMPv6 error
messages. This state-machine-based approach provides a structured
and reliable way to manage the authentication process for ICMPv6
error messages.
4.3. Random Number Generation and Management
* *Generation*: The IPv6 host 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 IPv6 host maintains a cache of
pending challenges, each associated with an expiration timer to
manage resources effectively and avoid indefinite waiting periods.
4.4. Challenge-Confirm Option
To support the Challenge-Confirm mechanism, this document defines a
new Challenge-Confirm Option. The challenge packet for a received
ICMPv6 error message containing a stateless protocol payload includes
the following option (as shown in Figure 3) in the IPv6 header.
Similarly, the ICMPv6 error message triggered in response to this
challenge packet should also include the same option in the header of
the embedded IPv6 challenge packet (as shown in Figure 4).
Xu, et al. Expires 30 August 2025 [Page 8]
Internet-Draft challenge-icmpv6 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| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Challenge Nonce (128 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Stateless Protocol Data (UDP/ICMP packet) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The IPv6 Challenge Packet with Challenge-Confirm Option
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.
Xu, et al. Expires 30 August 2025 [Page 9]
Internet-Draft challenge-icmpv6 February 2025
* *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-icmpv6 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU / Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Challenge Nonce (128 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Stateless Protocol Data (UDP/ICMP packet) |
| (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: New ICMPv6 Error Responding to the Challenge Packet
Xu, et al. Expires 30 August 2025 [Page 11]
Internet-Draft challenge-icmpv6 February 2025
5. Security Considerations
The proposed enhancements aim to bolster ICMPv6 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 ICMPv6 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.
* *Denial of Service (DoS) Prevention*: To prevent potential DoS
attacks, where adversaries flood a host with fake challenges, rate
limiting and challenge frequency controls should be implemented.
* *Backward Compatibility*: The proposed mechanism maintains
backward compatibility by requiring updates solely to the ICMPv6
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
"Destination Options and Hop-by-Hop Options" registry [RFC2780].
This draft requests the following IPv6 Option Type assignments from
the Destination Options and Hop-by-Hop Options sub-registry of
Internet Protocol Version 6 (IPv6) Parameters
(https://www.iana.org/assignments/ipv6-parameters/).
+===========+==============+=============+============+
| Hex Value | Binary Value | Description | Reference |
+===========+==============+=============+============+
| | act chg rest | | |
+-----------+--------------+-------------+------------+
| TBD | 00 0 - | | This draft |
+-----------+--------------+-------------+------------+
Table 1
7. References
Xu, et al. Expires 30 August 2025 [Page 12]
Internet-Draft challenge-icmpv6 February 2025
7.1. Normative References
[Feng2021] Feng, X., Li, Q., Sun, K., Fu, C., and K. Xu, "Off-path
TCP hijacking attacks via the side channel of downgraded
IPID", IEEE/ACM transactions on networking , 2021.
[Feng2023] 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.
[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>.
[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>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/rfc/rfc4861>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/rfc/rfc8200>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/rfc/rfc8201>.
Xu, et al. Expires 30 August 2025 [Page 13]
Internet-Draft challenge-icmpv6 February 2025
[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>.
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.
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
Ao Wang
Southeast University
Nanjing
China
Email: wangao@seu.edu.cn
Xu, et al. Expires 30 August 2025 [Page 14]