| Internet-Draft | challenge-icmpv6 | February 2025 |
| Xu, et al. | Expires 30 August 2025 | [Page] |
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.¶
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.¶
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.¶
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 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.¶
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].¶
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:¶
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.¶
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.¶
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].¶
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 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.¶
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:¶
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.¶
Ignoring the ICMPv6 Error Message: The IPv6 host ignores and discard the received ICMPv6 error message.¶
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.¶
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.¶
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.¶
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.¶
+-----------------+
| 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 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.¶
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.¶
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).¶
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.¶
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.¶
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¶
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.¶
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 |
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.¶