]> Tsinghua University & Zhongguancun Laboratory

xuke@tsinghua.edu.cn

Tsinghua University

fengxw06@126.com

Tsinghua University & Zhongguancun Laboratory

qli01@tsinghua.edu.cn

Tsinghua University

li-zx24@mails.tsinghua.edu.cn

Internet Area Internet Engineering Task Force cross-layer TCP/IP vulnerabilities ICMP security ICMP error messages are vital for network reliability, providing feedback on issues such as unreachable hosts or fragmentation requirements. They help devices adapt dynamically, support troubleshooting, and enable essential functions like Path MTU Discovery. However, off-path attackers on the Internet may forge ICMP error messages to bypass legitimate validation mechanisms, causing the victim's TCP/IP stack to misinterpret network conditions and exposing critical vulnerabilities. This document analyzes how such forged ICMP errors can be exploited by off-path attackers to induce cross-layer interactions within the victim's TCP/IP stack, leading to four classes of vulnerabilities: information leakage, desynchronization of shared variables, semantic gaps, and identity deception. These ICMP-based attacks allow off-path attackers to manipulate network traffic, disrupt communication flows, and compromise both infrastructure and user privacy, without being on the direct communication path. The document concludes with proposed countermeasures and recommendations for protocol evolution.

Introduction ICMP error messages are a fundamental part of the Internet control architecture. They serve as feedback mechanisms that inform endpoints and intermediate devices about various network issues, such as unreachable destinations, routing failures, and packet fragmentation requirements. By enabling dynamic adjustments in response to network conditions, ICMP error messages help maintain the reliability, efficiency, and robustness of end-to-end communication. Without this feedback channel, many essential protocols and diagnostic tools, including Path MTU Discovery and traceroute, would be significantly impaired. ICMP error messages pose inherent challenges in validation. This issue is especially pronounced when the ICMP error includes a payload from a stateless protocol, such as UDP and ICMP. In such cases, the receiving host often lacks sufficient context to determine whether the error message corresponds to a legitimate packet it previously sent. Since UDP does not maintain per-flow state at the transport layer, the absence of session semantics makes it difficult to verify the authenticity and relevance of the ICMP error, thereby opening a door to potential abuse. The difficulty in validating ICMP errors creates a powerful attack vector for off-path adversaries. By forging ICMP error messages that appear to target legitimate traffic, attackers can deceive the recipient into misinterpreting the network state. These forged messages can trigger complex cross-layer interactions within the TCP/IP stack-especially when they reference stateless protocols-causing the system to react in unintended ways. Such manipulation can lead to serious vulnerabilities, including information leakage, denial of service, or misrouting of traffic. Crucially, these attacks do not require the adversary to intercept or observe the actual traffic, enabling stealthy exploitation of protocol semantics from remote positions on the Internet. These ICMP-based attacks enable multiple exploitation scenarios:

1. Information leakage, where attackers observe system responses to ICMP error messages to infer internal state such as TCP sequence numbers or IP Identification (IPID) values;
2. Ambiguity on shared variables, where ICMP messages create inconsistencies in shared variables like MTU between layers, causing fragmentation errors or dropped packets;
3. Semantic gaps in legitimacy checking, where stateless protocols accept ICMP control messages without sufficient validation mechanisms to verify the legitimacy of diverse protocol data;
4. Identity deception due to lack of data source verification, where ICMP packets impersonate legitimate network devices without proper authentication, tricking targets into accepting malicious routing or control information.

The effectiveness of these attacks stems from the implicit trust protocols place in cross-layer communications and the difficulty of validating control message authenticity across protocol boundaries.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Threat Model This document focuses on vulnerabilities that can be exploited by off-path attackers-adversaries who are not positioned on the direct communication path between a client and a server. Unlike on-path attackers who can intercept, modify, or drop packets in transit, off-path attackers operate from external network locations and lack the ability to directly eavesdrop on or manipulate legitimate traffic flows. However, they retain the capability to inject spoofed packets into the network, making them a significant threat to protocol security. The off-path threat model represents a realistic and prevalent attack scenario in modern networks. Off-path attackers can operate from anywhere on the Internet, including compromised hosts, botnets, or even legitimate network positions that are simply not on the target communication path. This positioning makes detection more challenging and expands the potential attack surface significantly compared to on-path attacks, which require the attacker to be strategically positioned between communicating endpoints.

