Subject: Re: Calculations of ISN for new TCP sessions

From: Vernon Schryver <[email-masked]>
Date: Fri, 15 Sep 2000 22:28:41 -0600 (MDT)

> From: Satish Mynam <[email-masked]>
> To: [email-masked]

> I was just wondering about many of the TCP implementations are using
> a random number generator for the Initial Sequence Number(ISN)
> generation for the new TCP connections.  Most of the implementations
> (in the past) have been using the clock value in micro seconds to
> generate the ISN.  

How do you figure "most implementations" were doing that or similar?
It's awfully hard to make any statement about "most TCP implementations."

Some code I wrote at a previous employer did something like that but
somewhat better...when the hardware had microsecond or nanosecond
resolution.

Judging from customers using bogus test packages, RFC 1948 support is 
a global checklist item, which is to say that anyone who wants to
compete supports RFC 1948.

I say those test packages are bogus because they detect situations where
initial sequence #'s are predictable on high speed LAN's but unpredictable
in situations where initial sequence number predicting is a real threat
(i.e. WAN's).  I also do not believe they detect all predictable sequence
numbers in situations where it is a valid concern.  For example, if you
have bad guys on your LAN's, you ought to worry about cleartext passwords
for telnet, ftp, rlogin, and most Microsoft protocols first.

My realism/cynicism is moot, because many people use the tests or
RFC 1948 support as checklist items.

> ...
> Personally I feel, ...

S. Bellovin's discussion of the issues in RFC 1948 is good, except that
his discussion of the costs of MD5 hashing are dated.  CPU's are fast
enough that the cost of MD5 rarely matters.
I don't agree that MD5 hashes of secrets are always required....not
that he says that, but that's what the test authors tell their customers.

Vernon Schryver    [email-masked]

---

From: Alan Cox <[email-masked]>
Date: Sat, 16 Sep 2000 10:26:31 +0100 (BST)

> that he says that, but that's what the test authors tell their customers.

Im not a cryptographer but Im being told MD5 should not be used by people
who are, and that people have found MD5 weaknesses that are not (yet) apparent
in SHA

Are people still using MD5 ?

Alan

---

From: Andi Kleen <[email-masked]>
Date: Sat, 16 Sep 2000 19:56:01 +0200

> that he says that, but that's what the test authors tell their customers.

There are much easier ways to attack the ISN computation in most OS
anyways than attacking MD5:  you attack the secret generation.

On diskless devices you can usually just find out the initial secret because 
they have no easy way to restore the entry pool of the random generator from 
disk. Unless the vendors implemented a hardware random generator the secret
should be not too hard to guess.

[The rest of the discussion is primarily about Linux's /dev/random device
because I know its implementation, but I believe similar issues apply to
/dev/random equivalents on other OS] 

On many non diskless systems the entropy pool of /dev/random is restored from
disk _after_ the first TCP connection, which makes similar guesses possible 
[Linux fetches the secret for the first few minutes on the first connection]

The amount of entropy gathered during bootup is usually very small and rather 
predictible (unless the users moves the mouse, which is usually not the case 
on a firewall in a rack). 

The only source of randomness before the random pool is restored are the
CPU time stamp measurements of the ide disk interrupt. Although there are
some variances you can make some good guesses of the end result when
the disk/hardware configuration is known (e.g. the case with many
ready configured "firewall appliances" or just using the default OS 
installation of the vendor) 

Even when the bug of doing TCP before the entropy pool restoring is fixed
there are still some vunerabilities, because many firewalls etc. do never
any disk io (assuming a separate log server) and never get keyboard/mouse 
input. This means that the entropy pool stays pretty constant over time
and the window of vunerability after boot time extends over the whole uptime.

As soon as you can guess the entropy pool you can guess the secret and
attacking the ISN is trivial.

-Andi