ReDAN: Remote DoS Attacks against NAT Networks

NDSS Symposium 2025

Feb 2025

The Research Question

Can an off-path attacker...
...identify a NAT device?
...and terminate its TCP connections?

The Hypothesis

  • 1. RFC Ambiguity:
    PMTUD error handling is not strictly defined.
  • 2. Implementation Reality:
    Performance > Security.
  • 3. The Result:
    Skipping TCP Sequence Validation.

Phase 1: The Trap

Identifying the NAT Device

1. The Visit: User clicks a link.

2. The Probe: ICMP "Frag Needed" (MTU=600).

3. The Target: We now have the Public IP.

The Side Channel

Single Host

Updates own MTU.

Response: Fragmented

NAT Gateway

Forwards update to client.
Does NOT update itself.

Response: Full Size (1500)

Phase 2: The Target

Not "The Whole Internet"

NAT Mapping: 5-Tuple

[SrcIP, SrcPort, DstIP, DstPort, Protocol]


We must choose a "Victim Server"

e.g., SSH (22), HTTPS (443), Game Server

Phase 3 (A): Blind Flood

Deleting the NAT Mapping

  • 1. Spoof IP: Pretend to be Victim Server.
  • 2. RST Flood: Target ports 32768–61000.
  • 3. The Flaw: No Sequence Check.

Result: NAT "forgets" the connection.

Phase 3 (B): Ghost RST

Terminating the Server Side

  1. Attacker sends PUSH/ACK (Spoofed).
  2. NAT receives it -> "I have no mapping!"
  3. NAT sends Valid RST to Server.

Connection Terminated.

Vulnerability Stats

Network Type Vulnerable %
4G LTE 100% (52/52)
5G 100% (38/38)
Public Wi-Fi ~80-87%
Cloud (AWS/Ali) Mixed

Total: 92% of tested networks.

The "Library" Scenario

Attacker

Floods Port Range
(32768–61000)

→

Victim NAT

100 Students Connected

All 100 Students Disconnected.

Conclusion

  • NAT is not a firewall.
  • Attack requires only 5.7 MBps.
  • Fix: Sync PMTUD & Validate TCP Sequences.

Questions?