.if n .ds y +
.if n .ds z ++
.if t .ds y \(dg
.if t .ds z \(dd
.ds a ``An Introduction to the Berkeley Network''
.ds b ``Network System Manual''
.TL
The Berkeley Network \-
A Retrospective
.AU
Eric Schmidt
.AI
Computer Science Division
Department of Electrical Engineering and Computer Science
University of California, Berkeley
Berkeley, California 94720
.AB
The Berkeley Network connects a number of
.UX
machines on the Berkeley campus.
It provides facilities for file transfer, sending and reading mail,
and remote printing.
Operating in a batch mode, network requests are transferred one by one
through an inter-connected network until they reach their final destination.
.PP
This document describes the history and goals of this project,
the design decisions faced, discusses issues in portable software
development in networks, and discusses the future of this project.
.AE
.SH
.ce
Introduction
.sp .5
.PP
This document is intended for readers with an interest in networking
who are familiar with two other documents about the network,
\*a, and the \*b, by this author.
It is not necessary to read this document to set up and maintain the network,
although systems persons will benefit if they are familiar with the
concepts presented here.
.PP
The sections are presented as follows:
.DS
Principals
History
Overall System Description
Protocol Explanation
Portability
Security
Future Plans
Summary
.DE
.PP
The most important section is the last,
which details a set of principles the author
has learned during this project.
.SH
.ce
.sp 1
Principals
.sp .5
.PP
This project was a collaboration of many individuals.
Dr. Robert S. Fabry participated in the initial design
and has exerted the strongest influence on polishing the final product.
Bill Joy and Ed Gould provided valuable technical expertise every step of
the way, primarily about developing systems programs.
The support staff of the EECS Department and the Computer Center
(Bob Kridle, Jeff Schreibman, Vance Vaughan, Robyn Allsman, and Ricki Blau)
were involved in setting up and administering this multi-domain project.
The lowest-level concepts the author used came from experience
at \s-2XEROX PARC\s0, primarily from discussions
with David Boggs, one of the \s-2ETHERNET\s0\*y designers.
.FS
\*y ``Ethernet: Distributed Packet Switching for Local Computer Networks'', by Robert Metcalfe and David Boggs, CACM, July 1976.
.FE
.SH
.ce
.sp 1
History
.sp .5
.PP
The network project can be divided into two distinct phases.
The first, from January 1978 to May 1978 (4\(12 months)
involved designing and implementing the network facilities
now available.
The second, from October 1978 to March 1979 (5 months), saw the addition
of many more machines to the network with emphasis on
portability, security, and minor design changes.
The network has been in almost continuous service to users since May 1, 1978.
.SH
First Phase
.PP
An initial design was worked out with Dr. Fabry in January 1978.
A suitable connection was made between the Computer Center ``A'' and ``Q''
machines (then called ``D'').
.DS
.cs R 24
   
   
   A                  Q
   
   
.cs R
.DE
.PP
Development proceeded on two fronts \-
a set of daemons were written to transfer files, using
.UX
pipes for debugging.
The lowest-level protocols were designed and implemented of the terminal-type
connection between A and Q.
These were debugged using simple programs to send and receive packets,
and a pair
of programs to transfer a file from one to the other.
This was the first experience with a distributed software development \-
the Q machine is a DEC PDP-11/34 with no lineprinter, a non-standard
tape drive, and terminal access only by telephone, so
most development had to proceed on the A machine.
.PP
During this phase the goals of the project increased in scope.
The implementor and only user had to use the network to transfer
network source and worked out simple ways to automate this
(the ``.netrc'' file is an example).
.PP
When it appeared usable by more than the implementor,
the connection was changed to be between A and the Computer Center ``C''
machine:
.DS
.cs R 24
  
  
   A                  C
  
  
.cs R
.DE
.PP
Up until now, the network had required an account on both machines.
It became clear this was a handicap since
the A machine had too many accounts and the password file was immense.
Certain ``free'' commands were allowed, without an account.
.PP
The Cory machine was soon added to the network:
.DS
.cs R 24
  
  
  Cory                 A                  C
  
  
.cs R
.DE
.PP
This produced major changes in the design \-
initially we had assumed network users would have accounts on all machines.
This was unreasonably strict
and a solution (kludge) was worked out where a request was
examined and forwarded through the queue(s) on the intermediate machine.
The network became table-driven
to accomplish the routing, and distributed software
development became more difficult because of the increased number of machines.
The implementor quickly discovered only one solution:
Always have a designated source machine for all changes.
To this day, software changes are made only on this ``source'' machine,
the others are guaranteed to have copies.
This makes remote updating (copying new versions around the network)
possible.
.PP
Documentation was written and sent off to about fifteen
faculty, staff, and graduate student users.
A few bugs were fixed and the system frozen from the end
of May to October.
End of Phase 1.
.SH
Second Phase
.PP
While the implementor was away at a summer job, the connection between
the A and C machines was switched to reduce the loading on the A machine:
.DS
.cs R 24
  
  
  Cory                 C                  A
  
  
.cs R
.DE
.PP
Unknown to the implementor, the network source was modified in
divergent and incompatible ways, and the commands were moved to a different
place.
These changes invalidated certain assumptions about full pathnames and
some commands such as inter-machine mail stopped working.
.PP
The Computer Center had also made absolutely incompatible changes
to some system calls.
This began a path of software divergence that became very painful
and is still not completely solved.
.PP
Fortunately, the Computer Center placed Robyn Allsman in charge of maintaining
the network on their machines \-
to lighten that routine part of the load from the implementor.
.PP
The Computer Center acquired a ``D'' machine, and the EECS Division
a DEC VAX 11/780, running an experimental Version 7
.UX
system.
The implementor decided to use the (at this point) unused VAX
to to do software development and incorporate the Version 7
changes into the network code.
By this time, the protocols were stable which made it possible
to run a Version 7 network
on the VAX connected to the old Version 6 code
on the existing network, to facilitate debugging.
Because of improved terminal availability and better machine
response, many new ways were used to debug the network \-
using pipes, using TTY lines wired together on the VAX and over the
usual machine-to-machine link.
A file was added (``initfile'') which allowed quick reconfiguration
of the daemons when system parameters were changed.
A temporary connection between the VAX and C machines was arranged.
.DS
.cs R 24
                      
                      
                      VAX
                      
                      
                         
                         
                         
                         
  
  
  Cory                 C                  A


.cs R
.DE
.PP
The network code had to be able to run on three different types of
machines \-
the VAX running
.UX
Version 7, the Cory machine running Version 6, and the anomalous
Computer Center machines.
There was no conversion package available at the time,\*y
.FS
\*y The ``retrofit'' library, by Bill Joy, is now available.
.FE
and the old network code had not used any system header
files, so after a great deal of experimentation, conditional
compilation was used as much as possible and a procedural interface
was used to elide system differences.
.PP
The new
.UX
command
.I make
(I) was used with a ``makefile'' to organize this regime.
The old network code was used to bootstrap
the D machine onto a network running the new network code exclusively.
.DS
.cs R 24
                      
                      
                      VAX  
                      
                      
                         
                         
                         
                         
 
 
  Cory                 C                  A
 
 
                        
                        
                        
                        
                     
                     
                       D
                     
 
.cs R
.DE
.PP
Shortly thereafter, over the Christmas break, the VAX and Cory connections
went down for security reasons (discussed in the ``Security'' section).
After seven weeks, they reentered the network in a new configuration.
.DS
.cs R 24
 
 
  Cory                 C                  D
 
 
    
    
    
    
 
 
  VAX                  A   
 
  

.cs R
.tr --
.DE
.PP
Shortly after that, they were down again because of a lightning strike
for another week but have been operational since then.
During the last time period the network was made less Berkeley-specific
and a copy was run on the Rand Corporation UNIX machines.
Documentation was rewritten and prepared for release.
The network queues were converted to send shortest-job first.
Extensive monitoring of system load, network performance,
and network use was added.
The format of the
.I netq
command was changed to summarize more information on output.
The E machine, and then later the Survey Research Center (SRC)
machine, were added.
.DS
.cs R 24
                     
                     
                       A
                     
                     
                        
                        
                        
                        
 
 
  Cory                 C                  D
 
 
    
    
    
    
 
 
  VAX                  E                 SRC
 
 
.cs R
.DE
.PP
Tuning was still important \-
serious overloading problems caused by sluggish response
stopped the network between Cory and C for a week.
Network parameters were tuned to help solve this problem.
The complexity of software development and maintenance became too
great for unstructured changes.
Versions on all the machines except the VAX were frozen
for a month at a time.
The protocols were almost immutable.
People were delegated responsibility to observe and straighten
out, if necessary, problems with the net queues.
.PP
As this is written, the software is stable and the
user-documentation is finished and being sold,
and there is hope of adding more
.UX
machines to the network.
.SH
.ce
.sp 1
Overall System Description
.sp .5
.PP
The Berkeley network operates in a batch/ request mode, and is similar
in concept to a line printer queue.
``Requests'' are queued up at the source, where they are sent in shortest
job first order through an interconnected network of machines to
their destination.
At each intermediate node, they are queued as if they were originated locally.
.PP
The network consists of a set of user-executed commands,
a queue of requests to be sent, and a continuously-running
program called a
.I daemon
which transmits requests in the queue and listens for any request being sent
to it.
There are many network commands \-
one to send mail, one to read mail, one to copy files, etc.
They all use the
.I net
command to access the network.
The
.I net
command takes a command, assorted parameters, with any input
data, and puts a request in the queue.
These requests are composed of a header, the command to be executed,
and any data for input to the command.
The header contains network information such
as the destination machine, login name, and password.
This request is stored in the queue as a normal ASCII
file, owned by the invoker.
This way
.UX
commands can be used to examine the file.
.PP
The daemon examines the queue to see if there is anything to send.
If so, it begins sending to a remote daemon,
using a protocol to establish this dialog,
involving retransmissions and timeouts.
The remote daemon accepts the requests,
parses the header information, and takes any
data for the command and puts it in a file.
The main loop of the daemon then returns to a waiting state.
.PP
The command execution is done by `forking' a series of processes.
One of these is the user's login shell,
which is given the command to execute.
Another is a process which waits for the command
to be executed, then examines the output of the command.
The output is typically sent back to the user, via a
.I net
command, executed by the daemon.
.PP
In the reverse transmission, the command is called ``mwrite'',
and it is routed and handled exactly as in the forward mode,
except no password is required.
The ``mwrite'' command is executed on the original machine
with input data which is a copy of the output of
the remote command.
The user is either ``written'' or ``mailed'' to,
depending on certain options.
If ``written'', the user's screen is filled with the output\*y
.FS
\*y Standard output and standard error files.
.FE
of the command executed remotely, just as if he had executed it locally.
Otherwise, it is in his mailbox, as mail from the remote account he used.
The user's terminal must be write-able (see the
.I mesg
(I) option), the originating user must still be logged in,
and he must not have logged off and on again.
.PP
The output from the command is preceded by a line of information
listing the command, the time it was sent, and the time elapsed.
.PP
Our design then tries to simulate local
.UX
commands as much as possible.
With defaults set correctly\*y
.FS
\*y With a ``.netrc'' file, see below.
.FE
the user in principle need only precede the command he is executing
with the command
.I net.
.SH
Copying Remote Files
.PP
The most frequent use of the network is file-transfer using the
.I netcp
command.
The
.I netcp
command is based on the
.I cp
(I) command.
Its two arguments are a source and destination file, optionally with
remote machine names prepended:
.DS
\fBnetcp\fI\ \ from\-file\ \ to\-file\fR
.DE
where the names are local or remote.
Since
.DS
Cory:/usr/pascal/sh
.DE
is a file on the Cory machine,
.DS
% netcp\ \ junk\ \ Cory:/usr/pascal/sh
.DE
will transfer the file ``junk'' to the named file on the Cory machine\*z.
.FS
\*z For more examples, see the \*a document.
.FE
.PP
The way the transfer is accomplished depends on the type of file copy:
.IP 1.
Copy local file to remote file \-
.br
On the remote machine a
.I cat
(I) command is executed on the remote file with the local
file as standard input.
.IP 2.
Copy remote file to local file \-
.br
A
.I cat
command is executed on the remote machine from the remote file
to standard output.
This standard output is sent back to the local machine
into a
.I
response file,
.R
instead of being written or mailed to the user.
.IP 3.
Copy remote file to another remote file \-
.br
If both are on the same machine, a
.I cp
command is sent.
Otherwise, a
.I netcp
command is sent to the remote machine where the
.I from\-file
exists,
to copy that file to the \fIto\-file\fP's machine.
.PP
This last case is experimental.
Unfortunately, the system is structured only to carry one login
name and password to a remote machine.
Since the last option involves three machines,
the second remote machine is handled imperfectly at best.
.SH
Sending Mail
.PP
The
.I mail
(I) command on the network machines has been modified to examine the names of
the recipients of a particular message.
If their names have a remote prefix,
.I mail
executes an internal command ``sendmail'',
which in turn executes a
.I net
command.
This net command sends a mail command to the remote machine,
with the message as input.
Since the recipient would like to know which machine
the message came from, a simple program ``mmail''
is executed to insert a pseudo-header indicating the real
source of the mail.
The net command logs in as user ``network'',
so remote mail does not require an account on the destination machine.
This facility has proven invaluable.
.SH
Reading Mail
.PP
The
.I netmail
command uses the
.I net
command to send a command to read mail for a specified user
on a remote machine.
Since the existing mail programs on different machines vary in their
options, it was decided the only thing that would work on both
.UX
Version 6 and 7 systems was to copy the mail from the remote
to the local machine.
If the user subsequently logs in on the remote machine,
his mail will be there, as if it were unread.
An internal program ``prmail'' is used to copy the user's mail
back to the local machine.
It knows the location of the mailboxes and the user's name.
.PP
The mail programs at Berkeley are being modified to search a database
to see whether a user would like to receive all his mail on
another machine and automatically forward it.
This will diminish the need for the
.I netmail
command.
.SH
Printing on remote lineprinters
.PP
The
.I netlpr
command takes a list of arguments as files to be printed on a remote
lineprinter.
Unfortunately, there can only be one standard input file for the remote
command, so each file is sent as a
.I net
command executing the command
.I lpr.
.SH
Other System Components
.sp .5
.LP
The ``.netrc'' file.
.PP
A user must specify defaults for frequently repeated options
on a per-machine basis.
This is done in a file ``.netrc'' in the user's login directory,
and is fully described in the \*a.
.sp .5
.LP
The
.I netq
command.
.PP
To see the network queue, the user must type the
.I netq
command.
It lists the queue for each directly-connected machine, in the order
requests will be sent.
Each request is listed, one per line, giving
the local and remote machines, the destination machine, the time sent,
and the command to be executed.
Commands which are internal to the network are called ``responses''
in the
.I netq
listing.
.sp .5
.LP
The
.I netrm
command.
.PP
Requests may be removed from the send queue using the
.I netrm
command.
Since the originator of the file owns the queue file, a simple user-id
check suffices to validate permission.
Unfortunately, this notion breaks down for queue files
of requests on intermediate machines.
On such a machine an appropriate user does not exist,
and the files are owned by ``root''.
There is an option to
.I netrm
to remove all the user's queue files, to make
.I netrm
easier to use.
.sp .5
.LP
The
.I netlog
command and other information.
.PP
A number of log files are kept by the network.
Users may execute a
.I netlog
command which prints the last few entries of a log of commands
sent and received.
Also listed is the user, the time of the entry,
and the return code of the command.
.PP
A more unreadable logfile is `/usr/net/plogfile?'.
This log file has all the information of
.I netlog,
in a more cryptic form, along with trace information
about net errors.
The beginning and ending of sending and receiving are noted.
This way the exact state of the network can be determined.
.PP
Hourly and daily statistics in a file `/usr/net/netstat?'.
The number of bytes transmitted, the number of commands, and a
breakdown of their type, and system load is recorded.
This information is recorded in both hourly and daily form
to track the performance of the network under different system loads.
.PP
Every hour, a
.I netq
command is executed and the number of queue entries is recorded in a
file `/usr/net/netqstats'.
This gives an estimate of the queue length.
.PP
Finally, the login names of each local user are recorded
in a file `/usr/net/usernames'.
Periodically, these names are sorted and duplicates removed.
This gives a complete listing of network users,
useful for sending network-specific mail and for general interest.
.SH
.sp 1
.ce
Protocol Explanation
.sp .5
.PP
The network uses three distinct levels of protocol.
The highest level of protocol (the ``command'' protocol)
refers to the organization of the information sent to the remote
machine.
An intermediate level splits such a stream into distinct numbered packets
with a small header in each packet.
The lowest level refers to the appearance of these packets on the hardware
connection.
At the present, this is a modified 6-bit ASCII code.
Each of these layers is distinct, and presents the
interface through procedure calls.
.SH
The Command Protocol
.PP
Each machine sends a request using a precise command protocol
involving a header, the command, and any associated data.
.TS
center allbox;
l l l l.
length	header	command	... data ...
.TE
All but the length field is formatted by the
.I net
command before the file is queued for transmission.
The length is used to detect abnormally short, and
poorly-formed, requests.
The header includes all the information to route and verify the
request.
It includes
.RS
.IP a)
the origin and destination machines,
.IP b)
the login names on both machines,
.IP c)
a version stamp for this command protocol,
.IP d)
the time sent,
.IP e)
information about the originating terminal, and
.IP f)
the pseudo-command.
.RE
.PP
The pseudo-command is read by
.I netq,
and instead of printing the actual command being
executed, prints something more appropriate.
All the commands which use
.I net
(e.g.
.I netcp)
use the pseudo-command to list themselves rather
than the command they are executing on the remote machine.
.PP
In order to be able to print the data on a normal
.UX
terminal for debugging, the fields within the header are variable-length ASCII,
separated by colons (`:').
This forces the daemon to parse the header information and
requires that literal colons (e.g. in the command being sent)
be properly escaped within the protocol,
but I felt the alternatives of using byte counts or fixed-length fields
were too difficult to debug.
The shortest header is approximately 85 bytes.
Fortunately, this means the shortest command
will fit into a single packet.\*y
.FS
\*y (less than 100 bytes, see below).
.FE
.SH
The Packet Protocol
.PP
The above information is conveyed to each machine as a stream.
This is done using subroutine calls to read and write data
of arbitrary length over the link.
The write procedure breaks the information into a set
of numbered packets,
with a length and exclusive-or check-sum in a header:
.TS
center allbox;
l l l l l.
length	seqnum	type	chksum	... data ...
.TE
.PP
The length, type and checksum are one byte each,
and the sequence number is two bytes.
Since the packets are variable length the checksum is in the
header rather than at the end of the packet to avoid the extra computation
required to access it.
.PP
Each packet is transmitted over a link to a listener.
Normally an acknowledgement packet is sent back.
If there is an error, nothing is sent back,
and the sending end will retransmit after a certain number of seconds.
.PP
There are no windowing or piggyback acknowledgements for two reasons:
1) this scheme is very simple to implement and
2) the error rate if each packet were not acknowledged would be
high because of the hardware involved.
If the future, I hope that both hardware and kernel device drivers
will allow this improvement.
.PP
The so-called ``rendezvous'' protocol, whereby two daemons agree to communicate,
is a simple ``contention'' scheme.
When one daemon wants to transmit,
it sends a special packet ``reset'' to the possible receiver,
then transmits his first packet.
Normally a daemon able to receive listens for a ``reset''.
If it receives one, it enters a section of code designed
to receive a header command, and data, and ultimately will execute it.
If not, after a prescribed time interval is checks to see if there are any
requests to send.
Should both send at once, the characters may be garbled,
or both may receive resets at the same time.
In each case they both will retransmit.
Each has a randomizing factor to break any ties which might develop.
.PP
In retrospect, this protocol is very primitive.
Now that the network is in production use,
the extra acknowledgements and separate ``reset'' are too
expensive.
A redesign would modify the protocol to transmit
more than one packet before acknowledging it (ACKs),
use negative ACKs to indicate immediately that an error has occurred,
and eliminate the separate ``reset'' entirely.
.PP
The ``rendezvous'' protocol consumes a fair amount of time
when both daemons choose to send packets.
The alternative of constantly sending status packets when
the daemons would be idle was never seriously considered
because it was felt that the daemon should have as light a system
load as possible; it seems now the daemons are busy most of the time
and thus the initial connection tradeoffs
should have been studied more closely.
.SH
The Low-Level Protocol
.PP
The network transmits over TTY lines through terminal interfaces
and system drivers which behave as if the characters coming from another
machine are from a terminal.
This mode was chosen because it is absolutely the simplest,
cheapest interconnection scheme possible.
Unfortunately, the
.UX
terminal drivers cannot accept 8-bit bytes unless they are in
.I raw
mode.
This was judged to be a high system load, so the
TTY lines operate in
.I cooked,
the reverse of
.I raw,
mode.
In this mode certain bit combinations,
e.g. ASCII newline and escape, do not
transmit through the terminal driver to the user's program
but rather are interpreted as control information.
.PP
After much experimentation, the following transmission method was chosen.
Each 3 byte triple is viewed as 24 bits, and broken into 4 6-bit groups.
Each 6-bit number is in the range 0-63, and is added to a constant
representing the lowest acceptable character code (a blank)
in the ASCII sequence.
This is sent as an ASCII character to a receiver
who gathers 4 bytes, subtracts the increment, and shifts the 4 6-bit groups
into 3 bytes.
This represents a 3 to 4 expansion of all characters over the
link, or a 33% loss of bandwidth.
.PP
In retrospect, this expansion has a considerable cost.
The most scarce resource in the network
is the actual hardware speed of the links.
The alternative of using raw mode was never seriously considered.
.PP
The implementor's hope is that better hardware will make better
middle- and lower-level protocols easier.
Until then, the difficulties of using TTY lines efficiently
make further protocol improvements unlikely to yield big increases in speed.
.SH
A Note About Features this Protocol Lacks
.PP
In
.UX
a process may only read or write one I/O device at a time.
A daemon approach requires a single process reading and writing on a link to
another machine.
This process must decide who will receive this packet.
I judged (correctly) that this decision was hard to schedule using
.UX
pipes and signals,
and only allow one kind of communication between daemons.
This also makes it almost impossible
to forward packets through intermediate machines.
Thus intermediate machines copy whole requests before sending them again.
.PP
If the design specification required a simple packet-oriented driver
within the system, the
.UX
kernel could decide which of several special files this was destined to,
and allow much more intermixing of traffic than before.
I did not realize the importance of this and, in retrospect,
would have chosen the other of the two approaches.
.SH
.sp 1
.ce
Portability
.sp .5
.PP
The acquisition of VAX/UNIX (Version 7) and the divergence of the Computer
Center and Cory Hall Version 6 systems made the portability of the
network source code important.
Until then, the source code on all machines was identical.
Fortunately, the
.UX
implementors encountered these same problems and developed a number of
facilities the network now uses.
.PP
Since many system calls use machine and version dependent data fields,
so-called ``include'' files are available to hide the system differences
and help standardize the system interface.
The conditional compilation feature of the C language was used to select
which kinds of code to generate, when the ``include'' files were
not sufficient.
Roughly, the following command included at the beginning of each C module:
.DS
# include <whoami.h>
.DE
would define which system, by name, the code was run on.
For example, the above defines ``VAX'' on the VAX machine,
and then lines such as
.DS
# ifdef VAX
 .
 .
# endif
.DE
control the code generated.
In the network, sequences such as this in turn define other sequences,
such as
.DS
# ifdef \s-2CORY\s0
# define \s-2FUID\s0
# define \s-2OLDTTY\s0
# define \s-2PASSWDF\s0
# endif
.DE
defines the unusual features of the Cory machine:
the combined user-id and group-id returned by the
.I getuid()
system call, that it uses the old 1-character terminal names, and
that it has a split password file for security reasons.
Each of these symbols, e.g. ``FUID'', is tested
in order to compile the correct code for that feature.
.PP
To help in isolating the changes, attempts were made to create a procedural
interface to hide machines differences.
These procedures are all in one file.
Only one or two cases exist of conditional sections of code
not in ``mach.c'' or ``mach.h'', its header file.
.PP
One problem these features pose is testing changes \-
the conditional sections hide errors in inapplicable code.
A regimen was adopted:
Testing was first done on the VAX (Version 7),
then, after it was stable for a few days,
moved to Cory, where typically there was some Version 6-dependent
error, and after that was fixed and stable, it was moved to the
Computer Center machines.
This notion of a ``testing'' machine is very important \-
the VAX always has an up-to-date copy of the network
source, even though other machines may lag in improvements.
.PP
There is now a ``retrofit library''
that simulates many of the features ``mach.c'' provides.
It was not stable enough when the network was converted to Version 7,
otherwise I would have used it.
.PP
At this point, when the entire source for the software
for the network is transferred between machines only the first five
lines of the ``makefile'' need be changed.
.SH
.sp 1
.ce
.sp .5
Security
.PP
Over Christmas vacation of 1978, a 15-year old high school student
repeatedly broke into the Computer Center and Cory machines.
He was able to use the network to gain access to privileged files on
the VAX, and the fear of protection ``holes'' caused the staff to take
the network down for seven weeks.
.PP
There were two security problems posed by the network:
.RS
.IP 1.
The threat to the ``root'' account on another system.
.IP 2.
The threat to a user's remote accounts.
.RE
.NH 0
Threat to ``root''
.PP
Originally the network would allow a user logged in as ``root''
on one machine to execute any command as ``root'' on another network
machine.
As far as we know, this feature was never used to break into a system.
However, the network has been changed to prevent a user from logging
in as ``root'' on another machine, regardless of the password.
This check is performed on the sending machine.
Since ``root'' could conceivably circumvent this check by altering
the command, the receiving end of a command checks the user-id
of all commands being executed.
If it is zero (i.e. ``root'') only a set of five commands is allowed,
all needed by the network internally, and believed ``safe''.
.PP
We believe this makes the network ``safer'' than many local machine
features such as the use of dial-up lines.
.NH
Threat to user's remote accounts.
.PP
If a user places remote passwords in his ``.netrc'' file,
an illicit superuser could get the password to all the user's remote
accounts.
Even if the user does not care, system managers dislike this because
the illicit superuser could now use a legal account on another system
to break into it.
.PP
We have no good solutions to this.
Users are now warned of this danger in the documentation,
and a ``.netrc'' file with passwords must be
readable only by the owner of the file.
.PP
Various solutions have been proposed:
.RS
.IP a)
Disallow passwords in ``.netrc'' files.
.br
Unfortunately, heavy network users would have to repeatedly
type their password.
.IP b)
Encrypt the ``.netrc'' file.
.br
A program would have to exist to decrypt the file.
A superuser could get access to whatever key technique that program used,
if it were on the local machine.
A public-key encryption scheme would make this option possible.
We decided it was too much work to implement this.
.IP c)
Once-a-session passwords.
.br
In this scheme, a user would register his password when he logged in,
then use the network without needing to type in a password.
When he logged off, the password would be removed.
We discarded this because we could not guarantee the password would
disappear unless we wrote a daemon, which itself could be compromised.
The best solution along this line uses the ``alias'' feature
of the C shell.
Each net command is aliased with itself and the
\fB\-l\fP, \fB\-p\fP options.
When the user logs in,
he sets a shell variable to his password.
When he logs off, his shell dies and the passwords are forgotten.
.RE
.PP
I believe the current alternatives are sufficient for a conscientious
user to protect himself and still have an easy-to-use network interface.
.SH
.sp 1
.ce
Future Plans
.sp .5
.NH 0
Hardware
.PP
The net has suffered with low speed hardware.
Short-term plans include speeding up the current terminal
interface hardware from 1200 Baud to 9600 Baud and writing a driver
for the device to bypass the internal
.UX
character queues.
This driver will improve the reliability of transmission and decrease the character
interrupt overhead.
The speedup from 1200 Baud to 9600 Baud may overload the systems due
to the number of hardware interrupts it causes.
.PP
In the longer term, the EECS Department is considering acquiring
direct-memory-access (DMA) devices such as the Logical Network Interface (LNI)
or the Digital Corp. DMC-11 links for high-speed transmission.
These devices are capable of over 1-megabit speeds, and
would increase the speed of the current network by factors of hundreds.
.NH
Adding More Machines to the Network
.PP
The \s-2INGRES\s0 Research group and various other research units within
the EECS department have expressed interest in being added to the network.
.NH
Remote Use of the Typesetter Facilities
.PP
The Computer Center A machine has a Graphics Systems phototypesetter
and the VAX Research machine has a Versatec 36'' dot-matrix plotter
with a
.I troff
simulator.
Software now being debugged will allow remote use of the typesetter
by running the
.I troff
program locally and sending the typesetter device codes to the remote
machine.
.PP
This will distribute the typesetting load and help overloading on
the A and VAX machines.
It will also allow the use of
.I troff
macro packages only available on some machines.
.NH
Remote Mail Forwarding
.PP
The
.UX
mail programs will be modified to forward mail to another account on another
machine, allowing a user with accounts on many machines to read it all on one
designated machine.
.SH
.sp 1
.ce
Summary Points
.sp .5
.PP
The author would like to stress these points about his experience:
.IP 1.
Success in building networking software depends on having ready access
to the correct hardware.
The minimum is two terminals connected to two usable machines with two
magnetic tape drives or some other existing means of software transfer.
.IP 2.
Design in portability and security.
More careful attention to machine dependence and security
in the first phase would have saved much later re-programming.
.IP 3.
Develop good local debugging techniques.
The ``self-loop'' trick for network debugging depends on the accuracy
of that simulation.
.UX
pipes, for example, were not sufficient to simulate TTY lines
because TTY lines are 7-bits with a restricted ASCII range.
.IP 4.
Encourage users to use the system.
Their feed back is important.
However, it is necessary to have an unused network link for new
protocol development, etc.
.IP 5.
There is a fine line between support of an existing network and research.
In the best of all possible worlds, support of research-developed
software would be the responsibility of the systems staff
for the machines it runs on.
This is seldom the case.
.IP 6.
The concept of layers of networks was very helpful in this project.
There appear to be these levels:
.DS L
.ce 99
.ls 2
.sp 2
user interface
queues and daemons
command protocol
packet protocol
transmission protocol
teletype lines
.sp 2
.ls 1
.ce 0
.DE
These levels are quite distinct.
If a new, better network not involving queues is built, the transfer of files
could still be by
.I netcp.
If state-of-the-art link hardware is used, perhaps all of the levels
below the command protocol could be discarded.
.IP 7.
The chief virtue of the current system is its extreme flexibility
and low start-up costs.
No modifications to the
.UX
kernel are required and all local features are conditionally
specified in a header file.
.IP 8.
Networks are hard to build because
.RS
.IP a)
They involve mutually-cooperating copies of software on (usually)
differing computers.
.IP b)
Many options are not practical because of compatibility considerations \-
new networks need drivers in unchangeable systems, and new protocols have to
accept the old protocols until the old protocols are extinct.
.RE