]> Tsinghua University & Zhongguancun Laboratory

Beijing China xuke@tsinghua.edu.cn

Tsinghua University

Beijing China fengxw06@126.com

Southeast University

Nanjing China wangao@seu.edu.cn

AREA Internet Area Working Group off-path attack redirect fragmentation 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.

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 , Neighbor Discovery , and reporting errors encountered during packet processing . 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 , 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 , disrupting network throughput and latency-sensitive applications like video conferencing. This manipulation also simplifies off-path TCP hijacking . 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 . 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.

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 . TCP terminology should be interpreted as described in .

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:

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.

Authentication Evasion based on Embedded Packet State Although 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.

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 .

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 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.

Proposed Solution

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: 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) ]]> 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.
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.

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. 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.

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.

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). 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 requirements.

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.

IANA Considerations The Challenge-Confirm Option Type should be assigned in IANA's "Destination Options and Hop-by-Hop Options" registry . 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

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This memo provides guidance for the IANA to use in assigning parameters for fields in the IPv4, IPv6, ICMP, UDP and TCP protocol headers. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK] This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK] This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. This document describes Path MTU Discovery (PMTUD) for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4. It obsoletes RFC 1981. This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168. Informative References This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP). Additionally, this document describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues. This document is not an Internet Standards Track specification; it is published for informational purposes.

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.