Why is a stateful IPv4 NAT's session table a denial-of-service target, and what do the NAT RFCs require when it cannot create a new mapping?

## What the table holds A stateful NAT keeps an entry for every **mapping** (inside address and port to public address and port) and, alongside it, per-destination **session** and **filter** state; RFC 6888 REQ-5 names sessions and filters as the state an operator should be able to limit. Every entry costs memory and lookup work, and the table is finite. Unlike a router's forwarding table, which grows with the topology, this one grows with **traffic**. ## Why it fills, and who can fill it Entries are created by **new flows** and survive until they have been idle for at least the minimum the behavioural RFCs set: | Flow | Minimum idle lifetime | Source | |---|---|---| | UDP mapping | 2 minutes; 5 minutes or more recommended (shorter allowed for specific well-known destination ports) | RFC 4787 REQ-5 | | TCP, established | 2 hours 4 minutes | RFC 5382 REQ-5 | | TCP, partially open or closing | 4 minutes | RFC 5382 REQ-5 | The table's occupancy is therefore roughly **new-flow rate x how long each entry lingers**. Typical ways it fills: - An inside host that is infected or scanning opens thousands of connections a second to random destinations; every SYN that gets no answer sits in transitory state. - An application that sends many short UDP exchanges to many destinations. - An inbound SYN flood against a **forwarded** service: each attempt matching a forwarding rule creates session state. - By contrast, unsolicited inbound packets that match no mapping create **no mapping** - they are not forwarded. At most, a NAT following RFC 5382 REQ-4 holds an unsolicited SYN for at least 6 seconds before answering it, and it may drop such SYNs silently under attack - so an outside attacker usually needs a forwarded port, or a foothold inside, to fill the table. In a shared translator, one subscriber's flood exhausts the table for everybody, which is why RFC 6888 treats per-subscriber limits as a fairness and denial-of-service question. ## What the RFCs require when it is full RFC 6888 REQ-11 sets the rule for a carrier-grade NAT that cannot create a dynamic mapping because of resource constraints or quotas: 1. It MUST drop the packet that would have created the mapping. 2. It SHOULD send an ICMP Destination Unreachable with **code 1 (Host Unreachable)** to the sender - preferred over code 13 because RFC 1122 lists it as a soft error, so the sender's TCP does not abort the attempt outright. 3. It SHOULD notify a management system, if one is configured. 4. It MUST NOT delete existing mappings to make room for the new one. For NATs in general, RFC 5508 REQ-8 says to drop the packet and send an ICMP Destination Unreachable with **code 13 (Communication Administratively Prohibited)**. The shared principle: failing a **new** connection is better than killing an **established** one, because applications cope with setup failures far better than with a working session vanishing. ## Containing it - **Per-subscriber limits** - RFC 6888 REQ-4 on the number of external ports and REQ-5 on state memory - plus a rate limit on how fast one subscriber may create mappings. - **Shorter transitory timers** where security matters: RFC 7857 lets a NAT configure the partially-open timeout below 4 minutes, while still recommending 4 minutes as the default. - **Active liveness checks** while under attack, which RFC 5382's security considerations allow instead of waiting out passive timers. - Do **not** answer it by cutting the established-TCP timeout far below the RFC minimum on its own: healthy but idle connections then vanish without any endpoint closing them. ## Watching for it The early signal is not a full table but its slope: occupancy that climbs with no matching rise in users, many entries in the transitory state, or one inside address owning a disproportionate share of sessions. Those point at a scanning host or a flood against a forwarded service long before new connections start failing, and they are far cheaper to act on than an outage. ## State versus ports Keep this separate from **port exhaustion**: an address-and-port translator can also run out of external ports on its public addresses while it still has memory to spare. Both are capacity limits of the same box, but the remedies differ - more public addresses or wider port allocation for ports, limits and timer policy for state. In an interview, naming which resource ran out is half the diagnosis.