A blind attacker wants a long-lived TCP session down - is a forged reset or forged data the cheaper route?

## Two objectives, two very different bills A blind off-path attacker can try to *steer* a session by injecting bytes into it, or *end* it with a teardown. Interviewers ask this because the two look similar - both are a spoofed segment that has to be accepted - and cost wildly different amounts. ## What a forged teardown needs, on a classic stack - The four-tuple. - A sequence number inside the receive window. That is the whole list. There is no payload to construct, no acknowledgement value to make plausible, and nothing about the application protocol above needs to be understood. The attacker does not care what the two endpoints were saying to each other. One accepted packet and the connection is gone, and there is no partial success to manage: the search runs until a guess lands and then the objective is complete. This is why an actor whose goal is disruption - a state-aligned operator tearing down a peering session, or a group that wants an outage it can claim - finds this attack attractive at all. No foothold is sought, nothing is installed, nothing has to persist. ## What forged data needs Injecting bytes is a different job: - **The four-tuple**, as before. - **An in-window sequence number**, as before. - **An acceptable acknowledgement value.** Data-bearing segments are checked against an acknowledgement range as well, so there is a second search. - **Application-layer meaning.** Bytes that land in the stream are handed to whatever is above. For a routing session or a replication link, arbitrary bytes are a malformed message, and a malformed message usually causes the peer to abort the session. That is a teardown by a longer route, not the steering the attacker wanted. - **A race with the real sender.** The legitimate stream is filling that sequence space continuously. Injected bytes that arrive after the real ones for the same offsets are duplicates and discarded; if they arrive first, the real data becomes the duplicate, which desynchronises the two endpoints' views of the stream. So blind data injection is an expensive way to achieve an unreliable result. Its realistic outcome is corruption or an abort, not control. ## What RFC 5961 changed RFC 5961 exists specifically to harden TCP against blind in-window attacks, and it re-prices this comparison: - **Reset:** accepted only if its sequence number equals the next expected byte exactly. In-window but inexact produces a challenge acknowledgement to the *real* peer and the connection stays up. - **SYN on an established connection:** likewise answered with a challenge acknowledgement rather than acted upon. - **Data:** subject to a tighter acknowledgement acceptance check. On such a stack the reset search collapses from "one window in 2^32" back to "one value in 2^32", which really is infeasible to brute force, while in-window data remains range-checked. The cheap and the expensive forgeries swap places. ## Why "we are hardened" is not the end of the answer Two caveats belong in a senior answer. First, the challenge-acknowledgement machinery itself became an oracle. An implementation that rate-limited challenge acknowledgements with a single system-wide counter let an off-path attacker probe that shared counter and infer whether a guess had been in-window - turning a blind brute force into a guided search. The fix was to randomise the limit, but the lesson generalises: a mechanism that answers differently depending on a secret leaks that secret. Second, none of this authenticates the sender. Hardening raises the number of guesses; it does not make a forged segment distinguishable from a real one on its merits. Only a keyed value carried with each segment, or a check that the segment could not have come from off-path at all, does that. ## The recovery asymmetry The two objectives also cost the endpoints differently. A torn-down peering session withdraws everything learned over it and forces reconvergence downstream; the session itself may re-establish in seconds, but the routing churn is the damage and repeated teardowns can push a peer into damping. A desynchronised replication link tends to fail loudly and resynchronise, which is disruptive but self-correcting. Injected data that *does* parse is the worst case, because the endpoints do not disagree about the stream at all - they agree on something the attacker wrote. ## How to answer it in a loop Name the stack behaviour first, then the objective, then the bill. "On an unhardened receiver, the reset - one packet, any in-window value, no semantics needed. On an RFC 5961 receiver, the reset needs an exact match, so in-window data or the challenge-acknowledgement side channel is the cheaper route."