]> Tsinghua University & Zhongguancun Laboratory

Beijing China xuke@tsinghua.edu.cn

Tsinghua University

Beijing China fengxw06@126.com

Tsinghua University

Beijing China yangyx22@mails.tsinghua.edu.cn

Tsinghua University & Zhongguancun Laboratory

Beijing China qli01@tsinghua.edu.cn

AREA Internet Area Working Group off-path attack redirect fragmentation The Internet Control Message Protocol (ICMP) is essential for network diagnostics but is vulnerable to off-path spoofing attacks, especially when error messages relate to stateless transport protocols like UDP. An attacker can forge these messages to degrade performance or enable Man-in-the-Middle attacks. This document proposes a robust, stateless challenge-response mechanism to authenticate ICMP error messages. Traditional stateful challenge mechanisms are vulnerable to state-exhaustion Denial-of-Service (DoS) attacks. To avoid this, the proposed solution is inspired by TCP SYN-Cookies, eliminating the need to store per-challenge state by using cryptographic computation. It limits state management to minimal flags on existing sockets or a bounded probabilistic data structure. This approach effectively authenticates ICMP error messages while inherently resisting both off-path spoofing and state-exhaustion DoS attacks, thus improving the robustness of ICMP.

Introduction The Internet Control Message Protocol (ICMP) is an integral part of network operations, providing essential feedback on transmission issues. However, the legitimate verification of ICMP error messages is inherently vulnerable by design. To enable senders to correlate error reports with the original packets for effective network diagnostics, ICMP 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 ICMP, 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 ICMP 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 ICMP "Fragmentation Needed" messages to degrade throughput and harm latency-sensitive applications. This can also induce TCP segment fragmentation and enable IP ID-based TCP session hijacking . 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 , . These diverse attack vectors starkly underscore the critical and urgent necessity for robust authentication mechanisms in ICMP for error message processing. This document proposes a stateless challenge-confirm mechanism that authenticates these ICMP error messages. The mechanism is designed to prove that the source of an error is on the path of the associated data flow, thwarting off-path attackers without introducing new Denial-of-Service vulnerabilities.

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 ICMP specifications have inherent limitations that allow off-path attackers to forge ICMP error messages, undermining network security and reliability. The primary issues are:

Source-Based Blocking Ineffectiveness Certain ICMP error messages, such as "Fragmentation Needed" 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 and stipulate that error messages should include as much of the original (offending) packet as possible, the inherent characteristics of the embedded packet protocol directly influence the difficulty of authenticating ICMP 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 ICMP 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 details in the embedded TCP header match their maintained TCP connection state, thereby judging the authenticity of the ICMP error message.

Stateless Embedded Packets (e.g., UDP, ICMP) In contrast to stateful TCP, when attackers embed stateless protocol packets, such as UDP or ICMP messages, in forged ICMP error messages, receivers lose the ability to perform effective state verification. UDP and ICMP protocols are inherently designed as stateless protocols. The UDP or ICMP messages embedded in ICMP 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 ICMP error messages based on the embedded stateless packet header. This lack of state verification greatly reduces the authentication strength of ICMP error messages, making it easier for attackers to implement authentication evasion and use forged error messages for malicious attacks.

Stateless Challenge-Confirm Mechanism A simple stateful challenge-response mechanism, where a host stores a nonce while waiting for a confirmation, would introduce a critical state-exhaustion Denial-of-Service (DoS) vulnerability. An attacker could flood a target with forged error messages, forcing it to allocate state for each one. To solve this, the mechanism proposed here is stateless and inspired by TCP SYN-Cookies , where state is not stored but is instead encoded cryptographically and later re-computed for validation.

Core Principle: Eliminating State with Cryptographic Computation Instead of generating and storing a random nonce, the host computes a deterministic nonce on demand. This nonce is a cryptographic hash of information that defines the flow, combined with a secret key known only to the host. Challenge Nonce = F(secret_key, src_IP, dest_IP, [other_flow_info])

