ReDAN: An Empirical Study on Remote DoS Attacks against NAT Networks

ReDAN: An Empirical Study on Remote DoS Attacks against NAT Networks

Speakers: Xuewei Feng

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=Y8FV8q1KnfU

Overview

This article delves into "ReDAN: An Empirical Study on Remote DoS Attacks against NAT Networks," a pivotal talk delivered by Xuewei Feng at the NDSS Symposium. The presentation uncovers a series of novel vulnerabilities within Network Address Translation (NAT) devices and proposes a sophisticated, low-traffic denial-of-service (DoS) attack that can remotely terminate TCP connections for clients operating behind NAT. The research highlights critical flaws in how real-world NAT implementations handle TCP reset packets and interact with Path MTU Discovery (PMTUD) mechanisms, exposing a widespread security risk across various network environments, including Wi-Fi, 4G/5G, IoT, and cloud networks.

The talk is significant because it challenges long-held assumptions about the security posture of NAT devices, which are commonly perceived as offering a degree of protection by preventing direct access from the internet to internal hosts. By demonstrating how an external attacker can manipulate NAT session states and tear down established TCP connections with minimal resources, the research underscores a fundamental weakness that impacts millions of users and organizations globally. It provides a comprehensive empirical study, validating the attack's efficacy across a broad spectrum of commercial routers, firmware, and operating systems, prompting urgent calls for industry-wide mitigation.

Background

▶ Watch: Introduction and ReDAN attack threat model (0:00)

Network Address Translation (NAT) is a fundamental networking technique widely deployed in modern internet infrastructure. Its primary functions include conserving public IPv4 addresses by allowing multiple devices on a private network to share a single public IP, and providing a rudimentary form of security by preventing direct, unsolicited inbound connections from the internet to internal hosts. The core of NAT's operation relies on a session mapping table, where the NAT device records active connections, mapping private IP addresses and ports to public ones. This table stores critical information such as endpoint IP addresses, ports, and connection states. Historically, NAT devices have been assumed to correctly validate TCP packet sequence numbers, especially for control packets like TCP reset (RST), to prevent malicious manipulation of connection states. However, this research reveals a pervasive vulnerability: many real-world NAT devices lack sufficient sequence number validation for TCP RST packets. This oversight allows an attacker to manipulate the NAT device's session mapping states, even without full knowledge of the connection's sequence numbers.

Another critical background component is Path MTU Discovery (PMTUD), a mechanism designed to prevent IP fragmentation across the internet by dynamically determining the maximum transmission unit (MTU) along a network path. When a host sends a TCP packet, it typically sets the Don't Fragment (DF) bit in the IP header to '1' and initially assumes a default MTU (e.g., 1500 bytes for Ethernet). If an intermediate router encounters a packet larger than its own MTU, it discards the packet (due to the DF bit) and issues an ICMP Fragmentation Needed error message back to the sender. This ICMP message includes the router's MTU value, prompting the sender to reduce its effective Path MTU for subsequent packets. While PMTUD is essential for network efficiency, the research identifies a side channel vulnerability within its implementation. Specifically, the Path MTU value updated by a host is often a global setting, affecting not only TCP but also other protocols like UDP or ICMP. This global update behavior, combined with how NAT devices handle ICMP packets, creates an exploitable differential response that can be used to identify clients behind NAT.

Prior work in network security has explored various methods for identifying NAT devices or launching DoS attacks. However, ReDAN uniquely combines a novel PMTUD side channel with the inherent TCP RST validation weakness in NAT devices. This synergy enables a remote, low-traffic DoS attack that is both difficult to detect and widely applicable, distinguishing it from previous attacks that might require more information, higher traffic volumes, or local network access.

Key Findings

▶ Watch: Core NAT vulnerability: lack of sequence number validation (2:00)

The ReDAN research presents several key findings that collectively expose a significant security flaw in modern networking:

