The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: TCP-IP Distribution List - Archives (1983)
DOCUMENT: TCP-IP Distribution List for April 1983 (17 messages, 13713 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1983/04.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 1983 0916-PST
From:      Postel@isif
To:        Ata.SysMaint at RADC-MULTICS
Cc:        tcp-ip at SRI-NIC, jslove at MIT-MULTICS
Subject:   Simultaneous Opens
John:

Why does NSW depend on doing a simultaneous open?

--jon.
-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 1983 00:00 EST
From:      TCP-IP@Brl.ARPA
To:        TCP-IP@Brl.ARPA
Subject:   TCP-IP Digest, Vol 2 #3
TCP/IP Digest             Tuesday, 12 Apr 1983     Volume 2 : Issue 3

Today's Topics:
                              VDH on UNIX?
                    TCP/IP for UNIX on an LSI-11/23?
                 TCP/IP on 68000 running UNIX System III
                         XNS:  A Real Standard?
----------------------------------------------------------------------
                  TCP/IP Digest --- The InterNet Digest
                         LIMITED DISTRIBUTION
          For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------

Date:     25 Mar 83 00:28:41 EST  (Fri)
From: Mark Weiser <mark.umcp-cs@Udel-Relay.ARPA>
Subject:  VDH on Unix.
To: tcp-ip@Brl.ARPA, dan@Sri-Tsc.ARPA

I inquired about this a long time ago, to all the mailing lists I could
think of including Unix-Wizards and Info-Vax.  The silence was deafening.
An ECC from ACC is the only way to go.  (Two of these boxes at either
end of a transmission line of arbitrary length make each end think it
is talking a LH/DH protocol.)

[ Actually, one alternative to consider is an HDH (HDLC Distant Host)
  connection to the IMP.  ACC has a UNIBUS interface for HDH, and
  Rob Gurwitz of BBN is reported to be building a driver.  HDH uses
  the same type of access lines as VDH did (synchronous modems),
  and is less expensive than ECUs.  As HDH is still brand new, there
  may be some bugs left to find for a little while.  -Mike ]

------------------------------

Date:     Thu, 7 Apr 83 17:53:45 CST
From: Paul.Milazzo <milazzo.rice@Rand-Relay.ARPA>
Subject:  TCP/IP for UNIX LSI-11/23
To: TCP-IP@Brl.ARPA

Does anyone know of a TCP/IP implementation which will run under UNIX
V7 or 2.xBSD on an LSI-11/23?  The machine will be used as a network
print server on a 10Mb Ethernet using a specialized user-level
protocol, so no protocol software is necessary, although some flavor of
FTP would be nice during the development phase.

				Paul Milazzo
				Dept. of Mathematical Sciences
				Rice University, Houston, TX

[ The only PDP-11 UNIX implementations I know of fit only into split-I/D
  PDP-11s, although the MIT-CSR one might fit, as might the early
  "all in user code" TCP implementations.  -Mike ]

------------------------------

Date: 30 Mar 83 11:31:04 PST (Wed)
From: UCBVAX@Ucb-Vax.ARPA
Subject: tcp on 68000's
To: tcp-ip@Brl.ARPA

Unisoft has ported the UCB IP/TCP code to UNIX System III running on
various incarnations of the 68000.  The kernel code running now is derived,
in truth, from the Croft port of 4.1a+ to the pdp-11.  User programs
running now are rcp, rlogin, and mail -- based on "delivermail".

Buffer-to- buffer performance to date:

	Ethernet, 3com multibus controllers, 2 8-mhz "Sun"-type cpu boards,
	on-board memory (no wait-states).

	With Checksums		580,000+ bits/sec.
	Without Checksums	680,000+ bits/sec.

Future plans:  Merge in UCB 4.1c/4.2 kernel changes; bring up arpa standard
ftp, telnet, mail;  Bring up various random hacks such as rwho, etc.

We have experienced no "stuttering", a recent complaint about this code when
it runs on the 11 -- but of course we aren't on the Arpanet (sigh).

This code will be available to all oem's of Unisoft, some of which include
Wicat, Codata, Dual, Pixel, Callan, Corvus, Cosmos, CYB, Heurikon, Ampex,
Microbar, Megadata, Momentum, NCR, Pacific Micro, Victory, Xyvision.  Sun
Microsystems is an oem of Unisoft also; rumor has it that they have
some networking software of their own.

Whether any of these companies choose to make this code available to their
customers is up to the companies.

Bill Northlich
Unisoft Corp.
2405 Fourth Street
Berkeley, Ca. 94710
(415) 644-1230
TWX II (910)366-2145
ucbvax!unisoft!billn

------------------------------

Date:     12 Apr 83 2:11:22 EST (Tue)
From:     Mike Muuss (TCP-IP Digest)  <tcp-ip@BRL-VGR>
To:       tcp-ip at BRL-VGR
Subject:  XNS:  A Real Standard?

Recently, a very good question was raised about XNS,
Xerox's new network protocol:

	"Is XNS becoming the commercial [network] standard?"

Two statements about this question were made that bear repeating
(published by permission):

Chris Kent <CAK@Purdue> said:

	"XNS may well become a standard for Ethernet based networks;
	 what happens when you want to talk to someone else?"

Chris Ryland <CPR@MIT-XX> said:

	"Yes, it does appear that XNS is gaining the momentum needed
	 to become a true standard (vs. a paper standard).  I say this
	 because there are a lot of companies offering or about to offer
	 XNS-based networks (Network Research, ACC, 3Com, Bridge, are
	 a few)."

I would like to see a discussion of:

1)  the technical merits of XNS -vs- TCP/IP, and
2)  some speculation on their futures in the commercial arena

