----MESSAGE-BEGIN---- <1987010101483100> Received: from UDEL2.UDEL.EDU ([192.5.39.88]) by SRI-NIC.ARPA with TCP; Wed 31 Dec 86 18:01:33-PST Date: 01-Jan-87 01:48:31-UT From: mills@huey.udel.edu Subject: Ask not for whom the chimes tinkle To: tcp-ip@sri-nic.arpa, nsfnet@sh.cs.net 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987010107260000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Thu 1 Jan 87 09:28:19-PST Date: 1 Jan 1987 12:26-EST Sender: CERF@A.ISI.EDU Subject: Re: Ask not for whom the chimes tinkle From: CERF@A.ISI.EDU To: mills@HUEY.UDEL.EDU Cc: tcp-ip@SRI-NIC.ARPA, nsfnet@SH.CS.NET Message-ID: <[A.ISI.EDU] 1-Jan-87 12:26:37.CERF> In-Reply-To: The message of 01-Jan-87 01:48:31-UT from mills@huey.udel.edu 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701011534.a000049%40Huey.UDEL.EDU] <1987010110340500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills%udel.edu@LOUIE.UDEL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Ask not for whom the chimes tinkle Message-ID: <8701011534.a000049@Huey.UDEL.EDU> Date: Thu, 1-Jan-87 15:34:05 EST Article-I.D.: Huey.8701011534.a000049 Posted: Thu Jan 1 15:34:05 1987 Date-Received: Thu, 1-Jan-87 21:45:47 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701021025.AA04489%40topaz.rutgers.edu] <1987010200255800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Becomming an Internet site Message-ID: <8701021025.AA04489@topaz.rutgers.edu> Date: Fri, 2-Jan-87 05:25:58 EST Article-I.D.: topaz.8701021025.AA04489 Posted: Fri Jan 2 05:25:58 1987 Date-Received: Fri, 2-Jan-87 18:46:44 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [7259.536602072%40huey] <1987010208320700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: farber@HUEY.UDEL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Becomming an Internet site Message-ID: <7259.536602072@huey> Date: Fri, 2-Jan-87 13:32:07 EST Article-I.D.: huey.7259.536602072 Posted: Fri Jan 2 13:32:07 1987 Date-Received: Fri, 2-Jan-87 18:49:27 EST References: <8701021025.AA04489@topaz.rutgers.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701021538.AA19450%40mitre.ARPA] <1987010209450900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mckee@MITRE.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Ask not for whom the chimes tinkle Message-ID: <8701021538.AA19450@mitre.ARPA> Date: Fri, 2-Jan-87 14:45:09 EST Article-I.D.: mitre.8701021538.AA19450 Posted: Fri Jan 2 14:45:09 1987 Date-Received: Fri, 2-Jan-87 18:51:42 EST References: <8701011534.a000049@Huey.UDEL.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Washington, D.C. Lines: 12 Approved: tcp-ip@sri-nic.arpa >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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701021512.a008901%40Huey.UDEL.EDU] <1987010210123700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills%udel.edu@LOUIE.UDEL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Ask not for whom the chimes tinkle Message-ID: <8701021512.a008901@Huey.UDEL.EDU> Date: Fri, 2-Jan-87 15:12:37 EST Article-I.D.: Huey.8701021512.a008901 Posted: Fri Jan 2 15:12:37 1987 Date-Received: Fri, 2-Jan-87 20:44:29 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701022019.AA09740%40vu-vlsi.UUCP] <1987010210191800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: UUCP@seismo.CSS.GOV@vu-vlsi.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8701022019.AA09740@vu-vlsi.UUCP> Date: Fri, 2-Jan-87 15:19:18 EST Article-I.D.: vu-vlsi.8701022019.AA09740 Posted: Fri Jan 2 15:19:18 1987 Date-Received: Fri, 2-Jan-87 22:37:38 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 42 Approved: tcp-ip@sri-nic.arpa 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701022020.AA09781%40vu-vlsi.UUCP] <1987010210195900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: UUCP@seismo.CSS.GOV@vu-vlsi.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8701022020.AA09781@vu-vlsi.UUCP> Date: Fri, 2-Jan-87 15:19:59 EST Article-I.D.: vu-vlsi.8701022020.AA09781 Posted: Fri Jan 2 15:19:59 1987 Date-Received: Sat, 3-Jan-87 00:35:18 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 53 Approved: tcp-ip@sri-nic.arpa 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987010210270000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Fri 2 Jan 87 12:29:30-PST Date: 2 Jan 1987 15:27-EST Sender: CERF@A.ISI.EDU Subject: Re: Ask not for whom the chimes tinkle From: CERF@A.ISI.EDU To: Mills%udel.edu@LOUIE.UDEL.EDU Cc: mills@HUEY.UDEL.EDU, tcp-ip@SRI-NIC.ARPA Cc: nsfnet@SH.CS.NET Message-ID: <[A.ISI.EDU] 2-Jan-87 15:27:26.CERF> In-Reply-To: <8701011534.a000049@Huey.UDEL.EDU> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701021948.AA18392%40phun.riacs.edu] <1987010212381100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: leiner@ICARUS.RIACS.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Becomming an Internet site Message-ID: <8701021948.AA18392@phun.riacs.edu> Date: Fri, 2-Jan-87 17:38:11 EST Article-I.D.: phun.8701021948.AA18392 Posted: Fri Jan 2 17:38:11 1987 Date-Received: Fri, 2-Jan-87 20:39:15 EST References: <12267352563.28.ROMKEY@XX.LCS.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa 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 ---------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701022126.a011338%40Huey.UDEL.EDU] <1987010216260900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills%udel.edu@LOUIE.UDEL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Ask not for whom the chimes tinkle Message-ID: <8701022126.a011338@Huey.UDEL.EDU> Date: Fri, 2-Jan-87 21:26:09 EST Article-I.D.: Huey.8701022126.a011338 Posted: Fri Jan 2 21:26:09 1987 Date-Received: Sat, 3-Jan-87 01:41:57 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 21 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701040412.AA21966%40ucbvax.Berkeley.EDU] <1987010315581700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LYNCH@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Ask not for whom the chimes tinkle Message-ID: <8701040412.AA21966@ucbvax.Berkeley.EDU> Date: Sat, 3-Jan-87 20:58:17 EST Article-I.D.: ucbvax.8701040412.AA21966 Posted: Sat Jan 3 20:58:17 1987 Date-Received: Sun, 4-Jan-87 01:49:06 EST References: <8701022126.a011338@Huey.UDEL.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987010315581701> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Sat 3 Jan 87 18:00:55-PST Date: 3 Jan 1987 20:58:17 EST Subject: Re: Ask not for whom the chimes tinkle From: Dan Lynch To: Mills@HUEY.UDEL.EDU cc: tcp-ip@SRI-NIC.ARPA, nsfnet@SH.CS.NET, lynch@A.ISI.EDU In-Reply-To: <8701022126.a011338@Huey.UDEL.EDU> 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701040243.AA16444%40hoptoad.uucp] <1987010316432000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tim@cgl.ucsf.edu@hoptoad.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: More NFS discussion Message-ID: <8701040243.AA16444@hoptoad.uucp> Date: Sat, 3-Jan-87 21:43:20 EST Article-I.D.: hoptoad.8701040243.AA16444 Posted: Sat Jan 3 21:43:20 1987 Date-Received: Sun, 4-Jan-87 01:49:31 EST References: <8612222136.AA06270@rose.sun.com> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: hoptoad.UUCP!tim@cgl.ucsf.edu (Tim Maroney) Organization: Centram Systems, Berkeley Lines: 13 Approved: tcp-ip@sri-nic.arpa 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) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12268561964.27.PERILLO%40SRI-NIC.ARPA] <1987010510234100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PERILLO@SRI-NIC.ARPA (Francine Perillo) Newsgroups: mod.protocols.tcp-ip Subject: Contacting the NIC Message-ID: <12268561964.27.PERILLO@SRI-NIC.ARPA> Date: Mon, 5-Jan-87 15:23:41 EST Article-I.D.: SRI-NIC.12268561964.27.PERILLO Posted: Mon Jan 5 15:23:41 1987 Date-Received: Mon, 5-Jan-87 23:30:46 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701061609.AA10310%40cgcha.uucp] <1987010606085600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: whna%cgcha.UUCP%cernvax.BITNET@WISCVM.WISC.EDU (Heinz Naef) Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8701061609.AA10310@cgcha.uucp> Date: Tue, 6-Jan-87 11:08:56 EST Article-I.D.: cgcha.8701061609.AA10310 Posted: Tue Jan 6 11:08:56 1987 Date-Received: Wed, 7-Jan-87 23:38:34 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987010802341600> Received: from cu-arpa.cs.cornell.edu by SRI-NIC.ARPA with TCP; Thu 8 Jan 87 04:32:51-PST Received: by cu-arpa.cs.cornell.edu (5.45/4.30) id AA04575; Thu, 8 Jan 87 07:34:16 EST Date: Thu, 8 Jan 87 07:34:16 EST From: jqj@gvax.cs.cornell.edu (J Q Johnson) Message-Id: <8701081234.AA26850@gvax.cs.cornell.edu> Received: by gvax.cs.cornell.edu (5.45/4.30) id AA26850; Thu, 8 Jan 87 07:34:16 EST Newsgroups: arpa.tcp-ip Subject: Authentication (was: No more NFS flames) Summary: Expires: Sender: Reply-To: jqj@gvax.cs.cornell.edu (J Q Johnson) Followup-To: Distribution: Organization: Cornell Univ. CS Dept. Ithaca NY Keywords: Apparently-To: tcp-ip@sri-nic.arpa 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987010807180000> Received: from LOGICON.ARPA by SRI-NIC.ARPA with TCP; Thu 8 Jan 87 15:25:21-PST Date: 8 Jan 87 15:18 PST From: Tom Perrine To: mills@huey.udel.edu Cc: tcp-ip@sri-nic.arpa, Tom Perrine Subject: Re: Ask not for whom the chimes tinkle In-Reply-To: Message from "mills@huey.udel.edu" on 01/01/a at 87: 0 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701082340.AA17468%40ucbvax.Berkeley.EDU] <1987010813180000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Perrine@LOGICON.ARPA (Tom Perrine) Newsgroups: mod.protocols.tcp-ip Subject: Re: Ask not for whom the chimes tinkle Message-ID: <8701082340.AA17468@ucbvax.Berkeley.EDU> Date: Thu, 8-Jan-87 18:18:00 EST Article-I.D.: ucbvax.8701082340.AA17468 Posted: Thu Jan 8 18:18:00 1987 Date-Received: Fri, 9-Jan-87 00:38:02 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 20 Approved: tcp-ip@sri-nic.arpa 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870108-161706-2043%40Xerox] <1987010814165100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Murray.pa@XEROX.COM Newsgroups: mod.protocols.tcp-ip Subject: What's a repeater, bridge, router, or gateway? Message-ID: <870108-161706-2043@Xerox> Date: Thu, 8-Jan-87 19:16:51 EST Article-I.D.: Xerox.870108-161706-2043 Posted: Thu Jan 8 19:16:51 1987 Date-Received: Fri, 9-Jan-87 01:47:45 EST References: <11Feb86.133608.EN0C@A.CS.CMU.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 91 Approved: tcp-ip@sri-nic.arpa 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.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1704953%40um.cc.umich.edu] <1987010816365200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Hans-Werner_Braun@um.cc.umich.edu Newsgroups: mod.protocols.tcp-ip Subject: Re: Ask not for whom the chimes tinkle Message-ID: <1704953@um.cc.umich.edu> Date: Thu, 8-Jan-87 21:36:52 EST Article-I.D.: um.1704953 Posted: Thu Jan 8 21:36:52 1987 Date-Received: Fri, 9-Jan-87 01:40:41 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701090516.AA00786%40flash.bellcore.com] <1987010819165800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@FLASH.BELLCORE.COM (Phil R. Karn) Newsgroups: mod.protocols.tcp-ip Subject: Re: Authentication (was: No more NFS flames) Message-ID: <8701090516.AA00786@flash.bellcore.com> Date: Fri, 9-Jan-87 00:16:58 EST Article-I.D.: flash.8701090516.AA00786 Posted: Fri Jan 9 00:16:58 1987 Date-Received: Fri, 9-Jan-87 04:47:47 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 32 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701090105.a017755%40Huey.UDEL.EDU] <1987010820055300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills%udel.edu@LOUIE.UDEL.EDU Newsgroups: mod.protocols.tcp-ip Subject: Re: Ask not for whom the chimes tinkle Message-ID: <8701090105.a017755@Huey.UDEL.EDU> Date: Fri, 9-Jan-87 01:05:53 EST Article-I.D.: Huey.8701090105.a017755 Posted: Fri Jan 9 01:05:53 1987 Date-Received: Fri, 9-Jan-87 06:16:53 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 20 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701090124.a018369%40Huey.UDEL.EDU] <1987010820244400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills%udel.edu@LOUIE.UDEL.EDU Newsgroups: mod.protocols.tcp-ip Subject: Re: Ask not for whom the chimes tinkle Message-ID: <8701090124.a018369@Huey.UDEL.EDU> Date: Fri, 9-Jan-87 01:24:44 EST Article-I.D.: Huey.8701090124.a018369 Posted: Fri Jan 9 01:24:44 1987 Date-Received: Fri, 9-Jan-87 06:17:39 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 20 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1705302%40um.cc.umich.edu] <1987010902325200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Hans-Werner_Braun@um.cc.umich.edu.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Ask not for whom the chimes tinkle Message-ID: <1705302@um.cc.umich.edu> Date: Fri, 9-Jan-87 07:32:52 EST Article-I.D.: um.1705302 Posted: Fri Jan 9 07:32:52 1987 Date-Received: Fri, 9-Jan-87 22:42:38 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701091527.AA27212%40lbl-csam.arpa] <1987010905265800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: van@LBL-CSAM.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: tcp monitor available for anonymous ftp (long msg) Message-ID: <8701091527.AA27212@lbl-csam.arpa> Date: Fri, 9-Jan-87 10:26:58 EST Article-I.D.: lbl-csam.8701091527.AA27212 Posted: Fri Jan 9 10:26:58 1987 Date-Received: Fri, 9-Jan-87 23:18:39 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 222 Approved: tcp-ip@sri-nic.arpa 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.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701091300.a024423%40Huey.UDEL.EDU] <1987010908002600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills%udel.edu@LOUIE.UDEL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Authentication (was: No more NFS flames) Message-ID: <8701091300.a024423@Huey.UDEL.EDU> Date: Fri, 9-Jan-87 13:00:26 EST Article-I.D.: Huey.8701091300.a024423 Posted: Fri Jan 9 13:00:26 1987 Date-Received: Fri, 9-Jan-87 23:35:42 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701091809.AA05191%40mitre-gateway.arpa] <1987010908092800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gross@MITRE-GATEWAY.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: What's a repeater, bridge, router, or gateway? Message-ID: <8701091809.AA05191@mitre-gateway.arpa> Date: Fri, 9-Jan-87 13:09:28 EST Article-I.D.: mitre-ga.8701091809.AA05191 Posted: Fri Jan 9 13:09:28 1987 Date-Received: Fri, 9-Jan-87 23:36:28 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa > 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".) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701091319.a024517%40Huey.UDEL.EDU] <1987010908193800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills%udel.edu@LOUIE.UDEL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Ask not for whom the chimes tinkle Message-ID: <8701091319.a024517@Huey.UDEL.EDU> Date: Fri, 9-Jan-87 13:19:38 EST Article-I.D.: Huey.8701091319.a024517 Posted: Fri Jan 9 13:19:38 1987 Date-Received: Fri, 9-Jan-87 23:38:17 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701092303.AA04975%40flash.bellcore.com] <1987010913035900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@FLASH.BELLCORE.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Authentication (was: No more NFS flames) Message-ID: <8701092303.AA04975@flash.bellcore.com> Date: Fri, 9-Jan-87 18:03:59 EST Article-I.D.: flash.8701092303.AA04975 Posted: Fri Jan 9 18:03:59 1987 Date-Received: Fri, 9-Jan-87 23:43:10 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701092241.a029933%40Huey.UDEL.EDU] <1987010917414600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills%udel.edu@LOUIE.UDEL.EDU Newsgroups: mod.protocols.tcp-ip Subject: Re: Authentication (was: No more NFS flames) Message-ID: <8701092241.a029933@Huey.UDEL.EDU> Date: Fri, 9-Jan-87 22:41:46 EST Article-I.D.: Huey.8701092241.a029933 Posted: Fri Jan 9 22:41:46 1987 Date-Received: Sat, 10-Jan-87 03:46:41 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701102230.AA21918%40ucbvax.Berkeley.EDU] <1987011012311900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mills@huey.udel.edu.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Clocks moving relatively Message-ID: <8701102230.AA21918@ucbvax.Berkeley.EDU> Date: Sat, 10-Jan-87 17:31:19 EST Article-I.D.: ucbvax.8701102230.AA21918 Posted: Sat Jan 10 17:31:19 1987 Date-Received: Sat, 10-Jan-87 21:35:52 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701110003.AA06976%40topaz.rutgers.edu] <1987011014032700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: secure replacements for passwords Message-ID: <8701110003.AA06976@topaz.rutgers.edu> Date: Sat, 10-Jan-87 19:03:27 EST Article-I.D.: topaz.8701110003.AA06976 Posted: Sat Jan 10 19:03:27 1987 Date-Received: Sat, 10-Jan-87 21:36:48 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 49 Approved: tcp-ip@sri-nic.arpa 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701110205.AA13719%40cieunix.rpi.edu] <1987011016050900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: weltyc%cieunix@CSV.RPI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Ask not for whom the chimes tinkle Message-ID: <8701110205.AA13719@cieunix.rpi.edu> Date: Sat, 10-Jan-87 21:05:09 EST Article-I.D.: cieunix.8701110205.AA13719 Posted: Sat Jan 10 21:05:09 1987 Date-Received: Sat, 10-Jan-87 23:56:37 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa >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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987011022200400> Received: from UDEL2.UDEL.EDU ([192.5.39.88]) by SRI-NIC.ARPA with TCP; Sat 10 Jan 87 14:24:57-PST Date: 10-Jan-87 22:20:04-UT From: mills@huey.udel.edu Subject: Clocks moving relatively To: tcp-ip@sri-nic.arpa, nsfnet@sh.cs.net 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701111430.AA00591%40ucbvax.Berkeley.EDU] <1987011103350000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: NS-DDN@DDN2.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Password Security for the UCLA ACP Message-ID: <8701111430.AA00591@ucbvax.Berkeley.EDU> Date: Sun, 11-Jan-87 08:35:00 EST Article-I.D.: ucbvax.8701111430.AA00591 Posted: Sun Jan 11 08:35:00 1987 Date-Received: Sun, 11-Jan-87 12:38:28 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 39 Approved: tcp-ip@sri-nic.arpa 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987011103350001> Received: from ddn2 by SRI-NIC.ARPA with TCP; Sun 11 Jan 87 06:16:24-PST Date: 11 Jan 87 08:35 EST From: NS-DDN @ DDN2 Subject: Password Security for the UCLA ACP To: hedrick @ TOPAZ CC: tcp-ip @ SRI-NIC 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701111745.AA01536%40ucbvax.Berkeley.EDU] <1987011104382000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LYNCH@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: secure replacements for passwords Message-ID: <8701111745.AA01536@ucbvax.Berkeley.EDU> Date: Sun, 11-Jan-87 09:38:20 EST Article-I.D.: ucbvax.8701111745.AA01536 Posted: Sun Jan 11 09:38:20 1987 Date-Received: Sun, 11-Jan-87 15:35:16 EST References: <8701110003.AA06976@topaz.rutgers.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@sri-nic.arpa 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987011104382001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Sun 11 Jan 87 09:41:04-PST Date: 11 Jan 1987 09:38:20 EST Subject: Re: secure replacements for passwords From: Dan Lynch To: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) cc: tcp-ip@SRI-NIC.ARPA, LYNCH@A.ISI.EDU In-Reply-To: <8701110003.AA06976@topaz.rutgers.edu> 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987011106550000> Mail-From: STJOHNS created at 11-Jan-87 14:57:49 Date: 11 Jan 1987 14:55-PST Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: secure replacements for passwords From: STJOHNS@SRI-NIC.ARPA To: LYNCH@A.ISI.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA]11-Jan-87 14:55:49.STJOHNS> In-Reply-To: The message of 11 Jan 1987 09:38:20 EST from Dan Lynch 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) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870111-133755-4114%40Xerox] <1987011111375000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Murray.pa@XEROX.COM Newsgroups: mod.protocols.tcp-ip Subject: Re: secure replacements for passwords Message-ID: <870111-133755-4114@Xerox> Date: Sun, 11-Jan-87 16:37:50 EST Article-I.D.: Xerox.870111-133755-4114 Posted: Sun Jan 11 16:37:50 1987 Date-Received: Sun, 11-Jan-87 23:22:41 EST References: <8701110003.AA06976@topaz.rutgers.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 30 Approved: tcp-ip@sri-nic.arpa 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 ...). ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870112152639.858014%40MIT-MULTICS.ARPA] <1987011205260000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JSLove@MIT-MULTICS.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: secure replacements for passwords Message-ID: <870112152639.858014@MIT-MULTICS.ARPA> Date: Mon, 12-Jan-87 10:26:00 EST Article-I.D.: MIT-MULT.870112152639.858014 Posted: Mon Jan 12 10:26:00 1987 Date-Received: Mon, 12-Jan-87 21:35:45 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 90 Approved: tcp-ip@sri-nic.arpa 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701121034.aa13795%40SEM.BRL.ARPA] <1987011205340800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@BRL.ARPA (Ron Natalie) Newsgroups: mod.protocols.tcp-ip Subject: Re: Password Security for the UCLA ACP Message-ID: <8701121034.aa13795@SEM.BRL.ARPA> Date: Mon, 12-Jan-87 10:34:08 EST Article-I.D.: SEM.8701121034.aa13795 Posted: Mon Jan 12 10:34:08 1987 Date-Received: Mon, 12-Jan-87 22:37:30 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701121603.AA14907%40ucbvax.Berkeley.EDU] <1987011205411000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PADLIPSKY@A.ISI.EDU Newsgroups: mod.protocols.tcp-ip Subject: FTAM Implications Wrap-up (Maybe) Message-ID: <8701121603.AA14907@ucbvax.Berkeley.EDU> Date: Mon, 12-Jan-87 10:41:10 EST Article-I.D.: ucbvax.8701121603.AA14907 Posted: Mon Jan 12 10:41:10 1987 Date-Received: Mon, 12-Jan-87 22:36:36 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 175 Approved: tcp-ip@sri-nic.arpa 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: 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 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: 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 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701121504.AA09516%40mitre.ARPA] <1987011206184400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mckee@MITRE.ARPA (H. Craig McKee) Newsgroups: mod.protocols.tcp-ip Subject: Re: secure replacements for passwords Message-ID: <8701121504.AA09516@mitre.ARPA> Date: Mon, 12-Jan-87 11:18:44 EST Article-I.D.: mitre.8701121504.AA09516 Posted: Mon Jan 12 11:18:44 1987 Date-Received: Mon, 12-Jan-87 22:37:02 EST References: <8701110003.AA06976@topaz.rutgers.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Washington, D.C. Lines: 18 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701122156.AA00076%40apolling.imagen.uucp] <1987011211563100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: geof@decwrl.DEC.COM@apolling.UUCP (Geof Cooper) Newsgroups: mod.protocols.tcp-ip Subject: Re: secure replacements for passwords Message-ID: <8701122156.AA00076@apolling.imagen.uucp> Date: Mon, 12-Jan-87 16:56:31 EST Article-I.D.: apolling.8701122156.AA00076 Posted: Mon Jan 12 16:56:31 1987 Date-Received: Tue, 13-Jan-87 07:08:10 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: imagen!geof@decwrl.DEC.COM Organization: The ARPA Internet Lines: 41 Approved: tcp-ip@sri-nic.arpa > 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701122344.AA05481%40csv.rpi.edu] <1987011213442900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: yerazuws@CSV.RPI.EDU (Crah) Newsgroups: mod.protocols.tcp-ip Subject: Re: secure replacements for passwords Message-ID: <8701122344.AA05481@csv.rpi.edu> Date: Mon, 12-Jan-87 18:44:29 EST Article-I.D.: csv.8701122344.AA05481 Posted: Mon Jan 12 18:44:29 1987 Date-Received: Tue, 13-Jan-87 04:57:10 EST References: <8701111745.AA01536@ucbvax.Berkeley.EDU> Sender: molbio@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 65 Approved: tcp-ip@sri-nic.arpa Summary: How to avoid tampering....the hard way 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701130557.AA00409%40ucbvax.Berkeley.EDU] <1987011219583400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mills@HUEY.UDEL.EDU Newsgroups: mod.protocols.tcp-ip Subject: How sweet it is Message-ID: <8701130557.AA00409@ucbvax.Berkeley.EDU> Date: Tue, 13-Jan-87 00:58:34 EST Article-I.D.: ucbvax.8701130557.AA00409 Posted: Tue Jan 13 00:58:34 1987 Date-Received: Tue, 13-Jan-87 06:45:26 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 30 Approved: tcp-ip@sri-nic.arpa 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701131008.AA20447%40lbl-csam.arpa] <1987011300084300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: van@LBL-CSAM.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Analyzing Acknowledgement Strategies Message-ID: <8701131008.AA20447@lbl-csam.arpa> Date: Tue, 13-Jan-87 05:08:43 EST Article-I.D.: lbl-csam.8701131008.AA20447 Posted: Tue Jan 13 05:08:43 1987 Date-Received: Tue, 13-Jan-87 18:59:05 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 99 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987011300181600> Received: from vax.darpa.mil by SRI-NIC.ARPA with TCP; Tue 13 Jan 87 02:19:32-PST Received: by vax.darpa.mil (4.12/4.7) id AA20733; Tue, 13 Jan 87 05:18:27 est Date: Tue 13 Jan 87 05:18:16-EST From: Dennis G. Perry Subject: Re: Re: Password Security for the UCLA ACP To: ron@BRL.ARPA Cc: NS-DDN@DDN2.ARPA, hedrick@TOPAZ.RUTGERS.EDU, tcp-ip@SRI-NIC.ARPA, perry@VAX.DARPA.MIL Message-Id: In-Reply-To: Message from "Ron Natalie " of Mon, 12 Jan 87 10:34:08 EST 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1713165%40um.cc.umich.edu] <1987011303503200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Richard_S._Conto@UM.CC.UMICH.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Password Security for the UCLA ACP Message-ID: <1713165@um.cc.umich.edu> Date: Tue, 13-Jan-87 08:50:32 EST Article-I.D.: um.1713165 Posted: Tue Jan 13 08:50:32 1987 Date-Received: Tue, 13-Jan-87 19:23:22 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 27 Approved: tcp-ip@sri-nic.arpa In the message ( Message-Id: <8701121034.aa13795@SEM.BRL.ARPA>) of Mon, 12 Jan 87, Ron Natalie () 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." ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870113143008.200363%40MIT-MULTICS.ARPA] <1987011304300000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JSLove@MIT-MULTICS.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: secure replacements for passwords Message-ID: <870113143008.200363@MIT-MULTICS.ARPA> Date: Tue, 13-Jan-87 09:30:00 EST Article-I.D.: MIT-MULT.870113143008.200363 Posted: Tue Jan 13 09:30:00 1987 Date-Received: Tue, 13-Jan-87 19:23:41 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 35 Approved: tcp-ip@sri-nic.arpa 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.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987011305324200> Received: from UDEL2.UDEL.EDU ([192.5.39.88]) by SRI-NIC.ARPA with TCP; Mon 12 Jan 87 21:51:08-PST Date: 13-Jan-87 05:32:42-UT From: mills@huey.udel.edu Subject: How sweet it is To: tcp-ip@sri-nic.arpa, nsfnet-routing@mcr.umich.edu 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987011306445900> Received: from cu-arpa.cs.cornell.edu by SRI-NIC.ARPA with TCP; Tue 13 Jan 87 08:43:38-PST Received: by cu-arpa.cs.cornell.edu (5.45/4.30) id AA26190; Tue, 13 Jan 87 11:45:06 EST Date: Tue, 13 Jan 87 11:44:59 EST From: hurf@tcgould.tn.cornell.edu (Hurf Sheldon) Message-Id: <8701131644.AA24720@tcgould.tn.cornell.edu> Received: by tcgould.tn.cornell.edu (5.31/4.30) id AA24720; Tue, 13 Jan 87 11:44:59 EST Newsgroups: arpa.tcp-ip Subject: Hot setup for PC-AT? Expires: References: Sender: Reply-To: batcomputer!hurf@cu-arpa.cs.cornell.edu (Hurf Sheldon) Followup-To: Distribution: na Organization: Theory Center, Cornell University, Ithaca NY Keywords: IBM ,PC-AT Apparently-To: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701131751.AA17600%40cieunix.rpi.edu] <1987011307513400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: weltyc%cieunix@CSV.RPI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Tektronics TCP/IP for VMS Message-ID: <8701131751.AA17600@cieunix.rpi.edu> Date: Tue, 13-Jan-87 12:51:34 EST Article-I.D.: cieunix.8701131751.AA17600 Posted: Tue Jan 13 12:51:34 1987 Date-Received: Tue, 13-Jan-87 19:38:44 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701131322.a009629%40Huey.UDEL.EDU] <1987011308224600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@LOUIE.UDEL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Analyzing Acknowledgement Strategies Message-ID: <8701131322.a009629@Huey.UDEL.EDU> Date: Tue, 13-Jan-87 13:22:46 EST Article-I.D.: Huey.8701131322.a009629 Posted: Tue Jan 13 13:22:46 1987 Date-Received: Tue, 13-Jan-87 19:39:43 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 35 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701131926.aa07986%40SEM.BRL.ARPA] <1987011314264300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@BRL.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Re: Password Security for the UCLA ACP Message-ID: <8701131926.aa07986@SEM.BRL.ARPA> Date: Tue, 13-Jan-87 19:26:43 EST Article-I.D.: SEM.8701131926.aa07986 Posted: Tue Jan 13 19:26:43 1987 Date-Received: Wed, 14-Jan-87 04:55:23 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 4 Approved: tcp-ip@sri-nic.arpa Yes, last I heard DARCOM (er, AMC) headquarters was contemplating such a system. I haven't heard if it has been installed yet. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701141412.AA23945%40cgcha.uucp] <1987011404121400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: whna%cgcha.UUCP%cernvax.BITNET@WISCVM.WISC.EDU (Heinz Naef) Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8701141412.AA23945@cgcha.uucp> Date: Wed, 14-Jan-87 09:12:14 EST Article-I.D.: cgcha.8701141412.AA23945 Posted: Wed Jan 14 09:12:14 1987 Date-Received: Thu, 15-Jan-87 03:21:55 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 25 Approved: tcp-ip@sri-nic.arpa 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701141554.AA18711%40ohio-state.ARPA] <1987011405541700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bob@OHIO-STATE.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Tektronics TCP/IP for VMS Message-ID: <8701141554.AA18711@ohio-state.ARPA> Date: Wed, 14-Jan-87 10:54:17 EST Article-I.D.: ohio-sta.8701141554.AA18711 Posted: Wed Jan 14 10:54:17 1987 Date-Received: Thu, 15-Jan-87 06:51:01 EST References: <8701131751.AA17600@cieunix.rpi.edu> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: osu-eddie!bob (Bob Sutterfield) Organization: The Ohio State University Department of Computer & Information Science Lines: 5 Keywords: Tektronix TCP/IP VMS free Approved: tcp-ip@sri-nic.arpa Summary: mailing list address provided 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987011408210000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Wed 14 Jan 87 16:25:06-PST Date: 14 Jan 87 16:21:00 PST From: Subject: PSN Interoperability To: "tcp-ip" Reply-To: 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 ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987011409000000> Received: from WISCVM.WISC.EDU by SRI-NIC.ARPA with TCP; Fri 16 Jan 87 06:26:24-PST Received: from (MAILER)OHSTVMA.BITNET by WISCVM.WISC.EDU on 01/16/87 at 08:26:03 CST Received: by OHSTVMA (Mailer X1.23b) id 3364; Fri, 16 Jan 87 08:20:46 EST Resent-Date: Fri, 16 Jan 87 08:20:17 EST Resent-From: Bob Dixon Resent-To: TCP-IP@SRI-NIC.ARPA Date: Thu, 15-JAN-1987 16:40 N From: Subject: Returned Network Mail To: TS0400%OHSTVMA.BITNET@WISCVM.WISC.EDU ----------------------------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)" Sender: "(TCP-IP ARPA Digest)" From: Bob Dixon Subject: Password security To: "(no name)" 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: ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701141716.aa17479%40SEM.BRL.ARPA] <1987011412164700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@BRL.ARPA (Ron Natalie) Newsgroups: mod.protocols.tcp-ip Subject: Re: Password Security for the UCLA ACP Message-ID: <8701141716.aa17479@SEM.BRL.ARPA> Date: Wed, 14-Jan-87 17:16:47 EST Article-I.D.: SEM.8701141716.aa17479 Posted: Wed Jan 14 17:16:47 1987 Date-Received: Thu, 15-Jan-87 05:01:07 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 39 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701150043.AA08445%40ucbvax.Berkeley.EDU] <1987011414210000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: art@ACC.ARPA Newsgroups: mod.protocols.tcp-ip Subject: PSN Interoperability Message-ID: <8701150043.AA08445@ucbvax.Berkeley.EDU> Date: Wed, 14-Jan-87 19:21:00 EST Article-I.D.: ucbvax.8701150043.AA08445 Posted: Wed Jan 14 19:21:00 1987 Date-Received: Thu, 15-Jan-87 05:07:36 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The ARPA Internet Lines: 43 Approved: tcp-ip@sri-nic.arpa 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 ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701150106.AA20453%40aramis.rutgers.edu] <1987011415062900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: lear@rutgers.edu@aramis.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8701150106.AA20453@aramis.rutgers.edu> Date: Wed, 14-Jan-87 20:06:29 EST Article-I.D.: aramis.8701150106.AA20453 Posted: Wed Jan 14 20:06:29 1987 Date-Received: Thu, 15-Jan-87 06:52:36 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 24 Approved: tcp-ip@sri-nic.arpa 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] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987011502260000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Thu 15 Jan 87 04:27:08-PST Date: 15 Jan 1987 07:26-EST Sender: CERF@A.ISI.EDU Subject: Re: secure replacements for passwords From: CERF@A.ISI.EDU To: hedrick@TOPAZ.RUTGERS.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]15-Jan-87 07:26:55.CERF> In-Reply-To: <8701110003.AA06976@topaz.rutgers.edu> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701151311.AA19202%40ucbvax.Berkeley.EDU] <1987011502430000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: NS-DDN@DDN2.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Password Security in the UCLA ACP Message-ID: <8701151311.AA19202@ucbvax.Berkeley.EDU> Date: Thu, 15-Jan-87 07:43:00 EST Article-I.D.: ucbvax.8701151311.AA19202 Posted: Thu Jan 15 07:43:00 1987 Date-Received: Thu, 15-Jan-87 23:54:47 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 42 Approved: tcp-ip@sri-nic.arpa 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987011502430001> Received: from ddn2 by SRI-NIC.ARPA with TCP; Thu 15 Jan 87 04:57:02-PST Date: 15 Jan 87 07:43 EST From: NS-DDN @ DDN2 Subject: Re: Password Security in the UCLA ACP To: hedrick @ TOPAZ.RUTGERS.EDU CC: tcp-ip @ SRI-NIC.ARPA 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987011502590000> Mail-From: STJOHNS created at 15-Jan-87 11:01:27 Date: 15 Jan 1987 10:59-PST Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: PSN Interoperability From: STJOHNS@SRI-NIC.ARPA To: art@ACC.ARPA Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA]15-Jan-87 10:59:45.STJOHNS> In-Reply-To: The message of 14 Jan 87 16:21:00 PST from 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987011504414300> Received: from navajo.stanford.edu by SRI-NIC.ARPA with TCP; Thu 15 Jan 87 13:38:27-PST Received: by navajo.stanford.edu; Thu, 15 Jan 87 12:41:43 PST Date: Thu, 15 Jan 87 12:41:43 PST From: Dan Kolkowitz 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701151850.AA18157%40lbl-csam.arpa] <1987011508501500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: van@LBL-CSAM.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Analyzing Acknowledgement Strategies Message-ID: <8701151850.AA18157@lbl-csam.arpa> Date: Thu, 15-Jan-87 13:50:15 EST Article-I.D.: lbl-csam.8701151850.AA18157 Posted: Thu Jan 15 13:50:15 1987 Date-Received: Thu, 15-Jan-87 23:58:59 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 82 Approved: tcp-ip@sri-nic.arpa 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701152156.AA27126%40ucbvax.Berkeley.EDU] <1987011510414300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kolk@NAVAJO.STANFORD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: (none) Message-ID: <8701152156.AA27126@ucbvax.Berkeley.EDU> Date: Thu, 15-Jan-87 15:41:43 EST Article-I.D.: ucbvax.8701152156.AA27126 Posted: Thu Jan 15 15:41:43 1987 Date-Received: Fri, 16-Jan-87 00:03:05 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701152211.AA27457%40ucbvax.Berkeley.EDU] <1987011511010000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: NRC software, MICOM NI1010A tcp/ip boards & VAXes running VMS Message-ID: <8701152211.AA27457@ucbvax.Berkeley.EDU> Date: Thu, 15-Jan-87 16:01:00 EST Article-I.D.: ucbvax.8701152211.AA27457 Posted: Thu Jan 15 16:01:00 1987 Date-Received: Fri, 16-Jan-87 00:03:46 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987011511010001> Received: from RELAY.CS.NET by SRI-NIC.ARPA with TCP; Thu 15 Jan 87 13:56:08-PST Received: from northeastern.edu by csnet-relay.csnet id ag12696; 15 Jan 87 16:38 EST Date: Thu, 15 Jan 87 16:01 EST From: "I am only an egg." To: tcp-ip@SRI-NIC.ARPA, info-vax@SRI-KL.ARPA Subject: NRC software, MICOM NI1010A tcp/ip boards & VAXes running VMS X-VMS-To: TCP-IP,INFO-VAX 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701152224.AA27812%40ucbvax.Berkeley.EDU] <1987011511110000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: new node init procedures Message-ID: <8701152224.AA27812@ucbvax.Berkeley.EDU> Date: Thu, 15-Jan-87 16:11:00 EST Article-I.D.: ucbvax.8701152224.AA27812 Posted: Thu Jan 15 16:11:00 1987 Date-Received: Fri, 16-Jan-87 00:04:06 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 21 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987011511110001> Received: from RELAY.CS.NET by SRI-NIC.ARPA with TCP; Thu 15 Jan 87 13:56:31-PST Received: from northeastern.edu by csnet-relay.csnet id ah12696; 15 Jan 87 16:38 EST Date: Thu, 15 Jan 87 16:11 EST From: "I am only an egg." To: tcp-ip@SRI-NIC.ARPA Subject: new node init procedures X-VMS-To: TCP-IP 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701152029.aa10103%40SEM.BRL.ARPA] <1987011515291400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mike@BRL.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Analyzing Acknowledgement Strategies Message-ID: <8701152029.aa10103@SEM.BRL.ARPA> Date: Thu, 15-Jan-87 20:29:14 EST Article-I.D.: SEM.8701152029.aa10103 Posted: Thu Jan 15 20:29:14 1987 Date-Received: Fri, 16-Jan-87 23:47:14 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701152158.a012525%40Huey.UDEL.EDU] <1987011516581900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@LOUIE.UDEL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Analyzing Acknowledgement Strategies Message-ID: <8701152158.a012525@Huey.UDEL.EDU> Date: Thu, 15-Jan-87 21:58:19 EST Article-I.D.: Huey.8701152158.a012525 Posted: Thu Jan 15 21:58:19 1987 Date-Received: Fri, 16-Jan-87 22:21:24 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701161434.AA11808%40ucbvax.Berkeley.EDU] <1987011604354000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: POSTMASTER@FINFUN.BITNET Newsgroups: mod.protocols.tcp-ip Subject: Returned Network Mail Message-ID: <8701161434.AA11808@ucbvax.Berkeley.EDU> Date: Fri, 16-Jan-87 09:35:40 EST Article-I.D.: ucbvax.8701161434.AA11808 Posted: Fri Jan 16 09:35:40 1987 Date-Received: Sat, 17-Jan-87 01:05:13 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 28 Approved: tcp-ip@sri-nic.arpa ----------------------------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)" Sender: "(TCP-IP ARPA Digest)" From: Bob Dixon Subject: Password security To: "(no name)" 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: ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701161623.AA13948%40gswd-vms.ARPA] <1987011606221100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: srb%mycroft@GSWD-VMS.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: secure replacements for password Message-ID: <8701161623.AA13948@gswd-vms.ARPA> Date: Fri, 16-Jan-87 11:22:11 EST Article-I.D.: gswd-vms.8701161623.AA13948 Posted: Fri Jan 16 11:22:11 1987 Date-Received: Sat, 17-Jan-87 01:23:26 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 20 Approved: tcp-ip@sri-nic.arpa >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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987011606385900> Received: from SH.CS.NET by SRI-NIC.ARPA with TCP; Fri 16 Jan 87 12:03:33-PST Received: from loki.bbn.com by SH.CS.NET id aa09314; 16 Jan 87 15:01 EST To: tcp-ip%sri-nic.arpa@SH.CS.NET Subject: Gateway Monitoring Date: Fri, 16 Jan 87 14:58:59 -0500 From: Craig Partridge 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) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701161722.AA24656%40videovax.TEK] <1987011607225000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: stever@videovax.tek.com.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8701161722.AA24656@videovax.TEK> Date: Fri, 16-Jan-87 12:22:50 EST Article-I.D.: videovax.8701161722.AA24656 Posted: Fri Jan 16 12:22:50 1987 Date-Received: Sat, 17-Jan-87 01:46:39 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 24 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701161741.AA24750%40videovax.TEK] <1987011607412000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: stever@videovax.tek.com.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8701161741.AA24750@videovax.TEK> Date: Fri, 16-Jan-87 12:41:20 EST Article-I.D.: videovax.8701161741.AA24750 Posted: Fri Jan 16 12:41:20 1987 Date-Received: Sat, 17-Jan-87 01:47:23 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 34 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12271421358.18.KLH%40SRI-NIC.ARPA] <1987011608104800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: KLH@SRI-NIC.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Analyzing Acknowledgement Strategies Message-ID: <12271421358.18.KLH@SRI-NIC.ARPA> Date: Fri, 16-Jan-87 13:10:48 EST Article-I.D.: SRI-NIC.12271421358.18.KLH Posted: Fri Jan 16 13:10:48 1987 Date-Received: Sat, 17-Jan-87 01:37:57 EST References: <8701152158.a012525@Huey.UDEL.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 3 Approved: tcp-ip@sri-nic.arpa No, no, please keep the discussion going here. It's so rare for anything really interesting to come along... thanks! ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701161826.AA07043%40mitre.ARPA] <1987011609101400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mckee@MITRE.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Analyzing Acknowledgement Strategies Message-ID: <8701161826.AA07043@mitre.ARPA> Date: Fri, 16-Jan-87 14:10:14 EST Article-I.D.: mitre.8701161826.AA07043 Posted: Fri Jan 16 14:10:14 1987 Date-Received: Sat, 17-Jan-87 01:37:01 EST References: <8701151850.AA18157@lbl-csam.arpa> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Washington, D.C. Lines: 26 Approved: tcp-ip@sri-nic.arpa >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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701161950.AA16023%40ucbvax.Berkeley.EDU] <1987011609365300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LYNCH@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Analyzing Acknowledgement Strategies Message-ID: <8701161950.AA16023@ucbvax.Berkeley.EDU> Date: Fri, 16-Jan-87 14:36:53 EST Article-I.D.: ucbvax.8701161950.AA16023 Posted: Fri Jan 16 14:36:53 1987 Date-Received: Sat, 17-Jan-87 01:39:25 EST References: <8701152029.aa10103@SEM.BRL.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987011609365301> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Fri 16 Jan 87 11:40:58-PST Date: 16 Jan 1987 14:36:53 EST Subject: Re: Analyzing Acknowledgement Strategies From: Dan Lynch To: Mike Muuss cc: Van Jacobson , tcp-ip@SRI-NIC.ARPA, LYNCH@A.ISI.EDU In-Reply-To: <8701152029.aa10103@SEM.BRL.ARPA> 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701162017.AA16555%40ucbvax.Berkeley.EDU] <1987011610231700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: craig@LOKI.BBN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Gateway Monitoring Message-ID: <8701162017.AA16555@ucbvax.Berkeley.EDU> Date: Fri, 16-Jan-87 15:23:17 EST Article-I.D.: ucbvax.8701162017.AA16555 Posted: Fri Jan 16 15:23:17 1987 Date-Received: Sat, 17-Jan-87 01:41:43 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 20 Approved: tcp-ip@sri-nic.arpa 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) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [MS.V3.20.ms6b.80020b28.liberty.sun.943.0%40andrew.cmu.edu] <1987011611554700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ms6b#@ANDREW.CMU.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: secure replacements for password Message-ID: Date: Fri, 16-Jan-87 16:55:47 EST Article-I.D.: andrew.MS.V3.20.ms6b.80020b28.liberty.sun.943.0 Posted: Fri Jan 16 16:55:47 1987 Date-Received: Sat, 17-Jan-87 06:41:33 EST References: <8701161623.AA13948@gswd-vms.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987011705310000> Received: from SH.CS.NET by SRI-NIC.ARPA with TCP; Sat 17 Jan 87 13:38:39-PST Received: from sri-nic.arpa by SH.CS.NET id aa17053; 17 Jan 87 16:31 EST Date: 17 Jan 1987 13:31-PST Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: Gateway Monitoring From: STJOHNS@SRI-NIC.ARPA To: craig@loki.bbn.com Cc: tcp-ip%sri-nic.arpa@SH.CS.NET Message-ID: <[SRI-NIC.ARPA]17-Jan-87 13:31:29.STJOHNS> In-Reply-To: The message of Fri, 16 Jan 87 14:58:59 -0500 from Craig Partridge 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701171647.AA01115%40flash.bellcore.com] <1987011706474900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@FLASH.BELLCORE.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: secure replacements for password Message-ID: <8701171647.AA01115@flash.bellcore.com> Date: Sat, 17-Jan-87 11:47:49 EST Article-I.D.: flash.8701171647.AA01115 Posted: Sat Jan 17 11:47:49 1987 Date-Received: Sat, 17-Jan-87 18:53:19 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 28 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701171844.AA02374%40bunny.UUCP] <1987011708442300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mrs2@seismo.CSS.GOV@bunny.UUCP (Mark Scherfling) Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8701171844.AA02374@bunny.UUCP> Date: Sat, 17-Jan-87 13:44:23 EST Article-I.D.: bunny.8701171844.AA02374 Posted: Sat Jan 17 13:44:23 1987 Date-Received: Sun, 18-Jan-87 06:36:32 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701171908.AA11125%40lbl-csam.arpa] <1987011709085700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: van@LBL-CSAM.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Analyzing Acknowledgement Strategies, continued Message-ID: <8701171908.AA11125@lbl-csam.arpa> Date: Sat, 17-Jan-87 14:08:57 EST Article-I.D.: lbl-csam.8701171908.AA11125 Posted: Sat Jan 17 14:08:57 1987 Date-Received: Sat, 17-Jan-87 23:48:32 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 187 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701171503.a003309%40Huey.UDEL.EDU] <1987011710035600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@LOUIE.UDEL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Analyzing Acknowledgement Strategies, continued Message-ID: <8701171503.a003309@Huey.UDEL.EDU> Date: Sat, 17-Jan-87 15:03:56 EST Article-I.D.: Huey.8701171503.a003309 Posted: Sat Jan 17 15:03:56 1987 Date-Received: Sun, 18-Jan-87 00:23:46 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 29 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987011714194300> Received: from SH.CS.NET by SRI-NIC.ARPA with TCP; Sat 17 Jan 87 16:29:19-PST Received: from vax.darpa.mil by SH.CS.NET id aa17762; 17 Jan 87 19:20 EST Posted-Date: Sat 17 Jan 87 19:19:43-EST Received: by vax.darpa.mil (5.54/5.51) id AA07813; Sat, 17 Jan 87 19:19:46 EST Date: Sat 17 Jan 87 19:19:43-EST From: "Dennis G. Perry" Subject: Re: Gateway Monitoring To: craig@loki.bbn.com Cc: tcp-ip%sri-nic.arpa@SH.CS.NET, perry@vax.darpa.mil Message-Id: In-Reply-To: Message from "Craig Partridge " of Fri, 16 Jan 87 14:58:59 -0500 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987011802032900> Received: from glacier.stanford.edu ([36.22.0.115]) by SRI-NIC.ARPA with TCP; Sun 18 Jan 87 13:21:49-PST Received: by glacier.stanford.edu; Sun, 18 Jan 87 10:03:29 PST Date: Sun, 18 Jan 87 10:03:29 PST From: John B. Nagle Subject: Shock load after retransmission acknowlegement To: TCP-IP@nic.sri.com 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701181501.AA11439%40csv.rpi.edu] <1987011805011100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: schoff@CSV.RPI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Gateway Monitoring Message-ID: <8701181501.AA11439@csv.rpi.edu> Date: Sun, 18-Jan-87 10:01:11 EST Article-I.D.: csv.8701181501.AA11439 Posted: Sun Jan 18 10:01:11 1987 Date-Received: Sun, 18-Jan-87 12:38:24 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701182137.AA28185%40ucbvax.Berkeley.EDU] <1987011808032900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jbn@GLACIER.STANFORD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Shock load after retransmission acknowlegement Message-ID: <8701182137.AA28185@ucbvax.Berkeley.EDU> Date: Sun, 18-Jan-87 13:03:29 EST Article-I.D.: ucbvax.8701182137.AA28185 Posted: Sun Jan 18 13:03:29 1987 Date-Received: Sun, 18-Jan-87 18:36:17 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 30 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701182057.AA00808%40oddjob.UChicago.EDU] <1987011810575100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: matt@oddjob.uchicago.edu.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: secure replacements for passwords Message-ID: <8701182057.AA00808@oddjob.UChicago.EDU> Date: Sun, 18-Jan-87 15:57:51 EST Article-I.D.: oddjob.8701182057.AA00808 Posted: Sun Jan 18 15:57:51 1987 Date-Received: Sun, 18-Jan-87 18:35:37 EST References: <870113143008.200363@MIT-MULTICS.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: matt@oddjob.uchicago.edu (Matt Crawford) Organization: Just Things `n' Stuff, Et Cetera, Ltd. Lines: 9 Approved: tcp-ip@sri-nic.arpa 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701182351.AA29559%40ucbvax.Berkeley.EDU] <1987011813521900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mills@HUEY.UDEL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Transatlantic pings Message-ID: <8701182351.AA29559@ucbvax.Berkeley.EDU> Date: Sun, 18-Jan-87 18:52:19 EST Article-I.D.: ucbvax.8701182351.AA29559 Posted: Sun Jan 18 18:52:19 1987 Date-Received: Sun, 18-Jan-87 22:37:12 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 29 Approved: tcp-ip@sri-nic.arpa 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987011823265100> Received: from UDEL2.UDEL.EDU ([192.5.39.88]) by SRI-NIC.ARPA with TCP; Sun 18 Jan 87 15:42:22-PST Date: 18-Jan-87 23:26:51-UT From: mills@huey.udel.edu Subject: Transatlantic pings To: tcp-ip@sri-nic.arpa 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701190435.a019742%40Huey.UDEL.EDU] <1987011823355600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@LOUIE.UDEL.EDU Newsgroups: mod.protocols.tcp-ip Subject: Re: Gateway Monitoring Message-ID: <8701190435.a019742@Huey.UDEL.EDU> Date: Mon, 19-Jan-87 04:35:56 EST Article-I.D.: Huey.8701190435.a019742 Posted: Mon Jan 19 04:35:56 1987 Date-Received: Mon, 19-Jan-87 19:36:07 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987011902010000> Received: from SH.CS.NET by SRI-NIC.ARPA with TCP; Mon 19 Jan 87 10:19:18-PST Received: from sri-nic.arpa by SH.CS.NET id aa01665; 19 Jan 87 13:02 EST Date: 19 Jan 1987 10:01-PST Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: Gateway Monitoring From: STJOHNS@SRI-NIC.ARPA To: Mills@louie.udel.edu Cc: craig@loki.bbn.com, tcp-ip%sri-nic.arpa@SH.CS.NET Message-ID: <[SRI-NIC.ARPA]19-Jan-87 10:01:24.STJOHNS> In-Reply-To: <8701190435.a019742@Huey.UDEL.EDU> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701191118.a022642%40Huey.UDEL.EDU] <1987011906183200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@LOUIE.UDEL.EDU Newsgroups: mod.protocols.tcp-ip Subject: Re: Analyzing Acknowledgement Strategies Message-ID: <8701191118.a022642@Huey.UDEL.EDU> Date: Mon, 19-Jan-87 11:18:32 EST Article-I.D.: Huey.8701191118.a022642 Posted: Mon Jan 19 11:18:32 1987 Date-Received: Tue, 20-Jan-87 00:22:44 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987011907460200> Received: from SH.CS.NET by SRI-NIC.ARPA with TCP; Mon 19 Jan 87 10:06:27-PST Received: from vax.darpa.mil by SH.CS.NET id aa01555; 19 Jan 87 12:53 EST Posted-Date: Mon 19 Jan 87 12:46:02-EST Received: by vax.darpa.mil (5.54/5.51) id AA05707; Mon, 19 Jan 87 12:46:05 EST Date: Mon 19 Jan 87 12:46:02-EST From: "Dennis G. Perry" Subject: Re: Re: Gateway Monitoring 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 Message-Id: In-Reply-To: Message from "Mills@udel.edu" of Mon, 19 Jan 87 4:35:56 EST 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701191933.AA00226%40apolling.imagen.uucp] <1987011909335500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: geof@decwrl.DEC.COM@imagen.UUCP (Geof Cooper) Newsgroups: mod.protocols.tcp-ip Subject: Re: Analyzing Acknowledgement Strategies, continued Message-ID: <8701191933.AA00226@apolling.imagen.uucp> Date: Mon, 19-Jan-87 14:33:55 EST Article-I.D.: apolling.8701191933.AA00226 Posted: Mon Jan 19 14:33:55 1987 Date-Received: Tue, 20-Jan-87 04:59:36 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: imagen!geof@decwrl.DEC.COM Organization: The ARPA Internet Lines: 96 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701192033.AA14249%40ucbvax.Berkeley.EDU] <1987011909424700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brescia@CCV.BBN.COM (Mike Brescia) Newsgroups: mod.protocols.tcp-ip Subject: Re: Gateway Monitoring Message-ID: <8701192033.AA14249@ucbvax.Berkeley.EDU> Date: Mon, 19-Jan-87 14:42:47 EST Article-I.D.: ucbvax.8701192033.AA14249 Posted: Mon Jan 19 14:42:47 1987 Date-Received: Tue, 20-Jan-87 04:59:10 EST References: <8701181501.AA11439@csv.rpi.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987011909424701> Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Mon 19 Jan 87 12:17:26-PST To: Martin Schoffstall cc: STJOHNS@sri-nic.ARPA, craig@loki.bbn.com, brescia@ccv.bbn.com cc: tcp-ip@sri-nic.ARPA Subject: Re: Gateway Monitoring In-reply-to: Your message of Sun, 18 Jan 87 10:01:11 EST. <8701181501.AA11439@csv.rpi.edu> Date: 19 Jan 87 14:42:47 EST (Mon) From: Mike Brescia 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701191534.a025325%40Huey.UDEL.EDU] <1987011910343400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@LOUIE.UDEL.EDU Newsgroups: mod.protocols.tcp-ip Subject: Re: Re: Gateway Monitoring Message-ID: <8701191534.a025325@Huey.UDEL.EDU> Date: Mon, 19-Jan-87 15:34:34 EST Article-I.D.: Huey.8701191534.a025325 Posted: Mon Jan 19 15:34:34 1987 Date-Received: Tue, 20-Jan-87 05:44:40 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701191619.a025449%40Huey.UDEL.EDU] <1987011911195400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@LOUIE.UDEL.EDU Newsgroups: mod.protocols.tcp-ip Subject: Re: Gateway Monitoring Message-ID: <8701191619.a025449@Huey.UDEL.EDU> Date: Mon, 19-Jan-87 16:19:54 EST Article-I.D.: Huey.8701191619.a025449 Posted: Mon Jan 19 16:19:54 1987 Date-Received: Tue, 20-Jan-87 05:49:32 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987011911594700> Received-Date: Mon, 19 Jan 87 17:06:44 EST Received: from SH.CS.NET by vax.darpa.mil (5.54/5.51) id AA06111; Mon, 19 Jan 87 17:06:44 EST Received: from vax.darpa.mil by SH.CS.NET id aa03862; 19 Jan 87 17:00 EST Posted-Date: Mon 19 Jan 87 16:59:47-EST Received: by vax.darpa.mil (5.54/5.51) id AA06082; Mon, 19 Jan 87 16:59:52 EST Date: Mon 19 Jan 87 16:59:47-EST From: "Dennis G. Perry" Subject: Re: Gateway Monitoring Etc. To: craig@loki.bbn.com Cc: perry%vax.darpa.mil@SH.CS.NET, mills@louie.udel.edu, perry@vax.darpa.mil Message-Id: In-Reply-To: Message from "Craig Partridge " of Mon, 19 Jan 87 13:42:47 -0500 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701200607.AA14063%40topaz.rutgers.edu] <1987011920074000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: mod.protocols.tcp-ip Subject: how to make use of redundant routes Message-ID: <8701200607.AA14063@topaz.rutgers.edu> Date: Tue, 20-Jan-87 01:07:40 EST Article-I.D.: topaz.8701200607.AA14063 Posted: Tue Jan 20 01:07:40 1987 Date-Received: Tue, 20-Jan-87 22:25:35 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 59 Approved: tcp-ip@sri-nic.arpa 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.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012001220000> Mail-From: STJOHNS created at 20-Jan-87 09:23:24 Date: 20 Jan 1987 09:22-PST Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: Gateway Monitoring. From: STJOHNS@SRI-NIC.ARPA To: PERRY@VAX.DARPA.MIL Cc: hwb@MCR.UMICH.EDU, tcp-ip@SRI-NIC.ARPA Cc: craig@LOKI.BBN.COM Message-ID: <[SRI-NIC.ARPA]20-Jan-87 09:22:14.STJOHNS> In-Reply-To: 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012002350000> Received: from SH.CS.NET by SRI-NIC.ARPA with TCP; Tue 20 Jan 87 07:49:18-PST Received: from a.isi.edu by SH.CS.NET id aa09800; 20 Jan 87 10:28 EST Date: 20 Jan 1987 07:35-EST Sender: CERF@a.isi.edu Subject: Re: Gateway Monitoring From: CERF@a.isi.edu To: STJOHNS@SRI-NIC.ARPA Cc: craig@loki.bbn.com, tcp-ip%sri-nic.arpa@SH.CS.NET Message-ID: <[A.ISI.EDU]20-Jan-87 07:35:27.CERF> In-Reply-To: <[SRI-NIC.ARPA]17-Jan-87 13:31:29.STJOHNS> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701201410.AA00819%40ucbvax.Berkeley.EDU] <1987012003300000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: NS-DDN@DDN2.UUCP Newsgroups: mod.protocols.tcp-ip Subject: FTP Restart Message-ID: <8701201410.AA00819@ucbvax.Berkeley.EDU> Date: Tue, 20-Jan-87 08:30:00 EST Article-I.D.: ucbvax.8701201410.AA00819 Posted: Tue Jan 20 08:30:00 1987 Date-Received: Wed, 21-Jan-87 00:12:28 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 72 Approved: tcp-ip@sri-nic.arpa 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" Host A:User-PI <== Host B:Server-PI "227 10,1,0,1,16,5" Host A:User-PI ==> Host C:Server-PI "PORT 10,1,0,1,16,5" Host A:User-PI <== Host C:Server-PI "220 Okay" Host A:User-PI ==> Host B:Server-PI "MODE B" Host A:User-PI ==> Host C:Server-PI "MODE B" Host A:User-PI <== Host B:Server-PI "220 Okay" Host A:User-PI <== Host C:Server-PI "220 Okay" Host A:User-PI ==> Host B:Server-PI "STOR bigfile" Host A:User-PI ==> Host C:Server-PI "RETR bigfile" Host C:Server-DTP ==> Host B:User-DTP [Establish session] Host A:User-PI <== Host B:Server-PI "125 Transfer started" Host A:User-PI <== Host C:Server-PI "125 Transfer started" 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" 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" 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" 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" Host A:User-PI ==> Host C:Server-PI "REST MINE0002" Host A:User-PI <== Host B:Server-PI "350 Ready to restart" Host A:User-PI <== Host C:Server-PI "350 Ready to restart" Host A:User-PI ==> Host B:Server-PI "STOR bigfile" Host A:User-PI ==> Host C:Server-PI "RETR bigfile" Host C:Server-DTP ==> Host B:User-DTP [Establish session] Host A:User-PI <== Host B:Server-PI "125 Transfer started" Host A:User-PI <== Host C:Server-PI "125 Transfer started" 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012003300001> Received: from ddn2 by SRI-NIC.ARPA with TCP; Tue 20 Jan 87 05:55:44-PST Date: 20 Jan 87 08:30 EST From: NS-DDN @ DDN2 Subject: FTP Restart To: tcp-ip @ SRI-NIC.ARPA 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" Host A:User-PI <== Host B:Server-PI "227 10,1,0,1,16,5" Host A:User-PI ==> Host C:Server-PI "PORT 10,1,0,1,16,5" Host A:User-PI <== Host C:Server-PI "220 Okay" Host A:User-PI ==> Host B:Server-PI "MODE B" Host A:User-PI ==> Host C:Server-PI "MODE B" Host A:User-PI <== Host B:Server-PI "220 Okay" Host A:User-PI <== Host C:Server-PI "220 Okay" Host A:User-PI ==> Host B:Server-PI "STOR bigfile" Host A:User-PI ==> Host C:Server-PI "RETR bigfile" Host C:Server-DTP ==> Host B:User-DTP [Establish session] Host A:User-PI <== Host B:Server-PI "125 Transfer started" Host A:User-PI <== Host C:Server-PI "125 Transfer started" 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" 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" 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" 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" Host A:User-PI ==> Host C:Server-PI "REST MINE0002" Host A:User-PI <== Host B:Server-PI "350 Ready to restart" Host A:User-PI <== Host C:Server-PI "350 Ready to restart" Host A:User-PI ==> Host B:Server-PI "STOR bigfile" Host A:User-PI ==> Host C:Server-PI "RETR bigfile" Host C:Server-DTP ==> Host B:User-DTP [Establish session] Host A:User-PI <== Host B:Server-PI "125 Transfer started" Host A:User-PI <== Host C:Server-PI "125 Transfer started" 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701201440.AA01153%40ucbvax.Berkeley.EDU] <1987012004100000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: NS-DDN@DDN2.UUCP Newsgroups: mod.protocols.tcp-ip Subject: FTP Enhancements Message-ID: <8701201440.AA01153@ucbvax.Berkeley.EDU> Date: Tue, 20-Jan-87 09:10:00 EST Article-I.D.: ucbvax.8701201440.AA01153 Posted: Tue Jan 20 09:10:00 1987 Date-Received: Wed, 21-Jan-87 00:14:37 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012004100001> Received: from ddn2 by SRI-NIC.ARPA with TCP; Tue 20 Jan 87 06:33:52-PST Date: 20 Jan 87 09:10 EST From: NS-DDN @ DDN2 Subject: FTP Enhancements To: tcp-ip @ SRI-NIC 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701201427.AA28623%40mitre.ARPA] <1987012004565800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mckee@MITRE.ARPA (H. Craig McKee) Newsgroups: mod.protocols.tcp-ip Subject: Re: Analyzing Acknowledgement Strategies Message-ID: <8701201427.AA28623@mitre.ARPA> Date: Tue, 20-Jan-87 09:56:58 EST Article-I.D.: mitre.8701201427.AA28623 Posted: Tue Jan 20 09:56:58 1987 Date-Received: Wed, 21-Jan-87 00:15:39 EST References: <8701151850.AA18157@lbl-csam.arpa> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Washington, D.C. Lines: 28 Approved: tcp-ip@sri-nic.arpa >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 -------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012005150000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Tue 20 Jan 87 07:16:28-PST Date: 20 Jan 1987 10:15-EST Sender: CERF@A.ISI.EDU Subject: Re: FTP Enhancements From: CERF@A.ISI.EDU To: NS-DDN@DDN2.ARPA Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]20-Jan-87 10:15:44.CERF> In-Reply-To: The message of 20 Jan 87 09:10 EST from NS-DDN @ DDN2 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701201600.AA03470%40MCR.UMICH.EDU] <1987012006004600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hwb@MCR.UMICH.EDU (Hans-Werner Braun) Newsgroups: mod.protocols.tcp-ip Subject: Re: Gateway Monitoring. Message-ID: <8701201600.AA03470@MCR.UMICH.EDU> Date: Tue, 20-Jan-87 11:00:46 EST Article-I.D.: MCR.8701201600.AA03470 Posted: Tue Jan 20 11:00:46 1987 Date-Received: Wed, 21-Jan-87 00:38:18 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701201645.AA13582%40phun.riacs.edu] <1987012007120400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: leiner@ICARUS.RIACS.EDU Newsgroups: mod.protocols.tcp-ip Subject: Re: Gateway Monitoring Message-ID: <8701201645.AA13582@phun.riacs.edu> Date: Tue, 20-Jan-87 12:12:04 EST Article-I.D.: phun.8701201645.AA13582 Posted: Tue Jan 20 12:12:04 1987 Date-Received: Wed, 21-Jan-87 00:40:22 EST References: <8701172058.AA03288@icarus.riacs.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 41 Approved: tcp-ip@sri-nic.arpa 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 > 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) ---------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012007140200> Received: from vax.darpa.mil by SRI-NIC.ARPA with TCP; Tue 20 Jan 87 09:15:17-PST Posted-Date: Tue 20 Jan 87 12:14:02-EST Received: by vax.darpa.mil (5.54/5.51) id AA01721; Tue, 20 Jan 87 12:14:08 EST Date: Tue 20 Jan 87 12:14:02-EST From: Dennis G. Perry Subject: Re: Gateway Monitoring. 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 Message-Id: In-Reply-To: Message from "Hans-Werner Braun " of Tue, 20 Jan 87 11:00:46 EST 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701201813.AA28168%40topaz.rutgers.edu] <1987012008131400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: mod.protocols.tcp-ip Subject: Re: Gateway Monitoring Message-ID: <8701201813.AA28168@topaz.rutgers.edu> Date: Tue, 20-Jan-87 13:13:14 EST Article-I.D.: topaz.8701201813.AA28168 Posted: Tue Jan 20 13:13:14 1987 Date-Received: Wed, 21-Jan-87 01:56:02 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa 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.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870120145836.3.DCP%40KOYAANISQATSI.S4CC.Symbolics.COM] <1987012009580000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) Newsgroups: mod.protocols.tcp-ip Subject: how to make use of redundant routes Message-ID: <870120145836.3.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Tue, 20-Jan-87 14:58:00 EST Article-I.D.: KOYAANIS.870120145836.3.DCP Posted: Tue Jan 20 14:58:00 1987 Date-Received: Wed, 21-Jan-87 01:59:05 EST References: <8701200607.AA14063@topaz.rutgers.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 31 Approved: tcp-ip@sri-nic.arpa 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870120175612.5.DCP%40KOYAANISQATSI.S4CC.Symbolics.COM] <1987012012560000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) Newsgroups: mod.protocols.tcp-ip Subject: FTP Enhancements Message-ID: <870120175612.5.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Tue, 20-Jan-87 17:56:00 EST Article-I.D.: KOYAANIS.870120175612.5.DCP Posted: Tue Jan 20 17:56:00 1987 Date-Received: Wed, 21-Jan-87 03:50:05 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa 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? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012017265000> Received: from vax.darpa.mil by SRI-NIC.ARPA with TCP; Tue 20 Jan 87 19:27:40-PST Posted-Date: Tue 20 Jan 87 22:26:50-EST Received: by vax.darpa.mil (5.54/5.51) id AA03065; Tue, 20 Jan 87 22:26:53 EST Date: Tue 20 Jan 87 22:26:50-EST From: Dennis G. Perry Subject: Re: FTP Enhancements To: CERF@a.isi.edu Cc: NS-DDN@ddn2.arpa, tcp-ip@sri-nic.arpa, perry@vax.darpa.mil Message-Id: In-Reply-To: Message from "CERF@A.ISI.EDU" of 20 Jan 1987 10:15-EST 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012017392900> Received: from SH.CS.NET by SRI-NIC.ARPA with TCP; Tue 20 Jan 87 19:48:46-PST Received: from vax.darpa.mil by SH.CS.NET id aa15228; 20 Jan 87 22:42 EST Posted-Date: Tue 20 Jan 87 22:39:29-EST Received: by vax.darpa.mil (5.54/5.51) id AA03099; Tue, 20 Jan 87 22:39:33 EST Date: Tue 20 Jan 87 22:39:29-EST From: "Dennis G. Perry" Subject: Re: Gateway Monitoring 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 Message-Id: In-Reply-To: Message from "CERF@a.isi.edu" of 20 Jan 1987 07:35-EST 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12272596910.21.JNC%40XX.LCS.MIT.EDU] <1987012019481800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JNC@XX.LCS.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Looking for DDN/X.25 to TCP/IP router Message-ID: <12272596910.21.JNC@XX.LCS.MIT.EDU> Date: Wed, 21-Jan-87 00:48:18 EST Article-I.D.: XX.12272596910.21.JNC Posted: Wed Jan 21 00:48:18 1987 Date-Received: Wed, 21-Jan-87 20:35:01 EST References: <168@ames.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12272599084.21.JNC%40XX.LCS.MIT.EDU] <1987012020001500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JNC@XX.LCS.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: how to make use of redundant routes Message-ID: <12272599084.21.JNC@XX.LCS.MIT.EDU> Date: Wed, 21-Jan-87 01:00:15 EST Article-I.D.: XX.12272599084.21.JNC Posted: Wed Jan 21 01:00:15 1987 Date-Received: Wed, 21-Jan-87 18:41:24 EST References: <8701200607.AA14063@topaz.rutgers.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701210752.AA00659%40topaz.rutgers.edu] <1987012021523300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: how to make use of redundant routes Message-ID: <8701210752.AA00659@topaz.rutgers.edu> Date: Wed, 21-Jan-87 02:52:33 EST Article-I.D.: topaz.8701210752.AA00659 Posted: Wed Jan 21 02:52:33 1987 Date-Received: Wed, 21-Jan-87 19:36:42 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 77 Approved: tcp-ip@sri-nic.arpa 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012102202800> Received: from pescadero.stanford.edu by SRI-NIC.ARPA with TCP; Wed 21 Jan 87 10:24:32-PST Received: by pescadero.stanford.edu with Sendmail; Wed, 21 Jan 87 10:20:28 pst Date: Wed, 21 Jan 87 10:20:28 pst From: David Cheriton Subject: Gateway monitoring protocols To: tcp-ip@sri-nic.ARPA 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701211527.AA06816%40mitre-gateway.arpa] <1987012105273600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gross@MITRE-GATEWAY.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Gateway Monitoring. Message-ID: <8701211527.AA06816@mitre-gateway.arpa> Date: Wed, 21-Jan-87 10:27:36 EST Article-I.D.: mitre-ga.8701211527.AA06816 Posted: Wed Jan 21 10:27:36 1987 Date-Received: Wed, 21-Jan-87 20:27:28 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012108180000> Received: from SH.CS.NET by SRI-NIC.ARPA with TCP; Wed 21 Jan 87 23:03:25-PST Received: from sri-nic.arpa by SH.CS.NET id aa23843; 21 Jan 87 19:20 EST Date: 21 Jan 1987 16:18-PST Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: Gateway Monitoring From: STJOHNS@SRI-NIC.ARPA To: PERRY@vax.darpa.mil Cc: CERF@a.isi.edu, craig@loki.bbn.com Cc: tcp-ip%sri-nic.arpa@SH.CS.NET Message-ID: <[SRI-NIC.ARPA]21-Jan-87 16:18:18.STJOHNS> In-Reply-To: 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701211842.AA28609%40ucbvax.Berkeley.EDU] <1987012108202800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cheriton@PESCADERO.STANFORD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Gateway monitoring protocols Message-ID: <8701211842.AA28609@ucbvax.Berkeley.EDU> Date: Wed, 21-Jan-87 13:20:28 EST Article-I.D.: ucbvax.8701211842.AA28609 Posted: Wed Jan 21 13:20:28 1987 Date-Received: Wed, 21-Jan-87 21:35:57 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701211852.AA01256%40acetes.dec.com] <1987012108520000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mogul@DECWRL.DEC.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Packet filter (was Re: Gateway Monitoring) Message-ID: <8701211852.AA01256@acetes.dec.com> Date: Wed, 21-Jan-87 13:52:00 EST Article-I.D.: acetes.8701211852.AA01256 Posted: Wed Jan 21 13:52:00 1987 Date-Received: Wed, 21-Jan-87 21:35:38 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 36 Approved: tcp-ip@sri-nic.arpa 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701212002.AA23258%40devvax.TN.CORNELL.EDU] <1987012110024600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: swb@DEVVAX.TN.CORNELL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Gateway Monitoring Message-ID: <8701212002.AA23258@devvax.TN.CORNELL.EDU> Date: Wed, 21-Jan-87 15:02:46 EST Article-I.D.: devvax.8701212002.AA23258 Posted: Wed Jan 21 15:02:46 1987 Date-Received: Wed, 21-Jan-87 21:37:54 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 3 Approved: tcp-ip@sri-nic.arpa About security in monitoring: yes, it was mentioned as a requirement in one of the first messages among the "Partridge" contingent. Scott ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701212006.AA11015%40mitre-gateway.arpa] <1987012110061300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gross@MITRE-GATEWAY.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Looking for DDN/X.25 to TCP/IP router Message-ID: <8701212006.AA11015@mitre-gateway.arpa> Date: Wed, 21-Jan-87 15:06:13 EST Article-I.D.: mitre-ga.8701212006.AA11015 Posted: Wed Jan 21 15:06:13 1987 Date-Received: Wed, 21-Jan-87 21:37:35 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 25 Approved: tcp-ip@sri-nic.arpa > 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701212106.AA18267%40ORNL-MSR.ARPA] <1987012111062100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dunigan@ORNL-MSR.ARPA (Tom Dunigan 576-2522) Newsgroups: mod.protocols.tcp-ip Subject: seeking source for Ether packet types and vendor address codes Message-ID: <8701212106.AA18267@ORNL-MSR.ARPA> Date: Wed, 21-Jan-87 16:06:21 EST Article-I.D.: ORNL-MSR.8701212106.AA18267 Posted: Wed Jan 21 16:06:21 1987 Date-Received: Thu, 22-Jan-87 02:03:31 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12272778635.31.GROSSMAN%40Sierra.Stanford.EDU] <1987012112263300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: GROSSMAN@Sierra.Stanford.EDU (Stu Grossman) Newsgroups: mod.protocols.tcp-ip Subject: Re: Analyzing Acknowledgement Strategies, continued Message-ID: <12272778635.31.GROSSMAN@Sierra.Stanford.EDU> Date: Wed, 21-Jan-87 17:26:33 EST Article-I.D.: Sierra.12272778635.31.GROSSMAN Posted: Wed Jan 21 17:26:33 1987 Date-Received: Thu, 22-Jan-87 02:07:47 EST References: <8701191933.AA00226@apolling.imagen.uucp> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 29 Approved: tcp-ip@sri-nic.arpa 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701212056.AA18385%40mitre.ARPA] <1987012113135700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mckee@MITRE.ARPA (H. Craig McKee) Newsgroups: mod.protocols.tcp-ip Subject: Re: Analyzing Acknowledgement Strategies, continued Message-ID: <8701212056.AA18385@mitre.ARPA> Date: Wed, 21-Jan-87 18:13:57 EST Article-I.D.: mitre.8701212056.AA18385 Posted: Wed Jan 21 18:13:57 1987 Date-Received: Thu, 22-Jan-87 02:05:18 EST References: <8701171908.AA11125@lbl-csam.arpa> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Washington, D.C. Lines: 6 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012114460300> Received: from vax.darpa.mil by SRI-NIC.ARPA with TCP; Wed 21 Jan 87 16:47:35-PST Posted-Date: Wed 21 Jan 87 19:46:03-EST Received: by vax.darpa.mil (5.54/5.51) id AA07526; Wed, 21 Jan 87 19:46:08 EST Date: Wed 21 Jan 87 19:46:03-EST From: Dennis G. Perry Subject: Re: Gateway Monitoring. 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 Message-Id: In-Reply-To: Message from "gross@mitre-gateway.arpa (Phil Gross)" of Wed, 21 Jan 87 10:27:36 EST 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701220629.AA23169%40orion.arpa] <1987012120290700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: medin@orion.arpa (Milo S. Medin, NASA ARC Code ED) Newsgroups: mod.protocols.tcp-ip Subject: Re: Looking for DDN/X.25 to TCP/IP router Message-ID: <8701220629.AA23169@orion.arpa> Date: Thu, 22-Jan-87 01:29:07 EST Article-I.D.: orion.8701220629.AA23169 Posted: Thu Jan 22 01:29:07 1987 Date-Received: Thu, 22-Jan-87 06:34:49 EST References: <8701212006.AA11015@mitre-gateway.arpa> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 37 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012201342500> Return-Path: Received: from vax.darpa.mil by SRI-NIC.ARPA with TCP; Thu 22 Jan 87 03:35:47-PST Posted-Date: Thu 22 Jan 87 06:34:25-EST Received: by vax.darpa.mil (5.54/5.51) id AA03323; Thu, 22 Jan 87 06:34:29 EST Date: Thu 22 Jan 87 06:34:25-EST From: Dennis G. Perry Subject: Re: Gateway monitoring protocols To: cheriton@pescadero.stanford.edu Cc: tcp-ip@sri-nic.arpa, perry@vax.darpa.mil Message-Id: In-Reply-To: Message from "David Cheriton " of Wed, 21 Jan 87 10:20:28 pst 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012205163200> Received: from SH.CS.NET by SRI-NIC.ARPA with TCP; Thu 22 Jan 87 10:45:42-PST Received: from loki.bbn.com by SH.CS.NET id aa00003; 22 Jan 87 13:42 EST To: tcp-ip%sri-nic.arpa@SH.CS.NET Subject: Monitoring Revisited Date: Thu, 22 Jan 87 13:36:32 -0500 From: Craig Partridge 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012205360000> Mail-From: STJOHNS created at 22-Jan-87 13:38:33 Date: 22 Jan 1987 13:36-PST Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: Gateway monitoring protocols From: STJOHNS@SRI-NIC.ARPA To: cheriton@PESCADERO.STANFORD.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA]22-Jan-87 13:36:56.STJOHNS> In-Reply-To: The message of Wed, 21 Jan 87 10:20:28 pst from David Cheriton 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701221542.AA17952%40mitre-gateway.arpa] <1987012205424300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gross@MITRE-GATEWAY.ARPA (Phil Gross) Newsgroups: mod.protocols.tcp-ip Subject: Re: Gateway monitoring protocols Message-ID: <8701221542.AA17952@mitre-gateway.arpa> Date: Thu, 22-Jan-87 10:42:43 EST Article-I.D.: mitre-ga.8701221542.AA17952 Posted: Thu Jan 22 10:42:43 1987 Date-Received: Fri, 23-Jan-87 06:44:56 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701221550.AA14100%40videovax.TEK] <1987012205501200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: stever@videovax.tek.com ("Steven E. Rice") Newsgroups: mod.protocols.tcp-ip Subject: Re: Tektronics TCP/IP for VMS (Second try!) Message-ID: <8701221550.AA14100@videovax.TEK> Date: Thu, 22-Jan-87 10:50:12 EST Article-I.D.: videovax.8701221550.AA14100 Posted: Thu Jan 22 10:50:12 1987 Date-Received: Fri, 23-Jan-87 06:51:27 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701221553.AA14115%40videovax.TEK] <1987012205531400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: stever@videovax.tek.com ("Steven E. Rice") Newsgroups: mod.protocols.tcp-ip Subject: Re: Analyzing Acknowledgement Strategies (Second try!) Message-ID: <8701221553.AA14115@videovax.TEK> Date: Thu, 22-Jan-87 10:53:14 EST Article-I.D.: videovax.8701221553.AA14115 Posted: Thu Jan 22 10:53:14 1987 Date-Received: Fri, 23-Jan-87 22:15:29 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 35 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870122110146.5.DCP%40KOYAANISQATSI.S4CC.Symbolics.COM] <1987012206010000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) Newsgroups: mod.protocols.tcp-ip Subject: seeking source for Ether packet types and vendor address codes Message-ID: <870122110146.5.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Thu, 22-Jan-87 11:01:00 EST Article-I.D.: KOYAANIS.870122110146.5.DCP Posted: Thu Jan 22 11:01:00 1987 Date-Received: Fri, 23-Jan-87 07:28:49 EST References: <8701212106.AA18267@ORNL-MSR.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 24 Approved: tcp-ip@sri-nic.arpa 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701221735.AA02941%40postel.isi.edu] <1987012207355200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Postel@ISI.EDU (Jon Postel) Newsgroups: mod.protocols.tcp-ip Subject: Ethernet Type Codes Message-ID: <8701221735.AA02941@postel.isi.edu> Date: Thu, 22-Jan-87 12:35:52 EST Article-I.D.: postel.8701221735.AA02941 Posted: Thu Jan 22 12:35:52 1987 Date-Received: Fri, 23-Jan-87 06:44:07 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa A partial list is in "Assigned Numbers" (RFC-990), page 38. Information on other numbers to add to the list would be appreciated. --jon. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701222010.AA26868%40monk.proteon.com] <1987012210102200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jas@MONK.PROTEON.COM (John A. Shriver) Newsgroups: mod.protocols.tcp-ip Subject: seeking source for Ether packet types and vendor address codes Message-ID: <8701222010.AA26868@monk.proteon.com> Date: Thu, 22-Jan-87 15:10:22 EST Article-I.D.: monk.8701222010.AA26868 Posted: Thu Jan 22 15:10:22 1987 Date-Received: Fri, 23-Jan-87 06:43:27 EST References: <8701212106.AA18267@ORNL-MSR.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 2 Approved: tcp-ip@sri-nic.arpa 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701222012.AA14111%40usc-rt234.usc.edu] <1987012210120500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: estrin%usc-rt234@USC-CSE.USC.EDU (Deborah L. Estrin) Newsgroups: mod.protocols.tcp-ip Subject: security mechanisms for ip Message-ID: <8701222012.AA14111@usc-rt234.usc.edu> Date: Thu, 22-Jan-87 15:12:05 EST Article-I.D.: usc-rt23.8701222012.AA14111 Posted: Thu Jan 22 15:12:05 1987 Date-Received: Fri, 23-Jan-87 06:45:57 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701221856.AA15820%40ucbvax.Berkeley.EDU] <1987012210534900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: craig@LOKI.BBN.COM (Craig Partridge) Newsgroups: mod.protocols.tcp-ip Subject: Monitoring Revisited Message-ID: <8701221856.AA15820@ucbvax.Berkeley.EDU> Date: Thu, 22-Jan-87 15:53:49 EST Article-I.D.: ucbvax.8701221856.AA15820 Posted: Thu Jan 22 15:53:49 1987 Date-Received: Fri, 23-Jan-87 06:44:44 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701222335.a017242%40Huey.UDEL.EDU] <1987012218354300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@LOUIE.UDEL.EDU Newsgroups: mod.protocols.tcp-ip Subject: Re: Looking for DDN/X.25 to TCP/IP router Message-ID: <8701222335.a017242@Huey.UDEL.EDU> Date: Thu, 22-Jan-87 23:35:43 EST Article-I.D.: Huey.8701222335.a017242 Posted: Thu Jan 22 23:35:43 1987 Date-Received: Fri, 23-Jan-87 21:30:42 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701230248.a019445%40Huey.UDEL.EDU] <1987012221483200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@LOUIE.UDEL.EDU Newsgroups: mod.protocols.tcp-ip Subject: Re: security mechanisms for ip Message-ID: <8701230248.a019445@Huey.UDEL.EDU> Date: Fri, 23-Jan-87 02:48:32 EST Article-I.D.: Huey.8701230248.a019445 Posted: Fri Jan 23 02:48:32 1987 Date-Received: Fri, 23-Jan-87 22:48:29 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701240553.AA25691%40ucbvax.Berkeley.EDU] <1987012301480000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: security mechanisms for ip Message-ID: <8701240553.AA25691@ucbvax.Berkeley.EDU> Date: Fri, 23-Jan-87 06:48:00 EST Article-I.D.: ucbvax.8701240553.AA25691 Posted: Fri Jan 23 06:48:00 1987 Date-Received: Sat, 24-Jan-87 10:46:45 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 27 Approved: tcp-ip@sri-nic.arpa >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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012301480001> Received: from RELAY.CS.NET by SRI-NIC.ARPA with TCP; Fri 23 Jan 87 21:47:55-PST Received: from northeastern.edu by csnet-relay.csnet id af04332; 24 Jan 87 0:34 EST Date: Fri, 23 Jan 87 06:48 EST From: "I am only an egg." To: tcp-ip@SRI-NIC.ARPA Subject: security mechanisms for ip X-VMS-To: TCP-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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012301530000> Mail-From: STJOHNS created at 23-Jan-87 09:54:28 Date: 23 Jan 1987 09:53-PST Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: security mechanisms for ip From: STJOHNS@SRI-NIC.ARPA To: estrin%usc-rt234@USC-CSE.USC.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA]23-Jan-87 09:53:15.STJOHNS> In-Reply-To: <8701222012.AA14111@usc-rt234.usc.edu> Send it to me, I'll process it and provide it as a flat text file at the NIC. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701231723.AA12881%40ucbvax.Berkeley.EDU] <1987012307160000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: allen@esdvax.UUCP ("Maj. William Allen") Newsgroups: mod.protocols.tcp-ip Subject: request to be added to list Message-ID: <8701231723.AA12881@ucbvax.Berkeley.EDU> Date: Fri, 23-Jan-87 12:16:00 EST Article-I.D.: ucbvax.8701231723.AA12881 Posted: Fri Jan 23 12:16:00 1987 Date-Received: Sat, 24-Jan-87 00:42:16 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "Maj. William Allen" Organization: The ARPA Internet Lines: 21 Approved: tcp-ip@sri-nic.arpa 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 ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012307160001> Received: from esdvax by SRI-NIC.ARPA with TCP; Fri 23 Jan 87 09:17:28-PST Date: 23 Jan 87 12:16:00 EST From: "Maj. William Allen" Subject: request to be added to list To: "tcp-ip" Reply-To: "Maj. William Allen" 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 ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701231850.AA01924%40wilbur.arpa] <1987012308505600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: lekash@WILBUR.ARPA (John Lekashman) Newsgroups: mod.protocols.tcp-ip Subject: tftp and proteon gateways. Message-ID: <8701231850.AA01924@wilbur.arpa> Date: Fri, 23-Jan-87 13:50:56 EST Article-I.D.: wilbur.8701231850.AA01924 Posted: Fri Jan 23 13:50:56 1987 Date-Received: Sat, 24-Jan-87 05:35:49 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 32 Approved: tcp-ip@sri-nic.arpa 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); ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701241425.a002411%40Dewey.UDEL.EDU] <1987012409384100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cassel@dewey.udel.edu.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Gateway Monitoring. Message-ID: <8701241425.a002411@Dewey.UDEL.EDU> Date: Sat, 24-Jan-87 14:38:41 EST Article-I.D.: Dewey.8701241425.a002411 Posted: Sat Jan 24 14:38:41 1987 Date-Received: Sat, 24-Jan-87 23:35:38 EST References: <8701211527.AA06816@mitre-gateway.arpa> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 2 Approved: tcp-ip@sri-nic.arpa Sorry to be dense. What is IETF? Is it an open meeting? Where, when, ....? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701242102.AA04114%40postel.isi.edu] <1987012411022200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Postel@isi.edu.UUCP Newsgroups: mod.protocols.tcp-ip Subject: FTP Enhancements Message-ID: <8701242102.AA04114@postel.isi.edu> Date: Sat, 24-Jan-87 16:02:22 EST Article-I.D.: postel.8701242102.AA04114 Posted: Sat Jan 24 16:02:22 1987 Date-Received: Sat, 24-Jan-87 23:48:54 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701242133.AA04139%40postel.isi.edu] <1987012411335300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Postel@isi.edu.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Domain Names - DDN MGT Bulletin # 32 Message-ID: <8701242133.AA04139@postel.isi.edu> Date: Sat, 24-Jan-87 16:33:53 EST Article-I.D.: postel.8701242133.AA04139 Posted: Sat Jan 24 16:33:53 1987 Date-Received: Sat, 24-Jan-87 23:50:08 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 76 Approved: tcp-ip@sri-nic.arpa ********************************************************************** 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 ----- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [13396.538527299%40nrtc-gremlin.arpa] <1987012413084900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mrose@nrtc-gremlin.arpa.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: FTP Enhancements Message-ID: <13396.538527299@nrtc-gremlin.arpa> Date: Sat, 24-Jan-87 18:08:49 EST Article-I.D.: nrtc-gre.13396.538527299 Posted: Sat Jan 24 18:08:49 1987 Date-Received: Sun, 25-Jan-87 00:15:37 EST References: <8701242102.AA04114@postel.isi.edu> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: TCP-IP@sri-nic.ARPA Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701250117.AA13121%40ohio-state.ARPA] <1987012415170700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bob@ohio-state.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: request to be added to list Message-ID: <8701250117.AA13121@ohio-state.ARPA> Date: Sat, 24-Jan-87 20:17:07 EST Article-I.D.: ohio-sta.8701250117.AA13121 Posted: Sat Jan 24 20:17:07 1987 Date-Received: Sun, 25-Jan-87 06:03:16 EST References: <8701231723.AA12881@ucbvax.Berkeley.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: osu-eddie!bob (Bob Sutterfield) Organization: The Ohio State University Department of Computer & Information Science Lines: 7 Keywords: VMS All-in-1 header Approved: tcp-ip@sri-nic.arpa In article <8701231723.AA12881@ucbvax.Berkeley.EDU> "Maj. William Allen" 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 :-) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [MS.V3.20.ddp.80020d15.lancaster.ibm032.639.5%40andrew.cmu.edu] <1987012508023700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ddp#@andrew.cmu.edu.UUCP Newsgroups: mod.protocols.tcp-ip Subject: ethernet packet type 6004 Message-ID: Date: Sun, 25-Jan-87 13:02:37 EST Article-I.D.: andrew.MS.V3.20.ddp.80020d15.lancaster.ibm032.639.5 Posted: Sun Jan 25 13:02:37 1987 Date-Received: Mon, 26-Jan-87 01:52:13 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701260612.AA20606%40ucbvax.Berkeley.EDU] <1987012514090700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: GKN@SDSC.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: ethernet packet type 6004 Message-ID: <8701260612.AA20606@ucbvax.Berkeley.EDU> Date: Sun, 25-Jan-87 19:09:07 EST Article-I.D.: ucbvax.8701260612.AA20606 Posted: Sun Jan 25 19:09:07 1987 Date-Received: Tue, 27-Jan-87 03:56:41 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: San Diego Supercomputer Center Lines: 42 Approved: tcp-ip@sri-nic.arpa 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012600090700> Received: from SDSC.ARPA by SRI-NIC.ARPA with TCP; Sun 25 Jan 87 16:11:19-PST Date: Mon 26 Jan 87 00:09:07-GMT From: Gerard K. Newman Subject: Re: ethernet packet type 6004 To: ddp#@ANDREW.CMU.EDU Cc: tcp-ip@SRI-NIC.ARPA, info-vax@SRI-KL.ARPA In-Reply-To: Message from "ddp#@andrew.cmu.edu (Drew Daniel Perkins)" of Sun, 25 Jan 87 13:02:37 est Organization: San Diego Supercomputer Center USPS-Address: P.O. Box 85608; San Diego, CA 92138 Telephone: 619.534.5076 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701262248.AA04371%40ACC-SB-UNIX.ARPA] <1987012612485700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: lars@ACC-SB-UNIX.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: ACP6250 / ACP5250 on 4.3BSD Message-ID: <8701262248.AA04371@ACC-SB-UNIX.ARPA> Date: Mon, 26-Jan-87 17:48:57 EST Article-I.D.: ACC-SB-U.8701262248.AA04371 Posted: Mon Jan 26 17:48:57 1987 Date-Received: Wed, 28-Jan-87 06:13:04 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 21 Approved: tcp-ip@sri-nic.arpa 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12274318071.38.GROSSMAN%40Sierra.Stanford.EDU] <1987012709225500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: GROSSMAN@SIERRA.STANFORD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: ethernet packet type 6004 Message-ID: <12274318071.38.GROSSMAN@Sierra.Stanford.EDU> Date: Tue, 27-Jan-87 14:22:55 EST Article-I.D.: Sierra.12274318071.38.GROSSMAN Posted: Tue Jan 27 14:22:55 1987 Date-Received: Thu, 29-Jan-87 03:28:04 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@sri-nic.arpa 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012712240000> Received: from G.BBN.COM by SRI-NIC.ARPA with TCP; Tue 27 Jan 87 16:36:03-PST Date: 27 Jan 1987 17:24-EST Sender: URBANIAK@G.BBN.COM Subject: Re: seeking source for Ether packet types and vendor address... From: URBANIAK@G.BBN.COM To: dunigan@ORNL-MSR.ARPA Cc: tcp-ip@SRI-NIC.ARPA, Urbaniak@G.BBN.COM Message-ID: <[G.BBN.COM]27-Jan-87 17:24:31.URBANIAK> In-Reply-To: <8701212106.AA18267@ORNL-MSR.ARPA> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012713522200> Received: from mojave.stanford.edu by SRI-NIC.ARPA with TCP; Tue 27 Jan 87 21:52:54-PST Received: from LOCALHOST by mojave.stanford.edu with TCP; Tue, 27 Jan 87 21:52:25 PST To: hedrick@topaz.rutgers.edu Cc: tcp-ip@nic.sri.com Subject: Black holes for 4.3BSD Date: Tue, 27 Jan 87 21:52:22 PST From: satz@mojave.stanford.edu 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [145714.870127.JBVB%40AI.AI.MIT.EDU] <1987012718582300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JBVB@AI.AI.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Bit 8 in Telnet streams Message-ID: <145714.870127.JBVB@AI.AI.MIT.EDU> Date: Tue, 27-Jan-87 23:58:23 EST Article-I.D.: AI.145714.870127.JBVB Posted: Tue Jan 27 23:58:23 1987 Date-Received: Thu, 29-Jan-87 04:24:17 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701280607.AA11550%40ucbvax.Berkeley.EDU] <1987012719522200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: satz@MOJAVE.STANFORD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Black holes for 4.3BSD Message-ID: <8701280607.AA11550@ucbvax.Berkeley.EDU> Date: Wed, 28-Jan-87 00:52:22 EST Article-I.D.: ucbvax.8701280607.AA11550 Posted: Wed Jan 28 00:52:22 1987 Date-Received: Thu, 29-Jan-87 03:42:28 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701281142.AA13502%40devvax.TN.CORNELL.EDU] <1987012801425200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: swb@DEVVAX.TN.CORNELL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: seeking source for Ether packet types and vendor address... Message-ID: <8701281142.AA13502@devvax.TN.CORNELL.EDU> Date: Wed, 28-Jan-87 06:42:52 EST Article-I.D.: devvax.8701281142.AA13502 Posted: Wed Jan 28 06:42:52 1987 Date-Received: Thu, 29-Jan-87 05:43:18 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 2 Approved: tcp-ip@sri-nic.arpa What is the "valid machine protocol"? Scott ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701281152.AA17103%40ucbvax.Berkeley.EDU] <1987012801540200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: BLASCO@ICNUCEVM.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: DEC DELNI Message-ID: <8701281152.AA17103@ucbvax.Berkeley.EDU> Date: Wed, 28-Jan-87 06:54:02 EST Article-I.D.: ucbvax.8701281152.AA17103 Posted: Wed Jan 28 06:54:02 1987 Date-Received: Thu, 29-Jan-87 05:23:36 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [145859.870128.JBVB%40AI.AI.MIT.EDU] <1987012804274200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JBVB@AI.AI.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Clarification of 8-bit Telnet info request Message-ID: <145859.870128.JBVB@AI.AI.MIT.EDU> Date: Wed, 28-Jan-87 09:27:42 EST Article-I.D.: AI.145859.870128.JBVB Posted: Wed Jan 28 09:27:42 1987 Date-Received: Thu, 29-Jan-87 05:40:52 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@sri-nic.arpa 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701281815.AA01305%40postel.isi.edu] <1987012808152500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Postel@ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: croissants or doughnuts ? Message-ID: <8701281815.AA01305@postel.isi.edu> Date: Wed, 28-Jan-87 13:15:25 EST Article-I.D.: postel.8701281815.AA01305 Posted: Wed Jan 28 13:15:25 1987 Date-Received: Thu, 29-Jan-87 06:41:40 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa "... 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701282038.AA25069%40ucbvax.Berkeley.EDU] <1987012808522400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: walsh@HARVARD.HARVARD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: how to make use of redundant routes Message-ID: <8701282038.AA25069@ucbvax.Berkeley.EDU> Date: Wed, 28-Jan-87 13:52:24 EST Article-I.D.: ucbvax.8701282038.AA25069 Posted: Wed Jan 28 13:52:24 1987 Date-Received: Thu, 29-Jan-87 06:44:34 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012808522401> Received: from harvard.HARVARD.EDU by SRI-NIC.ARPA with TCP; Wed 28 Jan 87 12:25:03-PST Received: by harvard.HARVARD.EDU; Wed, 28 Jan 87 13:52:24 EST Date: Wed, 28 Jan 87 13:52:24 EST Received: by endor.HARVARD.EDU; Wed, 28 Jan 87 13:42:26 EST From: walsh@harvard.HARVARD.EDU (Bob Walsh) To: JNC@xx.lcs.mit.edu, hedrick@topaz.rutgers.edu Subject: Re: how to make use of redundant routes Cc: tcp-ip@sri-nic.ARPA 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012809420800> Received: from grape.ads.ARPA ([192.5.45.8]) by SRI-NIC.ARPA with TCP; Thu 29 Jan 87 14:55:09-PST 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 In-Reply-To: your article <16725@ads.ARPA> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987012811320000> Received: from WISCVM.WISC.EDU by SRI-NIC.ARPA with TCP; Wed 28 Jan 87 03:41:21-PST Received: from (MAILER)ICNUCEVM.BITNET by WISCVM.WISC.EDU on 01/28/87 at 05:41:31 CST Received: by ICNUCEVM (Mailer X1.23) id 8197; Wed, 28 Jan 87 10:43:25 SET Date: Wed, 28 Jan 87 10:32 SET From: A. Blasco Bonito Subject: DEC DELNI To: TCP-IP Distribution List 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701290022.AA17220%40monk.proteon.com] <1987012814221300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jas@monk.proteon.com.UUCP Newsgroups: mod.protocols.tcp-ip Subject: IEEE Address blocks Message-ID: <8701290022.AA17220@monk.proteon.com> Date: Wed, 28-Jan-87 19:22:13 EST Article-I.D.: monk.8701290022.AA17220 Posted: Wed Jan 28 19:22:13 1987 Date-Received: Fri, 30-Jan-87 01:40:35 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701290124.AA06332%40topaz.rutgers.edu] <1987012815245500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: how to make use of redundant routes Message-ID: <8701290124.AA06332@topaz.rutgers.edu> Date: Wed, 28-Jan-87 20:24:55 EST Article-I.D.: topaz.8701290124.AA06332 Posted: Wed Jan 28 20:24:55 1987 Date-Received: Fri, 30-Jan-87 06:14:19 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 2 Approved: tcp-ip@sri-nic.arpa Routed uses broadcasts, so snooping on the gateways doesn't require promiscuous mode. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701300846.AA26604%40ucbvax.Berkeley.EDU] <1987012815420800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mab@ADS.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Clarification of 8-bit Telnet info request Message-ID: <8701300846.AA26604@ucbvax.Berkeley.EDU> Date: Wed, 28-Jan-87 20:42:08 EST Article-I.D.: ucbvax.8701300846.AA26604 Posted: Wed Jan 28 20:42:08 1987 Date-Received: Sat, 31-Jan-87 05:29:42 EST References: <16725@ads.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12274787478.13.DUMAS%40SUMEX-AIM.STANFORD.EDU] <1987012904212700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DUMAS@SUMEX-AIM.STANFORD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Satellite gateways Message-ID: <12274787478.13.DUMAS@SUMEX-AIM.STANFORD.EDU> Date: Thu, 29-Jan-87 09:21:27 EST Article-I.D.: SUMEX-AI.12274787478.13.DUMAS Posted: Thu Jan 29 09:21:27 1987 Date-Received: Fri, 30-Jan-87 05:35:39 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa 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. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701291600.AA08933%40necntc.NEC.COM] <1987012906002800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jeff@necntc.NEC.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: internet numbering scheme Message-ID: <8701291600.AA08933@necntc.NEC.COM> Date: Thu, 29-Jan-87 11:00:28 EST Article-I.D.: necntc.8701291600.AA08933 Posted: Thu Jan 29 11:00:28 1987 Date-Received: Sat, 31-Jan-87 06:28:34 EST References: <8701262248.AA04371@ACC-SB-UNIX.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: jeff%necntc.uucp@harvisr.harvard.edu Organization: NEC Electronics Inc. Natick, MA 01760 Lines: 29 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701301915.AA09453%40ACC-SB-UNIX.ARPA] <1987013009151000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cam@ACC-SB-UNIX.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: WISCNET 3270 Protocol Conversion Message-ID: <8701301915.AA09453@ACC-SB-UNIX.ARPA> Date: Fri, 30-Jan-87 14:15:10 EST Article-I.D.: ACC-SB-U.8701301915.AA09453 Posted: Fri Jan 30 14:15:10 1987 Date-Received: Sat, 31-Jan-87 07:49:14 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701302053.AA12471%40mitre-bedford.ARPA] <1987013010533400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: sra@MITRE-BEDFORD.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: TCP for ATT machines Message-ID: <8701302053.AA12471@mitre-bedford.ARPA> Date: Fri, 30-Jan-87 15:53:34 EST Article-I.D.: mitre-be.8701302053.AA12471 Posted: Fri Jan 30 15:53:34 1987 Date-Received: Sat, 31-Jan-87 08:26:18 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701310118.AA16963%40ACC-SB-UNIX.ARPA] <1987013015185900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: lars@ACC-SB-UNIX.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: New Layout of 32-bit addresses ? Message-ID: <8701310118.AA16963@ACC-SB-UNIX.ARPA> Date: Fri, 30-Jan-87 20:18:59 EST Article-I.D.: ACC-SB-U.8701310118.AA16963 Posted: Fri Jan 30 20:18:59 1987 Date-Received: Sat, 31-Jan-87 16:17:17 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 72 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8701310247.AA17949%40ucbvax.Berkeley.EDU] <1987013016492300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mills@udel.edu.UUCP Newsgroups: mod.protocols.tcp-ip Subject: X.25 may be off the hook Message-ID: <8701310247.AA17949@ucbvax.Berkeley.EDU> Date: Fri, 30-Jan-87 21:49:23 EST Article-I.D.: ucbvax.8701310247.AA17949 Posted: Fri Jan 30 21:49:23 1987 Date-Received: Sat, 31-Jan-87 09:14:19 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 21 Approved: tcp-ip@sri-nic.arpa 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987013101160000> Mail-From: STJOHNS created at 31-Jan-87 09:17:41 Date: 31 Jan 1987 09:16-PST Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: New Layout of 32-bit addresses ? From: STJOHNS@SRI-NIC.ARPA To: lars@ACC-SB-UNIX.ARPA Cc: tcp-ip@SRI-NIC.ARPA, gary@ACC-SB-UNIX.ARPA Message-ID: <[SRI-NIC.ARPA]31-Jan-87 09:16:35.STJOHNS> In-Reply-To: <8701310118.AA16963@ACC-SB-UNIX.ARPA> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987013102262500> Received: from UDEL2.UDEL.EDU ([192.5.39.88]) by SRI-NIC.ARPA with TCP; Fri 30 Jan 87 18:33:19-PST Date: 31-Jan-87 02:26:25-UT From: mills@udel.edu Subject: X.25 may be off the hook To: tcp-ip@sri-nic.arpa 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 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702010431.AA06392%40ucbvax.Berkeley.EDU] <1987013117582400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dyer@harvard.HARVARD.EDU@spdcc.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: internet numbering scheme Message-ID: <8702010431.AA06392@ucbvax.Berkeley.EDU> Date: Sat, 31-Jan-87 22:58:24 EST Article-I.D.: ucbvax.8702010431.AA06392 Posted: Sat Jan 31 22:58:24 1987 Date-Received: Sun, 1-Feb-87 11:47:16 EST References: <8701291600.AA08933@necntc.NEC.COM> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: dyer@spdcc.COM (Steve Dyer) Organization: S.P. Dyer Computer Consulting, Cambridge MA Lines: 16 Approved: tcp-ip@sri-nic.arpa 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987013117582401> Received: from harvard.HARVARD.EDU by SRI-NIC.ARPA with TCP; Sat 31 Jan 87 19:57:33-PST Received: by harvard.HARVARD.EDU; Sat, 31 Jan 87 22:58:24 EST Date: Sat, 31 Jan 87 22:58:24 EST From: spdcc!dyer@harvard.HARVARD.EDU To: harvard!tcp-ip@sri-nic.arpa Newsgroups: mod.protocols.tcp-ip Subject: Re: internet numbering scheme References: <8701262248.AA04371@ACC-SB-UNIX.ARPA> <8701291600.AA08933@necntc.NEC.COM> Reply-To: dyer@spdcc.COM (Steve Dyer) Organization: S.P. Dyer Computer Consulting, Cambridge MA 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 ----MESSAGE-END----