The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 1983 0936-PDT
From:      POSTEL at USC-ISIF
To:        TCP-IP at SRI-NIC
Subject:   SMTP use of TCP & impact of SATNET
Mail-From: SMTP created at  6-Jun-83 09:16:20
Received: FROM [128.16.3.4] BY USC-ISIF.ARPA WITH TCP ; 6 Jun 83 09:16:32 PDT
Date:     2 Jun 83 12:52:13 BST (Thu)
From:     Steve Kille <steve@ucl-cs> (44a)
To:       knutsen @ sri-unix, dpk @ brl, mike @ brl
cc:       robert @ UCL-CS, steve @ UCL-CS, postel @ isif
Subject:  TCP performance across the Sattelite

After finding the thoughputs we have been getting across the sattelite,
we ran a packet trace.  By some conicidence we caught a letter from
SRI-KL running familiar code.

There are two points on the way the SMTP uses the TCP as a
transport:
1. The command line is split into two parts, the command and a
<CR><LF> pair. Both parts are pushed (delivered with an EOL
marker), this is ineficient for the receiving TCP/host.

2. The data part is sent on 40 byte pieces, with an ACK
required for each piece before sending the next. Each 40 bytes
is pushed (EOL bit set). Thus on a call
to the UK (3 sec approx round trip time) you get about 10
bytes/sec. IT IS possible to put more than 40 bytes of data
into a TCP packet, and IT IS NOT necesary to push every packet.

Robert Cole + Steve Kille

-------
-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 1983 1135-PDT
From:      POSTEL at USC-ISIF
To:        TCP-IP at SRI-NIC
Subject:   re: smtp use of tcp & impact of satnet

Small segments may help in some situations, and setting the push bit on
every segment may help is some situations, but it is hard to see how sending
the command in one segment and the line ending CR-LF in the next segment
helps anybody.

--jon.
-------
-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Mon 6 Jun 83 11:53:59-PDT
From:      Mark Crispin <MRC@SU-SCORE.ARPA>
To:        POSTEL@USC-ISIF.ARPA, steve@UCL-CS.ARPA, knutsen@SRI-UNIX.ARPA, dpk@BRL.ARPA, Mike@BRL.ARPA
Cc:        TCP-IP@SRI-NIC.ARPA, robert@UCL-CS.ARPA
Subject:   Re: SMTP use of TCP & impact of SATNET
     It sounds very much like you're running into an SMTP sender using
the interim TCP I/O routines I devised for the BBN system call interface
on TOPS-20.  I'm sorry for your difficulties; you are quite correct that
Push is set every 40 bytes.  Your claim that a Push is done before the
CR/LF surprises me but it's possible you're right.

     This was done in January and February out of operational necessity.
I discovered that any number of SMTP receivers simply would not work
unless you did a Push quite often.  The problem occurred with a wide
range of systems.  To coddle the systems and enable communication to work
at all, I went to some trouble to guarantee a Push every 40 bytes.

     In April, I tested it again.  I found that while the problem was by
no means as widespread as it once was, a number of sites still exhibited
it.  I felt it was advisable to be as conservative as possible and to
continue frequent Push'ing.

     It is now June and supposed the long-overdue DEC system call interface
is going to be released shortly.  As the present Push-every-40-byte
implementation has been shown to work (albeit inefficiently), I'm unwilling
to change it this late in the game.  I fully intend to try running the DEC
interface with Push set only when dictated by the protocols and see if I
can get away with it today.

     Again, I apologize for any inconvenience this has caused you.  You
have run up against a piece of interim software that is (or until very
recently was) compelled to do the behavior you exhibited to coddle hosts
with faulty implementations.  The penalty for not doing so is (was) not
getting your mail through.

Regards,

Mark Crispin
-------
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Mon 6 Jun 83 12:50:07-PDT
From:      Mark Crispin <MRC@SU-SCORE.ARPA>
To:        POSTEL@USC-ISIF.ARPA
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   re: smtp use of tcp & impact of satnet
I can think of one scenario in which the command in one segment and the
CR/LF in another segment could occur, and that is if the command is
exactly 40 bytes.  The algorithm is 40 byte segments or an explicit Push
from the higher level software, whichever comes first.  The message from
UCL implied that the CR/LF separation was something separate; I'd appreciate
hearing (offline from TCP-IP) where in the SMTP transactions this has been
observed, e.g. "after HELO and DATA, but not RCPT or MAIL", etc.  This is a
real bug, albeit relatively minor; however, I will be pleased to fix it.

