RFC 1948 (rfc1948) - Page 2 of 6

Defending Against Sequence Number Attacks

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