• secret_key: A high-entropy secret value held by the host's operating system. This key MUST be rotated periodically (e.g., every few minutes) to limit the impact of any potential key compromise and to mitigate replay attacks.
• F: A keyed-hash function, such as HMAC-SHA256, truncated to the size of the nonce field.

With this approach, a nonce can be generated when needed (for an outgoing challenge) and verified later (on a returning confirmation) by simply re-computing it. There is no need to store it in a cache.

Challenge-Confirm Procedure The stateless process is as follows:

• Receive and Validate Error: Host A receives an ICMP error message. It first validates the embedded header's 4-tuple against its list of active sockets/connections. If no matching socket exists, the message is silently discarded. No state is created.
• Mark Flow for Challenge: If a matching socket is found, Host A does not create new state. Instead, it sets a simple flag on the existing socket control block, marking it as "requires challenge". The initial ICMP error is then discarded.
• Issue Computed Challenge: The next time the application sends a packet on this marked socket, the networking stack intercepts it. It computes the challenge nonce using the secret key and the packet's flow information. This nonce is placed in a Challenge-Confirm IP Option, and the packet is sent.
• Receive and Verify Confirmation: If a legitimate on-path node returns a new ICMP error, it will contain the challenge packet. Host A receives this new error, extracts the embedded nonce, and recomputes the expected nonce using the same secret key and flow information.
• Process or Discard: If the received nonce matches the re-computed one, the error is authentic, and Host A can act on it. If it does not match, the message is a forgery or is stale, and it is discarded.

This flow achieves the anti-spoofing goal without creating state for unverified messages, thus defeating potential DoS attacks. Figure 1 illustrates the complete interaction. | | X (Error, e.g., MTU exceeded) |<--[ 1. ICMP Error (Original) ]-----------| | | | [Internal Action on Host A:] | | - Validate 4-tuple -> OK | | - Mark socket for challenge | | - Discard original error msg | | (No per-challenge state is stored) | | | |--------[ 2. Next UDP Packet + ]--------->| | [ Challenge Option (Nonce N) ] | | (Nonce N computed on-the-fly) | | | | X (Same error condition) |<--[ 3. New ICMP Error (contains N) ]-----| | | | [Internal Action on Host A:] | | - Extract received Nonce N | | - Re-compute expected Nonce N' | | - IF (N == N') THEN: | | Process error (SUCCESS) | | ELSE: | | Discard message (FAILURE) | | | Figure 1: Challenge-Confirm Mechanism ]]>

Protocol-Specific State Management The mechanism for "marking a flow" is lightweight and transport-specific.

• UDP: Upon receiving a validatable ICMP error, the host sets a flag on the corresponding UDP socket's control block.
• TCP: While TCP has its own protections, this mechanism can supplement it. A flag can be set on the TCB.
• ICMP: For connectionless protocols like ICMP Echo, which lack a socket state, a probabilistic, fixed-size data structure like a Sketch or Bloom Filter SHOULD be used.
  • On Error Reception: The host hashes a flow identifier (e.g., source IP, destination IP, ICMP Identifier) and increments the corresponding counter(s) in the sketch.
  • On Packet Transmission: When sending a new ICMP packet, the host queries the sketch. If the query indicates this flow has likely received a recent error, it attaches the computed challenge. This probabilistic approach ensures that state remains bounded, preventing DoS attacks against ICMP-based applications.

Challenge-Confirm Option To support the Challenge-Confirm mechanism, this document defines a new Challenge-Confirm IP Option. The challenge packet for a received ICMP error message containing a stateless protocol payload includes this option in the IP header (as shown in Figure 2). Similarly, the ICMP error message triggered in response to this challenge packet should also include the same option in the header of the embedded IP challenge packet (as shown in Figure 3). The fields in the 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 number computed as described in Section 4.1.

Exception Handling and Edge Cases

