skip to content

Why doesn't TCP's 32-bit sequence space make blind injection into an established flow infeasible?

level: middleimportance: must knowfreq 58%

answer

  1. the denominator is wrong
  2. acceptance is range-based, not exact
  3. divide the space by the window
  4. fast links advertise huge windows
  5. one accepted segment is enough

basics

~20 s

Because the receiver does not demand one exact value. Any sequence number falling inside the advertised receive window is acceptable, so the real search is the sequence space divided by the window - thousands of guesses on a high-throughput link, not billions.

solid answer

~40 s

The 32-bit figure is the wrong denominator. A receiver decides whether an arriving segment is acceptable by asking whether its sequence number falls inside the currently advertised receive window, not whether it equals the next expected byte. So the attacker is not searching for one value in 2^32; they are searching for one *window* in 2^32, and the number of guesses needed is roughly 2^32 divided by the window size. A long-lived, high-throughput flow makes that worse in the attacker's favour, because such flows scale their windows up to keep the pipe full: a 1 MB window leaves about 4,096 in-window sequence values to try. At a modest packet rate that search finishes in seconds to minutes. Bigger windows are good for throughput and bad for this exact problem.

code

text · 9 lines
text
established flow, as seen from off-path
  four-tuple     198.51.100.2:?????  ->  203.0.113.7:179   (peer addrs public, local port unknown)
  RCV.NXT        unknown to the attacker
  RCV.WND        1,048,576 bytes    (large window, high-throughput long-lived link)
  ...
receiver's acceptance test (not an equality test)
  accept if      RCV.NXT <= seg.seq < RCV.NXT + RCV.WND
search size
  2^32 / RCV.WND = 4,294,967,296 / 1,048,576 = 4,096 in-window guesses

go deeper

for a junior

Remember the core fact: an arriving segment is judged against a range of acceptable sequence numbers, not against one exact value, and that range is the advertised receive window.

for a middle

Be able to do the division out loud - sequence space over window size - and explain why a high-throughput link advertises the large window that makes the number small.

for a senior

Show you can apply it to your own estate: which long-lived flows advertise large windows, which of them exchange little data and could safely advertise less, and what one accepted forgery would cost.

for a principal

Own the framing that a performance default was silently a security decision, and be ready to argue for differentiating window policy between bulk data paths and low-volume control sessions.

## The wrong answer this corrects A competent senior engineer will often say: "the sequence number is 32 bits, so an attacker who cannot see the flow would need billions of packets - it is infeasible." The arithmetic is right and the model is wrong. Nothing in TCP requires a forged segment to carry the exact next sequence number in order to be processed. ## What the receiver actually asks A receiver keeps two pieces of state that matter here: the next byte it expects, and the window it is currently advertising to the sender. An arriving segment is *acceptable* when its sequence number falls inside that window - roughly, when it is at or after the next expected byte and before the next expected byte plus the window size. Out-of-order but in-window segments are exactly what a real network produces all the time, so TCP has to accept them; that tolerance is not a bug, it is what keeps a reordering, retransmitting protocol working. The consequence for a blind attacker is direct: the target is not a point in the sequence space, it is an interval. ## The arithmetic If the window is W bytes and the sequence space is 2^32, then stepping through the space in strides of W covers every possible position of the window in about 2^32 / W guesses. - 16 KB window: about 262,144 guesses. - 256 KB window: about 16,384 guesses. - 1 MB window: about 4,096 guesses. - 16 MB window: about 256 guesses. Those are packet counts, not years. A few thousand small packets is a negligible burst that finishes in well under a minute at any ordinary sending rate. ## Why throughput makes it worse The windows at the top of that list are not hypothetical. A link with high bandwidth and appreciable delay only stays full if the receiver allows a large amount of unacknowledged data in flight, so long-lived bulk flows - a replication stream across a server fleet is the classic one - end up advertising very large windows precisely because they are fast. The property that makes the flow perform is the property that shrinks the attacker's search. High throughput and blind-injection resistance pull in opposite directions, and most estates have tuned hard for the first without ever pricing the second. ## What else has to be right The sequence guess is not the only requirement, and an honest answer says so: - The four-tuple must match. On a control session with a well-known port and published endpoint addresses, only the ephemeral port is genuinely unknown, and a narrow or predictable ephemeral range shrinks that too. - For a segment carrying data, the acknowledgement value must also be plausible, which adds a second search - though a coarse one, because acknowledgement acceptance is itself range-based. - For a teardown, no data semantics are needed at all, which is why disruption is the cheapest objective. So the full cost is the product of the searches that remain, and the point of the leaf stands: none of the individual searches is anywhere near 2^32 in practice. ## Why one hit is enough The search does not have to be repeated. A single accepted reset ends the session outright - the connection is gone and, on a peering session, the routes learned over it go with it. There is no partial credit and no need for persistence: the attacker fires guesses until one lands and then stops. ## What actually changes the arithmetic Making the sequence space effectively larger is not the lever; the lever is refusing to judge segments on position alone. - **Authenticating each segment** (a keyed integrity value carried with it) makes the guess worthless. The tuple and the sequence can be perfect and the segment is still discarded. - **Refusing segments from beyond an expected hop distance** removes the off-path attacker's reach rather than their arithmetic. - **Randomising the local ephemeral port** widens the one tuple field the attacker cannot look up. - **Advertising a modest window on low-volume control sessions** costs a peering session nothing - it exchanges very little data - and multiplies the sequence search by orders of magnitude. ## The sentence to be able to say Acceptance is judged against a range, not a value, so the size of that range - not the width of the sequence field - sets the cost of the attack.

  • Would shrinking the advertised window on a peering session be a real control or a token one?
    A real one, and unusually cheap. A peering session exchanges a trickle of updates and keepalives, so a small window costs it no throughput, while cutting the window from a megabyte to a few kilobytes multiplies the sequence search by a hundred or more. It is a genuine trade only on bulk flows, where the same change would hurt.
  • Does the attacker learn anything from a guess that lands in-window?
    Not directly - they are off-path and see no reply. What they observe is the effect: the session drops, or it does not. That is why disruption objectives suit this attack and precision objectives do not; success is visible only as an outcome, never as feedback on any individual guess.
  • Where does the acknowledgement number fit into the cost?
    A segment carrying data is checked against an acceptable acknowledgement range as well as the sequence window, so data injection needs two coarse searches rather than one. A teardown needs no plausible acknowledgement at all, which is a large part of why ending a session is cheaper than steering it.

saying these in an interview costs you the question

  • Says the attacker must guess the exact next sequence number
  • Quotes 2^32 as the search size without dividing by the window
  • Claims large windows are purely a performance concern
  • Thinks retransmission logic would reject an in-window forgery
  • Believes many hits are needed rather than one

context

resolving links…