in future issues of the TCP Digest ("The INTERNET Digest").

				Best,
				 -Mike
------------------------------
END OF TCP-IP DIGEST
********************

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 1983 00:00 EST
From:      TCP-IP@Brl.ARPA
To:        TCP-IP@Brl.ARPA
Subject:   TCP-IP Digest, Vol 2 #4
TCP/IP Digest           Wednesday, 20 Apr 1983     Volume 2 : Issue 4

Today's Topics:
                          TCP/IP -vs- Xerox NS
                         Merging Protocol Sets?
                     MIT-CSR TCP/IP on non-I/D UNIX
                    3Com UNET on non-I/D UNIX systems
                   BBN TCP/IP on non-I/D UNIX systems
                         DEC Equipment & TCP/IP
----------------------------------------------------------------------
                  TCP/IP Digest --- The InterNet Digest
                         LIMITED DISTRIBUTION
          For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------

Date: Tue, 12 Apr 83 10:34 PST
From: Taft.PA@parc-maxc.arpa
Subject: TCP/IP vs Xerox NS
To: TCP-IP@brl.arpa

Let me suggest that there is not much point in engaging in a "TCP vs.
NS" debate, since there's far more to discuss than can reasonably be
presented in this forum.  People who want more information about NS
would be better served by reading the open literature (references below)
and forming their own judgements.

The Xerox NS family of protocols are a re-engineered version of the Pup
protocols.  NS and Pup are true internet protocols, architecturally very
similar to TCP/IP.  This is not accidental, as there was considerable
cross-fertilization between the Xerox and ARPA internet projects.

Of course, there are also many differences.  Some are a reflection of
differing technical judgements made by the designers, while others are
of no significance.  But the fundamental similarities are far more
important than the detailed differences.

So why is Xerox pushing NS rather than TCP/IP?  Well, why do similar but
incompatible products appear in any marketplace?  Xerox has a big
investment in NS, and had to make product plans based on it long before
TCP/IP had solidified to its present form.  NS is not really "new".
Though the protocol specifications were published only a little over a
year ago, NS has been around for several years, and its predecessor,
Pup, has been in active use since 1975.

	Ed Taft


References (there are many others; these are the ones that come
immediately to mind):

D. R. Boggs, J. F. Shoch, E. A. Taft, R. M. Metcalfe, "Pup: an
internetwork architecture", IEEE Transactions on Communication, vol.
COM-28, no. 4, April 1980.  (This was a special issue on network
architectures and protocols; it contains many interesting papers.)

Y. K. Dalal, "Use of multiple networks in the Xerox Network System",
IEEE Computer magazine, 15(10), October 1982.

J. E. White, Y. K. Dalal, "Higher-level protocols enhance Ethernet",
Electronic Design, 30(8), April 1982.

------------------------------

Date: 12 Apr 1983 0823-PST
Subject: TCP/IP vs. XNS
From:  Dan <LYNCH@Usc-Isib.ARPA>
To: tcp-ip@Brl.ARPA

ISI has decided to purchase a bunch of Xerox 8010 workstations
and will be implementing TCP/IP on them in the next 6 months.
We will be in a position to comment on the relative merits
of each protocol suite after we have our TCP/IP implementation 
running.  The first task we face is to figure out where to make
the cut.  We will have enough access to the low level drivers 
to be able to make the cut anywhere we choose, but we are not
sure that is the best way to "merge" the functionality of
these two "similar" protocols.  The whole insanity of "layered"
protocols becomes quite apparent when one considers what we are
about to delve into -- one from culumn A and one from column B
and then two from column A, etc???
Dan Lynch

------------------------------

Date: 12 Apr 1983 1026-EST (Tuesday)
From: lwa@Mit-Csr.ARPA
Subject: Re: Paul Milazzo's TCP request
To: TCP-IP@Brl.ARPA

Our TCP/IP implementation is running on one LSI-11/23 that I know
of.  It's pretty tight, though, and certain pieces (like the
Internet reassembly code) had to be omitted.  It's going to
take some amount of work on the part of whoever brings it up
to get it to fit.

