The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      01-Jan-87 01:48:31-UT
From:      mills@huey.udel.edu
To:        tcp-ip@sri-nic.arpa, nsfnet@sh.cs.net
Subject:   Ask not for whom the chimes tinkle
Folks,

Every year it's the same - I forget UT midnight comes five hours before the
ball drops in Times Square. For an hour and sixteen minutes after the hoot
and holler in Trafalgar Square at least four radiofuzz timetellers still
squawked yesteryear. DCN1, UMD1, FORD1 and NCAR springs have now been
rewound to 1987 and all you guys can forget those whopping disk-usage
refunds. Thanks to Hans-Werner Braun, who reminded me of my annual first
duty of the new year and annual first resolution to figure out how to
avoid paw to keyboard in the absence throughout the world, as far I know,
of a highly reliable electronic way to find out what year it is.

Dave
-------
-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 1987 12:26-EST
From:      CERF@A.ISI.EDU
To:        mills@HUEY.UDEL.EDU
Cc:        tcp-ip@SRI-NIC.ARPA, nsfnet@SH.CS.NET
Subject:   Re: Ask not for whom the chimes tinkle
Dave,

If you ran all clocks in universal time (GMT) they would all switch years
at the same time (Einstein, forgive me). If you need advice as to the time
and date according to a given time zone, apply the appropriate conversion
locally (at the point of query) when the GMT answer comes back. That's
what we finally did with MCI Mail to avoid confusion in our accounting
system - everything was GMT internally. Would that help your problem?

Vint
-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1-Jan-87 15:34:05 EST
From:      Mills%udel.edu@LOUIE.UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Ask not for whom the chimes tinkle

Vint,

Every single clock I can reach out and touch, and some others I can bully,
ALWAYS tick UT. Fuzzballs would never come within two picofarads of anything
local or I would pull their ears off. In fact, there are a few people out
there that get mad at me for this hard-line position. Now I can tell my
buddies MCI Mail came to the same conclusion. Goodie.

The problem occurs because the radio formats do not include the year; so, from
first principles a Rip van Winkle waking up with no prior information doesn't
know the year. Yes, thee have been numerous suggestions to avoid the problem,
but they all use previous state in the file system, collective buddies and
so forth. In principle, all it takes is one grand HEMP and the chimes would
tinkle for us, no matter who asks.

Dave

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2-Jan-87 05:25:58 EST
From:      hedrick@TOPAZ.RUTGERS.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Becomming an Internet site

Authorization is required to connect a network to the Arpanet, whether
the connection is direct or indirect.  More paperwork and time is
needed to connect directly to it, but you must register even if you
use a friendly local University as an intermediary, or connect to some
other network with indirect connections to the Arpanet (e.g. NSFnet).
Note that even such indirect connections require your network to
appear in the Arpanet's routing tables.  I.e. some Arpanet gateway
must advertise your network to the core gateways using EGP.

Note that it is not just your network that must be authorized to
connect to the Arpanet.  Individual users who use the Arpanet must be
using it for authorized purposes.  So when you connect a network to
the Arpanet, even indirectly, you are accepting the responsbility to
monitor your users and make sure that their use is appropriate.

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2-Jan-87 13:32:07 EST
From:      farber@HUEY.UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Becomming an Internet site

I would suggest that if your company is engaged in Computer Science 
Research or the support of it, you consider joining many other industrial
firms in becoming members of CSNET.

Dave

Conflict: I Chair the CSNET Exec Committee

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2-Jan-87 14:45:09 EST
From:      mckee@MITRE.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Ask not for whom the chimes tinkle

>Every single clock I can reach ... never come within two picofarads ...

Come now Dave - the capacity of a clock that ticks farads is bound 
to have an erratic charge; no doubt you meant two mho milli-henries;
or is this the sort of pedantic nonsense up with which you will not put.

You mentioned the lack of year information in the radio format; what
about date info?  Do your fuzzballs handle years divisible by 
4, 40, and 400; or must we place our (recently abused) trust in the 
clock czar?

Regards - Craig

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2-Jan-87 15:12:37 EST
From:      Mills%udel.edu@LOUIE.UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Ask not for whom the chimes tinkle

Craig,

Your current is clear. Millsiamps it is and don't resistor or you'll be
rectified. I know when my grid leaks anyway.

Fuzzballs leap the years properly, but sometimes don't leap the seconds, as
you might know from my experiments previously reported to this list. Time
and day-of-year are reliably reported in both US (WWV, WWVH, WWVB) and UK
(MSF) broadcasts, but not the year. A "daylight-time" bit is now included
(which I consider useless to dangerous), but not advance notice of a
leap-second (see NTP in RFC-958). We gotta infiltrate more computer
hackers into NBS.

Scenario: Martian comes to Earth, asks the year. Whatever you say, he
says he doesn't believe you. Think about it. Did Julian's astronomers get
the rate right but the date wrong? Think about that, too, and mumble a
prayer to the Axioms Peano.

Dave

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2-Jan-87 15:19:18 EST
From:      UUCP@seismo.CSS.GOV@vu-vlsi.UUCP
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: vu-vlsi!cbmvax!rutgers!ames!ucbcad!ucbvax!news@seismo.CSS.GOV@sun.UUCP
From: news@seismo.CSS.GOV@sun.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Submission for mod-protocols-tcp-ip
Message-ID: <8612290824.AA11689@sun.Sun.COM>
Date: 29 Dec 86 08:24:26 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 31
App@wved: tcp-ip@sri-nic.arpa

Path: sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: More NFS discussion
Summary: OK, what *about* "tmpfile"?
Message-ID: <10850@sun.uucp>
Date: 29 Dec 86 08:24:25 GMT
References: <8612242233.AA06278@cbosgd.MIS.OH.ATT.COM>
Sender: news@sun.uucp
Lines: 20

> In all this discussion of ways that NFS doesn't quite meet the
> "UNIX semantics" (this means "UNIX System V semantics", since
> UNIX is a trademark of AT&T and AT&T considers only its own
> releases to be UNIX) there is one more gotcha lurking.
> 
> The traditional implementation of (tmpfile) is to make up a name
> in /tmp, create the file, keep it open, and unlink it.  This works fine
> on System V and 4BSD.  It probably fails on VMS/Eunice.  As far as I'm
> aware, it also fails when /tmp is NFS mounted on a remote system.

Well, you aren't aware of how the Sun NFS implementation works; it works
just fine when "/tmp" is NFS mounted on a remote system.  (I just tried it,
with "tmpfile" - "tmpnam", actually - modified to use an NFS-mounted file
system.)  The local kernel knows that the file is open, and instead of
unlinking it, it renames it to a temporary name and deletes the temporary
file when the last program on the client that created it finishes with it.

Yes, this will fail if a process on a *different* machine unlinks it.
However, it's difficult for another such process to unlink it under UNIX,
since it only has a name for a very short time.

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2-Jan-87 15:19:59 EST
From:      UUCP@seismo.CSS.GOV@vu-vlsi.UUCP
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: vu-vlsi!cbmvax!rutgers!ames!ucbcad!ucbvax!SAPSUCKER.SCRC.SYMBOLICS.COM!Margulies
From: Margulies@SAPSUCKER.SCRC.SYMBOLICS.COM (Benson I. Margulies)
Newsgroups: mod.protocols.tcp-ip
Subject: Submission for mod-protocols-tcp-ip
Message-ID: <861229093712.6.MARGULIES@REDWING.SCRC.Symbolics.COM>
Date: 29 Dec 86 14:37:00 GMT
References: <8612291349.AA17416@seismo.CSS.GOV>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 41
App@oved: tcp-ip@sri-nic.arpa


	Date: 29 Dec 86 08:32:06 GMT
	From: sun!news@seismo.CSS.GOV

	Path: sun!gorodish!guy
	From: guy%gorodish@Sun.COM (Guy Harris)
	Newsgroups: mod.protocols.tcp-ip
	Subject: Re: Need information on NFS
	Summary: Pathname syntax/semantics and file formats are two separate issues.
	Message-ID: <10851@sun.uucp>
	Date: 29 Dec 86 08:32:06 GMT
	References: <8612250637.AA05517@seismo.CSS.GOV> <861225195214.5.MARGULIES@REDWING.SCRC.Symbolics.COM>
	Sender: news@sun.uucp
	Lines: 15

	> Consider TOPS-20 directory structure, VM/CMS mini-disks, file system
	> that permit "/" characters in their filenames, or especially file
	> systems (like VMS and VM/CMS) that have structured (non-byte stream)
	> files.  None of them map very quietly into a hierarchical set of
	> directories separated by "/" characters, and there are more and harder
	> where they came from.

	The problem with VMS pathnames has nothing whatsoever to do with the fact
	that some operating systems keep file attributes like file format around and
	that a certain level of those OSes (not the kernel, in the case of VMS, but
	RMS) imposes a certain interpretation of the bytes in the file, based on
	these file attributes, on its clients.  Those are separate issues; you can
	build a system with a VMS-style pathname syntax but with no interpretation
	of the file's contents below user-mode code, or a system with UNIX-style
	pathnames but with VMS-style file attributes handled by something like RMS.

    Indeed. Perhaps if I changed the last sentence to:

      "None of them map very quietly into a hierarchical set of directories
    separated by "/" characters where all of the files are expected to be
    simple vectors of 8bit bytes"

    you would like it better.  They are separate problems.  They are both
    hard.

 

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 1987 15:27-EST
From:      CERF@A.ISI.EDU
To:        Mills%udel.edu@LOUIE.UDEL.EDU
Cc:        mills@HUEY.UDEL.EDU, tcp-ip@SRI-NIC.ARPA nsfnet@SH.CS.NET
Subject:   Re:  Ask not for whom the chimes tinkle

AAAAAAAGGGGGHH!

I'm astonished. Didn't anyone at NBS ever hear of date-time groups for
uniqueness? Or should I be blaming some other (date-time) group?

Vint
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2-Jan-87 17:38:11 EST
From:      leiner@ICARUS.RIACS.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Becomming an Internet site

JOhn,

Actually, permission is not needed from DARPA in order to become an
internet site; only to have your traffic (in either direction) pass over
networks supported by DARPA.  What is needed is to be incorporated into
the internet addressing structure, which means basically obtaining a
network number.

Barry

----------

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2-Jan-87 21:26:09 EST
From:      Mills%udel.edu@LOUIE.UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Ask not for whom the chimes tinkle

Vint,

International clocks are coordinated by the BIH in Paris, so I suppose they
might take a timewarp or to of blame; however, my quarrel is only with
the shadowy figures who design the radio-time broadcast formats. Originally
we could blame the Inter_Range Instrumentation Group (IRIG), which coordinated
the Atlantic Missile Testing Range long, long ago when WWV was in Beltsville,
MD, and kept time with eight buried crystal oscillators. The original WWV
format as developed by the IRIG and still used, provides 54 bits per minute,
but I count only 27 being used in the WWV format (one less in the WWVB format).
The day of year takes 23 bits (in BCD!), the UTC-1 correction three and the
daylight indicator one. The 23 bits are coded minutes/hours/days in BCD
fergawshakes, and this in our age of microcomputers.

Now, if the slate could be wiped clean, it should not be hard to include the
year, leap-second alert, propagation forecasts, UTC-1 correction, daylight
indicator (ugh) and probably lots more, while encoding the whole thing in
the same 54-bit frame with some error-correction info to reduce the vulnerability
to time-warps, as every Heath clock owner knows.

Dave

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Sat, 3-Jan-87 20:58:17 EST
From:      LYNCH@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Ask not for whom the chimes tinkle

Dave,  Your IRIG time story brings back gorry memories for me.
I was a "computor" in the USAF about 20 years ago and the reason
we had those ghastly BCD encodings of time was because we humans
had to read that time data manually when in debug or panic mode.
Have you ever tried to look for a specific time, like 3 PM, in 
binary milleseconds since anything???  We were grateful for
that encoding scheme even though we knew it was wasteful.

The bit about not being able to note the change of year was also
amusing.  Because I was designing a missile tracking system and
we did not think the enemy would give us a grace period on New Year's
Eve, we had to put in logic to snake around that wraparound so we
could track the suckers through the (last?) champaigne toasts.
And, oh yes, we even tested that code...

Dan
-------

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 1987 20:58:17 EST
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        Mills@HUEY.UDEL.EDU
Cc:        tcp-ip@SRI-NIC.ARPA, nsfnet@SH.CS.NET, lynch@A.ISI.EDU
Subject:   Re:  Ask not for whom the chimes tinkle
Dave,  Your IRIG time story brings back gorry memories for me.
I was a "computor" in the USAF about 20 years ago and the reason
we had those ghastly BCD encodings of time was because we humans
had to read that time data manually when in debug or panic mode.
Have you ever tried to look for a specific time, like 3 PM, in 
binary milleseconds since anything???  We were grateful for
that encoding scheme even though we knew it was wasteful.

The bit about not being able to note the change of year was also
amusing.  Because I was designing a missile tracking system and
we did not think the enemy would give us a grace period on New Year's
Eve, we had to put in logic to snake around that wraparound so we
could track the suckers through the (last?) champaigne toasts.
And, oh yes, we even tested that code...

Dan
-------
-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Sat, 3-Jan-87 21:43:20 EST
From:      tim@cgl.ucsf.edu@hoptoad.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: More NFS discussion

Two comments on PC NFS.

A server side is not made impossible by the OS lack of support for
process-based multi-tasking.  If TOPS is any indication, acceptable
performance is possible with a background server design.

Second, floppies were mentioned.  Floppies are irrelevant.  The average
MS/DOS machine these days has a ten or twenty megabyte internal hard disk,
parts of which might often be made public.
-- 
Tim Maroney, Electronic Village Idiot
{ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp)
hoptoad!tim@lll-crg (arpa)

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5-Jan-87 15:23:41 EST
From:      PERILLO@SRI-NIC.ARPA (Francine Perillo)
To:        mod.protocols.tcp-ip
Subject:   Contacting the NIC

To Charles Bacon:

The DDN Network Information Center (NIC) edited and distributes the
DDN Protocol Handbook (3 vols.).  (The previous sentence uses both
the "official" name of the group and the complete title of those
big books.)  SRI is the official name of the company that houses the
NIC.  

To Jeff Siegal:

For information about DDN or Internet access, contact the NIC at
1-800-235-3155 or 415-859-3695.  Our information mailbox is 
NIC@SRI-NIC.ARPA.

-Francine  /NIC
-------

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6-Jan-87 11:08:56 EST
From:      whna%cgcha.UUCP%cernvax.BITNET@WISCVM.WISC.EDU (Heinz Naef)
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: cgcha!whna
From: whna@cgcha.UUCP (Heinz Naef)
Newsgroups: mod.protocols.tcp-ip
Subject: Please put me on the tcp-ip mailing list
Message-ID: <202@cgcha.UUCP>
Date: 6 Jan 87 16:08:54 GMT
Organization: CIBA-GEIGY AG, FO/WIRZ/WRZ, Basel, CH
Lines: 7

Please enter the following symbolic mail address into the distribution list
for TCP/IP related mail/news:

        tcpip@cgcha.UUCP

Thanks and best regards,
Heinz Naef

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Jan 87 07:34:16 EST
From:      jqj@gvax.cs.cornell.edu (J Q Johnson)
To:        arpa.tcp-ip
Subject:   Authentication (was: No more NFS flames)
In his message earlier this week Joe Pallas did, I think, an excellent
job of clearing the air on SUN NFS.  I would, though, be interested in
people's comments on the issues of authentication raised during the
discussion.  I had argued that authentication was necessary at the NFS
(or RFS, or whatever) level, not just in the transport mechanism (RPC;
Note that this is the transport *mechanism* required by SMI for SUN
NFS, but that it is not, of course, in the ISO transport *layer*).
Brad Taylor disagreed, arguing that it was natural to place in the RPC
layer those things (presumably including authentication) common to
different RPC applications in the common RPC code.

My position is that in a layered network protocol suite ANY layer is a
candidate for some form of authentication or credentials.  As an
example, any file-specific authentication in a remote file system (e.g.
an encryption key, or an account string [perhaps password protected] to
be associated with a file) is necessarily idiosyncratic to the remote
file system, and hence is arguably a proper part of the RFS rather than
the underlying RPC layer.

Arguing the kinds of authentication appropriate to other layers takes
me further out on a limb, but as a first attempt:
  physical layer	should allow verification of sender's physical
     (e.g. Ethernet)	address
  network/datagram	should allow verification of sender's logical
     layer (e.g. IP)	address
  transport/stream	should allow verification that all component
     layer (e.g. TCP)	packets in fact are part of the stream
  session layer		should allow verification of user ids, etc.
			i.e. traditional "login"-style authentication
  application layer	whatever...

It should be noted that the TCP/IP suite is woefully inadequate in
providing the kinds of authentication I'd like to see possible at the
lower levels of a protocol suite.  It is trivial for an intruder with
access to the transmission media to interject false traffic, masquerade
as any host, and even insert data in the middle of a TCP stream (though
that implies that the receiver will probably get 2 different IP packets
with the same sequence number, which might set off an alarm in some
implementations...).  In the days when most IP traffic was restricted
to the ARPAnet this was not a problem but nowadays who knows by what
devious paths my packets may wend their way across country?

Note that their are provisions for "security" at the IP level; so far as
I can see they are totally useless.  What I have in mind might (?) be
implemented as an (optional) public-key encryption of a packet checksum,
where the public key was distributed along with the network address of
the destination by the domain name server.
-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 87 15:18 PST
From:      Tom Perrine <Perrine@LOGICON.ARPA>
To:        mills@huey.udel.edu
Cc:        tcp-ip@sri-nic.arpa, Tom Perrine <Perrine@LOGICON.ARPA>
Subject:   Re: Ask not for whom the chimes tinkle
WARNING! TIME WARPS AHEAD!

Well the chimes sure tinkled for us!  On Thursday 8 Jan (1987 A.D.) at
about 1400 PST we queried DCN1 as we booted our PWB UNIX system and
received a 1986 date stamp!  (Gee Mr.  Peabody, set the Wayback machine
for 1987!)

Further investigation shows that DCN6 and GW.UMICH.EDU are also stuck
in a time warp.  UMD1 seems to be the only un-nostalgic clock.
(FORD1 was not reachable.)

For now, everyone better keep one eye on the Timex, and another on the
packets, and another on the Seiko!

Tom Perrine
Logicon - OSD


p.s.  What (Where?) is the previously mentioned NCAR clock/site?  I
can't find a net address for this place in the NIC host table.

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8-Jan-87 18:18:00 EST
From:      Perrine@LOGICON.ARPA (Tom Perrine)
To:        mod.protocols.tcp-ip
Subject:   Re: Ask not for whom the chimes tinkle

WARNING! TIME WARPS AHEAD!

Well the chimes sure tinkled for us!  On Thursday 8 Jan (1987 A.D.) at
about 1400 PST we queried DCN1 as we booted our PWB UNIX system and
received a 1986 date stamp!  (Gee Mr.  Peabody, set the Wayback machine
for 1987!)

Further investigation shows that DCN6 and GW.UMICH.EDU are also stuck
in a time warp.  UMD1 seems to be the only un-nostalgic clock.
(FORD1 was not reachable.)

For now, everyone better keep one eye on the Timex, and another on the
packets, and another on the Seiko!

Tom Perrine
Logicon - OSD


p.s.  What (Where?) is the previously mentioned NCAR clock/site?  I
can't find a net address for this place in the NIC host table.

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8-Jan-87 19:16:51 EST
From:      Murray.pa@XEROX.COM
To:        mod.protocols.tcp-ip
Subject:   What's a repeater, bridge, router, or gateway?

From Rudy:
	I have yet to hear a solid definition that is not disputed by someone
	for the terms "gateway", "router", "repeater" and "bridge".

It's mailbox housecleaning time. I don't remember seeing a response to
this corner of Rudy's message, so here is my 2 cents worth.

I believe that the standards groups (ISO, ANSI, IEEE...) have converged
upon the following meanings. This is an informal description, and
slanted towards ethernets, but the translation to other hardware should
be simple. In order of increasing complexity:

Repeater: A box that copies each bit of a packet from one segment of a
network to another. Thus if you put a scope on several chunks of coax
connected by repeaters, you would observe the same packet at the "same"
time if you are willing to ingore timing jitter up to several bit times.
(On an ethernet, a repeater also has to copy the collision signal in the
reverse direction.)

It's possible to pry a repeater into 2 halves and connect them somehow,
say with a pair of fibers. This gives you wider goegraphical coverage.
The ethernet specs, for example, left room in their timing budget for
1000 meters of fiber inside the repeaters.

Bridge: A box that selectivly copies raw packets from one one network to
another network of the same type. This is reasonable to do, at least in
theory, on an ethernet because the first few bytes of a raw ethernet
packet contain the destination address, so a bridge that's watching all
the traffic on an ethernet can deduce "Aah, host 12345657 is sending
packets on segment 13, so it must be connected there and I should copy
packets for it from other segments over to segment 13" and add that
entry to its tables.

There are several interesting ideas in bridges. First, the copy is
selective so traffic on each section of the network is reduced from what
would happen if you used repeaters rather than bridges. Second, raw
packets get copied so this scheme works for all higher lever protocols,
even ones that haven't been invented yet. Third, since whole packets get
copied, the geographical or timing constraints of the basic physical
network can be extended.

Bridges can be split just like repeaters. Because of the filtering
action, it might make sense to connect a pair of ethernets (10 megabits
per second) with a (slower) T1 line (1.5 megabits per second). In
theory, connections like this are "invisible" to the software on all the
machines on the network so everything should just works fine, and
probably does when things are lightly loaded. This isn't the place to go
into the complications. Dave Mills has already contributed several war
storys to TCP-IP.

Router: A box that forwards packets of a particular protocol type (eg
IP) from one logical network to another. The networks may be be of
different physical types - eg ethernet to ring or arpanet to a phone
line. (They can be the same - eg ethernet to another ethernet on a
different floor.) In order to forward a packet, a router looks inside
the packet to find the destination address, then consults its routing
table which is normaly kept up to date by having routers talk to
eachother via some routing protocol. Note that it's quite reasonable to
have a multilingual router - a single machine that forwards packets for
several protocol types - eg IP, Pup, and Chaos.

Gateway: A box that translates from one protocol family to another, for
example from Asyc RS232 connected to a dumb terminal to IP/TCP/Telnet,
or from IP/TCP/SMTP mail to (Xerox) Pup/Grapevine mail.

I think that "gateway" is the word responsible for most of the
confusion. The Arpanet community (as well as the research corner of
Xerox) uses "gateway" to mean what much of the rest of the world would
call a "router". When I am being careful, I say "router", "packet
gateway" or "mail gateway" in hopes of getting the correct binding.

"Bridge" also contributes some confusion since several RFCs and messages
refer to "mail bridges". I usually ignore that aspect and don't get
burned very often.

Another way to look at this mess is "What's a network?" In the ethernet
world, a physical segment is a single length of coax. A physical network
is several segments connected by repeaters.

A logical network makes sense only relative to a particular protocol,
and has a single network number. Logical networks have network numbers.
Usually there is a one-to-one mapping between physical network and
logical network, but things get blurred by subnets and bridges. An
internet is a collection of logical networks (all speaking the same
protocol) connected via routers.

We also need a term for a clump of internets connected by, for example,
mail gateways. I'd probably call it a metanet, but I don't think that
term is in common usage.

