Summary
- RFC 1948 described a blind attacker who sampled one legitimate connection, forged a trusted host's address and predicted the server's next TCP initial sequence number to finish a handshake whose reply the attacker never saw.
- Its fix was structured unpredictability: retain the time-driven number
Mfor repeated incarnations of one connection, add a secret-derived offsetFfor each four-tuple, and deny an observer a useful line from one connection's numbers to another's.
The thief's first move was perfectly ordinary: open a TCP connection and note the server's starting number. In the attack described by RFC 1948 in May 1996, that observation helped guess the starting number of the server's next connection. The thief then forged the IP address of a host the server trusted. The server's answer went to the real trusted host, out of the thief's sight. With a good guess and that host kept quiet, the thief could send the final acknowledgment anyway. An address-based remote-command service might then treat the intruder's packets as the trusted host's.
The point of the attack was the relationship between two conversations. The legitimate probe gave the attacker one initial sequence number, or ISN. Berkeley-derived TCP implementations described in RFC 1948 advanced their ISN by predictable increments over time and by new connection. The forged conversation needed another ISN. If the second could be inferred from the first, the attacker could complete a handshake without watching the server's reply. The server had a lock on the door; it had been announcing the next combination to anyone willing to ask politely at a different door.
The obvious repair, throw random numbers at every new connection, made the engineers pause. TCP's original RFC 793 used a progressing initial-number clock so an old packet from an earlier incarnation of the same connection would not look fresh when that connection reopened. RFC 1948 also pointed to TIME-WAIT handling in BSD-derived systems. Separate conversations needed unrelated starting positions; repeated incarnations of one conversation still needed forward motion. Security and old-packet hygiene wanted different things from the same 32-bit field.
RFC 1948 made room for both. A TCP connection is identified by four pieces: local IP address, local port, remote IP address and remote port. For each four-tuple, the proposal set the initial number to M + F(four-tuple). M was the progressing timer. F was a secret-dependent function of the connection's identity. Two different four-tuples therefore started on separate number tracks, while a repeated use of one four-tuple inherited the timer's progress. The attacker could inspect one track and still lack the offset for the other.
The function had to resist outside calculation. RFC 1948 suggested a cryptographic hash over the four-tuple and secret material, with MD5 as its then-available example. Its discussion included random secret material, a host secret, boot time and machine identity. The exact composition mattered because an observable or easily guessed F would put the next-door combination back in the thief's pocket. The proposal avoided storing a permanent record of every closed connection just to keep different tracks apart.
There was a second price hidden in the key ring. Changing the secret while a machine ran would move the starting track for a connection that reopened with the same four-tuple. RFC 1948 therefore tied a live secret change to either preserving dead-connection state or observing a quiet period of two maximum segment lifetimes. The secret was useful because it made tracks hard to relate; changing it carelessly could disturb the old-packet spacing that M was meant to preserve. A better lock still had to respect the building's fire doors.
The later RFC 6528, published in 2012, took this design to Standards Track, obsoleted RFC 1948 and updated RFC 793. It specified the four-tuple and secret key as inputs to a pseudorandom function, kept the M + F structure, and discussed key length and rotation. The historical move remained the same: make the next connection's starting line depend on the connection's identity and a hidden value, while time continues to carry repeated connections forward.
In the 1996 attack, a sample from the server was useful because the server's next answer was predictable across conversations. RFC 1948 took away that cross-door map. The thief could still knock on one door and read its ticket. The next door's roll began somewhere else, and the offset stayed behind the counter.
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance





