The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2-Sep-86 03:18:43 EDT
From:      JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa")
To:        mod.protocols.tcp-ip
Subject:   Re: Possible DDN to Ethernet or 802.3 Gateway Vendors


	Let me correct some slight errors in that posting about the
Proteon entry: a) Proteon does not yet have a DDN X.25 interface, but
hope to have one soon; b) for details please *do not* contact me, but
call Proteon at 617-655-3340.

	Noel
-------

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2-Sep-86 09:45:00 EDT
From:      DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer)
To:        mod.protocols.tcp-ip
Subject:   How to IP & ARP on 802 Nets


    Date: 29 Aug 1986 19:27:12 PDT
    From: POSTEL@B.ISI.EDU

    Hello. 
Hi.

    At an ad hoc special session on "IEEE 802 Networks and ARP" held
    during the recent TCP Vendors Workshop, an approach to a consistent
    way to sent DOD-IP datagrams and other IP related protocols on 802
    networks was developed.

    [...]

A very quick reading of this and a small amount of knowledge about 802.x
leads me to believe this looks reasonable.  The problem I see is "What
happens if ISO blesses DoD IP and then there are two different ways to
talk it?"

    The total length of the SAP Header and the SNAP header is 8-octets,
    making the 802.2 protocol overhead come out on a nice octet boundary.

Good.

    If we can not quickly resolve the issue of the values for K1 and K2,
    we will push for the assignment of a sap value (a K1 value) to
    indicate "IP related protocols" and do our own multiplexing (much like
    that proposed above).

Please don't say "IP related protocols."  Only one protocol is IP
related and that is IP.  Instead say "Ethernet'1980 related protocols"
which includes Chaos, PUP, XNS, DECnet, etc.

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Wed,  3-SEP-1986 17:20 EDT
From:      Ronald A. Jarrell  <JARRELLRA%VTVAX3.BITNET@WISCVM.WISC.EDU>
To:        <tcp-ip@sri-nic.arpa>
Subject:   nsfnet


We plan on hooking to nsfnet in the near future, probably through a sattelite
link and an imp.  We were going to be running Wollongong's WIN on the Vaxes,
but I've been told we are going to have a horrible time with it, that it
wouldn't work with out a lot of kluding.. Anyone have suggestions as to a
good, full-function, tcpip package to use in this situation?  It would
need ddn protocol support, and be able to talk to unix flavor systems.

Please also mention whether or not it would require new hardware, or if
we could share the deuna we currently have for decnet and lat.


Also, while I'm thinking of it, anyone have PD or non-PD code for domain
support for a VMS system?

-Ron
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2-Sep-86 14:20:46 EDT
From:      jas@BRUBECK.PROTEON.COM
To:        mod.protocols.tcp-ip
Subject:   Re: How to IP & ARP on 802 Nets

Your K1 (the SNAP SAP) is '01010101' when presented least signifigant
bit first. (First bit to the MAC layer first.) For those of us who think
in a forward direction, this is '10101010', or 'AA'hex.

While SNAP is only a proposal, I beleive it is de-facto real. I understand
that certain proprietary network vendors already plan to use it.

By the way, "ethernet types" were handed over by Xerox to the IEEE along
with the 24-bit address blocks. There is no list available from IEEE of
the allocation of either type of block, they consider that proprietary.

I have heard rumors that K2 is '0', and that this 24-bit block belongs to Xerox.
Are the Xerox people out there who can confirm this?

					john shriver
					proteon
-------

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2-Sep-86 14:27:27 EDT
From:      jas@BRUBECK.PROTEON.COM
To:        mod.protocols.tcp-ip
Subject:   Re: How to IP & ARP on 802 Nets

There already was a blessed way to send IP packets over 802.2. The problem
was that the powers that be were NEVER going to provide a SAP for ARP,
so the IP SAP was useless. Once we had this scheme for ARP, we decided
to do IP that way to provide an even-length data-link header, and one the
same size as ARP. (DoD Internet is SAP '06'hex.)
-------

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Sep 86 23:45 PDT
From:      Provan@LLL-MFE.ARPA
To:        tcp-ip@sri-nic.arpa
Subject:   re: How to IP & ARP on 802 nets

I have two problems with this scheme.  Unfortunately, both are caused by
the SNAP, which seems to be the part closest to being fully blessed.

The first problem is the 24 bit "organization" code.  A 24 bit field
seems excessively clumsy.  (In the immortal words of 1822, it's "not
particularly convenient for anyone.")  Not too serious, but it fits well
with my solution.

The second problem is that this plan works great with 802.2 type 1
headers, but 802.2 type 2 messages add an additional byte to the normal
802.2 header.  If the SNAP scheme is unchanged in this situation, we
find ourselves with the new ethernet type field shifted back to an odd
byte and our IP packet gets out of alignment.  Does anyone know what
happens to the SNAP in type 2?  I don't know if it's feasible to send IP
packets over type 2 802.2, but if it is we need to worry about this.

I have a solution that solves both of these problems.  Instead of a 24
bit organization code, break it into an eight bit unused pad field
followed by a 16 bit organization code.  (Happily, this field is then
aligned to an even byte.)  In type 2 802.2 packets, this unused eight
bits becomes the second byte of the 802.2 control field, but the other
four bytes of the SNAP (two for the organization code and two for the
new ethernet type field) remain the same.  So the 802.2 header would be
the same size (eight bytes) for both type 1 and type 2 packets, rather
than have the three byte header for type 1 and the four byte header for
type 2 in the currently published protocol.

Of course, this assumes we have anything to say about this.  Since this
doesn't appear to be the case, i guess it's too late to avoid these
problems.

Looking back on this note, i realize that someone without familiarity
with 802.2 might be confused.  I think i can lessen the confusion by
explaining that 802.2 packets, including these three or four (or eight)
byte headers, ride inside 802.3 packets, which have the familiar 14
byte ethernet header, with the ethernet type field replaced by the
famous 802.3 length field.

While i have the floor, at the TCP workshop, i think i heard twice that
802.3 lengths less than 60 are illegal, and, therefore, fall under the
famous ethernet footnote, which says that any illegal lengths can be
interpreted however the implementation wants (thus allowing previous
ethernet implementations to continue to operate on the same network as
802.3 impelmentations).  If i heard correctly, i'd like to point out
that this is not correct.  Lengths less than 60 are legal in 802.3.  In
fact, it's the need to express a packet smaller than 60 bytes in a
hardware environment which doesn't allow transmission of packets less
60 bytes in length that is the justification for the length field in
the first place.  (A packet can be padded out to 60 bytes while the
true length of the packet is preserved via the length field.)

						don provan
						provan@lll-mfe.arpa
-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4-Sep-86 02:01:55 EDT
From:      JARRELLRA@VTVAX3.BITNET (Ronald A. Jarrell)
To:        mod.protocols.tcp-ip
Subject:   nsfnet



We plan on hooking to nsfnet in the near future, probably through a sattelite
link and an imp.  We were going to be running Wollongong's WIN on the Vaxes,
but I've been told we are going to have a horrible time with it, that it
wouldn't work with out a lot of kluding.. Anyone have suggestions as to a
good, full-function, tcpip package to use in this situation?  It would
need ddn protocol support, and be able to talk to unix flavor systems.

Please also mention whether or not it would require new hardware, or if
we could share the deuna we currently have for decnet and lat.


Also, while I'm thinking of it, anyone have PD or non-PD code for domain
support for a VMS system?

-Ron

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4-Sep-86 02:14:56 EDT
From:      mrose@NRTC-GREMLIN.ARPA (Marshall Rose)
To:        mod.protocols.tcp-ip
Subject:   The ISO Development Environment at NRTC

[ multiple appologies for posting this to multiple lists... ]

/mtr
-----
			 A N N O U N C E M E N T


    The first release of the ISO Development Environment at NRTC is
    available for distribution.  This release is called

				ISODE 1.0

    This software supports the development of certain kinds of
    ISO/CCITT/ECMA protocols and applications.  

    Here are the details:

	 - ISODE is not proprietary, but it is not in the public domain.
	   This was necessary to include a "hold harmless" clause in the
	   release.  The upshot of all this is that anyone can get a
	   copy of the release and do anything they want with it, but
	   no one takes any responsibility whatsoever for any (mis)use.

	 - ISODE runs on native 4.2BSD and SVR2 with an Excelan card
	   (Future releases will support VAX/VMS and a variant of PC/IP.)

	 - Current modules include:
		TSAP	- makes TCP look like TP4
		SSAP	- ISO BCS session
		PSAP	- ASN.1 encoding
		PEPY	- ASN.1 yacc-like facility
		RoSAP	- ECMA Remote Operations Services

	 - Although the ISODE is not "supported" per se, it does have a
	   problem-reporting address, ISO-People@NRTC.NORTHROP.COM.  Bug
	   reports (and fixes) are welcome by the way.  


    The primary documentation for this release consists of a User's
    Manual (approx 150 pages) and a set of UNIX manual pages.  The
    sources to the User's Manual are in LaTeX format.  In addition,
    there are a number of notes, papers, and presentations included in
    the documentation set, again in either LaTeX or SLiTeX format.  


    There are two ways to get a distribution:

    1.  If you can FTP to the ARPA Internet, use anonymous FTP to
    louie.udel.edu [10.0.0.96] and retrieve the file portal/isode-1.tar.
    This is a tar image (approx 2.0MB).  The file portal/isode-1.tar.Z is
    the tar image after being run through the compress program (approx 0.8MB).

    2. Send a magtape and a self-addressed mailing label to:

	Northrop Research and Technology Center
	Attn: Automation Sciences Laboratory (0330/T30)
	One Research Park
	Palos Verdes Peninsula, CA  90274
	USA

	+1-213/544-5393

    We will write the tape in tar format at 1600bpi, and return it with
    a copy of the User's manual.  

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4-Sep-86 02:45:00 EDT
From:      Provan@LLL-MFE.ARPA
To:        mod.protocols.tcp-ip
Subject:   re: How to IP & ARP on 802 nets


I have two problems with this scheme.  Unfortunately, both are caused by
the SNAP, which seems to be the part closest to being fully blessed.

The first problem is the 24 bit "organization" code.  A 24 bit field
seems excessively clumsy.  (In the immortal words of 1822, it's "not
particularly convenient for anyone.")  Not too serious, but it fits well
with my solution.

The second problem is that this plan works great with 802.2 type 1
headers, but 802.2 type 2 messages add an additional byte to the normal
802.2 header.  If the SNAP scheme is unchanged in this situation, we
find ourselves with the new ethernet type field shifted back to an odd
byte and our IP packet gets out of alignment.  Does anyone know what
happens to the SNAP in type 2?  I don't know if it's feasible to send IP
packets over type 2 802.2, but if it is we need to worry about this.

I have a solution that solves both of these problems.  Instead of a 24
bit organization code, break it into an eight bit unused pad field
followed by a 16 bit organization code.  (Happily, this field is then
aligned to an even byte.)  In type 2 802.2 packets, this unused eight
bits becomes the second byte of the 802.2 control field, but the other
four bytes of the SNAP (two for the organization code and two for the
new ethernet type field) remain the same.  So the 802.2 header would be
the same size (eight bytes) for both type 1 and type 2 packets, rather
than have the three byte header for type 1 and the four byte header for
type 2 in the currently published protocol.

Of course, this assumes we have anything to say about this.  Since this
doesn't appear to be the case, i guess it's too late to avoid these
problems.

Looking back on this note, i realize that someone without familiarity
with 802.2 might be confused.  I think i can lessen the confusion by
explaining that 802.2 packets, including these three or four (or eight)
byte headers, ride inside 802.3 packets, which have the familiar 14
byte ethernet header, with the ethernet type field replaced by the
famous 802.3 length field.

While i have the floor, at the TCP workshop, i think i heard twice that
802.3 lengths less than 60 are illegal, and, therefore, fall under the
famous ethernet footnote, which says that any illegal lengths can be
interpreted however the implementation wants (thus allowing previous
ethernet implementations to continue to operate on the same network as
802.3 impelmentations).  If i heard correctly, i'd like to point out
that this is not correct.  Lengths less than 60 are legal in 802.3.  In
fact, it's the need to express a packet smaller than 60 bytes in a
hardware environment which doesn't allow transmission of packets less
60 bytes in length that is the justification for the length field in
the first place.  (A packet can be padded out to 60 bytes while the
true length of the packet is preserved via the length field.)

						don provan
						provan@lll-mfe.arpa

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4-Sep-86 05:07:22 EDT
From:      steve@BRL.ARPA (Stephen Wolff)
To:        mod.protocols.tcp-ip
Subject:   Re:  nsfnet

I've been told SRI  markets a competitive package, but I've lost the
reference.  Help, someone?		-s

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Sep 86 5:07:22 EDT
From:      Stephen Wolff <steve@BRL.ARPA>
To:        "Ronald A. Jarrell" <JARRELLRA%VTVAX3.BITNET@wiscvm.wisc.edu>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re:  nsfnet
I've been told SRI  markets a competitive package, but I've lost the
reference.  Help, someone?		-s

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 1986 06:24-EDT
From:      CERF@A.ISI.EDU
To:        JARRELLRA%VTVAX3.BITNET@WISCVM.WISC.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  nsfnet
Ron,

without commenting on the Wollongong software, which I am not qualified to
express an opinion about since I have not used it nor reviewed its operation
in detail, there is a lengthy publication available from the SRI NIC, and
also available on line, I believe, listing quite a number of commercial
TCP/IP related products. I don't have the book here with me but urge you
to investigate via the NIC.

Of course, you should get some interesting replies from the TCP-IP 
distribution list, too. There is only modest support for VMS, as I
recall, as the bulk of the implementations stem from the Berkeley
UNIX effort (perhaps 50% are derived in that fashion).

Vint
-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 1986 11:03-PDT
From:      Mike StJohns <StJohns@SRI-NIC.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   1822 vs 1822L Survey
I  need to know what implementations use what version of the 1822
protocol to talk to their IMPs.  If you are an implementer,  tell
me  whether  your implementation talks 1822 or 1822L or both.  If
you have an X25 implementation, I would appreciate knowing  about
that  also.   Reply  directly  to me and I will summarize for the
network.  Implementers only please....  can you imagine how large
my  mailbox  will  be if everyone replied.  Thanks, Mike StJohns,
DCA B612
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5-Sep-86 16:03:59 EDT
From:      klem@BRL.ARPA
To:        mod.protocols.tcp-ip
Subject:   (none)

Subject: imprecise DDN X.25 specification?
Newsgroups: mod.protocols.tcp-ip
Distribution: usa
To: tcp-ip@sri-nic.arpa
Keywords: DDN X.25 CDC



We have a contract with CDC to build and install an interface from a CDC
Cyber 750 running NOS to a MILNET IMP.  The contractors attended a 3-day
TCP/IP Vendor Workshop in Monterey last month.  They came away from the
meeting with lots of questions.  Can anyone answer the concerns that were
surfaced at the meeting (see below for the contractor's questions)?

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

It was stated that the contractor can be implementing X.25 in agreement with
the contract specification, pass the DCA Qualification Test and not be able
to communicate with the IMP.  This is a result of the imprecise DDN X.25
specification and the incompleteness of the X.25 Qualification Testing.  

One X.25 issue that was discussed was the X.25/1822 incompatibility on the
network. It is our understanding that the government has developed hardware
and software solutions and has the situation under control.

Other issues that could affect the CDC interface to the IMP include:

1) CDC X.25 does not establish a virtual circuit for each and every local
network destination host and corresponding precedence.

2) CDC will provide the destination address to the IMP through the IP
header, as opposed to the X.25 header.

3) CDC will not map an IP address into X.25 and vice-versa.

Is it true that any or all of the above issues will create problems in the
CDC interface with the DDN?

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

Thanks,
George Klem <klem@brl.arpa>

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Sep 86 16:03:59 EDT
From:      klem@BRL.ARPA
To:        tcp-ip@sri-nic.arpa
Subject: imprecise DDN X.25 specification?
Newsgroups: mod.protocols.tcp-ip
Distribution: usa
To: tcp-ip@sri-nic.arpa
Keywords: DDN X.25 CDC



We have a contract with CDC to build and install an interface from a CDC
Cyber 750 running NOS to a MILNET IMP.  The contractors attended a 3-day
TCP/IP Vendor Workshop in Monterey last month.  They came away from the
meeting with lots of questions.  Can anyone answer the concerns that were
surfaced at the meeting (see below for the contractor's questions)?

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

It was stated that the contractor can be implementing X.25 in agreement with
the contract specification, pass the DCA Qualification Test and not be able
to communicate with the IMP.  This is a result of the imprecise DDN X.25
specification and the incompleteness of the X.25 Qualification Testing.  

One X.25 issue that was discussed was the X.25/1822 incompatibility on the
network. It is our understanding that the government has developed hardware
and software solutions and has the situation under control.

Other issues that could affect the CDC interface to the IMP include:

1) CDC X.25 does not establish a virtual circuit for each and every local
network destination host and corresponding precedence.

2) CDC will provide the destination address to the IMP through the IP
header, as opposed to the X.25 header.

3) CDC will not map an IP address into X.25 and vice-versa.

Is it true that any or all of the above issues will create problems in the
CDC interface with the DDN?

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

Thanks,
George Klem <klem@brl.arpa>

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5-Sep-86 18:25:31 EDT
From:      cetron@UTAH-CS.ARPA (Edward J Cetron)
To:        mod.protocols.tcp-ip
Subject:   Re: nsfnet

-------------------------- the standard sacrificial line

	We have been using the Tektronix tcp/ip package for quite a
few months and have found it extremely useful... A quick summary:

	Advantages (especially vs. WIN/VX)

	1. you are given ALL of the source code (albeit in bliss)
	2. the code is NATIVE-style NOT a unix port
	3. it has proved to be very reliable, easy to modify for local
		hacks/improvements
	4. with very few exceptions, it is very clean, readable code which
		tends to follow the tcp mil-std very well....
	5. with the software tools message system (public domain from lbl)
		it also will support smtp as per rfc 822, 821....
	6. it is virtually free for an educational institutional site license.

	Disadvantages:

	1. It is available currently only to educational institutions (but
		some commercial sites HAVE gotten access to it).
	2. it currently only supports telnet, ftp, 3com ftp, and smtp
	3. there is no support (but then i understand the Wollongong doesn't
		support there product either in reality)
	4. it does not yet support nameservers, >255 hosts, and anything other
		than in its fixed host table (however; we are currently fixing
		these problems and hope to have them resolved within 2 months)


	All in all, compared to WIN/VX (which i HAVE used) i feel that it is
infinitely superior (and much cheaper).  While it isn't perfect (yet) you have
the code to fix whatever ails it.  One of our sites has been using it for 3
months with NO MAJOR COMPLAINTS  except when the WIN/VX site that they talk
to screws up.

	I would be happy to answer any further questions or supply details
if people would like...

-ed cetron
center for engineering design
Univ. of Utah

cetron%utah-cbd@utah-cs.arpa


	

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Sat, 6-Sep-86 05:02:54 EDT
From:      mckee@MITRE.ARPA
To:        mod.protocols.tcp-ip
Subject:   Gateway Selection Procedure


Gentlemen:

I solicit advice and document references on how IP should select a
particular Gateway when more than one is available.

Background

My responsibilities include writing communications and network
performance requirements for a large military system called the WWMCCS
Information System (WIS).  The WIS will (initially) consist of about 40
sites.  Each site will have:
  
    - a 10 Mbps Applitek LAN

    - 2 or 3 large host processors

    - 50 to 150 workstations

The workstations and hosts are connected to the LAN through Interface
Units (IUs).  TCP and IP are performed in the IUs.

Each LAN has at least one Gateway IU that connects the LAN to the
DDN-RVN (DDN-Red Virtual Network, Class A Net 21).  All inter-site
communications use net 21.  For increased throughput and availability,
some sites will have 2 or 3 Gateway IUs.  Some Gateways will connect to
the DDN-RVN at 56 Kbps, others at 9.6 Kbps.

Each LAN has a LAN Control Center/Security Monitor (CC/SM).  For
security and access control, procedures have been established such that
the CC/SM is aware of the status of every connection; every TCP active
or passive open/close/abort request is routed through the CC/SM.
Further, by means of periodic interrogation, the CC/SM knows the health
and traffic load of every local IU, including the local Gateways.

Questions

When IP in a host or workstation IU receives a datagram destined for a
remote site, what procedure should be used to select one of the local 
Gateways?

When IP in a Gateway receives a datagram from the LAN, what procedure
should be used to select one of the Gateways at the remote site?

Any advice or references would be appreciated.

H. Craig McKee
'mckee at mitre'
(703)883-5505

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Sun, 7-Sep-86 02:12:37 EDT
From:      Murray.pa@XEROX.COM
To:        mod.protocols.tcp-ip
Subject:   Re: Ethernet between buildings

If you can possibly find the $ for the fibers, that's the way to go. If
you talk to anybody in the fiber business, this is probably the first
application they will mention. 

I suggest a very cautious, respectful approach when dealing with things
as potent as lightning. You may think your buildings are both grounded
but at the currents developed near lightning strikes, all sorts of
unobvious things will happen.

Consider what will happen when your whole net goes down. You may only
have a few machines today, but you know that more be running tomorrow.
People will be using them for term projects and writing their thesis.
Networks are addicting. Remember that it will happen durning the end of
term rush.

We have one (coax) ethernet under the street to another building. 6 or 7
years ago, a lightning bolt hit the hill a bit beyond that building. It
fried the front end transistor in dozen or so transcievers. Each fried
transistor was a short accross the coax. That whole net was down until
they found the last dead transciever. There were lots of people milling
around the halls and grumbling... (At least we could scrounge enough
transcievers on short notice to get everybody back on the air.)

(That was a long time ago. A simple resistor in the right place will
probably provide enough protection. Most transcievers probably include
one now.)

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 1986 05:24-EDT
From:      CERF@A.ISI.EDU
To:        mckee@MITRE.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Gateway Selection Procedure

Mr. McKee -

you should be able to "pick any" of the known available gateways - if you
picked the wrong one, relative to minimum delay routing, that one will
"redirect" you to the right one. However, it is possible the one you picked
is dead. If the subnet you use to reach that gateway tells you about dead
hosts, as the ARPANET does, then you will be able to detect this mistake
and change your tables to select another gateway. 

There is no existing algorithm for selectively routing traffic across
multiple gateways. Dave Mills tried one that resulted in every other
packet landing in the Atlantic Ocean (The "Atlantic Two-Step"). It is
not even clear that such bifurcation oftraffic across a single TCP
logical connection would be a good idea - especially if the two routes
have widely differing delay/loss characteristics - the TCP level
performance monitoring and feedback control might have a lot of trouble
trying to adapt if every other packet, for instance, went a different
way with very different parametric profile.

Vint
-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 1986 05:40-EDT
From:      CERF@A.ISI.EDU
To:        klem@BRL.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA

Wow!

A fast reading of your message, especially the last part characterizing the DCD
X.25, suggest you are in trouble.

The IMP does NOT, so far as I know, examine the IP for an address. The host
or front end doing the IP has to map the internet address into an appropriate
X.25 address (to the destination or to the gateway on the X.25 network).

It is not necessarily a requirement that each TCP connection be mapped into
a distinct X.25 virtual circuit. Some implementations map all TCP connections
into a single X.25 virtual circuit between source and destination or source
and gateway. This could result in poorer throughput as the number of TCP
connections increases and also result in some interference between the varius
communicating processes sharing the common virtual circuit. Since there is
no easy way to tell IP that it is handling a new TCP connection, this is an 
area of performance concern which may have implementation and/or application
specific consequences and require specific remedies.

BBN has developed software which permits 1822 and X.25 interoperability;
however, there are two modes of X.25 interface on the network: standard
and basic. The basic mode is incapable of dealing with the X.25/1822
mapping since it is really just an end/end X.25 pipe - the commercial
interface to X.25 that BBN sells. The Standard mode (DoD standard) will
support 1822/X.25 interfacing. ALL of X.25 is terminated in the IMP
at the interface. At the destination, if the interface is also Standard
X.25 (not BASIC X.25), the full X.25 is RECREATED. If the destination
is 1822, it will see a fabricated 1822 exchange.  In the STANDARD case,
X.25 and 1822 addresses are mapped back and forth.

There was indication at the Monterey meeting that the STANDARD X.25 mode
had not necessarily been installed on both the ARPANET and MILNET -
the DDN NIC would be a good place to query in this regard.

The principle issue is whether the typical commercial implementations
of X.25 are compatible with (interoperate with) the DoD Standard X.25.
They certainly SHOULD interoperate with BASIC X.25. 

The reason there are two X.25 style interfaces is that the BASIC mode was
readily available and permitted hosts with vendor-specific protocols to
use the MILNET for communications, independent of interoperability with
other hosts on the system.

If all hosts used X.25 interfaces, I believe there would be no need for
the Standard X.25 interface with its conversion facility - but this is
not the case.

I'm sure you'll get other comments on the TCP-IP distribution.

Maybe we need an RFC laying all this out...

Vint
-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Sun, 7-Sep-86 17:32:27 EDT
From:      haverty@CCV.BBN.COM
To:        mod.protocols.tcp-ip
Subject:   Re: Gateway Selection Procedure


Vint et al,

A minor clarification.  There is no general algorithm in use
which spreads traffic across multiple gateways.  There is however
a special-purpose table-driven algorithm in the Arpanet/Milnet
mailbridges, which attempts to spread traffic amongst the seven
parallel mailbridges.  It is effective only for hosts which are
physically connected to the Arpanet or Milnet, but not gateways,
because hosts listen (should at least) to redirects but gateways
do not.  Fortunately this covers a lot of the traffic; without
this mechanism, the mailbridge would be a highly reliable
bottleneck (more so than it is now), since only one path would be
"best", with six !! idle backup gateways at any time.
Unfortunately, with more LANs all the time, this interim approach
is clearly limited. 

There is a feature in design stages now for the C/30 family,
which will permit multipath routing to occur -- i.e., between
points A and B several parallel paths might exist, and all might
be in use to carry traffic.  With such a mechanism, for example,
a network with only 9.6 kilobit/sec trunks could achieve a
host-host throughput greater than 9.6 by using the multiple
paths.  This is a very hard problem, to achieve stability and
efficiency and avoid behavior like the Atlantic two-step.

Jack Haverty

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Sun, 7-Sep-86 18:12:56 EDT
From:      jas@BRUBECK.PROTEON.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: re: How to IP & ARP on 802 nets

SNAP is not 'our' protocol, any more than 802.2 is ours. We don't
have any contorl over it. If we had wanted to avoid this mess, we (sigh)
should have been on 802.2. AS I noted, vendors are already using
SNAP.

The reason that the code is 3 bytes of owner, and two of protocol
number, is that they can then use the already-allocated 24-bit
prefixes that define 48-bit address blocks. Hey, 48-bits is absurdly
long, also.

I think that running a datagram network protocol like IP over class 2 802.2
is a non-sequitor, so we don't need to worry about it. I will admit that
I can't see how SNAP would work with class 2 at all. In the ISO world,
class 1 is used with connectionless internet at the network level, and
class 2 with a null network layer.

					john shriver
					proteon
-------

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Sun,  7 Sep 86 18:12:56 EDT
From:      jas@brubeck.proteon.com
To:        Provan@LLL-MFE.ARPA
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: re: How to IP & ARP on 802 nets
SNAP is not 'our' protocol, any more than 802.2 is ours. We don't
have any contorl over it. If we had wanted to avoid this mess, we (sigh)
should have been on 802.2. AS I noted, vendors are already using
SNAP.

The reason that the code is 3 bytes of owner, and two of protocol
number, is that they can then use the already-allocated 24-bit
prefixes that define 48-bit address blocks. Hey, 48-bits is absurdly
long, also.

I think that running a datagram network protocol like IP over class 2 802.2
is a non-sequitor, so we don't need to worry about it. I will admit that
I can't see how SNAP would work with class 2 at all. In the ISO world,
class 1 is used with connectionless internet at the network level, and
class 2 with a null network layer.

					john shriver
					proteon
-------

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8-Sep-86 11:30:43 EDT
From:      JNC@XX.LCS.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Gateway Selection Procedure


	The answer to the first question you ask is contained in two RFC's
in the TCP/IP guide; I don't remember which volume they are in in the
white books, but they are RFC's 814 and 816, "Names, Addresses, Ports and
Routes", and "Fault Isolation and Recovery". I don't want to sound like a
broken record, but I wish people would read the documentation provided
before asking questions. I am aware that those books contain a lot of
material: perhaps the NIC could include a 'Suggested Readings' list in
the next printing which would list RFC's 813-817 as 'Required'?
	The second question is sort of covered by RFC's 904 and 888, which
describe the current Internet model for routing packets among gateways.

	Noel
-------

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8-Sep-86 16:48:00 EDT
From:      MAB@CORNELLC.BITNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   Anybody Have Code for an Echo Host?

At the TCP/IP Vendor's Workshop in Monterey, mention was made of a beast
called an "Echo Host".  As I understand it, this is a tool for shaking out
a host implementation of TCP/IP.  It simply echoes IP datagrams, with
controls for delay, bandwidth, and error rate.

Does anyone have code for an Echo Host?  In particular for an IBM PC?
Also, mention was made at the workshop of the existence of a How-To-
Build-An-Echo-Host RFC.  I can't find it - can someone tell me the number?

My Internet address is:
     mab%cornellc.bitnet@wiscvm.wisc.edu

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Sep 1986 16:48 EDT
From:      Mark Bodenstein  <MAB%CORNELLC.BITNET@WISCVM.WISC.EDU>
To:        <tcp-ip@sri-nic.arpa>
Subject:   Anybody Have Code for an Echo Host?
At the TCP/IP Vendor's Workshop in Monterey, mention was made of a beast
called an "Echo Host".  As I understand it, this is a tool for shaking out
a host implementation of TCP/IP.  It simply echoes IP datagrams, with
controls for delay, bandwidth, and error rate.

Does anyone have code for an Echo Host?  In particular for an IBM PC?
Also, mention was made at the workshop of the existence of a How-To-
Build-An-Echo-Host RFC.  I can't find it - can someone tell me the number?

My Internet address is:
     mab%cornellc.bitnet@wiscvm.wisc.edu
-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8-Sep-86 20:17:38 EDT
From:      MDCG.HRD%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU ("Hank R. "Jim" Dixon")
To:        mod.protocols.tcp-ip
Subject:   X25 implementations

Hello, does anybody happen to know about any exsisting implkementations
for X25 on the VAX under either VMS (preferably) or UNIX?? Thank you.
                   JIM

-------

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8-Sep-86 20:44:04 EDT
From:      lekash@AMES-NASB.ARPA (John Lekashman)
To:        mod.protocols.tcp-ip
Subject:   hyperchannel and IP

Hi there.

two things:
1. I've been doing some work on an NSC hyperchannel device driver.
I started with what was working on 4.2, and with help from Mike
Karels at Berkeley, have got it working on 4.3 unix. Its available
on ames-nasb in /usr/ftp, including 4.3 kernel changes, (to support
raw access) cray research's cxint (yuk!) and hyroute (also yuk!)

2. While getting this working, I found many things about how
it functions in need of repair or improvement.  I am interested
in starting a mailing list of people who use hyperchannels on
IP nets.  I want to see some sort of standard about encapsulation,
routing, and raw access.  We spent a great deal of time wretching
about all sorts of things here, and finally everyone just copied
what cray research had given us, since getting them to change
was the hardest.

If no one else is currently running such a list, I will.  I
have created hy-people, and hy-people-request at ames-nasb.arpa
(orville).
					thank you,

					john

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9-Sep-86 06:55:22 EDT
From:      cel@MITRE-BEDFORD.ARPA
To:        mod.protocols.tcp-ip
Subject:   NETBIOS ISSUE---TCP Handoffs


	At the NETBIOS-TCP/IP Interface Specification Forum held Aug 28 in
Monterey, CA two proposals were discussed.  A major issue revolved around the
capability of some operating systems to support handoff of TCP connections
from one process to another.

	Are there problems in handing a TCP connection from one process to
another for some operating systems?  Which operating systems have difficulty?

	Please mail comments to netbios@mitre-bedford.arpa.


	The problem in the context of the NETBIOS issue is described below.

	Assume two hosts, one contains a client application program and the
other contains a server application program.  the problem is to establish a
session between the programs (message oriented, no loss or duplication).  The
hosts contain NETBIOS agents for their respective application programs to
interpret the various NETBIOS commands.    Also assume that the
server host contains a NETBIOS validation program that verifies if two NETBIOS
named application programs may communicate.  Exchanges may occur between the
client and validation programs via UDP messages as in proposal one or over a
TCP connection as another proposal.  Data passed over a session between
application programs occurs over a TCP connection.

	One proposal (figure A below) calls for passing all session control
information via UDP messages between the NETBIOS client program located in the
source host and the NETBIOS validation program in the destination host.
The NETBIOS Name service has provided the IP address of the server host.
The validation pgm is accessed through a TCP well known port (wkp). If the
session is valid (a server application has posted a NETBIOS listen for c-name)
then the server program does a fully specified TCP passive open using s-port,
c-port and the IP addresses.  The client program then establishes a TCP
connection to the server program using s-port, c-port, and the IP addresses.
No handoff of a TCP connection between the validation program and the server
program is required.

		Figure A: NETBIOS Names Passed via UDP

     CLIENT                                                     SERVER

							Validation pgm does
		UDP(c-name, s-name, c-port)------->     UDP wkp listen to any
	(timeout)
							agent pgm does TCP
		<--------------UDP(s-port)---------     fully spec passive
							open on s-port,c-port
						   (timeout)
		TCP(s-port) SYN ------------------>     TCP conn established
							to NETBIOS agent
		<---------------------SYN---------
		<-------------data---------------->

			     etc.

	Another proposal (figure B below) calls for the client to determine
the server's TCP port (s-port) via the NETBIOS Name service.  Meanwhile the
NETBIOS validation program posted a TCP partially specified passive open (ppo)
open on s-port due to a NETBIOS LISTEN issued by an application program.  The
client program then establishes a TCP connection to the client validation
program and passes session control information (c-name,s-name) over the
connection. If the session is valid between the two NETBIOS named
applications, then the TCP connection is handed off to the  server agent
program.  If the session is rejected then the TCP connection is broken.


		Figure B: NETBIOS Names Passed via TCP Connection

	CLIENT                                          SERVER

							Validation pgm does
							TCP ppo on s-port
		TCP(s-port) SYN----------------->
		<---------------------------SYN--
		------data(c-name, s-name)------>       Validate and handoff
							TCP conn to server
							agent pgm
	    (timeout)
		<----------data(ack, nack)-------
		<----------data----------------->

			    etc.


 Thanks,  ---- Lee LaBarre

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 1986 08:23-EDT
From:      CERF@A.ISI.EDU
To:        MDCG.HRD%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
Cc:        tcp-ip@SRI-NIC.ARPA, jsol%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
Subject:   Re: X25 implementations
Digital has a package called PSI (Version 4.0) which allows VMS to make
use of X.25 networks.

Vint Cerf
-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 1986 08:37-EDT
From:      CERF@A.ISI.EDU
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Formatting Query

I apologize for the broadcast, but I wonder if I am the only recipient of
TCP-IP distribution list messages troubled by receipt of messages containing
naked horizontal tabs (control-I characters)?

It is generally difficult to properly reconstruct the tab settings for
presentation.  If this is not just a local problem, perhaps we could
agree to expand tabs before submitting messages to TCP-IP distribution
to improve matters until someday we have a common document representation
format which can include adivce about tab settings automatically.

I recognize that such a proposal runs the risk of increasing the total
length of messages but perhaps this is a small price to pay for improved
communication.

Is anyone else out there having similar difficulties?

Vint Cerf
-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9-Sep-86 14:40:29 EDT
From:      ahill@CC7.BBN.COM ("Alan R. Hill")
To:        mod.protocols.tcp-ip
Subject:   re: imprecise DDN X.25 specification?

George,
	As Dr. Cerf already pointed out, the concerns you have are valid
and will definitely affect the ability of the CDC interface to communicate
with the DDN Standard Service.  I cannot comment on the relationship 
between DCA Qualification and an ability to communicate effectively using
the DDN but I can offer some information on what the BBN packet switch
does during use of Standard Service.

	Standard Service will process an X.25 call by removing its
X.25 transport envelope and using the contents to generate an 1822L
envelope.  Standard  Service allows only one VC per triplet of
<source address>, <destination address>, and <precedence>.

	Unfortunately, I believe each of your issues will prevent 
communication with the DDN.  I would like to hear suggestions about
areas for improvements in the specification or the DCA Qualification.


Alan

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Sep 86 14:40:29 EDT
From:      "Alan R. Hill" <ahill@cc7.bbn.com>
To:        klem@brl.arpa
Cc:        tcp-ip@sri-nic.arpa
Subject:   re: imprecise DDN X.25 specification?
George,
	As Dr. Cerf already pointed out, the concerns you have are valid
and will definitely affect the ability of the CDC interface to communicate
with the DDN Standard Service.  I cannot comment on the relationship 
between DCA Qualification and an ability to communicate effectively using
the DDN but I can offer some information on what the BBN packet switch
does during use of Standard Service.

	Standard Service will process an X.25 call by removing its
X.25 transport envelope and using the contents to generate an 1822L
envelope.  Standard  Service allows only one VC per triplet of
<source address>, <destination address>, and <precedence>.

	Unfortunately, I believe each of your issues will prevent 
communication with the DDN.  I would like to hear suggestions about
areas for improvements in the specification or the DCA Qualification.


Alan

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9-Sep-86 20:22:26 EDT
From:      mike@BRL.ARPA (Mike Muuss)
To:        mod.protocols.tcp-ip
Subject:   Re:  Formatting Query

I though there was general agreement that tab stops were every 8 characters?

I don't know if this is official NETASCII, but since TOPS-20, UNIX, and VMS
all do it this way, most systems go along.
	-Mike

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9-Sep-86 21:03:57 EDT
From:      jcp@BRL.ARPA (Joe Pistritto, JHU|mike)
To:        mod.protocols.tcp-ip
Subject:   VMS TCP/IP over Ethernet?


	I'm working on upgrading a site that currently runs VMS on
its Vaxen to running 4.3 (at least most of the time), and the issue of
communications has come up.  Presently, there is nothing, so the slate
is clean.  I'm thinking of getting some of the Interlan (MICOM) smart
ethernet controllers, and running their VMS TCP/IP package on one machine,
with 4.3 on the others.  Has anyone else come up against the problem of
needing hardware that is both VMS and UNIX compatable, (so that either
machine can be used for either system), and found a better (more cost
effective) solution?

	The Interlan folks claim to have FTP and TELNET implemented under
VMS, I have also checked out Wollongong, any others out there I've 
missed?  Were not Government or educational, so I don't think the 
Tektronix code is available.

						-JCP-

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10-Sep-86 08:34:24 EDT
From:      MRC@SIMTEL20.ARPA (Mark Crispin)
To:        mod.protocols.tcp-ip
Subject:   Re: Formatting Query

Vint -

     So far as I know Multics is the only operating system in common use
on the Internet which does not use tab stops at every 8th character.  My
experience suggests that it is basically hopeless in a true heterogenous
environment to use tab stops at any other position due to the large number
of terminals which do not offer settable tab stops.

     I admit that "8 tabs" are hopelessly hacker oriented and probably
aren't santioned by any standard, but c'est la vie.  Many of the Internet
protocols are hopelessly hacker oriented.  I'm sure ISO will "improve"
this situation; I have no way of telling if ISO will do anything to improve
it though.

     If you read your mail at A.ISI.EDU (as opposed to having some agent
pick it up and pass it on to your real mailbox), you should know that
A.ISI.EDU is a TOPS-20 system and TOPS-20 uses 8 tabs exclusively.  Tenex
had programmable tabs, but this functionality was deleted in TOPS-20.
Therefore, it is correct that any terminal connected to a TOPS-20 system
should use 8 tabs.  I think the same is true for Unix and VAX/VMS.  If
not I'm sure I'll receive 1000 messages telling me what an idiot I am...

-- Mark --
-------

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10-Sep-86 15:51:05 EDT
From:      AI.CLIVE@MCC.COM (Clive Dawson)
To:        mod.protocols.tcp-ip
Subject:   DELNI Strangeness

Here's a bit of info to add to the general folklore:

We moved to a new building last week, and after putting everything back
together, we found that TELNET connections from our Sun workstations
to our DEC-20 (they're on separate Ethernets, gateway is a Sun) were
suffering from horribly poor throughput.  Echo delays ranged from 1 to 10
seconds, with no load to speak of on any of the systems or the nets.

After being stumped for a couple of days, we finally realized that the only
thing that had changed was that the Sun gateway and the DEC-20 were now
sharing the same DELNI, whereas before they had been on two different
DELNIs.  We made a quick switch and put the Sun onto its own transceiver
two meters away from the DELNI's transceiver.  The results were immediate
and dramatic.  Echoing delays disappeared completely and users were once
again happy.

Now the obvious question:

Does anybody have an explanation?  Is there something fundamentally 
different about intra-DELNI communication that could cause such
enormous performance problems?

Thanks,

Clive
-------

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10-Sep-86 16:38:21 EDT
From:      cel@MITRE-BEDFORD.ARPA
To:        mod.protocols.tcp-ip
Subject:   Postponement of NETBIOS Meeting


	The NETBIOS meeting scheduled for Sept 29 at Stanford has been
postponed.  A new meeting date has yet to be selected.

	The package containing the proposals, slide copies and issue
discussions is still being prepared.  It will be sent to the participants of
the Aug 28 meeting in Monterey, CA.

				Lee LaBarre

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10-Sep-86 20:19:17 EDT
From:      mike@BRL.ARPA (Mike Muuss)
To:        mod.protocols.tcp-ip
Subject:   Re:  VMS TCP/IP over Ethernet?

For VMS, also consider the Excelan board in smart mode, and maybe the
CMC people have a VMS offering too?
	-M

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11-Sep-86 06:57:00 EDT
From:      Walker@RADC-MULTICS.ARPA ("Robert K. Walker 'Bob'")
To:        mod.protocols.tcp-ip
Subject:   Re: Formatting Query


    Date:  9 September 1986 20:22 edt
    From:  Mike Muuss <mike at BRL>
    Subject:  Re: Formatting Query

    I though there was general agreement that tab stops were every 8 characters?

    I don't know if this is official NETASCII, but since TOPS-20, UNIX, and VMS
    all do it this way, most systems go along.
              -Mike

Tab stops every 8 characters may be the convention for DEC equipment,
which was what was mentioned.  However, the Multics convention is every
10 characters.  I have FTP'ed files from DEC machines with the tab codes
present, only to get a very ragged looking format when it is
interpretted by Multics.  This is a nuisance.

-Bob Walker-

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11-Sep-86 11:20:14 EDT
From:      cel@MITRE-BEDFORD.ARPA
To:        mod.protocols.tcp-ip
Subject:   NETBIOS ISSUES -- Datagram service


	At the Aug 28 NETBIOS meeting in Monterey, CA two proposals for
implementing NETBIOS on TCP/IP were discussed.  One of the areas in which
these proposals differ pertained to the NETBIOS datagram service.  The essence
of the differences relative to this area is outlined below.  We would
appreciate your comments about the relative merits and implementation
feasibility/difficulty of the alternative proposals to accomplish datagram
service.  Please send your comments to:

		netbios@mitre-bedford.arpa


      (NOTE: In both proposals IP datagrams are not broadcast out on the
	     internet, i.e. WAN.)

	First Proposal

	a) Use NETBIOS Name service to discover target UDP port and IP address
	   Since a name cache is assumed to be at each node, only infrequently
	   would name queries result in traffic on the channel.

	b) Datagrams sent to a unique name are sent as directed UDP datagrams
	   with control info and data contained within.

	c) Datagrams sent to a group name or broadcast use IP subnet broadcast


	Second Proposal

	a) All NETBIOS datagrams would be IP subnet broadcast UDP datagrams.
	   No name lookup is required.

	b) UDP datagrams would contain control info and data


	ISSUES

	1. Is the first proposal's assumption of a name cache good? (note:
	   IBM's PC Network uses a cache at each node)

	   NOTE: If a name cache is not used then each NETBIOS datagram would
		 result in a broadcast name query, one or more responses and
		 the directed UDP containing the NETBIOS datagram.  All hosts
		 would have to process the name query.

	2. Proposal two would require all hosts on the subnet to process the
	   IP datagrams - even those not using NETBIOS.  The assumption here
	   is that the NETBIOS datagram service is infrequently used and thus
	   hosts that are not the intended recipient would not be overly
	   burdened.

	   Is infrequent use of directed NETBIOS datagrams a good assumption?

	   Are slow listeners going to miss datagrams?


		       Thanks ---  Lee LaBarre

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11-Sep-86 12:09:00 EDT
From:      Ata@RADC-MULTICS.ARPA ("John G. Ata")
To:        mod.protocols.tcp-ip
Subject:   Re: Formatting Query


          I think the point is being missed here with regard to tab
stops.  If everyone on the network interpreted tabs the same way, this
transaction would never have been started.  Since there is variation on
tab interpretation, it would seem that if the SMTP mailers expanded the
tabs to the appropiate number of spaces, then compatability would be
assured.  The only negative effect of this might be to people who FTP
files via mail, and who might not get exactly the same file on the other
side.  However, they might wish to to use FTP instead...

                    John G. Ata

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11-Sep-86 14:37:16 EDT
From:      jordan@UCBARPA.BERKELEY.EDU (Jordan Hayes)
To:        mod.protocols.tcp-ip
Subject:   Re: Formatting Query


        From: "John G. Ata" <Ata@RADC-MULTICS.ARPA>

        Since there is variation on tab interpretation, it would seem
        that if the SMTP mailers expanded the tabs to the appropiate
        number of spaces, then compatability would be assured.

Wow, did this come out of left field or am I really missing
something? I don't really think you want to do this ...

/jordan

ps: maybe a better way of looking at tabs is like those stupid vt100
    escape sequences that lock up my terminal, but give an vt100'er
    double width characters ...

pss: all you UNIX'ers out there using Mail can do a ~|expand just before
     hitting ^D to end your message ... I did this for this message --
     how does it look to you Multics'ers?

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11-Sep-86 15:20:00 EDT
From:      JSLove@MIT-MULTICS.ARPA ("J. Spencer Love")
To:        mod.protocols.tcp-ip
Subject:   Multics TABs

Are, as several have noted, every 10 columns.

It is the position of the Multics mailer developers that TAB characters
should never be sent over the network, since there is no "standard"
width.  Thus, all outgoing mail is detabbified, at some slight cost in
network throughput.

Mail coming in is also detabbified, which affects only non-Multics mail,
since there are no tabs in mail leaving Multics.  This detabbification
*ought* to assume tabs every 8 columns, since this is the de-facto
standard.  That it doesn't is a bug (to be fair, if the mailer developer
had agreed with me, this problem would never have arisen).

None of this helps FTP users, since FTP does no TAB transformations.
There is, however, a Multics command, "canonicalize", which can insert
and remove TAB characters assuming any TAB width, which helps out in
some situations.

There are other TAB widths in use.  I think that Magic 6 uses (used?)  a
width of 5.  The width of 8 is pretty consistent across DEC equipment,
but there are other manufacturers out there.  There didn't seem to be
any consistent use of TABs at all in IBM program products, last I
checked.

Anyone out there using non-DEC and non-Honeywell gear?

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11-Sep-86 15:35:08 EDT
From:      ROODE%BIONET@SUMEX-AIM.STANFORD.EDU (David Roode)
To:        mod.protocols.tcp-ip
Subject:   DELNI characteristics

We have noticed that DELNI's have some non-intuitive limitations
on cable length.  Could this perhaps have some bearing on your
problem?  Unlike other multiport transceivers, the rule
for DELNI's is that the transceiver cable length limitation
of 40m (vs. 50m for other devices) applies to the sum of
lengths of the drop to the DELNI and the drop from the DELNI
to the host system.

It is also against the rules to plug one DELNI into another one
unless that DELNI is NOT connected to an Ether.
-------

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11-Sep-86 19:58:36 EDT
From:      leong@andrew.cmu.edu (John Leong)
To:        mod.protocols.tcp-ip
Subject:   Re: DELNI Strangeness


Clive,

I don't really know what specifically is your problem with the DELNI.
However, one thing you may care to check is this :

The DELNI (and for that matter, almost all multiport tranceiver in the
market) does not handle "heart beat" correctly. For all practical purposes,
heart beat is a kind of acknowledgment from the tranceiver to the station.
Within a very short period of time after the tranceiver finished sending the
packet into the coax cable, it issue a heart beat signal on the collision
pairs of the tranceiver cable - essentially saying "all's well". In the case
of the DELNI, this signal is (mistakenly) fanned out to ALL attached
stations. The station doing the transmit will know it is a heart beat.
However, the other attached stations will treat it as an asynchonous
collision notification. Most station will ignore it but I don't know about
the DEC-20.

However, definitely, do not attached a repeater to a DELNI. Repeater will not
toss away heart beat. It will act on it and generate collision reinforcement
(jam) on the other side!!! The result is excessive collisions. Very bad news
to the overall band width availability.

John Leong

.

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Sep 86 11:19:57 CDT
From:      Phil Howard  <PHIL%UIUCVMD.BITNET@WISCVM.WISC.EDU>
To:        TCP/IP List <TCP-IP@SRI-NIC.ARPA>
Subject:   Tabs every 8 positions
Gee, even IBM has acknowledged that tabs belong on every 8 positions.
In VM/SP/CMS's XEDIT is the EXPAND subcommand that expands out the tabs
to proper positions.  There is also COMPRESS with puts tabs in, and in
the proper place.  I use these commands to handle files received from
non-IBM systems with tabs.  Everything has worked out fine.  Now I just
need a way to get square brackets on my IBM 3178 keyboard.
-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12-Sep-86 11:32:05 EDT
From:      jtw@mitre-bedford.ARPA (Welch)
To:        mod.protocols.tcp-ip
Subject:   RFC 912, Auth Service


I am interested in finding out whether anyone has either implemented or has
comments on the authentication protocol outlined in RFC 912, "Authentication
Service".

Any pointers or info would be appreciated.

	      Jim Welch
	      jtw@mitre-bedford

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Sep 86 11:48:14 EDT
From:      hurf@tcgould.tn.cornell.edu (Hurf Sheldon)
To:        mod.protocols.tcp-ip,,arpa.protocols.tcp-ip
Subject:   Ultrix1.2 to HPUX problem
	We recently connected a VaxstationII & an HP9000/300 via a delni
 & after getting the uvax setup correctly we then used the network setup
 program on the HP to set it up. What we get now is complete access from the
 HP to the uvax but from the uvax to the HP we get "connection refused"
 under telnet & just "time outs" on ftp & rlogin. We have set up the host tables
 on the uvax for some more HP's not yet connected & when we try to go to them
 we get a "host unreachable" so we believe the HP is recognizing it's address
 correctly but won't answer. 
	
 	We have Ultrix1.2 on the uvax & HPUX on the HP. The uvax is set
 "broadcast -trailers netmask 0xffffff00" - must be set this way to conform
 to local cornell net standards.

 Any & all suggestions appreciated.


     Hurf Sheldon			Arpa.css: Hurf@ionvax.tn.cornell.edu

     Lab of Plasma Studies	
     369 Upson Hall			phone: 607 255 7267
     Cornell University
     Ithaca, N.Y. 14853

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Sep 86 11:54:36 EDT
From:      hurf@tcgould.tn.cornell.edu (Hurf Sheldon)
To:        arpa.tcp-ip
Subject:   Ultrix to HPUX problems
	We recently connected a VaxstationII & an HP9000/300 via a delni
 & after getting the uvax setup correctly we then used the network setup
 program on the HP to set it up. What we get now is complete access from the
 HP to the uvax but from the uvax to the HP we get "connection refused"
 under telnet & just "time outs" on ftp & rlogin. We have set up the host 
 tables on the uvax for some more HP's not yet connected & when we try to
 go to them we get a "host unreachable" so we believe the HP is recognizing 
it's address correctly but won't answer. 
	
 	We have Ultrix1.2 on the uvax & HPUX on the HP. The uvax is set
 "broadcast -trailers netmask 0xffffff00" - must be set this way to conform
 to local cornell net standards.

 Any & all suggestions appreciated.


     Hurf Sheldon			Arpa.css: Hurf@ionvax.tn.cornell.edu

     Lab of Plasma Studies	
     369 Upson Hall			phone: 607 255 7267
     Cornell University
     Ithaca, N.Y. 14853

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12-Sep-86 11:58:00 EDT
From:      Chartoff@DDN2.ARPA
To:        mod.protocols.tcp-ip
Subject:   DECNET


I am looking for interface products that would allow DECNET
communication across the Arpanet/Milnet or a public data network (PDN).

Has anyone had experience with such products and want to give advice?

Thanks

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 86 11:58 EDT
From:      Chartoff @ DDN2
To:        tcp-ip @ sri-nic.arpa
Cc:        Chartoff @ DDN2
Subject:   DECNET

I am looking for interface products that would allow DECNET
communication across the Arpanet/Milnet or a public data network (PDN).

Has anyone had experience with such products and want to give advice?

Thanks

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12-Sep-86 12:19:57 EDT
From:      PHIL@UIUCVMD.BITNET (Phil Howard)
To:        mod.protocols.tcp-ip
Subject:   Tabs every 8 positions

Gee, even IBM has acknowledged that tabs belong on every 8 positions.
In VM/SP/CMS's XEDIT is the EXPAND subcommand that expands out the tabs
to proper positions.  There is also COMPRESS with puts tabs in, and in
the proper place.  I use these commands to handle files received from
non-IBM systems with tabs.  Everything has worked out fine.  Now I just
need a way to get square brackets on my IBM 3178 keyboard.

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12-Sep-86 12:48:21 EDT
From:      cetron@UTAH-CS.ARPA (Edward J Cetron)
To:        mod.protocols.tcp-ip
Subject:   Re: DELNI characteristics


	David Roode writes:

>It is also against the rules to plug one DELNI into another one
>unless that DELNI is NOT connected to an Ether[net].

WRONG!!!!!!!!!!!!!!!!  Nowhere does it say that one DELNI cannot be
cascaded to another ethernet connected DELNI! And I've check every manual,
tech and sales, Digital has produced....

	The above is a very common misconception...the real configuration
rule has to do with the fact the propagation delays build through the
ethernet having to do with things like cable lengths, numbers of repeaters
etc....

	The one rule that is most apropos is the 'no more than two repeaters
between any two nodes....'  This is (among other things) to prevent the
propagation delay between any two nodes to be less than the max... For very
conservative purposes, the DELNI acts with a propagation delay of 1 repeater
and this sort of implies the above misconception.

	In reality: 
	1. A DELNI actually appears to introduce the delay of about .6-.7 that
of a repeater.
	2. I have seen systems with 2, 3, and 4 cascaded DELNI's that work and
DO  maintain in-spec propagation delays.
	3. It has been pointed out that with the appropriate configuration, one
could even make 4 repeaters in a row work.
	4. The configuration rules (like the rs232 max line length rules) are
very conservative to allow 100% probability of a network working when they are
strictly adhered to.  This means that quite often, for networks not in a very
critical area (i.e. hospital ICU's controlling patient therapy) they are only
to be considered guidelines BY PEOPLE WHO UNDERSTAND WHY THE RULES ARE THERE.
Rules are there for a reason, but should be tested and verified before blindly
obeying them without knowing why

-ed cetron
Center for Engineering Design
Univ of Utah
cetron%utah-cbd@utah-cs.arpa

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12-Sep-86 12:49:01 EDT
From:      root@BU-CS.BU.EDU (Ra)
To:        mod.protocols.tcp-ip
Subject:   Re: Formatting Query

To add my 2c:

1. I am not sure about the definition of "commonly used" but
IBM Mainframes (EBCDIC) generally do not interpret tabs the
way full-duplex systems use them (not that you can't simulate
them, but it tends to be more variable in interpretation, if
at all, software application dependant.)

2. Sending files through mail via heterogenous systems is fraught
with peril although it usually works well enough if it's just text
meant to be used as text (eg. a fortran program with embedded tabs
may not compile at all when sent to an IBM system, I don't remember
for sure, but I wouldn't be in the slightest bit shocked, and fixing
it wouldn't take that much sophistication on the part of the user.)

A solution is the UUENCODE/UUDECODE program distributed with UNIX
(there are public domain versions) which encodes files in a very
conservative way (more or less 026 character subset, 40 chars/line.)
For example, I have a version of it running on our IBM mainframe and
it seems to work, particularly for cases as above (yes, I expand
tabs to every eight, perhaps that should be an option, but at least
it's all at the user level rather than a decision made by the SMTP daemon.)

Obviously with binary files there's not much you can do, but you
could pass one THROUGH an incompatible system with little risk of
problems using an encoding, hey, caveat usor.)

In re SMTP, I would vote conservative, change nothing unless you
have a good reason to (eg. ASCII->EBCDIC, there is an EBCDIC tab
character.) It should be easy enough to provide software to do
minor conversions once the the file has arrived (if it is intact,
expanding tabs for example discards information which seems to
violate some basic principle of design.)

	-Barry Shein, Boston University

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12-Sep-86 16:49:00 EDT
From:      Kevin_Crowston@XV.MIT.EDU
To:        mod.protocols.tcp-ip
Subject:   Re: Formatting Query

Just to add to the confusion...

My system (a Xerox Star) displays mail in a proportionally spaced font,
making all diagrams hard to read without changing the font.
I'm not sure if this is a bug or a feature, however.

In general, I think that having the mailer expand the tabs would be a bad
idea.  There might be reasons for wanting the tabs in the message and it shouldn't
be impossible to do this.  The user mail agent might do that sort of processing
by default, however.  For example, if I try to send a message that includes
font changes, etc. the mailer asks if I really want to send formatted text,
and strips the formatting if I don't.

Kevin Crowston
MIT Sloan School of Management

kevin@xv.mit.edu

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 1986 18:37-PDT
From:      STJOHNS@SRI-NIC.ARPA
To:        jtw@MITRE-BEDFORD.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, sra@MITRE-BEDFORD.ARPA tgw@MITRE-BEDFORD.ARPA
Subject:   Re: RFC 912, Auth Service
Speaking as the author of rfc912 (actually, see rfc931 which is a
revised version of 912) I know of no one who currently implements
it.   I  did  a  test  implementation of it for Multics and did a
little playing with implementing the services  end  of  it  (i.e.
TELNET  without  having to explicitly login), but that version is
lost to obscurity.  Mike
-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Sat, 13-Sep-86 16:56:42 EDT
From:      PALLAS@SUSHI.STANFORD.EDU (Joseph I. Pallas)
To:        mod.protocols.tcp-ip
Subject:   Re: Formatting Query

RFC821 says:
            The mail data may contain any of the 128 ASCII character
            codes.

This clearly makes it illegal for SMTP mailers to expand tabs.  On the
other hand, RFC822 says:

        Writers of  mail-sending  (i.e.,  header-generating)  programs
        should realize that there is no network-wide definition of the
        effect of ASCII HT (horizontal-tab) characters on the  appear-
        ance  of  text  at another network host; therefore, the use of
        tabs in message headers, though permitted, is discouraged.

This clearly suggests that mail-agents expand tabs before submitting
them to mailers.

Meanwhile, if you use tabs in formatting such that the width of a tab
stop affects the content of your message (e.g., in drawing pictures),
other people will get what you deserve.

joe
-------

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Sun, 14-Sep-86 12:21:56 EDT
From:      hedrick@topaz.rutgers.edu (Charles Hedrick)
To:        mod.protocols.tcp-ip
Subject:   Re: RFC 912, Auth Service

We implemented RFC 912 on our DEC-20's.  Our DEC-20 FTP supports
the equivalent of Unix's .rhosts file, and uses auth service
to verify that the guy at the other end is really who he claims
to be.  I regard this is slightly more secure than the mechanism
used by rcp.

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Sep 86 08:05:48 MDT
From:      ncc!lyndon%ALBERTA%UQV-MTS%UMich-MTS.Mailnet@MIT-MULTICS.ARPA
To:        tcp-ip@SRI-NIC.ARPA,    sri-nic.arpa!tcp-ip@ALBERTA
From: lyndon@ncc.UUCP (Lyndon Nerenberg)
Newsgroups: net.video,mod.protocols.tcp-ip
Subject: Re: Ethernet between buildings
Message-ID: <722@ncc.UUCP>
Date: Sat, 13-Sep-86 19:32:57 MDT
References: <611.rbbb.titan@Rice>
Organization: Nexus Computing Corp.,  Edmonton, AB
Lines: 35
Summary: Not a wives tale!

I am cross-posting as this sort of relates to the discussion in
mod.protocols.tcp-ip about grounding ethernet cables...

In article <611.rbbb.titan@Rice>, rbbb@rice.edu (David Chase) writes:
>    ...     A sort of old wives tale of lightning protection says that you
> should put a tight loop in a wire near a good ground; the lightning sees
> that as a great big inductor, and hops over to the good ground.
>
> David

The "signal" introduced into a cable by a lightning strike consists of
extremely high frequency radiation. It does not take much inductance to
throw up a "brick wall" to it. Many television stations run their feeds
through a single loop at the base of the tower, then to the transmitter
shack. The RF from a lightning strike will (hopefully :-) take the easier
path from the feed line, through the base of the tower, to ground.

I handled the transmitter plant installation and setup for a local FM BCST
station a couple of years back. The antenna was located on top of a
building at the University. We were unable to properly ground the tower,
so we threw up a loop inside the roof house for the elevators ( *lots*
of metal in there :-)

I know a number of amateur radio op's in town who do the same thing - 2
turns of the feedline at the base (approx. 3 feet in diameter) before
entering the house. I can't say that any of them have been hit, so I won't
guarantee results. Then again, I have watched local TV broadcast towers take
direct hits without going off the air.

I'm sure a posting to net.ham-radio would provide some further information
on practical experiences of dealing with lightning hits.
--

Lyndon Nerenberg (VE6BBM)                 {ihnp4,ubc-vision}!alberta!ncc!lyndon
Systems Group - A Div. of Nexus Computing Corp.                 Envoy_100: Unix

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15-Sep-86 08:37:18 EDT
From:      mckenzie@j.bbn.com (Alex McKenzie)
To:        mod.protocols.tcp-ip
Subject:   Ethernet Multiplexors

We have had various troubles attaching hosts to our BBN Ethernet using DELNIs.
We haven't actually tried too hard to diagnose them all - simply noted that
there are hosts which don't work when connected to a DELNI.  We assume that DEC
has probably "improved" or ignored some part of the host to transceiver
protocol.  We are now using large quantities of an Ethernet multiplexor made by
TCL, Inc., 41829 Albrae St., Fremont, CA 94538 (415/657-3800).  You buy a
chassis with 9 card slots.  You buy a "downstream" card and 1 to 8 "upstream"
cards.  Each upstream card can be either V1 or 802.3; I think this is also true
of the downstream card but I'm not so sure.  As I recall, a box with a
downstream card costs about $400 and each upstream card costs about $100.  We
have had no troubles with these multiplexors, have successfully cascaded them,
and I know of no hosts that can't use them.

Regards,
Alex McKenzie

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Sep 86 8:37:18 EDT
From:      Alex McKenzie <mckenzie@j.bbn.com>
To:        tcp-ip@sri-nic.arpa
Subject:   Ethernet Multiplexors
We have had various troubles attaching hosts to our BBN Ethernet using DELNIs.
We haven't actually tried too hard to diagnose them all - simply noted that
there are hosts which don't work when connected to a DELNI.  We assume that DEC
has probably "improved" or ignored some part of the host to transceiver
protocol.  We are now using large quantities of an Ethernet multiplexor made by
TCL, Inc., 41829 Albrae St., Fremont, CA 94538 (415/657-3800).  You buy a
chassis with 9 card slots.  You buy a "downstream" card and 1 to 8 "upstream"
cards.  Each upstream card can be either V1 or 802.3; I think this is also true
of the downstream card but I'm not so sure.  As I recall, a box with a
downstream card costs about $400 and each upstream card costs about $100.  We
have had no troubles with these multiplexors, have successfully cascaded them,
and I know of no hosts that can't use them.

Regards,
Alex McKenzie

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15-Sep-86 10:05:48 EDT
From:      lyndon%ALBERTA%UQV-MTS%UMich-MTS.MAILNET@ncc.UUCP
To:        mod.protocols.tcp-ip
Subject:   (none)

From: lyndon@ncc.UUCP (Lyndon Nerenberg)
Newsgroups: net.video,mod.protocols.tcp-ip
Subject: Re: Ethernet between buildings
Message-ID: <722@ncc.UUCP>
Date: Sat, 13-Sep-86 19:32:57 MDT
References: <611.rbbb.titan@Rice>
Organization: Nexus Computing Corp.,  Edmonton, AB
Lines: 35
Summary: Not a wives tale!

I am cross-posting as this sort of relates to the discussion in
mod.protocols.tcp-ip about grounding ethernet cables...

In article <611.rbbb.titan@Rice>, rbbb@rice.edu (David Chase) writes:
>    ...     A sort of old wives tale of lightning protection says that you
> should put a tight loop in a wire near a good ground; the lightning sees
> that as a great big inductor, and hops over to the good ground.
>
> David

The "signal" introduced into a cable by a lightning strike consists of
extremely high frequency radiation. It does not take much inductance to
throw up a "brick wall" to it. Many television stations run their feeds
through a single loop at the base of the tower, then to the transmitter
shack. The RF from a lightning strike will (hopefully :-) take the easier
path from the feed line, through the base of the tower, to ground.

I handled the transmitter plant installation and setup for a local FM BCST
station a couple of years back. The antenna was located on top of a
building at the University. We were unable to properly ground the tower,
so we threw up a loop inside the roof house for the elevators ( *lots*
of metal in there :-)

I know a number of amateur radio op's in town who do the same thing - 2
turns of the feedline at the base (approx. 3 feet in diameter) before
entering the house. I can't say that any of them have been hit, so I won't
guarantee results. Then again, I have watched local TV broadcast towers take
direct hits without going off the air.

I'm sure a posting to net.ham-radio would provide some further information
on practical experiences of dealing with lightning hits.
--

Lyndon Nerenberg (VE6BBM)                 {ihnp4,ubc-vision}!alberta!ncc!lyndon
Systems Group - A Div. of Nexus Computing Corp.                 Envoy_100: Unix

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15-Sep-86 17:19:27 EDT
From:      mckee@MITRE.ARPA
To:        mod.protocols.tcp-ip
Subject:   TCP/IP Conformance Testing


The following article was published in NETWORK WORLD, by Paul
Korzeniowski, 1 Sept. 86, pg 2.

Monterey, Calif. - Corporation for Open Systems (COS) supporters beware.
Ensuring that devices on a multivendor network really can work together
has proven to be a task too complex even for Uncle Sam.
    Last week at the first Transmission Control Protocol/Internet
Protocol (TCP/IP) Vendor Workshop ("TCP/IP future at stake," Network
World, Aug. 25), the U.S. Defense Communications Agency announced it is
washing its hands of TCP/IP conformance testing.
    The agency oversees transmission facilities that link government
agencies, universities, and corporations into one giant network of
networks.  The umbrella network grew out of the Advanced Research
Projects Agency Network (Arpanet), designed in the late 1960s as the
world's first packet-switching net.
    The original network has expanded so that today it supports more
than 30,000 computer systems ranging in size from Cray Research, Inc.'s
supercomputers to Apple Computer, Inc.'s Macintoshes.
    For the last few years, DCA and a number of other government
agencies have been developing test suites and creating a center for
TCP/IP conformance.  The work was similar to that undertaken by COS,
which will handle Open Systems Interconnect (OSI) conformance testing
and the development to test suites.  At the workshop, two government
officials told attendees that plans for the center had been dropped.
    The DCA has developed and continues to design conformance test
criteria, but they are not robust enough to ensure that all TCP/IP
products can interoperate.  "There have been instances where vendors
have spent a lot of time and money trying to ensure their products would
perform on the government network," said Daniel Lynch, president of
Advanced Computing Environments in Cupertino, Calif.  "When their
product was linked to another company's product, they couldn't
communicate."
    Government officials declined to discuss the decision.  But
conference attendees speculated the government found the task of
supplying comprehensive conformance tests nearly an impossible one.
    One problem testers faced is that the only way to test a product
properly is to attach it to the target network, a procedure that the
DCA would not condone.  Also, running a testing center requires a great
deal of money and engineering talent.  Lynch said only a handful of
engineers are qualified to develop and run conformance tests.
    The DCA decision leaves TCP/IP vendors with a number of unappealing
options.  They could form a COS-like organization.  But the consensus
seemed to be that fewer rather than more of such standards organizations
are needed.
    Individual companies could develop their own testing procedures.
But the resources required for such self-testing could limit the number
of vendors able to bring TCP/IP products to market.  Attendees formed a
task force to explore how vendors should proceed.

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15-Sep-86 17:23:12 EDT
From:      cetron@UTAH-CS.ARPA (Edward J Cetron)
To:        mod.protocols.tcp-ip
Subject:   Ultrix 1.2 and unacceptable tcp packets

After hacking with the Tek tcp/ip package to add keep-alive (or probe-alive
as the case may be) support, I found the following behaviour from two Ultrix
sites:

	line sits idle for x length of time (so snd.nxt = snd.una = Ultrix
		rcv.nxt...)
	Tek tcp/ip sends a packet designed to be unacceptable in order to force
		a response (as documented in the mil-std and rfc for tcp). This
		packet has   seg.seq = snd.nxt-1   and   seg.ack = rcv.nxt-1
		which is obviously unacceptable and should force and ack with
		the proper counters.

	The Ultrix site receives the packet, and promptly drops it off of the
		face of the earth (though apparently reading the code it does
		use it to update the window...)

Am I missing something or is this indeed non-compliant?  All of the 4.2bsd and
4.3 bsd sites handle this fine...  I know what is different between the 4.3bsd
and the Ultrix code but before I fix it myself, I want to be sure I haven't 
overlooked something and/or that other Ultrix sites have noticed this same 
problem....

		thanx

			ed

cetron%utah-cbd@utah-cs.arpa

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15-Sep-86 18:49:31 EDT
From:      leong@ANDREW.CMU.EDU (John Leong)
To:        mod.protocols.tcp-ip
Subject:   Re: DELNI characteristics


On the subject of cascading DELNI, one has to be careful about one quirk. 

The Intel 82586 chip has, by default, a check that is not really in
conformance of the Ethernet spec. It measures the time between transmit and
receiving the signal back from the transceiver and signals whether the round
trip time equates roughly to 50 meter of drop cable (nothing to do with the
Ethernet slot time of 51.2 micro seconds or roughly 2.5Km). This test is
quite bogus but some earlier version of DECNET software actually check for
that return code and declares the world is sick accordingly. We have ran into
that problem earlier on when we cascaded DELNI's since they introduced
roughly 10 meter of cable worth of delay and we ran over the 50 meters.

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16-Sep-86 05:36:52 EDT
From:      ROODE%BIONET@SUMEX-AIM.STANFORD.EDU (David Roode)
To:        mod.protocols.tcp-ip
Subject:   Re: DELNI characteristics

Reference on DELNI limitation to non-cascaded mode when connected
to an Ether cable:


EK-ETHV1-IN-002 Ethernet Installation Guide, Digital Equipment Corporation,
1984, Appendix E, p. E1:

"If DELNI interconnects are cascaded, the top DELNI interconnect
cannot connect to an Ethernet coaxial cable.  A maximum of two layers
of DELNI interconnects are permitted, with the second layer of
DELNI interconnects operating in the global mode."
-------

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16-Sep-86 08:57:16 EDT
From:      swb@DEVVAX.TN.CORNELL.EDU (Scott Brim)
To:        mod.protocols.tcp-ip
Subject:   DELNI characteristics


   Date: Mon, 15 Sep 86 18:49:31 edt
   From: leong@andrew.cmu.edu (John Leong)

   .....
   The Intel 82586 chip has, by default, a check that is not really in
   conformance of the Ethernet spec. It measures the time between transmit and
   receiving the signal back from the transceiver and signals whether the round
   trip time equates roughly to 50 meter of drop cable (nothing to do with the
   Ethernet slot time of 51.2 micro seconds or roughly 2.5Km). This test is
   quite bogus ....

You can tell the chip to disable that feature.  I think it's *on* at
power-up.  Gould used to use the round-trip-to-transceiver check; we
asked them to disable it and I believe it's now off for all new Gould
ethernet boards.
								Scott

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16-Sep-86 10:56:00 EDT
From:      DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer)
To:        mod.protocols.tcp-ip
Subject:   Re: Formatting Query

Tabs should be expanded at the source; not by any heuristic in some
program that has no chance of guessing right.  This is preferably the
user's mail composition program, perhaps by a user profile switch, but
it should not be done by the SMTP user side, or the SMTP sending side,
or any other mail delivery program (SMTP isn't the only one that exists
(surprise!!)).  If the user's composition program doesn't have this
feature, then the user should do the conversion if tabs are significant.

You simply cannot send data from one place to the other unless you
/know/ that both sides agree on how to interpret the characters.  I
believe the /only/ set of characters we all agree on are the 95 ascii
characters space through tilde, plus NVT newline.  I would have
italicized /know/ but only other Lisp Machines would be able to see it
without garbage characters...

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16-Sep-86 11:34:00 EDT
From:      Ata@RADC-MULTICS.ARPA ("John G. Ata")
To:        mod.protocols.tcp-ip
Subject:   Re: Formatting Query


Yes, you are correct...when I said SMTP mailer, I meant the mail
composition program that submits mail to the SMTP mailer.  Sorry for the
confusion.  I strongly believe that mail composition programs, should
for the most part, expand tabs to spaces unless overridden by another
command or control argument.  This is because, in the vast majority of
cases, tabs are used to merely position the next character in a
particular column, so that tab expanding is then the right thing to do
given that there isn't a standard definition of tabstops over the
network.  Of course, for those cases where tabs mean something else, the
user can override this, perhaps with a command/control argument.  The
bottom line is that, in most cases, tabs will be vastly reduced in SMTP
message text.
          As a matter of record, the standard Multics mail system does
not allow tabs at all whether local or network.  Therefore, the mail
program will expand tabs BEFORE submitting to the SMTP mailer, just like
it will expand before submission into another local mailbox.  Given that
tab characters are not allowed in messages, the server SMTP does also
expand tabs to maintain compatability with the rest of the mail system.

                    John G. Ata

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16-Sep-86 12:18:40 EDT
From:      alexp@xios.XIOS.CA (Alex Pepple)
To:        mod.protocols.tcp-ip
Subject:   X.25 Board Inquiry

*** BUGS SPRAY ***

I'm looking for X.25 boards (Full X.25) for Multibus and VMEbus machines
to interface to tcp-ip and other protocols. Would anyone have a list of
companies offering QUALITY products of that nature?
Please reply directly to me. Sufficient Interest = Net Summary.

I'm waiting in anticipation for E-mail bits of your brainwaves! -:)

-- Alex
 
...The bitterness of POOR QUALITY is remembered long after the
     sweetness of LOW PRICE is forgotten.  

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16-Sep-86 17:10:37 EDT
From:      louie@TRANTOR.UMD.EDU (Louis A. Mamakos)
To:        mod.protocols.tcp-ip
Subject:   Ultrix 1.2 and unacceptable tcp packets

I've noticed other TCP problems with Ultrix 1.2's TCP.  After we installed
ULTRIX on a MicroVAX system, we don't seem to be able to send mail to our
Sperry 1100 system anymore.  The connection just hangs after a bit.  This
concerned me greatly, being one of the authors of the TCP/IP software on
the Sperry host.  None of our other systems had any problems, (2.9BSD UNIX,
4.2 BSD UNIX, Wollongong VMS, FUZZBALL, *Ultrix 1.1*).  Examination of
trace data on the Sperry indicates that it's just waiting for more data
on the SMTP connection after sending a window update.

(Flame on)
Our solution?  Very simple.  Trash Ultrix and run 4.3 BSD.  Not only has
DEC managed not to fix broken code, but they've even broken working code!

I'll just bet DECNET works though.
(Flame off)

Louis A. Mamakos  WA3YMH    Internet: louie@TRANTOR.UMD.EDU
University of Maryland, Computer Science Center - Systems Programming

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19-Sep-86 09:32:26 EDT
From:      mrose@NRTC-GREMLIN.ARPA (Marshall Rose)
To:        mod.protocols.tcp-ip
Subject:   A new discussion group


    I am pleased to announce the charter of a new discussion group.


                         ISODE@NRTC.NORTHROP.COM

    ISODE is a discussion group which focuses on the ISO Development
    Environment, an openly available implementation of some of the
    higher-level protocols adopted by international organizations (ISO,
    CCITT, ECMA).  These implementations are hosted on top of TCP/IP
    using the method discussed in RFC983.  Appropriate topics are:  

        - questions about how to use ISODE (and announcements of ports to
          other target environments)

        - discussion of ISODE as a part of a TCP/IP to ISO migration strategy

        - exchange of ideas regarding ISO-based applications running in
          a native TCP/IP environment

	- debate regarding where ISODE should go next

    This list naturally has some overlap with the TCP-IP list, the ISO
    list, and so on.  Contributors are urged to use the appropriate list
    based on their topic of discussion.  If there is sufficient demand,
    new sublists may be formed.  

    All requests to be added to or deleted from this list, along with
    problems, questions and suggestions, should be sent to
    ISODE-Request@NRTC.NORTHROP.COM.

    Coordinator: Marshall T. Rose (MTR) <Bug-ISODE@NRTC.NORTHROP.COM>

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19-Sep-86 19:09:33 EDT
From:      braden@VENERA.ISI.EDU (Bob Braden)
To:        mod.protocols.tcp-ip
Subject:   Internet Multicasting for NETBIOS


I would like to comment on the use of Internet multicasting for the
implementation of NETBIOS over the DoD protocol suite.

Both of the proposed protocols for implementing NETBIOS quite properly
restrict the use of NETBIOS broadcast packets to the same local network.
This restriction is necessary because the Internet architecure has not
provided a reasonable Internet-wide broadcast/multicast mechanism.

However,  I believe that this can be only a temporary restriction. 
There is a clear need to extend the Internet architecture to provide a
multicasting mechanism, and in fact the NETBIOS application is an
excellent example of the requirement for "distributed binding" which 
multicasting can provide. 

There is active work on the development and experimental deployment of a
Internet multicasting facility, as described in RFC 966 and RFC988.
Since (as we proudly proclaim) our work is characterized by trying out
something new before writing a standards document, the multicasting
extension to the Internet architecture described in these RFC's is not
yet in the "proposed standard" stage, although we are moving in that
direction.  Experimental implementations are now under development.

What are the implications for the NETBIOS protocol design effort?

**> Make sure your protocol is consistent with the proposed Internet
    multicasting facility, so that the local-net-only restriction on
    broadcasting can be removed from a NETBIOS implementation with
    minimal work when and if Internet multicasting is generally
    available.

At some point, the NETBIOS application could be a good demonstration of
the Internet multicasting facility.  The vendors developing NETBIOS
implementations for the DoD protocol suite are concerned with making a
product and selling it, rather than in protocol development.  However,
if NETBIOS is successful, perhaps customer interest in removing the
broadcast restriction will bring about a more active collaboration
between vendors and researchers interested in Internet multicasting.

Bob Braden

  
  

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Sat 20 Sep 86 15:16:34-PDT
From:      "Henry Dardy" <dardy@nrl-acoustics>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Cc:        dardy
Subject:   RE: Ultrix 1.2 and unacceptable tcp packets
You are right: Decnet works perfectly! ***Cough, ghasp, wheeze***.  Sorry,
but your (flame on) hadn't cooled yet!

Hank

------
-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Sun, 21-Sep-86 14:17:56 EDT
From:      tcs@USNA.ARPA (Terry Slattery)
To:        mod.protocols.tcp-ip
Subject:   Fiber Ethernet problem

We have a fiber optic based Ethernet product installed here and are
having a problem with a Gould 9050 being attached to the net.

DESCRIPTION:

We have the Codenoll ethernet on fiber optic product with the following
configuration:

-----------  ~325M    --------------    ~800M       ---------------
|usna.arpa|-----------|Star Coupler|----------------|usna-gus.arpa|
-----------           --------------                ---------------
                            |     
                            | ~75M
                            |
                      ---------------
                      |usna-cs1.arpa|
                      ---------------
M = meters

Both usna.arpa and usna-cs1.arpa can communicate.  Usna-gus.arpa can hear
some (most?) rwho packets from usna and cs1.  Gus cannot send anything
out without error.  A Gould 6050 which is co-located with usna can
communicate over the 325 meter segment without problems.

ANALYSIS:

Optical power measurements show -15db at usna and -12db at gus (better
polished connectors and lower loss cable are the difference).  The
flux budget is 21db, so we are well within spec there.

A recent note to these lists leads me to believe that there is a timing
problem.  Codenoll supplied the following timing info:

Device					Delay (ns)
Controller encoder			  100
Xcvr xmit				  300
Fiber cable (1600 meters@4.33ns/m)	 6928
Xcvr rcv				  650
Xcvr cable (60 meters@5.13ns/m)		  308
					-----
TOTAL					 8386

I have connected the Gould and a Tektronix 6130 to a TCL MP station
and they communicate without problems, thus proving that the interface
is working correctly.

MISC. INFO:

The Gould Ethernet Controller Model 8561 Tech. Manual (May 85)
says that it tries 16 retransmits before giving up completely.
It also mentions a control bit described as:
  "Transmit even if no arrrier sense signal is detected."
The driver doesn't include any code to modify this bit; it
is automatically reset upon board power-up.

QUESTIONS:

Is the timing out of spec with respect to what the Gould ethernet
interface is capable of handling?

What time delay does most equipment expect?

Does anyone else have experience with this or Siecor's product over
the distances involved here?

Are there more details available on what Gould did w.r.t. the problem
reported at Perdue?
	

Please respond directly and I will summarize the responses.  Thanks,
	-tcs
	Terry Slattery	  U.S. Naval Academy	301-267-4413
	ARPA: tcs@usna.arpa
	UUCP: decvax!brl-smoke!usna!tcs

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Sun, 21 Sep 86 14:17:56 EDT
From:      Terry Slattery <tcs@USNA.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        gouldbugs@BRL.ARPA
Subject:   Fiber Ethernet problem
We have a fiber optic based Ethernet product installed here and are
having a problem with a Gould 9050 being attached to the net.

DESCRIPTION:

We have the Codenoll ethernet on fiber optic product with the following
configuration:

-----------  ~325M    --------------    ~800M       ---------------
|usna.arpa|-----------|Star Coupler|----------------|usna-gus.arpa|
-----------           --------------                ---------------
                            |     
                            | ~75M
                            |
                      ---------------
                      |usna-cs1.arpa|
                      ---------------
M = meters

Both usna.arpa and usna-cs1.arpa can communicate.  Usna-gus.arpa can hear
some (most?) rwho packets from usna and cs1.  Gus cannot send anything
out without error.  A Gould 6050 which is co-located with usna can
communicate over the 325 meter segment without problems.

ANALYSIS:

Optical power measurements show -15db at usna and -12db at gus (better
polished connectors and lower loss cable are the difference).  The
flux budget is 21db, so we are well within spec there.

A recent note to these lists leads me to believe that there is a timing
problem.  Codenoll supplied the following timing info:

Device					Delay (ns)
Controller encoder			  100
Xcvr xmit				  300
Fiber cable (1600 meters@4.33ns/m)	 6928
Xcvr rcv				  650
Xcvr cable (60 meters@5.13ns/m)		  308
					-----
TOTAL					 8386

I have connected the Gould and a Tektronix 6130 to a TCL MP station
and they communicate without problems, thus proving that the interface
is working correctly.

MISC. INFO:

The Gould Ethernet Controller Model 8561 Tech. Manual (May 85)
says that it tries 16 retransmits before giving up completely.
It also mentions a control bit described as:
  "Transmit even if no arrrier sense signal is detected."
The driver doesn't include any code to modify this bit; it
is automatically reset upon board power-up.

QUESTIONS:

Is the timing out of spec with respect to what the Gould ethernet
interface is capable of handling?

What time delay does most equipment expect?

Does anyone else have experience with this or Siecor's product over
the distances involved here?

Are there more details available on what Gould did w.r.t. the problem
reported at Perdue?
	

Please respond directly and I will summarize the responses.  Thanks,
	-tcs
	Terry Slattery	  U.S. Naval Academy	301-267-4413
	ARPA: tcs@usna.arpa
	UUCP: decvax!brl-smoke!usna!tcs
-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Sun, 21-Sep-86 14:50:03 EDT
From:      dardy@NRL-ACOUSTICS.ARPA ("Henry Dardy")
To:        mod.protocols.tcp-ip
Subject:   RE: Ultrix 1.2 and unacceptable tcp packets

You are right: Decnet works perfectly! ***Cough, ghasp, wheeze***.  Sorry,
but your (flame on) hadn't cooled yet!

Hank

------

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 86 11:19:00 PST
From:      <gary@acc.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic>
Subject:   Standard X.25 on Arpanet
Hans,

I would be extremely interested in what you find out.  As it would be
germane for this group, could you please publish your findings?

Thanks,

Gary
.

------
-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22-Sep-86 10:43:47 EDT
From:      hwb@MCR.UMICH.EDU (Hans-Werner Braun)
To:        mod.protocols.tcp-ip
Subject:   Standard X.25 on the Arpanet.

Hi:
 
I am wondering about who is using Standard X.25 to connect to an Arpa IMP
(PSN) these days. Not HDH, not DH or LH (no 1822 at all), no Basic X.25
and not on the Milnet. Just plain Arpanet Standard X.25 attachments. I
would appreciate a note if you are connected like that and would also be
interested in what machine/operating_system/interface you use and
eventually whether you saw any problems with such a setup.
 
	-- Hans-Werner

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22-Sep-86 12:00:51 EDT
From:      mckee@MITRE.ARPA
To:        mod.protocols.tcp-ip
Subject:   Comm. Fault Recognition/Diagnosis

For those of you interested in communications network fault
recognition and diagnosis, the 15 Sept. issue of Datamation has
a survey article by Bill Musgrave;  "Sorting Out The Solutions",
page 98.

H. Craig McKee

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22-Sep-86 15:19:00 EDT
From:      gary@acc.arpa
To:        mod.protocols.tcp-ip
Subject:   Standard X.25 on Arpanet

Hans,

I would be extremely interested in what you find out.  As it would be
germane for this group, could you please publish your findings?

Thanks,

Gary
.

------

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22-Sep-86 22:06:51 EDT
From:      rms@ACC-SB-UNIX.ARPA (Ron Stoughton)
To:        mod.protocols.tcp-ip
Subject:   X.25 on Arpanet

Hosts requiring X.25 Standard service must be connected to an IMP running
PSN6.  I am not certain, but I don't believe many (if any at all) Arpanet
IMPs have been converted to run PSN6.  Many will require a hardware upgrade
(C/30 to C/30E).  Maybe someone from BBN can comment on this and give a
schedule for upgrading the Arpanet IMPs.

Ron Stoughton
rms@acc-sb-unix.arpa

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 1986 05:53-PDT
From:      STJOHNS@SRI-NIC.ARPA
To:        rms@ACC-SB-UNIX.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, gary@BRL-SAGE.ARPA
Subject:   Re: X.25 on Arpanet
As  of  this  writing and speaking semi-authoritatively I believe
that all of the PSNs on the ARPANET have been upgraded  to  C30E.
I  am  not  sure of the status of the PSN software though on that
side of the net, but the plan was to field PSN 6  as  quickly  as
possible.

Mike StJohns (DDN PMO)
-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23-Sep-86 10:15:08 EDT
From:      jseeger@CC5.BBN.COM
To:        mod.protocols.tcp-ip
Subject:   Re: X.25 on Arpanet

All,

ARPANET nodes have been upgraded hardware-wise to C/30e's.  The upgrade to 
PSN 6.0 software is proceeding now.  However, all nodes have been running
PSN 5.0 for several months, and x.25 standard service was even possible
before that, under PSN 3.0/4.0 (although it required the loading of a
separate x.25 package).

-Josh Seeger (BBN Communications, Network Analysis)

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23-Sep-86 12:50:17 EDT
From:      fserr@CC5.BBN.COM (Frederick E Serr BBN 3/176 x2474)
To:        mod.protocols.tcp-ip
Subject:   re: X.25 on ARPANET

The hardware upgrade on the ARPANET is complete.  PSN 6 has been
deployed to a few nodes, and deployment to other nodes in ongoing.
I am not certain if a definite schedule has been established for
the remaining nodes, but I would expect that all ARPANET nodes would
be running PSN 6 within one month.

Fred Serr
BBNCC Network Analysis

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 86 12:50:17 EDT (Tue)
From:      Frederick E Serr BBN 3/176 x2474 <fserr@cc5.bbn.com>
To:        hwb@mcr.umich.edu
Cc:        tcp-ip@sri-nic.ARPA
Subject:   re: X.25 on ARPANET
The hardware upgrade on the ARPANET is complete.  PSN 6 has been
deployed to a few nodes, and deployment to other nodes in ongoing.
I am not certain if a definite schedule has been established for
the remaining nodes, but I would expect that all ARPANET nodes would
be running PSN 6 within one month.

Fred Serr
BBNCC Network Analysis
-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24-Sep-86 18:07:01 EDT
From:      tcs@USNA.ARPA (Terry Slattery)
To:        mod.protocols.tcp-ip
Subject:   Fiber Ethernet problem solved

The fiber ethernet problem has been solved.  This is rather long (~200
lines) and includes info supplied by various people on the net.  If you
only are interested in the solution, skip down to "THE SOLUTION".

First, a synopsis of the problem.

SYNOPSIS

A Gould 9050 connected via a Codenoll Ethernet over fiber optic network
wouldn't talk to a Vax 780 (or Gould 6050 co-located with the 780).  The
Goulds run thier UTX Unix product.  The fiber's optical power levels
checked out to be within spec.  The 9050 could hear rwho packets from
the 780. The 9050 would report errors on EVERY outgoing packet. Timing
estimates showed the 9050 getting receive carrier about 8us after
transmit started.  The controller manual noted a bit which when set
would:

  "Transmit even if no arrrier sense signal is detected."

but the driver didn't contain code to set the bit.  A recent note to
these lists from Cornell (I hope this is right this time) suggested that
the 9050 needed to have this bit set.

INPUT FROM OTHERS ON THESE LISTS

From: swb@devvax.tn.cornell.edu (Scott Brim)
I'm pretty sure I know what that bit is (haven't looked at the Gould
ethernet manual for a year) -- and I don't think it's your problem --
but here's an explanation of the bit: The Gould board uses the 82586
controller chip.  There's an option in the 82586 to look for its own
signal coming back from the transceiver within a certain amount of
time.  It used to be that you couldn't use a "transceiver cable" more
than a certain length (I remember 6 ns, but that seems awfully short).
They turned this off for us -- it's just a change to an initialization
bit in the PROMs on the Ethernet board.
							Scott

[Ed note: I didn't get any info from Gould on the actual time delay over
which the system would break, but our 6050 would work in place of the
780 and the time delay there was ~4us (calculated and measured).]

From:        <BEAME%MCMASTER.BITNET@WISCVM.WISC.EDU>
      Here at McMaster University we have a star coupler with 4 legs of
around 1500 ft. . We were using Codelink 2020A modems, we found that
we were able to transmit from leg 1 to leg (2,3,4) and leg 2 to leg (1,3,4)
we were unable to transmit from leg 3 to leg 4. This problem cleared up
after trying several modems on leg 4. Thus the matching of modems IS
important.

     Next, if you are using 2020A's, the echo from the modem (back down the
receive line while transmitting) is not done within the modem but at
the star coupler. Thus a machine might complain about late echo.

     We have just installed some 3030A's which do local echo and block out
the echo from the coupler and all of our problems and errors (DECNET errors
on every packet with 2020's) have gone away.

         - Carl Beame

[Ed note:  The 2020 is an old product and is no longer sold.
Codenoll told me that the modems (we have 3030 and 3030S)
do not do local echo.  The measurements with the scope showed delays
identical to the calculated delays on the three modems we have.]

From: leong@andrew.cmu.edu (John Leong)
Looking at your topology, it does not look like you have a distance or
propagation time problem. 

I am assuming GUS is your problem GOULD machine. Have you establish that the
GUS interface, fibre transceiver and the fibre are all O.K. ?  If it was us,
we would have checked it out as follows : disconnected both USNA and USNA-CS
from the net and put a portable PC running the Netwatch provided MIT's PCIP
to do snooping at the star hub just to make sure that GUS is transmitting
fine.

I know of a number of problems associated with asymetrical passive star hub
network where some spines are much longer than the other, although it doesn't
necessary explain you problem. However, you may be interested for future
reference just the same. 

One problem is receiver saturation. The receiver of a station near to the hub
can get blasted by the transmitter of a station also near to the hub. Your
75M link to USNA-CS may qualify for such problem, but then again, it may not.


Another more obscure problem has to do with collision. Most reciver has an
ACG (Automatic Gain Control) which essentially try to pick out signal from
background noise.  When a station on a long spine transmit to a station on
another long spine *at the same time as* one on the short spine started
transmitting, it is a normal collision. However, because of the relative
signal strength, the ACG of the nearer staion's receiver may view the remote
signal as noise and not count it as a collision for retry. On the other hand
relative value as seen by the receiving station may not be significant enough
for the remote stations signal to be dropped off as noise. In which case, you
have an undeteced collision. Ungermann Bass sells the same set up as Codenol.
However, for asymetrical network, they strongly recommend the use of an
active hub ... but there again, they may just like to make money since the
active hub is anything by cheap.

John leong
leong@andrew.cmu.edu

[Ed note:  I also thought the problem was optical power levels.  I spent
a lot of time checking that aspect.  Only after I checked the optical
signal levels and then got out the scope, opened up the xcvr and checked
the transmit and receive signals at the transceiver cable connector did
I decide that the optical stuff was indeed ok.]

From:     "Robert J. Reschly Jr." <reschly@BRL.ARPA>
   I don't have any helpful answers for you, but I do have an aside.

   One of the nicer things that gould has provided is a program called
enfunc(8).  When invoked with the stats option (/etc/enfunc en0 stats)
it displays a nicely formatted summary of the interface's activity.

   Just thought you may be interested (in case you had not noticed it
yet).

[Ed note:  This program is crucial to the problem solution (at least
for us).]

From: Preston Mullen <mullen@nrl-mpm.arpa>
On our 9005, Gould had to modify their Ethernet device driver software
to turn on that "transmit regardless of carrier sense" bit so that their
Ethernet card would work properly here with a DEC DELNI.  This was supposedly
because of some timing problems, for which I've never had an adequate
explanation.  (Broadband Ethernet, e.g. DEC DECOM, would supposedly
require the same fix.)  They also changed the Ethernet board itself
in some way (perhaps to implement the "ignore carrier sense" bit?)
The work was done in early June; I think the board dated back to
November-December.

I was told that the ability to set or reset this would eventually
be moved into the kernel so that it could be changed dynamically.

Caveat: I may have some of this wrong; unfortunately, I never got anything
in writing from Gould about this problem and solution.  Everything has
worked fine since the change was made.

	Preston Mullen

[Ed note:  Just like Scott's fix at Cornell.]

MISC INFO

Lew Law at Harvard University also called me Monday (they have a rather
large configuration there).  He couldn't offer much in the way of
concrete solutions after discussing all the testing I had already done.

Bart Brooks at Gould was really prompt; he called EARLY Monday and
said that the control bit in the interface was indeed the problem
and that there were two solutions (see below).

THE SOLUTION

Bart Brooks at Gould confirmed that the "Transmit without carrier
sense" bit was the problem.  There were two solutions:

1. Cornell (and NRL) have a different prom set which turns the
bit on at initialization; get a set of those proms for the interface.

2. The UTX 2.0 software driver (and enfunc program mentioned above)
contain code to set the bit.  Get a copy of this software and
use it to set the bit.

I made the necessary changes to the ethernet driver to set the
"tnosense" bit.  Running enfunc (a version that knows about setting
tnosense) set the bit (as reported by the driver).  However,
that didn't make the thing work.  The timing measurements showed
that the 9050 was only sending 10us long packets - much smaller
than a full ethernet packet.  Called Gould to ask for help.

Bart Brooks emailed me a manual page on enfunc (received this morning).
One of the notes was to "re-ifconfig" the interface after running
enfunc. Funny, when that procedure is used, it works!  We've not seen
any errors reported by the interface since this morning when it started
working.  For those interested, the functionality of the new driver
and enfunc will be in UTX 2.0.

One bad thing about this interface is that it uses a micro on board
which doesn't contain code to allow the user to examine the state of the
on-board control bits.  The driver tells the board what to do and
remembers what has been sent.

The people at Codenoll were very patient with my questions during
the testing and diagnosis of the problem (which turned out to not
be their fault).

As an aside, our Tektronix 6130 had the same symptoms when attached
to the fiber transceiver.  I called Excelan about their interface
(which we will be using in a gateway on the fiber net later this year)
and was told that there is a jumper on the card to affect the
same "transmit with no carrier sense" operation.

I have one remaining question:

The old December 1982, IEEE 802.3 DRAFT I have (our final is still on
order)  says under the section on "Transmit Media Access Management":

"After the last bit of the passing frame (i.e., when carrierSense
changes from true to false), the CSMA/CD Media Access sublayer continues
to defer for a proper interframe spacing, interFrameSpacing (see Section
4.2.3.2.2).

At the end of the interframe spacing of that time, if it has a frame
waiting to be transmitted, transmission is initiated independent of the
value of carrierSense.  When transmission has completed (or immediately,
if there was nothing to transmit) the CSMA/CD Media Access sublayer
resumes its original monitoring of carrierSense."

This seems to imply that the interface should not monitor carrier
during transmit.  Could someone more familiar with the spec elaborate?

Thanks to everyone for their help; especially Gould who had a
bunch of people working on it.

	-tcs
	Terry Slattery	  U.S. Naval Academy	301-267-4413
	ARPA: tcs@usna.arpa
	UUCP: decvax!brl-smoke!usna!tcs

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Sep 86 18:07:01 EDT
From:      Terry Slattery <tcs@USNA.ARPA>
To:        tcp-ip@SRI-NIC.ARPA, gouldbugs@BRL.ARPA
Cc:        tcs@USNA.ARPA, disque@USNA.ARPA
Subject:   Fiber Ethernet problem solved
The fiber ethernet problem has been solved.  This is rather long (~200
lines) and includes info supplied by various people on the net.  If you
only are interested in the solution, skip down to "THE SOLUTION".

First, a synopsis of the problem.

SYNOPSIS

A Gould 9050 connected via a Codenoll Ethernet over fiber optic network
wouldn't talk to a Vax 780 (or Gould 6050 co-located with the 780).  The
Goulds run thier UTX Unix product.  The fiber's optical power levels
checked out to be within spec.  The 9050 could hear rwho packets from
the 780. The 9050 would report errors on EVERY outgoing packet. Timing
estimates showed the 9050 getting receive carrier about 8us after
transmit started.  The controller manual noted a bit which when set
would:

  "Transmit even if no arrrier sense signal is detected."

but the driver didn't contain code to set the bit.  A recent note to
these lists from Cornell (I hope this is right this time) suggested that
the 9050 needed to have this bit set.

INPUT FROM OTHERS ON THESE LISTS

From: swb@devvax.tn.cornell.edu (Scott Brim)
I'm pretty sure I know what that bit is (haven't looked at the Gould
ethernet manual for a year) -- and I don't think it's your problem --
but here's an explanation of the bit: The Gould board uses the 82586
controller chip.  There's an option in the 82586 to look for its own
signal coming back from the transceiver within a certain amount of
time.  It used to be that you couldn't use a "transceiver cable" more
than a certain length (I remember 6 ns, but that seems awfully short).
They turned this off for us -- it's just a change to an initialization
bit in the PROMs on the Ethernet board.
							Scott

[Ed note: I didn't get any info from Gould on the actual time delay over
which the system would break, but our 6050 would work in place of the
780 and the time delay there was ~4us (calculated and measured).]

From:        <BEAME%MCMASTER.BITNET@WISCVM.WISC.EDU>
      Here at McMaster University we have a star coupler with 4 legs of
around 1500 ft. . We were using Codelink 2020A modems, we found that
we were able to transmit from leg 1 to leg (2,3,4) and leg 2 to leg (1,3,4)
we were unable to transmit from leg 3 to leg 4. This problem cleared up
after trying several modems on leg 4. Thus the matching of modems IS
important.

     Next, if you are using 2020A's, the echo from the modem (back down the
receive line while transmitting) is not done within the modem but at
the star coupler. Thus a machine might complain about late echo.

     We have just installed some 3030A's which do local echo and block out
the echo from the coupler and all of our problems and errors (DECNET errors
on every packet with 2020's) have gone away.

         - Carl Beame

[Ed note:  The 2020 is an old product and is no longer sold.
Codenoll told me that the modems (we have 3030 and 3030S)
do not do local echo.  The measurements with the scope showed delays
identical to the calculated delays on the three modems we have.]

From: leong@andrew.cmu.edu (John Leong)
Looking at your topology, it does not look like you have a distance or
propagation time problem. 

I am assuming GUS is your problem GOULD machine. Have you establish that the
GUS interface, fibre transceiver and the fibre are all O.K. ?  If it was us,
we would have checked it out as follows : disconnected both USNA and USNA-CS
from the net and put a portable PC running the Netwatch provided MIT's PCIP
to do snooping at the star hub just to make sure that GUS is transmitting
fine.

I know of a number of problems associated with asymetrical passive star hub
network where some spines are much longer than the other, although it doesn't
necessary explain you problem. However, you may be interested for future
reference just the same. 

One problem is receiver saturation. The receiver of a station near to the hub
can get blasted by the transmitter of a station also near to the hub. Your
75M link to USNA-CS may qualify for such problem, but then again, it may not.


Another more obscure problem has to do with collision. Most reciver has an
ACG (Automatic Gain Control) which essentially try to pick out signal from
background noise.  When a station on a long spine transmit to a station on
another long spine *at the same time as* one on the short spine started
transmitting, it is a normal collision. However, because of the relative
signal strength, the ACG of the nearer staion's receiver may view the remote
signal as noise and not count it as a collision for retry. On the other hand
relative value as seen by the receiving station may not be significant enough
for the remote stations signal to be dropped off as noise. In which case, you
have an undeteced collision. Ungermann Bass sells the same set up as Codenol.
However, for asymetrical network, they strongly recommend the use of an
active hub ... but there again, they may just like to make money since the
active hub is anything by cheap.

John leong
leong@andrew.cmu.edu

[Ed note:  I also thought the problem was optical power levels.  I spent
a lot of time checking that aspect.  Only after I checked the optical
signal levels and then got out the scope, opened up the xcvr and checked
the transmit and receive signals at the transceiver cable connector did
I decide that the optical stuff was indeed ok.]

From:     "Robert J. Reschly Jr." <reschly@BRL.ARPA>
   I don't have any helpful answers for you, but I do have an aside.

   One of the nicer things that gould has provided is a program called
enfunc(8).  When invoked with the stats option (/etc/enfunc en0 stats)
it displays a nicely formatted summary of the interface's activity.

   Just thought you may be interested (in case you had not noticed it
yet).

[Ed note:  This program is crucial to the problem solution (at least
for us).]

From: Preston Mullen <mullen@nrl-mpm.arpa>
On our 9005, Gould had to modify their Ethernet device driver software
to turn on that "transmit regardless of carrier sense" bit so that their
Ethernet card would work properly here with a DEC DELNI.  This was supposedly
because of some timing problems, for which I've never had an adequate
explanation.  (Broadband Ethernet, e.g. DEC DECOM, would supposedly
require the same fix.)  They also changed the Ethernet board itself
in some way (perhaps to implement the "ignore carrier sense" bit?)
The work was done in early June; I think the board dated back to
November-December.

I was told that the ability to set or reset this would eventually
be moved into the kernel so that it could be changed dynamically.

Caveat: I may have some of this wrong; unfortunately, I never got anything
in writing from Gould about this problem and solution.  Everything has
worked fine since the change was made.

	Preston Mullen

[Ed note:  Just like Scott's fix at Cornell.]

MISC INFO

Lew Law at Harvard University also called me Monday (they have a rather
large configuration there).  He couldn't offer much in the way of
concrete solutions after discussing all the testing I had already done.

Bart Brooks at Gould was really prompt; he called EARLY Monday and
said that the control bit in the interface was indeed the problem
and that there were two solutions (see below).

THE SOLUTION

Bart Brooks at Gould confirmed that the "Transmit without carrier
sense" bit was the problem.  There were two solutions:

1. Cornell (and NRL) have a different prom set which turns the
bit on at initialization; get a set of those proms for the interface.

2. The UTX 2.0 software driver (and enfunc program mentioned above)
contain code to set the bit.  Get a copy of this software and
use it to set the bit.

I made the necessary changes to the ethernet driver to set the
"tnosense" bit.  Running enfunc (a version that knows about setting
tnosense) set the bit (as reported by the driver).  However,
that didn't make the thing work.  The timing measurements showed
that the 9050 was only sending 10us long packets - much smaller
than a full ethernet packet.  Called Gould to ask for help.

Bart Brooks emailed me a manual page on enfunc (received this morning).
One of the notes was to "re-ifconfig" the interface after running
enfunc. Funny, when that procedure is used, it works!  We've not seen
any errors reported by the interface since this morning when it started
working.  For those interested, the functionality of the new driver
and enfunc will be in UTX 2.0.

One bad thing about this interface is that it uses a micro on board
which doesn't contain code to allow the user to examine the state of the
on-board control bits.  The driver tells the board what to do and
remembers what has been sent.

The people at Codenoll were very patient with my questions during
the testing and diagnosis of the problem (which turned out to not
be their fault).

As an aside, our Tektronix 6130 had the same symptoms when attached
to the fiber transceiver.  I called Excelan about their interface
(which we will be using in a gateway on the fiber net later this year)
and was told that there is a jumper on the card to affect the
same "transmit with no carrier sense" operation.

I have one remaining question:

The old December 1982, IEEE 802.3 DRAFT I have (our final is still on
order)  says under the section on "Transmit Media Access Management":

"After the last bit of the passing frame (i.e., when carrierSense
changes from true to false), the CSMA/CD Media Access sublayer continues
to defer for a proper interframe spacing, interFrameSpacing (see Section
4.2.3.2.2).

At the end of the interframe spacing of that time, if it has a frame
waiting to be transmitted, transmission is initiated independent of the
value of carrierSense.  When transmission has completed (or immediately,
if there was nothing to transmit) the CSMA/CD Media Access sublayer
resumes its original monitoring of carrierSense."

This seems to imply that the interface should not monitor carrier
during transmit.  Could someone more familiar with the spec elaborate?

Thanks to everyone for their help; especially Gould who had a
bunch of people working on it.

	-tcs
	Terry Slattery	  U.S. Naval Academy	301-267-4413
	ARPA: tcs@usna.arpa
	UUCP: decvax!brl-smoke!usna!tcs
-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24-Sep-86 19:45:58 EDT
From:      hwb@MCR.UMICH.EDU (Hans-Werner Braun)
To:        mod.protocols.tcp-ip
Subject:   Standard X.25.

The result of my inquiry some days ago is that Mitre claims to have the only
Standard X.25 port on the Arpanet (installed about two weeks ago) with so far
nothing connected to it. They intend to connect a host soon, though.
 
I have not heard about any other *installed* Standard X.25 ports on
Arpanet PSNs.
 
	-- Hans-Werner

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25-Sep-86 18:23:50 EDT
From:      rick@SEISMO.CSS.GOV (Rick Adams)
To:        mod.protocols.tcp-ip
Subject:   new hostnumber for seismo.


As of a few hours ago, seismo.CSS.GOV may ONLY be reached at the
host number 192.12.141.25. All other addresses should not be used as
they connect to another machine.

Please change this in your local host tables until the NIC has
incorporated them into the master tables.
Of course, if you are using a domain server, you will get the
correct address the next time you query the CSS.GOV servers.

---rick

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25-Sep-86 23:12:05 EDT
From:      Murray.pa@XEROX.COM
To:        mod.protocols.tcp-ip
Subject:   Re: Fiber Ethernet problem solved

"This seems to imply that the interface should not monitor carrier
during transmit.  Could someone more familiar with the spec elaborate?"

The main idea is that there should be a 9.6 microsecond minimum gap
between packets so that the receiver can get ready to grab the next
packet. Dropping packets can easily have disasterous impact on
performance. A bit of time will normaly simplify the hardware design.

The fine print is trying to say (I think) that after the transmitter
waits 9.6 microseconds, it shouldn't wait again/more (as if it were
starting fresh and the middle of a packet was already on the wire) just
because it now looks like there is a packet already on the wire. That
packet started just a very short while ago, probably less that a bit
time, (if everybody is following the rules).

If nothing else, the fraction of a bit difference in the phase of the
transmit clocks at the two stations could easily provoke this case. When
the (second/interesting) transmitter does starts to transmit, it will
cause a collision. That's the desired result when two stations try to
transmit at the "same" time.

Note that the fractional bit race condition actually happens quite
often. Consider three stations on an ethernet. Call them left to right
A, B, and C. Suppose A is transmitting and B and C are waiting to send.
When A finishes, the end of packet will sweep down the wire. When it
gets to B, B's 9.6 microsecond clock starts ticking. A while later, C's
clock will start too. When B's clock expires, the wire (around B) is
empty so B starts transmitting. When C's clock goes off, B's new packet
is just about to arrive at C or has just arrived at C. Because the wire
delays cancel out in this configuration, fractions of a bit dure to
clock synchronization are important.

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26-Sep-86 14:12:29 EDT
From:      mckee@MITRE.ARPA
To:        mod.protocols.tcp-ip
Subject:   (none)

Marshall Abrams, a Security guru here at MITRE, sent me a copy of the
following note by Brian Reid.  The note has little to do with TCP and
IP, but it is instructive to learn how our networks are being used for
nefarious purposes, and besides, there is a certain lascivious pleasure
in reading about somebody elses troubles.  H. C. McKee
--------------------------

From: reid@decwrl.DEC.COM (Brian Reid)
Date: 16 Sep 1986 1519-PDT (Tuesday)
To: Peter G. Neumann <Neumann@csl.sri.com>   [FOR RISKS]
Subject: Massive UNIX breakins at Stanford

    Lessons learned from a recent rash of Unix computer breakins

Introduction
   A number of Unix computers in the San Francisco area have
   recently been plagued with breakins by reasonably talented
   intruders. An analysis of the breakins (verified by a telephone
   conversation with the intruders!) show that the networking
   philosophy offered by Berkeley Unix, combined with the human
   nature of systems programmers, creates an environment in which
   breakins are more likely, and in which the consequences of
   breakins are more dire than they need to be.

   People who study the physical security of buildings and military
   bases believe that human frailty is much more likely than
   technology to be at fault when physical breakins occur. It is
   often easier to make friends with the guard, or to notice that he
   likes to watch the Benny Hill show on TV and then wait for that
   show to come on, than to try to climb fences or outwit burglar
   alarms.

Summary of Berkeley Unix networking mechanism:

   The user-level networking features are built around the
   principles of "remote execution" and "trusted host". For example,
   if you want to copy a file from computer A to computer B, you
   type the command
             rcp A:file B:file
   If you want to copy the file /tmp/xyz from the computer that you
   are now using over to computer C where it will be called
   /usr/spool/breakin, you type the command
             rcp /tmp/xyz C:/usr/spool/breakin
   The decision of whether or not to permit these copy commands is
   based on "permission" files that are stored on computers A, B,
   and C. The first command to copy from A to B will only work if
   you have an account on both of those computers, and the
   permission file stored in your directory on both of those
   computers authorizes this kind of remote access.

   Each "permission file" contains a list of computer names and user
   login names. If the line "score.stanford.edu reid" is in the
   permission file on computer "B", it means that user "reid" on
   computer "score.stanford.edu" is permitted to perform remote
   operations such as rcp, in or out, with the same access
   privileges that user "reid" has on computer B.

How the breakins happened.

   One of the Stanford campus computers, used primarily as a mail
   gateway between Unix and IBM computers on campus, had a guest
   account with user id "guest" and password "guest". The intruder
   somehow got his hands on this account and guessed the password.
   There are a number of well-known security holes in early releases
   of Berkeley Unix, many of which are fixed in later releases.
   Because this computer is used as a mail gateway, there was no
   particular incentive to keep it constantly up to date with the
   latest and greatest system release, so it was running an older version
   of the system. The intruder instantly cracked "root" on that
   computer, using the age-old trojan horse trick. (He had noticed
   that the guest account happened to have write permission into a
   certain scratch directory, and he had noticed that under certain
   circumstances, privileged jobs could be tricked into executing
   versions of programs out of that scratch directory instead of out
   of the normal system directories).

   Once the intruder cracked "root" on this computer, he was able to
   assume the login identity of everybody who had an account on that
   computer. In particular, he was able to pretend to be user "x" or
   user "y", and in that guise ask for a remote login on other
   computers. Sooner or later he found a [user,remote-computer] pair
   for which there was a permission file on the other end granting
   access, and now he was logged on to another computer. Using the
   same kind of trojan horse tricks, he was able to break into root
   on the new computer, and repeat the process iteratively.

   In most cases the intruder left trojan-horse traps behind on
   every computer that he broke into, and in most cases he created
   login accounts for himself on the computers that he broke into.
   Because no records were kept, it is difficult to tell exactly how
   many machines were penetrated, but the number could be as high as
   30 to 60 on the Stanford campus alone. An intruder using a
   similar modus operandi has been reported at other installations.

How "human nature" contributed to the problem

   The three technological entry points that made this intrusion
   possible were:

      * The large number of permission files, with entirely
          too many permissions stored in them, found all over the campus
          computers (and, for that matter, all over the ARPAnet).

      * The presence of system directories in which users have write
          permission.

      * Very sloppy and undisciplined use of search paths in privileged
        programs and superuser shell scripts.


Permissions: Berkeley networking mechanism encourages carelessness.

   The Berkeley networking mechanism is very very convenient. I use
   it all the time. You want to move a file from one place to
   another? just type "rcp" and it's there. Very fast and very
   efficient, and quite transparent. But sometimes I need to move a
   file to a machine that I don't normally use. I'll log on to that
   machine, quickly create a temporary permission file that lets me
   copy a file to that machine, then break back to my source machine
   and type the copy command. However, until I'm quite certain that
   I am done moving files, I don't want to delete my permission file
   from the remote end or edit that entry out of it. Most of us use
   display editors, and oftentimes these file copies are made to
   remote machines on which the display editors don't always work
   quite the way we want them to, so there is a large nuisance
   factor in running the text editor on the remote end. Therefore
   the effort in removing one entry from a permission file--by
   running the text editor and editing it out--is high enough that
   people don't do it as often as they should. And they don't want
   to *delete* the permission file, because it contains other
   entries that are still valid. So, more often than not, the
   permission files on rarely-used remote computers end up with
   extraneous permissions in them that were installed for a
   one-time-only operation. Since the Berkeley networking commands
   have no means of prompting for a password or asking for the name
   of a temporary permission file, everybody just edits things into
   the permanent permission file. And then, of course, they forget
   to take it out when they are done.


Write permission in system directories permits trojan horse attacks.

   All software development is always behind schedule, and
   programmers are forever looking for ways to do things faster. One
   convenient trick for reducing the pain of releasing new versions
   of some program is to have a directory such as /usr/local/bin or
   /usr/stanford/bin or /usr/new in which new or locally-written
   versions of programs are kept, and asking users to put that
   directory on their search paths. The systems programmers then
   give themselves write access to that directory, so that they can
   intall a new version just by typing "make install" rather than
   taking some longer path involving root permissions. Furthermore,
   it somehow seems more secure to be able to install new software
   without typing the root password. Therefore it is a
   nearly-universal practice on computers used by programmers to
   have program directories in which the development programmers
   have write permission. However, if a user has write permission in
   a system directory, and if an intruder breaks into that user's
   account, then the intruder can trivially break into root by using
   that write permission to install a trojan horse.

Search paths: people usually let convenience dominate caution.

   Search paths are almost universally misused. For example, many
   people write shell scripts that do not specify an explicit search
   path, which makes them vulnerable to inheriting the wrong path.
   Many people modify the root search path so that it will be
   convenient for systems programmers to use interactively as the
   superuser, forgetting that the same search path will be used by
   system maintenance scripts run automatically during the night.
   It is so difficult to debug failures that are caused by incorrect
   search paths in automatically-run scripts that a common "repair"
   technique is to put every conceivable directory into the search
   path of automatically-run scripts. Essentially every Unix
   computer I have ever explored has grievous security leaks caused
   by underspecified or overlong search paths for privileged users.

Summary conclusion: Wizards cause leaks

   The people who are most likely to be the cause of leaks are
   the wizards. When something goes wrong on a remote machine, often
   a call goes in to a wizard for help. The wizard is usually busy
   or in a hurry, and he often is sloppier than he should be with
   operations on the remote machine. The people who are most likely
   to have permission files left behind on stray remote machines are
   the wizards who once offered help on that machine. But, alas,
   these same wizards are the people who are most likely to have
   write access to system directories on their home machines,
   because it seems to be in the nature of wizards to want to
   collect as many permissions as possible for their accounts. Maybe
   that's how they establish what level of wizard that they are. The
   net result is that there is an abnormally high probability that
   when an errant permission file is abused by an intruder, that it
   will lead to the account of somebody who has an unusually large
   collection of permissions on his own machine, thereby making it
   easier to break into root on that machine.

Conclusions.

   My conclusions from all this are these:
      * Nobody, no matter how important, should have write permission
          into any directory on the system search path. Ever.

      * Somebody should carefully re-think the user interface of the
          Berkeley networking mechanisms, to find ways to permit people to
          type passwords as they are needed, rather than requiring them to
          edit new permissions into their permissions files.

      * The "permission file" security access mechanism seems
        fundamentally vulnerable. It would be quite reasonable
          for a system manager to forbid the use of them, or to
          drastically limit the use of them. Mechanized checking is
          easy.

      * Programmer convenience is the antithesis of security, because
          it is going to become intruder convenience if the programmer's
          account is ever compromised. This is especially true in
        setting up the search path for the superuser.



Lament
   I mentioned in the introduction that we had talked to the
   intruders on the telephone. To me the most maddening thing about
   this intrusion was not that it happened, but that we were unable
   to convince any authorities that it was a serious problem, and
   could not get the telephone calls traced. At one point an
   intruder spent 2 hours talking on the telephone with a Stanford
   system manager, bragging about how he had done it, but there was
   no way that the call could be traced to locate him. A few days
   later, I sat there and watched the intruder log on to one
   Stanford comptuer, and I watched every keystroke that he typed on
   his keyboard, and I watched him break in to new directories, but
   there was nothing that I could do to catch him because he was
   coming in over the telephone. Naturally as soon as he started to
   do anything untoward I blasted the account that he was using and
   logged him off, but sooner or later new intruders will come
   along, knowing that they will not be caught because what they are
   doing is not considered serious. It isn't necessarily serious,
   but it could be. I don't want to throw such people in jail,
   and I don't want to let them get away either. I just want to
   catch them and shout at them and tell them that they are being
   antisocial.

Brian Reid
DEC Western Research and Stanford University

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26-Sep-86 18:15:17 EDT
From:      BILLW@SU-SCORE.ARPA (William "Chops" Westfield)
To:        mod.protocols.tcp-ip
Subject:   Why is the ARPANet in such bad shape these days?

Both repsonse and throughput between Stanford and SRi is pretty
awful, and they are only one IMP apart.  Trying to FTP a file
from a host that is further away seems nearly impossible.

Is this just a local problem, say with the Stanford IMP, or
are other people having similar problems?

Note that this is NOT a gateway related problem, since for many
of the paths Ive tried, no gateways should be involved.

BillW
-------

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Sat 27 Sep 86 10:51:52-PDT
From:      Karl Auerbach <AUERBACH@CSL.SRI.COM>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   SMTP, 2600, and the security of mail
A while back I saw a copy of a newsletter titled "2600" which included
source code demonstrating how one could pretend to be an SMTP engine and
inject false mail into a host.  Although the code had a few flaws, its
general structure looked plausable (and short -- about 25 lines of C).

			--karl--
-------
-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27-Sep-86 12:52:00 EDT
From:      BEAME@MCMASTER.BITNET
To:        mod.protocols.tcp-ip
Subject:   Re: Peace fullness.



   Speeking as the president of one of those companies out there trying
to make a living by selling TCP/IP code for PC's ...

   As a developer it IS my responcibility to produce a product that my
clients desire and to develop new features and approches.

   I have done just that, but I am afraid to market it. Why ? Because the
Universities will produce a public (or very cheap) version and have their
name behind it! All my time, effort and MONEY will be wasted.

   What can I do ? Get a Patent ? That takes years, and the protocols might
have changed by than.

   I ask you, what would you do if you wanted to sell such a product.
(Remember were a very small company)

              - Carl Beame,
                President
                Beame & Whiteside Software Ltd.
                259 Fiddler's Green Rd.
                Ancaster, Ontario, Canada.

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27 Sep 86 12:52 EDT
From:      <BEAME%MCMASTER.BITNET@WISCVM.WISC.EDU>
To:        tcp-ip@SRI-nic.arpa
Subject:   Re: Peace fullness.


   Speeking as the president of one of those companies out there trying
to make a living by selling TCP/IP code for PC's ...

   As a developer it IS my responcibility to produce a product that my
clients desire and to develop new features and approches.

   I have done just that, but I am afraid to market it. Why ? Because the
Universities will produce a public (or very cheap) version and have their
name behind it! All my time, effort and MONEY will be wasted.

   What can I do ? Get a Patent ? That takes years, and the protocols might
have changed by than.

   I ask you, what would you do if you wanted to sell such a product.
(Remember were a very small company)

              - Carl Beame,
                President
                Beame & Whiteside Software Ltd.
                259 Fiddler's Green Rd.
                Ancaster, Ontario, Canada.
-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27-Sep-86 13:51:52 EDT
From:      AUERBACH@CSL.SRI.COM (Karl Auerbach)
To:        mod.protocols.tcp-ip
Subject:   SMTP, 2600, and the security of mail

A while back I saw a copy of a newsletter titled "2600" which included
source code demonstrating how one could pretend to be an SMTP engine and
inject false mail into a host.  Although the code had a few flaws, its
general structure looked plausable (and short -- about 25 lines of C).

			--karl--
-------

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 1986 18:07-PDT
From:      STJOHNS@SRI-NIC.ARPA
To:        BEAME%MCMASTER.BITNET@WISCVM.WISC.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Peace fullness.
The only thing I can suggest is make your product better than the
rest on the market.  And be prepared to support it  in  a  timely
manner  to  your  customers.   You  are  correct, Universities do
produce lots of "cheap" software, but it is usually  a  one  time
deal  done  as  part  of a thesis.  The exceptions being projects
funded by the gov't agencies.

In the US at least, you can't patent a software product, but  you
can protect it as a trade secret.  I think you can also patent an
algorithm (for ex the RSA encryption algorithm)

There are risks to any business, no guarantees.

Mike
-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27-Sep-86 21:35:00 EDT
From:      SRA@XX.LCS.MIT.EDU (Rob Austein)
To:        mod.protocols.tcp-ip
Subject:   Why is the ARPANet in such bad shape these days?

Bill,

No, the ARPANET problem is definitely not just at Stanford.  MIT has
been moderately crippled by this for weeks now (since the start of the
fall semester, which is probably -not- a coincidence).  MC and XX have
a hard time talking to each other and they are on the same IMP.  The
NOC claims that this is true for pretty much the entire ARPAnet.
Apparently MILNET is somewhate better off.

The NOC is refering to this mess as a "congestion problem" at the IMP
level.  The current theory the last few times I talked to the NOC was
that we have managed to reach the bandwidth limit of the existing
hardware.  A somewhat scary thought.  If this is in fact the case (and
there is circumstancial evidence that it is, such as the fact that the
net becomes usable again during off hours), we are in for a long
siege, since it is guarenteed to take the DCA and BBN a fair length of
time to deploy any new hardware or bring up new trunks.

Current thoughts and efforts at MIT are (1) we need more data on the
traffic going through the IMPs, and (2) we need to cut down on the
amount of traffic going through the IMPs.  The two go along with each
other to some extent (preliminary results show that roughly 25% of the
traffic through the MIT gateway is to or from XX).  Some interesting
ideas have come up for minimizing load due to email, if that turns out
to be a prime offender (surprisingly, the preliminary statistics don't
seem to indicate that).  If there is anybody else out there doing
analysis of network traffic, please share it.

Also, if there is anybody from BBN who knows more about the problem
and is willing to share it, -please- do.  It's hard to make any kind
of contingency plans in a vacuum.

--Rob

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27-Sep-86 22:49:11 EDT
From:      hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
To:        mod.protocols.tcp-ip
Subject:   Re:  SMTP, 2600, and the security of mail

It is moderately obvious from the protocol that you can spoof SMTP.
What we tell our users about mail is the following:
  - here is how to tell from the headers whether a message was
	delivered locally or via SMTP.  (Details vary per system.)
  - mail that is delivered locally is probably from the person
	it claims to be.  That depends upon the overall security
	of the system, which is never perfect, but probably it is
	OK.  But don't stake your life on it.
  - for mail that came in via network, all you can really be sure
	of is the identity of the most recent host in the link.  The
	received line will show the name of that host.  If the host
	claimed to be someone other than it was, we will tell you.
	(This is in the DEC-20 implementation.  I'm not sure whether
	our Unix code does this.  But I think it does.)  Unfortunately,
	the protocols are such that even if that machine is secure,
	a user on it could send mail to us claiming to be absolutely
	anyone he wanted to be.
In general, if you want to be more certain who the mail came from,
send a response back, referring to  the message.  If you get a 
message "what are you talking about?" you know you have been 
spoofed.  This assumes that the system the author is residing on
keeps his mail private.

You don't need C code to do this spoofing.  Just say "telnet host 25".
That will connect you to their SMTP server.  You can then type a message
claiming to be anybody you like.  We use this for debugging.  The
format of the commands is simple enough that it is perfectly practical
for a person to do.

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27-Sep-86 22:54:41 EDT
From:      dave@RSCH.WISC.EDU (Dave Cohrs)
To:        mod.protocols.tcp-ip
Subject:   Re: Why is the ARPANet in such bad shape these days?

I don't know why it's so bad, but no, it is *not* a localized problem.

Hosts at UW-Madison are also having problems reaching hosts farther
away than our local PSN.  The worst problems (of course) are reaching
hosts on the east coast, especially Rutgers and CSS.GOV sites.

The problem seems to be time/day-of-the-week related, so I assume it's
a congestion problem (response time seems pretty good right now), but
I'm not a net-watcher, so don't take that as gospel.  There also seem
to be some severe routing problems.  On one occation this past week, the
packet turnaround time from our gateway to the CSS gateway (10.0.0.25)
was about 1sec, while one hop farther, from a host on our Pronet to
10.0.0.25 was about 8sec with peaks of over 20sec and many packets were lost.

Actually, one site in the Bay Area has started setting up new UUCP
links (using good ol' dialup connections) to make sure that their mail
will get through.

dave

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27-Sep-86 22:55:52 EDT
From:      hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
To:        mod.protocols.tcp-ip
Subject:   Re: Why is the ARPANet in such bad shape these days?

We apologize for the problems we have caused other sites.  I am well
aware that Rutgers is among the hardest places to reach.  This is a
combination of our 9600 baud line into the IMP, and continual crashes
of our gateway.  We have now replaced our gateway with a gateway from
Cisco.  It is based on a 68000.  It appears to be more reliable than
the old 11/23 code we were using before, and has much better tools to
monitor what is going on and adjust things.  We think that the
reliability problems will largely go away, except for TCP protocol
problems with individual hosts on our network.  Early results suggest
that the 9600 baud line has enough bandwidth to keep mail and news
flowing.  We have long since given up on telnet, though at some times
of the day even that may now be practical.  We are also exploring an
upgrade of the line speed.

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28-Sep-86 00:01:00 EDT
From:      WANCHO@SIMTEL20.ARPA
To:        mod.protocols.tcp-ip
Subject:   Do we need another protocol?

There is a growing trend in the Army to network Intel 310s running
Xenix on a fat Ethernet under OpenNet.  When asked why OpenNet instead
of TCP/IP, the answer most often heard is because OpenNet provides
inter-machine file and record-level access at the application level.

At one time, there was a brief discussion of the possibility of
extending the FTP definition to allow for record-level access.  It
seemed to me then that FTP was the wrong place and that an entirely
new protcol should be defined.  Was this ever done and formally
recognized as part of the TCP protocol suite?  If not, why not?  Would
it be possible to provide an OpenNet functionality within the TCP
confines so that we don't have to provide two otherwise incompatible
services requiring two sets of hardware interfaces for every node that
should have both capabilities.

--Frank

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28-Sep-86 00:21:00 EDT
From:      WANCHO@SIMTEL20.ARPA
To:        mod.protocols.tcp-ip
Subject:   ARPANET congestion?

Over the past three weeks, we have been able to receive mail from
ARPANET hosts but not able to even establish connections, or when a
connection has been eventually established, send mail and receive
acknowledgements within rather generous timeouts to those same hosts.
This one-way performance has also been observed in eventually
established TELNET connections to various ARPANET hosts, where
single-character echoes may take several *minutes* while continuous
output, such as directory listings, appear normally.

According to the NOC, this is a known problem which is being
investigated.  Could we have an intermediate report concerning the
problem?  Are only certain hosts involved?  (Our most persistent and
common problems have been with CSNET-RELAY and WISCVM due to the
volume of mail they pass.)

--Frank

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28-Sep-86 00:52:37 EDT
From:      karn@MOUTON.BELLCORE.COM (Phil R. Karn)
To:        mod.protocols.tcp-ip
Subject:   Re: Peace fullness.

This note reinforces an (only half serious) suggestion somebody around here
made a little while ago on how to stop ISO/OSI dead in its tracks.  First,
write a full-blown implementation of their protocols.  Test it, document it,
do everything you can to make sure it's the best implementation around.

Then give it away.

Phil

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28-Sep-86 00:55:24 EDT
From:      karn@MOUTON.BELLCORE.COM (Phil R. Karn)
To:        mod.protocols.tcp-ip
Subject:   Re:  Why is the ARPANet in such bad shape these days?

I wonder how much of the existing congestion problems would go away if
DARPA banned all 4.2BSD sites from the net until they convert to 4.3?

Phil

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28-Sep-86 04:48:39 EDT
From:      hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
To:        mod.protocols.tcp-ip
Subject:   odd routings

I have been looking at our EGP routings.  I checked a few sites that I
know we talk to a lot.  Our current EGP peers are yale-gw and
css-ring-gw.  (We keep a list of possible peers, and the gateway picks
2.  It will change if one of them becomes inaccessible.  This particular
pair seems to be fairly stable.)  Here I what I found:
  CMU:  As far as I can see, the only way into CMU is cmu-gateway,
	10.2.0.14.  The EGP table showed 10.3.0.27, which is
	gateway.isi.edu.  We will hope that ISI would be smart enough
	to give us a redirect if we actually used this route, but
	it seems odd none the less.  We tried to establish a direct
	EGP connection with cmu-gateway, but we were unable to 
	acquire them.  (In addition to the list of potential peers,
	our gateway also has a list of secondary gateways, all of
	which it will acquire.  The intent is that these are gateways
	that are so important to us that we don't want to depend upon
	the core for information about them.)  We have ended up
	adding a static routing to them.
  MIT:  They seem to have 4 different networks.  The ones with direct
	Arpanet gateways are 18 (using 10.0.0.77) and 128.52 (using
	10.3.0.6).  EGP was telling us to use 10.3.0.27 (isi) and
	10.2.0.37 (purdue) respectively.  Fortunately, we were able
	to acquire both of MIT's gateways, so I am simply going to
	list them as secondary gateways.
  Stanford:  It appears that the only reasonable route to network 18
	is stanford-gateway, 10.1.0.11.  Our EGP table was telling
	us to use 10.2.0.37 (purdue-cs-gateway).  We were able to
	acquire the stanford gateway, and have also added them to
	our list of secondary gateways.
Am I doing something wrong?  Here is the relevant portion of our
current configuration file.  I confess that I do not know where the
list of primary neighbors came from.  It seems to have been developed
by one of our systems staff after numerous dealings with the Network
Operations Center trying to diagnose problems.  Note that the gateway
itself is Cisco Systems' commerical version of the Stanford Arpanet
gateway.  It is based on a 68000, with an ACC 1822 card.  This code
has probably not been used many places outside of Stanford, so it is
certainly possible that there are problems left with it.  But it gives
every appearance of doing the right thing.

primary-neighbors 2
egp-neighbor 10.7.0.63 46 primary	! bbn-net2-gateway
egp-neighbor 10.2.0.37 46 primary	! purdue-cs-gw
egp-neighbor 10.0.0.94 46 primary	! wisc-gateway
egp-neighbor 10.3.0.27 46 primary	! isi-gateway
egp-neighbor 10.0.0.25 46 primary	! css-ring-gw (seismo)
egp-neighbor 10.0.0.9  46 primary	! harvard-gw
egp-neighbor 10.1.0.51 46 primary	! sri-prm-gw
egp-neighbor 10.1.0.54 46 primary	! cit-cs-gw
egp-neighbor 10.2.0.9  46 primary	! yale-gw
# talk directly to our friends, since these tend to have bogus routes
egp-neighbor 10.0.0.77 46		! mit-gw, for net 18
egp-neighbor 10.3.0.6  46		! mit-ai-gw, for net 128.52
egp-neighbor 10.1.0.11 46		! stanford-gw, for net 36
# I can't get cmu-gateway to respond to EGP, so do it statically
route 128.2.254.36 10.2.0.14		! cmu-gateway, for net 128.2

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Sun 28 Sep 86 07:10:38-EDT
From:      Dennis G. Perry <PERRY@VAX.DARPA.MIL>
To:        rms@ACC-SB-UNIX.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, gary@BRL-SAGE.ARPA, perry@VAX.DARPA.MIL
Subject:   Re: X.25 on Arpanet
The Arpanet is not yet to PSN6.  Most of it is now running C30s and PSN5.
One site (USC) is still running an old IMP and PSN4.  It will be upgraded
and then the Arpanet can move to PSN6.  PSN7 testing will begin in the
spring.  (The C30s mentioned above should read C/30E)

dennis
-------
-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28-Sep-86 12:08:44 EDT
From:      sy.Ken@CU20B.COLUMBIA.EDU (Ken Rossman)
To:        mod.protocols.tcp-ip
Subject:   Re: ARPANET congestion?


  Over the past three weeks, we have been able to receive mail from ARPANET
  hosts but not able to even establish connections, or when a connection has
  been eventually established, send mail and receive acknowledgements within
  rather generous timeouts to those same hosts...

We're seeing much the same symptoms, though in reverse, and with FTP.  We
are able to make outbound connections to certain sites, but those sites get
rejected for inbound connections to us.  Got me baffled...
-------

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28-Sep-86 13:08:42 EDT
From:      ron@BRL.ARPA (Ron Natalie)
To:        mod.protocols.tcp-ip
Subject:   Re:  Why is the ARPANet in such bad shape these days?

It may not use gateways, but the ping wars between the BBN gateways
impact all net performance as their random behaviour wreaks havoc
with the IMPs virtual circuit set up time.

-Ron

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28-Sep-86 14:48:57 EDT
From:      news@clyde.att.com (Netnews Admin)
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: clyde!cbatt!cbosgd!mark
From: mark@cbosgd.ATT.COM (Mark Horton)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: SMTP, 2600, and the security of mail
Message-ID: <2629@cbosgd.ATT.COM>
Date: 28 Sep 86 15:54:40 GMT
References: <8609280151.AA12210@ucbvax.Berkeley.EDU>
Organization: AT&T Bell Laboratories, Columbus, Oh
Lines: 13
Summary: False SMTP mail is easy to generate, but so is false paper mail

AUERBACH@CSL.SRI.COM (Karl Auerbach) writes:
> A while back I saw a copy of a newsletter titled "2600" which included
> source code demonstrating how one could pretend to be an SMTP engine and
> inject false mail into a host.  Although the code had a few flaws, its
> general structure looked plausable (and short -- about 25 lines of C).

Sure it is.  But that's not surprising.  I can easily generate false
paper mail with a phony return address, and dump it into a paper
mailbox, too.

Nobody ever said EMail was hard to forge.

	Mark

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28-Sep-86 14:55:39 EDT
From:      dave@RSCH.WISC.EDU (Dave Cohrs)
To:        mod.protocols.tcp-ip
Subject:   Re: ARPANET congestion?

There are a few reasons that WISCVM has been hard to reach.  First, our
gateway has recently been converted from an 11/34 to a VAX 750.  The
routes that have been generated since the conversion are not always
very good (EGP problems).  In the long run, the upgrade should be
helpful; Wisc-Gateway passes between 0.75 and 1 million packets dayly.

Second, there have been some PSN connectivity problems recently.  One
or two weeks ago, only one of our three neighboring PSNs was alive.
Also, our PSN goes "not ready" (as seen by watching the lights on the
LH/DH used to connect the gateway to the PSN) once every 20-30 seconds
when the load gets high.  This condition lasts for 1-2 seconds.  This
causes lots of packets to get backed up and/or lost.

Third, the SMTP mailer on WISCVM has gone through some rough times.  I
think the version they are running now is stable.

Finally, WISCVM is physically connected to our Proteon token ring.  The
number of errors on this net are extremely high.  This seems to be a
problem with inferior cables, and not with the Proteon ring itself.
However, the old, bad cables are still in place, so the net still barfs
constantly.  The high error rate causes lots of broken and lost
packets, not to mention the time wasted while the controllers try to
regenerate lost tokens.

Put all of this together, and WISCVM is a tough place to reach.

dave

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28-Sep-86 20:22:47 EDT
From:      karn@MOUTON.BELLCORE.COM (Phil R. Karn)
To:        mod.protocols.tcp-ip
Subject:   forging SMTP

Not only is paper mail also easy to forge, but so is UUCP mail. At least
with SMTP and the internet you have the means to tighten things up if you
wish. You can tell who's actually sending you mail by looking at the address
on the remote socket, notifying the user if it doesn't match the name the
remote sender specifies in the HELO command.  Sendmail, at least, will
mention this in the Received headers, though you have to know what you're
looking at.  Certainly not foolproof, but better than UUCP where you
generally have NO idea who's really calling you on the phone (unless you've
gone whole hog and gotten rid of your generic uucp logins).