Off-Path Attack Model

In this threat model, the attacker leverages the ability to send spoofed IP packets-particularly ICMP messages-to trigger cross-layer vulnerabilities within the target's network stack. By forging source IP addresses, the attacker can impersonate trusted entities such as routers, servers, or network infrastructure components. These spoofed packets appear legitimate at the network layer and can successfully traverse network paths to reach their intended targets. The fundamental assumption underlying many protocol designs is that packets arriving from the network layer carry implicit trust regarding their origin and legitimacy. However, protocol implementations SHOULD NOT blindly trust such packets. This assumption becomes a critical vulnerability in the off-path attack model, where malicious packets can be crafted to exploit cross-layer interactions without requiring the attacker to compromise the direct communication path. The resulting attacks can violate protocol semantics, disrupt ongoing communications, or manipulate system behavior while remaining difficult to detect and attribute.

Problem Statement Four types of vulnerabilities-Information Leakage, Ambiguity or Desynchronization on shared variables, Semantic Gaps, and Identity Deception-can emerge from cross-layer interactions within the TCP/IP protocol suite. These vulnerabilities stem from fundamental flaws in architectural assumptions, shared state management, and the lack of guarantees for cross-layer validation.Protocol designers SHOULD carefully evaluate cross-layer interactions to minimize such risks.

Information Leakage This vulnerability arises when observable fields in one protocol layer expose information that is semantically or cryptographically bound to another layer. Specifically, when a protocol assigns values to a field based on internal or high-layer state-such as counters or identifiers-that field may serve as an unintentional side channel. If this field is externally observable, an entity without access to internal state can correlate changes in its value to infer sensitive information, undermining the isolation between protocol layers. The underlying cause of this vulnerability lies in the lack of entropy separation across protocol layers. When the state generation logic of a lower-layer protocol is influenced by, or derived from, upper-layer state-either directly or indirectly-observable behavior at the lower layer may unintentionally reveal sensitive upper-layer information. This creates a channel through which confidential state can be inferred by external observers. Furthermore, if protocol behavior permits external stimuli (such as control-plane messages) to affect the internal assignment policies of protocol fields, the risk of information leakage is significantly amplified. Fields originally designed for operational purposes at the network layer may, under such conditions, become conduits for exposing transport-layer state, thereby undermining confidentiality and weakening protocol-layer security guarantees such as sequence number randomization. A notable instance of this phenomenon is the coupling between the IP Identification (IPID) field and the TCP sequence number space. Although the IPID field was originally introduced to support IP-layer fragmentation and reassembly, certain implementations assign its value in ways that are indirectly influenced by active TCP session states. In some systems, off-path attackers can manipulate this assignment logic-e.g., by sending crafted ICMP errors-to trigger changes in the IPID generation behavior. By observing variations in IPID values, attackers can infer whether their injected TCP packets contain correct or incorrect sequence numbers, thereby learning the valid sequence number and enabling off-path TCP session hijacking .