When DEC's new release of TCP comes out, I intend to start fresh by sending
full-sized segments and only setting Push where it is required by SMTP.  I
will collect some more formal observations than was possible in the hurried
days of January.  If I still feel there is a need for smaller segments I
will publish my observations for general discussion and consideration of the
list.
-------
-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 83 18:03:53 EDT
From:      Vince Fuller <VAF@CMU-CS-C>
To:        TCP-IP@SRI-NIC
Subject:   FTP server lossage on TOPS-20 and Tenex sites
It would appear that the Tenex/TOPS-20 FTP server does not correctly
implement the CWD command. There are two different problems:

     1. CWD <directory> on Tenex gives an invalid directory error. It
	does, however, accept CWD directory (e.g. w/o <>'s). Is this
	the correct thing to do for Tenex directory names?

     2. The FTP server always tries to connect to the directory
	specified. If the logged-in user does not have connect
	access, it sends back a 331 - send password. If the user
	process then seds a password, it gets a 503 - already logged
	in error.

Since I don't know much about Tenex, it remains for someone else to
answer the first question. As for the second: according to the RFC,
this is a violation of the protocol - a CWD isn't supposed to get a
331 back. Perhaps the server should implement CWD by redefining DSK:
to be the specified path? This would be an easy change, and would
implement CWD basically the same way that Unix does.
-------
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      7 June 1983 00:00 EST
From:      TCP-IP@brl
To:        TCP-IP@brl
Subject:   TCP-IP Digest, Vol 2 #8
TCP/IP Digest            Tuesday, 7 June 1983      Volume 2 : Issue 8

Today's Topics:
                     Digest Numbering Mixup on V2#06
                       Comments on Host-Table RFC
                      InterNet -vs- SubNet Routing
                         More on SubNet Routing
                    Network Humor:  C/30 Power Wiring
----------------------------------------------------------------------
                  TCP/IP Digest --- The InterNet Digest
                         LIMITED DISTRIBUTION
          For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------

Date:     7 Jun 83 6:11:27 EDT (Tue)
From:     Mike Muuss (TCP-IP Digest)  <tcp-ip@BRL-VGR>
To:       tcp-ip@brl
Subject:  TCP-IP Digest Numbering Error

The 24-May issue was incorrectly marked as being V2#05
when it was in fact V2#06.

	V2#05 was published on 26-Apr
	V2#06 was published on 24-May
 and	V2#07 was published on 25-May.

My thanks to the many people who pointed out this error.

		Best,
		 -Mike

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

Date:     6 Jun 83 5:20:18 EDT (Mon)
From:     Ron Natalie <ron@brl-bmd>
To:       tcp-ip@brl-bmd
Subject:  Host table RFC

Since M. Crispin put out a real request for comments, I'm commenting.
He has many good points, but I don't feel that his preferred solution is
optimal.  He points out that the NIC is not always careful of notifying
users of host table updates.  He suggests that the NIC send out the
individual updates to the hosts as the database is modified.  My
observation is that the NIC is very reliably mailing me letters about
the tables being modified, but they batch up the submissions before
entering them in the database.  Every day I load up the host list using
the provided server.  It generally is identical every time except for
the biweekly (or whatever) event when they put in the new entries.  If
this mode of operation is to be continued, I suggest that Mark's
suggestion #2 is better.  This allows a host to query version number of
the hosts database as many times per day as he feels necessary and only
transfer the entire file when it has been changed.  This can easily be
done without altering any of the existing or creating any new protocols
by adding a "VERSION" keyword to the RFC811 hostnames server.  This will
return some string that is guaranteed to be different for each revision
of the database.  In this way a majority of the inquiries are very short
TCP connections rather than the time it takes to retrieve an entire copy
of the table.

VERSION		--> To nic host server
VERSION : 1234	<-- Back to host.

-Ron

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

Date: Thu, 26 May 83 17:38 PDT
From: Taft.PA@PARC-MAXC.ARPA
Subject: Internet vs. subnet routing
To: TCP-IP@Brl.ARPA

This has been a most interesting and constructive discussion.  I would
like to compliment the participants for their careful, well thought-out
presentations, and to offer a somewhat different approach to the
problem.

There are good arguments on both sides of the issue of Internet vs.
subnet routing:

  -- Assigning each local network its own IP network number has the
virtues of simplicity and of taking maximum advantage of the Internet
routing algorithm, but the disadvantage of propagating excessively large
amounts of detailed routing information to all parts of the Internet.

  -- Adopting a hierarchical structure, with each cluster of local
networks treated as a single IP network, reduces the spread of
irrelevant routing information, but has the disadvantages of requiring
duplication of routing mechanisms and of making poor routing decisions
when clusters are interconnected in more than one way.

In the design of the Pup Internet protocols, we used the first approach
(which I believe is still used in the Xerox NS protocols).  We regularly
have over 100 networks up at a time, and the distribution of routing
information is still manageable.  However, if we had an opportunity to
do the design over again, we would likely try to combine the best
features of both approaches.

The main problem with simple "area routing" strategies is that, in the
absence of knowledge about the internal structure of an area, they can't
know how to select the correct gateway into it.  If the area in fact has
a rich internal structure and has many gateways into it, the routing
algorithm will make bad choices and the resulting performance will be
very poor.

Suppose, for example, we carried DOD IP traffic in the Xerox Internet
(we don't, but there's no reason in principal that we couldn't).  And
suppose the DOD and Xerox internets were interconnected not just in Palo
Alto, California but also in Webster, New York.  It would clearly matter
a great deal which of the two gateways you chose to route packets to
when sending to a destination within Xerox.  This means that some
aspects of the internal structure of the Xerox Internet would have to be
distinguishable from the rest of the DOD Internet, which in turn means
that it would have to be assigned more than one IP network number.
Well, how many?  Two?  Ten?  A number that varies as the topology
changes?  You see the problem.

An alternative way of approaching this is not to adopt a hierarchical
structure for network addressing as a whole, but only for the
propagation of routing information.  That is, routing information flows
only along the branches of the hierarchy, but the routes computed for
transport of IP packets are not so constrained.

Each network in a "cluster" gets its own unique network number,
addressable from anywhere within the Internet.  The normal IP routing
algorithms are used for communication within the cluster.

However, detailed routing information about individual networks in this
cluster is NOT automatically propagated throughout the Internet.  What
is instead propagated everywhere is a route to some gateway (or more
precisely, some routing information server) that has enough local
knowledge to compute a good route to the precise desired network.  This
information is cached by the gateways along the route, maintained until
it falls into disuse or stops working, and then forgotten.

In this way we decouple the structure of the routing information
hierarchy from the actual structure of the Internet as embodied in IP
addresses.  This is just as well, since "clusters" may often represent
administrative entities that bear little relation to the overall
Internet topology.

Of course, there are many details I haven't discussed here (indeed, I
haven't worked them out), and much careful design work would have to be
done to make such a scheme work smoothly.  However, it does seem
promising as a way of combining most of the good features of the two
approaches previously discussed.  Additionally, it is entirely
transparent to host software and requires new routing update algorithms
to be implemented only in gateways.

By the way, as someone pointed out, the parallels between this and the
domain naming issue are striking.  Much confusion may be avoided if we
maintain a clean separation between names, addresses, and routes.  I
highly recommend John Shoch's paper, "Internetwork naming, addressing,
and routing", which appeared in the 1978 IEEE CompCon proceedings.  It
was also distributed as IEN-019; I haven't been able to find it on-line
anywhere, but I expect Jon can.

	Ed Taft

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

Date: 27 May 1983 0857-EDT (Friday)
From: Thomas Rodeheffer@cmu-cs-a
To: TCP-IP@brl
Subject: subnet routing

Well, I'm real glad to see subnet routing get some air time, because
there are a lot of tricky issues involved and I'd like to see some of
them sorted out before we at CMU have to plunge into building our own
implementation (which is imminent).

In TCP-IP 2(7) Larry Allen and Mike O'Dell described what is happenning
at MIT and LBL, respectively.  I'll call these the MIT and LBL schemes.
Since I like to rehash the issues, I'll summarize both of these schemes
and state what I see as their advantages and disadvantages.


The MIT scheme can be summarized as postulating a function

	ExtractNetworkNumber: IPaddress -> IPaddress

that is used in the internet module everywhere that network numbers are
contemplated:  principally, during IP routing.  The MIT scheme requires
that this function be changed so that, when in the context of MIT,
addresses that refer to MIT's particular network are treated specially,
in that some of the "rest" bits, which everywhere else in the world
would be ignored as not relevant, are treated as part of the network
number.  Although gateways between MIT and the rest of the world have to
be moderately schizoid (because "the context of MIT" changes from one
side to the other), everybody completely inside or outside of MIT can
just swim right along, and everything will work perfectly.

This is essentially the same scheme as propounded by Chris Kent of
Purdue.  It has the advantage that within MIT all of the routing
mechanisms of IP are applied to the problem of moving a datagram from
one place to another.  You don't need to implement any local routing
mechanisms.  Indeed, assuming that the gateway-to-gateway protocol sent
around routing updates without attempting to compress the data based on
"knowing" what class A, B, and C network numbers looked like, internal
gateways at MIT could be identical to their brethern everywhere else in
the world.

The disadvantage is that because the special treatment of MIT addresses
is not part of the IP standard, all code that is imported to MIT has to
be "upgraded" before it will work at MIT.  Because the necessary change
may require rooting around all through the internet module to find the
places where network numbers are used (not necessarily so nicely
modularized as an ExtractNetworkNumber function), even when source code
is available it may be quite difficult to carry out.


The LBL scheme can be summarized as postulating an external mechanism
for translating IP addresses to local network addresses (the address
resolution protocol) and a local system of gateways that
"transparently" route packets around between various subnets so as to
give the impression to the internet module that it's looking at a flat,
completely connected network.  The gateways respond to address
resolution requests on behalf of hosts on other subnets, giving the
local network address of the best first-hop gateway.  Thus packets
destined for other subnets get sent right to the appropriate gateway
without the host even having to know what is going on.  

Because some sort of address resolution protocol is needed anyway in
order to do anything intelligent with IP packets on the popular 10mb
Ethernet, there is a good chance that the LBL scheme will not require
modifying the software of any host that is to be plugged into it.  This
is a major advantage.

The major disadvantage is that you have to your own local gateway code
and routing update algorithms.  This may not be so hard if you have
friends at other sites who have already done exactly the same thing.

A second disadvantage is the presence of a very subtle violation of the
Internet Protocol specification.  The problem arises in connection with
the separation between the internet layer and the local network layer.
The way I read RFC 791, the internet module has the responsibility of
deciding for each datagram what address inside the network it should be
sent to and the local network interface has the responsibility of
getting it there.  This is not quite what happens in the LBL scheme.

An example should help illustrate the situation.  Suppose that A1, C1,
and D1 are stations on network 1, and D2 and Z2 stations on network 2.
D1 and D2 are two halves of an internet gateway.  Network 1 is actually
divided into two subnets, connected by B1a and B1b.  I will denote the
physical network's address corresponding to an internet address X as
@X.

 ====+======+========+===     ==+==========+=====
     |      |        |          |          |
     A1     C1       B1a~~~~~~~~B1b        D1
              *                              *
               C3                             D2        Z2
               |                              |         |
             ==+==                        ====+=========+==

Suppose that A1 wants to send a datagram to Z2.  Noticing the different
network number, A1 consults its routing tables and decides that D1 is
an appropriate gateway.  A1's internet module calls up its local network
interface, and says:

	Send "SRC=A1,DEST=Z2,DATA=xxx" to D1

A1's local network interface does address resolution on D1 and gets
@B1a.  So off goes the packet:

	To: @B1a, From: @A1, Type: DoDIP, Data: "SRC=A1,DEST=Z2,DATA=xxx"

Observe that at this point all knowledge of D1 has been lost.  What B1a
has to do is peek inside the datagram and recompute the IP routing for
Z2.  With any luck, it will come up with the same answer that A1 did.  Of
course, it might come up with C1 instead.  That would be unfortunate,
especially if C1 were an ordinary internet gateway that didn't
understand about the fancy subnet routing that was going on.  You might
see a whole slew of ICMP redirect messages come piling into A1 as C1
valiantly tried to push the datagram through B1a.  At the IP level the
problem would be characterized as a persistent delivery error in the
local network.

The problem is that the local network interface isn't acting as a
transparent delivery mechanism for the internet layer.  It is usurping
some of the routing responsibility that according to the specification
ought to be performed by the internet module.  The IP specification
assumes that if a datagram is wandering off course inside the same
network as the datagram's source, then it's the fault of the source,
who was supposed to route the datagram properly in the first place.
This is the position taken by the ICMP redirect message, whose purpose
is to correct such misroutings.  As my example shows, it wouldn't be
safe to use ordinary internet gateways with the LBL scheme because the
responsibility for routing errors is not always vested where the
gateway would expect.

I should note that if you only have one external gateway the misrouting
problem never comes up (at the IP level).

As a side issue, if subnet routers are going to have to perform IP
routing anyway in order to second guess where packets are supposed to
go, why not go the whole hog and punt IP routing from hosts entirely.
Let the address resolution take any random IP address and return an
appropriate physical network address.  Of course, the host software
wouldn't be complete IP implementations any more.  I'm not saying this
is bad, but it is not an implementation of IP according to the full
specification.

There are two ways one could modify the LBL scheme in order to make the
local network delivery transparent to the internet layer.  Neither of
these are very attractive.  The first way is to change the encapsulation
of IP packets by adding a field to the physical packet to carry the
local network destination address through the subnets.  In my example,
this would mean arranging for A1's local network interface to transmit
the packet:

	To: @B1a, From: @A1, Type: DoDIPx, DeliverTo: D1,
		Data: "SRC=A1,DEST=Z2,DATA=xxx"

This of course means changing all local network interfaces everywhere
on the local network, which erases the major advantage of the LBL
scheme of not requiring any host software modifications.  Back when I
gave my example, I sneaked the issue of packet encapsulation past you,
assuming an encapsulation that was similar to those used by all
implementations I am familiar with, one which is indeed the obvious
encapsulation to use under the assumption that the local area network
implements an entire IP network.  I am not aware of any formal
specifications of IP packet encapsulations, although of course such
specifications are necessary if IP implementations are ever really
going to be compatible.

The second way is to require that the address resolution function be
one-to-one instead of many-to-one.  In other words, address resolution
must produce a physical local network address that uniquely identifies
the desired IP address, at least when considered within the subnet in
which the address resolution was performed.  In this situation, the
subnet gateways could rederive the local network destination address by
inverting the address resolution on the physical destination address of
the packet.  The physical address space of the 10mb Ethernet is so large
that imbedding an entire IP network within it is no problem, but this
could be impossible on other kinds of local area networks.  Of course,
subnet gateways would have to attend to some potentially very large set
of addresses to which packets could be sent.

The question remains whether the original LBL scheme is suitable, even
though it violates the separation between the internet and local
network layers.  It might be that the benefit from being able to attach
hosts with software written according to the existing IP specification
and common-law packet encapsulations overweighs the disadvantage of
having slightly illegal routing behaviour.

		-Tom Rodeheffer

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

[ While this message does indeed detail an error in the C/30 documentation,
  it is published here because of the humorous nature of the mixup.  -Mike ]

Date:     6 Jun 83 5:34:02 EDT (Mon)
From:     Ron Natalie <ron@brl-bmd>
To:       tcp-ip@brl-bmd
cc:       romash@bbn-unix, brescia@bbn-unix, taccers@bbn-unix
Subject:  C-30 Site Preparation

BRL has taken delivery of eight C-30 processors to act as IMPs and TACs
on our CAN [Campus Area Network -Mike].  While reading the site
preparation guide provided by BBN, I came across some unusal problems
that I had not planned for.  The first line in section 2.2 (page 2-3)
states that "The receptacle MUST be wired as shown in figure 2.2."

Figure 2.2 (same page, labeled "Wiring of Power Receptacle) indicates
some interesting power considerations to which I was unacustomed.  I had
no problem figuring out what to do with contact number 1 labled "frame
ground", and I assume that I can jumper "request to send" to "clear to
send", since I always want power flowing, but contacts 2 and 3 for
"received data" and "transmitted data" really have me confused.

Figure 2.2, although labeled "Wiring of Power Receptacle", depicts how to
turn two DB-25's into an RS-232 null modem.  Interesting, since the only
other place that this figure appears is on page 3-9 where it is identified
as Figure 3.6 and again as "Wiring of Power Receptacle", this time for
the C-60 and C-70 processors.

I suggest that BBN would be better off if they adopted the more standard
three wire (hot, neutral, and ground) system of power.

-Ron

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

END OF TCP-IP DIGEST
********************
-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 1983 1928-PDT
From:      Lynn Gold <FIGMO at KESTREL>
To:        VAF at CMU-CS-C, TCP-IP at SRI-NIC
Subject:   Re: FTP server lossage on TOPS-20 and Tenex sites
On Tenex, one connects to directories without typing in angle-brackets.
The CWD command on Tenex sites DOES do the right thing

How does Unix implement CWD?

--Lynn
-------
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      15 June 1983 00:00 EST
From:      TCP-IP@brl
To:        TCP-IP@brl
Subject:   TCP-IP Digest, Vol 2 #9
TCP/IP Digest          Wednesday, 15 June 1983     Volume 2 : Issue 9

Today's Topics:
              Pointer to Naming, Addressing, & Routing Memo
             Routing of Routing Messages -vs- Data Messages
                       Fix for BBN VAX TCP Problem
                Comments on SMTP Design Flaw + Discussion
              Request for TCP/IP Implementations on Micros
                  Wanted:  Spooled FTP for BBN UNIX TCP
----------------------------------------------------------------------
                  TCP/IP Digest --- The InterNet Digest
                         LIMITED DISTRIBUTION
          For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------

Date:  7 Jun 1983 1419-PDT
From: POSTEL@usc-isif
Subject: IEN-19: Names, Addresses, and Routes
To:   TCP-IP@brl

The memo by John Shoch titled "Inter-Network Naming, Addressing, and
Routing", issued as IEN 19 was produced using some fancy formating
and printing facilities at Xerox PARC and was distributed only in hardcopy.

The later (and improved) version of this memo with the same title was
presented at COMPCON Fall 1987.  The order number from the IEEE
Computer Society is CH1388-8/78-0000-0072.

--jon.

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

Date:  7 Jun 1983 1435-PDT
From: POSTEL@usc-isif
Subject: Routing Messages vs. Data Messages
To:   tcp-ip@brl

Ed Taft's comments on routing information exchange being distinct from the
actual routes that data traffic moves on are well taken.  One aspect of the
development of the Exterior Gateway Protocol (RFC 827) is to allow testing
of different routing procedures in subsets of gateways without interfering
with the actual transmission of data datagrams.  The logical systems of
gateways in EGP are independent of the actual network topology.

--jon.

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

Date:  8 Jun 1983  9:32:11 EDT (Wednesday)
From: Dennis Rockwell <drockwel@bbn-vax>
Subject: TCP problem
To: Rob Gurwitz <gurwitz@BBN-UNIX>, dpk@brl-vgr

[ This message was forwarded to the Digest by Doug Kingston, and details
  a particularly insidious bug in the BBN VAX TCP.  Hopefully, if any site
  using that code has not heard of this problem yet, this message will
  have served a purpose.  Note that Berkeley 4.1a and 4.1c code does
  not have this bug.  -Mike ]

The fix for this bug is as follows: (I'm afraid I have no
familiarity whatsoever with the TCP variants, but the
code should be fairly easy to find)

In the routine rcv_text (in tcp_procs.c in our code), the routine
that does the resequencing, there is the following code:

			/* new overlaps at beginning of successor frags */

			q = savq->t_next;
			while ((q != (struct th *)tp) && (t->t_len != 0) && 
			       SEQ_LEQ(q->t_seq, last))

				/* complete cover */

        			if (SEQ_LEQ(t_end(q), last)) {
					p = q->t_next;
					tcp_deq(q);
					m_freem(dtom(q));
					q = p;

				} else {		/* overlap */

In your code, the first SEQ_LEQ is probably a SEQ_LT.  This is the bug.
There is an analogous bug in ip_input.c:

			/* new overlaps at beginning of successor frags */

				q = savq->ip_next;
				while ((q != (struct ip *)fp) &&
					(ip->ip_len != 0) && 
					(q->ip_off <= ip->ip_end)) 

					/* complete cover */

					if (q->ip_end <= ip->ip_end) {
						p = q->ip_next;
						ip_deq(q);
						m_freem(dtom(q));
						q = p;

Again, in your code the first <= is probably a <.

This fix was made just last week, and is slowly percolating out to the
other local BBN sites.  We are trying to spread this fix around, but
that's difficult.  Please tell everybody you know who is running this
code about the fix.

Good luck!  Feel free to write or call me at (617) 497-2643.

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

Date:     8 Jun 83 5:39:10 EDT (Wed)
From:     Doug Kingston  <dpk@BRL-VGR>
To:       tcp-ip@BRL-VGR
Subject:  SMTP Design Flaw

	SMTP as it currently stands has a serious flaw from the
point of view of fault-tolerant software.   The crux of the problem
is that the reply codes reuse certain values in different contexts.
This opens the possibility of of mis-interpreting replies in the
case where the user-smtp or the transmission channel is generating
spurious data.  A similiar problem exists if the smtp server
generates spurious responses.

	If both sides are bug-free, there will be no problems.
But, the world of software is seldom if ever bug-free.  A prudent
implementer plans for the inevitable error to be made by the
hardware, his own software, or someone else's software.  Spurious
commands or spurious responses can cause the server/user pair to
get out of sync without either being able to conclusively detect
the situation.

	The worst problem exists for the 250 reply which is the
affirmative reply from HELO, MAIL, RCPT, "final dot", and RSET
to name only the most commonly used commands.  The 500, 501, and
503 commands are also dangerously overloaded.

	Senarios:
			RCPT -->
unknown to sender	junk -->
			     <-- 250
			DATA -->
			     <-- 500  (actually reply to junk)
		Result: Mail is returned wrongfully.

		    ********************

			RCPT -->
unknown to sender      junk1 -->
		       junk2 -->	(we are now off by two...)
			     <-- 250
			RCPT -->
			     <-- 500  (actually reply to junk1)
		<Mail is returned here wrongfully>
			DATA -->
			     <-- 500  (actually reply to junk2)
we detect problem	RSET -->
			     <-- 250  (actually reply to second RCPT !!!)
			MAIL -->
			     <-- 354  (bletch.) (Protocol errror)
			RSET -->
			     <-- 250  (reply to first RSET!!!!!)
			MAIL -->
			     <-- 250  (reply to first MAIL...
			RCPT -->
			     <-- 250  (reply to second RSET...
			RCPT -->
			     <-- 250  (reply to second MAIL...

			... until we get to the DATA command again.
			
		Result: Mail is returned wrongfully.

		    ********************

			RCPT -->
unknown to sender	junk -->
			     <-- 250
			RCPT -->
			     <-- 500 (response to junk)
		<mail is returned here>
			RCPT -->
			     <-- 250 (response to SECOND rcpt command!!!)

		    ********************

			RCPT -->
unknown to sender	RCPT -->
			     <-- 250
			RCPT -->
			     <-- 250 (response to Second RCPT !!!)
			RCPT -->
			     <-- 250 (response to Third RCPT !!!)
			DATA -->
			     <-- 250 (response to Fourth RCPT !!!)

		    ***********************

	As I see it, there are two things that can be done done to
help out this situation.  First, the reply codes should be unique
for each command.  This would give the USER SMTP the ability to
detect sequencing errors from syntax or argument errors which
some hosts give on hosts they don't know how to reach, but I wont
drag the offenders out into public here.  They know who they are.

	Second, and perhaps more radical, is to add a sequence number
each command/reply pair.  Each command would be sent with a sequence
number.  The reply to that command would have to contain the same
sequence number.  This would allow both the server and user SMTP
to detect sequenceing errors.  I feel that this would be the most
prudent and reliable mechanism for detecting these faults.

	This problem is not just a figment of my imagination. This
very problem has plagued mail between out sites and sites running
BBN based TCP implementations for about a month now.  The spurious
input was probably induced by a bug in the BBN TCP's handling
of the sequenceing and/or retransmission or large numbers of incoming
1 character packets due to a bug in my mailer that caused it not to
buffer its output.

				Comments and Discussion are Welcomed
						-Doug-

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

Date:  8 Jun 1983 1445-PDT
From: POSTEL at USC-ISIF
Subject: Re: SMTP Design Flaw
To:   dpk at BRL-VGR, tcp-ip at BRL-VGR

Doug:

SMTP explicitly requires that it be operated on a reliable channel
(such as provided by TCP).  The situation you suggest does not arise
because of "junk" being inserted in the channel unknown to the sender.
There was (still is?) a totally bogus "implementation" of SMTP that sent
several commands in succession without even looking at the replies.  I
suggest that it is better to assume a reliable channel than to reimplement
TCP inside of SMTP, and to stomp out bad implementations of SMTP as soon
as we see them.

--jon.

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

Date:     8 Jun 83 18:13:50 EDT (Wed)
From:     Doug Kingston  <dpk@BRL-VGR>
To:       POSTEL@Usc-Isif
cc:       dpk@BRL-VGR, tcp-ip@BRL-VGR
Subject:  Re:  SMTP Design Flaw

Jon,

	I do not dispute that the problem is induced by a faulty
SMTP or channel.  I am arguing for cheap enhancements the buy
us a great deal of fault tolerance.  Obviously we're not going to
change SMTP, but I think this should be kept in mind for later
incarnations.  Faults will occur.  Mail software should make
every effort to detect and deal with errors.  We need to give
it a mechanism, and it doesn't have to be complicated.

			The problem with bugs is
			  that is they're so ingenious,
					-Doug-

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

Date: 9 Jun 1983 17:53:43-PST
From: ram.arizona@rand-relay
Subject: TCP/IP on Micros?
To: tcp-ip-request.brl@rand-relay

[ Anybody having information about micro implementations, please feel
  free to either contact Ralph directly, or to submit a message to the
  digest for all to see.  -Mike ]

I am interested in locating information on tcp/ip implementations on
microcomputer systems.  Specifically, on the LSI-11/23, 68000, and 8086.
I would like to know the language, operating system, and availability of
such implementations (costs).  Thanks for passing on this request.

----Ralph Martinez (ram.arizona@rand-relay)
    University of Arizona

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

Date: 9 Jun 1983 8:36-PDT (Thursday)
From: Jim Rees <jim@uw-beaver>
Subject: Want spooled FTP for BBN Unix TCP
To: tcp-ip@brl, bbn-tcp@bbn-vax

I am running BBN's TCP on a Vax with 4.1bsd.  I want a spooled FTP,
something like uucp, to run over the net between Unix machines.  Has
anyone already done this?  Does anyone have bright ideas?

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

END OF TCP-IP DIGEST
********************
-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Jun-83 23:41:01 EDT
From:      TCP-IP%brl@brl-bmd.UUCP
To:        fa.tcp-ip
Subject:   TCP-IP Digest, Vol 2 #9


TCP/IP Digest          Wednesday, 15 June 1983     Volume 2 : Issue 9

Today's Topics:
              Pointer to Naming, Addressing, & Routing Memo
             Routing of Routing Messages -vs- Data Messages
                       Fix for BBN VAX TCP Problem
                Comments on SMTP Design Flaw + Discussion
              Request for TCP/IP Implementations on Micros
                  Wanted:  Spooled FTP for BBN UNIX TCP
----------------------------------------------------------------------
                  TCP/IP Digest --- The InterNet Digest
                         LIMITED DISTRIBUTION
          For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------

Date:  7 Jun 1983 1419-PDT
From: POSTEL@usc-isif
Subject: IEN-19: Names, Addresses, and Routes
To:   TCP-IP@brl

The memo by John Shoch titled "Inter-Network Naming, Addressing, and
Routing", issued as IEN 19 was produced using some fancy formating
and printing facilities at Xerox PARC and was distributed only in hardcopy.

The later (and improved) version of this memo with the same title was
presented at COMPCON Fall 1987.  The order number from the IEEE
Computer Society is CH1388-8/78-0000-0072.

--jon.

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

Date:  7 Jun 1983 1435-PDT
From: POSTEL@usc-isif
Subject: Routing Messages vs. Data Messages
To:   tcp-ip@brl

Ed Taft's comments on routing information exchange being distinct from the
actual routes that data traffic moves on are well taken.  One aspect of the
development of the Exterior Gateway Protocol (RFC 827) is to allow testing
of different routing procedures in subsets of gateways without interfering
with the actual transmission of data datagrams.  The logical systems of
gateways in EGP are independent of the actual network topology.

--jon.

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

Date:  8 Jun 1983  9:32:11 EDT (Wednesday)
From: Dennis Rockwell <drockwel@bbn-vax>
Subject: TCP problem
To: Rob Gurwitz <gurwitz@BBN-UNIX>, dpk@brl-vgr

[ This message was forwarded to the Digest by Doug Kingston, and details
  a particularly insidious bug in the BBN VAX TCP.  Hopefully, if any site
  using that code has not heard of this problem yet, this message will
  have served a purpose.  Note that Berkeley 4.1a and 4.1c code does
  not have this bug.  -Mike ]

The fix for this bug is as follows: (I'm afraid I have no
familiarity whatsoever with the TCP variants, but the
code should be fairly easy to find)

In the routine rcv_text (in tcp_procs.c in our code), the routine
that does the resequencing, there is the following code:

			/* new overlaps at beginning of successor frags */

			q = savq->t_next;
			while ((q != (struct th *)tp) && (t->t_len != 0) &&
			       SEQ_LEQ(q->t_seq, last))

				/* complete cover */

        			if (SEQ_LEQ(t_end(q), last)) {
					p = q->t_next;
					tcp_deq(q);
					m_freem(dtom(q));
					q = p;

				} else {		/* overlap */

In your code, the first SEQ_LEQ is probably a SEQ_LT.  This is the bug.
There is an analogous bug in ip_input.c:

			/* new overlaps at beginning of successor frags */

				q = savq->ip_next;
				while ((q != (struct ip *)fp) &&
					(ip->ip_len != 0) &&
					(q->ip_off <= ip->ip_end))

					/* complete cover */

					if (q->ip_end <= ip->ip_end) {
						p = q->ip_next;
						ip_deq(q);
						m_freem(dtom(q));
						q = p;

Again, in your code the first <= is probably a <.

This fix was made just last week, and is slowly percolating out to the
other local BBN sites.  We are trying to spread this fix around, but
that's difficult.  Please tell everybody you know who is running this
code about the fix.

Good luck!  Feel free to write or call me at (617) 497-2643.

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

Date:     8 Jun 83 5:39:10 EDT (Wed)
From:     Doug Kingston  <dpk@BRL-VGR>
To:       tcp-ip@BRL-VGR
Subject:  SMTP Design Flaw

	SMTP as it currently stands has a serious flaw from the
point of view of fault-tolerant software.   The crux of the problem
is that the reply codes reuse certain values in different contexts.
This opens the possibility of of mis-interpreting replies in the
case where the user-smtp or the transmission channel is generating
spurious data.  A similiar problem exists if the smtp server
generates spurious responses.

	If both sides are bug-free, there will be no problems.
But, the world of software is seldom if ever bug-free.  A prudent
implementer plans for the inevitable error to be made by the
hardware, his own software, or someone else's software.  Spurious
commands or spurious responses can cause the server/user pair to
get out of sync without either being able to conclusively detect
the situation.

	The worst problem exists for the 250 reply which is the
affirmative reply from HELO, MAIL, RCPT, "final dot", and RSET
to name only the most commonly used commands.  The 500, 501, and
503 commands are also dangerously overloaded.

	Senarios:
			RCPT -->
unknown to sender	junk -->
			     <-- 250
			DATA -->
			     <-- 500  (actually reply to junk)
		Result: Mail is returned wrongfully.

		    ********************

			RCPT -->
unknown to sender      junk1 -->
		       junk2 -->	(we are now off by two...)
			     <-- 250
			RCPT -->
			     <-- 500  (actually reply to junk1)
		<Mail is returned here wrongfully>
			DATA -->
			     <-- 500  (actually reply to junk2)
we detect problem	RSET -->
			     <-- 250  (actually reply to second RCPT !!!)
			MAIL -->
			     <-- 354  (bletch.) (Protocol errror)
			RSET -->
			     <-- 250  (reply to first RSET!!!!!)
			MAIL -->
			     <-- 250  (reply to first MAIL...
			RCPT -->
			     <-- 250  (reply to second RSET...
			RCPT -->
			     <-- 250  (reply to second MAIL...

			... until we get to the DATA command again.

		Result: Mail is returned wrongfully.

		    ********************

			RCPT -->
unknown to sender	junk -->
			     <-- 250
			RCPT -->
			     <-- 500 (response to junk)
		<mail is returned here>
			RCPT -->
			     <-- 250 (response to SECOND rcpt command!!!)

		    ********************

			RCPT -->
unknown to sender	RCPT -->
			     <-- 250
			RCPT -->
			     <-- 250 (response to Second RCPT !!!)
			RCPT -->
			     <-- 250 (response to Third RCPT !!!)
			DATA -->
			     <-- 250 (response to Fourth RCPT !!!)

		    ***********************

	As I see it, there are two things that can be done done to
help out this situation.  First, the reply codes should be unique
for each command.  This would give the USER SMTP the ability to
detect sequencing errors from syntax or argument errors which
some hosts give on hosts they don't know how to reach, but I wont
drag the offenders out into public here.  They know who they are.

	Second, and perhaps more radical, is to add a sequence number
each command/reply pair.  Each command would be sent with a sequence
number.  The reply to that command would have to contain the same
sequence number.  This would allow both the server and user SMTP
to detect sequenceing errors.  I feel that this would be the most
prudent and reliable mechanism for detecting these faults.

	This problem is not just a figment of my imagination. This
very problem has plagued mail between out sites and sites running
BBN based TCP implementations for about a month now.  The spurious
input was probably induced by a bug in the BBN TCP's handling
of the sequenceing and/or retransmission or large numbers of incoming
1 character packets due to a bug in my mailer that caused it not to
buffer its output.

				Comments and Discussion are Welcomed
						-Doug-

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

Date:  8 Jun 1983 1445-PDT
From: POSTEL at USC-ISIF
Subject: Re: SMTP Design Flaw
To:   dpk at BRL-VGR, tcp-ip at BRL-VGR

Doug:

SMTP explicitly requires that it be operated on a reliable channel
(such as provided by TCP).  The situation you suggest does not arise
because of "junk" being inserted in the channel unknown to the sender.
There was (still is?) a totally bogus "implementation" of SMTP that sent
several commands in succession without even looking at the replies.  I
suggest that it is better to assume a reliable channel than to reimplement
TCP inside of SMTP, and to stomp out bad implementations of SMTP as soon
as we see them.

--jon.

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

Date:     8 Jun 83 18:13:50 EDT (Wed)
From:     Doug Kingston  <dpk@BRL-VGR>
To:       POSTEL@Usc-Isif
cc:       dpk@BRL-VGR, tcp-ip@BRL-VGR
Subject:  Re:  SMTP Design Flaw

Jon,

	I do not dispute that the problem is induced by a faulty
SMTP or channel.  I am arguing for cheap enhancements the buy
us a great deal of fault tolerance.  Obviously we're not going to
change SMTP, but I think this should be kept in mind for later
incarnations.  Faults will occur.  Mail software should make
every effort to detect and deal with errors.  We need to give
it a mechanism, and it doesn't have to be complicated.

			The problem with bugs is
			  that is they're so ingenious,
					-Doug-

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

Date: 9 Jun 1983 17:53:43-PST
From: ram.arizona@rand-relay
Subject: TCP/IP on Micros?
To: tcp-ip-request.brl@rand-relay

[ Anybody having information about micro implementations, please feel
  free to either contact Ralph directly, or to submit a message to the
  digest for all to see.  -Mike ]

I am interested in locating information on tcp/ip implementations on
microcomputer systems.  Specifically, on the LSI-11/23, 68000, and 8086.
I would like to know the language, operating system, and availability of
such implementations (costs).  Thanks for passing on this request.

----Ralph Martinez (ram.arizona@rand-relay)
    University of Arizona

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

Date: 9 Jun 1983 8:36-PDT (Thursday)
From: Jim Rees <jim@uw-beaver>
Subject: Want spooled FTP for BBN Unix TCP
To: tcp-ip@brl, bbn-tcp@bbn-vax

I am running BBN's TCP on a Vax with 4.1bsd.  I want a spooled FTP,
something like uucp, to run over the net between Unix machines.  Has
anyone already done this?  Does anyone have bright ideas?

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

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

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 1983 07:57:21-PDT
From:      bierma@NPRDC
To:        tcp-ip@sri-nic
Cc:        bierma@NPRDC, buckingh@NPRDC
Subject:   looking for a TCP/IP implementation for a IBM 4341.
I am trying to set up a full service communications link between my VAX 
and an IBM 4341 that is about 400 feet away in another building.  The
4341 is running VM/370 and the VAX is running 4.1 UNIX (with BBN TCP/IP).
Ideally I am looking for an implementation of TCP/IP that runs under
VM/370 and network hardware that is compatible with both the VAX and
the 4341 (ethernet?).  When I asked the IBM rep her answer was "What's
TCP/IP?". Oh, Well so much for "No. 1".

--Larry Bierma <bierma@nprdc>
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 1983 1740-PDT
From:      BRADEN at USC-ISI
To:        bierma at NPRDC, tcp-ip at SRI-NIC
Cc:        buckingh at NPRDC, BRADEN at USC-ISI
Subject:   Re: looking for a TCP/IP implementation for a IBM 4341.
In response to the message sent  16 Jun 1983 07:57:21-PDT from  bierma <bierma@NPRDC>

Larry,

Actually, IBM corporate is getting concerned about TCP/IP, since the govt
is starting to wave the DDN stick at them.  The prospect of not being able
to bid on contracts for 20 CPUs at once has them at least concerned.

We at UCLA have a TCP/IP for OS/MVS, driving an 1822 interface to the
ARPANET.  One will soon be able to buy a Series 1 that has an HDH
interface, also.

For VM software, I suggest you talk to Doug McKay at IBM FSD.
(301) 921 1914.

We are quite concerned about local network interface hardware...
Ethernet, Pronet, ... I would be interested in any leads you get
on this.  A number of other IBM sites are also interested.

Bob Braden

-------
-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 1983 1815-PDT
From:      Dan Whelan <DAN@CIT-20>
To:        bierma@NPRDC, braden@USC-ISI, tcp-ip@SRI-NIC
Subject:   TCP for an IBM 4341

	We at Caltech are also concerned about TCP for a 4341 since IBM is
upstairs right now installing one. We have a systems programmer who is
interested in implementing TCP/IP under VM/CMS. Of course, we would rather
port an exisiting implementation. We plan to connect our 4341 to our local
Ethernet through its UNIBUS. Thats right, our 4341 has a UNIBUS. It appears
IBM is now manufacturing a device called a DACU which is an IBM PC with
a UNIBUS that attaches to a channel. Like the others, we'd welcome any
suggestions.
						    Dan Whelan
-------
-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Thu 16 Jun 83 23:07:49-PDT
From:      Richard R. Cower <COWER@SRI-KL.ARPA>
To:        DAN@CIT-20.ARPA, bierma@NPRDC.ARPA, braden@USC-ISI.ARPA, tcp-ip@SRI-NIC.ARPA
Cc:        COWER@SRI-KL.ARPA
Subject:   Re: TCP for an IBM 4341
Where can one get information on the PC with a Unibus on the channel?
Stanford hung an 11 on a channel - wonder if it is a similar device?

.Thanks..Rich Cower
-------
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 1983 0946-PDT
From:      MILLS at USC-ISID
To:        COWER at SRI-KL, DAN at CIT-20, bierma at NPRDC, braden at ISI, tcp-ip at SRI-NIC
Cc:        MILLS at USC-ISID, Mike at UMD2, Louie at UMD2
Subject:   Re: TCP for an IBM 4341
In response to the message sent  Thu 16 Jun 83 23:07:49-PDT from COWER@SRI-KL.ARPA

Folks,

Several years ago I designed an interface to the IBM multiplexor channel
when I was at the University of Michigan. After I left they updated that
interface, which is still in use, for a number of PDP11s used for data
concentration and distribution. Call Mr. Dave Flower at the U of M
Computing Center in Ann Arbor for further details. The interface was 
capable of emulating a 270x controller, as well as more exciting
devices and also supported a two-channel switch.

Regards,
Dave
-------
-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 1983 1904-EDT
From:      Chris Ryland <CPR@MIT-XX>
To:        bierma@NPRDC, tcp-ip@SRI-NIC
Cc:        buckingh@NPRDC
Subject:   Re: looking for a TCP/IP implementation for a IBM 4341.
Try Larry Landweber at U Wisc: 608-262-14, for info about an IBM VM
TCP/IP implementation supposedly finished in August.

/Chris
-------
-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      18 June 1983 02:31 EDT
From:      Ken Harrenstien <KLH @ MIT-MC>
To:        tcp-ip @ SRI-NIC
Subject:   Possible ISIB TCP bug
I have fairly good proof that ISIB's TCP (or its FTP server) is not
working properly, as documented in the following message.  I have not
received any comments from the original addressees and so am forwarding
it to a wider distribution in the hope that it will reach someone who
may be able to shed more light on the problem.  It still exists;
I reproduced it again just now.
		------------------
Date: 2 June 1983 21:19 EDT
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: Possible ISIB TCP problem
To: postel @ USC-ISIF, clynn @ BBNA, clements @ BBNA,
    jgoldberger @ USC-ISIB
cc: BUG-TCP @ MIT-MC, ELLEN @ MIT-MC, BDB @ MIT-MC

	A user here has managed to isolate a reproducible problem that
at first glance appears to be the fault of the ISIB TCP or FTP server.
The file CRASH2;ISIB FTP contains a photo-like log of the session
which ran into the problem.  Briefly, an attempt to make an ASCII
transfer of the file <info-ibmpc>kermit.protocol from ISIB (server) to
MIT-MC (user) fails near the end; the data connection hangs for a
couple of minutes and is then aborted by ISIB.  The server claims that
the transfer was completed, however.

This appears to be completely reproducible.  I made a packet log
of one such instance, which can be found in the files
	CRASH2;TCPB X1
	CRASH2;TCPB X2
	CRASH2;TCPB X3

The first one shows the data connection being established and the
last file shows the terminating RST coming from ISIB.  The middle one
is just plain data transfer stuff.  I have not attempted to edit them
down to a smaller size since I am not sure what you might find
significant.

Also, the files CRASH2;KERMIT TRUNC and CRASH2;KERMIT PROTO contain
copies of the truncated and complete transfers respectively.
(the latter file was obtained by FTP'ing it to LLL-MFE and thence
to MIT-MC).

Some comments on the last few datagrams in the log:

	From what I can see, MIT-MC is not doing anything wrong.
The last data segment from ISIB is ACKed properly; after this there
is a long pause (note the timestamps -- about 1.5 minutes!) and
the RST comes in out of the blue.  The log shows everything
that MIT-MC sent to or received from ISIB for the period that
the log was active - as long as the IP address matches ISIB, the
datagram is logged whether or not it is illegal in any way.
(obviously I had to wait until no one else on MC was talking to ISIB!)
Thus, ANYTHING wrong with the TCP headers/data would have appeared in
the log (even if the datagram wasn't identifiable as a TCP datagram!)
Nothing like that appears.

	Possibly it is a FTP server problem wherein the data fork is
being killed (thus resetting the data connection) prematurely.  But
why is the problem apparently specific to requests from MIT-MC?
(I haven't tried it from other places actually; maybe LLL-MFE
was just lucky or something).

Let me know if there is anything more I can do to help track this down.
--Ken
		---------------

Postscript:
 My current theory is that MIT-MC's window updates just happen to come
in the right sizes to tickle a bug in the TOPS-20 TCP code, which in
the past has been found to be sensitive to datagram/buffer sizes.  Or
there may be a bug in the ISI code which takes ACK'd segments off the
retransmission queue; transmissions to MC may exercise this more
frequently since MC does not retain out-of-order segments (a slower,
but perfectly legal tactic).

Again, the log is convincing proof that ISIB is spazzing.  I am
hoping that someone out there will have an idea why, and perhaps
be able to suggest a fix.

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      18 June 1983 1026-EDT
From:      Rudy.Nedved@CMU-CS-A
To:        Ken Harrenstien <KLH@MIT-MC>
Cc:        tcp-ip@SRI-NIC
Subject:   Re: Possible ISIB TCP bug
Ken,

I suspect ISIB FTP server uses TCPSIM and that TCPSIM just aborts the
data transfer connection. If I remember correctly, Vince Fuller said
that the PAGED ASCII data connections are never closed and that he
could not get non-PAGED ASCII transfers to work "correctly". The user
process used a timeout to determine the eof instead of actual EOF
signal from the TCP JSYS. When we did change the user process to
wait and do closes on the TCP JCNs...we got BUGxxxs..sso we added a
abort after the close and that did the trick.

TOPS-20 people should get from Vince Fuller (VAF@CMU-CS-C) his
version of TCPSIM...he also has an excellent user FTP that
uses COMND% (this is CMU-CS-C system FTP).

-Rudy
-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      18 June 1983 11:19 EDT
From:      David C. Plummer <DCP @ MIT-MC>
To:        tcp-ip @ SRI-NIC
Cc:        KLH @ MIT-MC, Rudy.Nedved @ CMU-CS-A
Subject:   Re: Possible ISIB TCP bug

    I suspect ISIB FTP server uses TCPSIM and that TCPSIM just aborts the
    data transfer connection. If I remember correctly, Vince Fuller said
    that the PAGED ASCII data connections are never closed and that he
    could not get non-PAGED ASCII transfers to work "correctly". The user
    process used a timeout to determine the eof instead of actual EOF
    signal from the TCP JSYS. When we did change the user process to
    wait and do closes on the TCP JCNs...we got BUGxxxs..sso we added a
    abort after the close and that did the trick. 

What ever happened to the Completeness, Correctness, Cleanness
(??) and Robustness principles?  It is messages like the above
pointing out implementation deficiencies (for whatever reason) in
a major operating system that require kludges to bypass (not
implementaion corrections) that convince me TCP/IP is not as
sound as it should be 6 months after enforcement.  Sometimes it
is amazing we can even send mail to each other...

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Sat 18 Jun 83 14:53:55-PDT
From:      Mark Crispin <MRC@SU-SCORE.ARPA>
To:        Rudy.Nedved@CMU-CS-A.ARPA
Cc:        KLH@MIT-MC.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Possible ISIB TCP bug
Rudy -

     This is why I didn't use TCPSIM in MMailr (the TOPS-20 mail delivery
process) or in Telnet.  In Telnet I foolishyy used the TCP jsi directly
without benefit of any packages to assist.  When I did the mailsystem I
had learned my lesson and wrote the TCPIO package.

     I spent a significant amount of time reading through TCPSIM and the
monitor's TCPTCP module in developing TCPIO.  I suspect that the unknown
author of TCPSIM (1) never finished it, (2) never looked at the actual
monitor code and relied only the sketchy documentation, or (3) wrote
TCPSIM for an earlier version of TCP.  I suspect (3) is what actually
hapened.  TCPSIM fails to consider a number of cases of transient errors
which happen an alarming percentage of the time.

     In overall reliability, I suspect that TCPIO is superior to TCPSIM.
It does have two drawbacks; it was primarily written for the mailsystem
and hence didn't go to much effort to support multiple simultaneous
connections.  Some hooks are there but it isn't complete.  Also, the
sending logic isn't as efficiently-coded as it should be; it was optimized
for small bursts of data rather tha  large data streams.  I would do it
differently today.

     However, if anybody wants it, it is on MRC:<MM>TCPIO.MAC at Score.
It is written in "TOPS-20" (also known as "creole"), a structured programming
language using machine instructions as part of its non-control primitives.

-- Mark --
-------
-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Sat 18 Jun 83 16:25:30-PDT
From:      Mark Crispin <MRC@SU-SCORE.ARPA>
To:        DCP@MIT-MC.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, KLH@MIT-MC.ARPA, Rudy.Nedved@CMU-CS-A.ARPA
Subject:   Re: Possible ISIB TCP bug
David -

     The problem with TCPSIM and TOPS-20's TCP implementation is
not an "implementation eeficiency", nor is it a problem with TCP
itself.  An implementation deficiency requires an implementation
and it's implied that the implementation is finished.  The
present TOPS-20 TCP is an interim implementation that was for a
while mistaken as a final product by certain individuals.  Sites
such as Score which are multi-homed or dare to use non-ARPANET
networks (and therefore are "not supported") see ample evidence
of this -- Score crashes two or three times daily due to bugs in
the TCP code.

     For he non-TOPS-20 people receiving this, the problem is,
briefly: most TOPS-20 I/O is expressed in byte-stream form.  The
system calls on TOPS-20 to do TCP, however, are more segment or
record oriented.  Consequently, a good deal of the work of
segmenting and buffering has to be done by the user process.  To
work around this problem, there is a package called TCPSIM which
is intended to simulate traditional TOPS-20 I/O.  This package,
unfortunately, has problems.  Another package exists called TCPIO
which, in oome ways, is better.

     Whether TOPS-20 TCP will be finalized by rewriting it or by
hacking the current code into final form remains to be seen.  DEC
claims to have implemented byte-stream I/O in their TCP, so with
any luck both TCPSIM and TCPIO will be obsolete soon.  Now, if
only Multinet worked better...

-- Mark --
-------
-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      18 June 1983 22:14 EDT
From:      David C. Plummer <DCP @ MIT-MC>
To:        MRC @ SU-SCORE
Cc:        DCP @ MIT-MC, KLH @ MIT-MC, JTW @ MIT-MC, tcp-ip @ SRI-NIC, Rudy.Nedved @ CMU-CS-A
Subject:   Re: Possible ISIB TCP bug
Indeed, TCPSIM appears broken in the context of the current
implementation of TCP for TOPS-20.  Some comments:

I find it a fundamental design flaw that it was not implemented
as byte streams to begin with.  TCP is defined (last I looked) as
a byte stream ans has certain out of band signals (e.g., push and
urgent) that can be detected, if necessary, by interrupts.  Also,
last I looked, there is no provision in TCP to transmit a
"record" from one end of a connection to the other without
layering a record format on top of the byte stream.  Urgent and
push are not sufficient since they may be merged.

I certainly hope DEC's implementation implements BIN, BOUT, SIN,
SOUT, etc on TCP JFNs and has MTOPRs (or whatever) to do the
special things.  If not, I would hope somebody (or group) would
do it so we no longer have the need for TCPSIM and TCPIO.  I
assume nobody has because of the rumors about DEC's
implementation.

If you have had specific experiences with Multinet, JTW@MC
(actually MIT-SPEECH) and I would like to hear about them.  MIT
also has an unofficial network (i.e., CHAOS) which currently fits
into the monitor on the side of everything else.  JTW would love
to use Multinet to make things coexist better, especially with
TCP/IP.  Any known pitfalls would be appreciated.  (They needn't
go to tcp-ip@sri-nic.)

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      18 June 1983 2230-EDT
From:      Rudy.Nedved@CMU-CS-A
To:        David C. Plummer <DCP@MIT-MC>
Cc:        MRC@SU-SCORE, DCP@MIT-MC, KLH@MIT-MC, JTW@MIT-MC, tcp-ip@SRI-NIC, Rudy.Nedved@CMU-CS-A
Subject:   Re: Possible ISIB TCP bug
CMU has a mutli-homed TOPS-20 machine like SU-Score...one side is ARPANET
and the other side is 3MB Ethernet. We would like to hear about problems
and solutions that people have had or are having...why not send the information
to either TOPS-20@SU-Score or TCP-IP-TOPS20 (If such a list exists)??

Thanks,
-Rudy
-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 1983 1112-PDT
From:      Henry W. Miller <Miller at SRI-NIC>
To:        scohn at BBN-UNIX, lieberman at OFFICE-1, tharris at DDN1, jmayersohn at BBN-UNIX, ddnsr at BBN-UNIX, nmimno at BBN-UNIX, dball at OFFICE-2, snelson at OFFICE-1, bhitson at BBN-UNIX, tcp-ip at BRL, tcp-ip, tcp-ip-tops20 at SRI-NIC, tops-20 at SU-SCORE
Cc:        Miller
Subject:   Re: TCP & Gateway Pinging
Steve,

	Thank you for your deductions on this.  I believe that you will
find all or most of the TOPS20 and TENEX sites on the network exhibiting
this behavior, since we are running variants of the same code.  However,
the pinging algorithim should be sufficiently similar in all the
implementations to exhibit the same bad manners.  The exceptions, as
far as I can see are those hosts who have edited entries out of their
gateway tables.

	As far as I know, 37 seconds is the standard inter-ping
interval.  From conversations with Dave Mills and Mike Brescia,
this interval is way too short, and results with the poor gateways
being flooded by probes at a high rate.  This congests them as well,
and hampers communications with other nets.  The value of PINGT0
in the monitor should be raised to a higher value.  We are currently
using about a 1 minute interval, and may raise that if the results
warrant it.

	There are many other things that the code may be doing
wrong, but more research is needed.

-HWM
-------
-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 1983 13:37:21 EDT (Monday)
From:      Steven Cohn <scohn@BBN-UNIX>
To:        lieberman@office-1, tharris@ddn1, jmayersohn@bbn-unix, ddnsr@BBN-UNIX, nmimno@bbn-unix, dball@office-2, snelson@office-1, bhitson@bbn-unix, tcp-ip@brl, tcp-ip@sri-nic, tcp-ip-tops20@sri-nic, tops-20@su-score
Cc:        scohn@BBN-UNIX
Subject:   TCP & Gateway Pinging
In the course of studying the long delays and other problems experienced
by users of the TYMSHARE-43 Office machines 1,2,3, and 7, some undesirable
aspects of the TCP implementation at TYMSHARE were uncoveed.  We have not
yet examined the rest of the IMPs on the ARPANET to determine if other
hosts are suffering from the same disease, but have reason to suspect
TENEX and TOPS-20 TCP implementations.

TYMSHARE's TCP running on OFFICE-1 and OFFICE-2 had built into it a
clumsy approach to maintaining a table on the status of internet gateways.
Generally it is unnecessary to communicate with a gateway unless one
has traffic destined for that gateway, however, both hosts were regularly
"pinging", or exchanging single messages, with each of 23 gateways, at
the interval of 37 seconds.  This is unnecessary for TYMSHARE as none
of its users accesses the ARPANET through a gateway.  It also may have
contributed some of the degradation of service that they have observed.
This last point has not yet been demonstrated, but as I explain below,
there is good reason to suspect this.

Here is the scenario.  TYMSHARE-43 is a c/30 IMP running 4305.  This 
provides for 56 end-to-end connections.  TYMSHAR  has 4 real hosts
which, during one of my 5-minute measurements, 
sent substantial numbers of messages to 15 different hosts on
the ARPANET.  However, as their implementation of TCP,
combined with its interaction with 1822, uses the handling
type field, each of these logical connections may result in several subnetwork
connections.  (This results from a misinterpretation of the implementation
specifications in BBN Report 1822 on the interconnection of a host and IMP.
We are presently considering what the right policy on this matter should be.
Handling type should generally be set to zero.  If messages are submitted
on a single host-to-host connection with different handling types then
a separate connection will be set up for each type.  We have observed
as many as 5 different subnetwork connections between a pair of hosts.
This is undesirable for two reasons.  First, since messages in the same
stream will be sent on different connections, the IMPs will not deliver them in
order so that the TCP will have to reorder them;  messages on the same
connection are always delivered in correct order.  Second, having more
connections open drains the resources of the IMP.  This can be quite serious,
as I explain below.  Furthermore, it is not at all clear that there are any
benefits to maintaining multiple connections.)

Here's the problem.  Two of the hosts on TYMSHARE-43 ping
each of the 23 gateways every 37 seconds.  (CUMSTATS, after much scrutiny,
exposed this.)  These possibly also have variable handling type.  Thus this
configuration can easily consume the available connection resources in
the IMP which means that each time either of the hosts pings a gateway
it will probably need to set up a new connection.  (EESTATS over a 1-hour
period showed that the IMP was resetting its transmit blocks once every
1.07 seconds, on average.)

Assuming a new connection is required for each ICMP ping of a gateway, then
each host is blocked every 37/23 = 1.6 seconds for as long as it takes to
set up a connection.  (When the ping message is submitted the interface blocks
until a message number is obtained.  Since there is no existing connection
a connection must be established before obtaining a message number and
queuing the message.)  Measured roundttrip times for messages originating
at TYMSHARE-43 (using CUMSTATS) range between 440 and over 600 ms, averaged
over 1-hour periods.  Minute-by-minute fluctuations presumably result in
higher values at times.  If we assume a 600 ms round-trip time then it
takes at least 600 ms to set up a connection to a gateway and dispatch
the ping.  During this time nothing else can be submitted to the net by that
host.  Thus, using the above values, the two host would each be blocked
600 ms out of each 1.6 seconds or almost 40 % of the time.  If the ICMP pings
are bunched this could lead to higher blockage rates for particular intervals.

This can have at least two adverse effects.  First, it will certainly impact
host throughput if its interface is blocked 40 % of the time on useless
persuits, at least from TYMSHARE's perspective.  Second, it cannot be useful
to the gateways to be pinged this often by however many hosts on the
ARPANET happen to be running this code.  (Incidentally, we will soon
run measurements to try to identify any other culprits.)

When I explained this all to Robert Lieberman at TYMSHARE he discovered,
via some softwarepeople at SRI, that the timer in the TCP code which
controlled this gateway pinging could be easily adjusted and since his hosts
do not talk to gateways he set the timer to 280 minutes, effectively disabling
the pinging so that we can observe the effect on performance.  
Our hope is that this will yield improved service
for the STLA-61 users of TYMSHARE hosts.  Basically this approach to 
the gateways is inadequate and must be replaced.  Just setting the timers
is not an adequate solution, although useful immediately.

It is not known if this contention for connections is degrading service for
other hosts on the network.  However, the mechanism explained above may
very well be impacting your network performance without being obvious.  It
happens, for example, that this mechanism does not produce any kind of trap
that would signal a problem to network operators because, while the host
may be blocked much of the time, it is not blocked for an extended period
e.g. 3 seconds. 

I would appreciate hearing about any other cases, suspected or proven,
where connection contention causes degraded service.
Remember, the ARPANET is NOT just a datagram network.

Regards,

Steve Cohn
-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      21 June 1983 00:00 EST
From:      TCP-IP@brl
To:        TCP-IP@brl
Subject:   TCP-IP Digest, Vol 2 #10
TCP/IP Digest           Tuesday, 21 June 1983      Volume 2 : Issue 10

Today's Topics:
                Deadbeat Hosts Dropped from Distribution
               Looking for TCP/IP for an IBM 4341 (VM/370)
          Connecting an IBM to UNIBUS devices (like Ethernet)!
           Sources of TCP/IP Implementation for 68000 systesm
          Spooled FTP Comments  &&  Comments on TCP/IP for VMS
               Further Details on the ARPANET/MILNET Split
----------------------------------------------------------------------
                  TCP/IP Digest --- The InterNet Digest
                         LIMITED DISTRIBUTION
          For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------

Date:     Mon, 20 Jun 83 21:32:03 EDT
From:     Mike Muuss (TCP-IP Digest)  <tcp-ip@BRL-VGR>
To:       tcp-ip@BRL-VGR
Subject:  Deadbeat hosts

The following addresses have been deleted from the subscription list
of the TCP Digest.  Neither BRL-VGR nor BRL was able to get through
for a period of 14 days;  these hosts probably still have the TOPS-20
TCP bug.  If anybody can help out these hosts, please try.
			Best,
			 -Mike

	George @ Afsc-Hq		Dreifu @ Wharton-10
	King @ Afsc-Hq			HAGAN @ Wharton-10
	Perilli @ Afsc-Hq		LITWA @ Wharton-10

	PACE @ Afsc-Sd			JARONSON @ Nlm-Mcs

	Furuta @ Washington		Joe @ Washington

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

Date: 16 Jun 1983 07:57:21-PDT
From: bierma@nprdc
To: tcp-ip@sri-nic
Subject: looking for a TCP/IP implementation for a IBM 4341.

I am trying to set up a full service communications link between my VAX 
and an IBM 4341 that is about 400 feet away in another building.  The
4341 is running VM/370 and the VAX is running 4.1 UNIX (with BBN TCP/IP).
Ideally I am looking for an implementation of TCP/IP that runs under
VM/370 and network hardware that is compatible with both the VAX and
the 4341 (ethernet?).  When I asked the IBM rep her answer was "What's
TCP/IP?". Oh, Well so much for "No. 1".

--Larry Bierma <bierma@nprdc>

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

Date:     Thu, 16 Jun 83 15:07:00 CDT
From: Paul.Milazzo <milazzo.rice@rand-relay>
Subject:  TCP/IP for VM/370
To: tcp-ip@brl

It seems we have acquired yet another "strange" machine at Rice.
Does anyone know of a TCP/IP implementation for CMS under VM/SP
on an IBM 4341?  If so, how can I obtain a copy, and what
network interfaces does it support?

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


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

Date: 16 Jun 1983 1815-PDT
Subject: TCP for an IBM 4341
From: Dan Whelan <DAN@cit-20>
To: bierma@nprdc, braden@usc-isi, tcp-ip@brl

	We at Caltech are also concerned about TCP for a 4341 since IBM is
upstairs right now installing one. We have a systems programmer who is
interested in implementing TCP/IP under VM/CMS. Of course, we would rather
port an exisiting implementation. We plan to connect our 4341 to our local
Ethernet through its UNIBUS. Thats right, our 4341 has a UNIBUS. It appears
IBM is now manufacturing a device called a DACU which is an IBM PC with
a UNIBUS that attaches to a channel. Like the others, we'd welcome any
suggestions.
						    Dan Whelan

Our machine is just being installed now, but not all of the hardware
is here yet (including the DACU). I'll have more to add when we've played
around with it. My understanding is that the unit sells for 12-13K.

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

Date: 15 Jun 1983  9:43:40 EDT (Wednesday)
From: John Robinson <jr@bbncd>
Subject: 68000 TCP/IP
To: ram.arizona@rand-relay
Cc: schantz@bbncd, tcp-ip@brl, jr@bbncd

BBN is building a 68000 TCP/IP in the Distributed Operating System
project on government funding.  Inquire of Rick Schantz (SCHANTZ@BBN).

/jr

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

Date: 15 June 1983   18:08:58-PDT (Wednesday)
From: nowicki%Shasta@su-score
Subject: TCP/IP on Micros?
To: ram.Arizona@rand-relay
Cc: tcp-ip@brl

The Network Graphics Project at Stanford, now called the Partitionable
Computer Systems project, has developed an implementation of the IP/TCP
protocols.  It is structured as an "internet server" within the V
distributed system.  Processes anywhere in the system (on the same or
different workstation) may send it standard V messages using the V I/O
protocol.  The objects manipulated are either raw IP sockets or TCP
connections.  Its major use is virtual terminal communication from
graphics workstations through telnet.  It has been tested with the BBN
Vax/Unix, Berkeley 4.1c Unix, and BBN TOPS-20 implementations of TCP.

The internet server is portable with the rest of the V-System, since it
is all written in C.  Currently the V-System runs on five different
68000 systems based on the SUN CPU board, and is in the process of
being ported to the VAX.  The internet server is mostly the work of
Marvin Theimer, network address mmt@SU-HNV (or mmt%Diablo@Score).  It
is 37K bytes of object code + 7K data including libraries, and about
5000 lines of C source code.  The V-System is being licensed by the
Stanford Office of Technology Licensing, 415-497-0651.

	-- Bill

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

Date: 15 Jun 1983  9:24:48 EDT (Wednesday)
From: John Robinson <jr@bbncd>
Subject: Spooled FTP
To: jim@uw-beaver
Cc: tcp-ip@brl, bbn-tcp@bbn-unix, jr@bbncd

Certainly in the Unix environment one gets almost all the way there with
a combination of shell scripts and at(1).  The only troublesome aspect
is how to deal with deferring login at the remote site.  Also, FTP may
not in fact return error codes to the shell if the destination is
unreachable (some do, some don't).

Using mail (e.g. smtp) to send files isn't too bad a choice.  One could
add a control line (instead of or in addition to a normal mail header),
and queue the incoming message in a special directory where a daemon
scans the inbox from time to time and breaks the files apart again.
Giving this daemon root priveleges avoids the login issue, but
introduces security holes if it isn't careful (ought to setuid and
setgid before delivering the file).  Probably want this daemon to have
a private file system to avoid filling up /usr when something goes
wrong.

/jr

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

From: joseph sventek <sventek%j@lbl-csam>
Date:     Wednesday, 20 Apr 83 08:41:31 PST
Subject:  TCP/IP for VMS

We are currently running Compion's Access-X product (Access-T which can
be interfaced to your own link level) with no problems.  I have written
a driver interfacing the IP layer to the Proteon PRONET 10-Mbit ring
interface.  As a result, we have telnet and ftp connection to our 4.1A
UNIX host.  I have also interfaced the software tools mail delivery
system to use TCP circuits to support SMTP between the hosts, thus
providing a coherent mail system.  The user-interface utilities for
that mail system are sndmsg and msg clones.

As far as performance, I don't think anyone should expect blinding
speed from Compion's TCP/IP implementation, due to the modularity
employed in their software.  TCP service is provided by an ACP servicing
qio requests to a pseudo-device.  IP service is provided by another ACP
servicing requests to another pseudo-device.  The IP layer simply queues
up multiple read and write requests to the backend device driver.  As a
result, characters typed to user telnet when the remote host is providing
the character echo result in 6 process context switches per packet
(which may be single characters).  Other user protocols, such as ftp and
smtp, which are more block at a time oriented perform better, but still
suffer 6 context switches per request/response pair.  While this
architecture may not be the bottleneck when communicating with the
ARPANET, it is definitely the bottleneck when communicating over a
high-speed local net.

We have experienced none of the system-crashing bugs described above, as
I have been informed by Compion personnel that most of the outstanding
bugs were fixed in the Access-T 1.6 release, with which we share the
user and server utilities.  Our experience has been extremely positive,
not only with the software, but with the Compion personnel who aided us
in our attempts to be the first user site to link to our own network
link level.  It is an extremely easy way to get up to speed on TCP/IP on
VMS.

                                      Joe Sventek
                                      j @ LBL-CSAM

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

Date: 17 Jun 1983 2012-PDT
From: NIC@sri-nic
Subject: FURTHER DETAILS ON THE ARPANET/MILNET SPLIT

[ This message is an excerpt from DDN Newsletter 27, concerning the
  MILNET/EXPNET split.  For more information, contact <NIC@NIC>.  -Mike ]


Introduction

As previously discussed  in DDN  Newsletter 26,  the existing  ARPANET
will soon  be split  into  two separate  networks -  the  experimental
ARPANET and the operational  MILNET.  Hosts on  the two networks  will
intercommunicate  via  mail  bridges,   using  the  internet   gateway
mechanisms to pass  mail traffic  between hosts on  the two  networks.
The mail bridges will,  on a controlled  basis, provide full  internet
gateway services for MILNET hosts that request it.

The Logical Split

Because it takes a large amount of time and effort to physically split
a network  in a  coherent manner,  the ARPANET  will initially,  on  4
October  1983,  be  logically  partitioned  by  the  use  of  existing
mechanisms in the IMPs to enforce  segregation of hosts and TACs  into
separate communities of  interest.  Each community  of interest  (COI)
becomes a virtual network,  i.e., hosts (including  TACS) in the  same
community can fully interoperate as is currently the case, while hosts
in different communities  cannot directly  intercommunicate. This,  in
effect, transforms the ARPANET  into an Internet  in which the  MILNET
will assume  a new  class  A network  number,  network 26,  while  the
ARPANET  remains  network  10.   (Details  of  the  host   renumbering
procedures will  be covered  in a  later newsletter  from the  Network
Information Center (NIC).)

Intercommunication between the MILNET and ARPANET is via mail  bridges
which use  standard internet  protocols and  mechanisms to  pass  data
between hosts in the  two networks.  This is  why the conversion  from
NCP to TCP/IP is  so important; any host  with a fully working  TCP/IP
implementation (including ICMP, the host-gateway protocol), should see
no loss  in  service  because  of  the  split.  However,  hosts  using
incomplete TCP/IP implementations (those that do not include ICMP as a
part of  IP,  or  have  no  provision  for  using  gateways)  will  be
restricted to  communicating  with  other TCP/IP  hosts  in  the  same
network.  In particular, this means that they will not be able to send
(or receive) mail traffic  through the bridges to  hosts in the  other
network.

THERE CAN BE NO EXEMPTIONS TO THE SPLIT!!

Unlike the NCP-to-TCP  conversion which  is still underway  for a  few
hosts, once the  split occurs, there  is nothing that  can be done  to
allow a host with an incomplete TCP/IP to fully intercommunicate  with
the other  network other  than  helping them  to  convert to  a  fully
working TCP/IP as soon as possible.

Future DDN Newsletters will  discuss in greater  detail how the  split
affects the users  and host  software maintainers, and  how the  split
will be tested before it is finally implemented in October.

The Physical Split

Concurrent with  the logical  split the  network is  being  physically
split as  well.  Many  new  trunks are  being  added to  support  each
network, and  a  number of  trunks  will eventually  be  removed  once
replacement trunks have been installed.  The first quarter of CY  1984
has been established as the goal for completion of the physical split,
but this is dependent upon delivery  of new circuits from the  TELCOs,
some of which have very long lead times (over a year in some cases).

To complete the physical split, hosts and terminals which are homed on
the wrong IMP or TAC must be rehomed.  In some cases, a new IMP on the
proper network will be used;  in other cases, a  host may need to  use
HDH (the HDLC-based replacement  for VDH) in order  to gain access  to
its network via a  remote IMP.  In either  case, the host must  change
its network address,  and the TAC  users of these  hosts must be  made
aware of the change. Both host  and terminal rehoming will be kept  to
the absolute minimum possible.

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

END OF TCP-IP DIGEST
********************
-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      21-Jun-83 02:56 PDT
From:      RLL.TYM@OFFICE-2
To:        tharris@ddn1, jmayersohn@bbn-unix, ddnsr@BBN-UNIX nmimno@bbn-unix, DAB2.GVT@OFFICE-2, snelson@office-1 bhitson@bbn-unix, tcp-ip@brl, tcp-ip@sri-nic tcp-ip-tops20@sri-nic, tops-20@su-score
Cc:        scohn@BBN-UNIX
Subject:   Warning, TCP-4 problems
For a good explanation of the problems see SCOHN's msg of 20 jun 83.

This message is to make it clear that at least two problems exist in the TOPS20,
TENEX TCP code that is based on the BBN implementation. 1) the frequency of 
'pinging' has caused excessive delays and heavy net loads for our local IMP.  
Our brief experiments show that whatever the interval is, when the process wakes
up and begins to 'ping' the several gateways, all hell breaks loose and the 
host/imp are effectively down until this process completes.  The most noticeable
symptom is the sudden slowness for a minute or so. However, the most annoying is
the fact that this process in some way (yet unknown) can disrupt the other 
connections to our hosts with the result of user jobs that disconnect in funny 
ways leaving 'hung' jobs on the host.  With a PING interval of 37 seconds (the 
common standard), the situation is far worse.  We have gone the full way and 
will just NOOP the entire process of pinging.  When a proper solution is found, 
we will re-implement the pinging process.

2) This version of the BBN TCP code uses connections in an inefficient manner as
was stated by Steve Cohn.  Also we agree with Steve that this code has a 
'clumsy' approach to maintaining internet gateway data.

Since we run as vanilla as possible implementation of the TCP code to be as 
compatible as possible with the TOPS20 sites, we will wait until there is some 
general agreement on how to design the 'ping' process before installing it. 
Since BBN is not supporting this code, we will continue to work closely with 
SRI, ISI, Stanford, etc. in solving these common problems.

Robert

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Tue 21 Jun 83 04:00:25-PDT
From:      Mark Crispin <MRC@SU-SCORE.ARPA>
To:        RLL.TYM@OFFICE-2.ARPA
Cc:        tharris@DDN1.ARPA, jmayersohn@BBN-UNIX.ARPA, ddnsr@BBN-UNIX.ARPA, nmimno@BBN-UNIX.ARPA, DAB2.GVT@OFFICE-2.ARPA, snelson@OFFICE-1.ARPA, bhitson@BBN-UNIX.ARPA, tcp-ip@BRL.ARPA, tcp-ip@SRI-NIC.ARPA, tcp-ip-tops20@SRI-NIC.ARPA, tops-20@SU-SCORE.ARPA, scohn@BBN-UNIX.ARPA
Subject:   Re: Warning, TCP-4 problems
One suggestion -

     Do not run the NIC-supplied INTERNET.GATEWAYS file!!  This
is not made obvious to sites (I certainly was unaware of it), but
it is an important axiom.

     The problem is that the NIC gateways file has all the
gateways.  You really don't want all the gateways; instead, you
want a few "prime" gateways that are your primary contacts for IP
datagrams leaving ARPANET.  You probally also want a few other
selected "always-up" (these don't get pinged) and "dumb" gateways
(e.g. for nets you know you are going to talk to all the time).

     The reason you don't need all the gateways is that ICMP to
the prime gateways will take care of fixing up your routing table
to suit your needs dynamically as those needs happen.  ICMP is
always going to be better than any file the NIC could provide.

     I've talked to several individuals who've been involved with
this stuff for years, and they ll concur: if you're on the East
coast, run BBN's INTERNET.GATEWAYS; if you're on the West coast,
run ISI's.  Otherwise, look at both and figure out for yourself
what looks best for your needs.  Use the NIC's only as a
reference source of gateways you might want to add.  Don't
actually run it.

-- Mark --
-------
-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 1983 0945-PDT
From:      POSTEL at USC-ISIF
To:        HEDRICK at RUTGERS, MRC at SU-SCORE
Cc:        RLL.TYM at OFFICE-2, tharris at DDN1, jmayersohn at BBN-UNIX, ddnsr at BBN-UNIX, nmimno at BBN-UNIX, DAB2.GVT at OFFICE-2, snelson at OFFICE-1, bhitson at BBN-UNIX, tcp-ip at BRL, tcp-ip at NIC, tcp-ip-tops20 at NIC, tops-20 at SU-SCORE, scohn at BBN-UNIX, POSTEL at USC-ISIF
Subject:   Re: Warning, TCP-4 problems
In response to the message sent  21 Jun 83 11:34:32 EDT from HEDRICK@RUTERS

       +-------------------------------------------------------+
       |                                                       |
       | It is not necessary for any host to ping any gateway. |
       |                                                       |
       +-------------------------------------------------------+

All a host has to have is a short list of fairly reliable gateways.  The host
also keeps a dynamicly built table of (destination-network,gateway-to-use)
pairs.  When the host has oo send a datagram it first checks to see if the
destination network is in the dynamic table.  If it is then it uses the
indicated gateway.  If the destination network is not in the dynamic table,
then the host choose one of the gateways from the short list (randomly if
it wants) and makes a new entry in the dynamic table for that new pair.  If
a host sends a datagram to a destination network through the "wrong" gateway,
that gateway will (in addition to forwarding the datagram anyway) send back
to the host a  ICMP Redirect Control Message indicating the correct gateway.
The host on receiving an ICMP redirect message should update the dynamic
table entry to show the correct gateway for that destination network.  The
entries in the dynamic table should be aged and deleted after a fairly long
time (say, an hour). The entries should also be deleted at once if there if
is any indication that the gateway has died (e.g., an ARPANET 1822 "host dead"
is returned).

--jon.

-------
-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 1983 0959-PDT
From:      Joel Goldberger <JGoldberger@USC-ISIB>
To:        HEDRICK at RUTGERS
Cc:        MRC at SU-SCORE, RLL.TYM at OFFICE-2, tharris at DDN1 jmayersohn at BBN-UNIX, ddnsr at BBN-UNIX nmimno at BBN-UNIX, DAB2.GVT at OFFICE-2 snelson at OFFICE-1, bhitson at BBN-UNIX, tcp-ip at BRL tcp-ip at SRI-NIC, tcp-ip-tops20 at SRI-NIC tops-20 at SU-SCORE, scohn at BBN-UNIX
Subject:   Of gateways and pinging
Mark's comments on this subject are essentially correct, but it's clear that
there is some confusion.  PRIME gateways are a small subset of gateways that
engage in GGP (Gateway Gateway Protocol) amongst themselves to maintain up
to date routing tables.  At some interval they announce to each other what
networks they are connected to and how far (in hops) they are from all
networks that they know.  I'm not sure what their known set of networks is.
The way things are supposed to work is that if a host needs to talk to a
particular network and doesn't know the gateway to use it sends the message
to any PRIME gateway.  If that gateway knows of another gateway that is
closer it sends an ICMP re-direct packet back to the host.  TOPS-20 uses two
different methods to PING gateways; PRIME gateways are sent ICMP Echo
packets, which they return as ICMP Echo Reply packets.  Dumb gateways (which
don't speak ICMP) are PINGed with ICMP Echo-Reply packets
"reverse-addressed", that is the packet is addressed to the host taat is
pinging; since the packet isn't for the gateway that received it, it simply
sends it back out.  ALWAYS-UP and HOST gateways are not PINGed at all.
Since non-PRIME gateways don't get involved in the GGP routing table update
game one needs to include them in the tables if one wants to talk to hosts
on the network that they serve.

I hope this removes some of the mystery surrounding this subject.

- Joel Goldberger -
-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 1983 1216-PDT
From:      ROODE at SRI-NIC (David Roode)
To:        HEDRICK at RUTGERS, MRC at SU-SCORE
Cc:        RLL.TYM at OFFICE-2, tharris at DDN1, jmayersohn at BBN-UNIX, ddnsr at BBN-UNIX, nmimno at BBN-UNIX, DAB2.GVT at OFFICE-2, snelson at OFFICE-1, bhitson at BBN-UNIX, tcp-ip at BRL, tcp-ip, tcp-ip-tops20 at SRI-NIC, tops-20 at SU-SCORE, sscohn at BBN-UNIX
Subject:   Re: Warning, TCP-4 problems
Two more questions:

1) Does or Does NOT the TOPS-20 TCP's ICMP processes redirect messages?

2) IS there a program that anyone has that will printout the current
status of the monitor's gateway table?
-------
-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 1983 1308-PDT
From:      Henry W. Miller <Miller at SRI-NIC>
To:        brown at MITRE, tcp-ip
Cc:        Miller
Subject:   Re: Removal
Deb,
	Your name hase been removed.

-HWM
-------
-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 1983 11:23:27 EDT (Tuesday)
From:      Deborah Brown <brown at mitre>
To:        tcp-ip@sri-nic
Subject:   Removal
Please remove my name from the tcp-ip distribution list.

Thanks,
Deb Brown
deb@mitre
brown@mitre

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 83 11:34:32 EDT
From:      Dir LCSR Comp Facility <HEDRICK@RUTGERS.ARPA>
To:        MRC@SU-SCORE.ARPA
Cc:        RLL.TYM@OFFICE-2.ARPA, tharris@DDN1.ARPA, jmayersohn@BBN-UNIX.ARPA, ddnsr@BBN-UNIX.ARPA, nmimno@BBN-UNIX.ARPA, DAB2.GVT@OFFICE-2.ARPA, snelson@OFFICE-1.ARPA, bhitson@BBN-UNIX.ARPA, tcp-ip@BRL.ARPA, tcp-ip@SRI-NIC.ARPA, tcp-ip-tops20@SRI-NIC.ARPA, tops-20@SU-SCORE.ARPA, scohn@BBN-UNIX.ARPA
Subject:   Re: Warning, TCP-4 problems
It would help me (and I suspect also other people on this list) if someone
would describe in a bit more detail the method in which we hear about
gateways that are not listed in our internet.gateways file.  I would like
to be able to talk to any internet-addressable host.  I would not like
to spend all of my time pinging.  If I list only the prime gateways,
will I still be able to talk through any gateway?  If so, then why does
anyone list anything other than the prime gateways?  Also, a previous
message said that prime gateways are safe because they don't get pinged.
It also implied, but did not say, that this was true of DUMB gateways
also.  Is it?  Would anything be gained if we listed all of the
gateways from the NIC file, but changed the ones that get pinged (I am
still not clear on which those are) to be listed as dumb?
-------
-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 1983 1653-PDT
From:      Henry W. Miller <Miller at SRI-NIC>
To:        ROODE, HEDRICK at RUTGERS, MRC at SU-SCORE
Cc:        RLL.TYM at OFFICE-2, tharris at DDN1, jmayersohn at BBN-UNIX, ddnsr at BBN-UNIX, nmimno at BBN-UNIX, DAB2.GVT at OFFICE-2, snelson at OFFICE-1, bhitson at BBN-UNIX, tcp-ip at BRL, tcp-ip, tcp-ip-tops20 at SRI-NIC, tops-20 at SU-SCORE, sscohn at BBN-UNIX, Miller
Subject:   Re: Warning, TCP-4 problems
	Yes, it does, but only redirect net, not redirect host.

-HWM
-------
-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 1983 1940-EDT
From:      CLYNN at BBNA
To:        RLL.TYM at OFFICE-2
Cc:        tharris at DDN1, jmayersohn at BBN-UNIX, ddnsr at BBN-UNIX nmimno at BBN-UNIX, DAB2.GVT at OFFICE-2 snelson at OFFICE-1, bhitson at BBN-UNIX, tcp-ip at BRL tcp-ip at SRI-NIC, tcp-ip-tops20 at SRI-NIC tops-20 at SU-SCORE, scohn at BBN-UNIX
Subject:   Re: Warning, TCP-4 problems
  Recent measurements and messages indicate that a clarification
of the use and contents of the INTERNET.GATEWAYS file is needed and
that some TOPS20/TENEX hosts may still have a bug in their network
driver which is degrading network performance.  First, the bug:
The end of the IMPHDR routine (1822DV.MAC) should be:

	LOAD T3,NBBSZ,(T2)	; Get size
	SUBI T3,.NBHHL		; (Pseudo and real) header words
	ASH T3,2+3		; Make into bits
	CAILE T3,^D1008-1	; Uncontrolled flow must be single packet
	  MOVX T1,STY%FC	; Too big, must use Normal flow-controlled
	STOR T1,IHSTY,(T2)	; Message sub-type
	RET			; And return

If there is an		IDIVI T3,^D1008
			STOR T3,IHHTY,(T2)
please remove it.


  In theory, gateways do not have to be pinged;  a generic internet
gateway server whose internet logical name is coded into each host
could supply that host with the internet address of a gateway to use
(try) when the route to a destination network is not known.

   Until such a service is readily, reliably available, the TOPS20
and TENEX hosts use a site-dependent initialization file, named
INTERNET.GATEWAYS, to provide the address of a gateway to try when
the route to a destination is not known.  There is no need for a
host to know about all of the gateways;  the gateway system and
the ICMP protocol should make it possible for a host to reach any
"official" internet address, if it is at all possible.

  The INTERNET.GATEWAYS file should contain one or two (fairly
reliable) "PRIME" gateways on each network to which the TOPS20
or TENEX is directly connected.  Briefly, a PRIME gateway is
one of the "back-bone" gateways which knows now to route a packet
to one of the reachable networks, and will send ICMP redirect
messages when appropriate.  For reasons of performance (some of
which have been described in other messages), it is best if
sites do not all use the same gateway(s).  A "nearby" prime
gateway should be the first entry in the file, and a "backup"
should follow.  Entries should not be included simply because
the site has frequent communications with a particular net.

     One can make a reliability argument that the backup
     should be on the other side of the continent to try
     and minimize the possibility that both are down at
     the same time (due to a failure or maintenance).  A
     better solution (until the "gateway server" arrives)
     would be to have a backup file and to teach the
     operator(s) when and how to dynamically install it.

  Before one starts changing the values of the default network
parameters, make sure the consequences are well understood (and
please inform the operator what sorts of "performance problems"
the users may consequently report).  Most of the timeouts, etc.
are associated with robustness;  the longer the time constants,
the longer the associated outage will be when something fails.

   If a gateway listed in the routing cache goes down then
communication with the related network will not be possible
until the route is timed-out;  setting the timeout of the
routing cache to a large number can result in many problem
reports.  Setting it too short will cause packets to be sent
to the prime gateway more frequently.  [One recent incident:
"Users at B cannot communicate with Site D (anywhere else is
ok, though)" -- an ICMP redirect caused an entry to be placed
into the routing cache, and that gateway had subsequently
failed;  the routing cache was set to time out in six hours.
By the time the problem had been identified, there was only
one hour to go ...]

  If the ping interval is lengthened, the loss of a gateway will
not be noticed for a period about four times as long.  During the
interval, attempts to use the gateway (which are "hidden" from
the user) will fail.  If pinging is disabled, and the first prime
gateway listed in INTERNET.GATEWAYS goes down, the host will only
be able to communicate with directly connected networks and
networks which are still in the routing cache.

  If your host is only connected directly to the ARPANET, then
you need not read further.  Complications arise when the host
must be able to deal with "unofficial" entities -- hidden nets
or hosts, local area networks, home-brew gateways, etc.

  When the host tries to find a route to a network, it first checks
the routing cache.  If there is a functioning interface to the
desired network, it is used, secondly, if a <net,gateway> pair
is found, the gateway is used as the destination for the packet.
If no entry is found,
    [the gateways listed in INTERNET.GATEWAYS (which are "up")
    are examined (in the order specified in the INTERNET.GATEWAYS
    file) to see if one is listed as being able to reach the
    desired net, if so, it is used,  otherwise,]
the first PRIME gateway in the file (which is "up") will be tried.
If an ICMP Redirect Net message is received, the <net,gateway>
pair will be entered into the routing cache.

  The TOPS20/TENEX TCP-IP implementation is designed to operate in
the internet environment, not just the ARPANET;  in fact, it is not
necessary that the host even be connected to the ARPANET  (thus it
cannot rely on ARPANET/1822-specific mechanisms such as "host dead";
there is no corresponding mechanism in ethernet, for example).
The bracketed clause in the paragraph above is intended to allow a
site's liaison to both override the routing supplied by the internet
gateways (for administrative purposes, for example), and to allow
the host to use hidden or "unofficial" gateways, etc. between
networks with which the host must communicate, or which form the
site's local area network.  If such is not the case, there probably
should not be an entry in the gateway file;  if there is an entry
in the file (which isn't being pinged) and the gateway fails,
communications with the associated nets will be blocked.

  The following descriptions of non-PRIME gateways is included for
completeness, but use of such gateways is probably limited to sites
which have to communicate via local gateway implementations that do
not "conform to the official behavior" expected of a PRIME gateway.

PRIME gateways speak Internet Control Message Protocol, and will
turn an ICMP ECHO packet into an ECHO-REPLY;  they know how to
forward packets to reachable networks, and will send ICMP Redirect
messages when appropriate.  (E.g. the "backbone" gateways.)  They
are pinged to monitor when they are up and down.

DUMB gateways do not speak ICMP and thus will only forward packets.
These are pinged with ECHO-REPLIES instead of ECHO packets.

ALWAYS-UP gateways will not answer pings at all due to strange
implementations which, for example, prohibit reflecting packets
back into the net from which they came.  They are assumed to always
be up;  if they go down, you have a black hole.  (E.g. Two IMPs
on different networks which have ports which are wired together.)

HOST gateways are hosts which are capable of routing packets which
they receive;  they should not be burdened with forwarding packets
since they did not originate them, but they can be used in an
emergency.  (E.g.  TOPS20s [BBN or current DEC software] connected
to more than one (inter)network can be used to pass packets between
those (inter)networks.)

Hopefully, this has answered more questions than it raises;
if questions remain, send me a note.

Charlie
-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      22 June 1983 00:00 EST
From:      TCP-IP@brl
To:        TCP-IP@brl
Subject:   TCP-IP Digest, Vol 2 #11
TCP/IP Digest          Wednesday, 22 June 1983     Volume 2 : Issue 11

Today's Topic:
            TOPS-20/TENEX TCP/IP Implementations, and Pinging
----------------------------------------------------------------------
                  TCP/IP Digest --- The InterNet Digest
                         LIMITED DISTRIBUTION
          For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------

From: Mike Muuss <mike@brl>
Subject: Special Issue on TOPS-20/TENEX TCP/IP Implementations, and Pinging

This issue is entirely devoted to discussion of the TOPS-20/TENEX
IP routing mechanism, which uses InterNet Control Message Protocol "Echo"
(ICMP/ECHO) packets to determine the Up/Down status of various Gateways.
(I have removed most of the lengthy message headers to improve readability).

			-Mike

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

Date: 20 Jun 1983 13:37:21 EDT (Monday)
From: Steven Cohn <scohn@bbn-unix>
Subject: TCP & Gateway Pinging

In the course of studying the long delays and other problems experienced
by users of the TYMSHARE-[IMP]43 Office machines 1,2,3, and 7, some
undesirable aspects of the TCP implementation at TYMSHARE were
uncovered.  We have not yet examined the rest of the IMPs on the ARPANET
to determine if other hosts are suffering from the same disease, but
have reason to suspect TENEX and TOPS-20 TCP implementations.

TYMSHARE's TCP running on OFFICE-1 and OFFICE-2 had built into it a
clumsy approach to maintaining a table on the status of internet
gateways.  Generally it is unnecessary to communicate with a gateway
unless one has traffic destined for that gateway, however, both hosts
were regularly "pinging", or exchanging single messages, with each of 23
gateways, at the interval of 37 seconds.  This is unnecessary for
TYMSHARE as none of its users accesses the ARPANET through a gateway.
It also may have contributed some of the degradation of service that
they have observed.  This last point has not yet been demonstrated, but
as I explain below, there is good reason to suspect this.

Here is the scenario.  TYMSHARE-43 is a C/30 IMP running 4305.  This
provides for 56 end-to-end connections.  TYMSHARE has 4 real hosts
which, during one of my 5-minute measurements, sent substantial numbers
of messages to 15 different hosts on the ARPANET.  However, as their
implementation of TCP, combined with its interaction with 1822, uses the
handling type field, each of these logical connections may result in
several subnetwork connections.  (This results from a misinterpretation
of the implementation specifications in BBN Report 1822 on the
interconnection of a host and IMP.  We are presently considering what
the right policy on this matter should be.  Handling type should
generally be set to zero.  If messages are submitted on a single
host-to-host connection with different handling types then a separate
connection will be set up for each type.  We have observed as many as 5
different subnetwork connections between a pair of hosts.  This is
undesirable for two reasons.  First, since messages in the same stream
will be sent on different connections, the IMPs will not deliver them in
order so that the TCP will have to reorder them; messages on the same
connection are always delivered in correct order.  Second, having more
connections open drains the resources of the IMP.  This can be quite
serious, as I explain below.  Furthermore, it is not at all clear that
there are any benefits to maintaining multiple connections.)

Here's the problem.  Two of the hosts on TYMSHARE-43 ping each of the 23
gateways every 37 seconds.  (CUMSTATS, after much scrutiny, exposed
this.) These possibly also have variable handling type.  Thus this
configuration can easily consume the available connection resources in
the IMP which means that each time either of the hosts pings a gateway
it will probably need to set up a new connection.  (EESTATS over a
1-hour period showed that the IMP was resetting its transmit blocks once
every 1.07 seconds, on average.)

Assuming a new connection is required for each ICMP ping of a gateway,
then each host is blocked every 37/23 = 1.6 seconds for as long as it
takes to set up a connection.  (When the ping message is submitted the
interface blocks until a message number is obtained.  Since there is no
existing connection a connection must be established before obtaining a
message number and queuing the message.) Measured round-trip times for
messages originating at TYMSHARE-43 (using CUMSTATS) range between 440
and over 600 ms, averaged over 1-hour periods.  Minute-by-minute
fluctuations presumably result in higher values at times.  If we assume
a 600 ms round-trip time then it takes at least 600 ms to set up a
connection to a gateway and dispatch the ping.  During this time nothing
else can be submitted to the net by that host.  Thus, using the above
values, the two host would each be blocked 600 ms out of each 1.6
seconds or almost 40 % of the time.  If the ICMP pings are bunched this
could lead to higher blockage rates for particular intervals.

This can have at least two adverse effects.  First, it will certainly
impact host throughput if its interface is blocked 40 % of the time on
useless persuits, at least from TYMSHARE's perspective.  Second, it
cannot be useful to the gateways to be pinged this often by however many
hosts on the ARPANET happen to be running this code.  (Incidentally, we
will soon run measurements to try to identify any other culprits.)

When I explained this all to Robert Lieberman at TYMSHARE he discovered,
via some software people at SRI, that the timer in the TCP code which
controlled this gateway pinging could be easily adjusted and since his
hosts do not talk to gateways he set the timer to 280 minutes,
effectively disabling the pinging so that we can observe the effect on
performance.  Our hope is that this will yield improved service for the
STLA-[IMP]61 users of TYMSHARE hosts.  Basically this approach to the
gateways is inadequate and must be replaced.  Just setting the timers is
not an adequate solution, although useful immediately.

It is not known if this contention for connections is degrading service
for other hosts on the network.  However, the mechanism explained above
may very well be impacting your network performance without being
obvious.  It happens, for example, that this mechanism does not produce
any kind of trap that would signal a problem to network operators
because, while the host may be blocked much of the time, it is not
blocked for an extended period e.g. 3 seconds.

I would appreciate hearing about any other cases, suspected or proven,
where connection contention causes degraded service.  Remember, the
ARPANET is NOT just a datagram network.

Regards,

Steve Cohn

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

Date: 20 Jun 1983 1112-PDT
From: Henry W. Miller <Miller@sri-nic>
Subject: Re: TCP & Gateway Pinging

Steve,

	Thank you for your deductions on this.  I believe that you will
find all or most of the TOPS20 and TENEX sites on the network exhibiting
this behavior, since we are running variants of the same code.  However,
the pinging algorithim should be sufficiently similar in all the
implementations to exhibit the same bad manners.  The exceptions, as
far as I can see are those hosts who have edited entries out of their
gateway tables.

	As far as I know, 37 seconds is the standard inter-ping
interval.  From conversations with Dave Mills and Mike Brescia,
this interval is way too short, and results with the poor gateways
being flooded by probes at a high rate.  This congests them as well,
and hampers communications with other nets.  The value of PINGT0
in the monitor should be raised to a higher value.  We are currently
using about a 1 minute interval, and may raise that if the results
warrant it.

	There are many other things that the code may be doing
wrong, but more research is needed.

-HWM

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

Date: 21-Jun-83 02:56 PDT
From: RLL.TYM@office-2
Subject: Warning, TCP-4 problems

This message is to make it clear that at least two problems exist in the
TOPS20, TENEX TCP code that is based on the BBN implementation.

1) The frequency of 'pinging' has caused excessive delays and heavy net
loads for our local IMP.  Our brief experiments show that whatever the
interval is, when the process wakes up and begins to 'ping' the several
gateways, all hell breaks loose and the host/imp are effectively down
until this process completes.  The most noticeable symptom is the sudden
slowness for a minute or so. However, the most annoying is the fact that
this process in some way (yet unknown) can disrupt the other connections
to our hosts with the result of user jobs that disconnect in funny ways
leaving 'hung' jobs on the host.  With a PING interval of 37 seconds (the
common standard), the situation is far worse.  We have gone the full way
and will just NOOP the entire process of pinging.  When a proper
solution is found, we will re-implement the pinging process.

2) This version of the BBN TCP code uses connections in an inefficient
manner as was stated by Steve Cohn.  Also we agree with Steve that this
code has a 'clumsy' approach to maintaining internet gateway data.

Since we run as vanilla as possible implementation of the TCP code to be
as compatible as possible with the TOPS20 sites, we will wait until
there is some general agreement on how to design the 'ping' process
before installing it.  Since BBN is not supporting this code, we will
continue to work closely with SRI, ISI, Stanford, etc. in solving these
common problems.

Robert

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

Date: Tue 21 Jun 83 04:00:25-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: Warning, TCP-4 problems

One suggestion -

     Do not run the NIC-supplied INTERNET.GATEWAYS file!!  This
is not made obvious to sites (I certainly was unaware of it), but
it is an important axiom.

     The problem is that the NIC gateways file has all the
gateways.  You really don't want all the gateways; instead, you
want a few "prime" gateways that are your primary contacts for IP
datagrams leaving ARPANET.  You probably also want a few other
selected "always-up" (these don't get pinged) and "dumb" gateways
(e.g. for nets you know you are going to talk to all the time).

     The reason you don't need all the gateways is that ICMP to
the prime gateways will take care of fixing up your routing table
to suit your needs dynamically as those needs happen.  ICMP is
always going to be better than any file the NIC could provide.

     I've talked to several individuals who've been involved with
this stuff for years, and they all concur: if you're on the East
coast, run BBN's INTERNET.GATEWAYS; if you're on the West coast,
run ISI's.  Otherwise, look at both and figure out for yourself
what looks best for your needs.  Use the NIC's only as a
reference source of gateways you might want to add.  Don't
actually run it.

-- Mark --

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

Date: 21 Jun 83 11:34:32 EDT
From: Dir LCSR Comp Facility <HEDRICK@RUTGERS.ARPA>
Subject: Re: Warning, TCP-4 problems

It would help me (and I suspect also other people on this list) if
someone would describe in a bit more detail the method in which we hear
about gateways that are not listed in our internet.gateways file.  I
would like to be able to talk to any internet-addressable host.  I would
not like to spend all of my time pinging.  If I list only the prime
gateways, will I still be able to talk through any gateway?  If so, then
why does anyone list anything other than the prime gateways?  Also, a
previous message said that prime gateways are safe because they don't
get pinged.  It also implied, but did not say, that this was true of
DUMB gateways also.  Is it?  Would anything be gained if we listed all
of the gateways from the NIC file, but changed the ones that get pinged
(I am still not clear on which those are) to be listed as dumb?

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

Date: 21 Jun 1983 0945-PDT
From: POSTEL@usc-isif
Subject: Re: Warning, TCP-4 problems


       +-------------------------------------------------------+
       |                                                       |
       | It is not necessary for any host to ping any gateway. |
       |                                                       |
       +-------------------------------------------------------+

All a host has to have is a short list of fairly reliable gateways.  The host
also keeps a dynamicly built table of (destination-network,gateway-to-use)
pairs.  When the host has oo send a datagram it first checks to see if the
destination network is in the dynamic table.  If it is then it uses the
indicated gateway.  If the destination network is not in the dynamic table,
then the host choose one of the gateways from the short list (randomly if
it wants) and makes a new entry in the dynamic table for that new pair.  If
a host sends a datagram to a destination network through the "wrong" gateway,
that gateway will (in addition to forwarding the datagram anyway) send back
to the host a  ICMP Redirect Control Message indicating the correct gateway.
The host on receiving an ICMP redirect message should update the dynamic
table entry to show the correct gateway for that destination network.  The
entries in the dynamic table should be aged and deleted after a fairly long
time (say, an hour). The entries should also be deleted at once if there if
is any indication that the gateway has died (e.g., an ARPANET 1822 "host dead"
is returned).

--jon.

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

Date: 21 Jun 1983 0959-PDT
Subject: Of gateways and pinging
From: Joel Goldberger <JGoldberger@usc-isib>

Mark's comments on this subject are essentially correct, but it's clear
that there is some confusion.  PRIME gateways are a small subset of
gateways that engage in GGP (Gateway Gateway Protocol) amongst
themselves to maintain up to date routing tables.  At some interval they
announce to each other what networks they are connected to and how far
(in hops) they are from all networks that they know.  I'm not sure what
their known set of networks is.  The way things are supposed to work is
that if a host needs to talk to a particular network and doesn't know
the gateway to use it sends the message to any PRIME gateway.  If that
gateway knows of another gateway that is closer it sends an ICMP
re-direct packet back to the host.

TOPS-20 uses two different methods to PING gateways; PRIME gateways are
sent ICMP Echo packets, which they return as ICMP Echo Reply packets.
Dumb gateways (which don't speak ICMP) are PINGed with ICMP Echo-Reply
packets "reverse-addressed", that is the packet is addressed to the host
that is pinging; since the packet isn't for the gateway that received
it, it simply sends it back out.  ALWAYS-UP and HOST gateways are not
PINGed at all.  Since non-PRIME gateways don't get involved in the GGP
routing table update game one needs to include them in the tables if one
wants to talk to hosts on the network that they serve.

I hope this removes some of the mystery surrounding this subject.

- Joel Goldberger -

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

Date: 21 Jun 1983 1940-EDT
Sender: CLYNN@bbna
Subject: Re: Warning, TCP-4 problems
From: CLYNN@bbna

  Recent measurements and messages indicate that a clarification
of the use and contents of the INTERNET.GATEWAYS file is needed and
that some TOPS20/TENEX hosts may still have a bug in their network
driver which is degrading network performance.  First, the bug:
The end of the IMPHDR routine (1822DV.MAC) should be:

	LOAD T3,NBBSZ,(T2)	; Get size
	SUBI T3,.NBHHL		; (Pseudo and real) header words
	ASH T3,2+3		; Make into bits
	CAILE T3,^D1008-1	; Uncontrolled flow must be single packet
	  MOVX T1,STY%FC	; Too big, must use Normal flow-controlled
	STOR T1,IHSTY,(T2)	; Message sub-type
	RET			; And return

If there is an		IDIVI T3,^D1008
			STOR T3,IHHTY,(T2)
please remove it.


  In theory, gateways do not have to be pinged;  a generic internet
gateway server whose internet logical name is coded into each host
could supply that host with the internet address of a gateway to use
(try) when the route to a destination network is not known.

   Until such a service is readily, reliably available, the TOPS20
and TENEX hosts use a site-dependent initialization file, named
INTERNET.GATEWAYS, to provide the address of a gateway to try when
the route to a destination is not known.  There is no need for a
host to know about all of the gateways;  the gateway system and
the ICMP protocol should make it possible for a host to reach any
"official" internet address, if it is at all possible.

  The INTERNET.GATEWAYS file should contain one or two (fairly
reliable) "PRIME" gateways on each network to which the TOPS20
or TENEX is directly connected.  Briefly, a PRIME gateway is
one of the "back-bone" gateways which knows now to route a packet
to one of the reachable networks, and will send ICMP redirect
messages when appropriate.  For reasons of performance (some of
which have been described in other messages), it is best if
sites do not all use the same gateway(s).  A "nearby" prime
gateway should be the first entry in the file, and a "backup"
should follow.  Entries should not be included simply because
the site has frequent communications with a particular net.

     One can make a reliability argument that the backup
     should be on the other side of the continent to try
     and minimize the possibility that both are down at
     the same time (due to a failure or maintenance).  A
     better solution (until the "gateway server" arrives)
     would be to have a backup file and to teach the
     operator(s) when and how to dynamically install it.

  Before one starts changing the values of the default network
parameters, make sure the consequences are well understood (and
please inform the operator what sorts of "performance problems"
the users may consequently report).  Most of the timeouts, etc.
are associated with robustness;  the longer the time constants,
the longer the associated outage will be when something fails.

   If a gateway listed in the routing cache goes down then
communication with the related network will not be possible
until the route is timed-out;  setting the timeout of the
routing cache to a large number can result in many problem
reports.  Setting it too short will cause packets to be sent
to the prime gateway more frequently.  [One recent incident:
"Users at B cannot communicate with Site D (anywhere else is
ok, though)" -- an ICMP redirect caused an entry to be placed
into the routing cache, and that gateway had subsequently
failed;  the routing cache was set to time out in six hours.
By the time the problem had been identified, there was only
one hour to go ...]

  If the ping interval is lengthened, the loss of a gateway will
not be noticed for a period about four times as long.  During the
interval, attempts to use the gateway (which are "hidden" from
the user) will fail.  If pinging is disabled, and the first prime
gateway listed in INTERNET.GATEWAYS goes down, the host will only
be able to communicate with directly connected networks and
networks which are still in the routing cache.

  If your host is only connected directly to the ARPANET, then
you need not read further.  Complications arise when the host
must be able to deal with "unofficial" entities -- hidden nets
or hosts, local area networks, home-brew gateways, etc.

  When the host tries to find a route to a network, it first checks
the routing cache.  If there is a functioning interface to the
desired network, it is used, secondly, if a <net,gateway> pair
is found, the gateway is used as the destination for the packet.
If no entry is found,
    [the gateways listed in INTERNET.GATEWAYS (which are "up")
    are examined (in the order specified in the INTERNET.GATEWAYS
    file) to see if one is listed as being able to reach the
    desired net, if so, it is used,  otherwise,]
the first PRIME gateway in the file (which is "up") will be tried.
If an ICMP Redirect Net message is received, the <net,gateway>
pair will be entered into the routing cache.

  The TOPS20/TENEX TCP-IP implementation is designed to operate in
the internet environment, not just the ARPANET;  in fact, it is not
necessary that the host even be connected to the ARPANET  (thus it
cannot rely on ARPANET/1822-specific mechanisms such as "host dead";
there is no corresponding mechanism in ethernet, for example).
The bracketed clause in the paragraph above is intended to allow a
site's liaison to both override the routing supplied by the internet
gateways (for administrative purposes, for example), and to allow
the host to use hidden or "unofficial" gateways, etc. between
networks with which the host must communicate, or which form the
site's local area network.  If such is not the case, there probably
should not be an entry in the gateway file;  if there is an entry
in the file (which isn't being pinged) and the gateway fails,
communications with the associated nets will be blocked.

  The following descriptions of non-PRIME gateways is included for
completeness, but use of such gateways is probably limited to sites
which have to communicate via local gateway implementations that do
not "conform to the official behavior" expected of a PRIME gateway.

PRIME gateways speak Internet Control Message Protocol, and will
turn an ICMP ECHO packet into an ECHO-REPLY;  they know how to
forward packets to reachable networks, and will send ICMP Redirect
messages when appropriate.  (E.g. the "backbone" gateways.)  They
are pinged to monitor when they are up and down.

DUMB gateways do not speak ICMP and thus will only forward packets.
These are pinged with ECHO-REPLIES instead of ECHO packets.

ALWAYS-UP gateways will not answer pings at all due to strange
implementations which, for example, prohibit reflecting packets
back into the net from which they came.  They are assumed to always
be up;  if they go down, you have a black hole.  (E.g. Two IMPs
on different networks which have ports which are wired together.)

HOST gateways are hosts which are capable of routing packets which
they receive;  they should not be burdened with forwarding packets
since they did not originate them, but they can be used in an
emergency.  (E.g.  TOPS20s [BBN or current DEC software] connected
to more than one (inter)network can be used to pass packets between
those (inter)networks.)

Hopefully, this has answered more questions than it raises;
if questions remain, send me a note.

Charlie

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

Date: 21 Jun 1983 1216-PDT
From: David Roode <ROODE@sri-nic>
Subject: Re: Warning, TCP-4 problems

Two more questions:

1) Does or Does NOT the TOPS-20 TCP's ICMP processes redirect messages?

2) IS there a program that anyone has that will printout the current
status of the monitor's gateway table?

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

Date: 21 Jun 1983 1653-PDT
From: Henry W. Miller <Miller@sri-nic>
Subject: Re: Warning, TCP-4 problems

	Yes, it does, but only redirect net, not redirect host.

-HWM

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

END OF TCP-IP DIGEST
********************
-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1983 0209-PDT
From:      the tty of Geoffrey S. Goodfellow
To:        POSTEL at USC-ISIF, HEDRICK at RUTGERS, MRC at SU-SCORE RLL.TYM at OFFICE-2, tharris at DDN1 jmayersohn at BBN-UNIX, ddnsr at BBN-UNIX nmimno at BBN-UNIX, DAB2.GVT at OFFICE-2 snelson at OFFICE-1, bhitson at BBN-UNIX, tcp-ip at BRL tcp-ip at NIC, tcp-ip-tops20 at NIC, tops-20 at SU-SCORE scohn at BBN-UNIX
Subject:   Gateways- When should I ping, When should I purge, Who should I have?
So far we have heard that pinging gateways in a hosts gateway
cache every 37 seconds is too often and that very likely every
TENEX and TOPS-20 site on the ARPANET is currently doing this.
We had a suggestion that it might not be necessary to ping
gateways at all.  However, it was also suggested pinging gateways
periodically might be a good idea.

It was suggested that entries in a hosts dynamic gateway table
should be aged and deleted after about an hours time.

A number of informed parties suggested that each site configure
the contents of their INTERNET.GATEWAYS file very carefully and
some very helpful guidelines for choosing the initial contents of
your INTERNET.GATEWAYS file was given.

What I would like to see explored, discussed and hopefully
resolved by this group is:

1) What is the ideal interval with which to PING and under what
circumstances should I PING?

2) What is the ideal time a gateway entry should remain in a
given hosts gateway table before it is aged and flushed?

I think how one should configure the contents of their initial
INTERNET.GATEWAYS file was pretty well explained by Charlie Lynn,
but I still have not heard anything concrete enough on the
subject of when to PING and when to purge to make me dash to my
TENEX sources and stick the code in.

Could we hear from other operating system wizards on how
FUZZBALLS, TAC's, UNIX, Multics, VMS, IBM hosts, TIU's and so
forth have done it and from the Internet Holy Water Sprinklers on
what the ideal values would be?
-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1983 0329-PDT
From:      Henry W. Miller <Miller at SRI-NIC>
To:        Geoff at SRI-CSL, POSTEL at USC-ISIF, HEDRICK at RUTGERS, MRC at SU-SCORE, RLL.TYM at OFFICE-2, tharris at DDN1, jmayersohn at BBN-UNIX, ddnsr at BBN-UNIX, nmimno at BBN-UNIX, DAB2.GVT at OFFICE-2, snelson at OFFICE-1, bhitson at BBN-UNIX, tcp-ip at BRL, tcp-ip, tcp-ip-tops20 at SRI-NIC, tops-20 at SU-SCORE, scohn at BBN-UNIX
Cc:        Miller
Subject:   Re: Gateways- When should I ping, When should I purge, Who should I have?
	Ok, at the risk of starting a new mail deluge... (we just
recovered from the last...)

1)	Jon sez that it is not necessary to ping; that ICMP
redirects will handle it.  OK, seems reasonable, depending
on your net traffic.  Knowing a probable path, and trying
it first, and recovering from it in case of error seems
more efficient than probing J. Random Prime Gateway, hoping
for a win.  (This is why I'm in favor of rich gateway tables;
it gives you more initial options.)

2)	If you choose to ping, to keep up with the state of the
network, 37 seconds is clearly too short of a period to get a
snapshot of the net.  A couple of un-ACKED probes could lead one
to believe that a gate is down, when in fact, it might not be.
If pinging is desired, then an interval that is suffcently long
should be used, say 5-10 minutes.  (Personal opinion: A ping
from a host coming back on the air COULD/SHOULD be interpreted
as an "I'm Alive" message.  The gateways, in their infinte
wisdom, could spread the good news across the networks, so the
various hosts could update their routing tables.  Likewise, the
hosts should be able to poll the gateway of their dreams on
occaision and receive, in return, the latest routing poop.
A maxi ping, fer surre, but would help eliminate senseless
probings...)

3)	Updating routing tables: again, depending upon your
internet needs, 30 minutes at the max.  (Smallest interval...)
The current default, I believe is 6 hours.


4)	Another thot:  put a timer block in for each gateway:
when to ping next.  This would allow pinging on a selective
basis.


-HWM
-------
-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jun 83 07:44:20 PDT
From:      estell at nwc-387b
To:        TCP-IP at SRI-NIC
Cc:        Mike at BRL
Subject:   Request for Removal from mailing list
The TCP-IP mailing list seems to be for those who IMPLEMENT
TCP-IP; i.e., those who will be on the ARPANET (vice DDN)
after the split.

I have enjoyed much of the traffic on this list; but I suspect 
that (considering my job) I should no longer get it.
I still get (and want) the TCP-IP Digest from Mike Muuss at BRL.

Therefore, please remove the following names from the TCP-IP list:
Estell@NWC-387B    and    NWC@ECLB
-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jun 83 08:54 PDT
From:      Howard@LLL-MFE.ARPA
To:        tcp-ip@sri-nic.arpa
Subject:   Request for removal from mailing list

Please remove the following name from the TCP-IP list:  HOWARD@LLL-MFE.

Thanks,

Barry Howard
-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1983 1132-PDT
From:      Craig Milo Rogers  <ROGERS@USC-ISIB>
To:        ROODE@SRI-NIC (David Roode), HEDRICK@RUTGERS, MRC@SU-SCORE
Cc:        RLL.TYM@OFFICE-2, tharris@DDN1, jmayersohn@BBN-UNIX, ddnsr@BBN-UNIX, nmimno@BBN-UNIX, DAB2.GVT@OFFICE-2, snelson@OFFICE-1, bhitson@BBN-UNIX, tcp-ip@BRL, tcp-ip@SRI-NIC, tcp-ip-tops20@SRI-NIC, tops-20@SU-SCORE, sscohn@BBN-UNIX
Subject:   Re: Warning, TCP-4 problems
	The programs <PRVSYS>IGGSTS.EXE and <PRVSYS>IGSSTS.EXE on ISIA,B,D-F
will print TOPS20's Ping table and network routing table, respectively.
(The names are holdovers from the GGP days).  However, I don't expect
these programs to work outside ISI, because they use an ISI-specific (I
think) JSYS to map monitor pages (GTMPG).  The sources are in BLISS-10.
There are help files in <PRVSYS>.  You need the Wheel privelege to run
the programs.

					Craig Milo Rogers
-------
-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1983  9:08:55 EDT (Wednesday)
From:      Dennis Rockwell <drockwel@bbn-vax>
To:        Geoff@SRI-CSL
Cc:        POSTEL@USC-ISIF, HEDRICK at RUTGERS, MRC at SU-SCORE, RLL.TYM at OFFICE-2, tharris at DDN1, jmayersohn at BBN-UNIX, ddnsr at BBN-UNIX, nmimno at BBN-UNIX, DAB2.GVT at OFFICE-2, snelson at OFFICE-1, bhitson at BBN-UNIX, tcp-ip at BRL, tcp-ip at NIC, tcp-ip-tops20 at NIC, tops-20 at SU-SCORE, scohn at BBN-UNIX
Subject:   Re: Gateways- When should I ping, When should I purge, Who should I have?
BBN UNIX hosts ping all gateways that are currently in use (defined as
having an open connection which has as its local-net destination a
gateway) constantly, at a rate of once every few seconds.

We have thought about fancy schemes involving only pinging when TCP
has to retransmit, but this leaves users of non-TCP services out
in the cold.  The rapid rate of pinging is for detection of a dead
first-hop gateway.  Unless one assumes an 1822 net, there is very likely
no feedback as to whether a packet is delivered or not (as was previously
noted, ethernet in particular has no such feedback).

Since we only ping active gateways, our hosts' gateway table contains
all the gateways we can find out about that are connected to whatever
local net(s) we are connected to.

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1983 at 1304-PDT
From:      aguilar@Sri-Tsc
To:        tcp-ip@Sri-Nic
Subject:   remove me from tcp-ip mailing list
please do it at once.
Thanks
Lorenzo
-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1983 1351-PDT
From:      Henry W. Miller <Miller at SRI-NIC>
To:        estell at NWC-387B, TCP-IP
Cc:        Mike at BRL, Miller
Subject:   Re: Request for Removal from mailing list
	OK, will remove the names from the list.

-HWM
-------
-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1983 1352-PDT
From:      Henry W. Miller <Miller at SRI-NIC>
To:        Howard at LLL-MFE, tcp-ip
Cc:        Miller
Subject:   Re: Request for removal from mailing list
	OK, Barry, I'll remove it.

-HWM
-------
-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1983 1358-PDT
From:      ROODE at SRI-NIC (David Roode)
To:        TCP-IP at SRI-NIC
Subject:   use of TCP-IP-REQUEST
As will nearly every large mailing list, there exists
a TCP-IP-REQUEST at SRI-NIC to handle any corrections,
deletions or other business matters for TCP-IP@SRI-NIC
without generating huge volumes of mail.

Please use it!
-------
-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1983 14:10:32 EDT (Wednesday)
From:      Douglas Steele <steele@BBN-UNIX>
To:        tcp-ip@sri-nic
Cc:        steele@BBN-UNIX
Subject:   request removal from tcp-ip
Please remove me from the tcp-ip mailing list.

Thanks,
Doug

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Thu 23 Jun 83 08:57:50-PDT
From:      Suzanne Johnson <JOHNSON@SUMEX-AIM.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   ibm tcp/ip
It turns out that if you give your IBM rep VERY specific information on
WHO and WHERE within IBM the tcp/ip work goes on, they can follow up for
you.  

The tcp/ip work is evidently being done by IBM's Federal Systems Division
in Gaithersburg, Maryland.  The person doing the work is Doug McKay.

Our rep was able to confirm this, given the above info.  Since he is
somewhat up-to-date on status, you might have your rep contact
our IBM rep.  His name is Waymon Lee, and phone # is 415-855-0519.

Let us know what you find out.

Suzanne Johnson
-------
-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 1983 1000-PDT
From:      Francine Perillo <PERILLO at SRI-NIC>
To:        JOHNSON at SUMEX-AIM, tcp-ip
Cc:        PERILLO
Subject:   Re: ibm tcp/ip
You might also ask the Network Information Center for info on 
TCP/IP implementations.  We have a lot of vendors calling us
and we've been keeping track of what is out there.  Try us!

-Francine Perillo  /NIC
-------
-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 1983 1309-PDT
From:      DELEOT at USC-ISI
To:        tcp-ip at SRI-NIC
Cc:        deleot at USC-ISI
Subject:   removal
pls remoove the following fron the tcp-ip list:
deleot at isia

thanks,
chuck
deleot
-------
-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 1983 at 1527-PDT
From:      dan at SRI-TSC
To:        Suzanne Johnson <JOHNSON at SUMEX-AIM.ARPA>
Cc:        tcp-ip at SRI-NIC.ARPA
Subject:   Re: ibm tcp/ip
Doug McKay is indeed working on TCP/IP for the Series I.  He is porting the
SRI TCP/IP for PDP11/44's (which is itself a port of the 4.1b BSD VAX UNIX
TCP/IP).  It was my understanding that it is being integrated into the version
of UNIX they have running on the Series I and whatever other IBM systems are
running UNIX.  I don't know if his group is also working on TCP/IP for
non-unix operating systems, but I got the impression from talking to him that
they were not.

	-Dan Chernikoff (dan@sri-tsc)
	SRI International
-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 1983 1504-PDT
From:      Gary Poock <POOCK@USC-ISIE>
To:        TCP-IP@SRI-NIC
Cc:        POOCK@USC-ISIE
Subject:   REMOVE FROM MAILING LIST PLS

PLEASE REMOVE   POOCK@ISIE

FROM THE TCP-IP  MAILING LIST PLEASE

THANKS 

GARY
-------
-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Saturday, 25 June 1983, 21:17-EDT
From:      David A. Moon <Moon%SCRC-TENEX@MIT-MC>
To:        tcp-ip-request@SRI-NIC
Subject:   Mail to tcp-ip instead of tcp-ip-request
Do you have batch jobs at SRI-NIC?  May I suggest that a suitable punishment
for people who send mail to tcp-ip (rather than tcp-ip-request) asking to
be removed from the list is set up a batch job that sends them, once an hour
twenty four hours a day, a 50-line message explaining the xxx-request policy.
It would shut off automatically when any incoming message to tcp-ip-request
was received from the offending user (or perhaps anyone at his host).

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 1983 0921-PDT
From:      Brunner@OFFICE-7
To:        TCP-IP@SRI-NIC
Cc:        J.Tugman:, RTS:, Brunner
Subject:   Removal from Mailing List

Since I no longer am at my former job with the TAC responsibility, I
request that you remove me from all mailing lists regarding information
on the TAC or the ARPANET.

THANKS,
Linda Brunner
-------
-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 1983 1445-PDT
From:      Henry W. Miller <Miller at SRI-NIC>
To:        Brunner at OFFICE-7, TCP-IP
Cc:        Miller
Subject:   Re: Removal from Mailing List
	Ok, will do.

-HWM
-------
-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      30 June 1983 00:00 EST
From:      TCP-IP@brl
To:        TCP-IP@brl
Subject:   TCP-IP Digest, Vol 2 #12
TCP/IP Digest          Thursday, 30 June 1983      Volume 2 : Issue 12

Today's Topics:
                 IBM VM TCP/IP Implementation Now Exists
               Contacts within IBM for TCP/IP Information
                      Hooking IBMs to an Ethernet?
    Gateways: When should I ping, When should I purge, Who should I have?
                  Program to print TOPS20's Ping Table
               Security Problem with Mail?  Probably not.
----------------------------------------------------------------------
                  TCP/IP Digest --- The InterNet Digest
                         LIMITED DISTRIBUTION
          For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------

Date: 22 Jun 1983 13:22:04-CDT
From: L.H. Landweber <lhl@uwisc>
Reply-to: ibm-project@uwisc
To: tcp-ip@brl
Subject:  IBM VM TCP/IP IMPLEMENTATION

                  TCP/IP IBM VM IMPLEMENTATION


We are implementating of the Internet protocols (FTP/SMTP/Telnet/TCP/IP) for
IBM VM Systems under contract with IBM.  The TCP and IP have been running for
some time now under VM/SP on an IBM 4331 at Wisconsin and we are currently
putting the finishing touches on the higher-level protocols.  In addition, a 
software interface between IP and an X.25 implementation running on a
Series/1 (RPS operating system) has been completed.  The complete package
will enable CSNET IBM VM hosts to connect to the Darpa Internet via Telenet.

The 4300 software is written almost entirely in Pascal, with a small amount
of assembler-language support.  Some assembler code running on the Series/1
interfaces with the X.25 code, which is a standard IBM product.  Standard IBM
released software is used throughout (i.e., no modified or unreleased system
software has been employed).

The software will be ready for initial distribution to test sites in mid-July.
We hope to have production versions available by the end of August. 
Distribution will be controlled by IBM.  We encourage interested parties to
contact:

          Mr. Carl VanWinter
          IBM  Corporation
          Rochester, MN
          507-286-3378

to express an interest or request information on distribution
plans.


ADDITIONAL DETAILS

TCP/IP runs in a separate disconnected virtual machine.  Similarly, SMTP,
server FTP, and server Telnet each occupies a dedicated virtual machine. 
User FTP and user Telnet run within a user's virtual machine under CMS. 
Communication between virtual machines is done through the IBM Virtual
Machine Communication Facility (VMCF).  A detailed preliminary design
document is available by contacting one of the individuals listed below.
(Some details have changed since it was written, but it is still mostly
accurate.)

Over the Summer we expect to implement a Pronet driver to enable
our IP/TCP to use the PRONET 10 megabit/sec token ring LAN.  The hardware
interface will be via a DACU (Device Access Control Unit) provided by IBM.
The DACU enables connection of UNIBUS devices to an IBM channel.  We expect
other university groups to provide a driver for Ethernet.  We estimate that
each of these projects will take 2-4 man-months to complete.

Direct connection to a C/30 IMP will require implementation of a software
driver in conjunction with a suitable hardware interface (e.g., DACU--LH/DH
or Series/1--HDH).

For further technical information contact:

          David DeWitt, Larry Landweber, or Marvin Solomon
          Computer Science Department
          University of Wisconsin
          1210 W. Dayton St.
          Madison, WI 53706
          608-262-1204

		  ibm-project@uwisc

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

Date: Thu 23 Jun 83 09:08:37-PDT
From: Suzanne Johnson <JOHNSON@SUMEX-AIM.ARPA>
Subject: tcp/ip ibm info
To: tcp-ip@BRL.ARPA

It turns out that if you give your IBM rep VERY specific information on
WHO and WHERE within IBM the tcp/ip work goes on, they can follow up for
you.  

The tcp/ip work is evidently being done by IBM's Federal Systems Division
in Gaithersburg, Maryland.  The person doing the work is Doug McKay.

Our rep was able to confirm this, given the above info.  Since he is
somewhat up-to-date on status, you might have your rep contact
our IBM rep.  His name is Waymon Lee, and phone # is 415-855-0519.

Let us know what you find out.

Suzanne Johnson

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

Date: 23 Jun 1983 at 1527-PDT
From: dan@sri-tsc
To: Suzanne Johnson <JOHNSON@SUMEX-AIM.ARPA>
cc: tcp-ip@brl
Subject: Re: ibm tcp/ip

Doug McKay is indeed working on TCP/IP for the Series I.  He is porting
the SRI TCP/IP for PDP11/44's (which is itself a port of the 4.1b BSD
VAX UNIX TCP/IP).  It was my understanding that it is being integrated
into the version of UNIX they have running on the Series I and whatever
other IBM systems are running UNIX.  I don't know if his group is also
working on TCP/IP for non-unix operating systems, but I got the
impression from talking to him that they were not.

	-Dan Chernikoff (dan@sri-tsc)
	SRI International

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