(If I get enough/any corrections, I'll collect and summarize.)

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8-Jan-87 21:36:52 EST
From:      Hans-Werner_Braun@um.cc.umich.edu
To:        mod.protocols.tcp-ip
Subject:   Re: Ask not for whom the chimes tinkle

Tom:
 
GW.UMICH.EDU is NTP synchronized to a bunch of machines and a change in
DCN1's view of the year has noticable impact on the well-behaving of
GW.UMICH.EDU. There is another host on the same machine (WWV.UMICH.EDU)
which is locked on a local WWV clock and which will tell you the right
year. WWV.UMICH.EDU is probably slightly more inaccurate (may be by some
50 msec or so (may be less (infinity in Dave Mills' terms!))) than the
GW.UMICH.EDU time.
 
I will tell you the NCAR address if you promise not to send TCP/TIME
requests.
 
        -- Hans-Werner

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9-Jan-87 00:16:58 EST
From:      karn@FLASH.BELLCORE.COM (Phil R. Karn)
To:        mod.protocols.tcp-ip
Subject:   Re:  Authentication (was: No more NFS flames)

I am also interested in ways to add authentication to TCP/IP. The specific
motivation for this is amateur packet radio. FCC rules prohibit encryption
per se, though authentication based on cryptographic techniques is okay as
long as the actual information content of the message is in the clear.

I have therefore been thinking along the lines of adding an option to IP
containing an authenticator. This field would be computed only across the
data portion of the datagram (i.e., everything past the IP header) since
intermediate gateways must be able to modify the IP header.  The specific
algorithm is open for discussion, but as an initial proposal I would suggest
running the data portion of the packet through DES in the cipher block
chaining mode, padding out the data to a multiple of 8 bytes with zeros if
necessary.  Then the final 8-byte ciphertext is put into the IP option.  The
receiver performs the same calculation and compares its result with the
field in the IP header. Any modification or spoofing of the contents of the
data field without knowledge of the DES key used to generate the
authenticator would result in the received and computed authenticators being
different, and the receiver would ignore the packet.

Any modification or spoofing of the data field (which includes the TCP
header, if TCP is in use) would cause the authentication check to fail.  The
normal duplicate packet detection facilities already in TCP (or other
transport protocol) would protect against "playback" attacks (recording and
repeating valid traffic).

Basically this is a form of "checksum" or "CRC" with an algorithm complex
enough to protect against deliberate attack by humans as well as random
attacks from nature.

Is the floor open for an RFC on this subject?

Phil

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9-Jan-87 01:05:53 EST
From:      Mills%udel.edu@LOUIE.UDEL.EDU
To:        mod.protocols.tcp-ip
Subject:   Re:  Ask not for whom the chimes tinkle

Tom,

[expletive deleted]. From the DCN1 log, it appears some NTP peer came up
claiming to be an NTP primary radio clock, but one year off, argued with
DCN1 and won. I suspect it happened during the interval immediately
following reboot and when the radio clock direclty attached to DCN1
stabilized. Although the year is initialized from the file system during
reboot, until the local radio clock engages an broken NTP peer can
latch the wrong year. DCN1 has been rebooted maybe once every two weeks,
almost always to install software updates. The spoof window lasts maybe
a minute. What can I say? Yes, the window can probably be shut.

Independent, operational radio clocks are presently at DCN1 (128.4.0.1),
UMD1 (128.8.0.1) and FORD1 (128.5.0.1). The new NCAR clock is probably
best left alone until the NSFnet Backbone configuration changes have
completely stabilized. What these should do is provide up to six NTP
"servers" on various campus nets, all slaved to NCAR and will avoid
congestion on the network links serving NCAR itself.

Dave

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9-Jan-87 01:24:44 EST
From:      Mills%udel.edu@LOUIE.UDEL.EDU
To:        mod.protocols.tcp-ip
Subject:   Re:  Ask not for whom the chimes tinkle

HW,

Unfortunately, Hans-Werner's clock can be spoofed in the same way mine was
(both us the same synchronization code). The problem is rather tricky. Every
host is told at reboot what year it is and remembers this until told
otherwise. Let's assume some j-random glitch comes along and sets the
local clock using NTP or even eyeball-and-wristwatch, which causes the
year to be changed. Then the radio clock comes up and starts ticking the
seconds but using the bogus year.

How can you protect against this? The radio clock may never come up. In
its absence the local host falls back to NTP and believes what it is told.
If it is peering with a sufficient number of other reliable clocks, then
the bog should be overcome. However, the fuzzball bog-suppressant code
does not yet do all it can in comparing multiple clocks and at the moment
of failure had only one other (presumably broken) player. Once again to
the breech, dear hearts, and reflect on the fact that nothing is quite so
public and excites so many so quickly as a timewarp. Mr. Sulu would understand.

Dave

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9-Jan-87 07:32:52 EST
From:      Hans-Werner_Braun@um.cc.umich.edu.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Ask not for whom the chimes tinkle

Dave, I don't think this is true for the Heath clock. After all, I don't
have a DATE statement in STARTF.COM as I think you do. This thing needs
to be opened every 31st December in the hours between the time where
UT and local time think that the next day started and a switch gets thrown
to define the exact year (!@#$%^&). While you were able to fix your chimes
from home I had to go to the radio clock and use a screwdriver.
 
       -- Hans-Werner

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9-Jan-87 10:26:58 EST
From:      van@LBL-CSAM.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   tcp monitor available for anonymous ftp (long msg)

An incredible number of people have requested my tcp monitor.
It's available via anonymous ftp from host lbl-rtsg.arpa
(128.3.254.68 or 128.3.255.68), file tcpdump.tar.  This is
a binary file in Unix tar format (remember to set binary
mode before you ftp it).  It contains the program executable,
manual entry, README file and a couple of data analysis awk
scripts.  The file is about 100KB.  A copy of the README
file, describing the program and giving examples of some
of the things you can do with it, is appended to this 
message (and I apologize for the length of this message).

The program runs on a Sun-3 under version 3.2 or later of
the Sun OS.  It may run under earlier versions of the system.
It won't run on a Sun-2.

The source isn't available (don't even ask).  The program was,
unfortunately, originally based on Sun's etherfind so I won't
distribute it without permission from Sun.  It doesn't matter
if you have a Sun source license, we are not an authorized
re-distributor of Sun source.  If anyone from Sun is reading
this, it would be nice if you could
  - send me a letter saying it's ok to distribute the source, or
  - send me a letter saying it's ok to submit the source for the
    upcoming Sun user group tape.
If neither of the above is acceptable, maybe I'll just give you
the source and you can figure out what to do with it.

I would appreciate it if someone would post the tar to mod.sources
or any other appropriate redistribution points.  I'll be traveling
most of the next month.  Please don't send me mail asking if I'll
mail the program to you.

Best of luck using the program.  Hope it helps dispel some of the
tcp mis-information and folklore that's been floating around.

  - Van

------------------------
Fri Jan  9 05:40:50 PST 1987

This directory contains the binary and manual entry for an
ethernet monitor program, tcpdump.  The program runs on a Sun-3
under Sun OS version 3.2 or later (kernel bugs in earlier
versions of the system make it inadvisable to run this program). 

The program is loosely based on SMI's "etherfind" although very
little of the etherfind code remains.  It was written by Van
Jacobson, Lawrence Berkeley Laboratory, as part of an ongoing
research project to investigate and improve tcp and internet
gateway performance.

The current versions of these files are available via anonymous
ftp from host lbl-rtsg.arpa (128.3.254.68 or 128.3.255.68), file
tcpdump.tar (a Unix tar file).  The source to the program is not
currently available (pending distribution permission from Sun).

The author would welcome comments, bug reports, etc.  I can be
reached via electronic mail to van@lbl-csam.arpa or van@lbl-rtsg.arpa.
As of this writing, I have a backlog of 6 months of unread mail
(2500 msgs) so don't expect a prompt reply.  It is, for all
practical purposes, impossible to reach me by telephone.

The program is copyright (C) 1987 by Van Jacobson, Lawrence
Berkeley Laboratory.  You are free to copy and redistribute
it as long as you don't charge for it.  If you try to sell
tcpdump or claim that it's yours, I'll sic our overpaid,
underworked lawyers on you.


This directory also contains two short awk programs intended as
examples of ways to reduce tcpdump data when you're tracking
particular network problems.  The problem I was looking at was
the bulk-data-transfer throughput of medium delay network paths
(1-6 sec. round trip time) under typical DARPA Internet conditions.

The trace of the ftp transfer of a large file was used as the raw
data source.  The method was:

  - On a local host (but not the Sun running tcpdump), connect to
    the remote ftp.

  - On the monitor Sun, start the trace going.  E.g.,
	tcpdump between local remote and port ftp-data >tracefile

  - On local, do either a get or put of a large file (~500KB),
    preferably to the null device (to minimize effects like
    closing the receive window while waiting for a disk write).

  - When tranfer is finished, stop tcpdump.  Make a copy of the
    tracefile and delete the initial SYN packets and final FIN
    packets from the copy (using the editor).  While doing this,
    make note of the average packet size.

  - Use awk to make up the two files of summary data:
      awk -f send-ack.awk packetsize=avgsize tracecopy >sa
      awk -f packetdat.awk packetsize=avgsize tracecopy >pd

  - Do all of the above steps several times, both directions,
    at different times of day, with different protocol
    implementations on the other end.

  - Using one of the Unix data analysis packages (in my case,
    S and Gary Perlman's Unix|Stat), spend a few months staring
    at the raw and reduced data.

  - Change something in the local protocol implementation and
    redo the steps above.

  - Once a week, tell your funding agent that you're discovering
    wonderful things and you'll write up that research report
    "real soon now".



In both the awk programs we assume that all packets are about
the same size, the tcp max segment size (a size variation of
about 40% is handled ok).  Given this, we can regard the
sequence space as consecutive mss-size "chunks" and can label
each packet by the "chunk" it transports rather than the bytes
it transports.  I.e., the packet numbers will be 1, 2, 3, ...
instead of 1, 513, 1025, ....  (This simply makes it easier
to spot holes and duplicates, plot different views of the data,
etc.)  Keeping this chunking in mind, the awk programs are:

send-ack.awk
	Simplifies the tcpdump trace for an ftp (or other unidirectional
	tcp transfer).  Since we assume that one host only sends and
	the other only acks, all address information is left off and
	we just note if the packet is a "send" or an "ack".  Sequence
	numbers are converted to "chunk numbers" by assuming all
	packets are about the same size and dividing the start sequence
	number by that size.  

        There is one output line per line of the original trace. 
        Field 1 is the packet time in decimal seconds, relative
        to the start of the conversation.  Field 2 is delta-time
        from last packet.  Field 3 is packet type/direction. 
        "Send" means data going from sender to receiver, "ack"
        means an ack going from the receiver to the sender.  A
        preceding "*" indicates that the data is a retransmission.
        A preceding "-" indicates a hole in the sequence space
        (i.e., missing packet(s)).  Field 4 has the packet flags
        (same format as raw trace).  Field 5 is the "chunk
        number", essentially the start sequence number divided by
        the max segment size (rounded down to the nearest mss). 
        Send and ack numbers correspond, e.g., "ack 7" is the ack
        for "send 7".  The number in parens following an ack is
        the delta-time from the first send of the packet to the
        ack.  A number in parens following a send is the
        delta-time from the first send of the packet to the
        current send (on duplicate packets only).  Duplicate
        sends or acks have a number in square brackets showing
        the number of duplicates so far. 

	Here is a short sample from near the start of an ftp:
		3.00    0.20   send . 7
		3.20    0.20    ack . 7  (0.20)
		3.20    0.00   send P 8
		3.40    0.20    ack . 8  (0.20)
		3.80    0.40 * send . 1  (3.80) [2]
		3.82    0.02 *  ack . 8  (0.62) [2]
	Three seconds into the conversation, chunk 7 was sent.  200ms
	later it was acked.  Shortly thereafter chunk 8 was sent and,
	again, it was acked after 200ms.  Then, for no apparent reason,
	chunk 1 is retransmitted, 3.8 seconds after its initial
	send (the round trip time for this ftp was 1sec, +-500ms).
	Since the receiver is expecting chunk 9, chunk 8 is re-acked
	when chunk 1 arrives.

packetdat.awk
	Computes chunk summary data for an ftp (or similar
	unidirectional tcp transfer).

	A summary line is printed showing the number of chunks,
	the number of packets it took to send that many chunks
	(if there are no lost or duplicated packets, the number
	of packets should equal the number of chunks) and the
	number of acks.

	Following the summary line is one line of information
	per chunk.  The line contains eight fields:
	   1 - the chunk number
	   2 - the start sequence number for this chunk
	   3 - time of first send
	   4 - time of last send
	   5 - time of first ack
	   6 - time of last ack
	   7 - number of times chunk was sent 
	   8 - number of times chunk was acked
	(all times are in decimal seconds, relative to the start
	of the conversation.)

	As an example, here is the first part of the output for
	an ftp trace:

	# 134 chunks.  536 packets sent.  508 acks.
	1       1       0.00    5.80    0.20    0.20    4       1
	2       513     0.28    6.20    0.40    0.40    4       1
	3       1025    1.16    6.32    1.20    1.20    4       1
	4       1561    1.86    15.00   2.00    2.00    6       1
	5       2049    2.16    15.44   2.20    2.20    5       1
	6       2585    2.64    16.44   2.80    2.80    5       1
	7       3073    3.00    16.66   3.20    3.20    4       1
	8       3609    3.20    17.24   3.40    5.82    4       11
	9       4097    6.02    6.58    6.20    6.80    2       5

	This says that 134 chunks were transfered (about 70KB
	since the average packet size was 512 bytes).  It took
	536 packets to transfer the data (i.e., on the average
	each chunk was transmitted four times).  Looking at,
	say, chunk 4, we see it represents the 512 bytes of
	sequence space from 1561 to 2048.  It was first sent
	1.86 seconds into the conversation.  It was last
	sent 15 seconds into the conversation and was sent
	a total of 6 times (i.e., it was retransmitted every
	2 seconds on the average).  It was acked once, 140ms
	after it first arrived.

	(The data for this and the preceding example were
	taken from a Stanford-to-LBL ftp.  As of this
	writing, Stanford provides several fine sources of
	"interesting" tcp behavior.)

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9-Jan-87 13:00:26 EST
From:      Mills%udel.edu@LOUIE.UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Authentication (was: No more NFS flames)

Phil,

It's even easier than that. Simply encrypt the existing TCP/UDP checksum,
which includes the pseudo-header. Don't bother recomputing it. I have a little
toy proposal which might be used to distribute keys. If you would like to
see a copy, ftp the file nsa.txt from udel2.udel.edu with anonymous/guest.

Dave

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9-Jan-87 13:09:28 EST
From:      gross@MITRE-GATEWAY.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: What's a repeater, bridge, router, or gateway?


> We also need a term for a clump of internets connected by, for example,
> mail gateways. I'd probably call it a metanet, but I don't think that
> term is in common usage.

When discussing a (future) large conglomeration of DoD and ISO nets that 
might include application level gateways, dual protocol gateways, dual 
protocol hosts and some form of interoperable DoD/ISO routing, we came up 
with the term "Teranet".  (The greek prefix "tera-" means "so large and 
malformed as to be monsterous"; as in "teratology- the study of serious 
deviations from the normal type in organisms".)

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9-Jan-87 13:19:38 EST
From:      Mills%udel.edu@LOUIE.UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Ask not for whom the chimes tinkle

HW,

You are right, as usual, and I wrote the code. The year is in fact read off
the clock and I twitched my screwdriver just like you. I double-checked all
the configuration files on all the fuzzies known to me and found the right
year in the startup files. The mystery deepens, because now we have to
find some player somewhere who has his year wrong and is torqueing via
NTP. Distributed algorithms are a gas...

Dave

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9-Jan-87 18:03:59 EST
From:      karn@FLASH.BELLCORE.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Authentication (was: No more NFS flames)

Just encrypting the existing Internet checksum won't protect against someone
monitoring good packets and modifying them in such a way that the checksum
is unchanged.  This is easy since Internet checksums use a simple linear
algorithm; consider that swapping any pair of 16-bit integers within the
message leaves the checksum unchanged.

Also, since the checksum is only 16 bits, it isn't at all hard to watch the
channel and construct a lookup table mapping all 65536 possible checksum
values to their encrypted counterparts.

The value of the cipher checksum needs to depend in a highly nonlinear and
unpredictable (without the key) way on both the values and the positions of
bits within the message. It needs an "error extension" property.  Cipher
block chaining does this.

Phil

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9-Jan-87 22:41:46 EST
From:      Mills%udel.edu@LOUIE.UDEL.EDU
To:        mod.protocols.tcp-ip
Subject:   Re:  Authentication (was: No more NFS flames)

Phil,

Yes, you're right; however, my model has rather less weight than yours. It
is intended as a hotpatch that can be dropped into the code at a conenient
place, not require a lot of computation (I assume it to be done in software)
and to done for all UDP and TCP connections for a particular host. A perpetrator
surely can take advantage of the weaknesses of the checksum algorithm whether
encrypted checksums are used or not. I did not intend the simple function I
suggested to fix that - I'd rather fix the checksum algorithm itself. As for
the size of the checksum; well, we could always stuff it in an IP option.
Every time I get going in this vein I drown in the tradeoffs, then try to
remember I only need a lifevest, not a SAR team. Discussion on just how hard
is hard with respect not only to your model and mine, but also with respect to
distributed protocols such as gateway routing protocols and (heaven help me)
network time protocols would be welcome (but not specifics with respect to the
ciphers themselves). I would be glad to summarize comments sent to me at
mills@huey.udel.edu.

Dave

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Sat, 10-Jan-87 17:31:19 EST
From:      mills@huey.udel.edu.UUCP
To:        mod.protocols.tcp-ip
Subject:   Clocks moving relatively

Folks,

Be advised on or about 22 January there will be a configuration change
affecting the connectivity of the NSFnet Backbone and client nets, as well as
the WWVB radio clock at Linkabit in Vienna, VA. The change results from the
rehoming of some DCNET (128.4) hosts and gateways from Linkabit to the
University of Delaware and the assignment of a new net MACOMNET (192.5.8) for
Linkabit hosts. The physical configuration of the hosts now at Linkabit,
including the WWVB radio clock, will remain the same. Only the net numbers
will change.

Timekeepers ticking with host DCN1.ARPA aka POGO aka DCN-GATEWAY.ARPA at
Internet addresses 128.4.0.1 or 10.0.0.111 should re-tick following the
cutover with MACOM1.ARPA aka LINKABIT-GW.ARPA at its Internet addresses
192.5.8.1 or 10.0.0.111. Use of the ARPANET address 10.0.0.111 is discouraged,
since the clock may be reconfigured in future or moved to another host.

Be also advised the TCP/TIME service is to be removed from all fuzzballs at
some time in the near future. This service will no longer be advertised in the
NIC data base HOSTS.TXT following the cutover. The TCP/DAYTIME, UDP/NTP and
UDP/TIME services will continue indefinately. Use of the TCP/DAYTIME service
on a regular, recurring basis is strongly discouraged and may lead to
discontinuing all TCP-based time services in future.

Dave
-------

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Sat, 10-Jan-87 19:03:27 EST
From:      hedrick@TOPAZ.RUTGERS.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   secure replacements for passwords

Does anyone know of good replacements for the normal "please type your
password" approach to login validation?  We're thinking of moving our
administrative computing onto a campus-wide network.  I'm nervous
about having people updating student records on a system that is as
easy to tap as the typical Ethernet.  Obviously we'd like to prevent
people from seeing the data at all.  But I'm most concerned with
preventing people from changing it.  My theory is that once a TCP
connection is established, it's likely that no one will be able to
break in on it.  The gateways and backbone are likely to be physically
secure, so any breaking in would have to happen on the local net. I
think we can tweak the implementations so that is either impossible or
leaves immediately obvious evidence.  So what I'd like is a way, once
the connection is established, to validate the person who is on it.
It strikes me that fairly simple cryptographic techniques should work
here.  I had in mind something like the host sends me a random number,
I ask the user for his password, I encrypt the random number with the
password, and send back the results.  The host knows the password
(This is not Unix, so the password files are not public.), and
duplicates the results at its end.  The only constraint on the
encryption technique is that it has to be able to survive a known
plaintext attack on the random number.  Presumably that is short
enough that any reasonable technique (DES?) would work, as long as we
choose the passwords.  Obviously if the user chooses the passwords,
the space of passwords will be so small that it would be easy to
search.  Does this seem reasonable?  Anybody have a better idea?  I'm
looking for something that I can practically implement myself.
Probably all access with be a micro running pc/tn3270, when it becomes
available, and the mainframe will be running the UCLA MVS TCP/IP code.
I'm looking for something I can hack into that software.

Also, it would be sort of nice to encrypt the data itself.  Does
anybody know whether this is practical?  My feeling is that it might
be worth coming up with a random bit stream once for each connection
and just XOR'ing all the data with it.  Of course this would be a
sitting duck for known plaintext attack, but at least it would require
some work to see what was going on.  The security against change would
not depend upon this, but upon the security of the connections and the
password mechanism.  This would be designed simply to discourage
casual wiretapping.

I know nothing I'm going to come up with is going to prevent the NSA
from finding out our student grades.  But what bothers me is the
common approach that because the perfect is unobtainable, we do
nothing.  What I'd really like to do is to get something that is at
least as secure as locking your gradebook in your desk and then
locking your office door.  There are obviously many people on our
campus who can get past those locks.  But there is still a difference
between using the locks and leaving the grade book out on a coffee
table in a public lounge.

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Sat, 10-Jan-87 21:05:09 EST
From:      weltyc%cieunix@CSV.RPI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Ask not for whom the chimes tinkle


>You are right, as usual, and I wrote the code. The year is in fact read off
>the clock and I twitched my screwdriver just like you......

	Isn't it funnay how things like this happen... Right after I
got this message I saw the following "fortune" when I logged out:

	"Beware of programmers carrying screwdrivers"

	Hmmm. perhaps I should notify the police...

					-Chris

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      10-Jan-87 22:20:04-UT
From:      mills@huey.udel.edu
To:        tcp-ip@sri-nic.arpa, nsfnet@sh.cs.net
Subject:   Clocks moving relatively
Folks,

Be advised on or about 22 January there will be a configuration change
affecting the connectivity of the NSFnet Backbone and client nets, as well as
the WWVB radio clock at Linkabit in Vienna, VA. The change results from the
rehoming of some DCNET (128.4) hosts and gateways from Linkabit to the
University of Delaware and the assignment of a new net MACOMNET (192.5.8) for
Linkabit hosts. The physical configuration of the hosts now at Linkabit,
including the WWVB radio clock, will remain the same. Only the net numbers
will change.

Timekeepers ticking with host DCN1.ARPA aka POGO aka DCN-GATEWAY.ARPA at
Internet addresses 128.4.0.1 or 10.0.0.111 should re-tick following the
cutover with MACOM1.ARPA aka LINKABIT-GW.ARPA at its Internet addresses
192.5.8.1 or 10.0.0.111. Use of the ARPANET address 10.0.0.111 is discouraged,
since the clock may be reconfigured in future or moved to another host.

Be also advised the TCP/TIME service is to be removed from all fuzzballs at
some time in the near future. This service will no longer be advertised in the
NIC data base HOSTS.TXT following the cutover. The TCP/DAYTIME, UDP/NTP and
UDP/TIME services will continue indefinately. Use of the TCP/DAYTIME service
on a regular, recurring basis is strongly discouraged and may lead to
discontinuing all TCP-based time services in future.

Dave
-------
-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Sun, 11-Jan-87 08:35:00 EST
From:      NS-DDN@DDN2.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   Password Security for the UCLA ACP



I heard of a fascinating alternative to standard access validation which may be
right up your alley. Instead of a password, the user is presented with five
random numbers and asked to compute the result using his secret access
validation algorithm. Traces and taps will only show a plaintext response to
the specific access request. The algorithm is not apparent unless many accesses
are traced and analyzed. A good algorithm mechanism would support conditionals;
e.g., If 3rd number is odd, then result is 4th number minus 5th number, else
result is 1st number times 1st number plus 2nd number. While this is complex,
it avoids the overhead of DES (I shudder to think what that would do to the
ACP's resource consumption).
 
The ICT ACACCESS module (invoked via the PACCESS macro) is not designed
to work this way since it assumes it is merely interfacing to an MVS security
package which is password-driven. Worse still, the commutator is not party to
TCP and VTAM sessions; hence, it cannot solicit the userid, prompt for the
result, and capture the result. Consequently, implementation of this idea
cannot be easily be centralized within the PACCESS service.
 
There is no standard routine for solicitation of the userid/password. I would
suggest adding an A-service to provide a common solicitor routine which would
be knowledgeable of both TELNET and VTAM connections to deal with each
appropriately. Then modify the modules which obtain this information to use the
A-service instead.
 
Another problem with this would be the creation of an access table containing
each user's id, privileges, and algorithm. This should be part of ACACCESS.
PACCESS and ACACCESS would have to modified to expect six numbers (the prompted
five and the user's response) instead of the existing eight-byte password.
 
Be very careful with enhancements to the commutator! While this is not a
trivial enhancement, I believe it would serve your needs (and maybe ours, as
well).
 
Best regards,
 
Dave Craig
Network Solutions, Inc.

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 87 08:35 EST
From:      NS-DDN @ DDN2
To:        hedrick @ TOPAZ
Cc:        tcp-ip @ SRI-NIC
Subject:   Password Security for the UCLA ACP


I heard of a fascinating alternative to standard access validation which may be
right up your alley. Instead of a password, the user is presented with five
random numbers and asked to compute the result using his secret access
validation algorithm. Traces and taps will only show a plaintext response to
the specific access request. The algorithm is not apparent unless many accesses
are traced and analyzed. A good algorithm mechanism would support conditionals;
e.g., If 3rd number is odd, then result is 4th number minus 5th number, else
result is 1st number times 1st number plus 2nd number. While this is complex,
it avoids the overhead of DES (I shudder to think what that would do to the
ACP's resource consumption).
 
The ICT ACACCESS module (invoked via the PACCESS macro) is not designed
to work this way since it assumes it is merely interfacing to an MVS security
package which is password-driven. Worse still, the commutator is not party to
TCP and VTAM sessions; hence, it cannot solicit the userid, prompt for the
result, and capture the result. Consequently, implementation of this idea
cannot be easily be centralized within the PACCESS service.
 
There is no standard routine for solicitation of the userid/password. I would
suggest adding an A-service to provide a common solicitor routine which would
be knowledgeable of both TELNET and VTAM connections to deal with each
appropriately. Then modify the modules which obtain this information to use the
A-service instead.
 
Another problem with this would be the creation of an access table containing
each user's id, privileges, and algorithm. This should be part of ACACCESS.
PACCESS and ACACCESS would have to modified to expect six numbers (the prompted
five and the user's response) instead of the existing eight-byte password.
 
Be very careful with enhancements to the commutator! While this is not a
trivial enhancement, I believe it would serve your needs (and maybe ours, as
well).
 
Best regards,
 
Dave Craig
Network Solutions, Inc.

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Sun, 11-Jan-87 09:38:20 EST
From:      LYNCH@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: secure replacements for passwords

Charles,  I hope Brian Reid at DECWRL reads this list as he has
dealt with this problem at STanford and, as you note, no one has done
anything yet to at least put up a line of defense for "us nice citizens
who once in a while get tempted".  Your concern in advance is
commendable.  I have been secretly worring about "security" of
internetworking for a long while now because I fear the backlash
when the first big "thefts/damages" happen and the world finds
out how spartan our security features are.  

I have worked in the security arena long enough to know that anything
that one comes up with as a protective measure can be countervailed.
It is only a matter of the price one is willing to pay.  So, please,
some of you out there who know of some reasonable barriers to 
tampering on campus LANs, give Charles some feedback on his request.

Thanks,
Dan
-------

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 1987 09:38:20 EST
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
Cc:        tcp-ip@SRI-NIC.ARPA, LYNCH@A.ISI.EDU
Subject:   Re: secure replacements for passwords
Charles,  I hope Brian Reid at DECWRL reads this list as he has
dealt with this problem at STanford and, as you note, no one has done
anything yet to at least put up a line of defense for "us nice citizens
who once in a while get tempted".  Your concern in advance is
commendable.  I have been secretly worring about "security" of
internetworking for a long while now because I fear the backlash
when the first big "thefts/damages" happen and the world finds
out how spartan our security features are.  

I have worked in the security arena long enough to know that anything
that one comes up with as a protective measure can be countervailed.
It is only a matter of the price one is willing to pay.  So, please,
some of you out there who know of some reasonable barriers to 
tampering on campus LANs, give Charles some feedback on his request.

Thanks,
Dan
-------
-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 1987 14:55-PST
From:      STJOHNS@SRI-NIC.ARPA
To:        LYNCH@A.ISI.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: secure replacements for passwords
I'd  like  to remind all of you to be careful when addressing the
subject of  network  security  on  this  mailing  list.   General
problems  are  OK  for  discussion,  while  specific instances or
attack are not.

I realize this is  skirting  the  issue  and  may  in  the  final
analysis  give  us  no protection at all, but it may give us some
breathing space to address the problems/solutions.  (BTW, I  come
from  the old Multics community where the main security maxim was
"Security through obscurity is no security at all")

Lastly, those of you who have "security  incidents"  can  address
questions and requests for help to DDN-NSO@SRI-NIC.ARPA or USNail
Maj Steve Rudd, DCA Code B652, Washington, DC 20305-2000.

(I realize the above really has no relationship to the subject  I
am  replying  to,  but  it  looked  like  the discussion might be
heading in that direction)

Mike (DDN-PMO, Code B612)
-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Sun, 11-Jan-87 16:37:50 EST
From:      Murray.pa@XEROX.COM
To:        mod.protocols.tcp-ip
Subject:   Re: secure replacements for passwords

As long as you can work on the software at both ends, then your goals
are reasonable. Needham and Schroeder published a scheme back in '78.
Check out the Dec '78 CACM.

The basic idea you are looking for is pretty much the following. The
user calls the server, and sends his claimed identity (username) in the
clear. The server picks a random number and a session key, encrypts them
with the users password and sends them back to the user. The user
decrypts them, and uses the session key to encrypt the random number and
sends that back to the server.

DES will eat a lot of cycles if you do it in software. That's not a
problem if you only use it for authentication, but if you are encrypting
everything going to/from a terminal session, response will probably be
unacceptably slow. Micros are getting pretty fast these days. Check it
out. You might just make it. (Sorry I don't have any numbers handy.)

I strongly suggest a physically separate network for administrative
work. Don't even connect it to the rest of the world via any gateways.
This transforms the problem back into physical security. Most
administrative people understand that. In any case, it becomes their
problem and you (we?) can't get a black eye because some tricky point
got overlooked. Keep in mind that observing terminal traffic is just the
tip of the iceberg. As your users get more sophisticated and upgrade to
more powerful machines, you will have to worry about printing things
directly from a workstation, swapping to remote disks, remote debugging
sessions, and strange new things that nobody has even imagined yet.

Our administrative people upstairs have their own ethernet (and printer
and file server and ...).

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12-Jan-87 10:26:00 EST
From:      JSLove@MIT-MULTICS.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: secure replacements for passwords

Both TELNET and FTP-CONTROL (not FTP-DATA) sessions use the TELNET
protocol, so you could do some password protection in that layer.  For
example, if the TELNET turns off echoing, you could turn on encryption,
which would protect a password (and also emacs sessions, but you could
deal with that separately).  You could define negotiations to turn some
form of data protection on and off.

The alternative is to invent new protocols for login, file transfer and
so on.  This has been done already for Unix (at least in part), so specs
and implementations exist of protocols which dispense with the normal
login dialogue for user authentication.  You will probably have to
design and implement your own authenticator.

I recommend against keeping a cleartext password file.  Even if it is
secure, scramble the passwords.  You can use the scrambled passwords as
encryption keys.  Since the password will be supplied to the
authentication server scrambled by another key, the initial password
scrambling (when new passwords are set) might be done at the
authentication server as well.

In your login dialogue, start out using a key used by that
workstation-server pair.  Scramble the userid with this key (K1) so that
a listener can't easify find out who owns the connection.  The server
will unscramble it and look up the user.  Then the server will send back
a session key and a random number, encrypted with the userid and
workstation-server keys.  The workstation will decrypt this and ask the
user for a password.  It will then scramble the password, and encrypt
the random number with the session key and the scrambled password as
keys, returning the result to the server.  The server checks the
returned random number after decryption.

The session key is remembered for use during the session by operations
which require a high degree of protection, such as changing passwords.
However, it would probably use DES or some other form of encryption
which might be too expensive to use on all traffic.  I believe there are
network interfaces available for some machines which will encrypt your
entire packet with special hardware, but they may make it difficult to
communicate with any machine which doesn't have exactly the same
interface hardware.

For regular traffic, there are cheap forms of encipherment which will be
better than using the same XOR string for every connection.  For
example, you could use a character translate table, which is harder to
break than an XOR mask.  Don't use the same table for every byte.  You
could cycle between several, or you could select which table based on
some more complex algorithm.  For example, if you had 64K of table
space, you could use the previous byte to select the translation.  You
could have a circular list of tables and step to the next table using
the modular addition of the current table index and the previous
character.

This is certainly breakable in principle, but it is cheaper than
software DES.  Each translate table must be isomorphic (invertible) but
no relationship need exist between multiple tables.  The tables could be
mechanically generated and changed often, perhaps being distributed over
the network in encrypted form.  Encipherment would be done only on the
byte stream, so it probably could be implemented outside the operating
system kernal or without changes deep within the TCP/IP.

Rather than partition the network physically, consider an implementation
based on IP security options in the IP headers.  This would be enforced
by the gateways.  An IP gateway must be present between the ethernets
which have sensitive traffic and the rest of the internet.  The gateway
would refuse to pass packets off the sensitive network which contained
the security option.  Ideally, the hosts on the sensitive networks would
place the security options in the packets.  If that isn't feasible, the
gateways could.  Consider a campus network with subnets A, B, C, D and
E:

      B       D
       \     /
        A---C
             \
              E---ARPANET

Subnets B and D belong to the administration.  The AB gateway passes
packets from A to B only if the have the security option, and passes
packets from B to A adding the security option to the IP header.
Gateway CD has similar behavior.  Gateway AC ignores the option.
Gateway CE refuses to pass in either direction packets which contain the
security option.  (This description has been simplified for pedagogical
purposes so much that it resembles "community of interest" routing,
which is also a possibility, but which is more limiting.)

Subnets A and C must be physically secured just as networks B and D.
However, they can carry traffic from unsecured subnets.  It is desirable
for backbone networks to be able to carry traffic from all subnets.  The
AB, CD and CE gateways must be secured from tampering, but anyone on
subnet E or other networks connected to it will be completely unable to
send packets to or receive packets from subnets B and D.

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12-Jan-87 10:34:08 EST
From:      ron@BRL.ARPA (Ron Natalie)
To:        mod.protocols.tcp-ip
Subject:   Re:  Password Security for the UCLA ACP

Of course the problem with this is that the users who are likely to
be using a Unversity Administration system aren't likely to be able
to deal with too hard an algorithm and a Ethernet wiretapper probably
could deduce it over a period of time.  The only way I can think of
getting around it is to use a PC or some other semi-smart device as
the user terminal and encrypt some or all of the authentication information.
It's really the same idea, except that the terminal has most of the smart
algorithm in it, the user just has some key.

-Ron

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12-Jan-87 10:41:10 EST
From:      PADLIPSKY@A.ISI.EDU
To:        mod.protocols.tcp-ip
Subject:   FTAM Implications Wrap-up (Maybe)

Several messages were exchanged "off to the side" recently on the
FTAM Implications topic that I thought would be of interest (and
maybe even amusement) to all readers, so with Marshall Rose's kind
concurrence (which induced me to leave the last word with him...for
now), here they are:

[First he wrote (in reference to my public msg that contained the
observation that you can't do Top-down and Bottom-up simultaneously):]

 2-Jan-87 12:28:36-EST,776;000000000001
Return-Path: <mrose@nrtc-gremlin.arpa>
Received: FROM NRTC-GREMLIN.ARPA BY USC-ISI.ARPA WITH TCP ; 2 Jan 87 12:25:24 EST
Received: from nrtc-gremlin by nrtc-gremlin.arpa id a015756; 2 Jan 87 9:24 PST
To: PADLIPSKY@a.isi.EDU
Subject: Re: "FTAM" Implications 
In-reply-to: Your message of 30 Dec 86 10:42:00 -0500.
Date: Fri, 02 Jan 87 09:24:28 -0800
Message-ID: <15752.536606668@nrtc-gremlin.arpa>
From: Marshall Rose <mrose@nrtc-gremlin.arpa>

Nah.  It just says that you can't do it all at once unless there are
timely communication between groups.  If they all could have met at say,
NY, for a week, the problem would have been done.  I put more blame on the
FTAM people for just not waiting for the presentation people to finish,
than anything else.

/mtr

[And then I wrote (with a sentence more at the end about including
his msg that I've deleted here since it made more sense to put his
msg first in this context):]

Marshall--

Rats.  Here I went to all the trouble to compose the semielegant
bit of technicoaesthetic righteousness below and then when I
was in the midst of sending it I discovered that the msg I was
responding to was a private aside, not one you'd sent to TCP-IP.
If you think it would be amusing, do feel free to send it along
to the list anyway, with this preface on it so readers will know
there are no hard feelings going around (at least, I assume there
aren't).

   cheers, map

I can't agree that the mismatch between what ISO FTAM needed and
what ISO Presentation offered can be passed off as just a peccadillo.
After all, on a practical level people apparently did waste time,
energy, and funds implementing to the DP in the unfullfilled but not
unreasonable expectation that the committee had "done its homework"
properly, and on a theoretical level the fact that the mismatch
happened at all still strikes me as being Wrong.  Perhaps I was
too concise in my last msg, though, as to the reasoning, so as
one last shot in my current mini-salvo on the theme that Going
ISO Is Throwing Bad Money After Good (a brand-new Slogan), let's
try looking at it this way:

In the zeroth place, the designers of _any_ "Application" protocol
ought to be the best judges of what they need to virtualize.  (If
they aren't, they shouldn't be the designers.)  Therefore, they
shouldn't be expected/required to depend on whatever primitives
the Presntation committee happened to deem appropriate in the first
place.  In other words, it's wrong to think of L6 as a monolith;
it should be a repository of the virtualizations dictated by the
L7 protocols that need them.  Indeed, L6 is only defensible as
a separate layer at all because making it one might happen to
force modularity on the functions it offers; even that view assumes,
however, that there wouldn't be the desired modularity if there
were no layer boundary between the control and virtualization aspects
of an L7 protocol, and that doesn't have to be the case.  We needn't
waste time on FTP's using Telnet on its control connection here, but as
things stand, L6 seems to be being treated as the de facto fiefdom
of its committee, and this amounts to letting non-carpenters dictate
the contents of the carpenters' toolboxes for all L7 carpenters,
not just FTAM.

That, without boring everybody, is a bit more on the It's Level [sic]
5-7 charge.  Now to expand a bit on the other, related charge.
The relevant Slogan, assuming almost nobody ran off to find p. 215 of
The Book (especially since I didn't even bother to cite the page
last time) goes as follows:
   The more layers, the more committees--
   A bureaucrat's dream of the Feudal.
   The more committees, the more disparities--
   An implementor's nightmare of the futile.
That is, I take the FTAM misadventure to be evidence that it's
even worse to view a layer as a fiefdom than it is to view it
as a monolith.  My vague understanding of "CASE" is that it wouldn't
have been invented if L6 hadn't "belonged" to the L6ers: another
case related to the FTAM one.  But that's only a problem with
Presentation's being tardy, according to Marshall, or a problem that
would go away if L7ers could dictate what went into L6 (or even if
there were no pretense that 6 and 7 were different) according to
me.  The real nastiness of the Layer-as-fiefdom psychology, it seems
to me, is exposed when you look at the deliberations of the
Reference Model Security Appendix committee.  Two of them have
told me independently that the Security Appendix will call for the
vesting of _no_ security functionality in L5 (the "Session" level),
because--to paraphrase--there's nothing useful in the current L5
protocol (DIS or IS or whatever status it's reached).  When you stop
and think that many approaches to "security" _require_ that audit
trails be kept on a per-session basis, I submit you should realize that 
it's ludicrous for their approach to Security to have nothing to do
with their Session layer.  What I think is happening is that, once
again, a committee's layer/"turf" if being viewed as sacred, and
it it gets things wrong the Reference Model gets distorted rather
than the layer/protocol gets fixed.

Now, not only don't I want this to go on too long, I also really
_don't_ want it to turn into "anything personal" with regard to
Marshall (whom I don't even know, and who probably isn't an ISORMite
in TCP-IPer's clothing to begin with), but my bottom line for all
this is that I think the recruiting poster we were originally
shown (when he said that FTAM looked like a good alternative to NFS)
turns out to have, when looked at under a magnifying glass, little
pictures of atrocities being committed in the background; if anybody
wants to join such an army, I can't stop them, of course--though I
do hope they won't do their campaign planning on TCP-IP.  (Note that
I'm not saying I'm _for_ NFS, just against FTAM.)  (Note also that
I'm not challenging his right to have shown the recruiting poster,
just what I take to be the implications of the poster.)

As a reward to those who have waded through all the metaphors, I'll
climb off the soapbox for now ... provided I don't have to rebut
the rebuttal, of course.  (Which I hope and trust won't prove
to be necessary, since I should certainly be entitled to call
what I take to be Bad Art, Bad Art--which is really what all this
has been about, in some sense.)

[And finally he wrote:]

 9-Jan-87 16:59:53-EST,2214;000000000001
Return-Path: <mrose@nrtc-gremlin.arpa>
Received: FROM NRTC-GREMLIN.ARPA BY USC-ISI.ARPA WITH TCP ; 9 Jan 87 16:57:16 EST
Received: from killer-rat by nrtc-gremlin.arpa id a013062; 9 Jan 87 13:56 PST
To: PADLIPSKY@a.isi.EDU
Subject: Re: "FTAM" Implications 
In-reply-to: Your message of 08 Jan 87 16:21:16 -0500.
Date: Fri, 09 Jan 87 13:56:31 -0800
Message-ID: <15141.537227791@nrtc-gremlin.arpa>
From: Marshall Rose <mrose@nrtc-gremlin.arpa>

    Mike - if you want to redistribute our last few messages back to
    TCP-IP, fine with me.  In response to your last message:

    Since neither of us were on the two committees in question, it's
    not really enlightening to second-guess why they did what they did.
    However:

    All ISO DPs are clearly marked as being subject to radical change.
    If vendors want to implement the DP FTAM, then they do so at their
    own risk.  I imagine that they would do so just to say "We have an
    FTAM" in order to scoop the market.  Rather silly from the technical
    viewpoing actually.  From having observed the way standards bodies
    operate, I know that unless a DP is based on some other existing
    standard (e.g., a fully fleshed-out ECMA or ANSI contribution), that
    the DP will change dramatically when it goes to DIS.  

    One observation I will make is, recently at a TCP/IP conference, a
    speaker noted something to the effect that "the lack of
    interoperability with TCP/IP offerings is what is pushing ISO
    forward".  My experience is quite the reverse:  nothing has pushed
    the acqusition of TCP/IP in the corporation I work for more than the
    fact that ISO isn't ready yet (and the fact that if you look deep
    enough through the sales glossies, you can figure that out).  

    As to the ISO poster:  it's hard to argue with you, since I don't
    like committees in general.  As far as turf wars and all that
    nonsense goes, the more I understand the ISO model, the more I like
    it.  I tend to like the final form of things more than the inital
    stuff.  So the security draft, for example, is a WD (working draft),
    I believe, not even a DP.  I'm ignoring it!

/mtr
-------

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12-Jan-87 11:18:44 EST
From:      mckee@MITRE.ARPA (H. Craig McKee)
To:        mod.protocols.tcp-ip
Subject:   Re: secure replacements for passwords

Charles Hedrick

I suggest you review DoD Password Management Guideline (CSC-STD-002-85),
12 April 85.  The Guideline was developed by the Computer Security
Center, Ft. Meade, Maryland 20755.  The point of contact is the Office
of Standards and Products, Attn: Chief, Computer Security Standards.  
(If you like I'll make a copy and mail it to you.)  The Guideline offers
many recommendations, two of which follow.

The password should be a three-word phrase, because it is easier to
remember, rather than a random string of characters.  The words are drawn
randomly from a dictionary of at least 2000 words.

The passwords should be encrypted; thus, the clear text form of the
password exists only in the mind of the user, and very briefly in the
memory of the host.

Regards - Craig

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12-Jan-87 16:56:31 EST
From:      geof@decwrl.DEC.COM@apolling.UUCP (Geof Cooper)
To:        mod.protocols.tcp-ip
Subject:   Re: secure replacements for passwords


 >                                           My theory is that once a TCP
 >      connection is established, it's likely that no one will be able to
 >      break in on it....

I'm not sure you'll have enough secure pieces.  All networks 
traversed by packets that are part of the "secure" tcp connection must
be physically secure.  Otherwise, it is easy to interpose data into a
TCP connection and monitor the result.

For example:
    Monitor the connection and wait until it has been idle for some time
    (around lunch time, so the user is probably not looking at the terminal).
    Then spoof the server into receiving a packet with a particular input
    command in it.  Examine the data that results.  Then spoof a packet that
    causes the server to clear the screen.  Note that the legit TCP client
    will merrily receive all the data.  I wonder if it will get upset that
    the ACK numbers are too high... I'd bet few TCP's would.

    When the legit user returns, he/she will type a bit with no results
    (since the server will ignore those packets).  Eventually things will
    start working again, and he/she will probably just think it a magical
    glitch and not report the problem.

The idea of Needham/Schroeder authentication is the best way to go.  One
option in the scheme was to have the encryption key for the next packet
in this packet, so the above kind of spoofing would be hard (and would
certainly be detected at the legitimate receiver).

Needham/Schroeder doesn't assume that DES is used (as I remember, certainly
there is no need for them to make that assumption).  You can
increase the work factor needed to spoof the system sufficiently by just
XOR-ing passwords into the datastream.  I would think that this would be
"enough security" for a campus environment for the next few years.

- Geof

PS: On further consideration, you could probably get around TCP spoofing by
    just arranging to never leave a connection idle for more than 30 seconds or so.
    If the system dis- and re-connected to the server automatically, the
    users probably wouldn't rebel. - GHC

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12-Jan-87 18:44:29 EST
From:      yerazuws@CSV.RPI.EDU (Crah)
To:        mod.protocols.tcp-ip
Subject:   Re: secure replacements for passwords

In article <8701111745.AA01536@ucbvax.Berkeley.EDU>, LYNCH@A.ISI.EDU (Dan Lynch) writes:
>  So, please,
> some of you out there who know of some reasonable barriers to 
> tampering on campus LANs, give Charles some feedback on his request.
> 
 
Here at RPI we have a relatively tamperproof LAN system - but it wasn't
meant to be that way.  
	
For example, Professor A gets a pair of Sun 2's.  One diskless Sun goes in 
his office up on the sixth floor, and the fileserver goes down in the 
basement lab.  A piece of Ethernet goes in between them.
	
Then Center for XXX gets in a flock of uVAXen and puts them on an Ethernet.
Different piece of coax, of course.
 
Then Center for YYY interconnects their MV10000 and their /780's and
a couple of GPX's - on yet a third Ethernet.
	
All of these Ethernets coexist physically in the same building, run 
down the same cable trays, etc.  But they're all physically separate
and since the watchword is cost - there are NO bridges/gateways.  
You see, who pays for the gateway?  What "added value" is there in
a gateway?  
	
Ah, you say that XXX and YYY should have gone on A's cable?  Well, A
already paid for that cable and it's his bandwidth and he doesn't want
to clog down his diskless SUN 2 with all that DECnet traffic (which, having
used a diskless Sun 2, I do not blame him at all for.  I wouldn't
either, if I had any way to avoid sharing that cable.)
	
But XXX and YYY should have used the same cable?  Then who pays for it?
Each center has to bill out expenditures.  So, financially speaking, 
it isn't reasonable for either party to put in some LAN that it isn't
going to use.  Or that might need to be upgraded because a "sharing" 
arrangement is overloading the LAN.

Now you say "Why not at least install bridges/gateways"?  Again, who
pays for it?  So there are no gateways.  Instead, each machine has
one or two RS232 lines to a data switch.  At 9600 baud.  You dial
out and tell the data switch where to connect- and then you log in
there.  

Meanwhile, those three Ethernets sit there, safe and protected from the
"other" guy.   


	Forgive the sarcasm and the flames, dear reader.  But
restricting use of a LAN (or access to bandwidth on a broadband system)
may be what you want, although it pretty much negates the usefulness
of the LAN in the first place.  I'd personally advise against such 
physical protection systems where the stakes are low (How much can
a college campus net intruder get for his trouble?  Ten grand maybe,
at best?).  
	
	If the stakes were higher (like a case of national 
security) I'd say this is the way to go.  Hang the multiple Ethernet 
coaxes or fiber optics along the ceiling in the middle of a patrolled hall
and NOBODY is going to get to it without much pain.
	
	What it boils down to is that you can have security, or you
can have a useful LAN, or you can go crazy.  Those are your options.

		-Regrets for the depressing truth...
		 Bill Yerazunis

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13-Jan-87 00:58:34 EST
From:      mills@HUEY.UDEL.EDU
To:        mod.protocols.tcp-ip
Subject:   How sweet it is

Folks,

Mike Petry, fierce swamprat from U Maryland, staggered from the muck
waving an ACC 5250 X.25 interface driver in one hand and dragging
an awesome alligator in the other. Shortly before he passed out
(the swampgas was just too much - he began to see UFOs) he whispered
"only ten keystrokes did the varmits in." I rushed to the ooze and
tossed a ping raft between dcn-gateway (56-Kbps 1822/ECU 10.0.0.111)
and terp (56-Kbps X.25 10.8.0.111) and reeled in 5000 packets of
catfish, a possum and two owls. The swamp never smelled so good.


Relative to my gruesome scatter plots mentioned previously to the
list, the X.25 circuit has much joy. The Sun-format bitmap file
is on udel2.udel.edu under anonymous/guest as terp1.bit, should you
care to light it up. The max delay was almost five seconds, but only
five samples were more than two seconds. The regression line had
a y intercept of 32 and 576-octet intercept of 238, for a slop of
22411 bps, about to be expected for the two-hop dcn-gateway PSN 111
terp path. Mike tells me the problem was a simple bug in the driver,
so I suggested he set a reasonable price for ransome at just $500
per keystroke. Comes to one 5250, unless you can find a ripoff in
Filene's basement basement.

I don't know about you guys, but I am mighty relieved and would like
to be one of the first to throw Mike a towel so he can wipe off that
icky, smelly swamp stuff and take a bath.

Dave
-------

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13-Jan-87 05:08:43 EST
From:      van@LBL-CSAM.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Analyzing Acknowledgement Strategies

Craig -

  I tried to do some work on analytic models of transport
protocols a couple of years ago.  I have kept watching but
haven't found much in the ARQ literature that reflects realistic
protocol implementations.  There were 6 or so papers whose
*method* looked like it could be adapted to the analysis of TCP
or RDP.  Two that I kept in my "potentially useful" file were
Easton's "Batch Throughput Efficiency of ADCCP/HDLC/SDLC
Selective Reject Protocols", IEEE COM-28, No.2, Feb, 80, and Wai
Sum Lai's "Analysis of Piggybacking in Packet Networks", (this
was in the proceedings of one of the Berkeley Workshops on
Distributed Data Management and Computer Networks but I don't
know which one.  Probably the fourth, 1979).  A more recent paper
that looked interesting was "Performance Analysis of the
Selective Repeat ARQ Protocol" in COM-34, No.2, Feb, 86. 

  I wasn't sure from your msg what objective function you wanted
to optimize and what you viewed as constraints.  I was trying to
model a net where
 - each connection wished to maximize its throughput (as opposed
   to maximizing total network throughput)
 - aggregate network bandwidth is a limitting resource (i.e., data,
   acks and other connections all compete for the same bandwidth)
 - the population of users is large (i.e., the potential offered
   load is many times the available bandwidth)
 - all connections use the same send/ack policy and sends from
   different connections are initially i.i.d.
 - all packets go through gateways and the host-gateway path has
   much higher bandwidth than the gateway-gateway path.
 - gateways have finite buffer capacity
 - packets are subject to loss by both damage and congestion.

  Using some of the ALOHA analysis, you can show that any protocol
that deals the first six constraints must be fair and must be very
conservative with retransmissions (because congestive collapse is
exponential).  The congestive-loss constraint made the problem
novel and I got some simulation results that might explain some of
the behavior you observe.

  If we make the usual assumption of a constant bit error rate,
damage loss is a linear function of the traffic.  Congestive loss
is a function of the packet interarrival times (i.e., the derivative
of traffic w.r.t. time).  I made a loss model that looked like
	L(N) = (a + b dN/dt) N
where L is the number of packets lost and N is the number of
packets sent (including retransmissions).  I then did a cluster
analysis and a regression on a bunch of trace data to get
empirical values for a and b. Since I had first become interested
in gateway behavior when I noticed the large amount of congestive
loss, I wasn't surprised to find that b was three to four orders
of magnitude larger than a.

  This note is already too long so I'll state, without background,
some preliminary, *simulation* results (I hope to one day have
analytic results but am presently hampered by massive mathematical
ignorance). 

  - The network is wildly unstable under most send/receive policies
    if the rtt estimates are bad.

  - If the window is W packets and the round trip time is R, the
    sender policy that maximized throughput was to keep
    W/R <= dN/dt <= 2W/R  (i.e., spread the packets uniformly over
    the rtt interval but still fill the pipe).  Under heavy
    congestion it also helped to inject some random variation into
    the packet send times.

  - If the sender doesn't try to spread out packets, it is unwise
    for the receiver to delay an ack for more than half the average
    packet interarrival time.  An ack for multiple packets will
    make the sender generate a burst of packets to fill the
    window.  Any time a burst is sent, the probability of loss goes
    up quickly.  (If you were testing on a lossy path, this may have
    been what was happening when you observed that increasing the
    number of acks increased the throughput.)

  - If the sender doesn't try to spread packets, retransmissions
    (usually) result in a burst of packets, that results in loss, that
    results in retransmissions, that ....  Most tcp's are guilty of
    this burst, including 4.[23]bsd.  It's this mis-behavior of
    tcp which I believe accounts for you and others observing better
    throughput with RDP than TCP.  This is simply because the EACK
    makes it less likely that a naive protocol implementation will
    generate a burst of packets.  ("Naive" means "naive of interarrival
    time effects".)

  While I never got any of the preceeding into a publishable form, I
have gone over some of the trace data and simulation results with
Mike Karels.  I think we've agreed on a change to the 4bsd tcp
retransmission policy and hope to implement and test it soon.  In
(limited) simulation, the new policy reduced the number of
retransmissions by a factor of four and increased the throughput
under heavy congestion by a factor of two. 

  Hope some of this was useful.  If you have time to summarize, I'd
be interested in anything you learned from the replies to your query.

 - Van

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Tue 13 Jan 87 05:18:16-EST
From:      Dennis G. Perry <PERRY@VAX.DARPA.MIL>
To:        ron@BRL.ARPA
Cc:        NS-DDN@DDN2.ARPA, hedrick@TOPAZ.RUTGERS.EDU, tcp-ip@SRI-NIC.ARPA, perry@VAX.DARPA.MIL
Subject:   Re:  Re:  Password Security for the UCLA ACP
Actually, I would investigate some of the smart cards around for authentication
and potentially encryption.  Codercard at one time was thinking about putting
in their card the ability to not only have the one time password, but to
encrypt the data and change the encryption key in a period short compared to
the amount of data transfered, so that even if some was able to break the
key, the amount of data obtained would be small and then they would have to
start all over.

dennis
-------
-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13-Jan-87 08:50:32 EST
From:      Richard_S._Conto@UM.CC.UMICH.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Password Security for the UCLA ACP

In the message ( Message-Id: <8701121034.aa13795@SEM.BRL.ARPA>)
of Mon, 12 Jan 87, Ron Natalie (<ron@BRL.ARPA>) suggests:
 
> ...                                    The only way I can think of
>getting around it is to use a PC or some other semi-smart device as
>the user terminal and encrypt some or all of the authentication information.
>It's really the same idea, except that the terminal has most of the smart
>algorithm in it, the user just has some key.
 
  Is this really 'safe'?  If you're really so terribly worried about the
privacy and the secure validation (which I'd like to consider as seperate,
though linked issues), then doesn't this end also need to be secure?  I
can see specialized hardware possibly being secure, but a program that
resides on a PC can be easily duplicated.  In fact, with one person
borrowing another's copy to get some work done quickly, it would soon seem
to loose any real security at all and just become a nuisance.
 
--- Richard
 
ARPA     Richard_S._Conto@um.cc.umich.edu
USnail   Richard S. Conto
         Computing Center
         1075 Beal Ave.
         University of Michigan
         Ann Arbor, Mi.  48109
 
"It's too early in the day to be cute and funny."

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13-Jan-87 09:30:00 EST
From:      JSLove@MIT-MULTICS.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: secure replacements for passwords

I don't know about your TCP, but the Multics TCP will send a RST
immediately if it receives a packet with an ACK that it`s too high.  I
believe that this is clearly spelled out in the specification, but I am
at home and don't have the specification handy.

To prevent this, your penetrator must break network routing (e.g., using
ARP) to prevent the acknowledgements from reaching the workstation or
the RSTs they provoke from getting back to the server.  If you don't
mind breaking the connection, any damage you can do with a single packet
is perfectly possible.

I don't think most TCPs would give out any indication of why the
connection was broken, either on the scren or in a debugging log.  An
workstation in debug mode might note that an out-of-sequence
acknowledgement was received, but the server would only note that the
user had aborted the connection.  If you really have control of network
routing, it would be interesting to see if you could insert the
penetrator between the workstation and server, effectively splitting an
existing session into two sessions with the penetrator in the middle.
The potential for mischief would be awesome.

Receiving a packet which contains out-of-sequence acknowledgement should
probably ring alarm bells.  Even out-of-sequence packets which don't
contain acknowledgement (and thus must be SYN packets) are illegal, but
they probably indicate that the other end has crashed or a TTL anomaly,
rather than a penetration attempt.

Something else that might help is putting reasons for aborts into RST
packets as data, and having the receiving TCP log the abort reason.
Then there would be a record of the break-in at both ends of the
connection.  I believe that there are TCPs which implement this, but
have no idea which ones.  It certainly isn't in the spec.  (This could
be circumvented by having the penetrator abort the connection, but
unless routing is subverted, this gives too short a window to do much
other mischief.)

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      13-Jan-87 05:32:42-UT
From:      mills@huey.udel.edu
To:        tcp-ip@sri-nic.arpa, nsfnet-routing@mcr.umich.edu
Subject:   How sweet it is
Folks,

Mike Petry, fierce swamprat from U Maryland, staggered from the muck
waving an ACC 5250 X.25 interface driver in one hand and dragging
an awesome alligator in the other. Shortly before he passed out
(the swampgas was just too much - he began to see UFOs) he whispered
"only ten keystrokes did the varmits in." I rushed to the ooze and
tossed a ping raft between dcn-gateway (56-Kbps 1822/ECU 10.0.0.111)
and terp (56-Kbps X.25 10.8.0.111) and reeled in 5000 packets of
catfish, a possum and two owls. The swamp never smelled so good.


Relative to my gruesome scatter plots mentioned previously to the
list, the X.25 circuit has much joy. The Sun-format bitmap file
is on udel2.udel.edu under anonymous/guest as terp1.bit, should you
care to light it up. The max delay was almost five seconds, but only
five samples were more than two seconds. The regression line had
a y intercept of 32 and 576-octet intercept of 238, for a slop of
22411 bps, about to be expected for the two-hop dcn-gateway PSN 111
terp path. Mike tells me the problem was a simple bug in the driver,
so I suggested he set a reasonable price for ransome at just $500
per keystroke. Comes to one 5250, unless you can find a ripoff in
Filene's basement basement.

I don't know about you guys, but I am mighty relieved and would like
to be one of the first to throw Mike a towel so he can wipe off that
icky, smelly swamp stuff and take a bath.

Dave
-------
-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Jan 87 11:44:59 EST
From:      hurf@tcgould.tn.cornell.edu (Hurf Sheldon)
To:        arpa.tcp-ip
Subject:   Hot setup for PC-AT?
	We have two PC-AT's (not clones) & would like  to connect
them to our ethernet. What hardware/software would be good choices?
Both systems are msdos. Will h4000 decoders work with the hardware
& does the software support full tcp/ip - bsd4.3 networking?

I willsummarize any email replies-

thanks

     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

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13-Jan-87 12:51:34 EST
From:      weltyc%cieunix@CSV.RPI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Tektronics TCP/IP for VMS


	Sorry to ask a question that I know was answered previously,
but I can't seem to find it in my own archive...  There was mentioned
a list for people interested in the Tek TCP/IP at cornell or cmu or
someplace like that.  Can anyone tell me the actual address for
that???

					-Chris

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13-Jan-87 13:22:46 EST
From:      Mills@LOUIE.UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Analyzing Acknowledgement Strategies

Van,

You are doing some fantastically wonderful stuff that should have been done
long ago. Your conclusions coincide closely to my observations and probably
many others, especially with respect to bunching (aka spasms), especially
with Unix systems using humungus windows over lossy paths. One thing was
not clear from your note. Did your simulations include the use of the Nagle
Algorithm?

Some years ago when I was experimenting along with others on TCP models
I built a flow estimator into the code which produced in effect your
dN/dt. It was designed to produce exactly the result you describe -
spreading the packets uniformly over time. I also intended to build an
estimator for dL/dt as the loss rate (did I get your nomenclature backwards?),
but something else distracted me. However, I did wire up a couple of D/A
converters to panel meters on my desk so I could see the estimators in action.
One was the SRTT and the other the dN/dt. Boy, did I get an eyeful watching
these gizmos in action as tings clogged and unclogged. If there weren't so
many other beasties squealing for attention, I'd like to dive back in those
issues again. The results might well have a profound effect on second-generation
ISO transport protocol implementations.

Idea: Use median-filter estimators instead of linear, recursive-filter ones.
I found the former extraordinarily effective for comparing clocks across the
swamps, which means they should work well for SRTT as well. My variant, which
doesn't have a proper name, is as follows: save the last n RTT samples and
sort them. Identify the median (dither if you have to if the number of samples
is even), then toss out the extremum furthest from the median. Repeat until
only a single sample is left. Season for the endgames. Serve with appropriate
timeout, so that really old info is discarded. I have been using sample windows
of eight.

Keep up the good work.

Dave

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13-Jan-87 19:26:43 EST
From:      ron@BRL.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Re: Password Security for the UCLA ACP

Yes, last I heard DARCOM (er, AMC) headquarters was contemplating
such a system.  I haven't heard if it has been installed yet.

-Ron

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14-Jan-87 09:12:14 EST
From:      whna%cgcha.UUCP%cernvax.BITNET@WISCVM.WISC.EDU (Heinz Naef)
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: cgcha!whna
From: whna@cgcha.UUCP (Heinz Naef)
Newsgroups: comp.sources.wanted,mod.computers.sun,mod.protocols.tcp-ip
Subject: SLIP (Serial IP over asynchronous line)
Keywords: SLIP, IP, PC/IP, TCP/IP, asynchronous.
Message-ID: <204@cgcha.UUCP>
Date: 14 Jan 87 14:12:11 GMT
Organization: CIBA-GEIGY AG, FO/WIRZ/WRZ, Basel, CH
Lines: 15


Does anybody have implemented a piece of software on a UN*X 4.2bsd system
that supports the DoD Internet Protocol (IP) over asynchronous serial lines?

There are products available for MS/DOS PC's that offer this type of
attachment. These would allow PC-like systems that are located far away
from the Ethernet to get connected to the UN*X systems over phone lines.
PC users could take advantage of the Telnet, FTP etc. client functions as
if they were directly attached to the Ethernet, except they would experience
slower speed and some operational differences (dial-up, point-to-point etc.).

Thanks for your help,
Heinz Naef.

Please respond by electronic mail: ..!mcvax!cgcha!whna.

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14-Jan-87 10:54:17 EST
From:      bob@OHIO-STATE.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Tektronics TCP/IP for VMS

In article <8701131751.AA17600@cieunix.rpi.edu> weltyc%cieunix@CSV.RPI.EDU (Christopher A. Welty) writes:
> ... a list for people interested in the Tek TCP/IP ... ?

The list is resident at `TEKTCP%KLA.WESLYN@WESLEYAN.BITNET'.  Be quite
careful of the spelling, because those missing vowels will getcha.

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      14 Jan 87 16:21:00 PST
From:      <art@acc.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic>
Subject:   PSN Interoperability

I am trying to obtain information which I think is extremely important
for designing and maintaining interface hardware and software which
must interconnect to BBN PSNs.

Does anyone out there have a detailed understanding of how PSN 6.0 maps
between the 1822, X.25 Basic and X.25 Standard services and a description
of the underlying packetization performed between PSNs.  There doesn't
appear to be any publically available documents and BBN seems to be unwilling
or unable to communicate any information to us.

The original IMPs (PSNs) would take 1822 "messages" of up to roughly 1K and
split them up into 128 byte "packets" which were independently shipped
throught the IMP network.  When all of the "packets" were received and
reassembled by the destination IMP and the "message" delivered to the
destination host, a Request For Next Message (RFNM - pronounced "ruf num")
was sent back to the sending host.  For resource control, only 8
messages were allowed to be outstanding to any specific remote host per
1822 "link number".  IP datagrams were assigned a specific "link number"
to use.

Does anyone know whether the current PSNs operate this way for 1822
interfaces?

I would like to find out how HDH "packet mode" and HDH "message mode"
interacts with the internal PSN transport.

I would like to know how DDN Basic mode and DDN Standard mode interacts
with the internal PSN transport.

Specifically I would like to understand what happens (in DDN Standard
Mode) to an IP datagram which is sent as a sequence of X.25 "m-bit"
packets and is delivered elsewhere via an 1822 interface.  I would
like to know how the contents of the X.25 packets are handled and
how the X.25 packet window is controlled.

My understanding is that PSN 7.0 will change the behavior of X.25
through the PSN network.  Anyone have any real information?

					Art Berggreen
					<Art@ACC.ARPA>

------
-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15-JAN-1987 16:40 N
From:      <POSTMASTER%FINFUN.BITNET@WISCVM.WISC.EDU>
To:        TS0400%OHSTVMA.BITNET@WISCVM.WISC.EDU
Subject:   Returned Network Mail


----------------------------Original message----------------------------
Your mail is being returned to you.
Reason for return is:
%MAIL-E-LOGLINK, error creating network link to node VTTEL1
-SYSTEM-F-LINKEXIT, network partner exited
Returned mail follows:
------------------------------
Received: From BYUADMIN(MAILER) by FINFUN with RSCS id 5461
          for VTTTELTY@FINFUN; Thu, 15-JAN-1987 16:40 N
Received: by BYUADMIN (Mailer X1.23b) id 5420; Thu, 15 Jan 87 06:59:06 MST
Date:         Thu, 15 Jan 87 08:46:02 EST
Reply-To:     "(TCP-IP ARPA Digest)" <TCPIP-L@BYUADMIN>
Sender:       "(TCP-IP ARPA Digest)" <TCPIP-L@BYUADMIN>
From:         Bob Dixon <TS0400@OHSTVMA>
Subject:      Password security
To:           "(no name)" <VTTTELTY@FINFUN>

  Another way of minimizing the effect of possible ethernet tappers
is to use bridges and gateways which isolate groups of users appropriately.
Then a member of any given group cannot intercept messages which do not
involve that group, because other packets do not flow in their ethernet.


                                               Bob Dixon
                                               Ohio State University
Acknowledge-To: <TS0400@OHSTVMA>
-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14-Jan-87 17:16:47 EST
From:      ron@BRL.ARPA (Ron Natalie)
To:        mod.protocols.tcp-ip
Subject:   Re:  Password Security for the UCLA ACP

Well, any point of the system where the data is going to exist unencrypted
is going to have to be secured.  But consider the original application.
He was concerned about ethernet spies grabbing the passwords and such off
the wire.  You can do this even if the spy has a copy of your encryption
program.  Many people have the UNIX password crypt routine, but as of yet
no one has announced a way to use it to decrypt totally random passwords
(other than by exhaustive search, which even on our X/MP-48 takes a long
time...it does vectorize nicely though :-)).

Consider the following scenario...

A BIG SECURE UNIVERSITY ADMINISTRATIVE COMPUTER named I'm Big Money
An IBM PC in the Bursars Office named Petty Cash
and the campus ethernet spine with the above plus random PC's and
SUNs on it called "RU-YELLOW"

Petty Cash:  I'd like to talk to Big Bucks
	( now big brother makes up a verification string of random
	  letters)
I'm Big Money:  Encrypt "AWALKER" for me using your password as key.
	(PC now encrypts the random phrase with the user's password
		"TUITION")
PC:  The encrypted string is "*HOBBIT*".
	(IBM now encrypts "AWALKER" with the user's passord "TUITION"
	  and sees that they match and allows access.)
IBM:  OK PC...what shall we do today?

See at no time did the user's password "TUITION" ever exist in the
clear.  The Spy, seeing the random string and the encrypted answer
can not deduce the password.  He can't use the encrypted answer because
next time IBM will send a different string.  It makes no difference here
whether or not he has a copy of the program running in PC or not.

Of course, he can probably get all kinds of juicy data if the transactions
are not encrypted as the authentication was.  In addition, there is always
the chance that the spy can infiltrate either end (like by modifying the
software in the PC to also keep track of the cleartext passwords).

-Ron

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14-Jan-87 19:21:00 EST
From:      art@ACC.ARPA
To:        mod.protocols.tcp-ip
Subject:   PSN Interoperability


I am trying to obtain information which I think is extremely important
for designing and maintaining interface hardware and software which
must interconnect to BBN PSNs.

Does anyone out there have a detailed understanding of how PSN 6.0 maps
between the 1822, X.25 Basic and X.25 Standard services and a description
of the underlying packetization performed between PSNs.  There doesn't
appear to be any publically available documents and BBN seems to be unwilling
or unable to communicate any information to us.

The original IMPs (PSNs) would take 1822 "messages" of up to roughly 1K and
split them up into 128 byte "packets" which were independently shipped
throught the IMP network.  When all of the "packets" were received and
reassembled by the destination IMP and the "message" delivered to the
destination host, a Request For Next Message (RFNM - pronounced "ruf num")
was sent back to the sending host.  For resource control, only 8
messages were allowed to be outstanding to any specific remote host per
1822 "link number".  IP datagrams were assigned a specific "link number"
to use.

Does anyone know whether the current PSNs operate this way for 1822
interfaces?

I would like to find out how HDH "packet mode" and HDH "message mode"
interacts with the internal PSN transport.

I would like to know how DDN Basic mode and DDN Standard mode interacts
with the internal PSN transport.

Specifically I would like to understand what happens (in DDN Standard
Mode) to an IP datagram which is sent as a sequence of X.25 "m-bit"
packets and is delivered elsewhere via an 1822 interface.  I would
like to know how the contents of the X.25 packets are handled and
how the X.25 packet window is controlled.

My understanding is that PSN 7.0 will change the behavior of X.25
through the PSN network.  Anyone have any real information?

					Art Berggreen
					<Art@ACC.ARPA>

------

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14-Jan-87 20:06:29 EST
From:      lear@rutgers.edu@aramis.UUCP
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: aramis!lear
From: lear@aramis.RUTGERS.EDU (eliot lear)
Newsgroups: mod.protocols.tcp-ip,comp.unix.wizards
Subject: routed question/survey
Message-ID: <220@aramis.RUTGERS.EDU>
Date: 15 Jan 87 01:06:29 GMT
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 15

Hi,

I am writing a graphically oriented network monitoring facility and
I am interested in using routed to derive a map of systems on the
various networks.  My first question: Is routed used enough to get a
good picture of the net?  My second question: Does anyone know if
protocol specs exist for routed?

			Thanks in advance,

					...eliot
-- 

[lear@rutgers.rutgers.edu]
[{harvard|pyrnj|seismo|ihnp4}!rutgers!lear]

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 1987 07:26-EST
From:      CERF@A.ISI.EDU
To:        hedrick@TOPAZ.RUTGERS.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: secure replacements for passwords

An interesting authentication scheme uses a special calculator
issued to each user. The calculator has a crypto chip and is
keyed before being given to the user. To determine whether a
user is valid, the system presents a challenge in the form of
an integer (probably 5-6 digits long) which the user keys into
his calculator. The calculator applies the encryption algorithm
and key to the input and produces an integer output which the user
then keys into his terminal/PC. If the challenge is always taken
at random over a large enough field, it would take a tapper an unacceptably 
long time to accumulate enough samples to have much chance of 
spoofing. 

Obviously, one would want to re-key the device periodically and
perhaps even remotely, using appropriate rekeying methods, to
render useless any accumulations of challenge/response collected
by an adversary.

I believe an outfit in Ohio, Battelle Memorial Institute, has developed
such a device and is looking for opportunities to commercialize it.

Vint Cerf
-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15-Jan-87 07:43:00 EST
From:      NS-DDN@DDN2.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Password Security in the UCLA ACP


 
I know it's hard for some people to believe, but the only locally available
encrypting hardware/software for many users lies under the cranium! There are
still lots of dumb terminals in other budget-consious organizations. Although
Charles' original request specifically ruled them out of his network, I, for
one, have to maintain their support. Consequently, I would like this discussion
to bear them in mind.
 
As Ron said, Charles, we're ignoring the problem of application program
passwords (in this sense, TSO qualifies as such). Having run whatever gauntlet
is implemented to gain access to server TELNET, your users will then have to
logon to your host's applications. Thus you would probably want to monitor the
TELNET session and encrypt the incoming responses for all recognized password
prompts. But you would still be exposed to situations where no prompt is given
unless you encrypted the entire user transmission. For example, assuming an
implementation along the lines of Ron's scenario:
 
    TSO:            ENTER LOGON - 
    Server TELNET:  [Encrypt your response with your ACP password]
    User:           logon myid/mypass a(xyz) 
 
If this is going on through a virtual 3278, you would be forced to negotiate
back to an NVT for that one transaction or create a screen for TELNET's use,
decrypt the datastream returned, unwrap and remap the single line into the
VTAM screen.
 
It also means you would have to analyze your supported applications to
determine where passwords are expected in responses, what those prompts look
like in terms of constants and variables, and maybe software DES would be
running a tight footrace with this kind of overhead.
 
Does the application support command stacking with a special character, such as
a semi-colon? Server TELNET may never see the normal prompt...
 
I'll bet that physical security approach is sounding better and better all the
time!
 
Try suggesting to your IBM marketeer that they provide 370 DES instructions and
supporting software. Also, get involved in SHARE and champion a requirement
that IBM software get its password obscuring act together, recognizing that
users are not always connected by an SNA device.

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 87 07:43 EST
From:      NS-DDN @ DDN2
To:        hedrick @ TOPAZ.RUTGERS.EDU
Cc:        tcp-ip @ SRI-NIC.ARPA
Subject:   Re:  Password Security in the UCLA ACP

 
I know it's hard for some people to believe, but the only locally available
encrypting hardware/software for many users lies under the cranium! There are
still lots of dumb terminals in other budget-consious organizations. Although
Charles' original request specifically ruled them out of his network, I, for
one, have to maintain their support. Consequently, I would like this discussion
to bear them in mind.
 
As Ron said, Charles, we're ignoring the problem of application program
passwords (in this sense, TSO qualifies as such). Having run whatever gauntlet
is implemented to gain access to server TELNET, your users will then have to
logon to your host's applications. Thus you would probably want to monitor the
TELNET session and encrypt the incoming responses for all recognized password
prompts. But you would still be exposed to situations where no prompt is given
unless you encrypted the entire user transmission. For example, assuming an
implementation along the lines of Ron's scenario:
 
    TSO:            ENTER LOGON - 
    Server TELNET:  [Encrypt your response with your ACP password]
    User:           logon myid/mypass a(xyz) 
 
If this is going on through a virtual 3278, you would be forced to negotiate
back to an NVT for that one transaction or create a screen for TELNET's use,
decrypt the datastream returned, unwrap and remap the single line into the
VTAM screen.
 
It also means you would have to analyze your supported applications to
determine where passwords are expected in responses, what those prompts look
like in terms of constants and variables, and maybe software DES would be
running a tight footrace with this kind of overhead.
 
Does the application support command stacking with a special character, such as
a semi-colon? Server TELNET may never see the normal prompt...
 
I'll bet that physical security approach is sounding better and better all the
time!
 
Try suggesting to your IBM marketeer that they provide 370 DES instructions and
supporting software. Also, get involved in SHARE and champion a requirement
that IBM software get its password obscuring act together, recognizing that
users are not always connected by an SNA device.

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 1987 10:59-PST
From:      STJOHNS@SRI-NIC.ARPA
To:        art@ACC.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: PSN Interoperability
Andy  Malis  wrote  an  RFC detailing the change visible from the
user's point of view on this subject (sort of).   Check  the  RFC
index.  Mike
-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Jan 87 12:41:43 PST
From:      Dan Kolkowitz <kolk@navajo.stanford.edu>
To:        tcp-ip@sri-nic.arpa
There has been another rash of breakins on the Internet.  We've noticed the SUN
release includes a number of unpassworded special accounts in the
default  /etc/passwd  file.  Breakins have occurred on at
least one of these.  You may want to set 
the password for these accounts of disable them.  
		Dan Kolkowitz
		Computer Science, Stanford
-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15-Jan-87 13:50:15 EST
From:      van@LBL-CSAM.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Analyzing Acknowledgement Strategies

Dave -

  Thanks for the kind words.  I wish the DOE felt the same way.
My network research funds were cut off a year ago because "DARPA
funds transport protocol research, not DOE".  While trying to
find new money, I got the impression that no one funds transport
protocol research since transport protocols are a "solved
problem" (this while the mean Arpanet transit delay was 15
seconds -- I tried to laugh but it hurt too much). 


  I'm not sure which Nagle algorithm you mean.  I was assuming
instantaneous sources and sinks on each end of a connection so
all segments sent were the max segment size.  So the
accumulate-until-the-ack Nagle algorithm didn't apply.  I didn't
know about the send-one-packet-when-retransmitting algorithm at
the time and didn't simulate it. 

  I did do an empirical test of the Nagle retransmit algorithm
shortly after we brought up 4.3bsd.  I ran an A-B-A-B test with
and without the algorithm (4.3 uses the algorithm) and took
statistics on sends, acks, rexmits, etc..  Each of the four test
phases ran a week.  Local network traffic made it hard to assess
the results but it was clear that using the algorithm reduced the
number of retransmitted packets by about 30%. 

  I expected the effect to be larger.  A quick look at some trace
data suggested that there was a problem when you resumed normal
behavior after a retransmit.  Since you'll always be sending into
an empty window at this point, 4.3 will blast out 8 back-to-back
packets.  A couple of packets near the end of this blast are
almost certain to be dropped so you'll end up in retransmit state
2 RTT after the previous recovery.  The new algorithm we want to
try is designed to filter this turn-on transient. 


  I didn't look at median filters while looking at RTT estimators
but I did investigate several other FIR filters.  I think that in
the clock sync problem you want a filter with good low pass
characteristics.  For RTT, I wanted a filter with good transient
response:  Because congestion builds up exponentially, if it's
detected late senders have to take drastic action to clear it and
throughput really takes a hit.  If it's detected early senders
can make small adjustments to damp it out and throughput is
hardly affected.  The simulations suggested that "early" was
really early -- within 3 to 4 packet times of the onset. 

  The problem with FIR filters was that there's usually a
discontinuity in the RTT samples at integer multiples of W, the
window size in mss packets.  If the filter was short or tapered
enough to have good transient reponse, this discontinuity wiped
it out.  If the filter was long enough to smooth the
discontinuity, it had no transient response. 

  Measuring RTT and output packet rate is essentially estimating
a parameter and its time derivative.  This is the well known
"radar tracking problem" (estimating distance and velocity from
radar return echos) and my original estimator was a copy of the
IIR alpha-beta tracker equation from a GE radar handbook.  This
had trouble because it's fixed gain.  When the network is not
congested there's a lot of stochastic noise and the filter gain
has to be low to ignore this noise.  When the network starts to
get congested, the stochastic noise gets squeezed out and you
could use much higher gain.  Investigation of variable gain
filters led me to the Kalman's work on optimal stochastic
estimators. 

  A Kalman filter seems ideal for this problem.  It's simple,
computationally efficient (6 parameters instead of the current 1
but all integer arithmetic) and always has the maximum gain that
the data supports.  Also, if the underlying model is at all close
to reality, it's self tuning so network administrators don't have
to be mathematicians.  I was just going to start on a
Box-Jenkins' style gateway model identification when the money
ran out.  I keep intending to work on this in my copious free
time but ....

  - Van

ps- perhaps we should take this discussion off line?  I've been
    filling up peoples' mailboxes lately and I get the impression
    that there are only two or three of us interested in this topic.

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15-Jan-87 15:41:43 EST
From:      kolk@NAVAJO.STANFORD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   (none)

There has been another rash of breakins on the Internet.  We've noticed the SUN
release includes a number of unpassworded special accounts in the
default  /etc/passwd  file.  Breakins have occurred on at
least one of these.  You may want to set 
the password for these accounts of disable them.  
		Dan Kolkowitz
		Computer Science, Stanford

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15-Jan-87 16:01:00 EST
From:      JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   NRC software, MICOM NI1010A tcp/ip boards & VAXes running VMS


     Hi!

     Anybody heard anything good/bad/indifferent about NRC software 
running a MICOM NI1010A TCP/IP UNIBUS board on a VAX 8650 under VMS 4.4 
or higher?  Any info useful and I'll summarize for the list.  I specify
8650 'cause UNIBUS boards that work just wonderfully on other UNIBUSes
have been known not to work on 8650s.  However, I'm not finicky.  I'll
take anything I can get.  Especially  horrors stories but I need the 
good newws too.

Chris Johnson
Northeastern University

csnet:      johnson@nuhub.acs.northeastern.edu
arpa:       johnson%nuhub.acs.northeastern.edu@relay.cs.net
at&t:       (617) 437-2335

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Jan 87 16:01 EST
From:      "I am only an egg." <JOHNSON%nuhub.acs.northeastern.edu@RELAY.CS.NET>
To:        tcp-ip@SRI-NIC.ARPA, info-vax@SRI-KL.ARPA
Subject:   NRC software, MICOM NI1010A tcp/ip boards & VAXes running VMS
     Hi!

     Anybody heard anything good/bad/indifferent about NRC software 
running a MICOM NI1010A TCP/IP UNIBUS board on a VAX 8650 under VMS 4.4 
or higher?  Any info useful and I'll summarize for the list.  I specify
8650 'cause UNIBUS boards that work just wonderfully on other UNIBUSes
have been known not to work on 8650s.  However, I'm not finicky.  I'll
take anything I can get.  Especially  horrors stories but I need the 
good newws too.

Chris Johnson
Northeastern University

csnet:      johnson@nuhub.acs.northeastern.edu
arpa:       johnson%nuhub.acs.northeastern.edu@relay.cs.net
at&t:       (617) 437-2335
-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15-Jan-87 16:11:00 EST
From:      JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   new node init procedures


     Hi!.

     I'm a novice with tcp/ip and Sun systems and UNIX.  Receiving roled
in a Sun 3/180 the other day.  Our Comp Sci department has a number of 
UNIX systems on various machines all talking on an ethernet.

     The systems person at Comp Sci said he had to tell all his UNIX 
machines the ip net address I am giving my Sun before they will all 
babble relatively understandably at each other.

     Is this really true?  Is there no "hello I'm me" packet at the ip 
level such that I could just plug my Sun into the ether and have tcp/ip 
work?

Chris Johnson
Northeastern University

csnet:      johnson@nuhub.acs.northeastern.edu
arpa:       johnson%nuhub.acs.northeastern.edu@relay.cs.net
at&t:       (617) 437-2335

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Jan 87 16:11 EST
From:      "I am only an egg." <JOHNSON%nuhub.acs.northeastern.edu@RELAY.CS.NET>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   new node init procedures
     Hi!.

     I'm a novice with tcp/ip and Sun systems and UNIX.  Receiving roled
in a Sun 3/180 the other day.  Our Comp Sci department has a number of 
UNIX systems on various machines all talking on an ethernet.

     The systems person at Comp Sci said he had to tell all his UNIX 
machines the ip net address I am giving my Sun before they will all 
babble relatively understandably at each other.

     Is this really true?  Is there no "hello I'm me" packet at the ip 
level such that I could just plug my Sun into the ether and have tcp/ip 
work?

Chris Johnson
Northeastern University

csnet:      johnson@nuhub.acs.northeastern.edu
arpa:       johnson%nuhub.acs.northeastern.edu@relay.cs.net
at&t:       (617) 437-2335
-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15-Jan-87 20:29:14 EST
From:      mike@BRL.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Analyzing Acknowledgement Strategies

I vote for keeping it on the list.  I'm keenly interested, but working
on that level of the protocol always seems to stick about 3/4 of the way
down on my queue;  I think it's hopeless. I'll never get time to tinker
down there again.  But I do enjoy reading about somebody else doing an
excellent job.  Keep up the good work, and don't go underground!

	Best,
	 -Mike

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15-Jan-87 21:58:19 EST
From:      Mills@LOUIE.UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Analyzing Acknowledgement Strategies

Van,

You are probably right that some mailboxes out there are creaking, so let's
take this offline. If anybody else is interested, please honk.

I gave up on linear filters some time ago for clock-synch. That's when I
discovered median filters, which work like a razor through toothpaste in
my experiments. I suspect they would work well for RTT as well. I thought
of Kallman and Shannon and etc., but those dudes are all linear. I got to
many bent edges.

Dave

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16-Jan-87 09:35:40 EST
From:      POSTMASTER@FINFUN.BITNET
To:        mod.protocols.tcp-ip
Subject:   Returned Network Mail



----------------------------Original message----------------------------
Your mail is being returned to you.
Reason for return is:
%MAIL-E-LOGLINK, error creating network link to node VTTEL1
-SYSTEM-F-LINKEXIT, network partner exited
Returned mail follows:
------------------------------
Received: From BYUADMIN(MAILER) by FINFUN with RSCS id 5461
          for VTTTELTY@FINFUN; Thu, 15-JAN-1987 16:40 N
Received: by BYUADMIN (Mailer X1.23b) id 5420; Thu, 15 Jan 87 06:59:06 MST
Date:         Thu, 15 Jan 87 08:46:02 EST
Reply-To:     "(TCP-IP ARPA Digest)" <TCPIP-L@BYUADMIN>
Sender:       "(TCP-IP ARPA Digest)" <TCPIP-L@BYUADMIN>
From:         Bob Dixon <TS0400@OHSTVMA>
Subject:      Password security
To:           "(no name)" <VTTTELTY@FINFUN>

  Another way of minimizing the effect of possible ethernet tappers
is to use bridges and gateways which isolate groups of users appropriately.
Then a member of any given group cannot intercept messages which do not
involve that group, because other packets do not flow in their ethernet.


                                               Bob Dixon
                                               Ohio State University
Acknowledge-To: <TS0400@OHSTVMA>

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16-Jan-87 11:22:11 EST
From:      srb%mycroft@GSWD-VMS.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: secure replacements for password

>An interesting authentication scheme uses a special calculator
>issued to each user. The calculator has a crypto chip and is
>keyed before being given to the user. To determine whether a
>user is valid, the system presents a challenge in the form of
>an integer (probably 5-6 digits long) which the user keys into
>his calculator. The calculator applies the encryption algorithm
>and key to the input and produces an integer output which the user
>then keys into his terminal/PC.
>...

Authentication is normally based on "something you know" or
"something you have".  A small weakness of the scheme as described
is that you could lose the calculator and then someone else would
have it...

I'd suggest that the calculator itself have a "password", under the
control of its owner, which enters into the cryptographic algorithm.
(Since the calculator is not networked, monitoring of the password
entry is unlikely.)  At this point, something you know AND something
you have are necessary to gain entry.

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Jan 87 14:58:59 -0500
From:      Craig Partridge <craig@loki.bbn.com>
To:        tcp-ip%sri-nic.arpa@SH.CS.NET
Subject:   Gateway Monitoring

    The people working on network and gateway monitoring for NSFNET
have decided that we'd like to develop a gateway monitoring protocol
using UDP as the transport protocol.

    To this end I've been tapped to write an RFC specifying how monitoring
will be done with UDP.

    The purpose of this note is to announce the creation of a short-lived
(I hope) mailing list, gwmon@sh.cs.net, for people who are interested
in *actively* assisting me in writing the RFC.   People who "just want
to listen in" are discouraged -- I'm really trying to create a small
discussion group of people who are seriously interested.

    Mail request to join the list to gwmon-request@sh.cs.net

Cheers,

Craig Partridge
NSF Network Service Center (NNSC)
-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16-Jan-87 12:22:50 EST
From:      stever@videovax.tek.com.UUCP
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: videovax!stever
From: stever@videovax.Tek.COM (Steven E. Rice, P.E.)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Tektronics TCP/IP for VMS
Summary: Please spell it correctly. . .
Keywords: Tektronix TCP/IP VMS free
Message-ID: <4159@videovax.Tek.COM>
Date: 16 Jan 87 17:22:48 GMT
References: <8701131751.AA17600@cieunix.rpi.edu> <8701141554.AA18711@ohio-state.ARPA>
Reply-To: stever@videovax.Tek.COM (Steven E. Rice, P.E.)
Organization: Tektronix Television Systems, Beaverton, Oregon
Lines: 11

Aarrrrggghhhh!!!!!!

      Subject: Tektronics TCP/IP for VMS
               ^^^^^^^^^^

There are neither "cee"s nor "ess"s in "Tektronix"!!

					Steve Rice

----------------------------------------------------------------------------
{decvax | hplabs | ihnp4 | uw-beaver}!tektronix!videovax!stever

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16-Jan-87 12:41:20 EST
From:      stever@videovax.tek.com.UUCP
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: videovax!stever
From: stever@videovax.Tek.COM (Steven E. Rice, P.E.)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Analyzing Acknowledgement Strategies
Summary: Please continue to let us in on the discussion!
Message-ID: <4160@videovax.Tek.COM>
Date: 16 Jan 87 17:41:18 GMT
References: <8701151850.AA18157@lbl-csam.arpa>
Reply-To: stever@videovax.Tek.COM (Steven E. Rice, P.E.)
Organization: Tektronix Television Systems, Beaverton, Oregon
Lines: 22

In article <8701151850.AA18157@lbl-csam.arpa>, Van Jacobson
(van@LBL-CSAM.ARPA) writes:

> Dave -

[ body of the article deleted ]
 
>   - Van
> 
> ps- perhaps we should take this discussion off line?  I've been
>     filling up peoples' mailboxes lately and I get the impression
>     that there are only two or three of us interested in this topic.

I cannot speak for anyone but myself, but I appreciate seeing the
discussion of these issues.  I am not at present directly involved
with such networks, but the problems discussed are food for thought
and the solutions proposed have bearing in other areas.

					Steve Rice

----------------------------------------------------------------------------
{decvax | hplabs | ihnp4 | uw-beaver}!tektronix!videovax!stever

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16-Jan-87 13:10:48 EST
From:      KLH@SRI-NIC.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Analyzing Acknowledgement Strategies

No, no, please keep the discussion going here.  It's so rare for anything
really interesting to come along... thanks!
-------

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16-Jan-87 14:10:14 EST
From:      mckee@MITRE.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Analyzing Acknowledgement Strategies

>ps- perhaps we should take this discussion off line?  I've been
>   filling up peoples' mailboxes lately and I get the impression
>   that there are only two or three of us interested in this topic.

I expect/hope many people are interested.  The current MIL-STD 1777
and 1778 are incomplete; they need a section called Implementation
Guidelines.  The work that you, Mills, Nagle, Partridge, et al are doing
will be the basis of that section.  At any rate, while I can contribute
little more than intense interest, please include me in your
discussions.

I would particularly like to hear from John Nagle on:

>A quick look at some trace data suggested that there was a problem
>when you resumed normal behavior after a retransmit.  Since you'll
>always be sending into an empty window at this point, 4.3 will blast
>out 8 back-to-back packets.  A couple of packets near the end of this
>blast are almost certain to be dropped so you'll end up in retransmit
>state 2 RTT after the previous recovery.

I would offer the following comment: Packets are lost by Gateways, not
PSNs.  The PSNs can protect themselves against an input overload from
subscribers; Gateways can only whimper Source Quench.  Accordingly, we
should thump on the egp-people people to "do something."

Regards - Craig

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16-Jan-87 14:36:53 EST
From:      LYNCH@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Analyzing Acknowledgement Strategies

I vote with Mike.  Van and Dave are exploring critical issues and
exposing the sad fact that support for this kind of research
is not too big, but the problems are not going away.  We
wil never be able to build useful (and complex) internets until
we have solid methods for controlling packetorhea.

Dan
-------

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 1987 14:36:53 EST
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        Mike Muuss <mike@BRL.ARPA>
Cc:        Van Jacobson <van@LBL-CSAM.ARPA>, tcp-ip@SRI-NIC.ARPA, LYNCH@A.ISI.EDU
Subject:   Re:  Analyzing Acknowledgement Strategies
I vote with Mike.  Van and Dave are exploring critical issues and
exposing the sad fact that support for this kind of research
is not too big, but the problems are not going away.  We
wil never be able to build useful (and complex) internets until
we have solid methods for controlling packetorhea.

Dan
-------
-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16-Jan-87 15:23:17 EST
From:      craig@LOKI.BBN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Gateway Monitoring


    The people working on network and gateway monitoring for NSFNET
have decided that we'd like to develop a gateway monitoring protocol
using UDP as the transport protocol.

    To this end I've been tapped to write an RFC specifying how monitoring
will be done with UDP.

    The purpose of this note is to announce the creation of a short-lived
(I hope) mailing list, gwmon@sh.cs.net, for people who are interested
in *actively* assisting me in writing the RFC.   People who "just want
to listen in" are discouraged -- I'm really trying to create a small
discussion group of people who are seriously interested.

    Mail request to join the list to gwmon-request@sh.cs.net

Cheers,

Craig Partridge
NSF Network Service Center (NNSC)

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16-Jan-87 16:55:47 EST
From:      ms6b#@ANDREW.CMU.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: secure replacements for password

The January issue of Data Communications refers to some work being done by
NBS to help the Treasury
department upgrade its electronic fund transfer systems along the lines you
describe.  Encryption will 
require both a physical key and a password.

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 1987 13:31-PST
From:      STJOHNS@SRI-NIC.ARPA
To:        craig@loki.bbn.com
Cc:        tcp-ip%sri-nic.arpa@SH.CS.NET
Subject:   Re: Gateway Monitoring
DCA  (and  for  that  matter  DARPA)  is funding development of a
"standard" monitoring and control protocol.  There is  also  Xnet
and HMP.  Is there really a need for yet another protocol in this
area?  (Err...  just to let you know, BBN  is  doing  the  actual
work.)  Mike
-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Sat, 17-Jan-87 11:47:49 EST
From:      karn@FLASH.BELLCORE.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: secure replacements for password

I have already implemented a crude scheme which works exactly in this way.
I run a UNIX system which is available over amateur packet radio. From time
to time I will access it from a friend's station over the air. Needless to
say I don't want to blast my root password or even my personal password over
the air, so I implemented a challenge/response system using DES.  You first
log in using a special password-less ID. The system then prompts you for
your real login name. Then it sends you the UNIX time-of-day, expressed as a
64-bit hexadecimal number. You encrypt this number and type back the
ciphertext. To do the computation, I wrote a program called "descalc" for
the PC (though portable) which allows you to set a key, enter plaintext and
read back the cipher text, enter cipher text and read back the plaintext,
etc. (I'm still working on the command that takes the cipher and plain text
and reads back the key. :-)

The system keeps its list of keys in plaintext form in a read-protected
file; this is probably the a weak spot in the system (next to the
possibility of somebody "taking over" the connection after I've
authenticated it).  If somebody can show me how to do this scheme without
keeping cleartext passwords in the system and is reasonably fast, I'm all
ears.  However, I think it's just a stopgap until I switch to full time
TCP/IP operation on the air and implement authentication on every IP
datagram.

I will probably post this stuff on USENET shortly. The DES was derived from
a version already posted there, and I modified it for improved speed and
modularity.

Phil

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Sat, 17-Jan-87 13:44:23 EST
From:      mrs2@seismo.CSS.GOV@bunny.UUCP (Mark Scherfling)
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: bunny!mrs2
From: mrs2@bunny.UUCP (Mark Scherfling)
Newsgroups: mod.protocols.tcp-ip
Subject: SUN RPC for VMS TCP/IP Query
Keywords: Help, SUN RPC, Wollongong TCP/IP, VMS
Message-ID: <886@bunny.UUCP>
Date: 17 Jan 87 18:44:22 GMT
Distribution: usa
Organization: GTE Laboratories, Waltham, MA
Lines: 13

Has anyone ever thought of or completed a port of the 
Public Domain SUN RPC protocols to other operating systems, particularly
VMS?  We are running the Wollongong TCP/IP for VMS and would
like to also support RPC.  I know Wollongong now sells NFS, but
I don't want to pay for it just to get RPC.
Also, if such a port is possible, we would also like to support 
RPC on our IBM mainframe.  We are running the Spartacus KNET
software for MVS.

Any help would be appreciated.
-- Mark Scherfling
   GTE Labs

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Sat, 17-Jan-87 14:08:57 EST
From:      van@LBL-CSAM.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Analyzing Acknowledgement Strategies, continued

Boy, was I wrong!  I've had about 100 messages in the past couple
of days saying this discussion should stay on the list.  But this
opus should convince the diehards that they made a mistake...

Dave -

You're absolutely right.  Linear filters, including Kalman
filters, do a lousy job on estimating round trip time (witness
all the spurious retransmissions on our poor, congested
Internet).  And median filters, because they have very high noise
immunity and contain no assumptions about the underlying data
distribution, should do a great job estimating r.t.t.  But,
(since I'm running 0-for-3, I have to say "But...") I was
thinking of estimating something slightly different from r.t.t. 
I pictured the "filter" estimating the coefficients of a
mathematical model that describes how a network works.  Then tcp
would use those coefficients to decide what to do when sending
and retransmitting.  Since I didn't even come close to explaining
this in the last message, I'll try here.  (The simple-minded
explanations illustrate my ignorance; they're not intended as an
insult anyone's intelligence.)


What's the problem?

If you don't get an ack for a packet within some reasonable period
of time, you will have to retransmit.  There are two possible reasons
for not getting an ack and they lead to diametrically opposed
retransmit strategies:

  1) The packet was damaged or lost in transit.  In this case you
     want to retransmit the packet as soon as you can because
     throughput goes down linearly while you wait.  Or to put it
     another way, in this case throughput will increase linearly
     with retransmit rate.

  2) The packet was discarded because of congestion at a gateway.  In
     this case you want to wait a while before retransmitting to give
     the congestion a chance to clear.  In this case throughput will
     decrease exponentially with retransmit rate.

"No ack" conveys exactly one bit of information (that a packet was
lost) and there's no way we can squeeze another bit out to tell us
if this is case 1 or 2.  But, if acks are not independent of
one another, we might squeeze something out of pattern of acks
(the ack "time series") to help us decide between cases.


What information can you pull out of the time series?

I'm about to play "mathematician", so I'd better define some
notation.  Lets say P(i) is the send time of the i'th packet,
A(i) is the arrival time of the i'th ack, and R(i) = A(i)-P(i) is
the round trip time of the i'th packet.  All times are measured
at the sender.  All packets are the same size and the receive window
is a constant W packets (packets i through i+W-1 can be sent
prior to A(i) or, equivalently, P(i+W) >= A(i)).  The time to
generate and consume packets is small compared to the network
propagation times (the sender will immediately send a packet when
the window opens and the receiver will immediately ack a packet
when it arrives). 

It's pretty clear that our traffic will introduce correlations in
ack time series.  This is because A(i), the ack for packet i, is
related to the send of i by
	A(i) = P(i) + R(i)
but P(i) was sent when the window opened, i.e., when the ack for
i-W arrived.  So P(i) = A(i-W) and
	A(i) = A(i-W) + R(i)
This is what time-series people would call an "auto-regressive"
or AR model.  It's the simplest case of an AR(W) model, one where
current events are related to events W steps in the past with R(i)
adding some randomness so you don't get complacent.

[The nice thing about time series models is that some smart
people have devised cookbook ways for a complete idiot to
construct them (a topic called "system identification").  For
example, "Time-series analysis: forecasting and control" by Box
and Jenkins leads you by the hand from `guessing possible models
from inspection of sample data' through `picking the best model
to describe the data' to `using the model once you have it'.]

It's also pretty clear that the R(i) time series will have
internal correlations, at least under congestion.  You can view
the round trip time as being proportional to the amount of "work"
the network is doing (i.e., the number of packets ahead of us in
the gateway queues).  The definition of congestion is that we
aren't done handling the work from time i-1 when the new work for
time i arrives.  The previous statements define an AR(1) model
for round trip time:
	R(i) = a R(i-1) + d + e(i)
where "a" is the fraction of work carried over from the last
step, "d" is the fixed, minimum, end-to-end propagation delay and
"e" is a random "noise" term to account for new traffic entering
and internal state changes (like adaptive routing). 

Extrapolating and waving my hands, I was going to make a model
something like
	R(i+1) = b (P(i) - P(i-1)) + a R(i) + e(i) + d
where "b" estimates how much our traffic rate affects the r.t.t.,
"a" estimates how much residual work in the network affects the
r.t.t.  and the variance of "e" estimates how much random
fluctuations contribute to the r.t.t.  (for people who like
acronyms, I think this is called an ARMAX model - Auto-Regressive,
Moving Average with eXogenous inputs).  The filter would estimate
a, b and var(e).  (The preceding sounds impressive and difficult
but it's not.  The whole thing consists of about 10 lines of
arithmetic to update 6 numbers which you do each time an ack
arrives.  With the help of a good introductory text, like Peter
Young's "Recursive Estimation and Time-Series Analysis", the
arithmetic even makes sense in a twisted sort of way.)


So What?

The model should get us at least three ways to choose retransmit
strategy: If a is large or da/di is positive, the network can't
handle its load and loss is probably congestive.  If e is small
or de/di is negative, the network is probably congested (this is
a consequence of the P-K theorem: as the network nears
saturation, "random" external perturbations have less effect on
it.  Intuitively, the variance of e is a measure of the random
way traffic arrives at and flows through the network.  But at
saturation you can no longer see these random arrivals: Data
arrives and sits in queues while some poor, constipated,
bottleneck gateway chugs on its backlog.  The whole network
behavior reduces to the (deterministic) behavior of this
gateway).  Finally, if db/di has the same sign as dR/di (i.e.,
sending packets faster lowers throughput) the network is probably
congested. 

There's a bit more information in the model.  "a" is a measure of
how fast congestion is growing so it tells you how much to change
your packet generation rate to help damp out the congestion.  In
the case of loss by damage, var(e) tells you how long to wait
before retransmitting.  E.g., say you're the only user of a
point-to-point link with 1 sec. mean round trip time and the
variation in the r.t.t. is +-50ms.  The tcp spec says to wait 2
sec. before retransmitting but you can be damn near certain you
need to retransmit after 1.2 sec.  The model should say a = b = 0,
d = 1 sec and var(e) = .1 sec.  If you set your retransmit timer
to d + 2var(e) instead of 2(d + var(e)), you won't do any more
retransmissions and thoughput could improve by up to 50%,
depending on the loss rate. 

There are many things in this that need to be checked by
experimentation.  One is the applicability of the network model. 
The whole idea is useless if someone has to do a new model
identification when an IMP is added to a network.  My hope is
that the model is "generic"; that anything serving the function
of "computer network" has a first-order description of this form.
The parameters will change from network to network but those are
estimated dynamically by the filter IF the model form is close to
correct. 

Another check is for the rate of convergence of the model.  This
will have been "an interesting academic exercise" if it takes 50
packets for the model to figure out the parameters.  My past
experience with these kind of filters (in control systems, not
networks) has been that they converge incredibly quickly (3 to 5
samples) so I'm hopeful. 

And finally, to get back to the start of this whole thing: acks. 
Send-to-ack round trip time is the only way the sender has of
probing the state of the network.  If the receiver can do
something random, acks only probe the composite state of
network+receiver.  If the receiver can go "maybe I'll generate 3
acks, just in case one gets lost", the information for the sender
in an ack is enormously reduced. 

I think this is a protocol design issue.  To do the type of
modelling I've been talking about, the actions of the receiver
have to be deterministic from the point of view of the sender. 
(Note that this prohibits things like delayed acks: the
receiver's behavior is determined by the packet interarrival
times, something the sender cannot know.  Since delayed acks are
a good thing on a local net, I'll modify the opening statement to
"the receiver's behavior should be deterministic when the transit
delay is long".)  In the case of tcp, I'd like the receiver's
behavior to be "one packet in, one ack out", just because I don't
know how to model anything more complicated. 

Congratulations to anyone who got this far.  I'm off to Usenix
for a week but there will be a test over this material a week
from Monday ;-).

 - Van

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Sat, 17-Jan-87 15:03:56 EST
From:      Mills@LOUIE.UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Analyzing Acknowledgement Strategies, continued

Van,

Oh, yummy. Erstwhile grad student Mike Minnich here has been casting for
a dissertation topic. I think he just hooked his fish. It turns out to be
reasonably easy to capture real data to test various estimators, including
those you suggest, using the various fuzzballs scattered over the Internet
(some in positions of power). The easiest way of doing that is with ICMP
Echo messages with controlled spacing and size. The PING test program can
generate these messages under several different scenarios and collect the
RTTs in a file for later analysis. It would not be hard to add to that
program a scenario similar to that you suggest. I will include that on
Mike's plate of fish.

I already have a bunch of data collected under several scenarios and would
be glad to make it available to any who ask. The data include the test runs
described in RFC-889 plus the data collected recently and reported to this
list. All we need are some gullible number-cruncher hackers (having no
esthetic principles or agendae at all, I just hack in BASIC) willing to read
the texts you suggest (plus maybe H. van Trees' book(s) - you see how
old I am) and troll their own fishlines.

One of the things that struck me when I was experimenting with algorithms
similar to that suggested by Nagle was the enormous impact of the piggyback
mechanism with TELNET and remote echo. This affects the time series in
interesting ways and suggests a simplification where the traffic flows are
assumed symmetric. Otherwise, I think you may have to split your R(i) into
two components, one going and the other coming back.

Dave

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Sat 17 Jan 87 19:19:43-EST
From:      "Dennis G. Perry" <PERRY@vax.darpa.mil>
To:        craig@loki.bbn.com
Cc:        tcp-ip%sri-nic.arpa@SH.CS.NET, perry@vax.darpa.mil
Subject:   Re: Gateway Monitoring
Craig, please contact Dave Wood at MITRE to find out what they are
doing for DoD on gateway monitoring.  Hate to see the government
duplicate it spending.  Too bad we can coordinate this sort of thing
better.

dennis
-------
-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Sun, 18 Jan 87 10:03:29 PST
From:      John B. Nagle <jbn@glacier.stanford.edu>
To:        TCP-IP@nic.sri.com
Subject:   Shock load after retransmission acknowlegement
     Craig suggests that I reply to an observation about the shock load that
occurs after a retransmission has been successfully acknowledged and we are now
again sending into an empty window.  The sending TCP, if equipped with
the congestion window mechanism, will send until it runs out of data to
send, the flow control window fills up, or the congestion window fills up,
whichever happens first.  If we are operating in a congested situation,
ICMP Source Quench messages should have been coming in, and we should have
a small congestion window, so the amount of data sent after a successful
retransmission acknowledge should be relatively small, perhaps as little as
one packet.
     All this, though, presumes that ICMP Source Quench packets are in fact
being received.  This opens up a fruitful area of study.  It would be 
worthwhile to record the size of the congestion window and some ICMP
reciept statistics whenever a retransmit occurs.  If a TCP is encountering
heavy packet losses but is not receiving Source Quench messages, and we
have no reason to suspect heavy packet loss in the transmission system,
then some overloaded gateway is not generating Source Quench messages
when it should.  It should be easy to check this out. 
     Given that the usual cause of retransmissions is congestion, not
error, it might be worthwhile treating a retransmission timeout as
a congestion indication and shrinking the congestion window as if
a Source Quench had been received.  Give this idea some thought, people.
It would probably help in some situations but may have unexpected side
effects.
     It's good that people are instrumenting their transport protocols.
Most of my insights into network behavior were made possible by a 
heavily instrumented TCP implementation.  

					John Nagle

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Sun, 18-Jan-87 10:01:11 EST
From:      schoff@CSV.RPI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Gateway Monitoring

One of the "up-front" issues of HMP vs what Craig mentioned (using UDP)
that I can see is that HMP does its own multiplexing which will be
done in "user" space.  UDP does it in kernel space right now and we
can leverage off of that.

There are a number of other issues which I'm sure Craig will enumerate.

Cheers for the "hometeam" from the cheap seats,

Marty

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Sun, 18-Jan-87 13:03:29 EST
From:      jbn@GLACIER.STANFORD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Shock load after retransmission acknowlegement


     Craig suggests that I reply to an observation about the shock load that
occurs after a retransmission has been successfully acknowledged and we are now
again sending into an empty window.  The sending TCP, if equipped with
the congestion window mechanism, will send until it runs out of data to
send, the flow control window fills up, or the congestion window fills up,
whichever happens first.  If we are operating in a congested situation,
ICMP Source Quench messages should have been coming in, and we should have
a small congestion window, so the amount of data sent after a successful
retransmission acknowledge should be relatively small, perhaps as little as
one packet.
     All this, though, presumes that ICMP Source Quench packets are in fact
being received.  This opens up a fruitful area of study.  It would be 
worthwhile to record the size of the congestion window and some ICMP
reciept statistics whenever a retransmit occurs.  If a TCP is encountering
heavy packet losses but is not receiving Source Quench messages, and we
have no reason to suspect heavy packet loss in the transmission system,
then some overloaded gateway is not generating Source Quench messages
when it should.  It should be easy to check this out. 
     Given that the usual cause of retransmissions is congestion, not
error, it might be worthwhile treating a retransmission timeout as
a congestion indication and shrinking the congestion window as if
a Source Quench had been received.  Give this idea some thought, people.
It would probably help in some situations but may have unexpected side
effects.
     It's good that people are instrumenting their transport protocols.
Most of my insights into network behavior were made possible by a 
heavily instrumented TCP implementation.  

					John Nagle

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Sun, 18-Jan-87 15:57:51 EST
From:      matt@oddjob.uchicago.edu.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: secure replacements for passwords

J. Spencer Love writes:
) I don't know about your TCP, but the Multics TCP will send a RST
) immediately if it receives a packet with an ACK that it`s too high.  I
) believe that this is clearly spelled out in the specification, but I am
) at home and don't have the specification handy.

Nope, RFC-793 says "If the ACK acks something not yet sent
(SEG.ACK > SND.NXT) then send an ACK, drop the segment, and
return.

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Sun, 18-Jan-87 18:52:19 EST
From:      mills@HUEY.UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Transatlantic pings

Folks,

I boogied with a fuzzball far away (Stuttgart, W. Germany) from here today and
collected the data for another scatter diagram. The results, using ICMP Echo
messages uniformly distributed in length from 40 to 576 octets, proved
rather gruesome. The minimum roundtrip delay was a few hundred milliseconds,
and the maximum almost ten seconds, while the regression line had a y intercept
of 1845, 576-octet intercept of 3927 and slope of 2212 bps (all in milliseconds).
There was a surprisingly large cliff between the singel-packet and multi-packet
regimes at about 127 octets of over one second, reminiscent of the "old" ARPANET
protocols studied in RFC-889 and thought to be reduced in recent years. In fact,
I conclude based on these data alone it is faster to send two 127-octet messages
than one 128-octet message (or whatever the critical size is).

The data show a mean dispersion, but high reliability. Only a single packet was
lost in over 1100 volleys. I conclude this a good data set to experiment with
for TCP tuning. Earlier I FTPed three megabytes of useful data to the Stuttgart
fuzzball using the battered and scarred fuzzball TCP, but with reasonably good
results (I didn't have the chance to capture retransmission counts, etc., with
that transfer). Therefore, I would class this data set as a good example of
a network design that tries to maximize reliability at some cost in delay.
The tests were done on Sunday afternoon. I'll do another one on a day when
things are falling apart.

Both the raw data and Sun-format scatter diagram are on udel2.udel.edu in
anonymous/guest as the files usecom.txt and usecom.bit respectively.

Dave
-------

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      18-Jan-87 23:26:51-UT
From:      mills@huey.udel.edu
To:        tcp-ip@sri-nic.arpa
Subject:   Transatlantic pings
Folks,

I boogied with a fuzzball far away (Stuttgart, W. Germany) from here today and
collected the data for another scatter diagram. The results, using ICMP Echo
messages uniformly distributed in length from 40 to 576 octets, proved
rather gruesome. The minimum roundtrip delay was a few hundred milliseconds,
and the maximum almost ten seconds, while the regression line had a y intercept
of 1845, 576-octet intercept of 3927 and slope of 2212 bps (all in milliseconds).
There was a surprisingly large cliff between the singel-packet and multi-packet
regimes at about 127 octets of over one second, reminiscent of the "old" ARPANET
protocols studied in RFC-889 and thought to be reduced in recent years. In fact,
I conclude based on these data alone it is faster to send two 127-octet messages
than one 128-octet message (or whatever the critical size is).

The data show a mean dispersion, but high reliability. Only a single packet was
lost in over 1100 volleys. I conclude this a good data set to experiment with
for TCP tuning. Earlier I FTPed three megabytes of useful data to the Stuttgart
fuzzball using the battered and scarred fuzzball TCP, but with reasonably good
results (I didn't have the chance to capture retransmission counts, etc., with
that transfer). Therefore, I would class this data set as a good example of
a network design that tries to maximize reliability at some cost in delay.
The tests were done on Sunday afternoon. I'll do another one on a day when
things are falling apart.

Both the raw data and Sun-format scatter diagram are on udel2.udel.edu in
anonymous/guest as the files usecom.txt and usecom.bit respectively.

Dave
-------
-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19-Jan-87 04:35:56 EST
From:      Mills@LOUIE.UDEL.EDU
To:        mod.protocols.tcp-ip
Subject:   Re:  Gateway Monitoring

Mike,

If DARPA and/or DCA is funding development of a a "standard" monitoring and control
protocol, this is not evident to the task-force agenday. XNET is at least seven
years old and HMP is not much younger. Yes, there is need for a new protocol
in this area and BBn might not be doing the actual work.

Dave

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 1987 10:01-PST
From:      STJOHNS@SRI-NIC.ARPA
To:        Mills@louie.udel.edu
Cc:        craig@loki.bbn.com, tcp-ip%sri-nic.arpa@SH.CS.NET
Subject:   Re:  Gateway Monitoring
Dave,  the  reason  this hasn't come up at the IETF is due to the
fact it is still in very rough stages.  }iLet  me  describe  here
what  we  are  trying  to accomplish {_and maybe it will give you
some insights into the project.

What we are trying  to  develop  is  a  standard  Monitoring  and
Control  protocol  which  allows  a  device  on the network to be
described via some notation (I think they  are  using  the  ASN.1
notation)  and  then  compiled  and loaded into the system.  I.e.
few basic types of monitored objects  combined  to  describe  the
device.   THe  idea  is to be able to buy MCs and network objects
from diverse suppliers and still be able to Monitor aand  Control
them.

3 or 4 documents have been completed at least as far as the draft
stage.  If I can get approval once they are complete, I intend to
put them online for comment and also in the DTIC.

Mike
-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19-Jan-87 11:18:32 EST
From:      Mills@LOUIE.UDEL.EDU
To:        mod.protocols.tcp-ip
Subject:   Re:  Analyzing Acknowledgement Strategies

Henry,

Thanks for the vote. So far as I know, I have not restricted distribution
of any of my bleats, just answered what was sent. In the twinkle of keys
I may have blown that model.

You raise a good point, also raised by Gonzoles Arse here: why recurse
on the median filter? The sample data I have collected here are almost
always strongly skewed. They tend to be clustered more-or-less generally
about a median, but with a significant population of gross outliers.
The particular technique I evolved had a rather high seat of pants,
but worked fantastically well with Internet delays.

Dave

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Mon 19 Jan 87 12:46:02-EST
From:      "Dennis G. Perry" <PERRY@vax.darpa.mil>
To:        Mills@louie.udel.edu
Cc:        STJOHNS@sri-nic.ARPA, craig@loki.bbn.com, tcp-ip%sri-nic.arpa@SH.CS.NET, perry@vax.darpa.mil
Subject:   Re:  Re:  Gateway Monitoring
Dave, I am not sure that funding of a standard monitoring and contro9l
protocol is what Mitre is doing.  They are looking at what needs to
be monitored, they want to instrument a gateway and muck around with
measurments, etc.  The ANM progam at BBN is doing monitoring work, but
I am not certain if they are looking at a standard protocol.  I am concerned
about everybody doing their own thing.  Why can we not coordinate all
this and get something useful?

dennis
-------
-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19-Jan-87 14:33:55 EST
From:      geof@decwrl.DEC.COM@imagen.UUCP (Geof Cooper)
To:        mod.protocols.tcp-ip
Subject:   Re:  Analyzing Acknowledgement Strategies, continued

I did some research on timers in TFTP at MIT in 1983, with Karen
Sollins and John Romkey.  The problem at hand was to develop a 
strategy that made TFTP work on both 1200 baud lines and ethernets.
We had time for exactly one test, and it worked in that test.  After
that I left MIT and no one else was interested in tuning the algorithm
further.  I don't have a SCRIBE implementation that is willing to output
this thing without a fuss.  I hesitate to send the note to the entire
list, although it is short.  Perhaps someone would like to be mailed
a copy and act as an FTP gateway for the rest.

The algorithm is different from one previous to it in that it used
something similar to the "timeline" strategy that you outlined.  In
this case, I used the number of retransmissions of successive packets
as an indicator.  I concentrated on avoiding congestion and not on
recovering from lost packets.  The algorithm is interesting in that
it is two algorithms -- one is invoked if everything is going well,
and the other is invoked if recent history suggests that congestion
is going on.

The basic idea was to "get the hell out of there" when you detected
that you were sending multiple retransmissions of each packet.  In
this case, the algorithm increases as N^2 with each successive sample.
The algorithm comes down using a 2-element linear filter [(this+last)/2].
Measurements of the roundtrip time are made only when no retransmissions
occur.  This is the only way that the roundtrip timer can be tightened.
The N^2 backoff can happen any time.

The following is a rough outline of the algorithm.  Recall that in TFTP,
only one data packet can be outstanding.  This packet is retransmitted
until an ACK is received and then the next packet is sent.  Thus, it is
equivalent to a sliding window protocol with window size 1, where each
ACK opens the window.  The particular ACKing strategy is not important,
except that at least one ACK must be generated for each data packet
received.

NT means Number of Transmissions of the current data packet.
(NT = 1) => packet sent once.  When an ACK is received execute:

    MeasuredRoundTripTime := TimeReceivedFirstAck - TimeSentFirstData;
    
    if last_NT = 1 then
        K := K_Init;
    
    if NT = 1 then
        RountripTime := ( MeasuredRoundTripTime + RoundTripTime ) / 2
    else
        begin
            if last_NT > 1 then
                K := K + K_incr;
            RoundTripTime := RoundTripTime + K
        end;

    last_NT = NT;
    NT := 0;
    
When sending a packet, execute:

    RetransmitTime = (1.5 * RoundTripTime) * 2^NT;
    NT := NT + 1;

Initial values are chosen to overestimate the roundtrip time.

======================


Also, Raj Jain (who at least was then) of DEC did some work on retransmission
strategy.  He did some simulations while at MIT's lab for computer science,
and wrote a paper on the results.  I have a draft version of the paper.
It was to be published, but I don't remember where, and I never saw it come
by in print.  Maybe I missed it.  Here is the abstract:

    DIVERGENCE OF TIMEOUT ALGORITHMS FOR PACKET RETRANSMISSIONS
        Raj Jain
        DEC Hudson HLO2-3/N03

    The problem of adaptively setting the timeout interval for retransmitting
a packet has been discussed.  A layered view of the algorithms has been
presented.  It is shown that a timeout algorithm consists of essentially
five layers or procedures which can be independently chosen and modified.
A number of timeout algorithms proposed in the literature have been
decomposed into these five layers.

    One of the key layers not discussed in the literature is that of
determining the sample round trip delay for packets that have been transmitted
more than once.  It is shown that this layer has a significant impact on the
network performance.

    Under repeated packet loss, most timeout algorithms either diverge
or converge to a wrong value.  A number of alternative schemes have been
presented.  It is argued that divergence is preferable to false converence.
It is a feature that is helpful in reducing network traffic during congestion.

    DEC-TR-329
    Version: August 28, 1985

- Geof

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19-Jan-87 14:42:47 EST
From:      brescia@CCV.BBN.COM (Mike Brescia)
To:        mod.protocols.tcp-ip
Subject:   Re: Gateway Monitoring

Re: de-multiplexing -

TOPS-20 allows distribution to a user process of any protocol which does not
conflict with any other already used (kernel) protocol, and also allows
demultiplexing within a single protocol based on a port number (declared by
the user to be a mask and value combination somewhere in the first 4 bytes).
Thus, I can use XNET (protocol 15), since the kernel does nothing with it, and
also another user can use XNET as well, since there is a port number which is
used to distinguish her info from mine.

I would like to see UNIX able to give me the packets not explicitly granted to
the kernel.  I could then run an EGP tester (or a GGP spoofer) in user mode.

cf. Bill of Rights, Article 10.

    Mike

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 87 14:42:47 EST (Mon)
From:      Mike Brescia <brescia@ccv.bbn.com>
To:        Martin Schoffstall <schoff@csv.rpi.edu>
Cc:        STJOHNS@sri-nic.ARPA, craig@loki.bbn.com, brescia@ccv.bbn.com tcp-ip@sri-nic.ARPA
Subject:   Re: Gateway Monitoring
Re: de-multiplexing -

TOPS-20 allows distribution to a user process of any protocol which does not
conflict with any other already used (kernel) protocol, and also allows
demultiplexing within a single protocol based on a port number (declared by
the user to be a mask and value combination somewhere in the first 4 bytes).
Thus, I can use XNET (protocol 15), since the kernel does nothing with it, and
also another user can use XNET as well, since there is a port number which is
used to distinguish her info from mine.

I would like to see UNIX able to give me the packets not explicitly granted to
the kernel.  I could then run an EGP tester (or a GGP spoofer) in user mode.

cf. Bill of Rights, Article 10.

    Mike
-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19-Jan-87 15:34:34 EST
From:      Mills@LOUIE.UDEL.EDU
To:        mod.protocols.tcp-ip
Subject:   Re:  Re: Gateway Monitoring

Dennis,

The NSFnet crew is stumbling into this sandbox right now. I suspect they
would be glad to move their discussion to this list if everybody can
stand it. With the exception of the CMCC work done several years ago
at BBN, which was broadly discussed and documented (see IENs at the
NIC), HMPs in recent years have evolved to serve specialized processors,
linke IMPs (aka PSNs), LSI-11 gateways, Buttergates and related insects.
At least with respect to the DoD community, host monitoring has been
considered private business and available only to a closed community
with few subscribers. While this may be wholly appropriate for this
community, it may not be always appropriate for the academic community.
It would be wonderful if consensus could be achieved on a public protocol
which could be implemented widely and with access controls specialized
only as necessary. From the experience of the CMCC days, as well as the
evolution of HMP, I would not rate this as a sure thing.

Dave

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19-Jan-87 16:19:54 EST
From:      Mills@LOUIE.UDEL.EDU
To:        mod.protocols.tcp-ip
Subject:   Re:  Gateway Monitoring


Mike,

Thanks for the info. It might be very useful to all of us, including the
contractor, if those drafts could be distributed to the task forces before
being cast in DTIC. Sparta did that with their DCEC reports and we had much
joy.

Dave

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Mon 19 Jan 87 16:59:47-EST
From:      "Dennis G. Perry" <PERRY@vax.darpa.mil>
To:        craig@loki.bbn.com
Cc:        perry%vax.darpa.mil@SH.CS.NET, mills@louie.udel.edu, perry@vax.darpa.mil
Subject:   Re: Gateway Monitoring Etc.
Craig, I will give my opinion, knowing that there are yet messages for
me to read that will alter it.

NSF needs to become part of the community.  In their rush outdo eveyone
else in the world in networking, they have created a monster that will
become impossible to controll if someting isn't done soon.  The IETF should
get their act together and form a working group, including NSF people, and
come up with a spec that can be discussed in the IETF and a singel, agreed
upon RFC drafted.  I don't believe that this is an impossible task.  If
it is not done this way the NSF crowd will always be off on their own
creating who knows what and generating a rift in the networking community.
Phil Gross of Mitre iss part of the IETF, so getting Mitre involved should
not be difficult.

dennis
-------
-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20-Jan-87 01:07:40 EST
From:      hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
To:        mod.protocols.tcp-ip
Subject:   how to make use of redundant routes

We are just now beginning to look at making use of redundant routes,
to provide some extra reliability in our network.  For our internal
routing, we have dedicated gateways that handle most of the traffic.
(2 Cisco gateways, plus a home-brew gateway that is similar in
technology to Cisco's.)  There is no redundancy among those gateways.
However we also have various Unix machines with multiple interfaces.
If we set them all up to act as gateways, we could survive any gateway
being down.  However I'm somewhat unclear how to maintain our hosts'
routing tables.  Unix seems to be set up to get routing information
through both routed and routing directs.  Unfortunately, it seems that
these two techniques interact unfavorably.  Initially, I had the idea
that redirects alone might do the job.  But that clearly can't work.
If the current gateway goes down, there's nobody to issue a redirect
to someplace else.  4.3 makes this somewhat better by killing the
current route when a TCP connection is about to time out.  But that
doesn't help us with NFS, which uses only UDP.  The same problem
applies to our current kludge of using proxy ARP's.  I am beginning to
come to the view that there is no real alternative to routed or
something like that.  However the vanilla routed still has potential
problems.  If a gateway issues a host redirect, the kernel makes an
entry in the routing table that routed doesn't know about.  Should the
gateway named in the redirect go down, routed will not know that it
should remove that host route.  The only complete solution I have seen
is Cornell's gated.  If you ignore its support for EGP and HELLO
(which are not relevant in our situation), it can be thought of as a
souped-up routed.  Unlike routed, it uses a raw socket which gets
copies of every redirect received by the kernel.  Thus it is able to
maintain a model of exactly what routes the kernel has.  Presumably
this would allow gated to remove routes that no longer apply.  Some
folks here are reluctant to use gated on every one of our
workstations.  We have an aversion to regularly activating daemons on
diskless Suns.  (Although we don't have any real problems with them,
swapping over the network provides a certain incentive to minimize the
number of programs that get swapped in at regular intervals.)  There
is also a feeling that gated is large enough that we are probably not
going to understand what it is doing.  However I'm beginning to think
that its approach is inevitable.  I have thought of one alternative,
but I'm not sure that it has enough advantages to be worth coding.
That is a program that monitors routed traffic and keeps track of what
gateways are up.  It would not do anything with the contents of the
packets -- just remember what gateways are currently sending them.
The program would guarantee that there is always a default route that
points to a gateway that is up.  It would periodically examine the
routes in the kernel (using code stolen from netstat, presumably), and
kill any that involved gateways that are no longer up.  One might also
look at the use count field, and get rid of routes that haven't been
used for a certain period of time.  Presumably this program would be
smaller than gated, and I think I would also be more likely to
understand exactly what it is doing.  But I'm not sure I want to add
yet another routing daemon.  (The only approach I can think of other
than monitoring the gateways' routing protocol is to ping each gateway
periodically.  That would work, of course, but it would create more
network traffic.)  I'm reasonably convinced than any system acting as
an actual gateway should run gated.

I'd be curious to hear comments from places that have been using
dynamic routing for some time.  By the way, I am willing to assume
that all gateways participate in routing using routed.  (Cisco now
supports routed.)

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 1987 09:22-PST
From:      STJOHNS@SRI-NIC.ARPA
To:        PERRY@VAX.DARPA.MIL
Cc:        hwb@MCR.UMICH.EDU, tcp-ip@SRI-NIC.ARPA craig@LOKI.BBN.COM
Subject:   Re: Gateway Monitoring.
I've already asked Phill to set aside an hour at the next IETF to
discuss M&C issues.  Currently, I'm moderating it and I  hope  to
keep  it to essentials as we don't have a lot of time.  Send me a
note if you want to speak up during the session (for more than  a
minute  at  a  time)  so  I  can get some idea of how to schedule
people in.  The M&C Session will probably  be  afternoon  Friday.
Mike
-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 1987 07:35-EST
From:      CERF@a.isi.edu
To:        STJOHNS@SRI-NIC.ARPA
Cc:        craig@loki.bbn.com, tcp-ip%sri-nic.arpa@SH.CS.NET
Subject:   Re: Gateway Monitoring
Mike,

I had heard a rumor recently (gosh, I sure hope I am NOT
STARTING one!) that there had been some thought that HMP was
only a framework into which monitoring semantics had to be
fitted and that it might be more efficient to operate directly
on UDP with something more application specific to increase
efficiency. Could this motivate a re-examination of gateway
monitoring?

Vint
-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20-Jan-87 08:30:00 EST
From:      NS-DDN@DDN2.UUCP
To:        mod.protocols.tcp-ip
Subject:   FTP Restart


 
Has anyone successfully implemented the FTP restart support? Can anyone explain
definitively how it should work? I'm not confident that I've got a handle on
how it actually works according to RFC959. It appears that something like the
following must happen (illustrating on a three-party model):
 
  Host A:User-PI    ==> Host B:Server-PI   [Establish session]
  Host A:User-PI    ==> Host C:Server-PI   [Establish session]
  Host A:User-PI    ==> Host B:Server-PI   "PASV"<CRLF>
  Host A:User-PI    <== Host B:Server-PI   "227 10,1,0,1,16,5"<CRLF>
  Host A:User-PI    ==> Host C:Server-PI   "PORT 10,1,0,1,16,5"<CRLF>
  Host A:User-PI    <== Host C:Server-PI   "220 Okay"<CRLF>
  Host A:User-PI    ==> Host B:Server-PI   "MODE B"<CRLF>
  Host A:User-PI    ==> Host C:Server-PI   "MODE B"<CRLF>
  Host A:User-PI    <== Host B:Server-PI   "220 Okay"<CRLF>
  Host A:User-PI    <== Host C:Server-PI   "220 Okay"<CRLF>
  Host A:User-PI    ==> Host B:Server-PI   "STOR bigfile"<CRLF>
  Host A:User-PI    ==> Host C:Server-PI   "RETR bigfile"<CRLF>
  Host C:Server-DTP ==> Host B:User-DTP    [Establish session]
  Host A:User-PI    <== Host B:Server-PI   "125 Transfer started"<CRLF>
  Host A:User-PI    <== Host C:Server-PI   "125 Transfer started"<CRLF>
  Host C:Server-DTP ==> Host B:User-DTP    BH = 0,64,0, [1st 16Kbytes of data]
  Host C:Server-DTP ==> Host B:User-DTP    BH = 0,64,0, [2nd 16Kbytes of data]
  Host C:Server-DTP ==> Host B:User-DTP    BH = 0,64,0, [3rd block of data]
  Host C:Server-DTP ==> Host B:User-DTP    BH = 0,64,0, [4th block of data]
  Host C:Server-DTP ==> Host B:User-DTP    BH = 16,0,8, "SOFAR001"
 
Obviously Host C supports restarting. Now it's up to Host B. If he does not
support restarts, he ignores the restart marker and continues receiving data.
Otherwise, he figures out where he is in his file, does whatever needs to be
done to ensure that come what may, this much of the received data will survive
a catastrophe, constructs his restart marker (e.g., "MINE0001"), and:
 
  Host A:User-PI    <== Host B:Server-PI   "110 MARK MINE0001 = SOFAR001"<CRLF>
  Host C:Server-DTP ==> Host B:User-DTP    BH = 0,64,0, [5th block of data]
  Host C:Server-DTP ==> Host B:User-DTP    BH = 0,64,0, [6th block of data]
  Host C:Server-DTP ==> Host B:User-DTP    BH = 0,64,0, [7th block of data]
  Host C:Server-DTP ==> Host B:User-DTP    BH = 0,64,0, [8th block of data]
  Host C:Server-DTP ==> Host B:User-DTP    BH = 16,0,8, "SOFAR002"
  Host A:User-PI    <== Host B:Server-PI   "110 MARK MINE0002 = SOFAR002"<CRLF>
  Host C:Server-DTP ==> Host B:User-DTP    BH = 0,64,0, [9th block of data]
 
Then the unthinkable happens. The building engineer pulls the wrong switch, and
Host B goes to Never-Never Land. Host C gives up upon discovering Host B will
have to be resurected...
 
  Host A:User-PI    <== Host C:Server-PI   "426 Transfer aborted"<CRLF>
 
while Host A is also telling the end user that his PI session with Host B is
history. Some time in the future, the end user receives a birth announcement,
at which point he reestablishes his PI sessions, performing the same sequence of
events up through the MODE B commands. Then, having noted the last 110 reply he
received before the crash, he does the following:
 
  Host A:User-PI    ==> Host B:Server-PI   "REST SOFAR002"<CRLF>
  Host A:User-PI    ==> Host C:Server-PI   "REST MINE0002"<CRLF>
  Host A:User-PI    <== Host B:Server-PI   "350 Ready to restart"<CRLF>
  Host A:User-PI    <== Host C:Server-PI   "350 Ready to restart"<CRLF>
  Host A:User-PI    ==> Host B:Server-PI   "STOR bigfile"<CRLF>
  Host A:User-PI    ==> Host C:Server-PI   "RETR bigfile"<CRLF>
  Host C:Server-DTP ==> Host B:User-DTP    [Establish session]
  Host A:User-PI    <== Host B:Server-PI   "125 Transfer started"<CRLF>
  Host A:User-PI    <== Host C:Server-PI   "125 Transfer started"<CRLF>
  Host C:Server-DTP ==> Host B:User-DTP    BH = 0,64,0, [9th block of data]
 
and on to a happy ending. Did I get it right?
 
With deep appreciation to (and awed admiration of) all who read this far, I am
 
Dave Craig
Network Solutions, Inc.

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 87 08:30 EST
From:      NS-DDN @ DDN2
To:        tcp-ip @ SRI-NIC.ARPA
Subject:   FTP Restart

 
Has anyone successfully implemented the FTP restart support? Can anyone explain
definitively how it should work? I'm not confident that I've got a handle on
how it actually works according to RFC959. It appears that something like the
following must happen (illustrating on a three-party model):
 
  Host A:User-PI    ==> Host B:Server-PI   [Establish session]
  Host A:User-PI    ==> Host C:Server-PI   [Establish session]
  Host A:User-PI    ==> Host B:Server-PI   "PASV"<CRLF>
  Host A:User-PI    <== Host B:Server-PI   "227 10,1,0,1,16,5"<CRLF>
  Host A:User-PI    ==> Host C:Server-PI   "PORT 10,1,0,1,16,5"<CRLF>
  Host A:User-PI    <== Host C:Server-PI   "220 Okay"<CRLF>
  Host A:User-PI    ==> Host B:Server-PI   "MODE B"<CRLF>
  Host A:User-PI    ==> Host C:Server-PI   "MODE B"<CRLF>
  Host A:User-PI    <== Host B:Server-PI   "220 Okay"<CRLF>
  Host A:User-PI    <== Host C:Server-PI   "220 Okay"<CRLF>
  Host A:User-PI    ==> Host B:Server-PI   "STOR bigfile"<CRLF>
  Host A:User-PI    ==> Host C:Server-PI   "RETR bigfile"<CRLF>
  Host C:Server-DTP ==> Host B:User-DTP    [Establish session]
  Host A:User-PI    <== Host B:Server-PI   "125 Transfer started"<CRLF>
  Host A:User-PI    <== Host C:Server-PI   "125 Transfer started"<CRLF>
  Host C:Server-DTP ==> Host B:User-DTP    BH = 0,64,0, [1st 16Kbytes of data]
  Host C:Server-DTP ==> Host B:User-DTP    BH = 0,64,0, [2nd 16Kbytes of data]
  Host C:Server-DTP ==> Host B:User-DTP    BH = 0,64,0, [3rd block of data]
  Host C:Server-DTP ==> Host B:User-DTP    BH = 0,64,0, [4th block of data]
  Host C:Server-DTP ==> Host B:User-DTP    BH = 16,0,8, "SOFAR001"
 
Obviously Host C supports restarting. Now it's up to Host B. If he does not
support restarts, he ignores the restart marker and continues receiving data.
Otherwise, he figures out where he is in his file, does whatever needs to be
done to ensure that come what may, this much of the received data will survive
a catastrophe, constructs his restart marker (e.g., "MINE0001"), and:
 
  Host A:User-PI    <== Host B:Server-PI   "110 MARK MINE0001 = SOFAR001"<CRLF>
  Host C:Server-DTP ==> Host B:User-DTP    BH = 0,64,0, [5th block of data]
  Host C:Server-DTP ==> Host B:User-DTP    BH = 0,64,0, [6th block of data]
  Host C:Server-DTP ==> Host B:User-DTP    BH = 0,64,0, [7th block of data]
  Host C:Server-DTP ==> Host B:User-DTP    BH = 0,64,0, [8th block of data]
  Host C:Server-DTP ==> Host B:User-DTP    BH = 16,0,8, "SOFAR002"
  Host A:User-PI    <== Host B:Server-PI   "110 MARK MINE0002 = SOFAR002"<CRLF>
  Host C:Server-DTP ==> Host B:User-DTP    BH = 0,64,0, [9th block of data]
 
Then the unthinkable happens. The building engineer pulls the wrong switch, and
Host B goes to Never-Never Land. Host C gives up upon discovering Host B will
have to be resurected...
 
  Host A:User-PI    <== Host C:Server-PI   "426 Transfer aborted"<CRLF>
 
while Host A is also telling the end user that his PI session with Host B is
history. Some time in the future, the end user receives a birth announcement,
at which point he reestablishes his PI sessions, performing the same sequence of
events up through the MODE B commands. Then, having noted the last 110 reply he
received before the crash, he does the following:
 
  Host A:User-PI    ==> Host B:Server-PI   "REST SOFAR002"<CRLF>
  Host A:User-PI    ==> Host C:Server-PI   "REST MINE0002"<CRLF>
  Host A:User-PI    <== Host B:Server-PI   "350 Ready to restart"<CRLF>
  Host A:User-PI    <== Host C:Server-PI   "350 Ready to restart"<CRLF>
  Host A:User-PI    ==> Host B:Server-PI   "STOR bigfile"<CRLF>
  Host A:User-PI    ==> Host C:Server-PI   "RETR bigfile"<CRLF>
  Host C:Server-DTP ==> Host B:User-DTP    [Establish session]
  Host A:User-PI    <== Host B:Server-PI   "125 Transfer started"<CRLF>
  Host A:User-PI    <== Host C:Server-PI   "125 Transfer started"<CRLF>
  Host C:Server-DTP ==> Host B:User-DTP    BH = 0,64,0, [9th block of data]
 
and on to a happy ending. Did I get it right?
 
With deep appreciation to (and awed admiration of) all who read this far, I am
 
Dave Craig
Network Solutions, Inc.

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20-Jan-87 09:10:00 EST
From:      NS-DDN@DDN2.UUCP
To:        mod.protocols.tcp-ip
Subject:   FTP Enhancements


 
I would like to see FTP enhanced in the following areas:
 
  1.  Provide support for the "ARC" standard which seems to be well-established
      on PC bulletin boards. The benefits of very dense data should be obvious
      to all. However, all hosts need to be able to ARC/DEARC files. I do not
      know if the algorithms these programs use are proprietary, but there do
      seem to be multiple vendors providing interoperable (more or less)
      products. I think an Internet ARC standard would lead to significant
      gains in data throughput, especially if it were incorporated into SMTP as
      well.
 
  2.  Provide support for TAC terminals. I suspect that most of the terminals
      on TACs are in fact emulated on PCs. To download data in any form through
      a TAC is not impossible assuming the user has access to an internet host
      which extends to him interactive privileges (and since that what TACs are
      used for...), but it certainly is cumbersome! I remember reading some
      talk of Kermit support though TACs some time back, but nothing seems to
      have come of it.
 
Does anybody know if either of these is in the works? Are they good ideas?
Who's in charge here?
 
Dave Craig
Network Solutions, Inc.

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 87 09:10 EST
From:      NS-DDN @ DDN2
To:        tcp-ip @ SRI-NIC
Subject:   FTP Enhancements

 
I would like to see FTP enhanced in the following areas:
 
  1.  Provide support for the "ARC" standard which seems to be well-established
      on PC bulletin boards. The benefits of very dense data should be obvious
      to all. However, all hosts need to be able to ARC/DEARC files. I do not
      know if the algorithms these programs use are proprietary, but there do
      seem to be multiple vendors providing interoperable (more or less)
      products. I think an Internet ARC standard would lead to significant
      gains in data throughput, especially if it were incorporated into SMTP as
      well.
 
  2.  Provide support for TAC terminals. I suspect that most of the terminals
      on TACs are in fact emulated on PCs. To download data in any form through
      a TAC is not impossible assuming the user has access to an internet host
      which extends to him interactive privileges (and since that what TACs are
      used for...), but it certainly is cumbersome! I remember reading some
      talk of Kermit support though TACs some time back, but nothing seems to
      have come of it.
 
Does anybody know if either of these is in the works? Are they good ideas?
Who's in charge here?
 
Dave Craig
Network Solutions, Inc.

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20-Jan-87 09:56:58 EST
From:      mckee@MITRE.ARPA (H. Craig McKee)
To:        mod.protocols.tcp-ip
Subject:   Re: Analyzing Acknowledgement Strategies

>ps- perhaps we should take this discussion off line?  I've been
>   filling up peoples' mailboxes lately and I get the impression
>   that there are only two or three of us interested in this topic.

I expect/hope many people are interested.  The current MIL-STD 1777
and 1778 are incomplete; they need a section called Implementation
Guidelines.  The work that you, Mills, Nagle, Partridge, et al are doing
will be the basis of that section.  At any rate, while I can contribute
little more than intense interest, please include me in your
discussions.

I would particularly like to hear from John Nagle on:

>A quick look at some trace data suggested that there was a problem
>when you resumed normal behavior after a retransmit.  Since you'll
>always be sending into an empty window at this point, 4.3 will blast
>out 8 back-to-back packets.  A couple of packets near the end of this
>blast are almost certain to be dropped so you'll end up in retransmit
>state 2 RTT after the previous recovery.

I would offer the following comment: Packets are lost by Gateways, not
PSNs.  The PSNs can protect themselves against an input overload from
subscribers; Gateways can only whimper Source Quench.  Accordingly, we
should thump on the egp-people people to "do something."

Regards - Craig

--------

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 1987 10:15-EST
From:      CERF@A.ISI.EDU
To:        NS-DDN@DDN2.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: FTP Enhancements
Dave (Craig) -

If the ARC you reference is the compression method often used for
software distribution from bulletin boards, then I am very much
in support of the idea of exploring this as a possible agreed
convention within the Internet community. Now, having said that,
I must confess ignorance of the details of ARC/DEARC and thus concern 
that the specifics might be very geared toward MS-DOS or other PC
system and not readily adaptable to more complex file structures
and directory systems. But since I am not knowledgeable about the details,
these concerns are really just the usual generic worries one has about
the breadth of any proposed convention.

Vint
-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20-Jan-87 11:00:46 EST
From:      hwb@MCR.UMICH.EDU (Hans-Werner Braun)
To:        mod.protocols.tcp-ip
Subject:   Re: Gateway Monitoring.

It is not exactly appropriate or fair to bang on Craig's head about the
efforts he is undertaking. He was kind of pushed by the NSFnet folks to
start organizing the efforts concerning the immediate need for gateway 
monitoring. What is the alternative to get a concerted effort underway
which would bear results within the next four or five months (or
sooner)? We have a real immediate need right now which will require
monitoring to work in a multi vendor environment REAL SOON.

	-- Hans-Werner

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20-Jan-87 12:12:04 EST
From:      leiner@ICARUS.RIACS.EDU
To:        mod.protocols.tcp-ip
Subject:   Re: Gateway Monitoring

Craig,

As you probably are aware, there has been quite a bit of work done
already in "monitoring".  In fact, Jil Westcott at BBN has been doing
some work in automated network monitoring related to ADDCOMPE and packet
radio networks.  There have also been several proposals for "monitoring
protocols".

I'm happy to see you working in this area.  It is clearly critical for
large internets like NSFnet and the evolving national research internet.
Hopefully, with this new push, a "standard approach" can be developed.

Barry

> From: Craig Partridge <craig@loki.bbn.com>
> Subject: Gateway Monitoring
> To: tcp-ip%sri-nic.arpa@SH.CS.NET
> Date: Fri, 16 Jan 87 14:58:59 -0500
> 
> 
>     The people working on network and gateway monitoring for NSFNET
> have decided that we'd like to develop a gateway monitoring protocol
> using UDP as the transport protocol.
> 
>     To this end I've been tapped to write an RFC specifying how monitoring
> will be done with UDP.
> 
>     The purpose of this note is to announce the creation of a short-lived
> (I hope) mailing list, gwmon@sh.cs.net, for people who are interested
> in *actively* assisting me in writing the RFC.   People who "just want
> to listen in" are discouraged -- I'm really trying to create a small
> discussion group of people who are seriously interested.
> 
>     Mail request to join the list to gwmon-request@sh.cs.net
> 
> Cheers,
> 
> Craig Partridge
> NSF Network Service Center (NNSC)

----------

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      Tue 20 Jan 87 12:14:02-EST
From:      Dennis G. Perry <PERRY@vax.darpa.mil>
To:        hwb@mcr.umich.edu
Cc:        perry@vax.darpa.mil, stjohns@sri-nic.arpa, tcp-ip@sri-nic.arpa, craig@loki.bbn.com, perry@vax.darpa.mil
Subject:   Re: Gateway Monitoring.
HW,
I think there are answers to your concerns, especially if we all work together.
There are also answeres if we work separately, but those answeres may be to
different questions. Attached is my ideas of how we could procede, in a 
rapid manner, and still work towards a common solution.

dennis
-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20-Jan-87 13:13:14 EST
From:      hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
To:        mod.protocols.tcp-ip
Subject:   Re: Gateway Monitoring

Mike Brescia asks for a facility under Unix that will allow you to
receive any packet type that the kernel doesn't need.  The Ethernet
packet filter (/dev/enet) will do this.  There is supposedly a
copy of this software included with 4.3.  We use it on a Pyramid
to implement PUP.  (We can't give it to you, as our copy is covered
by a license with Xerox.)

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20-Jan-87 14:58:00 EST
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
To:        mod.protocols.tcp-ip
Subject:   how to make use of redundant routes


    Date: Tue, 20 Jan 87 01:07:40 est
    From: hedrick@topaz.rutgers.edu (Charles Hedrick)

    I'd be curious to hear comments from places that have been using
    dynamic routing for some time.  By the way, I am willing to assume
    that all gateways participate in routing using routed.  (Cisco now
    supports routed.)

Users of the Chaosnet protocol have been using dynamic routing for
nearly 10 years now.  Chaosnet is MIT AI memo number 628.  I think it is
online at MIT someplace, but can't find it.  (Snit: it's always bothered
me that IP didn't address this issue from the start.)

A very brief description of Chaos routing follows, so those wishing to
type D(elete) now can go ahead.

Chaosnet only has 255 subnets (which is a problem for very large
configurations, and therefore this may not prove useful for IP, but I
had ideas back in '81 or so on how to extend this kind of routine to IP.
JNC may remember some of them.)  With only 256 subnets, keeping a full
subnet routing table was not hard.  Periodically (every 15 seconds) a
multiple interface bridge would broadcast a routing packet on each
interface.  The routing packet contained several pairs: a subnet number
and a "cost" to get to that subnet.  Periodically (every 4 seconds) each
machine would increment all costs in the table by 1.  When processing a
routing packet, an entry would get replaced if the cost in the routing
packet is smaller than the cost in the current entry.

If you are interested in my extensions to IP / heirarchical addressing
schemes, I can try to dig them up.

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20-Jan-87 17:56:00 EST
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
To:        mod.protocols.tcp-ip
Subject:   FTP Enhancements


    Date: 20 Jan 87 09:10 EST
    From: NS-DDN @ DDN2
 
    I would like to see FTP enhanced in the following areas:

@begin(open mouth, position foot near said, don asbestos suit)

Wouldn't it be better to replace FTP with something real?

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Tue 20 Jan 87 22:26:50-EST
From:      Dennis G. Perry <PERRY@vax.darpa.mil>
To:        CERF@a.isi.edu
Cc:        NS-DDN@ddn2.arpa, tcp-ip@sri-nic.arpa, perry@vax.darpa.mil
Subject:   Re: FTP Enhancements
All,
there is a version of ARC that runs on unix.  I picked it up from
the mod.sources, so it is available whereever those are archived.
It uses various compression schemes, depending upon which yeilds
the highest compression.  I download ARCed files all the time with
FTP binary mode.  Some version of Kermit will compress even further
in the file transfer.  I use Kermit to get the file off the vax to
my Rainbow at home.  Limits of ARC on unix seem to be those Vint
alluded to, i.e. PC related issues such as file name length, etc.

dennis
-------
-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      Tue 20 Jan 87 22:39:29-EST
From:      "Dennis G. Perry" <PERRY@vax.darpa.mil>
To:        CERF@a.isi.edu
Cc:        STJOHNS@sri-nic.ARPA, craig@loki.bbn.com, tcp-ip%sri-nic.arpa@SH.CS.NET, perry@vax.darpa.mil
Subject:   Re: Gateway Monitoring
In all the network monitoring, has anyone thought about the security
aspects needed for such protocols?  Or will we just rush in where
Artifically Intelligent machines fear to tread?

dennis
-------
-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21-Jan-87 00:48:18 EST
From:      JNC@XX.LCS.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Looking for DDN/X.25 to TCP/IP router


	Much as you (and I) like 1822, I am given to understand that
requests for new connections using 1822 are no longer being accepted,
unless you can come up with a good reason. Progress marches on...

	Noel
-------

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21-Jan-87 01:00:15 EST
From:      JNC@XX.LCS.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: how to make use of redundant routes


	For the 59th time, an RFC (RFC816) in the 'Internet Protocol
Implementors Guide' discusses exactly how to use Redirects, and how to
figure out that your gateway is dead. The issue was addressed years
ago in detail, but apparently nobody bothers to read the specs.
	I won't both to waste my time pointing out that having hosts
listening to routing protocols is a terrible idea; nobody ever
believes me. Also, RIP is a piece of junk. It doesn't even work with
the current EGP, let alone with any followon. It's too bad that a) it
was around before any other IGP was, and b) it was in the Berkeley
system, because now we'll never get rid of it.

	Noel
-------

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21-Jan-87 02:52:33 EST
From:      hedrick@TOPAZ.RUTGERS.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: how to make use of redundant routes

Noel:

I appreciate your advice, but really, the people you should be flaming
at are not me, but Berkeley and the various vendors.  My problem is
very different than Berkeley's: I have to deliver reliable service
given products that actually exist. RFC816 says basically

  - somehow you keep track of what gateways are up
  - when you want to talk to somebody, try a gateway, and depend
	upon redirects to get the actual address
  - when a gateway goes down, just get rid of routes that use it.
	This will result in trying another random gateway, which
	will again tell you if there is a better one.

For keeping track of what gateways are up, RFC816 mentions

  - depend upon the network to tell you when a packet isn't
	delivered.
  - ping them regularly
  - depend upon the upper layers [for us, TCP and NFS] to tell
	you when a route no longer works.  When a route
	stops working, assume that its gateway is down.

Now, let's look at how much of that advice I can actually use.  I have
mostly Suns.  This means I have 4.2 networking.  I know that's
horrible, but there isn't a lot of real 4.3 in the marketplace yet.
I'm not in a position to implement my own, or even to port 4.3 to the
Sun.  In a 4.2 world, none of the suggestions in RFC816 look very
attractive.  Ethernet obstinately refuses to tell me that it is unable
to deliver a packet.  The one implementation that tried to ping all of
the gateways it knew about [TOPS-20] was roundly condemned by all.
And 4.2 has no feedback from the upper layers to the lower ones.
[Indeed even in 4.3, it's not clear whether the feedback is good
enough that you can really depend upon it in practice.  I'd like to
hear from anybody who has experience in this area.  If you just use
the route command to set up several default gateways, will 4.3 really
manage to keep up communications, using just redirects and hints from
TCP?  Note that for many of my users, the main application they are
using through the gateway is NFS, which is UDP-based.]

Since none of these methods seems very attractive, I proposed the next
best thing that I could think of: watching the routing traffic between
the gateways.  I don't propose to look in the packets.  I'm just
trying to keep track of what gateways are sending them.  If you hate
routed, imagine that I am watching Cisco's IGRP traffic (which is by
no means impossible).  Given this, I thought I was proposing something
that was very much in the spirit of RFC816.  I proposed a daemon that
would do the following:

  - keep track of what gateways are up, by listening to their
	routing traffic
  - periodically scan the routes in the kernel
  - when it finds a route that uses a dead gateway, remove the route.
	In Unix, this means that traffic will revert to the default
	gateway, which will then redirect it to a better one if there
	is any.  This is exactly what RFC816 says.
  - it would manage the default routing entry, to make sure that it
	always points to a gateway that is up.

What I asked was whether anyone has experience with such a thing, and
can advise me on whether it is really worth doing this instead of
just using routed.  I also mentioned some practical problems that
would have to be solved before we could really rely on routed.

I really have been trying to follow your advice.  I have tried to
avoid using routed.  I find that I am moving that way, because my
connections with NSFnet, and use of various random Unix machines as
gateways, provide little choice.  Cisco, who supplies our core
gateways, had tried to avoid routed as well, but has finally caved in
to the inevitable.  It would help a lot if there were a standard
defining something better.  When the current efforts in this direction
result in something, I'll be happy to push the vendors we deal with to
implement it.

I'd be happy to join you in a campaign lobbying vendors for
implementations that follow the RFC's.  But please don't yell at me.
I'm just trying to do something reasonable with the tools I have.

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Jan 87 10:20:28 pst
From:      David Cheriton <cheriton@pescadero.stanford.edu>
To:        tcp-ip@sri-nic.ARPA
Subject:   Gateway monitoring protocols
Responding in part to Dennis's question,  it seems appropriate to me to view
security as a transport-level functionality (unless the security demands are
extreme and application-specific).  Thus, I would like to broaden his question
slightly to:
What is the currently thinking by those involved on the provision of transport
functionality for a monitoring protocol.  This includes: transport-level 
addressing, error control and sequencing, flow control and security.

My opinion: gateways are a service or server in the distributed systems sense.
We should be able to contact this service using a standard RPC-like protocol
suite, at least for monitoring and control.  Only gateway-specific
"procedures" need to be specialized, not the transport and presentation levels.

Getting there: Bob Braden's end-to-end task force is looking at various
candidates for a "transaction protocol" (see RFC 955). There has also been
some discussion of presentation-level protocols.  (I have a candidate
protocol, VMTP, responding to RFC 955 which I hope to RFC in the near future.)

It would be helpful for the monitoring protocol people to think in terms of
this protocol structure or else indicate why this approach is unworkable.
Otherwise, we may have an explosion of higher-level and management protocols,
all solving the transport and presentation levels issues differently.
David C.
-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21-Jan-87 10:27:36 EST
From:      gross@MITRE-GATEWAY.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Gateway Monitoring.

If the measure of a hot topic is the number of messages generated per
unit time, then gateway monitoring is the latest sizzle.

Mitre is instrumenting a gateway work in order to 1) make baseline 
traffic profile studies, 2) perform congestion control experiments 
and then 3) compare results.  We are not designing a new monitoring 
protocol, but I agree that one is desperately needed.  Working together
is a clear win and I agree that the IETF can provide a timely forum.

I will put this on the agenda for a half day or day long workshop
at the upcoming IETF.  (There was already a performance workshop 
planned and this will replace it.)  

Phill

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 1987 16:18-PST
From:      STJOHNS@SRI-NIC.ARPA
To:        PERRY@vax.darpa.mil
Cc:        CERF@a.isi.edu, craig@loki.bbn.com tcp-ip%sri-nic.arpa@SH.CS.NET
Subject:   Re: Gateway Monitoring
Part  of  the  work  under  the  Uniform Device Support task (UDS
forever more) there is some consideration given to security.   As
I remember it was based on encryption ala DES.

Further  than  that I can't say until I spend about a week review
the mountain of documents pertaining to this project.  Mike
-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21-Jan-87 13:20:28 EST
From:      cheriton@PESCADERO.STANFORD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Gateway monitoring protocols

Responding in part to Dennis's question,  it seems appropriate to me to view
security as a transport-level functionality (unless the security demands are
extreme and application-specific).  Thus, I would like to broaden his question
slightly to:
What is the currently thinking by those involved on the provision of transport
functionality for a monitoring protocol.  This includes: transport-level 
addressing, error control and sequencing, flow control and security.

My opinion: gateways are a service or server in the distributed systems sense.
We should be able to contact this service using a standard RPC-like protocol
suite, at least for monitoring and control.  Only gateway-specific
"procedures" need to be specialized, not the transport and presentation levels.

Getting there: Bob Braden's end-to-end task force is looking at various
candidates for a "transaction protocol" (see RFC 955). There has also been
some discussion of presentation-level protocols.  (I have a candidate
protocol, VMTP, responding to RFC 955 which I hope to RFC in the near future.)

It would be helpful for the monitoring protocol people to think in terms of
this protocol structure or else indicate why this approach is unworkable.
Otherwise, we may have an explosion of higher-level and management protocols,
all solving the transport and presentation levels issues differently.
David C.

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21-Jan-87 13:52:00 EST
From:      mogul@DECWRL.DEC.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Packet filter (was Re: Gateway Monitoring)

Charles Hedrick writes:

    Mike Brescia asks for a facility under Unix that will allow you to
    receive any packet type that the kernel doesn't need.  The Ethernet
    packet filter (/dev/enet) will do this.  There is supposedly a
    copy of this software included with 4.3.  We use it on a Pyramid
    to implement PUP.  (We can't give it to you, as our copy is covered
    by a license with Xerox.)

Unfortunately, the packet filter (wonderful as it is) in its current
state won't solve Mike's problem; he wanted access to IP packets not
otherwise consumed by the kernel.  The packet filter plugs in to the
network device drivers, and so only gets to look at data-link layer
packet types not wanted by the rest of the kernel.  For example, an
ethernet driver takes a received packet, looks at its packet type,
and if it's not IP or ARP or XNS, it drops it into the packet filter
instead of on the floor.

I've toyed with the idea of creating a sort of pseudo-interface driver
that would do the same thing for IP packets that are about to be
dropped on the floor; the packet filter itself should handle this without
modifications, although I'm not sure if packet transmission is as easily
done this way.  This is just a "small matter of programming"; i.e.,
don't hold your breath.

The sources shipped with 4.3BSD are almost usable; apparently, the
kind folks at Berkeley (1) failed to include any documentation or
test programs, and (2) modified the modifications to the network
interface drivers.  This modified modifications might work, but I
don't know if anyone has ever proved this.  I really should do something
about this; if anyone out there wants to use the packet filter but
can't get the 4.3 distribution to work, I'd like to here from you.

By the way, I doubt if the Xerox license agreement had any control
over the packet filter sources, since I'm pretty sure Xerox knew they
were public-domain when they got them.

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21-Jan-87 15:02:46 EST
From:      swb@DEVVAX.TN.CORNELL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Gateway Monitoring

About security in monitoring: yes, it was mentioned as a requirement
in one of the first messages among the "Partridge" contingent.
							Scott

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21-Jan-87 15:06:13 EST
From:      gross@MITRE-GATEWAY.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Looking for DDN/X.25 to TCP/IP router


> My feelings are that for local connections to the IMP (PSN), 
> 1822DH is far superior if you can get an interface from
> ACC for your system.  A straight 1822DH connection will run
> twice as fast as a comparable X.25 connection simply because 
> the 1822 can signal at about 100-200 Kb/s and you can't connect X.25
> to an IMP faster than 64 Kb/s.  
>  
> All the usual disclaimers apply...
> 
> 			Milo "I love 1822" Medin
> 			NASA Ames/ Bendix Aerospace

Milo,

We have been doing some 1822 vs X.25 comparisons lately.  At first we 
thought we found a major X.25 performance problem but it turned out to
be the vendor's driver.  (For a price, I'll tell you who not to buy...)
We repeated our tests on Mike Petry's machine and actually got reasonable
response.  For hosts on the same Imp, 1822 wins, in cases by a large
margin; but for destinations across the net, the difference begins to
smear out.  By 7 hops away, X.25 wins about half the time.  We have
some nifty graphs that we'll show at the next IETF.

Phill

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21-Jan-87 16:06:21 EST
From:      dunigan@ORNL-MSR.ARPA (Tom Dunigan 576-2522)
To:        mod.protocols.tcp-ip
Subject:   seeking source for Ether packet types and vendor address codes

Where might one find a list of Ethernet packet types (e.g., 600 XNS,
600x DECnet, 800 tcp/ip . ...)?
Also, is there a list of vendor-to-Ethernet address assignments?
  thanks
   tom
   dunigan@ornl-msr.arpa

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21-Jan-87 17:26:33 EST
From:      GROSSMAN@Sierra.Stanford.EDU (Stu Grossman)
To:        mod.protocols.tcp-ip
Subject:   Re:  Analyzing Acknowledgement Strategies, continued

When I was at DEC, Raj Jain gave a paper on this subject, but it seemed to be
somewhat more refined than the work you mentioned.  Essentially, he was trying
to deal with congestion Control, not congestion Prevention.

The method he proposed went something like this:
1) Under conditions of no congestion, send as many packets as you want.

2) When congestion is first detected, reduce the number of outstanding
   (unacknowleged) packets to 1.

3) Increase the number of outstanding packets until either:
	a) the number of outstanding packets is equal to three times the
	   number of hops between you and your destination, or
	b) congestion is detected again, go back to step 2.

The number of outstanding packets is increased by one each time you have
successfully transmitted all of your previous outstanding packets without
detecting congestion.

I don't recall the particulars of how the congestion is detected.

This method was used in DECnet and did indeed make congested situations
much more palatable.  One of the primary cases where this algorithm helped
a lot was in the case where you had a gateway (pardon me, a DECnet router)
with interfaces to networks of differing speeds on each side (such as an
Ethernet and a 19.2kb line).

			Stu Grossman
-------

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21-Jan-87 18:13:57 EST
From:      mckee@MITRE.ARPA (H. Craig McKee)
To:        mod.protocols.tcp-ip
Subject:   Re: Analyzing Acknowledgement Strategies, continued

Concerning the design of a filter to estimate rtt - I think 
you're trying to do too much "within" TCP.  ICMP source quench messages
are a good indication of network congestion.  X.25 has a RNR (Receiver
Not Ready) indication that may also be useful.

Regards - Craig

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Wed 21 Jan 87 19:46:03-EST
From:      Dennis G. Perry <PERRY@vax.darpa.mil>
To:        gross@mitre-gateway.arpa
Cc:        PERRY@vax.darpa.mil, hwb@mcr.umich.edu, craig@loki.bbn.com, nsfnet-routing@mcr.umich.edu, stjohns@sri-nic.arpa, tcp-ip@sri-nic.arpa, perry@vax.darpa.mil
Subject:   Re: Gateway Monitoring.
Phil, thanks.  I think we need to not rush off and do something just
to appear to be doing someting to solve a perceived problem that will
infact generate a worse problem.

Let's try to do something right.

dennis
-------
-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22-Jan-87 01:29:07 EST
From:      medin@orion.arpa (Milo S. Medin, NASA ARC Code ED)
To:        mod.protocols.tcp-ip
Subject:   Re: Looking for DDN/X.25 to TCP/IP router


I can certainly believe that.  But under certain circumstances, such as
a gateway with many simultaneous VC's open to PSNs across the network,
I think you may run into the 64Kb/s X.25 host access line speed bottleneck,
a bottleneck that you wouldn't hit with 1822.  Granted the PSN's only have
56 Kb/s lines, but the NASA gateway to the DDN (for example) may be pushing 
traffic through multiple modem port lines and might actually be able to use that
added bandwidth.  I'm not saying using X.25 the way DDN is using it in
Standard service is a bad idea, in fact, its certainly more elegant
than ECU's and the like.  And even for hosts connected to a PSN, 
I think it's quite reasonable because you'll generally not have a 
lot of open VC's to other PSN's, and thus won't hit the 64 Kb/s
bottleneck since the X.25 flow control should block you when you
have lots of outstanding data to a given PSN (just like RFNM's). 
What I am saying is that for certain applications, especially gateways
with large numbers of hosts behind them, which are in many cases 
colocated (or in 1822DH range) with the PSN, that 1822 may provide
better performance with a much simpler interface.  1822 is far from
perfect, but it works, and it's been figured out pretty well
over the years.  I think that in a year or two, the X.25 connections
to PSNs will be pretty well figured out and shaken down.  But
the issue of performance in certain cases may still side with
1822.  If you could plug into a PSN with a 112 Kb/s X.25 line, then I don't
think you'd have that problem.  

Has anyone here done any benchmarking with X.25 connections from PSNs to
gateways in a situation where many VC's are open to multiple PSNs
all at once and plenty of data to send through all of them?  You should
be able to monitor the host access line and see if you are pushing
the limits of line utilization.

In addition, I understand from some folks at BBN that PSN 7.0 will
have a better end-to-end protocol that should greatly improve
X.25 performance.

					Thanks,
					  Milo

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      Thu 22 Jan 87 06:34:25-EST
From:      Dennis G. Perry <PERRY@vax.darpa.mil>
To:        cheriton@pescadero.stanford.edu
Cc:        tcp-ip@sri-nic.arpa, perry@vax.darpa.mil
Subject:   Re: Gateway monitoring protocols
Dave, I think you are on the right track, and have put my concerns in print
much better that my ravings.  Unfortunately the vertical solution of doing
something rapidly often ignores the horizontal breadth of the problem.

dennis
-------
-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Jan 87 13:36:32 -0500
From:      Craig Partridge <craig@loki.bbn.com>
To:        tcp-ip%sri-nic.arpa@SH.CS.NET
Subject:   Monitoring Revisited

    As you have no doubt noticed, my original posting announcing a group
working on a monitoring protocol has induced a flurry of responses from
interested parties.  In this note I try to summarize where things stand.

    It turns out that there are somewhat more people working on
monitoring than I thought.  DCA/DDN PMO and DARPA are both sponsoring
work in this area, as are several companies, including BBN and Mitre,
and several Internet Task Forces.  In addition, various standards
bodies, including ISO, MAP and IEEE are actively working in this area.

I've talked with many reprentatives of these groups and they
are generally supportive -- there seems to be a consensus that
using a general monitoring protocol for NSFNET makes sense and that
studying the literature is the next step.  The upshot is that I have a lot
of reading to do.  I expect to be at part of the IETF meeting to talk
with people there (I'll also be at the Monterey TCP-IP Conference in March).

    Furthermore, DARPA and BBN have agreed to make an implementation of
HMP that runs under 4.2 and 4.3bsd, and information on the monitoring
data gateways return, available to the community, to assist people working
with the day-to-day monitoring issues while we work our way towards a
more general standard.  (Details on the distribution to follow).

Craig Partridge
NSF Network Service Center
-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 1987 13:36-PST
From:      STJOHNS@SRI-NIC.ARPA
To:        cheriton@PESCADERO.STANFORD.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Gateway monitoring protocols
There is a need for security/authentication at every level of the
ISO model, although ISO doesn't seem to realize it.   Each  level
has it peculiarities and needs for security and each requires its
own specific solution.  It may be (and probably is) necessary  to
come  up  with  a different solution for each level (and possibly
each client on a level).

Someone wrote a very good comment on this subject  on  this  list
about  2  or  3  months ago.  Go take a look at the TCP archives.
Mike
-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22-Jan-87 10:42:43 EST
From:      gross@MITRE-GATEWAY.ARPA (Phil Gross)
To:        mod.protocols.tcp-ip
Subject:   Re: Gateway monitoring protocols

I agree with Dave.  I sent a note to the new gwmon mailing list expressing
some of the same concerns.  (I won't clutter mailboxes by including it here.)
Perhaps, we should move the discussion to that list?

Phill

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22-Jan-87 10:50:12 EST
From:      stever@videovax.tek.com ("Steven E. Rice")
To:        mod.protocols.tcp-ip
Subject:   Re: Tektronics TCP/IP for VMS (Second try!)

The "automatic" mailing software dropped the ball, so we'll try again:


From: stever@videovax.BITNET
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Tektronics TCP/IP for VMS
Message-ID: <4159@videovax.Tek.COM>
Date: Fri, 16-Jan-87 19:22:48 EET
References: <8701131751.AA17600@cieunix.rpi.edu> <8701141554.AA18711@ohio-state.
Reply-To: stever@videovax.Tek.COM (Steven E. Rice, P.E.)
Organization: Tektronix Television Systems, Beaverton, Oregon
Lines: 11
Keywords: Tektronix TCP/IP VMS free
Summary: Please spell it correctly. . .

Aarrrrggghhhh!!!!!!

      Subject: Tektronics TCP/IP for VMS
               ^^^^^^^^^^

There are neither "cee"s nor "ess"s in "Tektronix"!!

                                        Steve Rice

----------------------------------------------------------------------------
{decvax | hplabs | ihnp4 | uw-beaver}!tektronix!videovax!stever

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22-Jan-87 10:53:14 EST
From:      stever@videovax.tek.com ("Steven E. Rice")
To:        mod.protocols.tcp-ip
Subject:   Re: Analyzing Acknowledgement Strategies (Second try!)

The "automatic" mailing software dropped the ball, so we'll try again:

From: stever@videovax
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Analyzing Acknowledgement Strategies
Message-ID: <4160@videovax.Tek.COM>
Date: Fri, 16-Jan-87 19:41:18 EET
References: <8701151850.AA18157@lbl-csam.arpa>
Reply-To: stever@videovax.Tek.COM (Steven E. Rice, P.E.)
Organization: Tektronix Television Systems, Beaverton, Oregon
Lines: 22
Summary: Please continue to let us in on the discussion!

In article <8701151850.AA18157@lbl-csam.arpa>, Van Jacobson
(van@LBL-CSAM.ARPA) writes:

> Dave -

[ body of the article deleted ]

>   - Van
>
> ps- perhaps we should take this discussion off line?  I've been
>     filling up peoples' mailboxes lately and I get the impression
>     that there are only two or three of us interested in this topic.

I cannot speak for anyone but myself, but I appreciate seeing the
discussion of these issues.  I am not at present directly involved
with such networks, but the problems discussed are food for thought
and the solutions proposed have bearing in other areas.

                                        Steve Rice

----------------------------------------------------------------------------
{decvax | hplabs | ihnp4 | uw-beaver}!tektronix!videovax!stever

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22-Jan-87 11:01:00 EST
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
To:        mod.protocols.tcp-ip
Subject:   seeking source for Ether packet types and vendor address codes


    Date: Wed, 21 Jan 87 16:06:21 EST
    From: dunigan@ORNL-MSR.ARPA (Tom Dunigan 576-2522)

    Where might one find a list of Ethernet packet types (e.g., 600 XNS,
    600x DECnet, 800 tcp/ip . ...)?
    Also, is there a list of vendor-to-Ethernet address assignments?
      thanks
       tom
       dunigan@ornl-msr.arpa

The first list (Ethernet type codes) is a public list and is available
from the administrator of those codes.  The administrator used to be
Robert Prentiss, and the organization used to be (back in late '82)
	Network Systems Administration Office
	Office Systems Division
	Xerox
	3450 Hillview Avenue
	Palo Alto, CA  94304
I don't know if Printiss is still there, or if Xerox still handles that.

The vendor-Ethernet list also used to be administered by the same
person/organization.  I don't know if that list is public and/or if the
administration has changed.

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22-Jan-87 12:35:52 EST
From:      Postel@ISI.EDU (Jon Postel)
To:        mod.protocols.tcp-ip
Subject:   Ethernet Type Codes


A partial list is in "Assigned Numbers" (RFC-990), page 38. Information
on other numbers to add to the list would be appreciated.

--jon.

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22-Jan-87 15:10:22 EST
From:      jas@MONK.PROTEON.COM (John A. Shriver)
To:        mod.protocols.tcp-ip
Subject:   seeking source for Ether packet types and vendor address codes

This information is considered proprietary by the IEEE. The best I
know of is to look at RFC "Assigned Numbers", which has a lot of them.

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22-Jan-87 15:12:05 EST
From:      estrin%usc-rt234@USC-CSE.USC.EDU (Deborah L. Estrin)
To:        mod.protocols.tcp-ip
Subject:   security mechanisms for ip

We have been working on a scheme for supporting access control
in a multi-organization internet through the addition of a visa
mechanism to IP.

If you are interested and willing to provide feedback, I can send 
you a draft of a short paper entitled
"Visa Scheme for Inter-ORganization Network Security"

Deborah Estrin, Computer Science Dept, USC

ps if you can process a latex file i can send it via email;
if you cant, pls send a hard copy mail address.

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22-Jan-87 15:53:49 EST
From:      craig@LOKI.BBN.COM (Craig Partridge)
To:        mod.protocols.tcp-ip
Subject:   Monitoring Revisited


    As you have no doubt noticed, my original posting announcing a group
working on a monitoring protocol has induced a flurry of responses from
interested parties.  In this note I try to summarize where things stand.

    It turns out that there are somewhat more people working on
monitoring than I thought.  DCA/DDN PMO and DARPA are both sponsoring
work in this area, as are several companies, including BBN and Mitre,
and several Internet Task Forces.  In addition, various standards
bodies, including ISO, MAP and IEEE are actively working in this area.

I've talked with many reprentatives of these groups and they
are generally supportive -- there seems to be a consensus that
using a general monitoring protocol for NSFNET makes sense and that
studying the literature is the next step.  The upshot is that I have a lot
of reading to do.  I expect to be at part of the IETF meeting to talk
with people there (I'll also be at the Monterey TCP-IP Conference in March).

    Furthermore, DARPA and BBN have agreed to make an implementation of
HMP that runs under 4.2 and 4.3bsd, and information on the monitoring
data gateways return, available to the community, to assist people working
with the day-to-day monitoring issues while we work our way towards a
more general standard.  (Details on the distribution to follow).

Craig Partridge
NSF Network Service Center

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22-Jan-87 23:35:43 EST
From:      Mills@LOUIE.UDEL.EDU
To:        mod.protocols.tcp-ip
Subject:   Re:  Looking for DDN/X.25 to TCP/IP router

Milo,

Yes, some measurements have been made on gateways running X.25 to many
PSNs: the scatter diagrams I sent around a month or so ago. They raised
the suspicion, later confirmed, that something was amiss in the gateway
or PSN, not just bad protocol. Mike Petry at U Maryland subsequently
found a bug in a 4.3bsd driver, which gave much joy when fixed. Something
is apparently still wrong with the Ultirx driver, which was coded by
ACC for their 5250 interface.

Like you, I have real problems with the current X.25 design parameters
in the PSNs, but experience with HDH and ECUs suggests realistic level-3
parameters (big packet sizes and bigger windows) should result in performance
not worse than either HDH or ECUs with the same line speeds.

Dave

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23-Jan-87 02:48:32 EST
From:      Mills@LOUIE.UDEL.EDU
To:        mod.protocols.tcp-ip
Subject:   Re:  security mechanisms for ip

Deborah,

Anything electric is preferable to anything paper. Feedback is only
a matter of complex congugates. Send me anything gazinta and I will
gladly gazouta.

Dave

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23-Jan-87 06:48:00 EST
From:      JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   security mechanisms for ip


     >We have been working on a scheme for supporting
     >access control in a multi-organization internet
     >through the addition of a visa mechanism to IP. 
     >
     >If you are interested and willing to provide
     >feedback, I can send you a draft of a short paper
     >entitled "Visa Scheme for Inter-ORganization
     >Network Security" 
     >
     >Deborah Estrin, Computer Science Dept, USC
     >
     >ps if you can process a latex file i can send it
     >via email; if you cant, pls send a hard copy mail
     >address. 

     Deborah,

     I can take a latex file.  Please e-mail a copy of the paper.  
Thanks much.

Chris Johnson
Northeastern University

csnet:      johnson@nuhub.acs.northeastern.edu
arpa:       johnson%nuhub.acs.northeastern.edu@relay.cs.net
at&t:       (617) 437-2335

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Jan 87 06:48 EST
From:      "I am only an egg." <JOHNSON%nuhub.acs.northeastern.edu@RELAY.CS.NET>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   security mechanisms for ip
     >We have been working on a scheme for supporting
     >access control in a multi-organization internet
     >through the addition of a visa mechanism to IP. 
     >
     >If you are interested and willing to provide
     >feedback, I can send you a draft of a short paper
     >entitled "Visa Scheme for Inter-ORganization
     >Network Security" 
     >
     >Deborah Estrin, Computer Science Dept, USC
     >
     >ps if you can process a latex file i can send it
     >via email; if you cant, pls send a hard copy mail
     >address. 

     Deborah,

     I can take a latex file.  Please e-mail a copy of the paper.  
Thanks much.

Chris Johnson
Northeastern University

csnet:      johnson@nuhub.acs.northeastern.edu
arpa:       johnson%nuhub.acs.northeastern.edu@relay.cs.net
at&t:       (617) 437-2335

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 1987 09:53-PST
From:      STJOHNS@SRI-NIC.ARPA
To:        estrin%usc-rt234@USC-CSE.USC.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: security mechanisms for ip
Send it to me, I'll process it and provide it as a flat text file
at the NIC.

Mike
-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23-Jan-87 12:16:00 EST
From:      allen@esdvax.UUCP ("Maj. William Allen")
To:        mod.protocols.tcp-ip
Subject:   request to be added to list


                   I N T E R O F F I C E   M E M O R A N D U M

                                        Date:      23-Jan-1987 12:16 
                                        From:      MAJ WILLIAM M. ALLEN 
                                        Username:  ALLEN 
                                        Dept:      XRB-4
                                        Tel No:    377-6160

TO:  _MAILER!                             ( _DDN[TCP-IP@SRI-NIC] )


Subject: request to be added to list

request to be added to the tcp-ip mailing list.
my e-mail address is: allen@esdvax
thanks,
mike allen
 

------

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 87 12:16:00 EST
From:      "Maj. William Allen" <allen@esdvax>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   request to be added to list
                   I N T E R O F F I C E   M E M O R A N D U M

                                        Date:      23-Jan-1987 12:16 
                                        From:      MAJ WILLIAM M. ALLEN 
                                        Username:  ALLEN 
                                        Dept:      XRB-4
                                        Tel No:    377-6160

TO:  _MAILER!                             ( _DDN[TCP-IP@SRI-NIC] )


Subject: request to be added to list

request to be added to the tcp-ip mailing list.
my e-mail address is: allen@esdvax
thanks,
mike allen
 

------
-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23-Jan-87 13:50:56 EST
From:      lekash@WILBUR.ARPA (John Lekashman)
To:        mod.protocols.tcp-ip
Subject:   tftp and proteon gateways.

We noted there was no directory protection from
tftp on 4.3BSD vaxes. (At least ours) so here are
a few lines of change in /usr/src/etc/tftpd/tftpd.c
If you only have a binary, I'll go put a copy of ours
in public ftp from orville.arpa.
					john

232,234c232
< 	int	fd,deflist = 0;
< 	FILE    *flist ;
< 	char    s[1000];
---
> 	int	fd;
236,250c234,235
< 	  if (flist = fopen("/etc/tftp.perm","r")) {
< 	    while (fgets(s,1000,flist)) {
< 	      if (!strncmp(s,filename,strlen(s)-1)) {
< 		deflist++;
< 		break;
< 	      }
< 	    }
< 	    fclose(flist);
< 	    if (!deflist) return(EACCESS);
< 	  } else if ((strncmp(filename, "/tftpboot", strlen("/tftpboot")) &&
< 		     strncmp(filename,"/usr/local/tftpboot",
< 			      strlen("/usr/local/tftpboot")))) {
< 	    return(EACCESS);
< 	  }
< 
---
> 	if (*filename != '/')
> 		return (EACCESS);

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Sat, 24-Jan-87 14:38:41 EST
From:      cassel@dewey.udel.edu.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Gateway Monitoring.

Sorry to be dense.  What is IETF?  Is it an open meeting?  Where,
when, ....?

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Sat, 24-Jan-87 16:02:22 EST
From:      Postel@isi.edu.UUCP
To:        mod.protocols.tcp-ip
Subject:   FTP Enhancements


For those wishing for a better FTP (i.e., "something real") or just some
more features, please participate in the ISO development of FTAM.  Like it
or not, as a practical matter, FTAM is the next version of FTP

--jon.

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      Sat, 24-Jan-87 16:33:53 EST
From:      Postel@isi.edu.UUCP
To:        mod.protocols.tcp-ip
Subject:   Domain Names - DDN MGT Bulletin # 32


********************************************************************** 
DDN MGT Bulletin 32              DCA DDN Defense Communications System   
22 Jan 87                        Published by: DDN Network Info Center
                                    (NIC@SRI-NIC.ARPA)  (800) 235-3155


                        DEFENSE  DATA  NETWORK

                         MANAGEMENT  BULLETIN

The DDN MANAGEMENT BULLETIN is distributed online by the DDN Network
Information Center under DCA contract as a means of communicating
official policy, procedures and other information of concern to
management personnel at DDN facilities.  Back issues may be read
through the TACNEWS server ("@n" command at the TAC) or may be
obtained by FTP (or Kermit) from the SRI-NIC host [26.0.0.73 or
10.0.0.51] using login="anonymous" and password="guest".  The pathname
for bulletins is DDN-NEWS:DDN-MGT-BULLETIN-nn.TXT (where "nn" is the
bulletin number).
**********************************************************************

              PHASE 1 OF THE DOMAIN NAME IMPLEMENTATION

The DDN Network Information Center (NIC) is directed to remove all
nondomain-style host names and nicknames from the Official DoD Host
Table, NETINFO:HOSTS.TXT, by 31 March 1987.  After that time, names
which do not conform to domain-style naming conventions, i.e. do not
have ".domain" extensions, will not be allowed in either the Official
DoD Host Table or the domain name servers.

Nicknames, or aliases, will not be permitted in either the servers or
the Official Host Table unless authorized.  Network mailers are
required to use primary host names and to accept host names containing
dots (.), as specified in the DDN mail protocols RFC 821 (MILSTD-1781)
and RFC 822.  If mailers are not now adhering to these protocol
requirements, they may experience mail delivery problems when the
nondomain-style names are discontinued.  Users sending electronic mail
should use primary host names in all mail destinations and sources.
If nicknames are used, problems may arise in mail delivery.

The NIC will notify Host Administrators as to which names or nicknames
do not now conform.  Host Administrators may change nonconforming data
by the usual procedure via Network Change Requests (NCRs) and Network
Change Directives (NCDs), if they wish, before the 31 March 1987
deadline.

Host Administrators anticipating problems with this plan should notify
DCA Code B652 (DCAB652@DDN1.ARPA), or via AUTODIN message, and the NIC
Hostmaster (HOSTMASTER@SRI-NIC.ARPA) no later than 2 weeks prior to
the scheduled cutover.

In March of 1984, the DDN began the transition to domain-style names
with the issuance of DDN Management Bulletin 22.  In that bulletin,
all hosts were required to change their primary host names to contain
".domain" extensions in accordance with RFC 897.  At the same time,
all of the old-style names (without the ".domain" extensions) were
automatically declared to be nicknames in the Official Host Table,
NETINFO:HOSTS.TXT.  This use of old-style nicknames was allowed on an
interim basis to make the transition to domain-style naming easier.
Almost three years have passed, and this transition period must now
come to a close.

The transition to naming domains has progressed to the point where
there are many domain name servers implemented and running.  In order
to maintain interoperability between hosts on the DDN using the host
table and hosts using the domain name servers, all hosts must be able
to recognize domain-style names.  It is imperative that all transition
names and nicknames be upgraded to domain-style names or be removed
from NETINFO:HOSTS.TXT so that naming is consistent and so that all
use of names adheres to the specification for domain names adopted in
1984.
-------


----- End Forwarded Message -----

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      Sat, 24-Jan-87 18:08:49 EST
From:      mrose@nrtc-gremlin.arpa.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: FTP Enhancements


    I don't know how long it will take FTAM to replace FTP, (or even if
    it ever will), but it has all of the enhancements being discussed,
    such as recovery-restart at checkpoints, and the optional use of
    compression mechanisms when moving files.  Currently, the mechanisms
    for negotiating the compression method are defined; one could define
    a compression mode, e.g., ARC, or the 4.3BSD compress, or ..., and
    then those could be negotiated.  

/mtr

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Sat, 24-Jan-87 20:17:07 EST
From:      bob@ohio-state.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: request to be added to list

In article <8701231723.AA12881@ucbvax.Berkeley.EDU> "Maj. William Allen" <allen@esdvax> writes:
>
>                   I N T E R O F F I C E   M E M O R A N D U M

Yes, indeed, that was a VMS All-In-1 Mail message you saw!  It should
be forwarded to header-people as an example of how to avoid
standardization :-)

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      Sun, 25-Jan-87 13:02:37 EST
From:      ddp#@andrew.cmu.edu.UUCP
To:        mod.protocols.tcp-ip
Subject:   ethernet packet type 6004


Does anyone know what an ethernet packet type 6004 is?  It must have
something to do with DECnet, LAT, or DEC LAN bridges as far as I can tell.

Drew

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Sun, 25-Jan-87 19:09:07 EST
From:      GKN@SDSC.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: ethernet packet type 6004


	From:	 ddp#@andrew.cmu.edu (Drew Daniel Perkins)
	To:	 tcp-ip@sri-nic.arpa
	Subject: ethernet packet type 6004
	Date:	 Sun, 25 Jan 87 13:02:37 est


	Does anyone know what an ethernet packet type 6004 is?  It must have
	something to do with DECnet, LAT, or DEC LAN bridges as far as I can tell.

	Drew

It's LAT.  Here's a list of the ethernet packet types I know about:

	90-00	Loopback assistance
	60-01	Dump/Load assistance (DECnet MOP)
	60-02	Remote console facility (NCP CONNECT VIA ...)
	60-03	DECnet
	60-04	LAT
	08-00	IP
	00-02	PUP
	08-04	Chaosnet
	08-06	ARP
	08-07	XNS
	80-38	DEC LanBridge-100

The ones DEC uses (except for 80-38) are documented on page 6-5 of the
VAX/VMS I/O User's Reference Manual: Part II.  You'll also find a list
of the multicast addresses DECnet and friends use, too.  LAT and LanBridge-100s
also use multicasts, but I've not got a list of the addresses handy.

gkn
--------------------------------------
Arpa:	GKN@SDSC.ARPA
Bitnet:	GKN@SDSC
Span:	SDSC::GKN (5.600)
USPS:	Gerard K. Newman
	San Diego Supercomputer Center
	P.O. Box 85608
	San Diego, CA 92138
AT&T:	619.534.5076
-------

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Mon 26 Jan 87 00:09:07-GMT
From:      Gerard K. Newman <GKN@SDSC.ARPA>
To:        ddp#@ANDREW.CMU.EDU
Cc:        tcp-ip@SRI-NIC.ARPA, info-vax@SRI-KL.ARPA
Subject:   Re: ethernet packet type 6004
	From:	 ddp#@andrew.cmu.edu (Drew Daniel Perkins)
	To:	 tcp-ip@sri-nic.arpa
	Subject: ethernet packet type 6004
	Date:	 Sun, 25 Jan 87 13:02:37 est


	Does anyone know what an ethernet packet type 6004 is?  It must have
	something to do with DECnet, LAT, or DEC LAN bridges as far as I can tell.

	Drew

It's LAT.  Here's a list of the ethernet packet types I know about:

	90-00	Loopback assistance
	60-01	Dump/Load assistance (DECnet MOP)
	60-02	Remote console facility (NCP CONNECT VIA ...)
	60-03	DECnet
	60-04	LAT
	08-00	IP
	00-02	PUP
	08-04	Chaosnet
	08-06	ARP
	08-07	XNS
	80-38	DEC LanBridge-100

The ones DEC uses (except for 80-38) are documented on page 6-5 of the
VAX/VMS I/O User's Reference Manual: Part II.  You'll also find a list
of the multicast addresses DECnet and friends use, too.  LAT and LanBridge-100s
also use multicasts, but I've not got a list of the addresses handy.

gkn
--------------------------------------
Arpa:	GKN@SDSC.ARPA
Bitnet:	GKN@SDSC
Span:	SDSC::GKN (5.600)
USPS:	Gerard K. Newman
	San Diego Supercomputer Center
	P.O. Box 85608
	San Diego, CA 92138
AT&T:	619.534.5076
-------
-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26-Jan-87 17:48:57 EST
From:      lars@ACC-SB-UNIX.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   ACP6250 / ACP5250 on 4.3BSD

The ACP6250 (for UNIBUS VAXen) / ACP5250 (for MicroVAXen)
DDN interface has been available for some time for 4.2BSD
and ULTRIX 1.2. ACC is now almost ready with a 4.3BSD
driver. (Some customers have ported the 4.2BSD driver to
4.3BSD; some of those have had some problems).

We expect to be able to ship to Beta sites next week. If you
        (1) are currently running 4.3BSD
        (2) currently have an ACP6250 or ACP5250 board
        (3) want to participate in the field test round
- then please register your interest by sending email to
  "service@acc-sb-unix.arpa"

Lars Poulsen                      (805) 963-9431
ACC Customer Service              (800) 222-7308 Outside CA, AL, HI

PS: The "DDN device driver" in the 4.3BSD distribution is not
    compatible with the ACP6250; it is a fossil from some early
    testing. The device that it does support is not sanctioned
    for "standard mode" connections on DDN.
    Also, the if_hdh.c driver in the 4.3BSD kit is out of date.

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27-Jan-87 14:22:55 EST
From:      GROSSMAN@SIERRA.STANFORD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: ethernet packet type 6004

Ethernet protocol type 60-04 is DECs LAT protocol.  FYI, here are a few
others supported by DEC:

		60-01		MOP Ethernet configurator service
		60-02		MOP remote console server
		60-03		DECnet (Phase IV at least)
		90-00		Ethernet loopback server

The protocol that uses 90-00 is described in the Ethernet version 2 spec
by Digital/Intel/Xerox.

			Stu Grossman
-------

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 1987 17:24-EST
From:      URBANIAK@G.BBN.COM
To:        dunigan@ORNL-MSR.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, Urbaniak@G.BBN.COM
Subject:   Re: seeking source for Ether packet types and vendor address...
I was told by the IEEE that the Ethernet vendor addresses were not for
public distribution. Below are some of the Ethernet Type Field values
and Ethernet vendor addresses which I've noted. 
I would be happy to learn of any corrections or additional data.

Walter Urbaniak.

Current BBN Ethernet and IEEE802.3 "Type" Fields

The 13th and 14th octets of an Ethernet or IEEE802.3 packet (after the preamble)
consist of the "Type" or "Length" field. These are formerly assigned by
Xerox, currently assigned by IEEE. Some assignments are public, others private.
Information currently available includes: Xerox Public Ethernet Packet
Type documentation; IEEE802.3 Std, but not yet further documentation from
IEEE; NIC RFC960; knowledge of some BBN Private Type Field values.

Hex
0000-05EE	IEEE802.3 Length Field
0600	Xerox NS IDP *
0800	DOD IP * #
0801	X.75 Internet
0802	NBS Internet
0803	ECMA Internet
0804	CHAOSnet
0805	X.25 Level 3
0806	ARP * (for IP and for CHAOS)
0807	XNS Compatibility
081C	Symbolics Private
1001	Berkeley Trailer encapsulation?
1600	VALID-machine protocol? *
5208	BBN Simnet Private
6001	DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance
6002	DEC Maintenance Operation Protocol (MOP) Remote Console
6003	DECNET Phase IV
6004	DEC LAT
6005	DEC protocol, at interface initialization?
6006	DEC user protocol
8003	Cronus VLN
8004	Cronus Direct
8005	HP Probe protocol
8006	Nestar
8010	Excelan
8035	Reverse ARP
8038	DEC LanBridge Management
805B	Stanford V Kernel, experimental
805C	Stanford V Kernel, production
809B	AppleTalk over Ethernet (Kinetics only?)
9000	Loopback (Configuration Test Protocol)
FF00	BBN VITAL-LanBridge cache wakeups

* These protocols use Ethernet broadcast, where multicast would be preferable.
# BBN Butterfly Gateways also use 0800 for non-IP, with IP version field = 3.


Ethernet Vendor Addresses

Ethernet hardware addresses are 48 bits, expressed as 12 hexadecimal digits
(0-9, plus A-F, capitalized). These 12 hex digits consist of
the first/left 6 digits (which should match the vendor of the Ethernet interface
within the station) and the last/right 6 digits which specify the interface
serial number for that interface vendor.

Currently we have noted the following vendor addresses, on the
BBN Corporate Ethernet.

0000AA	Xerox		Xerox machines
000102	BBN		BBN internal usage (not registered)
00DD00	Ungermann-Bass
020701	Interlan	UNIBUS or QBUS machines
02608C	3Com		IBM PC; Imagen; Valid
02CF1F	CMC		Masscomp
080002	Bridge
080005	Symbolics	Symbolics LISP machines
080009	Hewlett-Packard
080010	AT+T
080014	Excelan		BBN Butterfly, Masscomp
080020	Sun		Sun machines
08002B	DEC		UNIBUS or QBUS machines, VAXen, LANBridges
			(DEUNA, DEQNA, DELUA)
080089	Kinetics	AppleTalk-Ethernet interface
08008D	XyVision	XyVision machines
AA0003	DEC		Physical address for some DEC machines
AA0004	DEC		Logical address for systems running DECNET

Ethernet addresses might be written unhyphenated (e.g. 123456789ABC),
or with one hyphen (e.g. 123456-789ABC), but should be written hyphenated
by octets (e.g. 12-34-56-78-9A-BC).

These addresses are physical station addresses, not multicast nor
broadcast, so the second hex digit (reading from the left)
will be even, not odd.

At present, it is not clear how the IEEE assigns Ethernet block addresses.
Whether in blocks of 2**24 or 2**25, and whether multicasts are assigned
with that block or separately. A portion of the vendor block address
is reportedly assigned serially, with the other portion intentionally
assigned randomly. If there is a global algorithm for which addresses
are designated to be physical (in a chipset) versus logical
(assigned in software), I am unaware of the algorithm.


Current BBN Ethernet Multicast Addresses

I do not have protocol specifications for DECNET and the VALID
protocol at this time.
There is no XNS or VALID router at present; those packets might be
Hello packets, or gateway query packets.

Ethernet		Type	
Address			Field	Usage

Multicast Addresses:

09-00-2B-01-00-01	8038	DEC LanBridge Hello packets
				1 packet per second, sent by the
				lowest-addressed LanBridge
AB-00-00-01-00-00	6001	DEC Maintenance Operation Protocol (MOP)
				Dump/Load Assistance
AB-00-00-02-00-00	6002	DEC Maintenance Operation Protocol (MOP)
				Remote Console
				1 System ID packet every 8-10 minutes, by every:
				DEC LanBridge
				DEC DEUNA interface
				DEC DELUA interface
				DEC DEQNA interface (in a certain mode)
AB-00-00-03-00-00	6003	DECNET Phase IV end node Hello packets
				1 packet every 15 seconds, sent by each DECNET host
AB-00-00-04-00-00	6003	DECNET Phase IV Router Hello packets
				1 packet every 15 seconds, sent by the DECNET router
AB-00-00-05-00-00	????	Reserved DEC
through		
AB-00-03-FF-FF-FF
AB-00-04-00-00-00	????	Reserved DEC customer private use
through		
AB-00-04-FF-FF-FF
CF-00-00-00-00-00	9000	Ethernet Configuration Test protocol (Loopback)

Broadcast Address:

FF-FF-FF-FF-FF-FF	0600	XNS packets, Hello or gateway search?
				6 packets every 15 seconds, per XNS station
FF-FF-FF-FF-FF-FF	0800	IP (e.g. RWHOD via UDP) as needed
FF-FF-FF-FF-FF-FF	0806	ARP (for IP and CHAOS) as needed
FF-FF-FF-FF-FF-FF	1600	VALID packets, Hello or gateway search?
				1 packets every 30 seconds, per VALID station
-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Jan 87 21:52:22 PST
From:      satz@mojave.stanford.edu
To:        hedrick@topaz.rutgers.edu
Cc:        tcp-ip@nic.sri.com
Subject:   Black holes for 4.3BSD
A simple solution for avoiding black holes is to keep hard coded
routes out of your routing tables. The major problem is suppling the
default route since connections fail without one.  Since your gateways
support Proxy Arp, they will provide a hardware address to send the IP
packet. The gateway could then send you an ICMP Redirect if necessary.

As a test, on my uVax running 4.3, I added a default route back to my
own interface (with metric 0) and removed the default route that
pointed to the gateway. I was able to access hosts on the rest of the
campus (other subnets) and through our ARPA gateway (other nets).

Sorry if this offends anyone's sense of aesthestics.
-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27-Jan-87 23:58:23 EST
From:      JBVB@AI.AI.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Bit 8 in Telnet streams

I would appreciate mail from anyone aware of specific implementations
which send other than "space parity" (Bit 8 always 0) on Telnet streams
(in normal mode, not binary).  This would include cases where an individual
manufacturer believed that, for instance, all Ascii characters always had
Bit 8 set, and the like.

I will summarize to the list.

jbvb@ai.ai.mit.edu
James B. VanBokkelen
FTP Software Inc.

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28-Jan-87 00:52:22 EST
From:      satz@MOJAVE.STANFORD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Black holes for 4.3BSD

A simple solution for avoiding black holes is to keep hard coded
routes out of your routing tables. The major problem is suppling the
default route since connections fail without one.  Since your gateways
support Proxy Arp, they will provide a hardware address to send the IP
packet. The gateway could then send you an ICMP Redirect if necessary.

As a test, on my uVax running 4.3, I added a default route back to my
own interface (with metric 0) and removed the default route that
pointed to the gateway. I was able to access hosts on the rest of the
campus (other subnets) and through our ARPA gateway (other nets).

Sorry if this offends anyone's sense of aesthestics.

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28-Jan-87 06:42:52 EST
From:      swb@DEVVAX.TN.CORNELL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   seeking source for Ether packet types and vendor address...

What is the "valid machine protocol"?
					Scott

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28-Jan-87 06:54:02 EST
From:      BLASCO@ICNUCEVM.BITNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   DEC DELNI

Folks,

using a DEC DELNI (an Ethernet 8-transceivers multiplexer) tapping from
our Ethernet I discovered the following:
the machines connected on it where unable to talk each other (to exchange
IP packets) meanwhile they are able to talk with any other machine
on the ethernet.
Has anybody ever met this problem? Could anybody help me in clarifying
the reason of that?

Thanks,
       Blasco

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28-Jan-87 09:27:42 EST
From:      JBVB@AI.AI.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Clarification of 8-bit Telnet info request

I just posted an inquiry about implementations sending other than
"space parity" on Telnet.  By this, I meant "cases where the normal
Ascii data stream (not IAC, etc.) may have bit 8 set", i.e. which
ptty drivers are *calculating* and sending parity.

My motivation: In the PC/TCP Telnet (inherited from PC/IP), there
are a number of places where the 8th bit is carefully masked off
lest it make it to the display (and turn Ascii into a PC graphics
character).  I wish to know which implementations this defends against.

jbvb@ai.ai.mit.edu
James B. VanBokkelen
FTP Software Inc.

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28-Jan-87 13:15:25 EST
From:      Postel@ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   croissants or doughnuts ?


"... there are about 5,000 people who are part of that commitee.  These
guys have a hard time sorting out what day to meet, and whether to eat
croissants or doughnuts for breakfast -- let alone how to define how all
these complex layers are going to be agreed upon."

					Craig Burton of Novell
					quoted in Network World
					26-Jan-87

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28-Jan-87 13:52:24 EST
From:      walsh@HARVARD.HARVARD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: how to make use of redundant routes


	to deliver a packet.  The one implementation that tried to ping all of
	the gateways it knew about [TOPS-20] was roundly condemned by all.

The BBN VAX networking code pinged gateways.  You don't need to ping X if
you're getting acks back for any connection actively using gateway X as a
first hop.  You also don't need to ping if you're not currently using the
gateway.

	Since none of these methods seems very attractive, I proposed the next
	best thing that I could think of: watching the routing traffic between
	the gateways.

Using an Ethernet board in snoopy mode sounds awfully inefficient.

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Jan 87 13:52:24 EST
From:      walsh@harvard.HARVARD.EDU (Bob Walsh)
To:        JNC@xx.lcs.mit.edu, hedrick@topaz.rutgers.edu
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: how to make use of redundant routes
	to deliver a packet.  The one implementation that tried to ping all of
	the gateways it knew about [TOPS-20] was roundly condemned by all.

The BBN VAX networking code pinged gateways.  You don't need to ping X if
you're getting acks back for any connection actively using gateway X as a
first hop.  You also don't need to ping if you're not currently using the
gateway.

	Since none of these methods seems very attractive, I proposed the next
	best thing that I could think of: watching the routing traffic between
	the gateways.

Using an Ethernet board in snoopy mode sounds awfully inefficient.

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Jan 87 17:42:08 pst
From:      mab@ads.ARPA (Mike Brzustowicz)
To:        jbvb@ai.ai.mit.edu, tcp-ip@sri-nic.arpa
Subject:   Re: Clarification of 8-bit Telnet info request
The SUN PC-NFS telnet, when emulating a vt-100, sends some non-zero
parity, probably even.  It also sends XON/XOFF (In the data packets.
This IS running over an ethernet.)

-Mike
<mab@ads.arpa>
-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Jan 87 10:32 SET
From:      A. Blasco Bonito, <BLASCO%ICNUCEVM.BITNET@WISCVM.WISC.EDU>
To:        TCP-IP Distribution List <TCP-IP@SRI-NIC.ARPA>
Subject:   DEC DELNI
Folks,

using a DEC DELNI (an Ethernet 8-transceivers multiplexer) tapping from
our Ethernet I discovered the following:
the machines connected on it where unable to talk each other (to exchange
IP packets) meanwhile they are able to talk with any other machine
on the ethernet.
Has anybody ever met this problem? Could anybody help me in clarifying
the reason of that?

Thanks,
       Blasco
-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28-Jan-87 19:22:13 EST
From:      jas@monk.proteon.com.UUCP
To:        mod.protocols.tcp-ip
Subject:   IEEE Address blocks

We're not secretive, Proteon's address block is 00-00-93 for 802.3 and
802.4, and 00-00-C9 for 802.5 and slotted ring.

The IEEE assigns addresses in 24-bit chunks.  You are free to set or
clear the multicast bit, but may not modify the other 23 high-order
bits.  You are expected to use all 2^24 addresses before you can have
another block.  You are to be very careful not to duplicate addresses.
They charge, in excess of $1000, for a block.

The reason for the two presentations is that they assign them in
NETWORK (MAC) bit order, so the "absolute value" depends on the bit
order of the MAC layer of your network.  (You thought IP people had
problems coping with byte order!)  IBM is so consistently big-indian
that their network is backwards from 802.3 at the MAC level.

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28-Jan-87 20:24:55 EST
From:      hedrick@TOPAZ.RUTGERS.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: how to make use of redundant routes

Routed uses broadcasts, so snooping on the gateways doesn't require
promiscuous mode.

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28-Jan-87 20:42:08 EST
From:      mab@ADS.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Clarification of 8-bit Telnet info request

The SUN PC-NFS telnet, when emulating a vt-100, sends some non-zero
parity, probably even.  It also sends XON/XOFF (In the data packets.
This IS running over an ethernet.)

-Mike
<mab@ads.arpa>

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29-Jan-87 09:21:27 EST
From:      DUMAS@SUMEX-AIM.STANFORD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Satellite gateways


 We are interested  by the products or developpments available in 
the area of satellite gateways and procedures between TCP/IP local
networks. ( any documentation or information is  welcome.)

Thanks in advance.

PS: We shall summarize the answers.
-------

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29-Jan-87 11:00:28 EST
From:      jeff@necntc.NEC.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   internet numbering scheme

I am interested in hearing about how everyone set up their
numbering schemes -

I am in the process of setting up a more extensive LAN and
must find some more information related to this.

We are not currenty connected to the ARPA/MILNET network,
but perhaps in the future...

Our current configuration is very simple; 

Two primary site LAN's connected via VITALINK bridge -

So, I ask of your experience in this matters;

What criteria are considered when deciding on a host numbering scheme?

How to maintain consistant host numbering when VMS sites are involved?

Any pointers to a source of information on this matter??

Thanks in advance for your time,

Jeff Janock

should work:        jeff@necntc.UUCP
or if need be:
{decvax | pyramid | husc6 | seismo!mirror | talcott}!necntc!jeff
gatech!gt-eedsp!necntc!jeff 

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30-Jan-87 14:15:10 EST
From:      cam@ACC-SB-UNIX.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   WISCNET 3270 Protocol Conversion

The Telnet Server in the WISCNET software, which is an implementation 
of the Internet protocol suite for IBM's VM operating system, creates 
a virtual 3270 (using VM's LDSF [Logical Device Support Facility]), for 
each Telnet connection. This virtual 3270 always interfaces to the VM 
application. If  the server telent is unable to negotiate a transparent 3270
session (eg. with Unix tn3270 or UCLA ACP or another WISCNET, etc.), the
virtual 3270 is converted to NVT by server telnet.

My question is, is there a way to do protocol conversion on the VM host
using a package such as SIMWARE's SIM3278 using WISCNET? I know about tn3270
so no need to mention that. I'm looking for a protocol conversion package that 
runs in VM, not at the remote end.

Chris Markle 
cam@acc-sb-unix
(301)290-8100

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30-Jan-87 15:53:34 EST
From:      sra@MITRE-BEDFORD.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   TCP for ATT machines

We are looking for information including performance info on
IEEE802.3 interfaces for the AT&T 3b2 and 6300 machines

Of particular interest is information is how well they work with RFS and
how good the tcp/ip port is.

Stan Ames

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30-Jan-87 20:18:59 EST
From:      lars@ACC-SB-UNIX.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   New Layout of 32-bit addresses ?

A private communication mentioned that 

> The current 32-bit address is divided into 4 fields (N,H,L,I):
> 
>           |   N    |    H     |    L   |    I   |
>           |--------|----------|--------|--------|
> 
> The proposed division (N,H1,H2,H3,F,G,L1,I1,I2) is according to 
> that which is to be proposed by BBN and the DDN PMO in an upcoming 
> RFC expected out in the January timeframe:
> 
>          |   N   |H1     H2|H3 F|G|L1|I1|   I2  |
>          |-------|---------|------------|-------|
> 
> The F field is proposed as a flag to indicate a X.25 Logical Address;
> the G field is reserved for future use.  With Logical Addressing
> the H field is proposed to be expanded to 10 bits (H1,H2,H3) and the
> I field similarily (I1,I2).  With Logical Addressing, there will
> remain a 16-bit X.25 Logical Address (H,I).  This means there are
> 4 Internet Addresses which map to the same X.25 Logical Address
> (those which differ only in the H3,L1, and I1 fields).  For
> compatibility with existing DDN X.25 the H field must still be
> greater than 64 for all X.25 Logical Addresses.

This prompts a few questions:

(1) Current address formats:
    I can see in HOSTS.TXT that currently class A networks based
    on C/30 PSN's use the above format, mostly with
    N = network number (1-126)
    H = port number on PSN
    L = 0 (can be non-zero with a port expander)
    I = PSN number in network

    I believe that class B networks based on BBN PSN's use
    N,H = network number (128.1 - 191.255)
    L = port number on PSN
    I = PSN number in network

    I don't know what format is used for class C PSN's.

(2) Logical addressing.
    As I understand it, the above physical addressing scheme is
    used throughout ARPAnet and MILNET; other networks use
    "logical addressing". Software generally has to be configured
    to know which of the two schemes is in use.
    When a host comes up, the PSN tells it its address if the
    network is physical, but the host tells the PSN its address
    if the network is logical.

    Physical and logical addressing cannot be mixed in the same
    network.

(3) IP addresses versus AHIP addresses.
    Logical addressing is a feature of the 1822 interface protocol
    (AHIP) and there is a standard translation from IP to AHIP.

(4) IP addresses versus X.25 addresses
    The conversion between IP addresses and X.25 addresses is defined
    in the DDN X.25 spec. so long as the class A "L" field is not used.
    Use of bits in the IP address to trigger a request for logical
    addresses is a new feature that may invalidate current port
    expander implementations.

(5) RFC review.
    BBN and the DDN PMO are discussing this, but no decision will be
    made until the RFC has had a chance to elicit comments from the
    protocol research community ?

Did I get all of that right ?

Lars Poulsen, ACC Customer Service

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30-Jan-87 21:49:23 EST
From:      mills@udel.edu.UUCP
To:        mod.protocols.tcp-ip
Subject:   X.25 may be off the hook

Folks,

Upon receiving a report the PSC-GW gateway between the NSFNET and ARPANET
swamps was running much better, I peeked in and shot a few scatter
diagrams. The results are fantastic and seem to indicate the problems
I reported last month have been solved. As you may remember, scatter
diagrams revealed something wrong in the ACC 5250 interface, PSN or
X.25 implementation. I was worried that this might be symptomaniac of
a more pervasive problem; however, it seems at least the problem at PSC-GW
has been resolved. The delays and variance are down by a factor of ten
and the incremental bit rate is six times higher than when I last measured
it a few days ago.

It may be most interesting if either/both ACC or BBN representatives could
summarize for this list what the problem was and how it was resolved.

As usual, the Sun-format scatter diagrams are on udel2.udel.edu (192.5.39.88)
and can be retrieved with ftp/anonymous/guest from the file psc9.bit.

Dave
-------

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 1987 09:16-PST
From:      STJOHNS@SRI-NIC.ARPA
To:        lars@ACC-SB-UNIX.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, gary@ACC-SB-UNIX.ARPA
Subject:   Re: New Layout of 32-bit addresses ?
To  forstall ANY questions on the TCP list until the RFC makes it
to the NIC I will make some comments on what and why.  This isn't
the final word.

1)  Due  to  the  fact that the MILNET is growing at a phenomenal
rate, we have had  to  start  considering  how  to  go  past  the
limitation of 256 PSN on the network.  Those of you familiar with
the 1822 and 1822L specs will realize the address  field  in  the
1822 and 1822 L physical headers limits us to 256.

2)  Since  we  are  toying with 1822, we figured we might as well
work out a way of including logical addressing in the 1822.

3) BBN will forward documents to the PMO (i.e.  ME)  for  review.
When we are satisfied, the documents will be forwarded to the NIC
in RFC format for public comment of 6 weeks duration.

Until the  documents  are  published,  we  will  not  respond  to
questions or comments for the simple reason I don't have the time
to answer the same questions over and over.

This bucket of worms was not supposed to be opened untilk the RFC
was available

Mike (no, it doesn't do forms) StJohns
-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      31-Jan-87 02:26:25-UT
From:      mills@udel.edu
To:        tcp-ip@sri-nic.arpa
Subject:   X.25 may be off the hook
Folks,

Upon receiving a report the PSC-GW gateway between the NSFNET and ARPANET
swamps was running much better, I peeked in and shot a few scatter
diagrams. The results are fantastic and seem to indicate the problems
I reported last month have been solved. As you may remember, scatter
diagrams revealed something wrong in the ACC 5250 interface, PSN or
X.25 implementation. I was worried that this might be symptomaniac of
a more pervasive problem; however, it seems at least the problem at PSC-GW
has been resolved. The delays and variance are down by a factor of ten
and the incremental bit rate is six times higher than when I last measured
it a few days ago.

It may be most interesting if either/both ACC or BBN representatives could
summarize for this list what the problem was and how it was resolved.

As usual, the Sun-format scatter diagrams are on udel2.udel.edu (192.5.39.88)
and can be retrieved with ftp/anonymous/guest from the file psc9.bit.

Dave
-------
-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Sat, 31-Jan-87 22:58:24 EST
From:      dyer@harvard.HARVARD.EDU@spdcc.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: internet numbering scheme

If your network might eventually be connected to the Internet, you can petition
the NIC for a "network number assignment for a network unconnected to the ARPA
Internet".  This will simplify matters if you ever manage to get hooked up later
(say, via CSNET.)  Send a message to Joyce Reynolds, jkrey@venera.isi.edu, and
she'll send you an electronic form to fill out.  You may request a Class B or
Class C network number, depending on your needs.

I don't see how having VMS machines has much to do with consistent network
numbering.  If they're running TCP/IP and support subnets, they're just like
any other host.  If VMS machines are talking DECnet on an interconnected DECnet,
then you have to worry about being consistent with the other DECnet hosts
and conventions, but it don't have nothing to do with TCP/IP.
---
Steve Dyer
dyer@harvard.HARVARD.EDU
dyer@spdcc.COM aka {linus,wanginst,bbnccv,harvard,ima,ihnp4}!spdcc!dyer

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Sat, 31 Jan 87 22:58:24 EST
From:      spdcc!dyer@harvard.HARVARD.EDU
To:        harvard!tcp-ip@sri-nic.arpa, mod.protocols.tcp-ip
Subject:   Re: internet numbering scheme
If your network might eventually be connected to the Internet, you can petition
the NIC for a "network number assignment for a network unconnected to the ARPA
Internet".  This will simplify matters if you ever manage to get hooked up later
(say, via CSNET.)  Send a message to Joyce Reynolds, jkrey@venera.isi.edu, and
she'll send you an electronic form to fill out.  You may request a Class B or
Class C network number, depending on your needs.

I don't see how having VMS machines has much to do with consistent network
numbering.  If they're running TCP/IP and support subnets, they're just like
any other host.  If VMS machines are talking DECnet on an interconnected DECnet,
then you have to worry about being consistent with the other DECnet hosts
and conventions, but it don't have nothing to do with TCP/IP.
---
Steve Dyer
dyer@harvard.HARVARD.EDU
dyer@spdcc.COM aka {linus,wanginst,bbnccv,harvard,ima,ihnp4}!spdcc!dyer

END OF DOCUMENT