How can forged ICMP error messages reset or slow an established TCP connection, and which defences does RFC 5927 describe?
answer
- a blind attacker needs the four-tuple
- hard errors versus soft errors
- the quoted header holds the sequence number
- a fake, tiny next-hop MTU
- PLPMTUD needs no ICMP
basics
~20 sA blind attacker who knows a connection's addresses and ports can forge ICMP hard errors to abort it, or tiny-MTU messages to cripple it. RFC 5927's defences: check the quoted sequence number, treat hard errors as soft, stop trusting ICMP for path MTU.
solid answer
~50 sTCP must act on ICMP errors, finding the connection from the quoted IP header plus the TCP header's first 8 bytes: both ports and the sequence number. RFC 5927 (Informational) describes three blind attacks. A forged hard error can abort the connection: RFC 1122 and RFC 9293 say TCP SHOULD abort on IPv4 type 3 codes 2 to 4, and RFC 5927 treats ICMPv6 type 1 codes 1 and 4 alike. A forged Source Quench once forced slow start, but RFC 9293 now says TCP MUST silently discard it. A forged type 3 code 4 or Packet Too Big advertising a tiny MTU forces tiny segments. The defences: accept an error only if its quoted sequence number lies between SND.UNA and SND.NXT; randomise ephemeral ports; treat hard errors as soft once the connection is synchronised; and use Packetization Layer PMTUD (RFC 4821), which needs no ICMP.
go deeper
Recall that forged ICMP errors can disrupt TCP connections and that the attacker needs to know the connection's addresses and ports.
Explain hard versus soft errors, what the quoted header carries for TCP, and why Source Quench no longer matters.
Show the defensive judgment: sequence-number validation and its blind spot, hard-as-soft handling, PMTUD hardening or PLPMTUD, and why dropping all type 3 is the wrong fix.
Weigh robustness against responsiveness: ignoring hard errors keeps connections alive under attack but delays reaction to real failures; decide where that trade belongs for long-lived connections.
## Why ICMP can touch TCP at all TCP **must** act on ICMP errors passed up from IP (RFC 9293 §3.9.2.2, which also applies to ICMPv6). Each error quotes the offending datagram's IP header and at least its first 64 bits of payload; for TCP those 8 bytes are the **source port, destination port and sequence number**. That is how the stack finds the connection, and it is also what an attacker must forge. RFC 1122 and RFC 9293 split the errors into two classes: - **Soft errors** — IPv4 Destination Unreachable codes 0, 1 and 5, Time Exceeded, Parameter Problem: TCP MUST NOT abort, and SHOULD tell the application. - **Hard errors** — Destination Unreachable codes 2, 3 and 4 (protocol unreachable, port unreachable, fragmentation needed and DF set): TCP SHOULD abort the connection. The outer source of an ICMP error is no help in judging it: any router on the path may legitimately send one, so the attacker does not even need to spoof that address. ## The three blind attacks (RFC 5927) | Attack | Forged message | Effect | Where it stands now | |---|---|---|---| | Blind connection reset | IPv4 type 3 codes 2, 3, 4; ICMPv6 type 1 codes 1 and 4 | Stack aborts the connection | Widely mitigated by implementations, see below | | Blind throughput reduction | Source Quench (IPv4 type 4) | Connection drops into slow start; with a one-segment initial window, about one segment per round trip | Dead: RFC 6633 deprecated it; RFC 9293 says TCP MUST silently discard it | | Blind performance degrading | Type 3 code 4, or ICMPv6 Packet Too Big, advertising a tiny next-hop MTU | Sender shrinks its segments; more packets and header overhead for the same data | Needs PMTUD hardening | Two details make the reset attack nastier. RFC 5927 notes it succeeds even when the TCP segments themselves are authenticated, because the abort is triggered by ICMP, which that authentication does not cover. And some stacks applied one hard error to every connection between the same two hosts. For the MTU attack, the damage has a floor: RFC 1191 says a host MUST never reduce its path-MTU estimate below 68 bytes, and should never raise its estimate because of a Datagram Too Big message. At 68 bytes, though, a TCP segment with options may carry little or no data. ## Defences 1. **Sequence-number check.** Accept an error only if the quoted sequence number satisfies `SND.UNA =< SEG.SEQ < SND.NXT`, i.e. it refers to data in flight. A blind guess then succeeds with probability about Flight_Size / 2^32, and with nothing in flight it cannot succeed. It does nothing against an on-path attacker who sees the segments, and it may discard a stale legitimate error. 2. **Port randomisation.** The attacker must know or guess the four-tuple; randomising the client's ephemeral port makes the guess harder. 3. **Hard errors as soft in synchronised states.** Most popular implementations, RFC 5927 reports, do not abort an ESTABLISHED (or later) connection on a hard error and do not spread one error across connections. RFC 9293 still says SHOULD abort and records that some implementations do not; the cost is slower reaction to a genuine error, which the connection's own timeout still catches. 4. **Discard Source Quench**, as RFC 6633 and RFC 9293 now require. 5. **Harden path-MTU discovery.** Disregard Packet Too Big messages while the connection keeps making progress (a modification RFC 5927 describes from implementations), or use **Packetization Layer PMTUD** (RFC 4821, and RFC 8899 for datagram transports), which probes with real packets and needs no ICMP, at the cost of slower convergence. 6. **Middlebox filtering on the quoted header.** A firewall cannot validate an error's outer source, but it can check the *quoted* header's source address: ingress filtering stops outsiders forging errors about internal connections, and egress filtering stops insiders attacking outside ones. ## What this means for filtering policy Dropping all type 3 messages is not a fix: it throws away path-MTU discovery to stop an attack that the stack itself can mostly neutralise. A stateful firewall that admits only errors whose quoted header matches a tracked connection forces the attacker to guess the four-tuple, which is the same bar the host's checks set, and the two together are the practical answer. ## Common misconceptions - That the attacker must spoof the remote peer's address: routers send errors too. - That TCP's own segment authentication blocks ICMP-triggered resets. - That a forged MTU message can drive the path-MTU estimate below 68 bytes; RFC 1191 sets that floor.
- Why can't a firewall stop forged ICMP errors by checking that their source is the remote TCP peer?RFC 5927 §4.3 points out that ICMP errors legitimately come from any router on the path, so the outer source address proves nothing and the attacker need not spoof it. What the attacker must forge is the quoted header, whose source has to be a connection endpoint. A middlebox can filter on that quoted source address: ingress filtering for errors about internal connections, egress filtering for attacks launched from inside.
- Why does the TCP sequence-number check not stop an on-path attacker?The check only proves the attacker knows which sequence numbers are in flight. A blind attacker must guess, with roughly Flight_Size / 2^32 odds per attempt; an attacker who can observe the connection's segments reads SND.UNA and SND.NXT directly and quotes a valid number. RFC 5927 says so explicitly. Against an on-path attacker, the remaining defences are treating hard errors as soft and not depending on ICMP for path MTU.
saying these in an interview costs you the question
- An attacker must spoof the remote peer's address to forge a useful ICMP error.
- TCP's own segment authentication protects a connection from ICMP-triggered resets.
- Current TCP must slow down on Source Quench, as RFC 1122 required.
- Blocking all ICMP type 3 messages is the right fix for ICMP attacks on TCP.
- A forged fragmentation-needed message can push a host's IPv4 path-MTU estimate below 68 bytes.