Date: 23 Jun 1983 0:57-EDT
From: Lee.Moore@Rochester.ARPA
Subject: Re: TCP-IP Digest, Vol 2 #11
To: tcp-ip@brl-vgr.ARPA
Origin: Filter-Queen

RE: hooking IBM's to an ethernet

I recently got a glossy brochure describing an IBM channel interface
for ethernet from ACC.  Does anybody know anything about this?

=lee

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

Date: 22 Jun 1983 0209-PDT
Sender: GEOFF@sri-csl
Subject: Gateways- When should I ping, When should I purge, Who should I have?
From: the tty of Geoffrey S. Goodfellow
Reply-To: Geoff@sri-csl
To: POSTEL@usc-isif, HEDRICK@rutgers, MRC@su-score
To: snelson@office-1, bhitson@bbn-unix, tcp-ip@brl

So far we have heard that pinging gateways in a hosts gateway
cache every 37 seconds is too often and that very likely every
TENEX and TOPS-20 site on the ARPANET is currently doing this.
We had a suggestion that it might not be necessary to ping
gateways at all.  However, it was also suggested pinging gateways
periodically might be a good idea.

It was suggested that entries in a hosts dynamic gateway table
should be aged and deleted after about an hours time.

A number of informed parties suggested that each site configure
the contents of their INTERNET.GATEWAYS file very carefully and
some very helpful guidelines for choosing the initial contents of
your INTERNET.GATEWAYS file was given.