Electronic mail is fundamentally a datagram service. You should never trust
isolated datagrams you receive from any network (be they email messages or
IP datagrams) without either some authentication in the message itself or
until you've conducted a three-way-handshake with the remote party to check
for spoofing.  As long as the real person is up and reachable, and the bad
guy hasn't subverted routing, this will suffice.

Phil

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28-Sep-86 20:25:35 EDT
From:      mark@cbosgd.att.com (Mark Horton)
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: cbosgd!mark
From: mark@cbosgd.ATT.COM (Mark Horton)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: SMTP, 2600, and the security of mail
Message-ID: <2632@cbosgd.ATT.COM>
Date: 29 Sep 86 00:25:32 GMT
References: <8609280151.AA12210@ucbvax.Berkeley.EDU>
Organization: AT&T Bell Laboratories, Columbus, Oh
Lines: 13
Summary: False SMTP mail is easy to generate, but so is false paper mail

AUERBACH@CSL.SRI.COM (Karl Auerbach) writes:
> A while back I saw a copy of a newsletter titled "2600" which included
> source code demonstrating how one could pretend to be an SMTP engine and
> inject false mail into a host.  Although the code had a few flaws, its
> general structure looked plausable (and short -- about 25 lines of C).

Sure it is.  But that's not surprising.  I can easily generate false
paper mail with a phony return address, and dump it into a paper
mailbox, too.

Nobody ever said EMail was hard to forge.

	Mark

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28 Sep 86 22:06:24 CDT
From:      Phil Howard  <PHIL%UIUCVMD.BITNET@WISCVM.WISC.EDU>
To:        TCP/IP List <TCP-IP@SRI-NIC.ARPA>
Subject:   False mail
The security of the Post Office depends on its people, and the services
they provide.  The same is true of a network.  The network can provide
better services, such as tell you who REALLY sent the mail, but do you
REALLY trust your network?
-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Sun 28 Sep 86 22:10:54-EDT
From:      Dennis G. Perry <PERRY@VAX.DARPA.MIL>
To:        SRA@XX.LCS.MIT.EDU
Cc:        BILLW@SU-SCORE.ARPA, tcp-ip@SRI-NIC.ARPA, perry@VAX.DARPA.MIL
Subject:   Re: Why is the ARPANet in such bad shape these days?
I can shed a few ray of light (or is that tears) on the Arpanet
congestion problem.  I don't guarentee that I fully understand the issues,
since I believe we have an onion problem.  The E-W problem seems to be
related to the fact that there are only two E-W lines, both running
on average about 60% utilization.  In fact, they occilate between
20 and 90% utilization.  Instability occurs when lines become saturated
and the network starts hunting.  Another congestion problem in the
PSNs is the multi-packet message.  Apparently there is not enough
buffer space to allocate all the buffers needed to support the current
multi-packet message traffic.  The net result is to paralyze the network,
as each PSN quits accepting incomming multi-packet messages.

There may be other problems as well.  We are working on solutions, but
as indicated, it may take a while.

dennis
-------
-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28-Sep-86 23:06:24 EDT
From:      PHIL@UIUCVMD.BITNET (Phil Howard)
To:        mod.protocols.tcp-ip
Subject:   False mail

The security of the Post Office depends on its people, and the services
they provide.  The same is true of a network.  The network can provide
better services, such as tell you who REALLY sent the mail, but do you
REALLY trust your network?

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 1986 23:46-EDT
From:      CERF@A.ISI.EDU
To:        BEAME%MCMASTER.BITNET@WISCVM.WISC.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Peace fullness.
Carl,

consider a licensing arrangement with other, larger vendors - can your
product be used in an OEM setting, augmenting or forming the basis for
new value-added products?

Freeware is not all it's cracked up to be - I am not sure I would worry
too much about university competition. A user who cares about quality
won't have anywhere to turn when university-software breaks. I don't
mean to suggest that software produced in a research environment is all bad,
only that maintenance and documentation often suffer; serious clients are
prepared to pay for this.

Vint
-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 1986 23:50-EDT
From:      CERF@A.ISI.EDU
To:        SRA@XX.LCS.MIT.EDU
Cc:        BILLW@SU-SCORE.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Why is the ARPANet in such bad shape these days?
It's possible the congestion is a consequence not of file transfers
but of short packet interactive traffic. In the past, the C30 limits were
on the packet-per-second side and this should be more true now with
the larger memory C30E installed.

If the network is suffering from too many short packets, there is little
one can do short of installing more IMPS or faster ones (such as C300's).

I do NOT have access to any detailed NOC information so I am speculating
dangerously.

Vint
-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 1986 23:52-EDT
From:      CERF@A.ISI.EDU
To:        WANCHO@SIMTEL20.ARPA
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Do we need another protocol?
Frank,

what about the FTAM (ISO) idea that Marshall Rose suggested? He
proposed putting several of the ISO higher layers above TCP, rather
than inventing yet another set of protocols.

Vint
-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 86 21:44:03 GMT
From:      Unix to Unix Copy <uucp%gatech.csnet@CSNET-RELAY.ARPA>
To:        mod-protocols-tcp-ip%gatech.csnet@CSNET-RELAY.ARPA
Subject:   Submission for mod-protocols-tcp-ip
Path: gatech!cbosgd!mark
From: mark@cbosgd.ATT.COM (Mark Horton)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: SMTP, 2600, and the security of mail
Message-ID: <2629@cbosgd.ATT.COM>
Date: 28 Sep 86 15:54:40 GMT
References: <8609280151.AA12210@ucbvax.Berkeley.EDU>
Organization: AT&T Bell Laboratories, Columbus, Oh
Lines: 13
Summary: False SMTP mail is easy to generate, but so is false paper mail

AUERBACH@CSL.SRI.COM (Karl Auerbach) writes:
> A while back I saw a copy of a newsletter titled "2600" which included
> source code demonstrating how one could pretend to be an SMTP engine and
> inject false mail into a host.  Although the code had a few flaws, its
> general structure looked plausable (and short -- about 25 lines of C).

Sure it is.  But that's not surprising.  I can easily generate false
paper mail with a phony return address, and dump it into a paper
mailbox, too.

Nobody ever said EMail was hard to forge.

	Mark

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Sep-86 04:32:05 EDT
From:      Lixia@XX.LCS.MIT.EDU (Lixia Zhang)
To:        mod.protocols.tcp-ip
Subject:   Re: Why is the ARPANet in such bad shape these days?

The following replies to two internet congestion related messages together.

    Date: Sat, 27 Sep 1986  21:35 EDT
    From: Rob Austein <SRA@XX.LCS.MIT.EDU>
    Subject: Why is the ARPANet in such bad shape these days?
    ......
    The NOC is refering to this mess as a "congestion problem" at the IMP
    level.  The current theory the last few times I talked to the NOC was
    that we have managed to reach the bandwidth limit of the existing
    hardware.  A somewhat scary thought...

Could someone from BBN provide measured network throughput numbers to
convince us that we indeed have hit the HARDWARE bandwidth limit?

					...If this is in fact the case (and
    there is circumstancial evidence that it is, such as the fact that the
    net becomes usable again during off hours), we are in for a long
    siege, since it is guarenteed to take the DCA and BBN a fair length of
    time to deploy any new hardware or bring up new trunks.

Better performance during off hours surely indicates that the problem is
network load-related, but does not necessarily mean that the DATA traffic
has hit the hardware limit -- there is a large percentage of non-data
traffic flowing in the net.  According to the measurement on a number of
gateways, in the week of 9/15-9/21, (as more or less the same for all time)
       43% of all received packets are addressed to a gateway
       48% of all sent packets originate at a gateway
Presumbly these gateway-gateway packets are routing updates, ICMP redirects,
etc.  But why should they take such a high percentage of the total traffic?
Can someone explain to us?

Even for data packets, I wonder if anyone has an idea about how much extra
traffic is generated by the known extra-hop routing problem.  More on this
later.

    ALSO, IF THERE IS ANYBODY FROM BBN WHO KNOWS MORE ABOUT THE PROBLEM
    AND IS WILLING TO SHARE IT, -PLEASE- DO.  IT'S HARD TO MAKE ANY KIND
    OF CONTINGENCY PLANS IN A VACUUM.

    --Rob

I capitalized the sentence, hoping no one would pretend not seeing it.


    Date: Sun, 28 Sep 86 04:48:39 edt
    From: hedrick@topaz.rutgers.edu (Charles Hedrick)
    Subject: odd routings

    I have been looking at our EGP routings.  I checked a few sites that I
    know we talk to a lot.  Our current EGP peers are yale-gw and
    css-ring-gw.  (We keep a list of possible peers, and the gateway picks
    2.  It will change if one of them becomes inaccessible.  This particular
    pair seems to be fairly stable.)  Here I what I found:
    ......
    MIT:  They seem to have 4 different networks.  The ones with direct
	  Arpanet gateways are 18 (using 10.0.0.77) and 128.52 (using
	  10.3.0.6).  EGP was telling us to use 10.3.0.27 (isi) and
	  10.2.0.37 (purdue) respectively...

This is probably caused by the EGP extra-hop problem: if MIT gateways are
EGP neighboring with isi and purdue gateways, all other core gateways will
tell you to go through isi/purdue gateways to get to MIT, even though everyone
is on ARPANET.  This should be a contributor to the cognestion too.

One question is: Can anyone tell us WHEN this extra-hop problem will be
completely eliminated?

Another question is how the stubs select core EGP neighbors; if they all
concentrate on a small number of core gateways, bottlenecks will be created,
because the extra-hop problem says that if a stub gw EGP-neighbors with a
core gw, most traffic to the stub is likely to travel through that core gw
as well.  Hedrick listed their coded-in core EGP gateway candidates in his
message.  Is the same list used by all non-core gateways?  Does someone know
how many stub gateways EGP-neighbor with one core gateway?  Will some
stub-core rebinding help relieve the congestion?

In short, reducing network overhead and fixing some long-standing protocol
problems may be a way to relieve the current poor net performance.

Lixia
-------

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Sep-86 04:51:33 EDT
From:      MRC@SIMTEL20.ARPA (Mark Crispin)
To:        mod.protocols.tcp-ip
Subject:   Re: SMTP, 2600, and the security of mail

Oh wow, big deal, so the little phone phreaks has discovered how to
talk to SMTP servers?  I mean, am I supposed to be impressed with
how bright they are or something?

The Internet protocols are insecure by nature.  A reasonably suspicious
host should always record the host name or IP address of the how which
actually connected to the SMTP server (the real host, not what was
claimed in a HELO).  Some hosts prevent random user programs from
making TCP connections to the SMTP port (I think Multics does), but
basically beyond knowing what host composed the message the end user
should be reasonably suspicious about any mail s/he receives.  After
all, even IP addresses can be faked, although I suspect inpersonating
the IP address of MIT-MULTICS is beyond the technical expertise of
your average phone phreak (it requires actually KNOWING something).
-------

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Sep-86 05:01:23 EDT
From:      MRC@SIMTEL20.ARPA (Mark Crispin)
To:        mod.protocols.tcp-ip
Subject:   Re: odd routings

The funny EGP stuff isn't in cisco's gateway; my TOPS-20 EGP gets the
same sort of garbage.  Fortunately, *most* of the gateways *will*
redirect.

I think the mailbridges are the principle culprit.  Dave Mills can
probably give you a complete description of what is wrong and why.
-------

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Sep-86 07:59:00 EDT
From:      Margulies@SAPSUCKER.SCRC.SYMBOLICS.COM (Benson I. Margulies)
To:        mod.protocols.tcp-ip
Subject:   (none)


    Date: Fri, 26 Sep 86 09:13:04 -0500
    From: mckee@mitre.ARPA

    Marshall Abrams, a Security guru here at MITRE, sent me a copy of the
    following note by Brian Reid.  The note has little to do with TCP and
    IP, but it is instructive to learn how our networks are being used for
    nefarious purposes, and besides, there is a certain lascivious pleasure
    in reading about somebody elses troubles.  H. C. McKee
    --------------------------

    From: reid@decwrl.DEC.COM (Brian Reid)
    Date: 16 Sep 1986 1519-PDT (Tuesday)
    To: Peter G. Neumann <Neumann@csl.sri.com>   [FOR RISKS]
    Subject: Massive UNIX breakins at Stanford

	Lessons learned from a recent rash of Unix computer breakins

   ...


    Brian Reid
    DEC Western Research and Stanford University


As an Ex-B2 security hacker (guess where), I just wanted to point out
that Brian's observations are basically right-on.  There is a big
tension between wanting to be able to run an application without having
the user have to type passwords and having fail-safe network security.
The bottom line is that if you treat an entire network of machines as
one "System" in the orange book sense (no passwords used in between),
then you had better be bloody sure that you have working software on all
of them, and that you monitor activities closely.

caveat manager

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Sep-86 12:03:37 EDT
From:      jsq@ZOTZ.CS.UTEXAS.EDU
To:        mod.protocols.tcp-ip
Subject:   passwords and protection files

Let's remember that if system people are forced to type super-user
passwords across a network in clear text that that's just as bad a
security problem as the permission file setup being complained about.
(Though I suppose the cracker is more likely to need physical access
to the local network.)

Also, the way the crackers got into system people's accounts in this
instance was through tricking badly written privileged programs to
execute out of directories with *public* write permission, without
which the question of whether system people should be able to write
into program directories without typing passwords would have been moot.

I.e., the really bad security problem in a network of 4BSD machines
is privileged programs that don't constrain their search paths and
arguments.

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Sep-86 12:11:01 EDT
From:      tencati@JPL-VLSI.ARPA
To:        mod.protocols.tcp-ip
Subject:   re: ARPAnet "Congestion"

I have a purely academic question.  Is anyone considering the fact that there
are many users on the ARPAnet that are not "official" users?  

When I was in college a few years ago, an arpanet account was very hard to get.
Unless you were faculty, forget it (this was at USC).  

It seems that now there are many more students and people who are not really
using the net for work, as much as an electronic post office.  My host spends
90% of it's time on the ARPAnet sending and receiving INFO-THIS, and INFO-THAT.

Also, I have multiple users receiving the same message from INFO-WHATEVER
as separate TCP connections to my host.  I think part of the congestion mess
is that hosts (like mine) do not utilize "central mailboxes" and do the 
redistribution locally.   

I do feel that the subscribership of the net, and the "official DARPA business"
rules that applied a few years ago have been very lax lately.  Now, most  
universities let their students onto the net, and most hosts with network 
access do the same.

I'm not saying that this should be restricted because the ARPAnet is a useful
tool.  Especially to system managers like myself.  I just think that with the
increased volume of users and the proliferation of INFO lists, the mail traffic
has increased drastically over the past few years, and with the advent of
these new protocols (PC/IP for example), it is becoming easier and easier for
*anyone* to get connected up to the ARPAnet...

I'm not flaming, I just had an extra 2 cents in my pocket...

                                  Ron Tencati
                                  JPL-VLSI.ARPA

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Sep-86 12:32:51 EDT
From:      braden@VENERA.ISI.EDU (Bob Braden)
To:        mod.protocols.tcp-ip
Subject:   Re:  Do we need another protocol?


	
	There is a growing trend in the Army to network Intel 310s running
	Xenix on a fat Ethernet under OpenNet.  When asked why OpenNet instead
	of TCP/IP, the answer most often heard is because OpenNet provides
	inter-machine file and record-level access at the application level.
	
I never understood military politics, but I am curious how the army can
do this in the face of the DoD directive to use TCP/IP.  If they are
in fact justifying it by the requirement for file access, it amazes me
that someone in DCA has not gotten excited about this.
	
	At one time, there was a brief discussion of the possibility of
	extending the FTP definition to allow for record-level access.  It
	seemed to me then that FTP was the wrong place and that an entirely
	new protcol should be defined.  Was this ever done and formally
	recognized as part of the TCP protocol suite?  If not, why not? 
	
The "why not" is easy to answer.  No one eager to fund it.  Protocol
development requires a number of  experienced people to devote quite a
lot of time and attention.  In our community, it also requires a cycle of
experiment and experience with test implementations.  The existing DoD
protocol suite -- IP, TCP, Telnet, FTP, and SMTP -- was developed as
part of a coherent R&D effort programmed and largely funded by DARPA.  The
importance of DARPA's leadership cannot be too strongly emphasized.

Since DARPA's mission is generally long-range research, it is no
longer interested in funding Internet R&D as an end in itself, and little
interest in "small" protocol improvements.  So, a lot of good ideas for
protocols (file access is only one example) have lain in the dust for 10
years.  Every 11.3 months someone brings up the need for file access on
this mailing list, for example.

Another fact has delayed work on the file access problem.  There has been
general agreement for a long time that, as you say, "FTP was the wrong place
and that an entirely new protcol should be defined", but no coherent concept
of what a new protocol should look like. With no terrific ideas, and no
funding interest, it is no wonder that file access has languished for 10 
years (actually 13 -- file access extensions to FTP were first proposed
by John Day in RFC520, dated June 25, 1973!)

Recently there has been a growing interest in the network file system
model, exemplified  by Sun's NFS, as the right way to go for file
access.  There is also an attempt, organized by DARPA and the IAB, to
revitalize Internet protocol research with a variety of funding sources.
The effective agency for this is supposed to be the IAB task forces. So
maybe the time has come to actually slay the file access dragon.

Suppose there were to be some meeting of interested persons to come up
with a draft specification of an Internet standard network file system
(note: NO capital letters!!)  protocol.  Would you have time and travel
funds to attend and contribute?


Bob Braden

   chairperson, End-to-End Protocols task force.
  
	
	

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Sep-86 14:05:12 EDT
From:      swb@DEVVAX.TN.CORNELL.EDU (Scott Brim)
To:        mod.protocols.tcp-ip
Subject:   Why is the ARPANet in such bad shape these days?

Lixia: I've always wondered about figures like that.  Aren't the
overwhelming majority of the gateways on Arpanet also decent-sized
hosts in their own right -- so that much of the traffic in your
figures might be legitimate user traffic?
							Scott

p.s. talk about degenerative congestion -- when the network gets slow
we all start sending gobs of mail back and forth in order to improve
it!

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Sep-86 14:34:19 EDT
From:      Lixia@XX.LCS.MIT.EDU (Lixia Zhang)
To:        mod.protocols.tcp-ip
Subject:   Re: Why is the ARPANet in such bad shape these days?

Scott,

As far as I know, the numbers in my message were from measurements (by BBN)
on the pure forwarding gateways, NOT including hosts.

Lixia

P.S. Also talking about degenerative congestion -- if no one uses the net,
surely no congestion would exist, probably nor would the net itself.
With no congestion, people still send mail daily, though probably on
different subjects.
-------

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Sep-86 15:32:03 EDT
From:      steve@BRL.ARPA (Stephen Wolff)
To:        mod.protocols.tcp-ip
Subject:   ISO Development Environment


    The NSF is committed to international networking standards and to the
timely migration of NSFNET to the full ISO protocol suite.  In support of
this commitment, the NSF will make available at each supercomputer center
on the NSFNET backbone, software which presents an ISO TP4 environment to
higher-level networking code, yet which uses the services of TCP and is
transportable over IP networks such as NSFNET and the ARPANET.

    This ISO Development Environment (ISODE) software will

        a) allow early deployment and use of existing high-level ISO
        networking software that requires a TP4 transport interface, and

        b) permit the development and testing of new ISO-style software
        with the assurance that the development effort will not have been
        wasted when the actual underlying transport and network layers
        switch from TCP and IP to their ISO counterparts.

