RFC 1948 (rfc1948) - Page 2 of 6
Defending Against Sequence Number Attacks
Alternative Format: Original Text Document
RFC 1948 Sequence Number Attacks May 1996
Details of the Attack
In order to understand the particular case of sequence number
guessing, one must look at the 3-way handshake used in the TCP open
sequence [2]. Suppose client machine A wants to talk to rsh server
B. It sends the following message:
A->B: SYN, ISNa
That is, it sends a packet with the SYN ("synchronize sequence
number") bit set and an initial sequence number ISNa.
B replies with
B->A: SYN, ISNb, ACK(ISNa)
In addition to sending its own initial sequence number, it
acknowledges A's. Note that the actual numeric value ISNa must
appear in the message.
A concludes the handshake by sending
A->B: ACK(ISNb)
The initial sequence numbers are intended to be more or less random.
More precisely, RFC 793 specifies that the 32-bit counter be
incremented by 1 in the low-order position about every 4
microseconds. Instead, Berkeley-derived kernels increment it by a
constant every second, and by another constant for each new
connection. Thus, if you open a connection to a machine, you know to
a very high degree of confidence what sequence number it will use for
its next connection. And therein lies the attack.
The attacker X first opens a real connection to its target B -- say,
to the mail port or the TCP echo port. This gives ISNb. It then
impersonates A and sends
Ax->B: SYN, ISNx
where "Ax" denotes a packet sent by X pretending to be A.
B's response to X's original SYN (so to speak)
B->A: SYN, ISNb', ACK(ISNx)
Bellovin Informational