What I would like to see explored, discussed and hopefully
resolved by this group is:

1) What is the ideal interval with which to PING and under what
circumstances should I PING?

2) What is the ideal time a gateway entry should remain in a
given hosts gateway table before it is aged and flushed?

I think how one should configure the contents of their initial
INTERNET.GATEWAYS file was pretty well explained by Charlie Lynn,
but I still have not heard anything concrete enough on the
subject of when to PING and when to purge to make me dash to my
TENEX sources and stick the code in.

Could we hear from other operating system wizards on how
FUZZBALLS, TAC's, UNIX, Multics, VMS, IBM hosts, TIU's and so
forth have done it and from the Internet Holy Water Sprinklers on
what the ideal values would be?

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

Date: 22 Jun 1983 0329-PDT
From: Henry W. Miller <Miller@sri-nic>
Subject: Re: Gateways- When should I ping, When should I purge, Who should I have?
To: Geoff@sri-csl, POSTEL@usc-isif, HEDRICK@rutgers, MRC@su-score, 
    tcp-ip@brl, tcp-ip@sri-nic, tcp-ip-tops20@sri-nic, tops-20@su-score
cc: Miller@sri-nic

1)	Jon sez that it is not necessary to ping; that ICMP
redirects will handle it.  OK, seems reasonable, depending
on your net traffic.  Knowing a probable path, and trying
it first, and recovering from it in case of error seems
more efficient than probing J. Random Prime Gateway, hoping
for a win.  (This is why I'm in favor of rich gateway tables;
it gives you more initial options.)

