From owner-freebsd-questions  Tue Apr 11 07:23:10 1995
Return-Path: questions-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id HAA20522
          for questions-outgoing; Tue, 11 Apr 1995 07:23:10 -0700
Received: from grapenuts.bellcore.com (grapenuts.bellcore.com [192.4.4.35])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id HAA20515
          for <questions@freebsd.org>; Tue, 11 Apr 1995 07:23:05 -0700
Received: from localhost (localhost [127.0.0.1]) by grapenuts.bellcore.com (8.6.9/8.6.9) with SMTP id KAA22536; Tue, 11 Apr 1995 10:21:16 -0400
Message-Id: <199504111421.KAA22536@grapenuts.bellcore.com>
X-Authentication-Warning: grapenuts.bellcore.com: Host localhost didn't use HELO protocol
From: Andrew Heybey <ath@bellcore.com>
To: Brian Smith <brians@protools.com>
cc: questions@FreeBSD.org
Subject: Re: Does BSD implement TCP/IP incorrectly? 
In-reply-to: Your message of Mon, 10 Apr 1995 10:32:15 -0700.
             <9504101732.AA16157@dot.protools.com> 
Date: Tue, 11 Apr 1995 10:21:15 -0400
Sender: questions-owner@FreeBSD.org
Precedence: bulk

The problem with the BSD implementation of TCP is the method by which it
chooses the initial sequence number for a TCP connection.  RFC793
specifies that:

  When new connections are created,
  an initial sequence number (ISN) generator is employed which selects a
  new 32 bit ISN.  The generator is bound to a (possibly fictitious) 32
  bit clock whose low order bit is incremented roughly every 4
  microseconds.

What BSD does is increment the "clock" (the variable tcp_iss) at the
correct rate (well, half the correct rate) but with a granularity of
PR_SLOWHZ--twice a second.  That is, it bumps tcp_iss by 64000 every
time the slow timeout happens.

The problem with the BSD method is that it makes it relatively easy to
predict what the initial sequence number of a new connection to a
particular host will be.  The IP spoofing attack is greatly simplified
by this weakness.  If you can guess the initial sequence number used,
it is possible to "half-way" open a TCP connection to a host without
ever receiving any packets back from the host.  (By "half-way" I mean
that you can send data down the connection but not get anything back.)
So the attacker can put the IP address of a trusted host in the source
field, open such a connection (to say the rexec port) and send
something down the connection to facilitate further attacks.

andrew