Thus with the ISODE at each NSF supercomputer center, NSFNET can serve as
an early testbed for ISO-style high-level networking.

    The ISODE package was developed by Marshall T. Rose and Dwight E.Cass
of the Northrop Research and Technology Center and, while not in the public
domain, is made available to the networking community without charge and
without support.  Comments on the package, including bug reports, will be
gratefully received.

                                           Stephen Wolff
                                           Program Director for Networking
                                           National Science Foundation

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Sep 86 15:32:03 EDT
From:      Stephen Wolff <steve@BRL.ARPA>
To:        tcp-ip@sri-nic.arpa
Subject:   ISO Development Environment
    The NSF is committed to international networking standards and to the
timely migration of NSFNET to the full ISO protocol suite.  In support of
this commitment, the NSF will make available at each supercomputer center
on the NSFNET backbone, software which presents an ISO TP4 environment to
higher-level networking code, yet which uses the services of TCP and is
transportable over IP networks such as NSFNET and the ARPANET.

    This ISO Development Environment (ISODE) software will

        a) allow early deployment and use of existing high-level ISO
        networking software that requires a TP4 transport interface, and

        b) permit the development and testing of new ISO-style software
        with the assurance that the development effort will not have been
        wasted when the actual underlying transport and network layers
        switch from TCP and IP to their ISO counterparts.

Thus with the ISODE at each NSF supercomputer center, NSFNET can serve as
an early testbed for ISO-style high-level networking.

    The ISODE package was developed by Marshall T. Rose and Dwight E.Cass
of the Northrop Research and Technology Center and, while not in the public
domain, is made available to the networking community without charge and
without support.  Comments on the package, including bug reports, will be
gratefully received.

                                           Stephen Wolff
                                           Program Director for Networking
                                           National Science Foundation

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Sep-86 16:04:11 EDT
From:      nowicki@SUN.COM (Bill Nowicki)
To:        mod.protocols.tcp-ip
Subject:   Re: Do we need another protocol?


	There is a growing trend in the Army to network Intel 310s
	running Xenix on a fat Ethernet under OpenNet.  When asked why
	OpenNet instead of TCP/IP, the answer most often heard is
	because OpenNet provides inter-machine file and record-level
	access at the application level.

Of course I am biased, but you might want to consider the Sun Network
File System (NFS) protocol.  NFS has the advantage of being 
available on many different machines and operating systems:
MS-DOS, many Unix versions, VMS etc. It is licensed by more than 60
vendors, and based on the IP protocol.  Specifications are public
domain, with fully-supported implementations avilable from several
sources. "Open" Net is quite a misnomer if it is only available from
one vendor.

I know, we should circulate an RFC form of the NFS spec; we are 
working on it.
	
	Bill Nowicki
	Sun Microsystems

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Sep-86 17:55:03 EDT
From:      heilner_k@sitvxb.BITNET (Keith J. Heilner)
To:        mod.protocols.tcp-ip
Subject:   ThinWire Repeaters


  Greetings.  Im looking for vendors who manufacture the ThinWire
(RG58) multiport repeater. I have been able to identify two vendors,
DEC and HP. Digital manufactures a device called a DEMPR and HP
has a four port device. If you know of any other vendors
manufacturing these devices please let me know. Thanks for
your time and help.


                                    Heilner_K@sitvxb.bitnet
                                             or
                                    Heilner_K@sitvxb

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Sep-86 18:17:46 EDT
From:      GROSSMAN@SIERRA.STANFORD.EDU (Stu Grossman)
To:        mod.protocols.tcp-ip
Subject:   Re: SMTP, 2600, and the security of mail

You could (marginally) increase the security of SMTP traffic by having
SMTP servers only accept connections from a 'privileged' remote socket.  

Of course, you now would be required to run yet another privileged daemon
just to ship mail out of your host.

				Stu Grossman
-------

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Sep-86 19:47:40 EDT
From:      phil@amdcad.UUCP (Phil Ngai)
To:        mod.protocols.tcp-ip
Subject:   testing

Sorry about this. Gotta try it.

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Sep-86 21:47:25 EDT
From:      phil@amdcad.UUCP (Phil Ngai)
To:        mod.protocols.tcp-ip
Subject:   Ethernet carrier sense during transmit

Terry Slattery asks "<should> the interface monitor carrier during
transmit?" I have reviewed the 802.3 spec and see no requirement to do
so. (But I still find the language of the spec a bit confusing so I
may have overlooked it.)

The Ethernet 2 spec calls for a CarrierSenseTest process on page 53
which reports if carrier disappears while transmitting or if it never
appears during an entire transmission.  It does not seem to be used.

Is Codenoll without fault? Ethernet assumes a certain maximum
transceiver cable length and a certain minimum signal propagation
velocity. The transceiver is supposed to send to the controller
everything which appears on the cable. One may conclude that carrier
should be present during transmission. The advantage of monitoring the
presence of carrier is that you have more information with which to
perform problem isolation. The Codenoll system alters the parameters
which permit the monitoring of carrier.  As such, calling it
"Ethernet" or "Ethernet compatible" could be misleading and could
cause network failures which are hard to diagnose such as your case.

This is not to say the Codenoll product is bad or that you shouldn't
use it. However, I will be cautious whenever someone proposes breaking
one of the Ethernet configuration rules. If someone does break the
rules and has a failure, then that would be one of the first places to
look at.

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30-Sep-86 00:46:08 EDT
From:      mike@BRL.ARPA (Mike Muuss)
To:        mod.protocols.tcp-ip
Subject:   Re:  ARPAnet "Congestion"

The multiple recipients of mail argument is a bit hard to support,
considering that SMTP allows (and most implementations implement)
all recipient addresses to be presented first, followed by
one copy of the body of the message.  At most 4 IP datagrams
are needed for each additional address (assuming no packet loss).
	-Mike

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30-Sep-86 09:05:44 EDT
From:      leiner@ICARUS.RIACS.EDU
To:        mod.protocols.tcp-ip
Subject:   Re: Peace fullness.

Carl,

The theory is that products developed in the R&D community (read
universities) are not supported adequately for industry to rely on.
Hence the commercial market is for an equally functional product that
is maintained, evolved, supported, etc.

It appears from your note that you don't buy that argument.  I would be
interested in your reaction.


----------

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30-Sep-86 09:55:14 EDT
From:      gross@EDN-VAX.ARPA (Martin Gross)
To:        mod.protocols.tcp-ip
Subject:   (none)


Does anyone have any specific information on y[D[[Dthe problems associated with
Wollongong's implementation of TCP/IP. I've heard it's not user friendly
and has mail and support problems. Any more specific information would be greatly apprecited[D[D[Dated.
               thanks
                      Martin

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Sep 86 09:55:14 edt
From:      gross@EDN-VAX.ARPA (Martin Gross)
To:        tcp-ip@sri-nic.ARPA

Does anyone have any specific information on y[the problems associated with
Wollongong's implementation of TCP/IP. I've heard it's not user friendly
and has mail and support problems. Any more specific information would be greatly apprecitedated.
               thanks
                      Martin
-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30-Sep-86 11:16:02 EDT
From:      john@moncskermit.OZ.AU (John Carey)
To:        mod.protocols.tcp-ip
Subject:   TCP/IP for Burroughs


Does anyone know of a TCP/IP implementation for the B7800 ?

Or have some semi-transportable code written in pascal or algol

						John Carey

						john@monu1.oz@seismo.ARPA

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Sep 86 06:52:09 cet
From:      GLM%IPGUNIV.BITNET@WISCVM.WISC.EDU
To:        TCP-IP@SRI-NIC.ARPA
Subject:   booking TCP-IP mailing list
I wuould like to be registered in the TCP-IP mailing list.
Sincerely
              Gianfranco Galmacci
-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30-Sep-86 12:06:00 EDT
From:      DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer)
To:        mod.protocols.tcp-ip
Subject:   re: ARPAnet "Congestion"


    Date:    Mon, 29 Sep 86 09:11:01 PDT
    From:     tencati@Jpl-VLSI.ARPA

    I have a purely academic question.  Is anyone considering the fact that there
    are many users on the ARPAnet that are not "official" users?  

My opinions:

The INFO-THIS, INFO-THAT problem is a site administration problem.  Your
site allows your users to receive those lists.  I'm not sure there are
programs to prevent people from getting added, but if somebody were
willing to watch the mail logs and "catch" the people, they could be
told to conform to site policy and get themselves removed from the
lists.  One possible solution is to ask all maintainers of major mailing
lists to completely disallow individuals on the lists and require that
all "recipients" be local redistribution lists at the target sites.
This would allow site managers to restrict incoming mail volume by
disallowing their users to receive lists contrary to site policy.
(Sounds facsist, and it probably is.  I don't know if I believe this,
but it is a possibility.)

The "multiple users receiving the same message on separate connections"
problem has two causes.  The major cause is that the sending site
refuses to send the same message to multiple recipients.  I believe this
was the case with previous Unix software; I don't know if it has ever
been fixed.  A second possible cause is lack of local redistribution.

"Official DARPA business" made a lot more sense back in the NCP days.
With the advent of IP, it can be claimed that you aren't connected to
the ARPAnet, you are connected to the Internet.  The ARPAnet is
logically and physically just a very small part of the entire Internet.
The real problem we are seeing is that it is the backbone of the
Internet.  The solution is obvious (I'm assuming the proliferation of
machines will continually increase traffic): put more bandwidth into the
>>Internet<<.  This could be by adding more ARPAnet capability, or
providing other (redundant) paths.  Who pays for it isn't clear, nor is
the choice of technology.

    I'm not flaming, I just had an extra 2 cents in my pocket...

The 2 cent token is moving around the net...

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30-Sep-86 13:13:20 EDT
From:      phil@amdcad.UUCP (Phil Ngai)
To:        mod.protocols.tcp-ip
Subject:   MIT pcip and 3com board

I am trying to use MIT's pcip package with a Compaq Portable Model 2
(286, smaller box) with a 3com etherlink card (3c501? the new short
dumb card). It won't talk to a VAX780 running vanilla 4.2 with an
Interlan NI1010A. It will talk to any Valid workstation (they have
3com interfaces) or a couple of microvax IIs with DEQNAs or a
730/BSD4.2 with an NI1010A.

Network Research's telnet does work, but I was interested in the mon
program that MIT has.

My theories are:

1) It's not a design problem with the NI1010A since the 730 works
2) It's not vanilla 4.2 since the 730 works.
3) It's not the Compaq or the 3c501 since NRC works.
4) It's not pcip since it talks to the 730.
5) It's not the 780 or its particular NI1010A since NRC works to it.

One or more of my theories must be wrong since it does not work.  Any
suggestions?

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30-Sep-86 13:29:00 EDT
From:      gds@SPAM.ISTC.SRI.COM (The lost Bostonian)
To:        mod.protocols.tcp-ip
Subject:   Re: SMTP, 2600, and the security of mail

> From: Mark Crispin <MRC@SIMTEL20.ARPA>
 
> The Internet protocols are insecure by nature.  A reasonably suspicious
> host should always record the host name or IP address of the how which
> actually connected to the SMTP server (the real host, not what was
> claimed in a HELO).

If it is true that all IP implementations enable a server program to
determine the IP address of its peer, then the HELO command, and its
response could be eliminated, which would save us a few bytes.
Certainly the response to the HELO is not necessary, since the server
has already identified itself in the opening greeting.

However, I quote from RFC 821, the explanation for HELO:

	This command and an OK reply to it confirm that both the
	sender-SMTP and receiver-SMTP are in the initial state, 
	that is, there is no transaction in progress and all state
	tables and buffes are cleared.

I do not see that there would be a big problem of detecting the initial
state without a HELO.  Other protocols (FTP, NNTP) don't use it.

--gregbo

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30-Sep-86 14:50:00 EDT
From:      james@ZERMATT.LCS.MIT.EDU ("James William O'Toole, Jr.")
To:        mod.protocols.tcp-ip
Subject:   Re: Peace fullness.


    From: leiner@riacs.edu
    Date: Mon, 29 Sep 86 10:48:13 -0700
    To: <BEAME%MCMASTER.BITNET@wiscvm.wisc.edu>
    Cc: tcp-ip@sri-nic.ARPA
    Subject: Re: Peace fullness. 

    Carl,

    The theory is that products developed in the R&D community (read
    universities) are not supported adequately for industry to rely on.
    Hence the commercial market is for an equally functional product that
    is maintained, evolved, supported, etc.

    It appears from your note that you don't buy that argument.  I would be
    interested in your reaction.

---------

Would anyone mind moving the discussions of commercial vs. university
product requirements to a more appropriate list, and off of tcp-ip?

Thanks.

  --Jim

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30-Sep-86 16:56:58 EDT
From:      smb@ulysses.UUCP (Steven Bellovin)
To:        mod.protocols.tcp-ip
Subject:   Re:  SMTP, 2600, and the security of mail

It's important to remember that SMTP is used on non-TCP virtual circuits.
For example, some hosts within Bell Labs use it over Datakit(r) VCS connections.
You can't do this nearly as easily with FTP because the semantics of some of
the commands (i.e., PORT and PASSIVE) are intimately tied to TCP and IP.  In
general, though, I regard SMTP as a newer and better protocol than FTP, and
as a better model for other protocols.  The concept of looking for the initial
state is a good one; I've often seen half-open circuits get spliced to due
to software bugs (though not on TCP, of course).

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30-Sep-86 17:05:41 EDT
From:      mark@cbosgd.att.com (Mark Horton)
To:        mod.protocols.tcp-ip
Subject:   Re: ARPAnet "Congestion"

>My host spends
>90% of it's time on the ARPAnet sending and receiving INFO-THIS, and INFO-THAT.
>Also, I have multiple users receiving the same message from INFO-WHATEVER
>as separate TCP connections to my host.

If the ARPANET mailing lists do turn out to be the cause of the problem,
I'd like to suggest a possible solution:  Netnews.

Netnews was invented on the UUCP network, where we didn't have the
seemingly "unlimited" bandwidth of the ARPANET.  It had to survive
on 1200 baud dialup lines with UUCP.  Nonetheless, we still manage
to push around about a megabyte/day of traffic over dialups.  (This
figure 1MB/day counts each message only once, not once per recipient.)

It's been possible for UNIX sites on the ARPANET to exchange netnews
via UUCP or SMTP Mail for years now.  Even these primitive methods
have many benefits (in our perception) over mailing lists:

(1) Only one copy of each message is sent to each system (although
we do sometimes have redundant links, sending redundant copies, for
extra reliability, duplicates are weeded out using Message-ID so
the users rarely see a duplicate.)

(2) Error messages don't go to the sender, they automatically go to the
person responsible for the link in question.

(3) Users see their "news" separately from their "mail" (unless they
want their news mailed to them, which is also possible but inefficient)
which means that mail will have higher priority than news for most users.
(By "news" I mean what's considered "mass mailing" on the ARPANET.)

(4) Users get other benefits, such as grouping of subjects and discussions,
and never have to go through a moderator or list maintainer to start
reading or posting to a newsgroup.

(5) Only one copy is kept on each machine's disk, rather than one copy
in each user's mailbox.

(6) News is automatically expired after two weeks (or whatever it's
locally configured to) so the disk usage is fairly constant; still,
users can join into the middle of a discussion and immediately have
two weeks worth of "back issues".

(7) Cross-posting allows a discussion to go on in multiple forums
(e.g. header-people and namedroppers) while sending only one copy
of each message around, and each user sees each message only once.

(8) By batching news, there is less transport overhead.  Each hour,
a host may accumulate all new news and send it to its neighbors.

(9) All news goes through the same pipe, so it's easy to gather
statistics about traffic volume, both total and per-group.  We
have also recently found a way to measure readership.

Even better methods are evolving.  NNTP allows transfer of netnews
efficiently over TCP, and allows one machine to serve as a remote
disk so you don't need a copy of netnews on every machine.  Stargate
will allow you to get moderated news from any cable TV service that
carries WTBS, or any satellite dish that can get WTBS.

The major problems with using netnews on the ARPA Internet have
historically been

(1) The implementations run under UNIX, and nobody has written one
for TOPS 20.  (But I've heard rumors of an NNTP compatible TOPS 20
implementation under development.)

(2) Many users prefer to keep their mail and news lumped together
in their mailbox.  (I can't understand this, but I guess it's a
religious issue, like which editor you use.)  We have several
user interfaces for netnews, optimized to reading large volumes
of traffic, and encouraging good manners among the posters.

Usenet is the network currently carrying netnews, and includes large
chunks of UUCP as well as many ARPA Internet Usenet hosts.  (If the
host runs UNIX and is a major Internet host, chances are good it's
on Usenet, although representation is light at some of the senior
ARPANET universities like MIT, CMU, and Stanford.)  Some fraction of
the ARPA mailing lists are gatewayed into Usenet newsgroups, including
the TCP-IP list (I'm posting this as a Usenet message, and it will be
transparently be sent to the moderator.)

Usenet is a network, netnews is a technology.  If mailing lists are
congesting the ARPANET, it may be possible to use the netnews technology
to carry the same amount of traffic at far less cost to the network,
simultaneously making the mailing lists more widely available and
cutting down on the workload of mailing list maintainers.  (Most unmoderated
Usenet newsgroups don't have anyone "in charge" of them, they run themselves.)

Let's see where the load is really coming from; if mailing lists turn
out to be the culprit, I offer netnews as an alternative to cutting back.

	Mark

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30-Sep-86 17:55:26 EDT
From:      ron@celerity.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Peace fullness.

In article <8609280050.AA11782@ucbvax.Berkeley.EDU> BEAME@MCMASTER.BITNET writes:
>
>
>   Speeking as the president of one of those companies out there trying
>to make a living by selling TCP/IP code for PC's ...
>
>   As a developer it IS my responcibility to produce a product that my
>clients desire and to develop new features and approches.
>
>   I have done just that, but I am afraid to market it. Why ? Because the
>Universities will produce a public (or very cheap) version and have their
>name behind it! All my time, effort and MONEY will be wasted.
>
>   What can I do ? Get a Patent ? That takes years, and the protocols might
>have changed by than.
>
>   I ask you, what would you do if you wanted to sell such a product.
>(Remember were a very small company)
>
>              - Carl Beame,
>                President
>                Beame & Whiteside Software Ltd.
>                259 Fiddler's Green Rd.
>                Ancaster, Ontario, Canada.

There seems to be no way to avoid (for large or small companys) doing
market research before doing a product development. I don't even think
that patents would solve your problem. They certainly would work if you
were trying to protect an original invention, but anything that is in
the public domain as much as TCP/IP is, well, forget it.

A possible device you could use to market a product for which there is
competition in the public sector, is to do the job better than the
public version. Presumably, you are using designers and programmers
that are professional (not a wild-eyed bunch of unmanagable undergrads
;-) and you will provide support and subsequent product updates and
DOCUMENTATION that are frequently not available for public domain
software. An example of this strategy being sucessfully employed is the
Ingress DBMS.

I guess I do feel a little sorry for you, your tax dollars being used
to subsidize your competition and all. Kind of makes you want to go sell
real estate or something.


R. L. (Ron) McDaniels

CELERITY COMPUTING . 9692 Via Excelencia Way . San Diego, California . 92126
(619) 271-9940 . {decvax || ucbvax || ihnp4 || philabs}!sdcsvax!celerity!ron
"Yes, my Precious. . . we hates them socket(2)eses!"

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30-Sep-86 17:56:15 EDT
From:      ehrlich@psuvax1.BITNET
To:        mod.protocols.tcp-ip
Subject:   BOOTP daemon for BSD 4.x


        I would appreciate hearing from any who has or knows of a daemon
        for BSD 4.x that implements the BOOTP protocol.

        Thanks in advance.

--Daniel Ehrlich
===============================================================================
CSNET:    ehrlich@penn-state.csnet      USPS: The Pennsylvania State University
INTERNET: ehrlich@psuvax1.psu.edu             Department of Computer Science
UUCP:     ...!ihnp4!psuvax1!ehrlich           334B Whitmore Laboratory
BITNET:   ehrlich@psuvax1.bitnet              University Park, PA   16802
                                        BELL: (814) 863-1142
"The sky is blue so we know were to stop mowing."  Judge Harry Stone
===============================================================================

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Sep 86 17:56:15 edt
From:      ehrlich%psuvax1.bitnet@WISCVM.WISC.EDU
To:        info-vax@brl.arpa
Cc:        tcp-ip@sri-nic.arpa
Subject:   BOOTP daemon for BSD 4.x
        I would appreciate hearing from any who has or knows of a daemon
        for BSD 4.x that implements the BOOTP protocol.

        Thanks in advance.

--Daniel Ehrlich
===============================================================================
CSNET:    ehrlich@penn-state.csnet      USPS: The Pennsylvania State University
INTERNET: ehrlich@psuvax1.psu.edu             Department of Computer Science
UUCP:     ...!ihnp4!psuvax1!ehrlich           334B Whitmore Laboratory
BITNET:   ehrlich@psuvax1.bitnet              University Park, PA   16802
                                        BELL: (814) 863-1142
"The sky is blue so we know were to stop mowing."  Judge Harry Stone
===============================================================================
-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1-Oct-86 01:15:19 EDT
From:      ROMKEY@XX.LCS.MIT.EDU (John Romkey)
To:        mod.protocols.tcp-ip
Subject:   Re: SMTP, 2600, and the security of mail

The whole idea of "privileged" sockets loses. There are lots of machines
out there on the network right now which don't even have the concept
of privileges in their operating system: IBM PC's. There's really
very little you can do to stop someone with network code on an IBM PC
from sending whatever they want, from whatever socket they choose, even
whatever IP ADDRESS they wish to appear as, to the net. (of course, if
they choose a sufficiently off-the-wall IP address then no packets
will ever make it back to them)

If you object to the idea of IBM PC's, then just think about all those
single user Unix work stations that are appearing nowadays around the
Internet. You can't really depend on their "owners" (most of whom probably
know the root passwords) being trustworthy.

I think we might be better off if no one would even suggest that
privileged sockets have any role to play in the security of today's
Internet. They only really provide a very thin illusion of security.
					- john romkey
-------

END OF DOCUMENT