2)	If you choose to ping, to keep up with the state of the
network, 37 seconds is clearly too short of a period to get a
snapshot of the net.  A couple of un-ACKED probes could lead one
to believe that a gate is down, when in fact, it might not be.
If pinging is desired, then an interval that is suffcently long
should be used, say 5-10 minutes.  (Personal opinion: A ping
from a host coming back on the air COULD/SHOULD be interpreted
as an "I'm Alive" message.  The gateways, in their infinte
wisdom, could spread the good news across the networks, so the
various hosts could update their routing tables.  Likewise, the
hosts should be able to poll the gateway of their dreams on
occaision and receive, in return, the latest routing poop.
A maxi ping, fer surre, but would help eliminate senseless
probings...)

3)	Updating routing tables: again, depending upon your
internet needs, 30 minutes at the max.  (Smallest interval...)
The current default, I believe is 6 hours.


4)	Another thot:  put a timer block in for each gateway:
when to ping next.  This would allow pinging on a selective
basis.

-HWM

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

Date: 22 Jun 1983  9:08:55 EDT (Wednesday)
From: Dennis Rockwell <drockwel@bbn-vax>
Subject: Re: Gateways- When should I ping, When should I purge, Who should I have?
To: Geoff@sri-csl
Cc: POSTEL@usc-isif, HEDRICK@rutgers, MRC@su-score, RLL.TYM@office-2, 
    DAB2.GVT@office-2, snelson@office-1, bhitson@bbn-unix, tcp-ip@brl

