Pages: p. 6
I quite enjoyed reading David Alan Grier's look back at the Morris worm in "The Benefits of Being Different" (In Our Time, Nov. 2006, pp. 6–8). But I fear he has picked the wrong culprit.
On 7 Nov. 1988, I was working for Digital Equipment and chairing the IEEE POSIX (UNIX) standards committee just getting ready to bring the gospel of standardization to the folks at BBN. They were running between offices, since, as Grier noted, e-mail was spreading the worm.
However, when I got back to DEC, its systems had not been affected.
The "finger" overflow compiled differently on the VAX, and the mail debug flag had been turned off in the most recent version of Ultrix (only a few months old at the time.) Clearly, there was an advantage to being different, but the major vendors were all still conforming to the same standards, the POSIX suite being the core.
The real risk is not standards, but clones. As with biological populations, survival can depend on differentiation, and clones are all susceptible to the same attack vectors. Those most concerned about the robust operation of their systems would be well advised to adopt standards so their applications are portable between systems. But they also should explicitly seek out compatible variations of the systems, dramatically reducing the probability of a total collapse.
Jim Isaak has identified a key phenomenon of the computer age, one that indeed played a role in the Internet worm of 1988. His solution has a great deal of merit and should be considered by anyone looking to build resistant and resilient systems
In 1988, several brands of workstations survived the attack because they ran variants of Unix and hence did not have the same weaknesses as the machines that were infected. I recall that the Apollo machines were resistant to attacks.
I would like to claim that my school had the foresight to run a different variant of Unix, but the story is much less profound. We had an IBM proprietary store-and-forward network, a technology that was completely immune to the Internet worm because it offered none of the TCP/IP services. The research faculty, including myself, had been trying for years to replace it with a standard Unix network connection. Had we been successful, we could easily have been one of the victims of the worm.
David Alan Grier
There is an error in the mathematical formulation of the server sizing problem described in "Mathematical Server Sizing" in Computer's July 2006 issue (IT Systems Perspectives, pp. 91–93).
This article states that arrival rate lambda equals load * requests per second. The arrival rate is not a function of server load. Therefore, lambda should just equal requests per second. The performance curve in Figure 3 that used the incorrect formulation is not correct either.
The figure provided here illustrates a valid performance curve.