Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!genrad!decvax!ucbvax!A.ISI.EDU!LYNCH
From: LYNCH@A.ISI.EDU.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: My Broadcast
Message-ID: <8704061653.AA16642@ucbvax.Berkeley.EDU>
Date: Mon, 6-Apr-87 12:35:16 EST
Article-I.D.: ucbvax.8704061653.AA16642
Posted: Mon Apr  6 12:35:16 1987
Date-Received: Wed, 8-Apr-87 04:36:43 EST
References: <1987.4.5.16.35.48.Rudy.Nedved@h.cs.cmu.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 26
Approved: tcp-ip@sri-nic.arpa

Well,  Looks like we have (re)uncovered a can of mixed worms here.
The example I gave was definitely in the "security" area and you
should note that the method used to get it fixed involved exactly
one "outside site", the site of the author of the operating system.

The example of the broadcast that went "astray" is more accurately
described as an "integrity" issue.  With integrity one is concerned
that the "system/facility" stay alive and functional under both
normal use and many forms of abnormality.  What we are learning
with some of the facilities for message sending is that our
"internet" is very highly connected and even can be considered
to be too highly connected for some forms of (even innocent)
misbehavior.  How do we benefit from what we have learned thus far?

Dennis has suggested that one of the manufacturers fix some code
and/or defaults and/or procedures in its releases.  I'm sure other
manufacturers can do likewise should they also exhibit the
same misfeatures in their offerings.  But the big thing that we
need to understand is that we do not understand how to live
in these highly connected internets yet.  Much more research needs
to happen in the area of intergroup interactions.  And much more
tolerance needs to be exhibited towards those who are probing
the edges of all this.

Dan
-------