BBN UNIX hosts ping all gateways that are currently in use (defined as
having an open connection which has as its local-net destination a
gateway) constantly, at a rate of once every few seconds.

We have thought about fancy schemes involving only pinging when TCP
has to retransmit, but this leaves users of non-TCP services out
in the cold.  The rapid rate of pinging is for detection of a dead
first-hop gateway.  Unless one assumes an 1822 net, there is very likely
no feedback as to whether a packet is delivered or not (as was previously
noted, ethernet in particular has no such feedback).

Since we only ping active gateways, our hosts' gateway table contains
all the gateways we can find out about that are connected to whatever
local net(s) we are connected to.

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

Date: 22 Jun 1983 1433-EDT
From: Geoffrey H. Cooper <GEOF@mit-xx>
Subject: RE: Sending Pings to Gateways
To: TCP-IP@brl
cc: clynn@bbnc, geof@mit-xx

CLYNN's message describing the way in which TOPS-20 uses its list of
internet gateways brings up a more general problem with ICMP.  As
mentioned by Postel (in the last digest), every host implementation of
internet routing maintains a cache of <net,gateway_to_use> pairs, and a
list of "prime" internet gateways.  When a packet is routed the Internet
implementation first searches the cache for an appropriate gateway to
use.  If this search fails, the packet is sent to a "default intelligent
(prime) gateway" which will send a redirect back to the host IF A BETTER
GATEWAY EXISTS FOR THAT NET, so that subsequent packets to the same net
will hit the host's cache.  Note that the prime gateway can not be
relied upon to send a packet back (this is a necessary part of the way
internet routing works, since otherwise a prime gateway would have to
send back a redirect to itself for EVERY packet it forwards).

