|
|
ARCHIVE: TCP-IP Distribution List - Archives (1984)
DOCUMENT: TCP-IP Distribution List for April 1984 (58 messages, 25334 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1984/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: 2 Apr 1984 1239 PST From: Eric P. Scott <EPS@JPL-VLSI> To: TCP-IP@SRI-NIC.ARPA Subject: Security/Privacy in a large broadcast Local Area Network
We would like to pass sensitive information over a broadcast LAN; one of the problems with this is that traffic appears everywhere on the cable. This is one of those "outlet in every office" deals and the ability of a snoop with a suitable personal computer to abuse the "promiscuous receive" feature of his LAN interface has some people worried. I would appreciate commentary on the following strategy as to its feasibility (or details, if something similar has already been done). 1. Network interfaces have a moderate amount of "intelligence." 2. There should be a minimal impact on host software (ideally this should be transparent). 3. All single-destination datagrams would be encrypted using at least a commercial grade public-key scheme. Frame headers would remain untouched; just the "data" would be scrambled. 4. Broadcast/Multicast datagrams would not be encrypted. 5. Gateways only see plaintext. 6. A network interface broadcasts its public key upon request, or if it is changed. 7. Each interface maintains a cache of recently used keys. If a datagram needs to be sent to a host whose key is unknown, it is dropped; a cache entry is made with a "null" key and a key request is broadcast. Whenever a key definition broadcast is seen each interface updates its cache if the sender is listed. 8. This could be integrated with ARP. Replies to the list, please. -=EPS=- ------
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: 2 Apr 1984 1451 PST From: Eric P. Scott <EPS@JPL-VLSI> To: TCP-IP@SRI-NIC Subject: Re: Secure LAN/more on security
I should have specified unclassified only! I also deliberately did not specify that all traffic would be IP-based. The whole point of this is that physical security of the cable is out. Your turn. -=EPS=- ------
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: Mon, 2 Apr 84 17:21 EST From: "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA> To: tcp-ip@SRI-NIC.ARPA Subject: Secure LAN
First, a Caveat.
The DoD Computer Security Center is still studying standards for
networks to accompany the Orange Book criteria for systems. ANYTHING
you do should be bounced off of them. Dan Edwards at Ft. Meade is a
good starting contact.
We have a preliminary MLS TCP/IP running on the NSC hyperchannel. The
assumption is that a trusted interface must filter datagrams destined
for non-multi-level machines. The cable must be physically secured (no
easy trick). All of our TCP connections are single-level. Without
special privilege, a process can only initiate a TCP connection at its
level and categories.
I would suggest that you pay special attention to the data integrity of
the IP Security option. The 1-s complement checksum is clearly
insufficient to protect this from single-bit errors that could change
the compartment marking of a datagram. Your network will have to have
hardware data integrity to suplement/replace the IP checksum.
have fun,
benson
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: Mon, 2 Apr 84 17:28 EST From: "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA> To: tcp-ip@SRI-NIC.ARPA Subject: more on security
I realize that I lept to an assumption -- that you were in the MLS business. Far easier than public key hardware, I think, would be to use MLS and IP security options. All that key exchange looks like a drag.
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: 2 Apr 84 19:07:52 EST From: dca-pgs @ DDN1 To: tcp-ip @ sri-nic Cc: dca-pgs @ DDN1 Subject: Zilog Z8000 System
Does anybody know anything about this system? I understand it runs a sort of Unix-like OS called Zeus. How hard (or possible?) would it be to port Berkeley utilities (like TCP/IP) to this? Seems like it might be most worthwhile to port Berk Unix onto the Zilog hardware. Discussion/suggestions invited. Sincerely, Pat Sullivan DCA/DDN/PMO
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: 2 Apr 84 1956 EST From: Rudy.Nedved@CMU-CS-A.ARPA To: EPS@JPL-VLSI.ARPA Cc: TCP-IP@SRI-NIC.ARPA Subject: Re: Security/Privacy in a large broadcast Local Area Network
A bunch of people at CMU got together and discussed security on LANs. We ended up having a physically secure cable with a gateway at the end which was also physically secured. The gateway looks at what "cable" the packet came from, where it wants to go to and where it says it from and then looks it up in a table. If the table disagrees with the destination or source as described by the per cable info then the packet is dropped. The result is "public" or "insecure" sites can not see packets between two secure sites (this also reduces load), public sites can not fake out a secure site and a public site can not disrupt a conversation between two secure sites. The above mechanism works pretty well and doesn't address the issue of what to do with the public sites that want a degree of security like someone connecting from their PC to a secure site and typing their password in. We have no solution at present given that 1) public key encryption needs an authentication server and all the problems with generating keys for each new connection....very high CPU costs (one estimate was 16 seconds of raw PDP-11/23 time) and 2) gateways and vendor supplied software don't deal with the problem so unless everything understands that everything is encrypted how do you avoid someone aborting connections and re-transmitting old data (also none of the current protocols deal with "sabotage" of intermediate gateways/bridges). In general, once something goes across something that is "public" you can no longer trust the data or the relaibilit of the connection. You can probably encrypt the data at the application level like the contents of a mail message and use people with chained brief cases to exchange secret keys but you can not prevent the message from being "derailed" or stopped. -Rudy
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 1984 11:06:19 PST From: POSTEL@USC-ISIF To: tcp-ip@SRI-NIC Subject: Privacy on Broadcast LANs
Eric Scott: Privacy protection in Broadcast systems is a real problem. I want to encourage work on developing a way to provide privacy for the transmission of user data in such environments. I think the outline of points you present are a good starting point. Please go ahead with this and formulate a draft proposal for a protocol. --jon. -------
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: Tue, 3 Apr 84 08:11 EST From: "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA> To: tcp-ip@SRI-NIC.ARPA Subject: Securing LAN's
Oh well. Do you really need public key? Would (hiss, boo) DES take care of your problems? Somehow, it seems to me that trusted adapters could use fairly simple encryption in this environment, and them public-key would be used on a host-host or agent-agent level for reeally sensitive data, like mail.
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: 3 Apr 1984 17:29-PST From: William "Chops" Westfield <BillW @ SRI-KL> To: tcp-ip@NIC Subject: security, IBMPC TCP/IP
Gee, I pointed this out privately, but since everyone seems to be neglecting the fact, arent public keys systems computationally very slow? i think even the DES chips would have a hard time keeping up with ethernet data rates. (faster than most disks, remember...) On a totally unrelated issue, I have heard that the MIT TCP/IP for the IBM PC was released to the public domain after they gave up trying to find someone to market it. Is this true, and if so, how do I get a copy... Thanks Bill W
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Tue, 3 Apr 84 16:07:38 EST From: Jonathan Dreyer <jdreyer@BBN-UNIX> To: EPS@JPL-VLSI Cc: TCP-IP@SRI-NIC.ARPA Subject: Re: Security/Privacy in a large broadcast Local Area Network
Eric,
8. This could be integrated with ARP.
Actually, ARP could do most of the work. ARP packets have two
fields, ar$hrd (hardware address space, e.g. Ethernet, Packet
Radio Net) and ar$hln (byte length of each hardware address) that
could be twiddled for this purpose. Currently, ARP
implementations on ethernets use a 1 for the ar$hrd field to
indicate ethernet and 6 for the ar$hln field.
All you have to do is to consider "ethernet with encryption" to
be a new hardware type (ar$hrd) and consider hardware addresses
to be ethernet addresses concatenated with public encryption
keys, so ar$hln would be 6 + (encryption key length). Wherever
you would place an ethernet address, you instead place the
ethernet address followed by your public encryption key. Then it
should all "just work"; ARP should handle the key distribution
and cacheing automatically. This would be a good test of the
generality of your ARP implementation. (Luckily, my implementation
lives in a gateway and "gateways see only plaintext.")
This is aesthetically nice because in an encrypted environment the
encryption key is really part of the "address" of an encrypted
packet.
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: Tue, 3 Apr 84 22:11:39 EST From: Mike Muuss <mike@Brl-Tgr.ARPA> To: dca-pgs@ddn1.arpa Cc: tcp-ip@sri-nic.arpa, dca-pgs@ddn1.arpa Subject: Re: Zilog Z8000 System
Last I heard, Zeus was a port of UNIX Version 7 to the Zilog Z8000 fempto-processor. It can comfortably support a handful of users. Porting Berkeley's TCP/IP to a V7 kernel will take a skilled kernel programmer about 3 man-months (kernel code plus user support). But, fitting TCP/IP into limited address-space processors is *real hard*, starting with the Berkeley implementation. Which is not to try and denigrate the Berkeley code; it just takes a lot of space -- but you get lots of generality for it. I speak on this with some experience: when ARPANET converted to TCP/IP, I lead a team of 3 people to port the Berkeley code to our V6 PDP-11 system. We had a functioning (but not perfect) implementation in 1 month (and missed the 1-Jan conversion date by only 1 day!). Of course, it would have been twice as hard if we hadn't had the fine work of the folks at SRI (2.8a BSD effort) to start from. Porting a full 4.2 BSD (VAX-UNIX) to a less than 32-bit processor is likely to be excessively difficult, and a waste of time. So, while people who use real computers do their software maintenance over reliable high-speed networks, our micro-processor fiends find themselves maintaining 100's of tiny computers via the "shopping carts full of floppy disks" procedure. Chuckle! Best, -Mike Muuss U. S. Army Ballistic Research Laboratory
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: Wed, 4 Apr 84 21:03 EST From: JSLove@MIT-MULTICS.ARPA (J. Spencer Love) To: TCP-IP@SRI-NIC.ARPA Subject: Secure LAN's
The ones completement checksum that is a standard for IP headers is really not sufficient for the IP security option, as Benson Margulies pointed out. However, the IP checksum must be recomputed at every IP gateway, since time-to-live changes, even if there are no options to change. Thus, any network which uses IP security options can use a better checksum (e.g., CRC). Since security options are not used on the ARPA from such secured networksnet (the research side, anyway), all gateways onto ARPA from such secured networks must assume that the option might not be honored and restrict sensitive traffic according the the handling restrictions. Everything that is needed for deliver of a datagram, modulo the protocol violations that occur in the mail-only gateways, is in the IP header. Thus, everything in the protocol portion of the datagram, including the protocol header, can be encrypted. CRC and DES are both available in cheap hardware, and thus are good candidates for a properly designed system; if either must be done in software, cheapness of calculation probably rules both out. Key exchange and further interpretation of the security option are properly the subject of additional standards. I suspect that such documents exist. I also suspect that they are classified. (Actually, I have such a document on the security option, and while "classified" is too strong; I don't have a clearance; they are fairly hard to come by). Would the No Such Agency types care to comment?
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: 5 Apr 1984 08:25-CST From: PVAYDA@STL-HOST1 To: JSLove@MIT-MULTICS Cc: TCP-IP@SRI-NIC Subject: Re: Secure LAN's
Steve: a. WHY we leaving off DDN/Dhenry on such goodness stuff?, since he has a viable interest.. b. What is the DNG list? I never saw...but...with all other glitch- ery with BUREAU and AUTOCOM listings...(PLUS "fact" that , supposedly, stl-host1 MAIL is still screwed up (as far as being rec`d at Hq Here)??? ( I guess I`m losing track of system "management"... PeevVee
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: Tue, 10 Apr 84 08:17:51 EST From: Nathaniel Mishkin <Mishkin@YALE.ARPA> To: tcp-ip@SRI-NIC.ARPA Subject: CSNet
Could someone illuminate that present and expected future relationship
between the ARPA Internet and CSNet? I take it that an increasing
number of CSNet sites are actually able to communicate with each other
via IP (but that a number of CSNet sites are still communicating only
via UUCP-like methods). What is the role of Telenet in this? Will
all CSNet sites use it as a data link level, or will there be other
data links?
Also, I take it that there are IP gateways between CSNet and the ARPA
Internet. If this is so, in what sense is CSNet different from the
ARPA Internet? Is there some mechanism for preventing IP packets from
a CSNet site to a CSNet site from traversing DoD-funded networks? Do
CSNet sites have unrestricted access to DoD-funded networks when the
CSNet sites want to communicate with an ARPA Internet site?
Please respond to me directly, because I'm not on this list. Thanks.
-- Nat
-------
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 1984 13:36-PST From: the tty of Geoffrey S. Goodfellow <Geoff @ SRI-CSL> To: drockwel@BBN-VAX Cc: Mishkin@YALE, tcp-ip@SRI-NIC, cic@CSNET-CIC obrien@RAND-UNIX, jdreyer@BBN-VAX, mimno@BBN-VAX gurwitz@BBN-VAX Subject: Re: CSNet
I have a couple of curiosity inspired questions I'd like to toss out: 1) In the most recent update of HOSTS.TXT from the NIC, it seems that DECWRL moved from [14.0.0.13] (going thru the VAN-GATEWAY at BBN) to [192.5.58.3] (going thru CSNET-PDN-GW on [10.7.0.49] which is really CSNET-RELAY). Why the switch from using the LSI-11/23 VAN-GATEWAY to using the CSNET-RELAY VAX/UNIX as bridge between Telenet and the DARPA Internet? And then, why only for DECWRL? 2) When someone on the DARPA Internet side of the house originates an IP connection to a host on the GTE Telenet side of the house, who pays for the packet charges? (i.e., I'm at a MILNET or ARPANET TAC, or even SRI-CSL for that matter, open a connection to RICE, for example, which will involve the VAN-GATEWAY (?or perhaps CSNET-RELAY?), which then uses the IP-in-X.25 encapsulation scheme between the VAN-GATEWAY and RICE, over Telenet). Since the Telenet `Call' is originating from the VAN-GATEWAY to RICE, doesn't the VAN-GATEWAY get charged for all packet or costs thusly incurred? I'm assuming this because it is my understanding that the originating host on Telenet pays for all costs associated with a `Call'. When the originating host is the VAN-GATEWAY, who pays? 3) Wouldn't it be possible for hosts on either side of the VAN-GATEWAY to bypass access control restrictions in the VAN-GATEWAY by forcing their Internet traffic to be routed thru hosts like CSNET-RELAY (or others?) which are dual-homed on more than one network? g
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: Thu, 12 Apr 84 14:29 EST From: Dennis Rockwell <drockwel@BBN-VAX> To: Nathaniel Mishkin <Mishkin@YALE.ARPA>, tcp-ip@sri-nic Cc: cic@csnet-cic, obrien@rand-unix, jdreyer@BBN-VAX, mimno@BBN-VAX, gurwitz@BBN-VAX Subject: Re: CSNet
This is a complex question. As of right now, there are some CSNet sites that communicate with each other and the CSNET-RELAY host via IP. Some of these hosts are on the ARPAnet, and some are connected to GTE Telenet via an IP-in-X.25 encapsulation scheme. This net (PDN, net 14) is connected to the rest of the internet through a special gateway (the VAN gateway). As for CSNet access to DoD-funded networks, DARPA-approved domestic X.25-based CSNet sites can exchange packets freely with Internet hosts because of a special agreement between NSF and DARPA. This agreement basically prohibits those sites from relaying packets outside their organization and insures that no charges will be levied on Internet hosts for network access. There are access controls in the gateway to only allow certain hosts to communicate with each other, but these are in fact open at this point; this is only because we have no non-domestic sites right now. When we do have foreign sites, they will have complete access to other CSNet X.25-based sites, but no direct access to the rest of the Internet. They will have to relay mail through CSNET-RELAY. We do not expect this restriction to change in the near future. The X.25 portion of our network is expected to grow; we currently have three sites connected, with about a half dozen waiting for the software to get out of beta-test. All the X.25-based CSNet sites are on the same network (except for a couple on a testbed network), so if they were to talk to each other, there would be no DoD network in the middle; however, the CSNet sites that are also ARPAnet hosts must use the ARPAnet to contact any other sites. If you have any questions, feel free to write me or call (617) 497-2643. Dennis Rockwell CSNet Technical Staff
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 1984 17:53-PST From: the tty of Geoffrey S. Goodfellow <Geoff @ SRI-CSL> To: cak@PURDUE Cc: Mishkin@YALE, tcp-ip@SRI-NIC, cic@CSNET-CIC obrien@RAND-UNIX, jdreyer@BBN-VAX, mimno@BBN-VAX gurwitz@BBN-VAX, drockwel@BBN-VAX Subject: Re: CSNet
Chris Thanks for the explanations. With them in mind, is it possible for X.25 hosts to selectively accept/refuse collect calls based on the source address? Two situations come to mind: (Ref: last summers antics of the 414s's and more recently the article "HACKING ON TELENET. It's as easy as 123456!", cover story, Volume one, Number two, Feb '84, 2600). Selectively accepting collect calls ONLY from the VAN-GW, while refusing them all others would prevent random crackers from connecting up to a site from uncontrolled public Telenet TACs and incurring packet charges while attempting to break in. An unneighborly Telenet host which sets the `collect call' bit when opening connections to other hosts within Telenet (or thru a secret gateway which didn't have the refuse collect call bit set) in order to circumvent packet charges. Given the above, if I were a CSNET site on Telenet, it would seem a prudent measure to refuse collect calls all hosts other than the VAN-GW, don't you think? g
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: 12 Apr 1984 1732-EST (Thursday) From: Christopher A Kent <cak@Purdue.ARPA> To: the tty of Geoffrey S. Goodfellow <Geoff@SRI-CSL.ARPA> Cc: Mishkin@YALE.ARPA, tcp-ip@SRI-NIC.ARPA, cic@CSNET-CIC.ARPA, obrien@RAND-UNIX.ARPA, jdreyer@BBN-VAX.ARPA, mimno@BBN-VAX.ARPA, gurwitz@BBN-VAX.ARPA, drockwel@BBN-VAX.ARPA Subject: Re: CSNet
1) In the most recent update of HOSTS.TXT from the NIC, it seems
that DECWRL moved from [14.0.0.13] (going thru the VAN-GATEWAY
at BBN) to [192.5.58.3] (going thru CSNET-PDN-GW on [10.7.0.49]
which is really CSNET-RELAY). Why the switch from using the
LSI-11/23 VAN-GATEWAY to using the CSNET-RELAY VAX/UNIX as
bridge between Telenet and the DARPA Internet? And then, why
only for DECWRL?
Purdue-tn moved, too. We (CSNET) are experimenting with using a VAX
running 4.2 Unix and the Purdue-developed IP over X.25 code (called
XNI) as a gateway, because throughput through the VAN gateway is often
quite bad. This is mainly due to the large speed mismatch between the
Arpanet (56K) and Telenet (9.6K), and the limited number of buffers the
VAN gateway has, as well as some Telenet specific limitations (example:
you can only have two packets in flight on a channel at a given time
without having received their end-to-end X.25 ACK.)
By running in a VAX, the gateway can survive bursts in a nicer fashion.
The XNI code also can be configured to open multiple channels to the
same site, and round-robins through them, giving the effect of a larger
X.25 window, leading to higher throughput.
2) When someone on the DARPA Internet side of the house
originates an IP connection to a host on the GTE Telenet side of
the house, who pays for the packet charges? (i.e., I'm at a
MILNET or ARPANET TAC, or even SRI-CSL for that matter, open a
connection to RICE, for example, which will involve the
VAN-GATEWAY (?or perhaps CSNET-RELAY?), which then uses the
IP-in-X.25 encapsulation scheme between the VAN-GATEWAY and
RICE, over Telenet). Since the Telenet `Call' is originating
from the VAN-GATEWAY to RICE, doesn't the VAN-GATEWAY get
charged for all packet or costs thusly incurred? I'm assuming
this because it is my understanding that the originating host on
Telenet pays for all costs associated with a `Call'. When the
originating host is the VAN-GATEWAY, who pays?
X.25 allows you to make collect calls; the gateway always calls
collect, and never accepts a collect call.
3) Wouldn't it be possible for hosts on either side of the
VAN-GATEWAY to bypass access control restrictions in the
VAN-GATEWAY by forcing their Internet traffic to be routed thru
hosts like CSNET-RELAY (or others?) which are dual-homed on
more than one network?
The only hosts that are dual-homed as such are the gateways, and they
have the access control built in.
Cheers,
chris
----------
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: 13 Apr 1984 0813 PST From: Scott McCord <SMJPM@JPL-VLSI.ARPA> To: tcp-ip-request@sri-nic Subject: SMTP
Does anyone know if Federal Information Processing Standard 98,"Message Format for Computer-based Message Systems," (FIPS 98) is compatible with SMTP? i.e will SMTP accept a message in this format? Also if not, can FIPS 98 be adapted as it's own application running over TCP/IP? (I'm not familiar enough with its internal format and adressing scheme to make this determination) Any feedback/input on this topic would be very helpful. Scott McCord <SMJPM at JPL-VLSI> ------
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: Fri 13 Apr 84 12:35:20-PST From: David Roode <ROODE@SRI-NIC.ARPA> To: Mishkin@YALE.ARPA, TCP-IP@SRI-NIC.ARPA Subject: Re: IP over Telenet
The biggest advantage of Telenet for use as the backbone of a pseudo net is that the connections are switched and dynamic. When not needed, the connections are broken and no cost is incurred. Connections can be established to any host on Telenet. -------
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: 13 Apr 1984 1023-EST (Friday) From: Christopher A Kent <cak@Purdue.ARPA> To: the tty of Geoffrey S. Goodfellow <Geoff@SRI-CSL.ARPA> Cc: Mishkin@YALE.ARPA, tcp-ip@SRI-NIC.ARPA, cic@CSNET-CIC.ARPA, obrien@RAND-UNIX.ARPA, jdreyer@BBN-VAX.ARPA, mimno@BBN-VAX.ARPA, gurwitz@BBN-VAX.ARPA, drockwel@BBN-VAX.ARPA Subject: Re: CSNet
I believe that it is possible to accept/refuse collect calls on a per host basis, if your implementation supports it. Essentially what happens is that the caller sends a call request packet, indicating that it wants to make a collect call; the callee gets to inspect that packet and decide whether or not it will accept or refuse, and sends an ACK or NAK (effectively). The CSNET sites on Telenet do mostly refuse collect calls, though some pairs of hosts may agree that one should always pay. In general, the XNI code tries not to accept calls from anyone other than another CSNET site (since incoming PAD support isn't currently working in the 4.2bsd code). In reality, hardware brain-damage makes this a little difficult, but that is changing. Cheers, chris ----------
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: 13 Apr 1984 1520 PST From: Eric P. Scott <EPS@JPL-VLSI.ARPA> To: TCP-IP@SRI-NIC.ARPA Cc: SMJPM@JPL-VLSI.ARPA Subject: SMTP and FIPS 98
Afraid not. The first third or so of FIPS 98 is pretty interesting (it brings up a number of important points along with describing the motivation for the document). There are a few good ideas that would fit in well with RFC 822, but I'm not particularly thrilled with it (FIPS 98) as a standard. RFC 822 is entirely text-based, FIPS 98 is geared mor towards an "internal representation" rather than something to pass between hosts in a heterogenous environment. In any case, the two are not compatible. -=EPS=- ------
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: Fri, 13 Apr 84 12:56:14 EST From: Jonathan Dreyer <jdreyer@BBN-UNIX> To: the tty of Geoffrey S. Goodfellow <Geoff @ SRI-CSL> Cc: cak@PURDUE, Mishkin@YALE, tcp-ip@SRI-NIC, cic@BBN-UNIX, obrien@RAND-UNIX, jdreyer@BBN-UNIX, mimno@BBN-UNIX, gurwitz@BBN-UNIX, drockwel@BBN-UNIX Subject: Re: CSNet
The VAN gateway has "got a little list" of hosts it accepts calls from and hosts it may call, and it never accepts reverse-charge calls. Every once in a while I get a trap message saying that the gateway rejected a call from some random host. I assume that these calls are either wrong numbers or curious folks at Pads. I checked a few of the soures with Telenet, and they all were public Pads. Jon
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: Fri, 13 Apr 84 13:53:19 EST From: Paul Milazzo <milazzo@cmu-cs-g.ARPA> To: the tty of Geoffrey S. Goodfellow <Geoff@SRI-CSL.ARPA> Cc: cak@PURDUE.ARPA, Mishkin@YALE.ARPA, tcp-ip@SRI-NIC.ARPA, cic@CSNET-CIC.ARPA, obrien@RAND-UNIX.ARPA, jdreyer@BBN-VAX.ARPA, mimno@BBN-VAX.ARPA, gurwitz@BBN-VAX.ARPA, drockwel@BBN-VAX.ARPA Subject: Re: CSNet
Geoff: One problem with refusing collect calls from random Telenet addresses is that I, along with other legitimate users, call my host (RICE) from all sorts of random places. I suffer from withdrawal symptoms if deprived of my mail for more than a day or so, and for all of Telenet's disadvantages, at least I'm never far from a Telenet office. Paul G. Milazzo <Milazzo@Rice.ARPA> (temporarily hiding at CMU) Dept. of Computer Science Rice University, Houston, TX
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Fri 13 Apr 84 17:40:15-PST From: David Roode <ROODE@SRI-NIC.ARPA> To: FRANK@UTAH-20.ARPA, milazzo@CMU-CS-G.ARPA, Geoff@SRI-CSL.ARPA Cc: cak@PURDUE.ARPA, Mishkin@YALE.ARPA, tcp-ip@SRI-NIC.ARPA, cic@CSNET-CIC.ARPA, obrien@RAND-UNIX.ARPA, jdreyer@BBN-VAX.ARPA, mimno@BBN-VAX.ARPA, gurwitz@BBN-VAX.ARPA, drockwel@BBN-VAX.ARPA Subject: Re: CSNet
The optional mode of operation for Telenet described by Randy Frank (issuance of network id's) is the standard mode of operation for Tymnet. It is interesting to note that news accounts of breakins over commercial networks seem to always involve Telenet sites which do accept collect calls, and the news articles never mention that the acceptance of collect calls was a factor. -------
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: Fri 13 Apr 84 16:40:48-MST From: Randy Frank <FRANK@UTAH-20.ARPA> To: milazzo@CMU-CS-G.ARPA, Geoff@SRI-CSL.ARPA Cc: cak@PURDUE.ARPA, Mishkin@YALE.ARPA, tcp-ip@SRI-NIC.ARPA, cic@CSNET-CIC.ARPA, obrien@RAND-UNIX.ARPA, jdreyer@BBN-VAX.ARPA, mimno@BBN-VAX.ARPA, gurwitz@BBN-VAX.ARPA, drockwel@BBN-VAX.ARPA Subject: Re: CSNet
There is a relatively easy solution to the collect call problem. We are on Telenet, and refuse collect calls from all sites. For people we want to communicate with us we issue network id's (not that dissimilar from TAC login ids). With network id's calls placed from a Telenet pad are not placed collect; instead, they are placed prepaid, and the charges billed to the network id. Another advantage of this approach is that Telenet charges are then broken down by id. It has the disadvantage that you must issue someone who wants to access your host an id beofre they can do so, and that each id must be registered with Telenet before being activated. -------
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: Fri, 13 Apr 84 15:06:26 EST From: Nathaniel Mishkin <Mishkin@YALE.ARPA> To: TCP-IP@SRI-NIC.ARPA Subject: IP over Telenet
Next dumb question: isn't it overkill to use Telenet as a data link
for IP? I mean, isn't Telenet providing reliable connections whose
reliability is then ignored by IP and TCP? Is it possible to rent
unreliable (and presumably cheaper) links from Telenet or someone
else?
Please reply to me directly because...
-- Nat
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: Fri 13 Apr 84 21:43:00-PST From: Philip Almquist <ALMQUIST@SU-SCORE.ARPA> To: Mishkin@YALE.ARPA Cc: TCP-IP@SRI-NIC.ARPA Subject: Re: IP over Telenet
Nat,
X/25 (upon which Telenet is based) is not "reliable" (in the
technical sense of the word) in some circumstances. Those circum-
stances are those in which an X/25 link can die but communication can
continue via another path.
Suppose, for example, that I can get to some remote site by
Telenet or by some other transport layer. I open a connection to that
host, and my host chooses to route me via Telenet. I start a data
transfer, and then for some reason my Telenet connection vanishes. My
host should be able to reroute my connection through the other net,
but if it has not been using a reliable protocol (such as TCP) on top
of X/25 it cannot. Why? It cannot tell how much data was lost in
transmission when my Telenet connection died. You need packets and
acks (ie, a "reliable" protocol) to tell you that.
Even if an X/25 net is the only path to the remote host you
can get similar lossage if the X/25 net does not do dynamic routing
internally (I'm not an expert on Telenet, so I don't know whether it
does). If the X/25 net is uses static routing and some component of
the route I am using goes down, my host ought to be able to (behind my
back) get a working route by issuing another call request. Once
again, the host can only do this if it knows what was lost.
The situation gets worse when you get into internetting, since
X/25 is also not (or at least not usually thought of as) an end-to-end
protocol. If I am on an ARPA host, and I want to talk to an X/25 host
through a gateway I want my connection to be reliable. Even if the
ARPAnet provides reliable transport between me and the gateway and
X/25 provides reliable transport between the gateway and the X/25 host
it is still possible that the gateway will screw up (or run out of
buffers, or ...). I'd have to implement end-to-end X/25 @i(on top of)
Telenet to protect me from the gateway, or instead I could use another
end-to-end protocol such as TCP.
@begin(flame)
When you use TCP and IP on top of an X/25 net it is the X/25
(and not the TCP or IP) that is overkill. For most sorts of network
hardware it takes a lot of extra effort to implement the pseudo-
reliability that X/25 provides, and the effort is wasted since higher-
level protocols have to treat a psedo-reliable net as if were
unreliable. The good things that can be said about X/25 are:
1) It works ok for terminal<-->host connections, since these can
get by with an approximation of reliability (the human operator
reestablishes the connection and figures out what got through
and what didn't).
2) People who have worked for the phone company for a long time
find the X/25 model easy to understand and (perhaps more
importantly) easy to bill for. For this reason alone X/25
has become both the de facto international standard (if not
the official international standard) network transport layer.
@end(flame)
Philip
-------
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: 14 Apr 1984 1410 PST From: Eric P. Scott <EPS@JPL-VLSI.ARPA> To: TCP-IP@SRI-NIC.ARPA Subject: <flame on> What it means to live in a Free Country
is that I don't have to conform to CCITT "recommendations" because a state-run telecommunications monopoply makes it a "do or die" proposition. Thank goodness no one in this great nation of ours believes in the filth spread by CCITT ISO ANSI NBS IEEE ... <flame off> ------
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: 14 Apr 1984 15:39:13 PST From: Paul Kirton <KIRTON@USC-ISIF> To: EPS@JPL-VLSI Cc: tcp-ip@SRI-NIC Subject: Re: <flame on> What it means to live in a Free Country
..but some of us want the freedom to communicate with other countries as well. -------
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: 14 Apr 84 15:57:19 PST From: DonWinter.pasa@Xerox.ARPA To: EPS@JPL-VLSI.ARPA Cc: DonWinter.pasa@Xerox.ARPA, TCP-IP@SRI-NIC.ARPA Subject: Re: <flame on> What it means to live in a Free Country
What are you foaming at the mouth about this time? Is it in response to the message from John Covert of DEC on the X.400 message system stuff, which appeared in today's issue of HumanNets? In case it is, let me respond. There is nothing in the X.400 stuff which prevents DEC (or Xerox, who I work for) from having a private network spanning several countries, provided it doen't carry non-DEC (or non-Xerox) traffic across national boundaries. Thus: (a) I can exchange messages with Rank Xerox in the UK, Sweden, or West Germany, over the Xerox internal net. (b) An Arpanet user at SRI can almost certainly NOT use the Xerox message system to communicate with someone at Siemens, in Munich, even though that person has a Xerox associate's message account. (c) I believe that it is OK for me to communicate with the Siemens person. (d) I believe that it is OK for the Rank Xerox people to communicate with a person at SRI. The crucial words are that a Private Domain may not BRIDGE two Administration Domains. There is nothing that says a Private Domain cannot INTERFACE with more than one Administration Domain, PROVIDING it is not carrying traffic BETWEEN those two Administration Domains. Don
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: Sun 15 Apr 84 00:43:00-PST From: David Roode <ROODE@SRI-NIC.ARPA> To: jdreyer@BBN-UNIX.ARPA, Geoff@SRI-CSL.ARPA Cc: cak@PURDUE.ARPA, Mishkin@YALE.ARPA, tcp-ip@SRI-NIC.ARPA, cic@BBN-UNIX.ARPA, obrien@RAND-UNIX.ARPA, mimno@BBN-UNIX.ARPA, gurwitz@BBN-UNIX.ARPA, drockwel@BBN-UNIX.ARPA Subject: Re: CSNet
Who operates the VAN gateway? Is is part of CSNET? Is it a general service for ARPANET? -------
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: 15 Apr 1984 13:52:10 PST From: POSTEL@USC-ISIF To: EPS@JPL-VLSI, TCP-IP@SRI-NIC Cc: SMJPM@JPL-VLSI, POSTEL@USC-ISIF Subject: Re: SMTP and FIPS 98
In response to the message sent 13 Apr 1984 1520 PST from EPS@JPL-VLSI.ARPA Any one looking at standards for the next mail system should be looking at the CCITT X.400 series recommendations. --jon. -------
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 15 Apr 1984 1453-PST From: Lars Poulsen <LARS at ACC> To: TCP-IP at NIC Subject: CCITT X.400
What is the easiest way to get a copy of the X.400 spec ? If it is available in machine readable form anywhere, it oughta be published as an RFC ?? / Lars Poulsen <lars@ACC> ------
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: Sun, 15 Apr 84 15:30:16 EST From: Bob Hinden <hinden@BBN-UNIX> To: David Roode <ROODE@SRI-NIC.ARPA> Cc: jdreyer@BBN-UNIX.ARPA, Geoff@SRI-CSL.ARPA, cak@PURDUE.ARPA, Mishkin@YALE.ARPA, tcp-ip@SRI-NIC.ARPA, cic@BBN-UNIX.ARPA, obrien@RAND-UNIX.ARPA, mimno@BBN-UNIX.ARPA, gurwitz@BBN-UNIX.ARPA, drockwel@BBN-UNIX.ARPA, hinden@BBN-UNIX Subject: Re: CSNet
The VAN gateway is operated by BBNCC under contract from DARPA. It provides a limited expermental service for authorized Intenet users. Bob
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: 16 Apr 84 17:49:01 EST From: dca-pgs @ DDN1 To: ddn-pmo @ DDN1 Cc: dca-pgs @ DDN1, navyusers @ ddn, tcp-ip @ sri-nic Subject: Govt Unix & TCP/IP Users Meeting, NBS, 9-10 May 1984
Comment:
Forwarded FYI.
Pat Sullivan sends...
Forwarded message(s):
-----------------------------------------------------
Date: Mon, 16 Apr 84 15:38:14 EST
From: myra @ Brl-Bmd.ARPA
To: unicorn @ Brl-Bmd.ARPA
Subject: May 84 Meeting at NBS
Text:
Spring 1984 UNICORN Meeting
The Spring 1984 UNICORN Meeting will be held at the
National Bureau of Standards, Gaithersburg, MD on 9-10 May
1984. Dr. Sinnott and Mr. Bob Crosson are sponsoring this
meeting in the Green Auditorium.
In order to provide NBS with as much attendence
information as possible, please provide the names of your
representatives by calling Sue Schantz at Autovon 283-
6674/6722, commercial (301) 278-6674/6722, NLT 4 May 1984.
A registration fee of $10 per person is being charged as
announced during the October 1983 meeting at Aberdeen
Proving Ground, MD. Tables will be set up outside the
Auditorium for registration. Registration fees will be
collected and receipt provided. Everyone will be issued a
badge.
NBS has reserved a block of 50 rooms at the Holiday Inn
of Gaithersburg, which is approximately 1 mile away. A list
of the local hotels has been included for your convenience,
should all the reserved rooms at the Holiday be filled.
Your room reservations should be made at the Holiday by
April 25th.
ABOUT NBS
No food, beverages or smoking is permitted in the
Auditorium.
A message board will be provided, the telephone number
is FTS 921-3330.
Public/pay phones are available for your use, outside
the Auditorium.
We will be dining at the NBS cafeteria for lunch, both
days, therefore, our lunch breaks are scheduled for
1300-1400. This will eliminate an overload on the
cafeteria staff, as well as the NBS staff. The
cafeteria generally provides grill,
soup/salad/sandwich, and "hot meal" lines.
If we can be of any further assistance, please contact
my office (the phone number is listed above). Hope to see
all of you next month.
UNICORN Agenda
9-10 May 1984
National Bureau of Standards
Gaithersburg, Maryland
GREEN AUDITORIUM
9 May 84
0800-0900 Registration (includes Coffee and Pastry)
0900-0910 Welcome Address Dr. Sinnott, NBS
0910-0930 Administrative Notes Myra Hartwig, BRL
0930-1045 Rome AFB Project Lonex Update COL Nacito, Rome AFB
1045-1100 Break - includes coffee
1100-1200 Dept of Army - Project HIOS
1200-1300 Technical Information System (TIS) Jerry Conway, IRS
1300-1400 LUNCH - NBS Cafeteria
1400-1500 UNIX Release 2.0 Craig Cook, Western
Jack Kreger, Western
1500-1600 BRL System 5 Emulation for 4.2BSD Doug Gwyn, BRL
1600-1700 Defense Data Network Rod Richardson, DCA
Pat Sullivan, DCA
1715 Adjourn
10 May 84
0830-0900 Registration (includes Coffee and Pastry)
0900-0930 Administrative Announcements Myra Hartwig, BRL
0930-1030 DoD Computer Security Center Sue O'Connor
1030-1045 Break - includes Coffee
1045-1145 SCOMP Dick Kane, Honeywell
1145-1300 Design Concepts for the Automated Office Randy Ivanciw,
HQ, DA
1300-1400 LUNCH in NBS Cafeteria
1400-1500 Government Only Session
1500 Adjourn
MYRA G. HARTWIG
-------------END OF FORWARDED MESSAGE(S)-------------
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: Mon, 16 Apr 84 21:39:43 pst From: ucscc!ucscc!emacs@Berkeley (05170000) To: tcp-ip@sri-nic.ARPA Subject: Info...
I picked up your address locally and was wondering if you have any online documentation I could grab or you could send me on tcp/ip. I want to know everything about it. I do use it, but the subject is kind of fuzzy to me. I need to know the capabilities, the limitations, etc. Any help is appreciated... Mike ucscc!emacs@berkeley caroff@ames-vmsb
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: Mon, 16 Apr 84 21:26:31 est From: rick@SEISMO (Rick Adams) To: unix-wizards@brl-vgr Cc: tcp-ip@sri-nic Subject: Strange TCP checksum problem with several interconnected networks
Here's the situation: C--------D | | A--------B C & D are on the milnet (sharing the same imp). C & B are on an ethernet. A & B are connected with a serial line. A, B & C are on the same Class-B network. D is a vax running 4.2bsd. B & C are vaxes running 4.1C with the networking code of 4.2 (The 4.1C was extremely hacked before we got 4.2, so I "lifted" the 4.2 networking code). A is a 68000 running a System III compatible unix with TCP/IP based loosely on 3Comms UNET. A, C and D can all talk to each other in both directions (C as both a milnet number and the class-B network number). Here's where it starts to get strange. B can talk to A or C with the Class-B number. However, it can NOT talk to D or C as a Milnet number. (Before you say routing, remember A can talk to everyone and everyone can talk to A). The really wierd part is that when B is trying to talk to C or D, the destination machines (C/D) get TCP CHECKSUM ERRORS! The ip packets are ok. Destination Class-B Milnet Source A B C C D A ok ok ok ok ok B ok ok ok NO NO C ok ok ok ok ok D ok ok ok ok ok Any ideas on why I am getting TCP checksum errors in this one case would be greatly appreciated. ---rick
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: Tue 17 Apr 84 08:39:27-PST From: Francine Perillo <PERILLO@SRI-NIC.ARPA> To: ucscc!ucscc!emacs@UCB-VAX.ARPA, tcp-ip@SRI-NIC.ARPA Cc: PERILLO@SRI-NIC.ARPA, nic-staff@SRI-NIC.ARPA Subject: Re: Info...
The Network Information Center (NIC) is the source of TCP/IP specs. We can send you the full set of documents if you send your mailing address to NIC@SRI-NIC. You have addressed a discussion list on the subject of TCP/IP implementation issues. -Francine /NIC -------
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: 17 Apr 1984 1108 PST From: Eric P. Scott <EPS@JPL-VLSI.ARPA> To: TCP-IP@SRI-NIC.ARPA Cc: DDeutsch@BBNA.ARPA,SMJPM@JPL-VLSI.ARPA,CLYNN@BBNA.ARPA Subject: FIPS 98
"There is a growing `non-ASCII world'" where FIPS 98 is more likely to get in trouble than SMTP. Just out of curiosity, has anyone actually implemented FIPS 98 on the Internet? Has a well- known port been assigned? -=EPS=- ------
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: Tue, 17 Apr 84 8:54:30 EST From: Mike Brescia <brescia@BBN-UNIX> To: rick@SEISMO (Rick Adams) Cc: unix-wizards@brl-vgr, tcp-ip@sri-nic, brescia@BBN-UNIX Subject: Re: Strange TCP checksum problem with several interconnected networks
Rick, My first reaction is to suspect IP source routing. Are you using SR to get through to nets that are not known to the world? The feature of the TCP checksum that enters in here is that it is invariant as source routing is followed. The TCP pseudoheader used in the checksum has the ultimate destination rather than the first IP destination in it. Mike
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: Tue, 17 Apr 84 10:14:09 EST From: Ron Natalie <ron@Brl-Tgr.ARPA> To: Rick Adams <rick@seismo.arpa> Cc: unix-wizards@brl-vgr.arpa, tcp-ip@sri-nic.arpa Subject: Re: Strange TCP checksum problem with several interconnected networks
All I can suggest is to make sure that you are using the correct address in the TCP pseudo header while computing and checking checksums. -Ron
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: Tue 17 Apr 84 14:23:46-PST From: Harry Sameshima <HSS@SRI-NIC.ARPA> To: tcp-ip@SRI-NIC.ARPA Subject: Failed mail
Many of the people on this list have been complaining about the annoying failed mail messages that they receive whenever the vagaries of the network prevent delivery. If there is enough interest, I'm willing to fix the problem by redistributing the mail manually. Naturally, a software solution would be better, but it's not likely to happen in the near future. Send comments to HSS@NIC. Harry Sameshima Coordinator -------
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: 17 Apr 1984 12:03-EST From: DDEUTSCH@BBNA To: EPS@JPL-VLSI Cc: TCP-IP@SRI-NIC, SMJPM@JPL-VLSI, CLYNN@BBNA DDeutsch@BBNA Subject: Re: [Scott McCord <SMJPM@JPL-VLSI.ARPA>: SMTP]...
Charlie Lynn passed your message along to me. I'd like to offer some clarification on the issue of FIPS 98/SMTP. FIPS 98 is not "geared mor towards an '"internal representation"' rather than something to pass between hosts in a heterogenous environment". In fact, just the opposite is true. FIPS 98 specifies the transfer syntax of messages, and does not dictate how they are to be represented within any given system. The transfer syntax is binary (as opposed to the text-based RFC 822). FIPS 98 and SMTP are not compatible because SMTP prepends (text-based) headers to messages. This does not "break" SMTP; it breaks message readers that expect to find messages that are made entirely of FIPS 98 data elements. If SMTP kept and delivered relay information seperate from the message content, there would be no problem at all. Debbie Deutsch
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: 17 Apr 1984 14:54-EST From: DDEUTSCH@BBNA To: EPS@JPL-VLSI Cc: DDeutsch@BBNA, TCP-IP@SRI-NIC, SMJPM@JPL-VLSI CLYNN@BBNA Subject: Re: FIPS 98
We had a test implementation of FIPS 98 here at BBN. I believe that Gerald Neufeld at UBC also has implemented FIPS 98. (He is reachable on CSNET.) There is no well-known port assigned to FIPS 98 messages. There are several reasons for this. First, it is not an official Internet (or ARPAnet) protocol. Second, SMTP would break FIPS 98 messages. Third, nobody has been clamoring for one. What did you mean by "a growing `non-ASCII world' where FIPS 98 is more likely to get in trouble than SMTP"? --Debbie
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: Tue, 17 Apr 84 13:51:34 BST From: Peter Higginson <plh@ucl-cs.arpa> To: Jonathan Dreyer <jdreyer@bbn-unix.arpa> Cc: "the tty of Geoffrey S. Goodfellow" <Geoff@sri-csl.arpa>, cak@purdue.arpa, Mishkin@yale.arpa, tcp-ip@sri-nic.arpa, cic@bbn-unix.arpa, obrien@rand-unix.arpa, jdreyer@bbn-unix.arpa, mimno@bbn-unix.arpa, gurwitz@bbn-unix.arpa, drockwel@bbn-unix.arpa Subject: Re: CSNet
Reverse charging (and most other options) are not available internationally either Peter Higginson (plh@ucl-cs)
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: 18 Apr 1984 12:27-CST From: SNELSON@STL-HOST1 To: PERILLO@SRI-NIC Cc: ucscc!ucscc!emacs@UCB-VAX, tcp-ip@SRI-NIC nic-staff@SRI-NIC Subject: Re: Info...
FRANCINE: I WOULD APPRECIATE A SET. DIRECTOR USACC-ST LOUIS ATTN*CCNC-STL (S.NELSON) 4300 GOODFELLOW BLVD. ST LOUIS MO. 63120. STEVE
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: Thu, 19 Apr 84 16:11:23 EST From: dca-pgs <dca-pgs@ddn1> To: tcp-ip@sri-nic, hawgs@sri-nic, telecom@mit-mc, navyusers@ddn1 Cc: dca-pgs@ddn1, allusers@ddn1 Subject: Proteon proNET and Bell Atlantic
Telecommunications magazine, Apr 1984: (p. 12) "LAN VIA CPE ... Bell Atlantic is entering the emerging market for local area networks through its customer-premises equipment and system subsidiary. Bell Atlanticom Systems plans initially to market two local area networks: proNET (TM) (Proteon, Inc.) and DATAKIT (TM) (AT&T Technologies, Inc.). Letters of intent have been signed with the manufacturers, and contracts are being negotiated." Does anybody have any further details on this? My understanding of the Proteon LAN is that it is a TCP/IP ring LAN. Does anyone out there have one connected to the Arpanet or Milnet? Replies appreciated. Best, -Pat Sullivan DCA/DDN/PMO
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: 19 Apr 1984 1742-EST (Thursday) From: Christopher A Kent <cak@Purdue.ARPA> To: dca-pgs <dca-pgs@ddn1.ARPA> Cc: dca-pgs@ddn1.ARPA, allusers@ddn1.ARPA, tcp-ip@sri-nic.ARPA, hawgs@sri-nic.ARPA, telecom@mit-mc.ARPA, navyusers@ddn1.ARPA Subject: Re: Proteon proNET and Bell Atlantic
Yup, we have a proNET (network Purdue-CS, 128.10), and are pretty happy with it. It's a 10Mb token passing ring; the nicest thing is that hosts can enter and leave the ring without disrupting communications for the other hosts. There's a mailing list for proNET users: v2lni-people@MIT-MC. Cheers, chris ----------
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: 19 Apr 84 1926 EST From: Rudy.Nedved@CMU-CS-A.ARPA To: dca-pgs <dca-pgs@DDN1.ARPA> Cc: tcp-ip@SRI-NIC.ARPA, hawgs@SRI-NIC.ARPA, telecom@MIT-MC.ARPA, navyusers@DDN1.ARPA, dca-pgs@DDN1.ARPA, allusers@DDN1.ARPA Subject: Re: Proteon proNET and Bell Atlantic
I think the Proteon folks hang around MIT or used to... CMU has the stuff in its Computation Center. The stuff has different characteristics (read failures) but at least you know what the minimum transition time is....no random back offs like ethernet. -Rudy
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: 19 Apr 84 1929 EST From: Rudy.Nedved@CMU-CS-A.ARPA To: Christopher A Kent <cak@Purdue.ARPA> Cc: dca-pgs <dca-pgs@ddn1.ARPA>, dca-pgs@ddn1.ARPA, allusers@ddn1.ARPA, tcp-ip@sri-nic.ARPA, hawgs@sri-nic.ARPA, telecom@mit-mc.ARPA, navyusers@ddn1.ARPA Subject: Re: Proteon proNET and Bell Atlantic
Chris, It turns out that the connectors or whatever you call them act like repeaters...you turn off a machine that happens to be between to long pieces of cable and things get worst....the current trick is to turn on power to the board but disable the rest of the machine. No perfect solutions in a hostile non-homogenous enviroments that tends to cheat on specifications because everything is on backorder. -Rudy
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: Thu, 19 Apr 84 21:34:08 EST From: Bob Hinden <hinden@BBN-UNIX> To: dca-pgs <dca-pgs@ddn1> Cc: tcp-ip@sri-nic, hawgs@sri-nic, telecom@mit-mc, navyusers@ddn1, allusers@ddn1, hinden@BBN-UNIX Subject: Re: Proteon proNET and Bell Atlantic
We have gateways to Proteon ring nets at several sites: U. of Wisc, Purdue U., Aerospace Corp., and NTARE. They run at 10Mbits and seem to work well. One major advantage they have over Ethernets is that they can run over a variety of media, ranging from twisted pairs to fiber optics. Bob
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: Fri, 20 Apr 84 07:53:38 PST From: Lou Nelson <lou@AEROSPACE> To: dca-pgs <dca-pgs@ddn1> Cc: tcp-ip@sri-nic, allusers@ddn1, gal, sills, crocker Subject: Proteon proNET and Bell Atlantic
>> Received: from ddn1 by SRI-NIC.ARPA with TCP; Thu 19 Apr 84 13:32:33-PST >> Date: Thu, 19 Apr 84 16:11:23 EST >> From: dca-pgs <dca-pgs@ddn1> >> Subject: Proteon proNET and Bell Atlantic >> To: tcp-ip@sri-nic, hawgs@sri-nic, telecom@mit-mc, navyusers@ddn1 >> Cc: dca-pgs@ddn1, allusers@ddn1 >> >> ...Does anybody have any further details on this? My understanding of the >> Proteon LAN is that it is a TCP/IP ring LAN. Does anyone out there have >> one connected to the Arpanet or Milnet? Replies appreciated. >> >> Best, >> -Pat Sullivan >> DCA/DDN/PMO As Bob Hinden said, we here at Aerospace have had a Proteon proNET in operation for about a year. In that time it has grown to be the most complex mix of transmission media in a single net that Proteon knows about. Two buildings are connected to a third via fiber optics and that third building is connected to a fourth via twinax wire and also to a fifth building via coax. Currently we have three wire centers with more on the way and have 4 VAXes and 1 PDP-11/23 Prime Gateway to the MILNET attached to the proNET backbone. We are now about to bring two intra-building Ethernets into operation that will be connected to the backbone via PDP-11/23 gateways, one of which will be our Prime Gateway functioning with 3 "legs". The whole hierarchical structure is known as the Aeronet. For more technical details and a possibly colorful account of our experiences in getting this all up, please ask Lou Gallenson (gal@aerospace). Regards, Lou
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: 24 Apr 84 03:11:11 PST From: Murray.pa@XEROX.ARPA To: Rudy.Nedved@CMU-CS-A.ARPA Cc: dca-pgs <dca-pgs@DDN1.ARPA>, tcp-ip@SRI-NIC.ARPA, telecom@MIT-MC.ARPA Subject: Re: Proteon proNET => "no random back offs like ethernet"
Have you ever worked with a network where you would notice the
randomness introduced by the backoff time?
There is a critical engineering concept that isn't mentioned in the
ethernet specs. If you expect your ethernet to have an AVERAGE
throughput of anywhere near 10 megabits/sec, you are asking for trouble.
If you set things up so that the normal peak load (as averaged over a
few seconds) is below 3 to 5 megabits/sec, then collisions are rare
enough so that they can almost be neglected.
There is a lot of screaming and shouting going around about rings vs
etherents. I think most of it is pure religion. From what I've seen, the
critical step is not the high level architecture, but rather how
carefully the small details are handled.
Your next message ("you turn off a machine that happens to be between
two long pieces of cable and things get worse") is a good example.
We had another example out here a few years ago. We have an ethernet
under the street to another building. Lightning hit the hill out back.
It zapped a handful of transcievers. Unfortunately, they died shorted,
so the whole net was dead. A 100 ohm resistor in the right place is all
it takes to make a transciever immune to problems like this.
The way I look at things, it doesn't make much difference how the
packets get from my machine to the next one as long as they get through
reasonably reliably. The details of the actual transport mechanisim are
all contained within one module for each specific type of hardware. Some
problems are easier if the hardware supports broadcasting, but there are
usually ways to fake it somehow if you can't do that.
The interesting question is what protocols will Bell Atlantic, or any
other part of the established "phone" system support on high bandwidth
LANs? Can you picture them using IP/TCP?
At least they would solve the naming/addressing problems - just send my
mail to 415-494-4452.
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: 25 Apr 84 0312 EST From: Rudy.Nedved@CMU-CS-A.ARPA To: Murray.pa@XEROX.ARPA Cc: dca-pgs <dca-pgs@DDN1.ARPA>, tcp-ip@SRI-NIC.ARPA, telecom@MIT-MC.ARPA Subject: Re: Proteon proNET => "no random back offs like ethernet"
Gee. Let's see: 1) I don't care about which is better. CMU has got token rings, RS232 lines, ethernet (3MB and 10MB) and a bunch of other "networking" technology. The point about "random back-off" was based on how the product was being presented. I know what is going on and understand the issues but I am not out there buying the now-famous "LAN" hardware and I am not selling it....How the ethernet people "fight back" when they sell the stuff is not my problem...only time will tell and how well the people that put the systems together get things working. Remeber that IBM does alot of "customer service" after their products are installed. This is what makes "winning technology"....how well it works for the guy on the street who tells his next friend over...[or how well it works for company A's EDP director who meets a friend at a conference and talks to company B's EDP director...] 2) I don't expect the phone company to mix digital data and voice data over the same piece of hardware. Of what I know from what I hear from the people doing network phones at Xerox...it is a bad move...too much data and gateway contention problems. The current Xerox system uses a seperate 1MB cable for the voice stuff...because the ethernet chip was available. I suspect in the long run that the telephone company will have a non-NS, non-IBM, non-TCP/IP and definitely BELL protocol that runs on some much faster network system. The current LANs don't cut it but then I am not familiar with "ESS 5" to know if the "long run" started a few years ago. 3) I live in a high turn over "college" area...My two phones in my house get an average of one "wrong number" a day for each phone...real irritating when I sleep during the day...I would really dislike sending mail to a phone number address....I wouldn't want to encourage the use by my friends. The way to go is still what the postal system does... except bring back the old postman who knows who you are and can figure out mail to "Ed Nesbed" is probably for me.... -Rudy
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: Thursday, 26 Apr 1984 12:03-PST From: imagen!geof@su-shasta.arpa To: shasta!en0c@cmu-cs-a.arpa, shasta!Rudy.Nedved@CMU-CS-A.ARPA Cc: shasta!Murray.pa@XEROX.ARPA, shasta!dca-pgs@DDN1.ARPA, shasta!tcp-ip@SRI-NIC.ARPA, shasta!telecom@MIT-MC.ARPA Subject: Re: Proteon proNET
The Proteon ringnet, whose product name is PRONET (with suitable capitalization) was developed in conjunction with members of the Computer Systems Research Group at MIT's Lab for Computer Science. MIT's involvement was funded by DARPA as I understand it. The ring has been refered to in some MIT documents the ``V.2 LNI'' or ``Version 2 Ring'' (don't ask about the version 1 ring). It is a forrunner of the Zurich Ringnet, which (rumour has it) is being turned into IBM's LAN product for SNA. PRONET, like Ethernet, is a link-level transport mechanism. It can accomodate any number (i.e., 2**8 or 2**16 I think) of different higher level protocols. Thus its description as a `TCP-IP ring' is incorrect. The ring runs as 10Mb/s. It uses a token contention scheme. There is no ring master; instead all stations in the ring cooperate to replace the token if it is lost. In this way, it is possible to add and remove hosts from the ring without disrupting existing communications. An important part of the pronet scheme is that it is a so-called `star-shaped ring'. All stations connect to the ring via a passive wire center which splices stations that are powered on into the ring. Thus, `pulling the plug' on a host (either the electrical plug or the network plug) will not destroy the ring (it will probably cause it to reinitialize). I have pulled out hosts' connectors while telnet and FTP connections were running over that host and other hosts. No one noticed; the higher level protocols simply retransmitted any lost packets. I have heard that IBM's ringnet is also star shaped. I have worked with a non-star shaped ring and it is annoying. - Geof Cooper Imagen
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: Fri, 27 Apr 84 13:41:33 EST From: dca-pgs <dca-pgs@ddn1> To: sun.user!sun@berkeley Cc: dca-pgs@ddn1, hawgs@sri-nic, navyusers@ddn1, tcp-ip@sri-nic Subject: Sun Workstation; Who's Got Them On Arpanet or Milnet?
Dear Sun Microsystems: Can you give me a list of Sun users who are on Arpanet or Milnet? If this list reaches any Sun users, also request that you sound off. Is there an on-line Sun newsletter/digest anywhere? Thank you, Pat Sullivan DCA/DDN/PMO
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: 30 Apr 84 14:00:43 EDT From: nrdcnola @ DDN2 To: allusers @ DDN2, allusers @ ddn1, tcp-ip @ sri-nic, info-ibmpc @ usc-isib Cc: nrdcnola @ DDN2, murray @ ddn1 Subject: tcp/ip for micros
we have seen numerous references made to tcp/ip implementations
for microcomputers in mailbox correspondence over the past
several months. we're requesting information from any users that
have implemented tcp/ip (and ftp if available) on micros that may
help us locate sources for our own implementation.
specifically, we're interested in a package to operate on a 16-bit
micro under ms-dos (or compatible) for connection to ddn and need
the answers to such questions as:
1. what interfacing strategies have been used (i.e. ethernet,
x.25, 1822, etc.)?
2. manufacturer and model of micro
3. who provides tcp/ip, ftp, x.25, etc., software and/or
associated hardware?
4. who provides support for the software?
5. what is the cost?
6. in what language is it written?
any such information or points-of-contact that could be provided
would be greatly appreciated.
point of contact:
nrdcnola at ddn2
lt p. l. richardson -or- mr alan david
autovon 363-5730/5727
fts 686-5730/5727
comm 504-948-5730/5727
END OF DOCUMENT
| ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved. |