• Reliable NAT Identification via PMTUD Side Channel: The study demonstrates a novel and highly reliable method to identify if a target host is behind a NAT device using a side channel in the PMTUD mechanism. This method is shown to be more effective than existing JavaScript-based or timing-based techniques.
• Widespread Vulnerability to NAT Mapping Manipulation: A core finding is the pervasive lack of sufficient TCP sequence number validation for RST packets in NAT devices. This vulnerability allows an attacker to arbitrarily remove NAT session mappings. The empirical study revealed this flaw in:
• Two out of six tested native operating systems (including FreeBSD and certain Linux versions).
• Six out of eight router firmware (including OpenWRT).
• An alarming 29 out of 30 commercial routers evaluated.
• Low-Traffic Remote DoS Capability: The researchers successfully demonstrated that an attacker can terminate established TCP connections or prevent new connections for NAT clients with a remarkably low traffic bandwidth. This makes the attack stealthy and resource-efficient.
• Real-World Impact and Validation: Extensive real-world experiments, involving seven vantage points and voluntary users over 11 months, confirmed the PMTUD identification method's effectiveness. Further analysis of 180 randomly selected NAT networks (including 4G/5G, Wi-Fi, and cloud environments) found that over 92% were vulnerable to the TCP reset attacks.
• Responsible Disclosure and CVEs: The vulnerabilities were responsibly disclosed to affected manufacturers, leading to acknowledgments from the FreeBSD community, OpenWRT, three major Chinese ISPs, three cloud providers, and four router vendors. The research secured four CVE identifiers (though the speaker mentions five in the transcript, the slide shows four, indicating potential for more or a slight discrepancy in reporting).
• Proposed Mitigations: The study also proposes two primary layers of mitigation: fixing the PMTUD side channel to prevent NAT identification, and enforcing stricter sequence number checks for TCP RST packets at NAT devices.

Technical Deep Dive

▶ Watch: Step 1: Identifying NAT clients using PMTUD side channel (4:00)

The ReDAN attack is a multi-stage process that leverages specific vulnerabilities in NAT and PMTUD implementations. To understand it, we first define the threat model and then detail the two main attack phases: NAT identification and the DoS attack itself.

The threat model for ReDAN involves five types of hosts:

1. An arbitrary victim TCP server: This could be any server providing TCP services (e.g., web, SSH, FTP).
2. A vulnerable NAT device: A gateway in various networks (Wi-Fi, 4G/5G, IoT, cloud).
3. Several victim clients: Located behind the vulnerable NAT device, accessing the victim server.
4. A fast attacker: Located on the internet, possessing the ability to perform IP spoofing.
5. An attacker-controlled vantage point: A server deployed by the attacker, which can be accessed by the victim clients (e.g., via URL-based advertisements).

The core of the attack hinges on the observation that while NAT devices maintain a session mapping table for TCP connections, many implementations lack robust validation for TCP reset (RST) packets. A legitimate TCP RST packet should have a sequence number within the receiver's valid window. However, vulnerable NAT devices often process and act upon RST packets with arbitrary sequence numbers, leading to the premature removal of session mappings. This is a critical departure from TCP specification and a significant security flaw.

Phase 1: Identifying Vulnerable NAT Clients via PMTUD Side Channel

The first step for the attacker is to determine if a target host is behind a NAT device or has a directly routable public IP address. This is achieved by exploiting a side channel in the Path MTU Discovery (PMTUD) mechanism.

The process unfolds as follows:

1. Initial Connection: A potential victim client initiates a TCP connection to the attacker's vantage point (e.g., by visiting a malicious URL).
2. Crafted ICMP Error: The vantage point, upon receiving the client's connection, crafts and sends an ICMP Fragmentation Needed error message back to the client. This message is designed to simulate a router along the path having a very small MTU (e.g., 600 bytes), much smaller than the typical 1500-byte Ethernet MTU. The attacker assumes the client's initial Path MTU is 1500 bytes.
3. Path MTU Update: If the client's host correctly processes this ICMP message, it will update its global Path MTU value to the smaller value (e.g., 600 bytes). This update affects all subsequent packets originating from that host, not just TCP packets.
4. Verification with ICMP Ping: The attacker then sends an ICMP ping packet of a large size (e.g., 1500 bytes) to the client's public-facing IP address. The response to this ping reveals whether the client is behind a NAT.