The question that arises is to which of the default gateways that are
known to the host should a "defaulted" packet be sent?  The answer is,
of course, to the least-loaded, working (up), closest default gateway.
Unfortunately, none of those attributes is determinable by the host.

If the host is on the Arpanet, it would be possible to make use of the
arpanet's "host dead" messages to determine that a particular prime
gateway doesn't seem to be working (either because it is too busy or
crashed).  Thus, it would be possible to order the prime gateways that a
host knows about in order of "usefulness to the host" (or perhaps
closeness on the network is the best static measure to use).  The best
gateway (earliest on the list) is always used, and the network status
messages are used to declare that gateway's entry temporarily invalid
when packets sent to it result in "host dead" messages.

If the host is on a network other than the Arpanet, the problem is more
severe, since the network will generally not take the responsibility to
tell the host that a packet it sent was not received by the gateway to
which it was sent (the Ethernet is the best example of such a network).
If all packets are sent by default to a single "best" gateway and that
gateway is down, then all the packets will fall into a "black hole" and
a section of the internet will become inaccessible to the host.

One way to deal with this situation is what is done by Tops-20:
Explicitly and regularly find out what prime gateways are up, and always
send your packets to the best prime gateway that is up.  The last issue
of the digest described some of the problems with this approach.

Another approach is to use the telephone company's ''linefinder''
algorithm: Keep the N prime gateways that a host knows about in an
ordered table, and cycle through the table (i.e., always use the
''next''
gateway after the one that you last used).  The host maintains no
information on the state of the prime gateways in its tables.  Some
packets will indeed be sent to the "black hole" of a crashed prime
gateway; higher level protocols can be counted upon to retransmit these
packets, and will hit other gateways on the retransmissions.

One advantage of this scheme is that it ``load shares'' the burden of
sending redirects among all of the prime gateways that a host knows
about, rather than placing undue burden on one particular gateway that
it considers to be the "best."

Another advantage is that it leaves a host implementation open to the
add the identities of new prime gateways to its tables.  Consider the
following algorithm: when a host receives a redirect to a gateway, it
place a ``dubious'' entry for that gateway into its prime gateway table.
The entry is dubious because the host knows that the gateway exists, but
does not know if it is a prime gateway.  A count is kept of the number
of times a packet is sent to that gateway.  If, say, five packets are
sent to the gateway, and no redirect is ever seen from it, then the
gateway is deleted from the host's prime gateway table.  If a redirect
is seen from the gateway in question, the gateway's entry may be
upgraded from "dubious" to "certain." In this way, a host can slowly
accumulate information about the gateways that are of most use to it in
the internet.

Although I am biased (since the above scheme is of my own design), I
believe that the idea of cycling through the list of known gateways is
the "way to go." The advantages I see are, once more:

	1. Solves "black hole" disease
	2. Shares the "redirect" load among many gateways
	3. Allows a host to dynamically learn about new prime gateways

- Geof Cooper
  MIT

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

Date: 22 Jun 1983 1132-PDT
Subject: Re: Warning, TCP-4 problems
From: Craig Milo Rogers <ROGERS@usc-isib>
To: David Roode <ROODE@sri-nic>, HEDRICK@rutgers, MRC@su-score
cc: RLL.TYM@office-2, tharris@ddn1, jmayersohn@bbn-unix, ddnsr@bbn-unix, 
    tcp-ip@brl, tcp-ip@sri-nic, tcp-ip-tops20@sri-nic, tops-20@su-score

	The programs <PRVSYS>IGGSTS.EXE and <PRVSYS>IGWSTS.EXE on ISIA,B,D-F
will print TOPS20's Ping table and network routing table, respectively.
(The names are holdovers from the GGP days).  However, I don't expect
these programs to work outside ISI, because they use an ISI-specific (I
think) JSYS to map monitor pages (GTMPG).  The sources are in BLISS-10.
There are help files in <PRVSYS>.  You need the Wheel privelege to run
the programs.
					Craig Milo Rogers

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

Date:     Tue, 28 Jun 83 21:45:37 EDT
From:     Ron Natalie <ron@brl-bmd>
To:       tcp-ip@brl-bmd, unix-wizards@brl-bmd
cc:       msggroup@brl-bmd
Subject:  Security Problem?

I have noticed that many sites have taken the precaution of
having their login programs (and their FTP servers) not make
a distinction between an invalid user name and an invalid
password.  The reasoning behind this is that if a user could
tell, he could sit there hacking a user name until he got a
valid one and then start hacking its password.  While trying
to figure out a user name that I had written down rather illegibly,
I found this is a rather effective deterrent to those guessing
at user name.

Until I got the following idea.  I connected to the site's
SMTP server and did the following:

	220 HOST-OF-HOSTS SERVER SMTP
	HELO HACKER
	250 HOST-OF-HOSTS
	MAIL FROM: <HACKER@ARPALAND>
	250 OK
	RCPT TO: <ROT@HOST-OF-HOSTS>
	550 We have no "ROT" here.
	RCPT TO: <ROOT@HOST-OF-HOSTS>
	250 Recipient accepted.

Since most machines have mailboxes that are the same as the valid
login names, this may prove an effective way of hacking the names.
In addition, the easiest way to get user names at valid hosts is
to just subscribe to one of the busy mailing lists and use the ones
of those sending mail.

-Ron

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

Date: 29 Jun 1983 09:10-PDT
Sender: GEOFF@sri-csl
Subject: Re:  Security Problem?
From: the tty of Geoffrey S. Goodfellow
Reply-To: Geoff@sri-csl
To: ron@brl-bmd
Cc: tcp-ip@brl-bmd, unix-wizards@brl-bmd
Cc: msggroup@brl-bmd

A real easy way of "hacking names" on a host is to just connect
up with TELNET and do a SYSTAT or FINGER.  Big Deal.

A gourmet "name hacker" would use the NIC's informative "WHOIS"
Server.  Just give the name of your favorite host preceded with a
star `*' (i.e.  try `*brl' for example) and a nicely formatted
list, replete with full name, initials(nic id), mailbox and phone
number will promptly be displayed.

Happy Hacking.

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

Date: Wednesday, 29 Jun 1983 12:41-PDT
To: Ron Natalie <ron@brl-bmd>
Cc: tcp-ip@brl-bmd, unix-wizards@brl-bmd, msggroup@brl-bmd
Subject: Re:  Security Problem?
From: greep@su-dsn

