----MESSAGE-BEGIN---- <1983040501160000> Return-path: Received: from USC-ISIF by SRI-NIC at 5-Apr-83 0921-PST Date: 5 Apr 1983 0916-PST Sender: WESTINE at USC-ISIF Subject: Simultaneous Opens From: Postel@isif To: Ata.SysMaint at RADC-MULTICS Cc: tcp-ip at SRI-NIC, jslove at MIT-MULTICS Message-ID: <[USC-ISIF] 5-Apr-83 09:16:52.WESTINE> John: Why does NSW depend on doing a simultaneous open? --jon. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983041119000000> Return-path: Mail-From: SMTP created at 12-Apr-83 03:28:42 Received: FROM BRL-VGR BY USC-ISIF.ARPA WITH TCP ; 12 Apr 83 03:28:51 PST Sender: Mike Muuss From: TCP-IP@Brl.ARPA To: TCP-IP@Brl.ARPA Date: 12 Apr 1983 00:00 EST Subject: TCP-IP Digest, Vol 2 #3 Received: From Brl-Vgr.ARPA via smtp; 12 Apr 83 3:03 EST 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 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 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) 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 said: "XNS may well become a standard for Ethernet based networks; what happens when you want to talk to someone else?" Chris Ryland 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 ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983041919000000> Return-path: Mail-From: SMTP created at 20-Apr-83 19:11:48 Received: FROM BRL-VGR BY USC-ISIF.ARPA WITH TCP ; 20 Apr 83 19:12:05 PST Received: From Brl-Vgr.ARPA by BRL-VGR via smtp; 20 Apr 83 6:56 EST Sender: Mike Muuss From: TCP-IP@Brl.ARPA To: TCP-IP@Brl.ARPA Date: 20 Apr 1983 00:00 EST 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 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 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 ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983042008061500> Return-path: 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983042023574200> Return-path: Received: from NWC-387B by SRI-NIC at 21-Apr-83 0756-PST Date: Thu, 21 Apr 83 07:57:42 PST From: estell at nwc-387b Subject: Protection of Password File To: tcp-ip at sri-nic 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983042105200000> Return-path: Received: from UTEXAS-11 by SRI-NIC at 21-Apr-83 0931-PST Date: 21 Apr 1983 at 1120-CST From: Bill Lee Subject: Reply to: protection of password file To: estell@nwc-387b cc: tcp-ip@sri-nic 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. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983042105314900> Return-path: Received: from LBL-CSAM by SRI-NIC at 21-Apr-83 1333-PST Resent-Date: 21 Apr 83 13:31:49 PST (Thu) Date: 21 Apr 83 13:31:49 PST (Thu) Resent-From: mo@LBL-CSAM (Mike O'Dell [system]) Subject: Re: Protection of Password File Resent-Message-Id: <8304212131.AA03649@LBL-CSAM.ARPA> Message-Id: <8304212131.AA03649@LBL-CSAM.ARPA> Received: by LBL-CSAM.ARPA (3.320/3.21) id AA03649; 21 Apr 83 13:31:49 PST (Thu) To: dee@CCA-UNIX Cc: tcp-ip@sri-nic, estell@nwc-387b In-Reply-To: Your message of 21 Apr 1983 1305-PST (Thursday). <8304212101.AA03286@LBL-CSAM.ARP>> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983042105570000> Return-path: Received: from SU-DSN by SRI-NIC at 21-Apr-83 1408-PST Date: Thursday, 21 Apr 1983 13:57-PST To: tcp-ip at SRI-NIC Subject: Re: Protection of Password File In-reply-to: drockwell's message of 21 Apr 1983 13:46:57 EST (Thursday). From: greep at SU-DSN 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983042106500000> Return-path: Received: from MIT-MULTICS by SRI-NIC at 21-Apr-83 1411-PST Date: 21 April 1983 11:50 est From: Kovalcik.Multics at MIT-MULTICS Subject: Re: Protection of Password File To: estell at NWC-387B cc: tcp-ip at SRI-NIC In-Reply-To: Message of 21 April 1983 11:26 est from estell 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983042106522300> Return-path: Received: from CCA-UNIX by SRI-NIC at 21-Apr-83 0903-PST Date: 21 Apr 1983 11:52:23-EST From: dee at CCA-UNIX (Donald Eastlake) To: estell at nwc-387b Subject: Re: Protection of Password File Cc: tcp-ip at sri-nic 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983042108070000> Return-path: Received: from OFFICE-3 by SRI-NIC at 21-Apr-83 1639-PST Date: 21-Apr-83 16:07 PST From: WBD.TYM@OFFICE-3 Subject: Re: Protection of Password File To: Kovalcik.Multics@MIT-MULTICS Cc: estell@NWC-387B, tcp-ip@SRI-NIC Message-ID: <[OFFICE-3]TYM-WBD-2A004> In-reply-to: EXT-Kovalcik-Multics-299YG Message of 21 April 1983 11:26 est from estell You mean that Multics hasn't been broken into by either ZARF or the DOD's tiger teams? --Bi<< ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983042108440000> Return-path: Received: from MIT-MC by SRI-NIC at 21-Apr-83 1048-PST Date: 21 April 1983 13:44 EST From: Christopher C. Stacy 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983042108465700> Return-path: Received: from BBN-VAX by SRI-NIC at 21-Apr-83 1055-PST Date: 21 Apr 1983 13:46:57 EST (Thursday) From: Dennis Rockwell Subject: Re: Protection of Password File In-Reply-to: Your message of 21 Apr 1983 11:52:23-EST To: dee@CCA-UNIX (Donald Eastlake) Cc: estell@nwc-387b, tcp-ip at sri-nic, drockwel@BBN-UNIX 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983042111550000> Return-path: Received: from MIT-MC by SRI-NIC at 21-Apr-83 1518-PST Date: 21 April 1983 16:55 EST From: David C. Plummer Subject: Reply to: protection of password file To: lee @ UTEXAS-11 cc: tcp-ip @ SRI-NIC, estell @ NWC-387B Hey folks, this is UNIX your talking about, not TCP-IP. Care to move it to a more appropriate mailing list? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [bnews.brl-bmd.562] <1983042201261700> Message-ID: Newsgroups: fa.tcp-ip X-Path: utzoo!decvax!duke!unc!brl-bmd!TCP-IP@Brl.ARPA From: TCP-IP@Brl.ARPA Date: Fri Apr 22 06:26:17 1983 Subject: TCP-IP Digest, Vol 2 #4 X-Google-Info: Converted from the original B-News header Posted: Wed Apr 20 07:10:22 1983 Received: Fri Apr 22 06:26:17 1983 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 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 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 ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983042503421500> Return-path: Received: from PURDUE by SRI-NIC at 25-Apr-83 0642-PDT Date: 25 Apr 1983 08:42:15-EST From: Christopher A Kent Reply-to: cak@purdue.ARPA To: CSTACY@MIT-MC Cc: estell@NWC-387B, tcp-ip@SRI-NIC In-reply-to: Your message of 21 Apr 1983 1617-EST (Thursday) 21 April 1983 13:44 EST. 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983042519000000> Return-path: Mail-From: SMTP created at 26-Apr-83 03:45:49 Received: FROM BRL-VGR BY USC-ISIF.ARPA WITH TCP ; 26 Apr 83 03:45:58 PDT Received: From Brl-Vgr.ARPA by BRL-VGR via smtp; 26 Apr 83 5:42 EDT Sender: Mike Muuss From: TCP-IP@Brl.ARPA To: TCP-IP@Brl.ARPA Date: 26 Apr 1983 00:00 EST 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 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 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 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 ******************** ----MESSAGE-END----