Regarding the earlier user-only implementations (eg. BBN's): we
actually had the BBN implementation running on an 11/40 at one
point, but there were only three disk buffers left, so it wasn't
very useful...
					regards,
					Larry

------------------------------

Date: 12-Apr-83 10:32:43-EST
From: gc@Bnl.ARPA
Subject: TCP/IP for nonsplit I/D systems
To: milazzo.rice@Rand-Relay.ARPA
Cc: tcp-ip@Brl.ARPA

We are currently running the 3Com Unet implementation of TCP/IP on a v7
system on an 11/44, however there are installation directions in our manual
for installing on non-split I/D systems and on BSD 2.8 systems also.
From our experience, it might be a tight fit but probably worth a try.

------------------------------

Date: 12 Apr 1983 0943-PST
From: DEDWARDS@Usc-Isi.ARPA
Subject: re' TCP/IP for UNIX LSI-11/23
To:   milazzo.rice@Rand-Relay.ARPA
cc:   tcp-ip@Brl.ARPA

As it turns out I am running TCP/IP on my 11/34 and 11/23 - this
is the external to the kernel version done at BBN several years ago.
The underlying UNIX is a BBN version 6, but it should be movable
to V7.  It does require that you have portions of the old NCP
buffering mechanism installed though, so you do need to have
room to add stuff to your kernel (also needs Rand ports, await/
capac, pty, etc).  With only a couple of users and full memory,
the 11/34 does pretty well on the ARPAnet - the 11/23 is somewhat
slower.

Howard Weiss
DoD Computer Security Center

------------------------------

From:     smb%mhb5b@brl-bmd
Date:     13 Apr 83 11:26:51 EST  (Wed)
Subject:  TCP/IP for UNIX LSI-11/23
To:       unc!milazzo.rice@Rand-Relay.ARPA, unc!tcp-ip@brl-bmd.arpa
Full-Name: Steven M. Bellovin

I'm pretty sure that 3Com's UNET will run on 11/23s, under either v7 or 2.8BSD.
A source license is about $5000, I believe.

------------------------------

Date: 14 Apr 83 20:51:19 PST (Thu)
From: unisoft!billn@Ucb-Vax.ARPA
Subject: tcp on 11/23
To: milazzo.rice@Rand-Relay.ARPA
Cc: tcp-ip@Brl.ARPA

UNET from 3com runs on an 11/23.  At least they say so; I've never tried it.
I suspect it does, since they developed much of UNET on 11/23's.  There are
alot of options you can turn off to get sizes down in user programs. Kernel
size is a bit of a problem, but solvable, using the kernel overlay scheme
("kov's") from Ken Harrenstein (klh@sri-nic)  The new version (UNET 2.0) is
reputed to be up-to-date arpa compatable, including smtp.  They include,
naturally, a driver for their q-bus ethernet controller.

/bill

------------------------------

Date: 23 Nov 1982 1653-PST
Subject: DEC equipment and IP/TCP
From: Joel Goldberger <JGoldberger@USC-ISIB>
To: TCP-IP@BRL

I can tell you what the situation is regarding IP/TCP implementations on
most DEC equipment.  There are basically four operating systems that
people run on DEC 10/20's and two operating systems that are run on
Vaxes.

On the 10/20's people are running:
	TOPS-10
	TENEX
	TOPS-20
	and ITS (The MIT Incompatible Timesharing System)

BBN has had an implementation of IP/TCP for TENEX and TOPS-20 for some time
and that is what we are running.  Very few other sites were willing to run
this software though.  DEC proposed a much cleaner user-interface to TCP for
TOPS-20 that most of the TOPS-20 sites decided to wait for.  This code was
originally scheduled to be made available to ISI at the beginning of July,
since then the date has been slipping.  Monday the person working on it at
DEC (Kevin Paetzold) announced over the TOPS-20 distribution list that he
would be making the code available on 1 December.  Obviously once the code
is delivered there will be some lag before the support software gets written
and debugged, and I seriously doubt that all of that can be accomplished in
the one month before the switchover.

I don't believe that anything besides the present BBN implementation of
IP/TCP will ever be available for TENEX systems, and most of the TENEXes on
the Network already have this code up and running.  There is some work
needed to make the support programs run under TENEX, but I believe Henry
Miller at NIC is doing this.

Ken Harrenstein has been (re-)hired by MIT to implement IP/TCP on the ITS
machines (MIT-AI/DM/ML/MC).  I believe he is already back at MIT doing this.

I know of no implementation for TOPS-10 (or WAITS), either available or in
development.


On VAXes people mostly run either VMS or UNIX (primarily Berkeley UNIX).

For VMS there are two implementations available:

Digital Technology Incorporated offers a comercial product called ACCESS-T
in a Binary only distribution that includes all the usual servers and user
programs (FTP/TELNET/SMTP), as well as a library of user callable routines
for establishing and controlling IP and TCP connections.  We ordered this
product for our VMS system and were given a very early Beta-Test version
that was essentially unusable (It crashed VMS every time a TELNET connection
was closed).  They did some debugging on our system and fixed most of the
problems, but we still chose not to run it for the time being.  This
decision was mostly due to the way they had implemented MAIL; sending and
receiving were two disjoint programs and there was no way to REPLY or
FORWARD messages conveniently.  They have just announced a new version of
their software that will run under version 3.0 of VMS; The previous release
would not.  We will be evaluating this latest version when we bring up
version 3.0 on our VAX.

David Kashtan at SRI has been working on porting the Berkeley 4.1aBsd (UNIX)
implementation of IP/TCP to run under the EUNICE UNIX compatibility package
that he authored and SRI distributes.  (We are currently running his ported
version of the Berkeley NCP code on our VAX.)  I received a message from him
on Friday (19 November) that he had succeeded in bringing up IP/TCP, and was
now running his VAX (SRI-IU) with both NCP and TCP.  We will be getting a
copy of his code in the next week or so and hope to use that on our VMS
system.  I assume he will make it available to anyone who wants it.

Under Berkeley UNIX there are also two choices:

BBN (Rob Gurwitz) has an implementation for Berkeley 4.1Bsd which many sites
are running (including us).  It comes complete with user and server
processes, source code, and again a library of user-callable routines for
establishing connections.  We have found it to be very stable and Rob is
very good about bug-fixes and general support.  I don't know if he plans on
offering an implementation for Berkeley's future releases.

Berkeley (Bill Joy) essentially re-wrote the BBN implementation for 
Berkeley 4.1aBsd, and the soon to be released 4.2 Bsd.  We have been running
this version on VAX 11/750's connected to a 10MBit EtherNet and have found
it also very stable.  4.1a & 4.2 include a set of network utilities that
allow access to remote file-systems and remote command execution, features
not directly available with the BBN implementation.

I hope this has been of some help to you.

- Joel Goldberger -

------------------------------

END OF TCP-IP DIGEST
********************

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 1983 16:06:15-PST
From:      stanonik@NPRDC
To:        tcp-ip@sri-nic
Subject:   security and ftp
This might not be news to some of you, but it was news to us.
If you have login commands such as "who" and your ftp server
accepts "who" as passwordless user, then any normally readable
file can be ftp'ed away; eg, the password file.  

Ron Stanonik
stanonik@nprdc
-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 Apr 83 07:57:42 PST
From:      estell at nwc-387b
To:        tcp-ip at sri-nic
Subject:   Protection of Password File
The following message is yet another example of the axiom that no system
is immune to penetration.

May I suggest a pair of fixes; they don't make the system immune either,
but they do raise the level of resistance.

 (1) Do NOT allow the password file (among others) to be "normally readable"
     by just any user; require some privileges for that.

 (2) Use so-called "one way" encryption on the password file; i.e., scramble
     the bits, actually throwing away some of them in the process, so that
     there is no way back.
     CAUTION: Be careful with such an algorithm; you want to preserve as much
     of a unique mapping as possible; i.e., you want to avoid a situation
     where dozens of raw passwords encrypt to the same file entry.

Regards,
Bob
--------------------------------------------------------
From:	stanonik 20-APR-1983 22:12:40  
To:	ESTELL
Subj:	(Network Mail)
 
Return-Path: <@SRI-NIC:stanonik@NPRDC> 
Mail-From: SRI-NIC received by nwc-387b at 20-Apr-83 22:12:33-PST 
Received: from NPRDC by SRI-NIC at 20-Apr-83 1623-PST
Date: 20 Apr 1983 16:06:15-PST
From: stanonik@NPRDC
To: tcp-ip@sri-nic
Subject: security and ftp

This might not be news to some of you, but it was news to us.
If you have login commands such as "who" and your ftp server
accepts "who" as passwordless user, then any normally readable
file can be ftp'ed away; eg, the password file.  

Ron Stanonik
stanonik@nprdc
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 1983 at 1120-CST
From:      Bill Lee <lee@utexas-11.arpa>
To:        estell@nwc-387b
Cc:        tcp-ip@sri-nic
Subject:   Reply to: protection of password file
The "fix" is not to make the password file unreadable. The problem
is that a ftp server allows someone to log in as who without specifying
a password. If this is allowed, then any readable file can be whisked
away. The ftp server should require a password (unless it allows a
restricted anonymous account) and it shouldn't allow a system account
to log in (such as who, uucp, or root).

By the way, the Unix password file uses a modified DES algorithm to
encrypt the password. It is reasonable safe even if someone did manage
to ftp it away (NSA notwithstanding) assuming that the users choose
passwords that don't show up in your on-line dictionary.


-------
-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 83 13:31:49 PST (Thu)
To:        dee@CCA-UNIX
Cc:        tcp-ip@sri-nic, estell@nwc-387b
Subject:   Re: Protection of Password File
In the 4.1cBSD and later systems, the ftp server deals with this
several ways.  First, the only account allowed to have no
password is the "ftp" or "anonymous" account.  This is easily
done by always asking for and checking a non-null password except if the
USER name is exactly "ftp" or "anonymous".  The other problem is
logins with well-known passwords, like UUCP.  The solution there
is to check a file listing the "personae non grata" who aren't allowed
FTP login under any circumstances.  Most sites pu at least "root" and "uucp"
in this list.  Finally, after logging in with "anonymous", the
server does a "chroot()" to fence the person in.  This actually introduces
some other problems which can be solved by careful creation of subdirectories
and control of file modes.  (These details are discussed in installation
documents.)  I leave it as an exercise for the reader.
	-Mike
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Thursday, 21 Apr 1983 13:57-PST
From:      greep at SU-DSN
To:        tcp-ip at SRI-NIC
Subject:   Re: Protection of Password File
1. Some sites (e.g. UDEL-EE) give a positive acknowledgement to VRFY
regardless of the argument (except that they fail to give any reply
at all for the null argument, but that appears to be a bug).

2. Anyone who wants to find out some valid user names for a given site
has only to look through the Arpanet direcoory.

3. I think the discussion about encryption of password files has reached
the point where it doesn't have much to do with SMTP any more and suggest
it be dropped or moved to unix-wizards.
-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      21 April 1983 11:50 est
From:      Kovalcik.Multics at MIT-MULTICS
To:        estell at NWC-387B
Cc:        tcp-ip at SRI-NIC
Subject:   Re: Protection of Password File
No system is immune from penetration?  Please stop putting your foot in
your mouth.  Try breaking into a Honeywell Multics system sometime. You
will die of old age before you succeed.

The problem with cheap rip-off systems like Unix (TM) is that they try
to do things the easy way too often.  (Yes, I am saying that most of the
ideas in Unix were ripped-off from Multics.)  If you are going to learn
from something, you should follow all the lessons presented by that
thing / program / product / system / whatever, not just those it is
convenient to follow.

                              Rick Kovalcik
                              Multics System Development
                              Cambridge Information Systems Laboratory
                              Honeywell Information Systems
                              575 Tech Square
                              Cambridge, MA   02139
-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 1983 11:52:23-EST
From:      dee at CCA-UNIX (Donald Eastlake)
To:        estell at nwc-387b
Cc:        tcp-ip at sri-nic
Subject:   Re: Protection of Password File
In response to your message of Thu Apr 21 11:15:17 1983:

Assuming this was a UNIX password file, the passwords are already
one-way encrypted but there is a lot of other information in the
password file that wants to be generally readable.  Some systems move
the one-way encrypted info to a different and protected file foranother
level of security.

Seems to me that you don't want to let people log into FTP with random
non-password names (on our system they only work from local termnnals
anyway) except for some explicit anonymous login in feature that you
understand.  I suspect the password file in readable through the
deliberate anonymous login feature on may UNIX systems anyway.  It is
not that different from implementing a "finger" server which many
machines have.  Decisions on these things depend on judgements
concerning what needs to be private, etc.

						Donald Eastlake
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      21-Apr-83 16:07 PST
From:      WBD.TYM@OFFICE-3
To:        Kovalcik.Multics@MIT-MULTICS
Cc:        estell@NWC-387B, tcp-ip@SRI-NIC
Subject:   Re: Protection of Password File
You mean that Multics hasn't been broken into by either ZARF or the DOD's tiger 
teams?  --Bi<<

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      21 April 1983 13:44 EST
From:      Christopher C. Stacy <CSTACY @ MIT-MC>
To:        estell @ NWC-387B
Cc:        tcp-ip @ SRI-NIC

It is a feature that Unix password files have encrypted passwords,
and that they are ok to make publicly readable.  What you want to
do is specify (in the passwd file, I think) that the WHO account
should get a dedicated shell.  Write a program which (for example)
runs the FINGER or WHO program and then logs out.

Alternatively, flush the WHO account and install a network
FINGER server on your machine (unless local users need the WHO account).

Chris

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 1983 13:46:57 EST (Thursday)
From:      Dennis Rockwell <drockwel@BBN-UNIX>
To:        dee@CCA-UNIX (Donald Eastlake)
Cc:        estell@nwc-387b, tcp-ip at sri-nic, drockwel@BBN-UNIX
Subject:   Re: Protection of Password File
One additional security problem shows up with an SMTP server:
UNIX deliberately asks for a password when it gets
an invalid name so that a potential breaker doesn't know
when a valid username is entered;  however, the SMTP VRFY
command can be used to circumvent this rather easily.
VRFY is not included in the "minimum implementation",
but RCPT is, and can be usdd in the same manner.

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      21 April 1983 16:55 EST
From:      David C. Plummer <DCP @ MIT-MC>
To:        lee @ UTEXAS-11
Cc:        tcp-ip @ SRI-NIC, estell @ NWC-387B
Subject:   Reply to: protection of password file
Hey folks, this is UNIX your talking about, not TCP-IP.  Care to
move it to a more appropriate mailing list?

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Fri Apr 22 06:26:17 1983
From:      TCP-IP@Brl.ARPA
To:        fa.tcp-ip
Subject:   TCP-IP Digest, Vol 2 #4


TCP/IP Digest           Wednesday, 20 Apr 1983     Volume 2 : Issue 4

Today's Topics:
                          TCP/IP -vs- Xerox NS
                         Merging Protocol Sets?
                     MIT-CSR TCP/IP on non-I/D UNIX
                    3Com UNET on non-I/D UNIX systems
                   BBN TCP/IP on non-I/D UNIX systems
                         DEC Equipment & TCP/IP
----------------------------------------------------------------------
                  TCP/IP Digest --- The InterNet Digest
                         LIMITED DISTRIBUTION
          For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------

Date: Tue, 12 Apr 83 10:34 PST
From: Taft.PA@parc-maxc.arpa
Subject: TCP/IP vs Xerox NS
To: TCP-IP@brl.arpa

Let me suggest that there is not much point in engaging in a "TCP vs.
NS" debate, since there's far more to discuss than can reasonably be
presented in this forum.  People who want more information about NS
would be better served by reading the open literature (references below)
and forming their own judgements.

The Xerox NS family of protocols are a re-engineered version of the Pup
protocols.  NS and Pup are true internet protocols, architecturally very
similar to TCP/IP.  This is not accidental, as there was considerable
cross-fertilization between the Xerox and ARPA internet projects.

Of course, there are also many differences.  Some are a reflection of
differing technical judgements made by the designers, while others are
of no significance.  But the fundamental similarities are far more
important than the detailed differences.

So why is Xerox pushing NS rather than TCP/IP?  Well, why do similar but
incompatible products appear in any marketplace?  Xerox has a big
investment in NS, and had to make product plans based on it long before
TCP/IP had solidified to its present form.  NS is not really "new".
Though the protocol specifications were published only a little over a
year ago, NS has been around for several years, and its predecessor,
Pup, has been in active use since 1975.

	Ed Taft


References (there are many others; these are the ones that come
immediately to mind):

D. R. Boggs, J. F. Shoch, E. A. Taft, R. M. Metcalfe, "Pup: an
internetwork architecture", IEEE Transactions on Communication, vol.
COM-28, no. 4, April 1980.  (This was a special issue on network
architectures and protocols; it contains many interesting papers.)

Y. K. Dalal, "Use of multiple networks in the Xerox Network System",
IEEE Computer magazine, 15(10), October 1982.

J. E. White, Y. K. Dalal, "Higher-level protocols enhance Ethernet",
Electronic Design, 30(8), April 1982.

------------------------------

Date: 12 Apr 1983 0823-PST
Subject: TCP/IP vs. XNS
From:  Dan <LYNCH@Usc-Isib.ARPA>
To: tcp-ip@Brl.ARPA

ISI has decided to purchase a bunch of Xerox 8010 workstations
and will be implementing TCP/IP on them in the next 6 months.
We will be in a position to comment on the relative merits
of each protocol suite after we have our TCP/IP implementation
running.  The first task we face is to figure out where to make
the cut.  We will have enough access to the low level drivers
to be able to make the cut anywhere we choose, but we are not
sure that is the best way to "merge" the functionality of
these two "similar" protocols.  The whole insanity of "layered"
protocols becomes quite apparent when one considers what we are
about to delve into -- one from culumn A and one from column B
and then two from column A, etc???
Dan Lynch

------------------------------

Date: 12 Apr 1983 1026-EST (Tuesday)
From: lwa@Mit-Csr.ARPA
Subject: Re: Paul Milazzo's TCP request
To: TCP-IP@Brl.ARPA

Our TCP/IP implementation is running on one LSI-11/23 that I know
of.  It's pretty tight, though, and certain pieces (like the
Internet reassembly code) had to be omitted.  It's going to
take some amount of work on the part of whoever brings it up
to get it to fit.