IPID-Based Connection Inference Attack | (Action: Clear DF | | Needed" | Flag, Use Hash-based | | (src=attacker) | IPID) | | | | |---(2) Probe Request---->| | |<--(3) Probe Reply-------| | | (IPID=x) | | | | | | |<--------(4) SYN---------| | | | | |---(5) SYN/ACK---------->| | | (IPID=x+1) | | | (Shared IPID | | | increments) | | | | |---(6) Probe Request---->| | |<--(7) Probe Reply-------| | | (IPID=x+2) | | | (Attacker observes | | | IPID jump) | | ]]>

Ambiguity on Shared Variables Protocols within the same stack frequently operate on shared global variables, such as metrics related to path properties, endpoint capabilities, or buffer dimensions. When these variables are updated asynchronously or within layer-specific contexts, state inconsistencies may arise. These shared variables are often used by multiple layers to make decisions, leading to potential conflicts or discrepancies if updates are not properly synchronized. State desynchronization occurs when one layer updates a shared variable in response to a specific event, while other dependent layers are either unaware of the update or unable to reflect the change immediately. This type of vulnerability is characterized by temporal or contextual divergence in the interpretation of shared data. Such divergence can occur when network or transport layers rely on outdated or inconsistent information due to the asynchronous nature of updates across layers. For instance, a network-layer parameter such as Maximum Transmission Unit (MTU), which is updated in response to a control-plane input or a network change, may not immediately be propagated to the transport layer. As a result, the transport layer may continue to operate under the assumption of an outdated MTU, which can lead to improper handling of data fragments or errors in packet transmission. A concrete example of this vulnerability can be seen in the interaction between the TCP and IP layers concerning Path MTU Discovery (PMTUD). When an attacker sends a forged ICMP fragmentation-needed packet to manipulate the Path MTU (PMTU), the newly updated PMTU may not be immediately propagated to the transport layer, which continues to operate under the assumption of the previous, higher MTU value. This desynchronization can cause TCP to generate packets that exceed the updated MTU, resulting in unintended fragmentation at points where fragmentation is prohibited, or packet drops in environments where fragmentation is not supported. Such cross-layer inconsistencies disrupt data transmission, violate TCP's non-fragmentation assumptions, and introduce operational errors including communication delays and packet loss. Implementations SHOULD ensure that updates to shared variables are properly synchronized across protocol layers. More critically, this vulnerability enables attackers to exploit IP fragmentation mechanisms to inject malicious packets and potentially hijack TCP connections . The lack of proper synchronization between layers in handling shared path properties like MTU creates significant security vulnerabilities within the protocol stack, exposing systems to both denial-of-service and session hijacking attacks.

IP Fragment Injection Attack | | | Connection | | | | | |---(2) Trigger IP------->| | | Fragmentation | | | | | |-----------(3) Forge & Inject IP Fragment--------->| | | | | |<--(4) Legitimate--------| | | IP Fragments | | | | | | (5) Mis-reassemble | | | Packet | | | (Forged + Legitimate) | | | | ]]>

Semantic Gaps to Check the Legitimacy of Diverse Protocol Data Protocols often depend on implicit assumptions about the structure and statefulness of adjacent protocol layers. When a protocol receives cross-layer input containing data attributed to another protocol, it may attempt validation based on limited semantic knowledge or incomplete contextual information. If the incoming data originates from a stateless or loosely specified layer, or lacks integrity guarantees, the receiving protocol faces significant challenges in determining data legitimacy. This fundamental limitation creates vulnerabilities when protocol validation processes prove inadequate for ensuring the authenticity and integrity of cross-layer communications. This semantic validation gap becomes particularly exploitable when protocols rely on partial data representations, such as fixed-length headers or truncated payloads, for legitimacy assessment. Protocols often implement basic checksums or header-based validation mechanisms without considering the full operational context or semantic meaning of the data. This creates opportunities for attackers to craft malicious packets that conform syntactically to expected formats while semantically violating intended operational contexts. Such carefully crafted malformed packets can trigger unintended state transitions, erroneous control decisions, or inconsistent processing behaviors that diverge from correct protocol logic. A concrete illustration of this vulnerability emerges in the handling of forged ICMP redirect messages targeting stateless protocols such as UDP. ICMP redirect messages are legitimate network control packets used by routers to inform hosts about more optimal routing paths. However, stateless protocols like UDP cannot maintain session state or establish trust relationships for their connections, making direct validation of ICMP control messages impossible. Attackers exploit this validation gap by crafting and injecting malicious ICMP redirect messages with spoofed source addresses, deceiving target hosts into redirecting their traffic through attacker-controlled gateways . This enables sophisticated man-in-the-middle attacks where adversaries can intercept, modify, or redirect network traffic without being positioned on the original communication path. The fundamental vulnerability stems from the absence of stateful correlation mechanisms and authenticity validation across protocol layer boundaries, allowing forged control messages to manipulate legitimate network behavior.

