The 'Security Digest' Archives (TM)

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

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