There are two distinct scenarios:

• Separate Host (Public IP): If the client is a separate host with a direct public IP address, its global Path MTU would have been updated to 600 bytes. When it receives the 1500-byte ICMP ping, it will attempt to send an ICMP reply. Since the packet size (1500 bytes) exceeds its updated Path MTU (600 bytes), and the DF bit is typically set for ICMP pings, the host will generate multiple IP fragments to send the reply (or respond with an ICMP "Fragmentation Needed" error itself, which is also distinguishable). The key is that the packet originates from the host itself.
• Client Behind NAT: If the client is behind a NAT device, the attacker's 1500-byte ICMP ping packet will only reach the NAT device. Crucially, the NAT device itself typically does not update its global Path MTU based on ICMP messages intended for internal hosts. Therefore, when the NAT device receives the ICMP ping, it will directly respond with a single ICMP reply packet of the same size (1500 bytes), without fragmentation, as its own Path MTU remains at the default 1500 bytes. The packet does not reach the client in a way that would trigger the client's updated Path MTU.

By observing whether the ICMP reply is fragmented or a single large packet, the attacker can reliably differentiate between a separate host and a client behind a NAT device. NAT clients are then marked as potential victims for the DoS attack.

Phase 2: Remote DoS Attack Against NAT Networks (ReDAN)

Once a NAT client is identified, the attacker proceeds to terminate its established TCP connections to a victim server. The attack relies on IP spoofing and the NAT device's poor TCP RST validation.

Assume a victim client behind a NAT device has an active TCP connection to a victim TCP server. The NAT device maintains two NAT mappings for this connection: one for the client's outgoing connection and one for the server's incoming responses. The attacker, being off-path, does not know the precise source port numbers, destination port numbers, or sequence numbers of this legitimate connection.

The attack unfolds in several steps:

1. NAT Mapping Removal (Client-side): The attacker first sends a large number of spoofed TCP RST packets to the NAT device. These packets are crafted with a spoofed source IP address of the victim server and various guessed destination port numbers (to hit the NAT mapping). Crucially, the sequence numbers in these RST packets can be arbitrary. Because the vulnerable NAT device does not strictly validate TCP sequence numbers for RST packets, it will likely process these spoofed resets and, upon matching a guessed port, tear down the corresponding NAT mapping for the client-server connection. The victim client, upon receiving these (potentially forwarded) RST packets, will check the sequence numbers and discard them as invalid, remaining oblivious to the NAT mapping removal.
2. Server-Side Socket Termination: With the NAT mapping removed, the attacker then sends forged TCP data packets to the victim server. These packets have a spoofed source IP address of the NAT device's public IP and various guessed source port numbers. Again, the sequence numbers in these forged data packets are arbitrary.
3. Server Response and NAT Device Action: If one of the forged data packets hits the correct source port that the server expects from the NAT device, the victim server will respond with a duplicate ACK packet (acknowledging the forged data) back to the spoofed source IP (the NAT device's public IP).
4. NAT Device Issues RST to Server: When this duplicate ACK packet arrives at the NAT device, the device attempts to find a corresponding NAT mapping. Since the attacker successfully removed the mapping in step 1, the NAT device finds no active mapping for this incoming ACK. According to TCP/IP stack behavior for unmapped packets, the NAT device will then generate and send a TCP RST packet back to the victim server. Critically, the sequence number of this RST packet will be copied from the incoming ACK packet, making it a valid RST from the server's perspective.
5. Server Socket Teardown: The victim server receives this valid RST packet (originating from the NAT device's public IP) and tears down its side of the TCP connection (its socket).
6. Client Socket Teardown: Later, when the victim client attempts to send further TCP data to the server, the server's socket is already closed. The server will respond with a TCP RST packet to the client, which will then tear down the client's side of the TCP connection.

At this point, the entire TCP connection between the victim client and the victim server has been terminated by the attacker, using a low volume of spoofed packets and without knowing the connection's internal state.

Demo / Proof of Concept

▶ Watch: Step 2: Detailed ReDAN DoS attack procedure (6:00)

The ReDAN research is underpinned by extensive empirical studies and real-world demonstrations, validating the attack's efficacy across a wide range of network devices and scenarios.

The first phase of the empirical study focused on verifying the PMTUD side channel for reliably identifying NAT clients. The researchers conducted end-to-end evaluations and confirmed that their PMTUD-based method was indeed more effective and reliable than existing JavaScript-based or timing-based techniques for differentiating between hosts with public IPs and those behind NAT. This foundational step is crucial for the attacker to select viable targets.

The second phase involved a comprehensive assessment of the widespread vulnerability to NAT mapping manipulation. The researchers systematically tested various NAT implementations:

• Operating Systems: They found that two out of six tested native operating systems (specifically FreeBSD and certain versions of Linux) were vulnerable to the TCP reset-based NAT mapping manipulation.
• Router Firmware: Six out of eight popular router firmware (including OpenWRT) exhibited the vulnerability.
• Commercial Routers: A staggering 29 out of 30 commercial routers evaluated were found to be vulnerable. This indicates a pervasive and systemic issue across the hardware and software used in consumer and small business networks.

To demonstrate the practical impact of the DoS attack, the researchers conducted two case studies:

• SSH (Secure Shell): They showed that an attacker could terminate established SSH connections, disrupting secure remote access.
• FTP (File Transfer Protocol): They also demonstrated the ability to prevent victim clients from establishing new FTP connections or terminating existing ones, thereby blocking file transfers.

In both cases, the attack required only a low traffic bandwidth from the attacker, highlighting its efficiency and stealth.

Finally, the study extended to real-world experiments to confirm the attack's applicability in diverse live environments.

• Vantage Points for PMTUD Testing: Seven vantage points were deployed globally, and links were shared with voluntary users over 11 months. The PMTUD identification method successfully identified numerous NAT clients, confirming its real-world viability.
• Anonymized Field Cases: The researchers also analyzed anonymized field cases to further validate their findings.
• Large-Scale Network Scanning: They randomly selected and tested 180 diverse NAT networks, encompassing 4G/5G mobile networks, Wi-Fi networks, and cloud network environments. The results were alarming: over 92% of these real-world NAT networks were found to be vulnerable to the TCP reset attacks. This extensive validation underscores the broad impact and urgency of addressing the ReDAN vulnerabilities.

Defensive Implications

▶ Watch: Empirical study findings and attack effectiveness (8:00)

The ReDAN attack reveals critical weaknesses in network infrastructure, necessitating a multi-layered defensive strategy. Defenders, including network administrators, ISPs, and device manufacturers, must consider the following implications and mitigations:

1. Fixing the PMTUD Side Channel: The initial step of the ReDAN attack relies on reliably identifying NAT clients through the PMTUD side channel. Mitigating this requires that hosts and NAT devices handle ICMP Fragmentation Needed messages more carefully:

• Host-side: Hosts should ideally apply Path MTU updates more granularly, perhaps per-connection or per-application, rather than globally for all packet types. Alternatively, they could be more robust in validating the source and context of ICMP messages before updating critical network parameters.
• NAT-side: NAT devices should not forward ICMP Fragmentation Needed messages in a way that allows an external attacker to infer the internal client's Path MTU state. Their behavior in responding to large ICMP pings should be indistinguishable between a direct host and a NAT client, or simply drop such diagnostic packets if they cannot be securely handled.

1. Enforcing Stricter TCP Packet Checks on NAT Devices: This is the most critical mitigation. The core vulnerability lies in the lack of robust TCP sequence number validation for RST packets by NAT devices.

• Sequence Number Validation: NAT devices must be updated to perform strict sequence number validation for all incoming TCP control packets, especially RST packets, before acting upon them (e.g., tearing down session mappings). An RST packet should only be accepted if its sequence number falls within the receiver's valid window. This requires NAT devices to maintain a more complete TCP state for each connection, which might increase resource requirements but is essential for security.
• Port Randomization: While not a direct mitigation for the RST vulnerability, robust port randomization by clients and servers makes it harder for attackers to guess active connection ports, thereby reducing the chances of hitting a valid NAT mapping with spoofed RST packets. However, this only adds a layer of difficulty, not a fundamental fix.

1. ISP-Level Source IP Spoofing Detection and Filtering: As highlighted in the Q&A, a fundamental prerequisite for the ReDAN attack is the attacker's ability to spoof IP addresses. If Internet Service Providers (ISPs) implement strict Ingress Filtering (BCP 38/84), where they verify that outgoing packets from their customers originate from valid IP addresses assigned to those customers, the attack's foundation is severely undermined. If spoofed packets cannot traverse the internet, the attacker cannot impersonate the victim server or NAT device. This is a crucial network-level defense that can prevent a wide range of spoofing-based attacks.

It's important to acknowledge the challenge raised during the Q&A regarding stricter checks on TCP RST packets. While stricter checks are vital, an attacker might still manage to craft some RST packets that fall within a valid (though perhaps narrow) sequence number window, making it "a little bit harder" rather than impossible. This suggests that a defense-in-depth approach, combining all proposed mitigations, is necessary to significantly reduce the attack surface. Furthermore, the historical context of similar RST attacks against BGP sessions underscores that simply hardening checks might not be a silver bullet without comprehensive authentication mechanisms like TCP MD5 or TCP AO, which haven't seen widespread deployment. Therefore, a combination of NAT device hardening, PMTUD obfuscation, and strong ingress filtering at ISPs offers the most robust defense.

Key Takeaways

• Widespread NAT Vulnerability: A significant majority (over 92%) of real-world NAT devices and networks are vulnerable to remote TCP DoS attacks due to insufficient sequence number validation for TCP reset packets.
• Novel NAT Identification: A new, highly effective PMTUD side channel allows remote attackers to reliably identify hosts operating behind NAT devices, a crucial precursor to the DoS attack.
• Low-Traffic DoS Capability: The ReDAN attack can terminate established TCP connections and prevent new ones for NAT clients with remarkably low traffic, making it stealthy and resource-efficient for attackers.
• Impact Across Network Types: The vulnerability affects a broad spectrum of network environments, including Wi-Fi, 4G/5G mobile networks, IoT, and cloud infrastructure, indicating a systemic issue.
• Urgent Need for Mitigation: Responsible disclosure has led to CVEs and acknowledgments from major vendors and ISPs, underscoring the urgency for patching NAT firmware, improving TCP stack robustness, and implementing stricter ingress filtering by ISPs.
• Defense-in-Depth Required: Effective mitigation necessitates a multi-layered approach, combining fixes for the PMTUD side channel, stricter TCP reset validation on NAT devices, and robust source IP spoofing prevention at the ISP level.

About the Speaker(s)

The talk "ReDAN: An Empirical Study on Remote DoS Attacks against NAT Networks" was presented by Xuewei Feng, representing a collaborative research effort from Tsinghua University, George Mason University, and Southeast University. While the transcript does not provide an extensive personal biography, Feng's presentation demonstrates deep expertise in network security, particularly in the intricacies of TCP/IP protocols, NAT implementations, and DoS attack vectors. Their work highlights a commitment to rigorous empirical study, responsible vulnerability disclosure, and proposing practical mitigations for critical internet infrastructure issues. The research reflects a strong academic background in identifying and analyzing complex security vulnerabilities in widely deployed networking technologies.