ICMP Redirect Traffic Hijacking Attack | | | | Neighbor | | | | Host | | | | | | | |-------(2) Forge UDP Datagrams-------------------->| | | | | | | |---(3) Establish->| | | | UDP Socket | | | | | |-------(4) Forge ICMP Redirect-------------------->| | | | | | | (5) Check Passed | | | | | | |<-----(6) Redirected Traffic------| | | | | | |--(7) Discard--| | | | Traffic X | | | | | | | | | (8) No Response | | | Received ]]>

Identity Deception Due to Lack of Data Source Verification Cross-layer interactions often rely on implicit trust assumptions regarding the provenance and authenticity of received data, particularly when control messages or routing information traverses protocol layer boundaries. Protocol implementations typically operate under the assumption that data originating from lower layers-including control messages, routing updates, and error notifications-carries inherent legitimacy, provided it conforms to expected syntactic formats and protocol specifications. However, this fundamental trust assumption creates a critical vulnerability when protocols accept cross-layer input without implementing robust mechanisms to verify the authentic origin or validate the association with established communication contexts. Under such circumstances, protocols become susceptible to identity deception attacks, where malicious entities can successfully impersonate legitimate network components or communication peers. This vulnerability emerges from the systematic absence of cryptographic authentication frameworks and contextual validation mechanisms that would otherwise establish secure bindings between data sources and trusted communication relationships. The lack of comprehensive identity verification enables malicious actors to exploit these authentication gaps by injecting carefully crafted ICMP packets and other spoofed control messages into legitimate communication flows, effectively masquerading as authoritative network infrastructure components such as routers, gateways, or access points. The severity of this vulnerability is further amplified when underlying network infrastructure-including forwarding engines, hardware accelerators, and intermediate processing nodes-fails to enforce stringent access control policies or implement comprehensive provenance verification before relaying control messages to higher protocol layers. Consequently, maliciously crafted ICMP packets can propagate through the network stack unchecked, systematically undermining the integrity and trustworthiness of the entire communication system. The propagation of these unverified ICMP control messages can trigger cascading security failures, including unauthorized reconfiguration of forwarding behaviors, systematic disruption of established communication flows, illegitimate privilege escalation within protocol stacks, and ultimately comprehensive compromise of network reliability and security. These attacks leverage the inherent trust protocols place in ICMP control messages, exploiting the fundamental assumption that such messages originate from legitimate network infrastructure. A concrete manifestation of this vulnerability can be observed in sophisticated attacks against Wi-Fi networks, where adversaries deploy malicious terminals to impersonate legitimate Access Points (APs) while simultaneously injecting forged ICMP redirect messages. In this attack scenario, the malicious entity exploits the implicit trust that Wi-Fi-enabled devices place in both wireless control frames and ICMP network control messages. By strategically crafting and transmitting spoofed ICMP redirect packets alongside fraudulent wireless association messages, attackers can systematically deceive target devices into redirecting their network traffic through attacker-controlled infrastructure. This multi-vector approach enables sophisticated man-in-the-middle attacks that combine wireless protocol exploitation with ICMP-based traffic manipulation, allowing adversaries to intercept, modify, or redirect victim communications while maintaining the appearance of legitimate network operation . The effectiveness of these attacks stems from the fundamental vulnerability in cross-layer trust assumptions and the absence of robust authentication mechanisms for verifying the identity of ICMP message sources.