Other tactics include looking in the Arpanet directory or just trying
common names.  In addition, many Unix sites have a "who" login that
runs the "who" or "finger" program, and most tops-20 sites let you
run "finger" or "systat" without being logged in.  In fact, you can
(at least with some dec-20's) run finger with a null argument and
get a list of every user (not just those logged in).  It is generally
agreed that keeping user names secret is not a reasonable thing to
do -- that's what passwords are for.

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

Date: Tue 28 Jun 83 23:17:08-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: Security Problem?
To: ron@BRL-BMD.ARPA
cc: tcp-ip@BRL-BMD.ARPA, unix-wizards@BRL-BMD.ARPA, msggroup@BRL-BMD.ARPA

     One thing you could do would be to not validate mailboxes in the
SMTP server, but that only delays the error message unless you "black
hole" mail to invalid mailboxes.  It's a trade-off between security and
friendliness.

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

Date: 28 Jun 1983 2357-PDT
Subject: Re: Security Problem?
From: Einar Stefferud <msggroup-request@brl>
To: ron@brl-bmd
Cc: tcp-ip@brl-bmd, unix-wizards@brl-bmd
Cc: msggroup@brl-bmd

[ Comments to MSGGROUP readers deleted here -Mike ]

Rather than trying to shut down the ability to extract login names
from mail servers, I think attention should be focused on other
security techniques.

Like, making the penalty higher for failing to login correctly, and
making the user start over at the beginning of the whole process when
an error occurs before completion.  One thing to do is force a delay
following any failure, like an extra 5 or 10 seconds, which slows down
the hacking rate to less than 6 tries per minute.  Then, I think that
too many failures in a row should cause a disconnect, which further
slows down serious password hackers.

Seems to me that it is too easy to put obstacles in the way to let
ourselves get sidetracked into trying to conceal names.  Whither goest
the whole idea of name-servers if we try to close the mail gap?

So, lets just chase this issue back to the other lists, unless a more
genuine mail connection can be conjured up.

Cheers - Stef

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

END OF TCP-IP DIGEST
********************
-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30-Jun-83 08:36:25 EDT
From:      TCP-IP%brl@brl-bmd.UUCP
To:        fa.tcp-ip
Subject:   TCP-IP Digest, Vol 2 #12


TCP/IP Digest          Thursday, 30 June 1983      Volume 2 : Issue 12

Today's Topics:
                 IBM VM TCP/IP Implementation Now Exists
               Contacts within IBM for TCP/IP Information
                      Hooking IBMs to an Ethernet?
    Gateways: When should I ping, When should I purge, Who should I have?
                  Program to print TOPS20's Ping Table
               Security Problem with Mail?  Probably not.
----------------------------------------------------------------------
                  TCP/IP Digest --- The InterNet Digest
                         LIMITED DISTRIBUTION
          For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------

Date: 22 Jun 1983 13:22:04-CDT
From: L.H. Landweber <lhl@uwisc>
Reply-to: ibm-project@uwisc
To: tcp-ip@brl
Subject:  IBM VM TCP/IP IMPLEMENTATION

                  TCP/IP IBM VM IMPLEMENTATION


We are implementating of the Internet protocols (FTP/SMTP/Telnet/TCP/IP) for
IBM VM Systems under contract with IBM.  The TCP and IP have been running for
some time now under VM/SP on an IBM 4331 at Wisconsin and we are currently
putting the finishing touches on the higher-level protocols.  In addition, a
software interface between IP and an X.25 implementation running on a
Series/1 (RPS operating system) has been completed.  The complete package
will enable CSNET IBM VM hosts to connect to the Darpa Internet via Telenet.

The 4300 software is written almost entirely in Pascal, with a small amount
of assembler-language support.  Some assembler code running on the Series/1
interfaces with the X.25 code, which is a standard IBM product.  Standard IBM
released software is used throughout (i.e., no modified or unreleased system
software has been employed).

The software will be ready for initial distribution to test sites in mid-July.
We hope to have production versions available by the end of August.
Distribution will be controlled by IBM.  We encourage interested parties to
contact:

          Mr. Carl VanWinter
          IBM  Corporation
          Rochester, MN
          507-286-3378

to express an interest or request information on distribution
plans.


ADDITIONAL DETAILS

TCP/IP runs in a separate disconnected virtual machine.  Similarly, SMTP,
server FTP, and server Telnet each occupies a dedicated virtual machine.
User FTP and user Telnet run within a user's virtual machine under CMS.
Communication between virtual machines is done through the IBM Virtual
Machine Communication Facility (VMCF).  A detailed preliminary design
document is available by contacting one of the individuals listed below.
(Some details have changed since it was written, but it is still mostly
accurate.)

Over the Summer we expect to implement a Pronet driver to enable
our IP/TCP to use the PRONET 10 megabit/sec token ring LAN.  The hardware
interface will be via a DACU (Device Access Control Unit) provided by IBM.
The DACU enables connection of UNIBUS devices to an IBM channel.  We expect
other university groups to provide a driver for Ethernet.  We estimate that
each of these projects will take 2-4 man-months to complete.

Direct connection to a C/30 IMP will require implementation of a software
driver in conjunction with a suitable hardware interface (e.g., DACU--LH/DH
or Series/1--HDH).

For further technical information contact:

          David DeWitt, Larry Landweber, or Marvin Solomon
          Computer Science Department
          University of Wisconsin
          1210 W. Dayton St.
          Madison, WI 53706
          608-262-1204

		  ibm-project@uwisc

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

Date: Thu 23 Jun 83 09:08:37-PDT
From: Suzanne Johnson <JOHNSON@SUMEX-AIM.ARPA>
Subject: tcp/ip ibm info
To: tcp-ip@BRL.ARPA

It turns out that if you give your IBM rep VERY specific information on
WHO and WHERE within IBM the tcp/ip work goes on, they can follow up for
you.

The tcp/ip work is evidently being done by IBM's Federal Systems Division
in Gaithersburg, Maryland.  The person doing the work is Doug McKay.

Our rep was able to confirm this, given the above info.  Since he is
somewhat up-to-date on status, you might have your rep contact
our IBM rep.  His name is Waymon Lee, and phone # is 415-855-0519.

Let us know what you find out.

Suzanne Johnson

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

Date: 23 Jun 1983 at 1527-PDT
From: dan@sri-tsc
To: Suzanne Johnson <JOHNSON@SUMEX-AIM.ARPA>
cc: tcp-ip@brl
Subject: Re: ibm tcp/ip

Doug McKay is indeed working on TCP/IP for the Series I.  He is porting
the SRI TCP/IP for PDP11/44's (which is itself a port of the 4.1b BSD
VAX UNIX TCP/IP).  It was my understanding that it is being integrated
into the version of UNIX they have running on the Series I and whatever
other IBM systems are running UNIX.  I don't know if his group is also
working on TCP/IP for non-unix operating systems, but I got the
impression from talking to him that they were not.

	-Dan Chernikoff (dan@sri-tsc)
	SRI International

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

Date: 23 Jun 1983 0:57-EDT
From: Lee.Moore@Rochester.ARPA
Subject: Re: TCP-IP Digest, Vol 2 #11
To: tcp-ip@brl-vgr.ARPA
Origin: Filter-Queen

RE: hooking IBM's to an ethernet

I recently got a glossy brochure describing an IBM channel interface
for ethernet from ACC.  Does anybody know anything about this?

=lee

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

Date: 22 Jun 1983 0209-PDT
Sender: GEOFF@sri-csl
Subject: Gateways- When should I ping, When should I purge, Who should I have?
From: the tty of Geoffrey S. Goodfellow
Reply-To: Geoff@sri-csl
To: POSTEL@usc-isif, HEDRICK@rutgers, MRC@su-score
To: snelson@office-1, bhitson@bbn-unix, tcp-ip@brl

So far we have heard that pinging gateways in a hosts gateway
cache every 37 seconds is too often and that very likely every
TENEX and TOPS-20 site on the ARPANET is currently doing this.
We had a suggestion that it might not be necessary to ping
gateways at all.  However, it was also suggested pinging gateways
periodically might be a good idea.

It was suggested that entries in a hosts dynamic gateway table
should be aged and deleted after about an hours time.

A number of informed parties suggested that each site configure
the contents of their INTERNET.GATEWAYS file very carefully and
some very helpful guidelines for choosing the initial contents of
your INTERNET.GATEWAYS file was given.

What I would like to see explored, discussed and hopefully
resolved by this group is:

1) What is the ideal interval with which to PING and under what
circumstances should I PING?

2) What is the ideal time a gateway entry should remain in a
given hosts gateway table before it is aged and flushed?

I think how one should configure the contents of their initial
INTERNET.GATEWAYS file was pretty well explained by Charlie Lynn,
but I still have not heard anything concrete enough on the
subject of when to PING and when to purge to make me dash to my
TENEX sources and stick the code in.

Could we hear from other operating system wizards on how
FUZZBALLS, TAC's, UNIX, Multics, VMS, IBM hosts, TIU's and so
forth have done it and from the Internet Holy Water Sprinklers on
what the ideal values would be?

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

Date: 22 Jun 1983 0329-PDT
From: Henry W. Miller <Miller@sri-nic>
Subject: Re: Gateways- When should I ping, When should I purge, Who should I have?
To: Geoff@sri-csl, POSTEL@usc-isif, HEDRICK@rutgers, MRC@su-score,
    tcp-ip@brl, tcp-ip@sri-nic, tcp-ip-tops20@sri-nic, tops-20@su-score
cc: Miller@sri-nic

1)	Jon sez that it is not necessary to ping; that ICMP
redirects will handle it.  OK, seems reasonable, depending
on your net traffic.  Knowing a probable path, and trying
it first, and recovering from it in case of error seems
more efficient than probing J. Random Prime Gateway, hoping
for a win.  (This is why I'm in favor of rich gateway tables;
it gives you more initial options.)

2)	If you choose to ping, to keep up with the state of the
network, 37 seconds is clearly too short of a period to get a
snapshot of the net.  A couple of un-ACKED probes could lead one
to believe that a gate is down, when in fact, it might not be.
If pinging is desired, then an interval that is suffcently long
should be used, say 5-10 minutes.  (Personal opinion: A ping
from a host coming back on the air COULD/SHOULD be interpreted
as an "I'm Alive" message.  The gateways, in their infinte
wisdom, could spread the good news across the networks, so the
various hosts could update their routing tables.  Likewise, the
hosts should be able to poll the gateway of their dreams on
occaision and receive, in return, the latest routing poop.
A maxi ping, fer surre, but would help eliminate senseless
probings...)

3)	Updating routing tables: again, depending upon your
internet needs, 30 minutes at the max.  (Smallest interval...)
The current default, I believe is 6 hours.


4)	Another thot:  put a timer block in for each gateway:
when to ping next.  This would allow pinging on a selective
basis.

-HWM

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

Date: 22 Jun 1983  9:08:55 EDT (Wednesday)
From: Dennis Rockwell <drockwel@bbn-vax>
Subject: Re: Gateways- When should I ping, When should I purge, Who should I have?
To: Geoff@sri-csl
Cc: POSTEL@usc-isif, HEDRICK@rutgers, MRC@su-score, RLL.TYM@office-2,
    DAB2.GVT@office-2, snelson@office-1, bhitson@bbn-unix, tcp-ip@brl

BBN UNIX hosts ping all gateways that are currently in use (defined as
having an open connection which has as its local-net destination a
gateway) constantly, at a rate of once every few seconds.

We have thought about fancy schemes involving only pinging when TCP
has to retransmit, but this leaves users of non-TCP services out
in the cold.  The rapid rate of pinging is for detection of a dead
first-hop gateway.  Unless one assumes an 1822 net, there is very likely
no feedback as to whether a packet is delivered or not (as was previously
noted, ethernet in particular has no such feedback).

Since we only ping active gateways, our hosts' gateway table contains
all the gateways we can find out about that are connected to whatever
local net(s) we are connected to.

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

Date: 22 Jun 1983 1433-EDT
From: Geoffrey H. Cooper <GEOF@mit-xx>
Subject: RE: Sending Pings to Gateways
To: TCP-IP@brl
cc: clynn@bbnc, geof@mit-xx

CLYNN's message describing the way in which TOPS-20 uses its list of
internet gateways brings up a more general problem with ICMP.  As
mentioned by Postel (in the last digest), every host implementation of
internet routing maintains a cache of <net,gateway_to_use> pairs, and a
list of "prime" internet gateways.  When a packet is routed the Internet
implementation first searches the cache for an appropriate gateway to
use.  If this search fails, the packet is sent to a "default intelligent
(prime) gateway" which will send a redirect back to the host IF A BETTER
GATEWAY EXISTS FOR THAT NET, so that subsequent packets to the same net
will hit the host's cache.  Note that the prime gateway can not be
relied upon to send a packet back (this is a necessary part of the way
internet routing works, since otherwise a prime gateway would have to
send back a redirect to itself for EVERY packet it forwards).

The question that arises is to which of the default gateways that are
known to the host should a "defaulted" packet be sent?  The answer is,
of course, to the least-loaded, working (up), closest default gateway.
Unfortunately, none of those attributes is determinable by the host.

If the host is on the Arpanet, it would be possible to make use of the
arpanet's "host dead" messages to determine that a particular prime
gateway doesn't seem to be working (either because it is too busy or
crashed).  Thus, it would be possible to order the prime gateways that a
host knows about in order of "usefulness to the host" (or perhaps
closeness on the network is the best static measure to use).  The best
gateway (earliest on the list) is always used, and the network status
messages are used to declare that gateway's entry temporarily invalid
when packets sent to it result in "host dead" messages.

If the host is on a network other than the Arpanet, the problem is more
severe, since the network will generally not take the responsibility to
tell the host that a packet it sent was not received by the gateway to
which it was sent (the Ethernet is the best example of such a network).
If all packets are sent by default to a single "best" gateway and that
gateway is down, then all the packets will fall into a "black hole" and
a section of the internet will become inaccessible to the host.

One way to deal with this situation is what is done by Tops-20:
Explicitly and regularly find out what prime gateways are up, and always
send your packets to the best prime gateway that is up.  The last issue
of the digest described some of the problems with this approach.

Another approach is to use the telephone company's ''linefinder''
algorithm: Keep the N prime gateways that a host knows about in an
ordered table, and cycle through the table (i.e., always use the
''next''
gateway after the one that you last used).  The host maintains no
information on the state of the prime gateways in its tables.  Some
packets will indeed be sent to the "black hole" of a crashed prime
gateway; higher level protocols can be counted upon to retransmit these
packets, and will hit other gateways on the retransmissions.

One advantage of this scheme is that it ``load shares'' the burden of
sending redirects among all of the prime gateways that a host knows
about, rather than placing undue burden on one particular gateway that
it considers to be the "best."

Another advantage is that it leaves a host implementation open to the
add the identities of new prime gateways to its tables.  Consider the
following algorithm: when a host receives a redirect to a gateway, it
place a ``dubious'' entry for that gateway into its prime gateway table.
The entry is dubious because the host knows that the gateway exists, but
does not know if it is a prime gateway.  A count is kept of the number
of times a packet is sent to that gateway.  If, say, five packets are
sent to the gateway, and no redirect is ever seen from it, then the
gateway is deleted from the host's prime gateway table.  If a redirect
is seen from the gateway in question, the gateway's entry may be
upgraded from "dubious" to "certain." In this way, a host can slowly
accumulate information about the gateways that are of most use to it in
the internet.

Although I am biased (since the above scheme is of my own design), I
believe that the idea of cycling through the list of known gateways is
the "way to go." The advantages I see are, once more:

	1. Solves "black hole" disease
	2. Shares the "redirect" load among many gateways
	3. Allows a host to dynamically learn about new prime gateways

- Geof Cooper
  MIT

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

Date: 22 Jun 1983 1132-PDT
Subject: Re: Warning, TCP-4 problems
From: Craig Milo Rogers <ROGERS@usc-isib>
To: David Roode <ROODE@sri-nic>, HEDRICK@rutgers, MRC@su-score
cc: RLL.TYM@office-2, tharris@ddn1, jmayersohn@bbn-unix, ddnsr@bbn-unix,
    tcp-ip@brl, tcp-ip@sri-nic, tcp-ip-tops20@sri-nic, tops-20@su-score

	The programs <PRVSYS>IGGSTS.EXE and <PRVSYS>IGWSTS.EXE on ISIA,B,D-F
will print TOPS20's Ping table and network routing table, respectively.
(The names are holdovers from the GGP days).  However, I don't expect
these programs to work outside ISI, because they use an ISI-specific (I
think) JSYS to map monitor pages (GTMPG).  The sources are in BLISS-10.
There are help files in <PRVSYS>.  You need the Wheel privelege to run
the programs.
					Craig Milo Rogers

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

Date:     Tue, 28 Jun 83 21:45:37 EDT
From:     Ron Natalie <ron@brl-bmd>
To:       tcp-ip@brl-bmd, unix-wizards@brl-bmd
cc:       msggroup@brl-bmd
Subject:  Security Problem?

I have noticed that many sites have taken the precaution of
having their login programs (and their FTP servers) not make
a distinction between an invalid user name and an invalid
password.  The reasoning behind this is that if a user could
tell, he could sit there hacking a user name until he got a
valid one and then start hacking its password.  While trying
to figure out a user name that I had written down rather illegibly,
I found this is a rather effective deterrent to those guessing
at user name.

Until I got the following idea.  I connected to the site's
SMTP server and did the following:

	220 HOST-OF-HOSTS SERVER SMTP
	HELO HACKER
	250 HOST-OF-HOSTS
	MAIL FROM: <HACKER@ARPALAND>
	250 OK
	RCPT TO: <ROT@HOST-OF-HOSTS>
	550 We have no "ROT" here.
	RCPT TO: <ROOT@HOST-OF-HOSTS>
	250 Recipient accepted.

Since most machines have mailboxes that are the same as the valid
login names, this may prove an effective way of hacking the names.
In addition, the easiest way to get user names at valid hosts is
to just subscribe to one of the busy mailing lists and use the ones
of those sending mail.

-Ron

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

Date: 29 Jun 1983 09:10-PDT
Sender: GEOFF@sri-csl
Subject: Re:  Security Problem?
From: the tty of Geoffrey S. Goodfellow
Reply-To: Geoff@sri-csl
To: ron@brl-bmd
Cc: tcp-ip@brl-bmd, unix-wizards@brl-bmd
Cc: msggroup@brl-bmd

A real easy way of "hacking names" on a host is to just connect
up with TELNET and do a SYSTAT or FINGER.  Big Deal.

A gourmet "name hacker" would use the NIC's informative "WHOIS"
Server.  Just give the name of your favorite host preceded with a
star `*' (i.e.  try `*brl' for example) and a nicely formatted
list, replete with full name, initials(nic id), mailbox and phone
number will promptly be displayed.

Happy Hacking.

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

Date: Wednesday, 29 Jun 1983 12:41-PDT
To: Ron Natalie <ron@brl-bmd>
Cc: tcp-ip@brl-bmd, unix-wizards@brl-bmd, msggroup@brl-bmd
Subject: Re:  Security Problem?
From: greep@su-dsn

Other tactics include looking in the Arpanet directory or just trying
common names.  In addition, many Unix sites have a "who" login that
runs the "who" or "finger" program, and most tops-20 sites let you
run "finger" or "systat" without being logged in.  In fact, you can
(at least with some dec-20's) run finger with a null argument and
get a list of every user (not just those logged in).  It is generally
agreed that keeping user names secret is not a reasonable thing to
do -- that's what passwords are for.

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

Date: Tue 28 Jun 83 23:17:08-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: Security Problem?
To: ron@BRL-BMD.ARPA
cc: tcp-ip@BRL-BMD.ARPA, unix-wizards@BRL-BMD.ARPA, msggroup@BRL-BMD.ARPA

     One thing you could do would be to not validate mailboxes in the
SMTP server, but that only delays the error message unless you "black
hole" mail to invalid mailboxes.  It's a trade-off between security and
friendliness.

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

Date: 28 Jun 1983 2357-PDT
Subject: Re: Security Problem?
From: Einar Stefferud <msggroup-request@brl>
To: ron@brl-bmd
Cc: tcp-ip@brl-bmd, unix-wizards@brl-bmd
Cc: msggroup@brl-bmd

[ Comments to MSGGROUP readers deleted here -Mike ]

Rather than trying to shut down the ability to extract login names
from mail servers, I think attention should be focused on other
security techniques.

Like, making the penalty higher for failing to login correctly, and
making the user start over at the beginning of the whole process when
an error occurs before completion.  One thing to do is force a delay
following any failure, like an extra 5 or 10 seconds, which slows down
the hacking rate to less than 6 tries per minute.  Then, I think that
too many failures in a row should cause a disconnect, which further
slows down serious password hackers.

Seems to me that it is too easy to put obstacles in the way to let
ourselves get sidetracked into trying to conceal names.  Whither goest
the whole idea of name-servers if we try to close the mail gap?

So, lets just chase this issue back to the other lists, unless a more
genuine mail connection can be conjured up.

Cheers - Stef

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

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

END OF DOCUMENT