Packet Loss The proposed mechanism is inherently resilient to packet loss due to its stateless design. It does not maintain timers or retransmission states for the challenge-confirm exchange itself. The requires challenge flag is cleared as soon as the challenge packet is transmitted, meaning the host does not enter a state of "waiting for a confirmation". Whether the outgoing challenge packet or the returning ICMP confirmation is lost in transit, the outcome is the same: the host that issued the challenge does not receive a confirmation and takes no special action. The exchange silently fails. Recovery is not driven by a timer, but by the persistence of the underlying network issue. If the condition that caused the initial ICMP error persists, a subsequent data packet from the application will likely trigger a new, initial ICMP error, naturally restarting the challenge process. This "fire-and-forget" approach avoids adding stateful complexity for the challenge itself.

Multi-Path Routing Scenarios The mechanism's performance, but not its security, can be affected in networks that employ per-packet load balancing across multiple paths. Consider a scenario where a flow's packets alternate between a "bad" path that triggers an ICMP error and a "good" path that does not. A recurring cycle could emerge: 1. A data packet is routed to the "bad" path, triggering an initial ICMP error and causing the host to set the requires challenge flag. 2. The next packet (now a challenge packet) is routed to the "good" path and reaches its destination successfully. No ICMP confirmation is returned. 3. The host, having sent its challenge, clears the flag. The next data packet is a normal packet, which is again routed to the "bad" path, restarting the cycle. This cycle does not compromise the security of the mechanism. The host never acts on an unvalidated ICMP error, so spoofing attacks remain ineffective. However, it creates a performance degradation. In this specific scenario, the effective throughput for the flow could be halved. This is a performance cost in certain network topologies, not a security vulnerability.

Security Considerations The proposed enhancements aim to bolster ICMP security by addressing specific vulnerabilities related to message authentication. Key security aspects include:

• Authentication Strength: The security of the authentication depends on the unguessability of the computed nonce, which is guaranteed by the use of a strong keyed-hash function and a secret key with sufficient entropy .
• Denial of Service (DoS) Resistance: This is the principal security advantage over stateful designs. The mechanism is resilient to state-exhaustion attacks because:
  1. It creates no state for ICMP errors that do not correspond to an existing, active transport-layer socket.
  2. For valid flows, the state added is minimal (a flag) or probabilistically bounded (a sketch), preventing uncontrolled resource consumption.
• Replay Attack Mitigation: The periodic rotation of the secret_key provides the primary defense against replay attacks. A captured nonce-confirmation pair will become invalid after the key is changed. The rotation interval presents a trade-off between security and the maximum legitimate round-trip time for a challenge-confirm exchange.
• Reflection and Amplification Attacks: The mechanism is designed to be immune to reflection and amplification attacks. An attacker cannot use this protocol to turn a victim into a traffic amplifier. The critical design choice preventing this is that the receipt of an initial, unverified ICMP error message does NOT trigger the immediate transmission of a new packet. Instead, the host's response is limited to two low-cost internal actions: silently discarding the incoming message and setting a lightweight flag on an existing socket's control block. The challenge packet itself is not a new, separately generated packet; it is the next application packet for that flow, modified on-the-fly to include the Challenge-Confirm option. Therefore, an attacker sending a flood of forged ICMP messages cannot compel the target to generate any network traffic beyond what its applications would have sent anyway. The victim does not become a reflector.
• Backward Compatibility: The mechanism is fully backward-compatible. Hosts not implementing this specification will ignore the IP Option as per standard IP header processing rules . Intermediate routers are unaffected. Only end hosts wishing to enhance their security need to implement the changes.

IANA Considerations The Challenge-Confirm Option Type should be assigned in IANA's "IP Option Numbers" registry . This draft requests the following IP Option Type assignments from the IP Option Numbers registry in the Internet Protocol (IP) Parameters registry group (https://www.iana.org/assignments/ip-parameters).

References Normative References This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK] 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 TCP SYN flooding attacks, which have been well-known to the community for several years. Various countermeasures against these attacks, and the trade-offs of each, are described. This document archives explanations of the attack and common defense techniques for the benefit of TCP implementers and administrators of TCP servers or networks, but does not make any standards-level recommendations. This memo provides information for the Internet community. 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

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.