Wireless Network Routing Cache Poisoning | | | | (src=Server) | | | | |-(1.2) Ping---->|------------->| | | Reply | | | | (Action: Create| | | | Routing Cache)| | | | | | |-(1.3) UDP Port->| | | | Probe | | | |<-(1.4) ICMP-----| | | | Port | | | | Unreachable | | | | (Attacker finds | | | | open port) | | | | | | | | | | | |-(2.1) ICMP----->| | | | Redirect | | | | (src=AP, with | | | | forged UDP for | | | | check evasion) | | | | | | | | (2.2) Action: Routing Cache is Poisoned,| | Attacker becomes the next-hop. | | | | | | | | | |<-(3.1) Redirect-| | | | Traffic | | | | ("I like you, | | | | server Bob!") | | | | | | | |-(3.2) Falsified>|------------------------------>| | Traffic | | | | ("I hate you, | | | | server Bob!") | | | | | | | ]]>

Mitigation Directions The vulnerabilities arising from cross-layer interactions can be mitigated according to the following directions: First, enhancing data provenance validation across protocol layers is crucial. By introducing robust mechanisms to authenticate the source of control messages and routing information, implementations SHOULD prevent unauthorized entities from injecting malicious data into the network. This may involve integrating cryptographic signatures or contextual authentication protocols that verify the identity of the sender and the legitimacy of the message. For example, each control message can be signed with a cryptographic key, and the recipient protocol layer would validate the signature before processing the message. This ensures that the data originates from a trusted source and has not been tampered with in transit. Second, enforcing stronger access control and provenance checks at lower protocol layers is essential. The underlying infrastructure, such as routers, access points, and hardware accelerators, should be designed to perform rigorous checks on all control messages before passing them to higher layers. This includes verifying the authenticity of the source and ensuring that the message belongs to a valid communication context. By placing these checks at the network layer or physical layer, we can prevent malicious control messages from propagating up to higher layers, where they could potentially cause misconfigurations or elevate an attacker's privileges. Finally, introducing more granular trust models for cross-layer communications can reduce reliance on implicit trust. Instead of assuming that data from lower layers is always trustworthy, protocols can establish explicit trust relationships that govern interactions between layers. This could involve using a combination of contextual information, such as previous successful communication sessions, coupled with cryptographic mechanisms that ensure data integrity. For instance, transport layer protocols could require secure key exchange with the network layer before accepting control messages. This approach ensures that only trusted entities can send sensitive control information and prevents malicious actors from exploiting the cross-layer trust assumptions. These directions provide a framework for securing cross-layer interactions by ensuring that data flows between layers are properly validated and authenticated, reducing the risk of identity deception and unauthorized control. By implementing these strategies, we can significantly enhance the overall security of protocol stacks and protect against attacks that exploit cross-layer vulnerabilities.

IANA Considerations This memo includes no request to IANA.

Security Considerations This document identifies security vulnerabilities in cross-layer interactions within the TCP/IP protocol suite. The vulnerabilities described-information leakage, shared variable desynchronization, semantic gaps, and identity deception-represent significant threats to network security that require careful consideration in protocol design and implementation. The security implications of these vulnerabilities extend beyond individual protocol layers to affect the overall integrity and trustworthiness of network communications. Implementers and protocol designers SHOULD consider the mitigation strategies outlined in this document when developing new protocols or updating existing ones.

References Normative 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. 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. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References 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. Tsinghua University Tsinghua University, Zhongguancun Laboratory George Mason University Tsinghua University, Zhongguancun Laboratory Tsinghua University, Zhongguancun Laboratory Tsinghua University Tsinghua University Tsinghua University George Mason University Tsinghua University Tsinghua University Tsinghua University George Mason University Tsinghua University Tsinghua University Tsinghua University, Qi An Xin Group Qi An Xin Group Tsinghua University, Qi An Xin Group UC Riverside Tsinghua University Tsinghua University, Zhongguancun Laboratory George Mason University Tsinghua University Tsinghua University, Zhongguancun Laboratory Tsinghua University Tsinghua University, Zhongguancun Laboratory George Mason University UC Riverside Tsinghua University Beijing University of Posts and Telecommunications Tsinghua University Tsinghua University, Zhongguancun Laboratory

Acknowledgements The authors would like to thank the IETF community, particularly members of the ICMP and Security Working Groups, for their valuable feedback and insights during the development of this proposal. Special thanks to the contributors who provided research findings that form the foundation of this analysis.