Regarding the earlier user-only implementations (eg. BBN's): we
actually had the BBN implementation running on an 11/40 at one
point, but there were only three disk buffers left, so it wasn't
very useful...
					regards,
					Larry

------------------------------

Date: 12-Apr-83 10:32:43-EST
From: gc@Bnl.ARPA
Subject: TCP/IP for nonsplit I/D systems
To: milazzo.rice@Rand-Relay.ARPA
Cc: tcp-ip@Brl.ARPA

We are currently running the 3Com Unet implementation of TCP/IP on a v7
system on an 11/44, however there are installation directions in our manual
for installing on non-split I/D systems and on BSD 2.8 systems also.
>From our experience, it might be a tight fit but probably worth a try.

------------------------------

Date: 12 Apr 1983 0943-PST
From: DEDWARDS@Usc-Isi.ARPA
Subject: re' TCP/IP for UNIX LSI-11/23
To:   milazzo.rice@Rand-Relay.ARPA
cc:   tcp-ip@Brl.ARPA

As it turns out I am running TCP/IP on my 11/34 and 11/23 - this
is the external to the kernel version done at BBN several years ago.
The underlying UNIX is a BBN version 6, but it should be movable
to V7.  It does require that you have portions of the old NCP
buffering mechanism installed though, so you do need to have
room to add stuff to your kernel (also needs Rand ports, await/
capac, pty, etc).  With only a couple of users and full memory,
the 11/34 does pretty well on the ARPAnet - the 11/23 is somewhat
slower.

Howard Weiss
DoD Computer Security Center

------------------------------

From:     smb%mhb5b@brl-bmd
Date:     13 Apr 83 11:26:51 EST  (Wed)
Subject:  TCP/IP for UNIX LSI-11/23
To:       unc!milazzo.rice@Rand-Relay.ARPA, unc!tcp-ip@brl-bmd.arpa
Full-Name: Steven M. Bellovin

I'm pretty sure that 3Com's UNET will run on 11/23s, under either v7 or 2.8BSD.
A source license is about $5000, I believe.

------------------------------

Date: 14 Apr 83 20:51:19 PST (Thu)
From: unisoft!billn@Ucb-Vax.ARPA
Subject: tcp on 11/23
To: milazzo.rice@Rand-Relay.ARPA
Cc: tcp-ip@Brl.ARPA

UNET from 3com runs on an 11/23.  At least they say so; I've never tried it.
I suspect it does, since they developed much of UNET on 11/23's.  There are
alot of options you can turn off to get sizes down in user programs. Kernel
size is a bit of a problem, but solvable, using the kernel overlay scheme
("kov's") from Ken Harrenstein (klh@sri-nic)  The new version (UNET 2.0) is
reputed to be up-to-date arpa compatable, including smtp.  They include,
naturally, a driver for their q-bus ethernet controller.

/bill

------------------------------

Date: 23 Nov 1982 1653-PST
Subject: DEC equipment and IP/TCP
From: Joel Goldberger <JGoldberger@USC-ISIB>
To: TCP-IP@BRL

I can tell you what the situation is regarding IP/TCP implementations on
most DEC equipment.  There are basically four operating systems that
people run on DEC 10/20's and two operating systems that are run on
Vaxes.

On the 10/20's people are running:
	TOPS-10
	TENEX
	TOPS-20
	and ITS (The MIT Incompatible Timesharing System)

BBN has had an implementation of IP/TCP for TENEX and TOPS-20 for some time
and that is what we are running.  Very few other sites were willing to run
this software though.  DEC proposed a much cleaner user-interface to TCP for
TOPS-20 that most of the TOPS-20 sites decided to wait for.  This code was
originally scheduled to be made available to ISI at the beginning of July,
since then the date has been slipping.  Monday the person working on it at
DEC (Kevin Paetzold) announced over the TOPS-20 distribution list that he
would be making the code available on 1 December.  Obviously once the code
is delivered there will be some lag before the support software gets written
and debugged, and I seriously doubt that all of that can be accomplished in
the one month before the switchover.

I don't believe that anything besides the present BBN implementation of
IP/TCP will ever be available for TENEX systems, and most of the TENEXes on
the Network already have this code up and running.  There is some work
needed to make the support programs run under TENEX, but I believe Henry
Miller at NIC is doing this.

Ken Harrenstein has been (re-)hired by MIT to implement IP/TCP on the ITS
machines (MIT-AI/DM/ML/MC).  I believe he is already back at MIT doing this.

I know of no implementation for TOPS-10 (or WAITS), either available or in
development.


On VAXes people mostly run either VMS or UNIX (primarily Berkeley UNIX).

For VMS there are two implementations available:

Digital Technology Incorporated offers a comercial product called ACCESS-T
in a Binary only distribution that includes all the usual servers and user
programs (FTP/TELNET/SMTP), as well as a library of user callable routines
for establishing and controlling IP and TCP connections.  We ordered this
product for our VMS system and were given a very early Beta-Test version
that was essentially unusable (It crashed VMS every time a TELNET connection
was closed).  They did some debugging on our system and fixed most of the
problems, but we still chose not to run it for the time being.  This
decision was mostly due to the way they had implemented MAIL; sending and
receiving were two disjoint programs and there was no way to REPLY or
FORWARD messages conveniently.  They have just announced a new version of
their software that will run under version 3.0 of VMS; The previous release
would not.  We will be evaluating this latest version when we bring up
version 3.0 on our VAX.

David Kashtan at SRI has been working on porting the Berkeley 4.1aBsd (UNIX)
implementation of IP/TCP to run under the EUNICE UNIX compatibility package
that he authored and SRI distributes.  (We are currently running his ported
version of the Berkeley NCP code on our VAX.)  I received a message from him
on Friday (19 November) that he had succeeded in bringing up IP/TCP, and was
now running his VAX (SRI-IU) with both NCP and TCP.  We will be getting a
copy of his code in the next week or so and hope to use that on our VMS
system.  I assume he will make it available to anyone who wants it.

Under Berkeley UNIX there are also two choices:

BBN (Rob Gurwitz) has an implementation for Berkeley 4.1Bsd which many sites
are running (including us).  It comes complete with user and server
processes, source code, and again a library of user-callable routines for
establishing connections.  We have found it to be very stable and Rob is
very good about bug-fixes and general support.  I don't know if he plans on
offering an implementation for Berkeley's future releases.

Berkeley (Bill Joy) essentially re-wrote the BBN implementation for
Berkeley 4.1aBsd, and the soon to be released 4.2 Bsd.  We have been running
this version on VAX 11/750's connected to a 10MBit EtherNet and have found
it also very stable.  4.1a & 4.2 include a set of network utilities that
allow access to remote file-systems and remote command execution, features
not directly available with the BBN implementation.

I hope this has been of some help to you.

- Joel Goldberger -

------------------------------

END OF TCP-IP DIGEST
********************

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 1983 08:42:15-EST
From:      Christopher A Kent <cak@purdue.ARPA>
To:        CSTACY@MIT-MC
Cc:        estell@NWC-387B, tcp-ip@SRI-NIC
I have to second Chris's comments. It would be a terrible lose to have
the Unix password file read-protected against general use.

As to his second point (installing a network finger), I have just such
a program for BBN TCP/IP hosts, and am about to convert it to run under
4.1c. Anyone interested is welcome to a copy (and periodic updates).

Cheers,
chris
-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 1983 00:00 EST
From:      TCP-IP@Brl.ARPA
To:        TCP-IP@Brl.ARPA
Subject:   TCP-IP Digest, Vol 2 #5
TCP/IP Digest           Wednesday, 26 Apr 1983     Volume 2 : Issue 5

Today's Topics:
                      The Purpose of the TCP-Digest
                     More on VAX/VMS TCP/IP Software
                 Tidbits from the latest DDN-Newsletter
----------------------------------------------------------------------
                  TCP/IP Digest --- The InterNet Digest
                         LIMITED DISTRIBUTION
          For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------

Date:     20 Apr 83 22:03:22 EST (Wed)
From:     Mike Muuss <mike@brl-vgr>
To:       tcp-ip at brl-vgr
Subject:  The Purpose of the TCP-Digest

Just in case you were wondering what this is all about...

	The TCP Digest is a moderated network mailing list.  Sort of a
"do it yourself Letters-to-the-Editor" column.

	The audience is fairly large, mostly protocol implementors,
system managers, communications specialists, various types of management,
and some onlookers.  The intention is to have a forum to discuss
implementation details and current problems of networking (especially
the Dod Standard TCP/IP), in a much more concrete fashion than the often
"blue sky" HUMAN-NETS Digest.

	Keep those cards (ugh) and letters comming!
			 -Mike Muuss
			 Moderator, TCP-Digest

------------------------------

Date: 18 Apr 1983 23:04:03 EST (Monday)
From: Gail Rubin <grubin@Bbn-Unix.ARPA>
Subject: VAX Arpanet software
To: TCP-IP@BRL

The company mentioned in Joel Goldberger's message, DTI, has changed its
name  to  Compion. We (BBN) are currently running their software on some
of our VMS systems - the version for VMS >3. It sounds much better  than
the  version  Joel  used,  but  it  still  has a few problems - the most
serious ones are in ftp. When running from the vms  as  a  host,  it  is
incredibly slow - you should always run it from the other machine (if it
isn't also a vms!). This may be just the way things are  with  VMS,  I'm
not sure this is something Compion can get around.  Also in ftp, you can
only GET one file from vms at a time - subsequent files give  you  error
messages  so  you  have  to  re-establish  the connection for each file.
Compion is working on these problems; they have already fixed one  other
problem  that we reported to them.  On our vax unix machines here we run
our own software - that of Rob Gurwitz of our company, as also mentioned
in  Joel's  message.  The  hardware  is  the  same in both cases - ACC's
LHDH-11.

-- Gail Rubin, (GRubin at bbn-unix)


------------------------------

[ Due to the "Maximum Distribution Requested" on the front of this, I am
  reproducing portions of the DEFENSE DATA NETWORK NEWSLETTER here which
  concern subscription and information-distribution details, for those
  who may not have seen this in a direct mailing.  For those who don't
  have ARPANET access, the NIC may be telephoned at (415)-859-3695.  -Mike ]

                       DEFENSE DATA NETWORK NEWSLETTER

   (Maximum Distribution Requested.  The DDN Newsletter is published by the 
   Network Information Center under DCA contract.  For subscription, contact
   NIC@SRI-NIC.  Back issues obtainable by FTP from the directory <DDN-NEWS>
   at SRI-NIC [10.0.0.73].)

SUBSCRIPTIONS WANTED.

Along with the change in name and format, the DDN Newsletter gains a greatly 
expanded role as the official means by which the DDN Program Management Office 
communicates with DDN and ARPANET users.  To this end, a significant increase
in circulation is sought.  Two means of accomplishing this are feasible.

The first means of increasing circulation is by remailing at the host level.
This clearly is the more efficient method, and avoids building the mailing list
at the NIC into something unmanageable.  Host Administrators and Technical
Liaison personnel are therefore requested, where feasible, to remail the DDN 
Newsletter to all account holders on their host.  Remailing is particularly 
solicited for this edition of the DDN-NEWS.

The second means is by direct mailing from the NIC.  Although not the desired 
approach, an increase in size of the NIC mailing list is feasible within 
limits.  Users with accounts at hosts which cannot provide remailing of the 
newsletter may, therefore, obtain a copy directly from the NIC by submitting a 
request for subscription directly to NIC@SRI-NIC.

DDN-DIGEST.

Our thanks to Steve Nelson and Pete Vayda for their timely and excellent
suggestion that we begin a DDN-DIGEST, similar to the TCP-IP Digest published
by Mike Muuss, to keep you, the users, informed about the DDN and to get 
feedback from you as well.  To this end, we have established the mailbox 
DDN-NEWS@SRI-NIC to receive questions, comments, and the like which you want
to send us.  These we will incorporate in the UNOFFICIAL section of the 
Newsletter (allowing for duplication) along with an answer from an appropriate
person.  More on this in future Newsletters, but in the meanwhile, the mailbox
is there and ready for your use.

                                   DARRYL HENRY
                                   DCA Code B627
                                   DDN-PMO System Development Branch

------------------------------

END OF TCP-IP DIGEST
********************

END OF DOCUMENT