----MESSAGE-BEGIN---- <1984020203570000> Return-Path: Received: from JPL-VLSI.ARPA by SRI-NIC with TCP; Thu 2 Feb 84 11:59:48-PST Date: 2 Feb 1984 1157 PST From: Eric P. Scott Subject: When a stranger knocks... To: TCP-IP@SRI-NIC Reply-To: EPS@JPL-VLSI We changed our official name and address yesterday; this had some amusing effects on SMTP servers. Most didn't seem to mind, e.g. 220 UCB-VAX.ARPA Sendmail 4.22/4.21 ready at Wed, 1 Feb 84 19:15:25 pst HELO JPL-VLSI.ARPA 250 UCB-VAX.ARPA Hello JPL-VLSI.ARPA, pleased to meet you QUIT 221 UCB-VAX.ARPA closing connection [I discovered that FUZZBALLs match the first three characters of SMTP commands, e.g. HELP gives a 250 reply.] BRL was perfectly calm until I QUIT... 220 brl Server SMTP (Complaints/bugs to: MMDF@BRL-BMD.ARPA) HELO JPL-VLSI.ARPA 250 brl QUIT 221 brl says goodbye to 10.3.0.54 at Wed Feb 1 22:23:40 . ...but a number of TOPS-20 sites complained sooner: 220-SU-SCORE.ARPA SMTP Service 5.3(161) at Wed 1 Feb 84 19:07:23-PST 220 Bugs/Gripes to Bug-MAISER@SU-SCORE.ARPA HELO JPL-VLSI.ARPA 250 SU-SCORE.ARPA - You are a charlatan, [10.3.0.54] QUIT 221 SU-SCORE.ARPA Service closing transmission channel One REAL LOSER was UCI-750A. After a long pause: 521 Mail system claims 10.3.0.54 is an unknown host No CRLF followed the text; the connection closed immediately. Just the facts, ma'am. -=EPS=- ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020206213400> Return-Path: Received: from SU-SCORE.ARPA by SRI-NIC with TCP; Thu 2 Feb 84 14:24:17-PST Date: Thu 2 Feb 84 14:21:34-PST From: Mark Crispin Subject: Re: When a stranger knocks... To: EPS@JPL-VAX.ARPA cc: TCP-IP@SRI-NIC.ARPA In-Reply-To: Message from "Eric P. Scott " of Thu 2 Feb 84 11:57:00-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) The TOPS-20 SMTP server validates addresses vs. claimed names, but will still accept the HELO command. Note that Score's SMTP server responded with a 250. It will note the discrepancy in the "Received" RFC 822 header line in a command, as in: Received: from JPL-VLSI.ARPA ([10.3.0.54]) by SU-SCORE with TCP; Thu 2 Feb 84 11:59:48-PST but otherwise will allow the mail through. "You are a charlatan" means that the claimed name was known on a different address; "never heard of you" means the claimed name is unknown. The TOPS-20 mailsystem considers bracketed host addresses (as in [10.3.0.54]) to be completely equivalent to host names and in fact it can't tell the difference in most places. -- Mark -- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020208041500> Return-Path: Received: from UCI-750a by SRI-NIC with TCP; Thu 2 Feb 84 16:06:56-PST Date: 02 Feb 84 16:04:15 PST (Thu) Message-ID: <372.444614655@uci-750a> To: EPS@Jpl-Vax cc: TCP-IP@Sri-Nic cc: Reply Distribution List: ; Subject: Re: When a stranger knocks... In-reply-to: Your message of 2 Feb 1984 1157 PST. From: Network Services (agent: Marshall Rose) I must take some issue with your description of one of our hosts. I realize that your report was intentionally humorous (at least that's how I read it), but I think you touched upon a legitimate issue, while you were calling us names. One REAL LOSER was UCI-750A. After a long pause: 521 Mail system claims 10.3.0.54 is an unknown host No CRLF followed the text; the connection closed immediately. At the bottom of the message, I have an explanation as to why we didn't know who you were, but it's a digression, so I'll skip it for now. I object though to the term "loser". As far as we know, 10.3.0.54 is ficticious. It's not in any of OUR host tables which was updated from the NiC's copy 1 week ago. Why should we accept mail from you? UCB-VAX is running SendMail which couldn't care less about the mail it gets. It is not "secure" in the sense that it does not do authentication of the sender. BRL is running a later version of MMDF than we are and has what I would imagine to be a much better server that the UCI counterpart. My guess is that their server tells the mail system that you are 10.3.0.54 and the mail system uses that and not the name you gave it. Apparently, the server does not take it as given that your name really is JPL-VLSI. I applaud the efforts of the MMDF people to try and make MMDF very "secure". MMDF does lots of authentication checking. They treat mail very seriously [my personal opinion, flames to me, not them]. MRC's TOPS-20 server also knows that you aren't who you say you are, but says it up front, before you do anything else. I don't know what Mark's implementation does, since I'm not familiar with it, but I'd guess that it uses 10.3.0.54 instead of JPL-VLSI. We are running one of the earliest versions of MMDF, which has been modified quite a bit to use SMTP and act 822-ish. The long pause is due to the fact that we search many host tables looking for "10.3.0.54" (which we aren't going to find) and also because that system is always heavily loaded. As far as the lack of a CRLF goes, that's a typo. I've fixed it. You might claim that because our server doesn't accept a connection when it can't determine the internet name of a host making the connection, that it doesn't meet the SMTP spec. I disagree. If your host is not registered in the NiC's HOSTS.TXT file, we refuse to talk mail with you. You are not an Internet site by "our definition". Perhaps an Internet guru (listening JBP or PVM?) can clarify this for me. We had the same problem when we hooked into the Internet in December of last year. Although we made it into the 26-Dec-83 HOSTS.TXT, a lot of sites didn't start accepting mail from us until about mid-January. I'm sure there are still a few hosts about that refuse to talk to us. Also, being new at all of this, can someone tell me how often I should be grabbing HOSTS.TXT from the NiC? I've been doing this once every other week, but after reading the "ps" below, it seems that isn't enough. Thanks, /mtr ps: Why we didn't know who you were: On January 28th, I grabbed the 1-26-84 version of HOSTS.TXT from the NiC. The entry for JPL-VAX was: HOST : 26.3.0.54 : JPL-VAX,JPL-VLSI : VAX-11/780 : VMS : TCP/TELNET,TCP/FTP,TCP/SMTP,TCP/FINGER,UDP : Just a few minutes ago, I grabbed the most "recent" HOSTS.TXT file from the NiC. The date at the top STILL says 1-26-84, but the file has changed. The version of the new file, according to the hostnames server is 328. Sadly, I didn't check on the version of the other file dated 1-26-84. Anyway, now the entry for JPL-VLSI is: HOST : 10.3.0.54 : JPL-VLSI,JPL-VAX : VAX-11/780 : VMS : TCP/TELNET,TCP/FTP,TCP/SMTP,TCP/FINGER,UDP : The address of a host called "NSWC-WO" has also changed between these two files with the same date. That explains why our host tables are supposedly 1 week out of date, despite the fact the date on the HOSTS.TXT file at the NiC hasn't changed. Guilty. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020208260000> Return-Path: Received: from JPL-VLSI.ARPA by SRI-NIC with TCP; Thu 2 Feb 84 16:30:52-PST Date: 2 Feb 1984 1626 PST From: Eric P. Scott Subject: When to update tables To: TCP-IP@SRI-NIC Cc: netser@UCI-750A Reply-To: EPS@JPL-VLSI I was under the impression that "the right thing to do" is to send a VERSION request to the hostnames server (as part of a daily procedure, for example) and retrieve the new tables if the reply you get doesn't agree with the last one you remember. Some sites apparently never update their tables unless they get a mass mailing from the NIC advertising the availability of a new set; this is suboptimal behavior. Many mailers have short attention spans; after three days of non-delivery they give up. "Can it wait until Monday?" "No!" I get really ticked when I get dropped from mailing lists because of temporary problems beyond my control, often with no notification whatsoever. When I notice non-deliveries in our mailer log, I try to track them down. Sometimes the 1822 host dead status is useful! IP is wonderful, etc., but if I have unnatural knowledge I use it. If your "secure" SMTP is going to be antisocial, it could at least notify someone human that something bozo is happening. Refusing to accept traffic just strikes me as blatently wrong behavior. I stand by my value judgement. -=EPS=- ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020208374900> Return-Path: Received: from UCI-750a by SRI-NIC with TCP; Thu 2 Feb 84 16:39:16-PST Date: 02 Feb 84 16:37:49 PST (Thu) Message-ID: <372.444616669@uci-750a> To: EPS@Jpl-Vax cc: TCP-IP@Sri-Nic cc: Reply Distribution List: ; Subject: Re: When to update tables In-reply-to: Your message of 2 Feb 1984 1626 PST. From: Network Services (agent: Marshall Rose) Thanks for the "version" tip. I'll start using it in a "automated" fashion. Actually, our mail server does tell us when something like that happens, once a day. Unfortunately, someone "stole" my status report listing last night and I haven't generated a new one yet. I really don't consider our SMTP either "secure" or anti-social. Cautious is a better term. (-: /mtr ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020210450000> Return-Path: Received: from SU-SCORE.ARPA by SRI-NIC with TCP; Thu 2 Feb 84 18:47:57-PST Date: Thu 2 Feb 84 18:45:00-PST From: Mark Crispin Subject: "secure"/"anti-social"/"cautious" SMTP server To: TCP-IP@SRI-NIC.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Any SMTP server which rejects mail because its (possibly out of date) host tables cause a host name validation failure deserve to be called "losing". I can think of a zillion ways to forge mail to such a server. It is not secure. I seriously doubt that the server intentionally rejects mail in order to inconvenience new hosts. It is not anti-social. A cautious approach would dictate accepting the message, as it could be some critical message (e.g. funding information!); at most it should note the host name validation failure as a comment. The server in question is not cautious. If "losing" seems to be too personal, use "faulty" instead. A faulty SMTP server rejected a valid mail message from a site which validly stated its valid name on its valid address. The cause of the rejection was that the faulty SMTP server uses the faulty and obsolete concept of host tables. Only name server information should be considered current or trustworthy. We live in a networking era of incomplete knowledge of network topology. There are many sites at Stanford talking TCP which aren't in the NIC table. In general, most of those sites won't be sending mail to ARPANET anyway. But it doesn't mean that mail from such a site should necessarily be rejected. I wonder how many SMTP servers will accept a command such as: HELO [10.3.0.11] (TOPS-20s will!). -- Mark -- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020215211800> Return-Path: Received: from UCI-750a by SRI-NIC with TCP; Thu 2 Feb 84 23:23:01-PST Date: 02 Feb 84 23:21:18 PST (Thu) Message-ID: <372.444640878@uci-750a> To: Mark Crispin cc: TCP-IP@Sri-Nic cc: Reply Distribution List: ; Subject: Re: "secure"/"anti-social"/"cautious" SMTP server In-reply-to: Your message of Thu 2 Feb 84 18:45:00-PST. From: Network Services (agent: Marshall Rose) [Watch closely and I will remove the foot from my mouth.] I agree that faulty is a much better term, and I agree that uci-750a's SMTP server is faulty at best. However, you should think that I was claiming that our SMTP server was "secure". I made no advertisements of that kind at all. I was trying to explain, rather lamely, why it did what it did. /mtr ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020215575700> Mail-From: ROODE created at 2-Feb-84 23:57:57 Date: Thu 2 Feb 84 23:57:57-PST From: David Roode Subject: Re: When a stranger knocks... To: wert.Rice@RAND-RELAY.ARPA, netser@UCI-750A cc: EPS@JPL-VLSI, TCP-IP@SRI-NIC In-Reply-To: Message from "Scott Comer " of Thu 2 Feb 84 22:38:56-PST Location: EJ286 Phone: (415) 859-2774 On many hosts, users can reply to the ADDRESS even if the HOSTNAME is not known to the system. Thus they can slip around lax system operators who do not update hostables rapidly. Soon, we will have domain addressing with dynamic name resolution and such concerns will not be relevant (knock on wood). ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020216162100> Return-Path: Received: from RUTGERS.ARPA by SRI-NIC with TCP; Thu 2 Feb 84 18:21:20-PST Date: 2 Feb 84 21:16:21 EST From: Charles Hedrick Subject: Re: When a stranger knocks... To: netser.UCI-750A@RAND-RELAY.ARPA cc: EPS@JPL-VAX.ARPA, TCP-IP@SRI-NIC.ARPA In-Reply-To: Message from "Network Services (agent: Marshall Rose) " of 2 Feb 84 19:04:15 EST Probably your message crossed Crispin's in the mail. But in case you didn't notice, Tops-20 does what I think is the optimal thing: 1) it accepts the mail 2) the response to HELO, although 250 (which indicates that it worked), gives a clear indication that something is wrong, so that someone can follow up. 3) in the RECEIVED line, a comment is supplied giving the actual host address when it differs from what we think it should be. Actually I think my old code was better. It said Received from [1.2.3.4] (claiming to be FOO.ARPA) This message causes me to raise two other issues that have been sitting in my mind waiting for an excuse: 1) The protocol specified that user names must be validated. However as far as I can see there is no way to do that. We can verify the host from which it came, and Crispin's Tops-20 handles that fairly well. But anyone at that site can open a connect to us and claim to be anybody he wants. We prevent that on our Ethernet by having the mail sender use a privileged socket. The mail receiver refuses to talk to anyone who is not on a privileged socket. This guarantees that we accept mail only from the real mailer on the other end. We are able to use operating system facilities to make sure that the real mailer always gives a return-path that is the actual person who created the message. Either the RFC's should drop the requirement that names be validated, or some mechanism like this should be made network-wide. I realize that there will be systems where this doesn't make sense (e.g. ITS, where there is little security), or dialup implementations of TCP. But at least we should be able to preserve the same degree of security that was present on the originating system. 2) It might be helpful to have ways of reporting nonfatal problems. E.g. for problems on the sending side, the receiver could use a response meaning "this operation succeeded, but it probably shouldn't have". This would cause the mail system at the other end to make an entry in an exceptions log, send mail to the maintainer, or something else appropriate. Then we could acknowlege a HELO by: 251 You are internet [1.2.3.4]. You claim to be FOO.ARPA. 251-According to our records you are not. The sender should also be able to do this, presumably via a new commands, something like EXCEPTION-REPORT: EXCEPTION-REPORT 250 end with . In delivering a message from FOO.ARPA to BAR.ARPA, FOO.ARPA had to use 50-byte segments, pushed. Something may be wrong with your TCP. . ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020218182600> Return-Path: Received: from RICE by SRI-NIC with TCP; Thu 2 Feb 84 22:38:36-PST Received: by RICE (AA05499); Fri, 3 Feb 84 00:26:22 cst Date: Fri, 3 Feb 84 00:18:26 CST From: Scott Comer Subject: Re: When a stranger knocks... To: Network Services (agent: Marshall Rose) Cc: EPS@Jpl-Vax, TCP-IP@Sri-Nic Message-Id: <441.wert.Dione@Rice> In-Reply-To: a message from Network Services dated 02 Feb 84 16:04:15 PST (Thu) It seems to me to be better to reject mail from an unknown host than to accept mail from such a host and then have users (on the local host) get mail from this machine and not be able to reply. This puts the responsibility on the machine with the strange name to make sure everyone knows its name, rather than on the unsuspecting users who got mail from a bogus host. Of course, this is just my opinion... wert ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020222353800> Return-Path: Received: from BRL-VGR by SRI-NIC with TCP; Fri 3 Feb 84 01:17:14-PST Date: Fri, 3 Feb 84 3:35:38 EST From: Mike Muuss To: "Network Services (agent: Marshall Rose)" cc: tcp-ip@sri-nic Subject: Fetching HOSTS.TXT from NIC The strategy that we use at BRL is to download the NIC table to ONE machine once a night (at 0400 EST), and redistribute it to all BRLNET machine locally. The procedure is entirely automated, and makes heavy use of the UNIX RSH/RCP facility (Bravo, Berkeley!). This procedure is called /etc/nightly, and in addition to updating host tables, it also propagates changes in the "BRL global name space", and causes fresh MMDF binary databases to be generated. -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020223590000> Return-Path: Received: from Shasta by SRI-NIC with TCP; Sat 4 Feb 84 23:12:45-PST Received: from imagen by Shasta with UUCP; Sat, 4 Feb 84 23:08 PST Date: Saturday, 4 Feb 1984 23:05-PST Date: Friday, 3 Feb 1984 07:59-PST To: shasta!TCP-IP@sri-nic.arpa Cc: geof@Shasta Subject: RE:When a stranger knocks... From: geof@Shasta I don't see why the desire for a ``secure mailer'' prevents a host from accepting mail when the sender's host name is unknown. After all we are Receiving information, not sending it. As long as the receiver of the mail knows that the sender's identity is dubious, I see no reason to avoid forwarding the mail to its destination. I am arguing for an approach like that of Tops-20, where the unknown identity of the sender is added to the mail header. Actually, I think that the (somewhat obscure) message that is presently placed there should be more to the effect of: Security-Caution: THE IDENTITY OF THE HOST THAT SENT THIS MESSAGE (name) DOES NOT CONCUR WITH ITS ADDRESS IN INTERNAL TABLES (address). PLEASE AVOID RELYING ON THE AUTHENTICITY OF THE SENDER WITHOUT SEPARATE VERIFICATION. (alright, it's a little verbose, but who would overlook it?) - Geof Cooper Imagen ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020301160000> Return-Path: Received: from PARC-MAXC.ARPA by SRI-NIC with TCP; Fri 3 Feb 84 09:19:56-PST Date: Fri, 3 Feb 84 09:16 PST From: Taft.PA@PARC-MAXC.ARPA Subject: Re: When a stranger knocks... To: TCP-IP@SRI-NIC.ARPA Who says the host named in the HELO command has anything to do with the domain of the message's originator? Validating the host name serves no useful purpose. If you insist on validating anything, it should be the return-path domain name given in the MAIL FROM command. Arguments about security considerations in this context are absurd. The ARPA Internet is an open system. "Validated" host names and "privileged" sockets are meaningless and have no security benefit. The only way to achieve secure communication in an open system is to use end-to-end encryption. Ed Taft ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020303390000> Return-Path: Received: from JPL-VLSI.ARPA by SRI-NIC with TCP; Fri 3 Feb 84 11:45:06-PST Date: 3 Feb 1984 1139 PST From: Eric P. Scott Subject: RTFM ("Read The Manual") To: TCP-IP@SRI-NIC Cc: wert@Rice Reply-To: EPS@JPL-VLSI RFC 821 states: Sometimes a host is not known to the translation function and communication is blocked. To bypass this barrier two numeric forms are also allowed for host "names". One form is a decimal integer prefixed by a pound sign, "#", which indicates the number is the address of the host. Another form is four small decimal integers separated by dots and enclosed by brackets, e.g., "[123.255.37.2]", which indicates a 32-bit ARPA Internet Address in four 8-bit fields. -=EPS=- ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020303400000> Return-Path: Received: from LLL-MFE by SRI-NIC with TCP; Fri 3 Feb 84 11:41:42-PST Date: Fri, 3 Feb 84 11:40 PST From: Maron@LLL-MFE.ARPA Subject: I need pointers to TCP/IP code To: tcp-ip@nic.arpa (1) I need to implement TCP/IP on PDP-11s using a home grown OS, i.e. not RSX, RT, VMS , UNIX, etc. etc. Does anyone have any PD code either in assembler (PDP-11) or C that I could get as a guide or to use fairly directly? (2) Please respond directly to me, I am not on the list. I'm MARON@LLL-MFE. Thanks in advance, --Neil Maron CC: tcp-ip@nic.arpa, Maron ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020309450000> Return-Path: Received: from JPL-VLSI.ARPA by SRI-NIC with TCP; Fri 3 Feb 84 17:47:36-PST Date: 3 Feb 1984 1745 PST From: Eric P. Scott Subject: Query for Murphy's Lawyers To: TCP-IP@SRI-NIC Reply-To: EPS@JPL-VLSI What do you do when something goes wrong with the network where nothing *ever* goes wrong? We're learning... * * * Our IMP connection is via a microwave link that isn't quite as reliable as we'd like (you'd think JPL wouldn't have this problem, especially at terrestrial distances). Our 4.1cBSD- derived software doesn't seem to care that the IMP Ready line has gone away for an extended period of time. How can I convince it that the interface is unavailable? A non-obvious (to me, anyway) and somewhat elegant approach: capitalizing on the symmetry of the 1822 Host Access Protocol, put our ECU in Local Loopback 2 and send a Type 2 (IMP going down in 30 seconds) message using a "raw IMP" socket. Half a minute later things are left in a consistent state from which recovery will automatically occur once the link is restored and a Reset is received. * * * Does anyone have a set of guidelines related to network fault- finding? Comments? -=EPS=- ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020313233100> Return-Path: Received: from USC-ISID.ARPA by SRI-NIC with TCP; Fri 3 Feb 84 21:27:36-PST Date: 3 Feb 1984 21:23:31 PST From: MILLS@USC-ISID Subject: Re: When a stranger knocks... To: EPS@JPL-VAX, TCP-IP@SRI-NIC cc: MILLS@USC-ISID In response to the message sent 2 Feb 1984 1157 PST from EPS@JPL-VLSI Eric, Oh gawrd, another one caught me! Fuzzies do, indeed, parse only the first three characters of the command name. THey should, however, return what they think is the current mapping between your host address and its apparent name from the NIC tables. Unfortunately, they are a leetle bit behind in snarfing the HOSTS.TXT, at least compared with the TOPSes. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020407580000> Return-Path: Received: from MIT-MC by SRI-NIC with TCP; Sat 4 Feb 84 10:00:01-PST Date: 4 February 1984 12:58 EST From: David C. Plummer Subject: Re: When a stranger knocks... To: MILLS @ USC-ISID cc: TCP-IP @ SRI-NIC, EPS @ JPL-VLSI Date: 3 Feb 1984 21:23:31 PST From: MILLS@USC-ISID In response to the message sent 2 Feb 1984 1157 PST from EPS@JPL-VLSI BTW, folks. What silly mail reading program is putting this textual "In response to ... " in the body instead of using an In-reply-to: field in the header? I guess you've never used m-X Select Conversation by References on a Lisp Machine... (BABYL may have something similar.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020410375300> Return-Path: Received: from USC-ISID.ARPA by SRI-NIC with TCP; Sat 4 Feb 84 18:42:01-PST Date: 4 Feb 1984 18:37:53 PST From: MILLS@USC-ISID Subject: Re: When a stranger knocks... To: DCP@MIT-MC cc: TCP-IP@SRI-NIC, EPS@JPL-VAX, MILLS@USC-ISID In response to your message sent 4 February 1984 12:58 EST David, I just use 'em, not build 'em. On TOPS-20s anyway. If you want to take umbrage, wait until I send something from a fuzzball, which I do build. The little fuzzthings would never do anything like stuff an "In reply" in the text. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020416143900> Return-Path: Received: from SU-SCORE.ARPA by SRI-NIC with TCP; Sun 5 Feb 84 00:17:17-PST Date: Sun 5 Feb 84 00:14:39-PST From: Mark Crispin Subject: mail security To: TCP-IP@SRI-NIC.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) Let's end this discussion about mail security. As Ed Taft pointed out, secure electronic mail in the Internet context is impossible. If any user fantasizes that he cannot receive forged mail, or that his outgoing (or incoming) mail cannot be read by anyone other than the intended recipient, that user should be educated to the hard facts. All the TOPS-20 mailsystem's "security" features will do is to assist a reasonably competant user in resisting undetected forged mail (or unauthorized reading of private mail) in those cases where the attack is initiated by a relatively unskilled vandal. I wrote much of the "security" code; it would not resist an attack by me or for that matter from any other competant TOPS-20 system programmer who took the time to familiarize himself with the mailsystem's internals. This isn't due to any Trojan horses introduced by me. This is due to the fact that Internet doesn't have any better support. Mail security is only as good as the least secure host. That's pretty unsecure. The only "secure mail" possible involves end to end encryption between trusted hosts. Let's drop this subject, and let's not hear "mail security" presented or argued as a justification for faulty software. There ain't no such thing, and the sooner this is generally recognized the sooner we can move to more productive issues, such as multi-media mail. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020604290200> Return-Path: <@DCN6.ARPA:Mills@dcn6> Received: from DCN6.ARPA by SRI-NIC with TCP; Sun 5 Feb 84 20:32:14-PST Date: 06-Feb-84 04:29:02-UT From: Mills@dcn6 Subject: An EGP one-act play To: tcp-ip@sri-nic Folks, The following longish message is offered as an example of the world seen by an EGP gateway fighting the Packet Wars resulting from the various trash floating about the Internet system. Ordinarily, I would send it (as I have sent many similar previous messages) to the wizards to help in the casting of spells. However, I think the TCP-IP community at large may gain an interesting insight into the practical problems of day-to-day operation, as well as an appreciation of the importance of isolating potential routing loops entirely within an autonomous system. Please note that some of the ills related here are due to bugs that can in principle be quickly fixed. Others are due to the sheer size of the core-gateway community, which has far outgrown the present GGP protocol. In the "near" future GGP will be replaced by something more robust, so that the disasterous "counting to infinity" problem should disappear. On the other hand, routinge and congestion problems will probably be with us for some time, so the lessons of the following may be relearned in many implementations. OUR STORY DCN-GATEWAY lives on a lonely EGP island in the midst of the GGP core-gateway sea. The story you are invited to hear involves almost a day in its hard life maintaining order for the Protocol Police. CAST OF CHARACTERS The Hero DCN-GATEWAY 10.3.0.17 (aka DCN1) a good EGP soldier and teller 128.4.0.1 of this tale 128.5.0.1 The Villians BBN-INOC 10.2.0.82 the internet monitor interface and speaker of most of the dialog TEST3 10.3.0.63 the only EGP/GGP navigation aid in the area BBN-VAN-GW 10.3.0.40 a flakeway in search of stability 14.0.0.10 Shifty Characters COLUMBIA-20 10.0.0.89 a rather dense character which talks a lot and learns nothing SRI-NIC 10.0.0.51 a firehose hard to quench RICE 14.0.0.12 a TELENET host, usually recognized as a black hole CISL-SERVICE-MULTICS 10.3.0.31 believed an EGP gateway embryo 192.5.1.1 Incidental Players FORD-WDL1 128.5.32.1 a Unixcorn hiding behind DCN-GATEWAY and a 9.6-Kbps piece of plumbing UCB-VAX 10.2.0.78 a passerby MIT-MC 10.3.0.44 mostly used by people with unscrewed heads THE PLOT DCN-GATEWAY receives its only routing information from TEST3 via EGP. When a net or a GGP core gateway is killed in a skirmish, TEST3 tells DCN-GATEWAY sooner or later, mostly later. The story opens with a backstage whisper saying that somehow DCN-GATEWAY is the best route to TELENET. That seems to unhinge BBN-INOC, which just can't seem to believe the truth, probably because of an unstable routing loop within the core system. THE SCRIPT Stage directions: Ignore the octal process number following the time. The ICMP lines in the script represent ICMP messages sent by DCN-GATEWAY. The two octal numbers are the type and code, while the Internet addresses represent the source and destination of the original datagram. Type 003 is destination- unreachable, 004 is source-quench and 005 is redirect. The Leader error lines represent 1822 host-dead messages and include the octal leader exactly as received. The script, excerpted from the DCN-GATEWAY log, begins with about 30 minutes of misrouted packets from BBN-INOC to the TELENET side of BBN-VAN-GW. DCN-GATEWAY babbles redirects (presumably to 10.3.0.40) on and on, but BBN-INOC isn't listening. 23:12:59 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] ... 178 duplicate(s) ... 23:41:44 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] Now, this is very curious, since TEST3 should be biasing anything sent by DCN-GATEWAY so that dialog within the core system should never, never escape outside. Then BBN-VAN-GW apparently dies and things get worse (note the byte-swapped leader reveals host 3 on IMP 40, which is one of the interfaces of BBN-VAN-GW). 23:41:44 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:41:44 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:42:02 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:42:02 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:42:14 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:42:14 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:42:14 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:42:14 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:42:44 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:42:44 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:42:46 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:42:46 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:42:49 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:42:49 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:43:15 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:43:15 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:43:15 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:43:16 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:43:35 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:43:35 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:43:47 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:43:47 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:43:47 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:43:47 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:44:16 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:44:16 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:44:16 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:44:16 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:44:20 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:44:20 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:45:07 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] ... 277 duplicate(s) ... 23:51:53 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:51:53 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 ... 11 duplicate(s) ... 23:52:20 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:52:24 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:52:24 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:52:25 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:52:25 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:53:00 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:53:00 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:53:00 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:53:00 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:53:28 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:53:28 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 23:53:28 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:53:29 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 23:53:58 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] ... 495 duplicate(s) ... 23:58:09 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] This spasm lasts for over 13 minutes, presumably being the time to count to infinity in that nasty GGP babble. Finally, TEST3 tells DCN-GATWEWAY net 14 is dead and things die down. BBN-INOC continues to sputter. 23:58:35 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10] ... 20 duplicate(s) ... 00:07:59 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10] A few minutes later net 14 comes back up and the raunch resumes after only 5 minutes. 00:19:10 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:24:46 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:24:46 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:24:48 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:24:48 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:25:17 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:25:17 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:25:18 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:25:18 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:25:48 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:25:48 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:25:48 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:25:49 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:26:19 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:26:19 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:26:20 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:26:20 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:26:49 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:26:50 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:26:50 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:26:50 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:27:20 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:27:20 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:27:21 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:27:21 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:27:28 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:27:29 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:27:36 006 ?TRAP-I-ICMP 005 000 [10.2.0.78] -> [14.0.0.12] 00:27:36 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:27:50 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:27:51 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:27:51 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:27:51 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:28:21 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:28:21 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:28:22 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 00:28:22 006 ?TRAP-I-Leader error 000017 003400 001400 024000 000633 00:28:50 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] ... 422 duplicate(s) ... 00:33:14 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] That spasm, having lasted over 8 minutes, passes the same way as the previous one. 00:33:30 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10] ... 21 duplicate(s) ... 00:42:30 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10] Enter the clowns. Net 128.8 is off a dumb gateway on MILNET. How did COLUMBIA-20 get here? 00:42:41 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4] Next, FORD-WDL1 attempts to FTP something from SRI-NIC, which sloshes over all 26 buffers in DCN-GATEWAY. The latter bitterly complains source-quenchedly, but SRI-NIC will have none of that truck. 00:56:30 006 ?TRAP-I-ICMP 004 000 [10.0.0.51] -> [128.5.33.1] 00:56:30 006 ?TRAP-I-No buffer 2 00:56:42 006 ?TRAP-I-ICMP 004 000 [10.0.0.51] -> [128.5.33.1] 00:56:43 006 ?TRAP-I-No buffer 2 00:56:47 006 ?TRAP-I-ICMP 004 000 [10.0.0.51] -> [128.5.33.1] 00:56:47 006 ?TRAP-I-No buffer 2 TEST3 gets quenched, too (!). Later COLUMBIA-20 chimes again. 00:56:50 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17] 00:56:50 006 ?TRAP-I-No buffer 2 01:17:04 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] A bit later COLUMBIA-20 and a friend begin hammering on FORD-WDL1 again. Buffers and quenches are dripping all over the place. 01:37:38 006 ?TRAP-I-ICMP 004 000 [10.0.0.31] -> [128.5.32.1] 01:37:38 006 ?TRAP-I-No buffer 2 01:39:11 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] 01:39:11 006 ?TRAP-I-No buffer 2 01:39:12 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] 01:39:12 006 ?TRAP-I-No buffer 2 ... 5 duplicate(s) ... 01:39:17 006 ?TRAP-I-No buffer 2 01:39:18 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] 01:39:18 006 ?TRAP-I-No buffer 2 01:39:19 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] 01:39:19 006 ?TRAP-I-No buffer 2 01:39:20 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] 01:39:21 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] 01:39:21 006 ?TRAP-I-No buffer 2 01:39:22 006 ?TRAP-I-No buffer 2 01:39:23 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] 01:39:23 006 ?TRAP-I-No buffer 2 01:39:24 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] 01:39:24 006 ?TRAP-I-No buffer 2 01:39:25 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] 01:39:25 006 ?TRAP-I-No buffer 2 ... 2 duplicate(s) ... 01:39:27 006 ?TRAP-I-No buffer 2 01:39:28 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] 01:39:28 006 ?TRAP-I-No buffer 2 01:39:29 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] 01:39:29 006 ?TRAP-I-Link up 01:39:29 006 ?TRAP-I-No buffer 2 01:39:30 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] 01:39:31 006 ?TRAP-I-No buffer 2 01:39:32 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] 01:39:32 006 ?TRAP-I-No buffer 2 01:39:33 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] 01:39:33 006 ?TRAP-I-No buffer 2 ... 3 duplicate(s) ... 01:39:36 006 ?TRAP-I-No buffer 2 01:39:37 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17] 01:39:37 006 ?TRAP-I-No buffer 2 01:43:57 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] This mess, previously identified as an instance of the "runaway ACK" bug, has been repeatedly reported to the COLUMBIA-20 wizards. As evident from the above, it completely destabilizes any gateway in its path, not just DCN-GATEWAY, that happens to have smaller than 56-Kbps pipes on the other side. In the case of COLUMBIA-20 the bug has persisted for some weeks, at least, and caused many, many spasms of the kind illustrated above. Nevertheless, COLUMBIA-20 finally gives up. Meanwhile, CISL bobbles of unknown causes, probably irrelevant here. 02:06:37 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 ... 10 duplicate(s) ... 02:07:33 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 02:09:42 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 02:11:35 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] What? Net 48 was removed from the NIC tables a month ago. Somebody needs a HOSTS.TXT injection. 02:19:41 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [48.3.2.41] 02:41:40 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] Net 14 comes unstuck again, but this time BBN-INOC is not the only one fooled. 02:45:49 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 02:48:40 006 ?TRAP-I-ICMP 005 000 [10.0.0.91] -> [14.0.0.12] ... 34 duplicate(s) ... 02:48:49 006 ?TRAP-I-ICMP 005 000 [10.0.0.91] -> [14.0.0.12] 02:48:49 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 02:48:50 006 ?TRAP-I-ICMP 005 000 [10.0.0.91] -> [14.0.0.12] ... 44 duplicate(s) ... 02:49:05 006 ?TRAP-I-ICMP 005 000 [10.0.0.91] -> [14.0.0.12] 02:51:10 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] ... 355 duplicate(s) ... 02:54:37 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 02:54:38 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10] 02:54:38 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] ... 2 duplicate(s) ... 02:54:38 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 02:54:48 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10] ... 21 duplicate(s) ... 03:03:51 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10] 03:09:14 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 ... 10 duplicate(s) ... 03:10:10 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 03:11:51 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 03:20:23 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [3.3.0.5] Off we go again with net 14: 03:22:27 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 03:25:00 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 03:27:22 006 ?TRAP-I-ICMP 005 000 [10.3.0.44] -> [14.0.0.12] ... 95 duplicate(s) ... 03:27:42 006 ?TRAP-I-ICMP 005 000 [10.3.0.44] -> [14.0.0.12] The next one is legitimate. Bleeding continues after that: 03:27:43 006 ?TRAP-I-ICMP 003 001 [128.2.254.156] -> [128.4.0.3] 03:27:43 006 ?TRAP-I-ICMP 005 000 [10.3.0.44] -> [14.0.0.12] ... 2 duplicate(s) ... 03:27:43 006 ?TRAP-I-ICMP 005 000 [10.3.0.44] -> [14.0.0.12] 03:28:02 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] ... 12 duplicate(s) ... 03:28:04 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 03:28:05 006 ?TRAP-I-ICMP 005 000 [10.2.0.78] -> [14.0.0.12] ... 2 duplicate(s) ... 03:28:05 006 ?TRAP-I-ICMP 005 000 [10.2.0.78] -> [14.0.0.12] 03:28:05 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 03:28:06 006 ?TRAP-I-ICMP 005 000 [10.2.0.78] -> [14.0.0.12] ... 76 duplicate(s) ... 03:28:29 006 ?TRAP-I-ICMP 005 000 [10.2.0.78] -> [14.0.0.12] 03:28:32 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] ... 24 duplicate(s) ... 03:28:36 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 03:28:43 006 ?TRAP-I-ICMP 005 000 [10.2.0.78] -> [14.0.0.12] ... 14 duplicate(s) ... 03:28:45 006 ?TRAP-I-ICMP 005 000 [10.2.0.78] -> [14.0.0.12] 03:29:33 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] ... 149 duplicate(s) ... 03:31:39 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 03:32:36 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10] ... 4 duplicate(s) ... 03:35:46 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10] 03:36:46 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 03:40:04 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 03:40:37 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [14.0.0.12] ... 79 duplicate(s) ... 03:41:02 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [14.0.0.12] 03:41:49 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 03:42:41 006 ?TRAP-I-ICMP 005 000 [10.3.0.44] -> [14.0.0.12] ... 99 duplicate(s) ... 03:43:01 006 ?TRAP-I-ICMP 005 000 [10.3.0.44] -> [14.0.0.12] 03:43:07 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] ... 156 duplicate(s) ... 03:49:10 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 03:49:11 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10] 03:49:11 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 03:49:11 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 03:50:21 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10] 03:51:27 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10] 03:51:44 006 ?TRAP-I-ICMP 003 000 [10.2.0.78] -> [14.0.0.12] 03:52:09 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10] ... 9 duplicate(s) ... 03:58:43 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [14.0.0.10] 04:08:45 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [192.5.46.4] ... 47 duplicate(s) ... 04:09:34 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [192.5.46.4] 04:09:48 006 ?TRAP-I-ICMP 003 000 [10.2.0.78] -> [14.0.0.12] 04:12:14 006 ?TRAP-I-ICMP 005 000 [10.2.0.78] -> [14.0.0.12] 04:12:32 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [192.5.46.4] 04:13:10 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 04:16:05 006 ?TRAP-I-ICMP 005 000 [10.3.0.44] -> [14.0.0.12] 04:41:05 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] CISL wobbles and bobbles. COLUMBIA-20 continues to whack on net 128.8 the wrong way every half hour (probably mail): 04:49:41 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 ... 10 duplicate(s) ... 04:50:38 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 04:56:32 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 04:57:17 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [14.0.0.10] 05:10:13 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 05:39:38 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 05:52:53 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 ... 10 duplicate(s) ... 05:53:51 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 06:09:29 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 06:42:58 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 06:57:08 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 ... 10 duplicate(s) ... 06:58:05 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 07:12:56 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 07:42:58 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 08:00:12 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 ... 10 duplicate(s) ... 08:01:10 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 08:12:55 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] Somebody out there is fooling with the fuzzies. DCN2 and DCN3 are asleep. After all, it is 3:30 in the morning. The carnage continues sporadically and indefinately. 08:33:24 006 ?TRAP-I-ICMP 003 001 [128.2.254.156] -> [128.4.0.2] 08:33:32 006 ?TRAP-I-ICMP 003 001 [128.2.254.156] -> [128.4.0.3] 08:41:53 006 ?TRAP-I-ICMP 003 001 [128.2.254.156] -> [128.4.0.2] 08:42:57 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 09:03:09 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 ... 10 duplicate(s) ... 09:04:06 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 09:12:56 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 09:42:54 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 10:05:49 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 ... 10 duplicate(s) ... 10:06:47 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 Just for fun, DCN-GATEWAY's line to the ARPANET IMP flaps. 10:12:16 006 ?TRAP-I-Leader error 000017 000400 000000 000000 001000 10:13:01 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 10:42:48 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 11:06:08 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 ... 10 duplicate(s) ... 11:07:04 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 11:12:51 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 11:42:49 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 12:08:39 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 ... 10 duplicate(s) ... 12:09:36 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 12:12:49 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 12:42:46 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 13:11:14 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 ... 10 duplicate(s) ... 13:12:10 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 13:12:44 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] ... 2 duplicate(s) ... 14:12:45 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 14:13:50 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 ... 10 duplicate(s) ... 14:14:45 006 ?TRAP-I-Leader error 000017 003400 001400 017400 000633 14:42:45 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 15:12:43 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] Finally, TEST3 dies as the curtain falls for the final time. 15:13:16 006 ?TRAP-I-Leader error 000017 003400 001400 037400 000233 ... 18 duplicate(s) ... 15:22:33 006 ?TRAP-I-Leader error 000017 003400 001400 037400 000233 15:23:04 006 ?TRAP-I-Leader error 000017 003400 001400 037400 000633 *** FIN *** This play will never make it to Broadway. However, even the bombs have morals: 1. How did any ARPANET host ever get the idea anything except 128.4 and 128.5 were reachable via DCN-GATEWAY? DCN-GATEWAY is known under certain conditions to fib about routing, but these conditions did not hold here. In any case, TEST3 should not believe any path outside the core system is shorter than any path inside. 2. Assuming the rash of misrouted packets from BBN-INOC was due to unstable routing information which existed while the system counted to infinity, note the terribly long time it takes to again reach stability - from a few minutes to twenty minutes or more in previous scenarios. 3. Much of the carnage illustrated in the play was apparently due to the BBN-VAN-GW gateway bobbing up and down. If we get many more gateways doing that kind of thing, it could happen that the entire gateway system could self-destruct and assume a pathological state where infinity would never be reached. 4. How can rogue hosta like COLUMBIA-20, which are second only to pingers as network disrupters, be politely but firmly repulsed until repaired? The runaway-ACK problem is probably the worst kind of thing that any host anywhere can do. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020623530000> Return-Path: Received: from OFFICE-2.ARPA by SRI-NIC with TCP; Tue 7 Feb 84 07:57:40-PST Date: 7-Feb-84 07:53 PST From: Bill Barns Subject: Martian Attack on OFFICE-8 To: tcp-ip@sri-nic Message-ID: <[OFFICE-2]TYM-WWB-4284U> The SMTP server logs for host OFFICE-8 [26.0.0.93] show attempted connections from the same Martians referred to in the message of 07-Feb-84 05:22:33-UT from , namely [97.128.13.75]. The connections failed to open up properly, as you might imagine. These connections began occurring on 30 Jan 84 13:15:53 PST and ended after 2 Feb 84 23:05:44 PST, ranging from about 14 minutes 48 seconds apart to 15 minutes 20 seconds apart, with about three 15-minute cycles skipped over entirely. The meaning of this is unknown to me. I find it interesting that the Martians are contacting us on the SMTP port. They must be on Jon Postel's RFC mailing list. I presume that every time OFFICE-8 tried to do its part of the TCP opening sequence, events similar to those cited for CMU-GATEWAY and DCN-GATEWAY probably occurred. I don't understand (and don't currently wish to understand) how all these things work at the protocol level, so I cannot interpret the meaning of it all. It does seem that it would be interesting to find out where the "Martian" datagrams are really coming from. It also seems that there is some value in distributing widely such implementation esoterica as the Mills messages. In this case it reassures me that my SMTP is not hallucinating and there really are such datagrams out there in the network. -b ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020704263500> Return-Path: Received: from SU-SCORE.ARPA by SRI-NIC with TCP; Tue 7 Feb 84 12:30:00-PST Date: Tue 7 Feb 84 12:26:35-PST From: Mark Crispin Subject: ICMP source quench To: TCP-IP@SRI-NIC.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) TOPS-20 TCP/IP, as distributed by DEC, does not implement Source Quench. I thought this was well known. Any time you have a TOPS-20 doing battle with a network that wants Source Quench you are going to lose. If ISI has written code to support Source Quench this would be the first that I have heard of it. Certainly ISI has taken no trouble to publicize the fact. If some kind ISI person would provide me with their code, I would be happy to do the work of translating it to DEC TOPS-20 and publicizing it further. TOPS-20's have a pre-set gateway table. It "pings" all pre-set "prime" and "dumb" gateways periodically, as this is the only way it can tell if a gateway is safe to use (let's hear it for this and other older and dumber implementations of TCP!). It assumes that all "always-up" gateways are "always up" and that silence from that gateway doesn't imply it is down. Now that I've described the stage, let's enter two of the stage designers who Dave has overlooked. One is the NIC, the other are the nice people who bring us gateways. In theory, it suffices for a host to only have two Prime gateways wired in. This has been demonstrated to NOT be the case. Repeatedly, TOPS-20s have discovered that there are gateways in the NIC INTERNET.GATEWAYS table which are NOT known to Prime gateways. So we must argue that there is a definite communication problem between the NIC and the gateway maintainers as to what are gateways on Internet. Next, the NIC evidentally refuses to provide an INTERNET.GATEWAYS table which is useful; that is, a table which contains only the gateways which a site needs to have pre-wired in. Nominally the table would only contain a few Prime gateways (implying a set of tables, with each site assigned to take a particular one) and those gateways not known to Prime gateways. The latter set of gateways should normally be empty, but let's say there is a problem in the gateways. I would like to hear why the NIC won't do this. All too many sites just take the full NIC INTERNET.GATEWAYS table and install it. They don't know any better, and some of them can't be taught any better. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020704580000> Return-Path: Received: from JPL-VLSI.ARPA by SRI-NIC with TCP; Tue 7 Feb 84 13:01:20-PST Date: 7 Feb 1984 1258 PST From: Eric P. Scott Subject: Re: Martian Attack on OFFICE-8 To: TCP-IP@SRI-NIC Cc: WWB.TYM@OFFICE-2 Reply-To: EPS@JPL-VLSI I suspect the Martians have INTERLANded somewhere in the Berkeley hills... -=EPS=- ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020705223300> Return-Path: <@DCN6.ARPA:mills@dcn6> Received: from DCN6.ARPA by SRI-NIC with TCP; Mon 6 Feb 84 23:13:07-PST Date: 07-Feb-84 05:22:33-UT From: mills@dcn6 Subject: A short story To: tcp-ip@sri-nic Folks, After that bomb I dropped last night, I am hesitant to inflict more pain. With the kind help of Mike Brescia and Eric Rosen we may have found one reason for the hemorrhage of BBN-INOC redirects noted. To tell you true, DCN-GATEWAY may have contributed something to the mayhem itself; however, that is now fixed and swept quietly under the rug. The other problems remain. I have pondered whether sequels to my one-act play serve a useful purpose distributed to the entire tcp-ip list and concluded that the lessons learned may be useful to the implementors in general. Please understand that I am not trying to lob grenades (a few hit me, in fact) or make unneccesarily disparaging remarks. I am trying to good-naturedly flush some of the Bad Packets washing ashore on my island and in the process understand some of the nonsense that can happen in a community such as ours. Today, a short story. The players include a wanderer MIT-TAC (10.2.0.77) who shuffles on and then off the stage causing no lasting impression. The heavies include CMU-GATEWAY (10.2.0.14), who tries to call a friend on Mars (97.128.13.75) every half hour, but DCN-GATEWAY has no wires to that space. COLUMBIA-20 (10.0.0.89), RUTGERS (10.2.0.58) and AIDS-UNIX (10.2.0.56) appear to have DCN-GATEWAY wired in as the way to UMDNET (128.8), but that net has hidden behind a VAX on MILNET since early January, a fact well known to the core gateways. Here is a specimen from the DCN-GATEWAY log (Typ 003 is destination-unreachable, Typ 005 is redirect). Time (UT) 6-7 Feb Typ Cod From To ------------------------------------------------------------ 19:03:26 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [3.3.0.5] 19:13:32 006 ?TRAP-I-ICMP 003 000 [10.2.0.58] -> [128.8.0.4] ... 3 duplicate(s) ... 19:13:50 006 ?TRAP-I-ICMP 003 000 [10.2.0.58] -> [128.8.0.4] 19:15:30 006 ?TRAP-I-ICMP 003 000 [10.0.0.89] -> [128.8.0.4] ... 2 duplicate(s) ... 19:15:39 006 ?TRAP-I-ICMP 003 000 [10.0.0.89] -> [128.8.0.4] 19:15:48 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4] 19:24:14 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 19:24:36 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 19:39:10 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4] 19:55:11 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 19:55:15 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4] 19:55:42 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 20:12:19 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 20:20:03 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4] 20:25:31 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 20:37:44 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4] 20:40:14 006 ?TRAP-I-ICMP 005 000 [10.2.0.77] -> [18.10.0.65] ... 7 duplicate(s) ... 20:40:19 006 ?TRAP-I-ICMP 005 000 [10.2.0.77] -> [18.10.0.65] 20:53:16 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4] 20:55:06 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 20:55:29 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 21:06:31 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4] 21:24:43 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4] 21:25:09 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 21:36:55 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 21:55:16 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 21:55:35 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 22:09:58 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4] 22:20:30 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4] 22:25:29 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 22:25:50 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 22:38:31 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4] 22:55:11 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 22:55:48 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4] 23:05:48 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 23:10:27 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 23:26:19 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4] 23:35:09 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [3.3.0.5] 23:40:24 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] ... 5 duplicate(s) ... 01:28:17 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 01:46:25 006 ?TRAP-I-ICMP 005 000 [10.2.0.56] -> [128.8.0.4] ... 3 duplicate(s) ... 01:49:21 006 ?TRAP-I-ICMP 005 000 [10.2.0.56] -> [128.8.0.4] 02:01:49 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 02:02:11 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 02:20:34 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4] ... 6 duplicate(s) ... 02:22:21 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4] 02:32:45 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] The Protocol Police would probably class these as misdemeanors. Now we add SU-SCORE (10.3.0.11) to COLUMBIA-20 (10.0.0.89) on the list of Firehose Felons. Following is a record of the ICMP source-quench messages sent to SU-SCORE during a recent instance (host 128.5.32.1 is at our back door connected via 9.6-Kbps line). Time (UT) 6 Feb Typ Cod From To ------------------------------------------------------------ 20:02:43 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] ... 21 duplicate(s) ... 20:03:15 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] 20:03:16 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17] 20:03:19 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] ... 9 duplicate(s) ... 20:03:30 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] 20:03:31 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17] 20:03:32 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] ... 17 duplicate(s) ... 20:03:54 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] 20:03:56 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17] 20:03:57 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] ... 8 duplicate(s) ... 20:04:09 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] 20:04:11 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17] 20:04:12 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] ... 19 duplicate(s) ... 20:04:36 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] 20:04:37 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17] 20:04:38 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] ... 12 duplicate(s) ... 20:04:53 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] 20:04:56 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17] 20:04:58 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] ... 20 duplicate(s) ... 20:05:25 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] 20:05:26 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17] 20:05:27 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] ... 9 duplicate(s) ... 20:05:37 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] Note how the TEST3 (10.3.0.63) EGP gateway got trapped in that wash. I was watching the "ready-for-next-bit" light on our ECU during this spasm, from which it was apparent that the IMP was blocked for darn near three minutes. DCN-GATEWAY sends a source-quench when the number of free buffers falls below a threshold (currently two), hopefully before packets have to be dropped. Only a few hosts (fuzzballs among them) actually do something with source-quench. The fuzzballs keep careful track of the number of packets "outstanding" on a TCP connection and enforce an upper limit (currently 8) which is throttled back when a source-quench is received. We have learned that, without these controls we cannot build a stable network of multi-diameter plumbing. The firehose bug illustrated above with SU-SCORE, previously found with COLUMBIA-20 and suspected with several other TOPS-20s (but not those at ISI), could be due to naive retransmission controls or the "runaway-ACK" bug noted previously. From prior experience the culprit is probably the latter, which is known to quickly and completely distroy any gateway in its path. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020705490000> Return-Path: Received: from USC-ISIB.ARPA by SRI-NIC with TCP; Tue 7 Feb 84 13:58:54-PST Date: 7 Feb 1984 13:49-PST Sender: JGOLDBERGER@USC-ISIB Subject: Re: ICMP source quench From: Joel Goldberger To: MRC@SU-SCORE Cc: TCP-IP@SRI-NIC Message-ID: <[USC-ISIB] 7-Feb-84 13:49:58.JGOLDBERGER> In-Reply-To: The message of Tue 7 Feb 84 12:26:35-PST from Mark Crispin ISI has no code to obey Source Quench ICMP msgs. Like most other TCP implementations (as reported at the most recent Internet Research Group Meeting) we simply count their occurance. What ISI does have is a hardened IP/TCP as compared to that offered by DEC, or the older versions of the original BBN code. This is the result of folks like Dave Mills beating up on us to get things right, and Charlie Lynn (of BBN) and Dale Chase (of ISI) attacking specific problems as they have arisen (like the runaway ACKs). We have very extensive monitoring and tracing facilities installed in our system that has been of great help in isolating and correcting many of the problems Dave has uncovered. All of the corrective measures and bugfixes have been returned to BBN, and Charlie Lynn is currently working with DEC to get them all back into the DEC distributed version. As to the gateway questions; this is an issue that I believe was beaten to death recently enough that it should be dropped. BBN is busily at work on improving the general gateway situation through the use of EGP and changes in the core (prime) gateways. There was an announcement at the INRG meeting that dumb gateways would have to implement EGP within the next six months. This will insure that all legitimate gateways can be discovered, which is not the case now. BBN also recognizes the problems of GGP, which is the mechanism that the PRIME gateways use to maintain all their routing information. It simply doesn't work well as the number of gateways increases. As a point of information it was reported at this meeting that GGP amongst the 22 Arpanet and 8 Milnet gateways was responsible for 225K packets/hour. - Joel Goldberger - ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020707515200> Return-Path: Received: from USC-ISID.ARPA by SRI-NIC with TCP; Tue 7 Feb 84 15:58:05-PST Date: 7 Feb 1984 15:51:52 PST From: MILLS@USC-ISID Subject: Re: ICMP source quench To: MRC@SU-SCORE, TCP-IP@SRI-NIC cc: MILLS@USC-ISID In response to the message sent Tue 7 Feb 84 12:26:35-PST from MRC@SU-SCORE.ARPA Mark, I won't comment on the NIC issue. As for the TOPS-20s, I have been beating especially on ISID for as long as there was a TCP (over five years) using my haywire kit of leaky plumbing and know it well. So far as I know it and all other TOPS-20s and VAXen (exception: FORD-WDL1, which was locally massaged) disregard source-quench. It has generally been the case that gateways with a couple of dozen packet buffers can manage pretty well, even with mismatched pipes an order of magnitude apart. This is normally the case with DCN-GATEWAY, which hides perhaps two dozen active hosts behind it, some connected by pipes as low as 1200 bps. However, an especially agile typist can sometimes nudge a TOPS-20 to fill up all the buffers for echoes on the way back to one of these hosts, for example. With FTP and mail things generally go pretty well. The problems I reported are believed to be due to bugs in the host implementations. The "runaway-ACK" problem in particular just breaks everything in sight. Ill-advised TCP retransmission timeouts also break things, but not nearly so badly. I have observed several times today, for example, that hosts trying to send mail to DCN6 (connected via 4.8-Kbps pipe) appear to initialize their trx timeout as low as one second, which is clearly way too low for any path not confined to the ARPANET. It is not clear whether some "correct" implementation of source quench would help avoid the pain of these problems. Bugs of opposite sign seldom cancel. However, a rational response to these messages would certainly improve the behavior of the system, not to mention the host itself. We have argued these points within the ICCB incessantly and have not yet come up with a clearly optimal and architectable recommendation. The experiments with the fuzzballs, both as gateways and hosts, have shown that at least some mechanisms are not difficult to implement and work very well. Unfortunately, the inertia against change, especially in the case of vendor-maintained software, is terrific. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020711183300> Return-Path: Received: from ut-sally.ARPA by SRI-NIC with TCP; Tue 7 Feb 84 15:21:31-PST Date: Tue, 7 Feb 84 17:18:33 cst From: jsq@ut-sally.ARPA (John Quarterman) Posted-Date: Tue, 7 Feb 84 17:18:33 cst Message-Id: <8402072318.AA15504@ut-sally.ARPA> Received: by ut-sally.ARPA (4.22/4.22) id AA15504; Tue, 7 Feb 84 17:18:33 cst To: Mike.Accetta@cmu-cs-ius.ARPA Subject: Re: A short story and Martian Attack on OFFICE-8 Cc: , Barns@ut-sally.ARPA, Bill@ut-sally.ARPA, jsq@ut-sally.ARPA, mills@dcn6.ARPA, tcp-ip@sri-nic.ARPA I'd already notified the appropriate people at ut-ngp (UT Computation Center) before your letter. [97.128.13.75] is ut-ngp's local ethernet address (about time to get a real network number, I'd say), but [97.128.13.72] doesn't seem to correspond to anything (at least on this planet...). ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020711354000> Return-Path: Received: from ut-ngp.ARPA by SRI-NIC with TCP; Tue 7 Feb 84 15:47:43-PST Posted-Date: Tue, 7 Feb 84 17:35:40 CST Message-Id: <8402072345.AA18237@ut-ngp.ARPA> Received: by ut-ngp.ARPA (4.22/3.14) id AA18237; Tue, 7 Feb 84 17:45:30 cst Date: Tue, 7 Feb 84 17:35:40 CST From: Bill Lee To: Mike.Accetta@cmu-cs-ius.ARPA, WWB.TYM@office-2.ARPA Cc: tcp-ip@sri-nic.ARPA Subject: Re: A short story and Martian Attack on OFFICE-8 Ok, we are still alive and looking for the Martians. They seem to be us. In any case, this problem should go away very shortly. We seem to be letting some Ethernet traffic out on the ARPANET in an attempt to find a gateway that knows how to route things. This is especially unfortunate since these packets are coming from an unknown host on an unknown network (at least to the rest of the ARPANET). We will try very hard to prevent this from happening again. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020711423900> Return-Path: Received: from CMU-CS-IUS by SRI-NIC with TCP; Tue 7 Feb 84 13:40:29-PST Date: Tuesday, 7 February 1984 16:42:39 EST From: Mike.Accetta@cmu-cs-ius To: mills@dcn6, Bill Barns cc: tcp-ip@sri-nic Subject: Re: A short story and Martian Attack on OFFICE-8 Message-ID: <1984.2.7.21.18.11.Mike.Accetta@cmu-cs-ius> In-Reply-To: <[OFFICE-2]TYM-WWB-4284U> After some investigation, the Martian attack seems to be originating from host 0 on IMP 62 (UT-NGP). At the moment, CMU-GATEWAY is receiving frequent packets from this IMP port with an IP source address of 97.128.13.72 (somewhere on Mars) and an IP destination address of 128.2.254.132 (CMU-CS-G). CMU-CS-G responds to the connection attempts and routes its replies back to CMU-GATEWAY. CMU-GATEWAY (itself having no direct communication with Mars) then asks a few of its gateway neighbors (including DCN-GATEWAY) if they know they way, yielding the previously described results. Of course, the question of the moment is now: have the Martians left anyone alive in Texas to fight back? - Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020802212600> Return-Path: <@DCN6.ARPA:mills@dcn6> Received: from DCN6.ARPA by SRI-NIC with TCP; Thu 9 Feb 84 10:13:57-PST Date: 08-Feb-84 02:21:26-UT From: mills@dcn6 Subject: Martian chronicles To: tcp-ip@nic Folks, The Martians have just landed at the dcn6 spaceport (25, or smtp, that is). Kamikazegrams are falling every fifteen minutes from 97.128.13.75 spewing unreachable shrapnel all about. The Protocol Police have been roused and horsed, but their numbers are sadly divided while fighting Smany battles under alien Suns. Will the last datagram, source-quenched from our zoo, please turn off the lights? Sadly, I bury our frazzled fuzzballs and resolve to go forth and beat those aliens caught in their Ethernets around their ears with a Valid Network Number. Long live the Czar! Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020806200000> Return-Path: Received: from JPL-VLSI.ARPA by SRI-NIC with TCP; Wed 8 Feb 84 14:27:09-PST Date: 8 Feb 1984 1420 PST From: Eric P. Scott Subject: I see no Martians here To: TCP-IP@SRI-NIC Reply-To: EPS@JPL-VLSI You don't see our "unadvertised" (and potentially conflicting) network addresses courtesy of the Class A logical host chameleon. UT-NGP, is that a viable solution for you? -=EPS=- ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020809264900> Return-Path: Received: from RICE by SRI-NIC with TCP; Wed 8 Feb 84 13:49:25-PST Received: by RICE (AA16965); Wed, 8 Feb 84 15:45:22 cst Received: by RICE-JANUS (AA09298); Wed, 8 Feb 84 15:41:31 cst Date: Wed, 8 Feb 84 15:26:49 CST From: Paul Milazzo Subject: Re: A short story and Martian Attack on OFFICE-8 To: Mike.Accetta@cmu-cs-ius Cc: mills@dcn6, Bill Barns , tcp-ip@sri-nic Message-Id: <1984.02.08.15.26.49.910.09156@Rice-Janus.rice> In-Reply-To: a message from Mike.Accetta dated Tuesday, 7 February 1984 16:42:39 EST A quick glance out the window reveals the Houston skyline still safely in place. Still, Rice periodically repulses a similar attack from the Martians, and I believe I understand the cause. Net 97 is what certain 4.2bsd sites which do not employ ARP use to address Interlan Ethernet boards. The Ethernet interface replaces the "97" with the high 3 bytes of an Interlan Ethernet address (02-07-01), and the remaining 3 class A address bytes become the lower 3 bytes. Thus, [97.128.13.72] corresponds to an Ethernet address of 02-07-01-80-0D-48. This is either the Ethernet board in UT-NGP or a host on UT's local network for which UT-NGP is gatewaying packets. Paul G. Milazzo Dept. of Mathematical Sciences Rice University, Houston, TX ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020900270000> Return-Path: Received: from sri-tsc by SRI-NIC with TCP; Thu 9 Feb 84 08:34:55-PST Date: 9 Feb 1984 at 0827-PST To: TCP-IP@Sri-Nic Cc: bobbi@sri-tsc, dan@sri-tsc Subject: gateways From: bobbi@sri-tsc I've been tasked with determining the availability of a "compact, single-purpose processor" that could be a gateway between an Ethernet LAN and a packet-switching network. The gateway should support the Ethernet, TCP/IP, and Address Resolution protocols on one side and IP and 1822 protocols on the other. I would appreciate any suggestions of vendors and/or contacts who could supply me with product information on gateway hardware and software. Thank you for your help. -Bobbi bobbi@sri-tsc ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020902575000> Return-Path: Received: from USC-ISID.ARPA by SRI-NIC with TCP; Thu 9 Feb 84 11:00:43-PST Date: 9 Feb 1984 10:57:50 PST From: MILLS@USC-ISID Subject: Re: gateways To: bobbi@SRI-TSC, TCP-IP@SRI-NIC cc: dan@SRI-TSC, MILLS@USC-ISID In response to the message sent 9 Feb 1984 at 0827-PST from bobbi@sri-tsc Bobbi, We use LSI-11 "fuzzballs" for general packet-switching jobs in our shop. They support IP, 1822, HDH, GGP, EGP and 17 different hardware devices, including Interlan and 3COM Ethernets, as well as several kinds of SRI and ACC ARPANET gizmos. We happen to use then with various kinds of disks, since we tend to load miscellaneous application- level stuff into them. Others, including Paal Spilling at NTARE, are using them in the diskless configuration for the same application as you describe. If you need further informationk please see the file DCNET.DOC in the MILLS directory at ISID. You should contact me directly for further correspondence, rather than copy everybody in this group. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020904451000> Return-Path: Received: from ut-sally.ARPA by SRI-NIC with TCP; Thu 9 Feb 84 08:48:04-PST Date: Thu, 9 Feb 84 10:45:10 cst From: jsq@ut-sally.ARPA (John Quarterman) Posted-Date: Thu, 9 Feb 84 10:45:10 cst Message-Id: <8402091645.AA12900@ut-sally.ARPA> Received: by ut-sally.ARPA (4.22/4.22) id AA12900; Thu, 9 Feb 84 10:45:10 cst To: tcp-ip@sri-nic.ARPA Subject: Martians Beaten Back / Networks Sigh in Common Relief Cc: clyde@ut-ngp.ARPA, jsq@ut-sally.ARPA, lee@ut-ngp.ARPA, smoot@ut-sally.ARPA Checking the backlog of TCP-IP list messages, I see nobody else has announced the problem has been fixed, and there seems to still be interest, so here's an announcement: From jsq Thu Feb 9 10:29:42 1984 Date: Thu, 9 Feb 84 10:28:53 cst From: jsq (John Quarterman) Posted-Date: Thu, 9 Feb 84 10:28:53 cst Received-Date: Thu, 9 Feb 84 10:28:53 cst Message-Id: <8402091628.AA12662@ut-sally.ARPA> Received: by ut-sally.ARPA (4.22/4.22) id AA12662; Thu, 9 Feb 84 10:28:53 cst To: brescia@BBN-UNIX Subject: Re: Have you been getting these mail exchanges? Cc: clyde@ut-ngp, jsq, smoot Yes. I threw in my two bits on the TCP-IP list a couple of times. It seems the folks at ut-ngp configured their Interlan board before their ACC IMP in their 4.2BSD kernel configuration file. The effects of this are actually documented in "Installing and Operating 4.2BSD," but it's easy to overlook that paragraph.... Anyway, the wormhole the Martians came through has evidently been closed. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984020907512500> Return-Path: Received: from bbnccq by SRI-NIC with TCP; Thu 9 Feb 84 10:08:27-PST Date: Thu, 9 Feb 84 12:51:25 EST From: Jonathan Dreyer Subject: Re: gateways In-Reply-To: Your message of 9 Feb 1984 at 0827-PST To: bobbi@sri-tsc Cc: TCP-IP@Sri-Nic, dan@sri-tsc The BBN gateways currently support both Ethernet with ARP and 1822, and we have a few operational gateways with both an Ether leg and an 1822 leg. The gateway runs on LSI-11s with Interlan Ethernet boards and ACC 1822 boards. These are IP gateways; any encapsulated TCP information is passed transparently. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984021005430000> Return-Path: Received: from RADC-MULTICS.ARPA by SRI-NIC with TCP; Fri 10 Feb 84 07:46:10-PST Date: 10 February 1984 10:43 est From: Ata.SysMaint at RADC-MULTICS Subject: Re: FTP implementation questions To: Mark Crispin cc: TCP-IP at SRI-NIC, Ata.SysMaint at RADC-MULTICS In-Reply-To: Message of 30 January 1984 08:45 est from Mark Crispin Date: Fri 27 Jan 84 20:44:00-PST From: Mark Crispin Subject: FTP implementation questions I have the following questions for the Internet community regarding FTP. Instead of hearing a chorus of "no"s I would rather just hear from those who can answer "yes" to any or all of the following questions: Answers are for the Multics FTP server. . Does your FTP implementation implement TYPE L with bytesizes OTHER than 8, 32, or 36? If so, is it useful or necessary to transfer with such a bytesize? Yes, we support a logical bytesize of 9 only with the type L. This is to support the native bytesize of 9. Processing is like type I. Where one would use TYPE L 9 instead of type I (to the Multics FTP server) is hypothetically possible, but doubtful in reality. . Would you consider as deficient an FTP implementation which did not support a TYPE L bytesize other than 8, 32, or 36? Would a useful data transfer be prevented by this deficiency? Give examples. I would think that most machines would support a logical bytesize based on their hardware's native bytesize regardless of whether it is 8,32, or 36. . The current FTP standard does not define the 0xx FTP reply codes the way the previous one did. Do you feel that an FTP server should be prevented from issuing any unsolicited or "irrelevant" replies, or that it is alright to continue to use a 0xx FTP reply code? What will your FTP user software do when it encounters a 0xx reply code (I feel that the "right thing" is to ignore it, optionally printing it on the user's terminal). In my opinion, FTP reply codes of the 0xx flavor are illegal and should never be sent. All system messages (unsolicited) should be sent without reply codes as per RFC 765 page 33. However on some systems (Multics is one culprit, I admit) these spontaneous messages are buried whithin the operating system code with the old 0xx reply format and are hard to dispose of. Therfore, it is not unreasonable for a user FTP to print the message on the user terminal, otherwise ignoring it. . Consider an FTP implementation where the REIN command is not implemented and you cannot change your USER once you have logged in. Suppose this implementation allows an unlogged-in RETR by doing an implicit login of ANONYMOUS (the special account which allows retrieval of public-access files). Should the FTP implementation announce the auto-login? If 0xx codes are allowed, 030 is the obvious code. If 0xx is not allowed, what would you consider valid for it to use to announce the auto-login (remember, this will prevent a login as something else). If the auto-login anouncemnet is unsolicited, then no reply code should precede it. . Does your FTP user process change the port after each data transfer in Stream mode? Yes, otherwise you may be prevented from doing further file transfers for a while. This is caused by some data connections taking over a minute to fully close. . Does your FTP user process implement a mode other than Stream mode? If so, which? Yes, we implement block mode also. The latest version should work properly. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984021104312800> Return-Path: Received: from SU-SCORE.ARPA by SRI-NIC with TCP; Sat 11 Feb 84 12:34:41-PST Date: Sat 11 Feb 84 12:31:28-PST From: Mark Crispin Subject: Re: Another nastygram report To: Mills@DCN6.ARPA cc: TCP-IP@SRI-NIC.ARPA In-Reply-To: Message from "Mills@dcn6" of Sat 11 Feb 84 09:28:46-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) As of sometime in the evening of 8 February, SU-SCORE has *all* the BBN/ISI fixes for "runaway ACK" as passed to me. Any instances of runaway ACK after that time (let's say starting from 9 February) would be a different bug. I think we would all appreciate hearing if the fixes at SU-SCORE so far have fixed the problem, because if they haven't, further investigation by all parties is required. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984021114592500> Return-Path: Received: from RUTGERS.ARPA by SRI-NIC with TCP; Sat 11 Feb 84 17:02:53-PST Date: 11 Feb 84 19:59:25 EST From: Charles Hedrick Subject: Re: Another nastygram report To: Mills@DCN6.ARPA cc: TCP-IP@SRI-NIC.ARPA In-Reply-To: Message from "Mills@dcn6" of 17 Nov 1858 13:01:42 EST I just looked at our INTERNET.GATEWAYS. It does not list 128 8 or 128 4. This suggests that some other gateway is telling us to use DCN-GATEWAY. Unfortunately we don't log ICMP level transactions, so I am unable to tell what is going on. However if Tops-20 does what it is supposed to do, there aren't a lot of candidates. The only gateways we list as PRIME are DCEC-MILNET-GW ARPA-MILNET-GW BBN-CRONUS-GW These are our assigned primary and alternate Milnet gateway, and a randomly chosen BBN-operated gateway. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984021115352300> Return-Path: <@DCN6.ARPA:Mills@dcn6> Received: from DCN6.ARPA by SRI-NIC with TCP; Sat 11 Feb 84 08:38:25-PST Date: 11-Feb-84 15:35:23-UT From: Mills@dcn6 Subject: Another nastygram report To: TCP-IP@nic Folks, The Nastygram Novellas continue. Today's hit list includes: 10.0.0.15 ROCHESTER 10.0.0.51 SRI-NIC 10.0.0.89 COLUMBIA-20 10.1.0.31 CCA-VMS 10.1.0.72 BBN-UNIX 10.2.0.14 CMU-GATEWAY 10.2.0.52 USC-ISIF 10.2.0.56 AIDS-UNIX 10.2.0.58 RUTGERS 10.2.0.77 MIT-MC 10.2.0.82 BBN-INOC 10.3.0.11 SU-SCORE 10.3.0.44 MIT-MC 10.3.0.63 BBN-TEST3 10.4.0.2 SRI-AI 10.5.0.2 SRI-IU 128.32.0.11 UCBKIM 14.0.0.12 RICE 18.26.0.37 MIT smallfry The following data were collected in the DCN-GATEWAY log over the two-day period from about 20:00:00 Feb 8 to 20:0:0 Feb 10. This time I sorted the log by host, so that I could call out the problems more easily. Note that this scrambles the time relationships, so that you can't easily tell the times of the events during the ... duplicate(s) ... periods. Remember, ICMP 003 is destination-unreachable, ICMP 004 is source-quench and ICMP 005 is redirect. The addresses refer to those in the original datagram, not the ICMP itself, which is sent to the first address. During this period the BBN test EGP gateway appeared brain-damaged, so I reactivated our GGP and peered with MILARP. Thus, one would expect spasms as the GGP system counted to infinity when some net or gateway died. During such spasms one would also expect redirects to flail about, probably accounting for some of the mischief recorded below. The annotated script follows. 10.0.0.15 ROCHESTER This guy may have old gateway tables. Net 128.8 (UMDNET) is reachable now only via a dumb gateway on MILNET, but used to be reached via DCN-GATEWAY. 00:41:13 006 ?TRAP-I-ICMP 005 000 [10.0.0.15] -> [128.8.0.4] 10.0.0.51 SRI-NIC Only one source-quench returned to this guy, so probably not significant. 23:00:41 006 ?TRAP-I-ICMP 004 000 [10.0.0.51] -> [128.5.33.1] 10.0.0.89 COLUMBIA-20 Multiple offenses. Evidence of runaway-ACK in the first spasm, old gateway tables for net 128.8 in the rest. 00:52:01 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] ... 67 duplicate(s) ... 23:25:31 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] 16:54:05 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.11] 00:55:00 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] ... 71 duplicate(s) ... 23:59:14 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 00:15:07 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4] ... 61 duplicate(s) ... 19:05:41 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4] 19:15:30 006 ?TRAP-I-ICMP 003 000 [10.0.0.89] -> [128.8.0.4] ... 2 duplicate(s) ... 19:15:39 006 ?TRAP-I-ICMP 003 000 [10.0.0.89] -> [128.8.0.4] 19:15:48 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4] ... 16 duplicate(s) ... 23:42:29 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4] 10.1.0.31 CCA-VMS (Is this guy running Access-T?) Possible old tables for 128.8. 02:53:41 006 ?TRAP-I-ICMP 005 000 [10.1.0.31] -> [128.8.0.8] 10.1.0.72 BBN-UNIX Another 128.8 problem. This is a known good player, which leads me to believe this particular microspasm may have been the result of a counting-to-infinity glitch. 22:55:49 006 ?TRAP-I-ICMP 005 000 [10.1.0.72] -> [128.8.0.4] 22:55:50 006 ?TRAP-I-ICMP 005 000 [10.1.0.72] -> [128.8.0.4] 10.2.0.14 CMU-GATEWAY Note the kamikazegrams to nets 0, 77 and 97, some of them persistent. The Martians have apparently not been blown away yet. The remainder suggest trouble with redirects during counting-to-infinity spasms. Note, this gateway is ALWAYS-UP according to the NIC tables. 02:20:50 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [0.0.0.0] 16:22:57 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [0.0.0.0] 22:06:06 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [128.31.41.120] ... 4 duplicate(s) ... 22:09:22 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [128.31.41.120] 14:37:03 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [128.34.251.1] 04:31:58 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [14.0.0.12] 21:46:43 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [192.5.15.5] 22:02:04 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [192.5.15.5] 04:23:32 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [192.5.21.6] ... 3 duplicate(s) ... 22:16:26 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [192.5.21.6] 17:41:46 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [192.5.36.5] 20:00:09 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [26.0.0.14] 05:41:50 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [26.1.0.34] 00:15:32 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [3.1.0.5] ... 18 duplicate(s) ... 22:51:29 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [3.1.0.5] 00:33:57 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [3.3.0.5] ... 20 duplicate(s) ... 23:35:09 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [3.3.0.5] 05:21:53 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [36.40.0.205] 16:20:49 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [36.40.0.205] 22:25:36 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [77.45.0.2] 22:05:26 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [8.0.0.7] 00:06:33 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] ... 122 duplicate(s) ... 23:58:32 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.13.75] 10.2.0.52 USC-ISIF Known good player apparently mildly annoyed by network glitches. Not believed significant. 21:19:08 006 ?TRAP-I-ICMP 003 000 [10.2.0.52] -> [128.9.0.47] ... 7 duplicate(s) ... 21:24:09 006 ?TRAP-I-ICMP 003 000 [10.2.0.52] -> [128.9.0.47] 21:15:31 006 ?TRAP-I-ICMP 005 000 [10.2.0.52] -> [128.9.0.48] ... 18 duplicate(s) ... 21:15:34 006 ?TRAP-I-ICMP 005 000 [10.2.0.52] -> [128.9.0.48] 21:17:31 006 ?TRAP-I-ICMP 003 000 [10.2.0.52] -> [128.9.0.48] ... 5 duplicate(s) ... 21:27:32 006 ?TRAP-I-ICMP 003 000 [10.2.0.52] -> [128.9.0.48] 10.2.0.56 AIDS-UNIX Old tables? 01:46:25 006 ?TRAP-I-ICMP 005 000 [10.2.0.56] -> [128.8.0.4] ... 8 duplicate(s) ... 23:11:17 006 ?TRAP-I-ICMP 005 000 [10.2.0.56] -> [128.8.0.4] 10.2.0.58 RUTGERS Fuzzy 128.4.0.2 has been hiding for some time now. Maybe somebody here tried to pet it. Also, suspected old 128.8 tables. 06:03:03 006 ?TRAP-I-ICMP 003 001 [10.2.0.58] -> [128.4.0.2] ... 3 duplicate(s) ... 06:03:20 006 ?TRAP-I-ICMP 003 001 [10.2.0.58] -> [128.4.0.2] 00:00:58 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4] ... 48 duplicate(s) ... 18:53:10 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4] 19:13:32 006 ?TRAP-I-ICMP 003 000 [10.2.0.58] -> [128.8.0.4] ... 3 duplicate(s) ... 19:13:50 006 ?TRAP-I-ICMP 003 000 [10.2.0.58] -> [128.8.0.4] 19:23:51 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4] ... 14 duplicate(s) ... 23:32:23 006 ?TRAP-I-ICMP 005 000 [10.2.0.58] -> [128.8.0.4] 10.2.0.77 MIT-MC Redirects probably resulting from spasm not believed significant. 20:40:14 006 ?TRAP-I-ICMP 005 000 [10.2.0.77] -> [18.10.0.65] ... 7 duplicate(s) ... 20:40:19 006 ?TRAP-I-ICMP 005 000 [10.2.0.77] -> [18.10.0.65] 10.2.0.82 BBN-INOC This is a very frisky host, as noted on previous occasions. Note the spasm beginning about 20:16, indicating something big broke about then. That may account for many of the redirects reported to other hosts. The data are sorted the wrong way to correlate properly, however. 20:34:07 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [128.16.3.0] ... 7 duplicate(s) ... 20:34:09 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [128.16.3.0] 08:54:29 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [128.39.0.1] ... 15 duplicate(s) ... 08:57:32 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [128.39.0.1] 09:00:29 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [128.39.0.1] ... 2 duplicate(s) ... 09:06:30 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [128.39.0.1] 20:16:10 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [128.39.0.1] ... 15 duplicate(s) ... 20:19:13 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [128.39.0.1] 20:22:10 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [128.39.0.1] ... 2 duplicate(s) ... 20:28:18 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [128.39.0.1] 21:15:11 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [128.9.0.81] ... 32 duplicate(s) ... 21:15:46 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [128.9.0.81] 20:16:11 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [192.5.29.1] ... 15 duplicate(s) ... 20:19:14 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [192.5.29.1] 20:22:11 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [192.5.29.1] ... 2 duplicate(s) ... 20:28:18 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [192.5.29.1] 08:53:07 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [192.5.46.4] ... 40 duplicate(s) ... 20:19:13 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [192.5.46.4] 20:22:10 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [192.5.46.4] ... 2 duplicate(s) ... 20:28:18 006 ?TRAP-I-ICMP 003 000 [10.2.0.82] -> [192.5.46.4] 20:34:14 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [32.3.0.42] ... 7 duplicate(s) ... 20:34:15 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [32.3.0.42] 20:33:06 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [35.7.0.0] ... 7 duplicate(s) ... 20:33:07 006 ?TRAP-I-ICMP 005 000 [10.2.0.82] -> [35.7.0.0] 10.3.0.11 SU-SCORE Classic indications of the runaway-ACK problem, probably at least two occasions. 02:07:38 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] ... 151 duplicate(s) ... 23:31:20 006 ?TRAP-I-ICMP 004 000 [10.3.0.11] -> [128.5.32.1] 10.3.0.44 MIT-MC Our backdoor customer on FORDNET probably went belly-up for a couple of minutes. Not significant. 20:01:49 006 ?TRAP-I-ICMP 003 001 [10.3.0.44] -> [128.5.32.1] ... 4 duplicate(s) ... 20:02:03 006 ?TRAP-I-ICMP 003 001 [10.3.0.44] -> [128.5.32.1] 10.3.0.63 BBN-TEST3 This is our EGP peer, which gets knocked with source-quench when some other player, probably suffering from the runaway-ACK bug, hammers on DCN-GATEWAY. The times suggest the bad guys are COLUMBIA-20 and SU-SCORE. 02:08:24 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17] ... 11 duplicate(s) ... 23:20:24 006 ?TRAP-I-ICMP 004 000 [10.3.0.63] -> [10.3.0.17] 10.4.0.2 SRI-AI Old tables? 17:53:49 006 ?TRAP-I-ICMP 005 000 [10.4.0.2] -> [128.8.0.4] ... 2 duplicate(s) ... 19:03:25 006 ?TRAP-I-ICMP 005 000 [10.4.0.2] -> [128.8.0.4] 10.5.0.2 SRI-IU Old tables? 01:56:08 006 ?TRAP-I-ICMP 005 000 [10.5.0.2] -> [128.8.0.10] 128.32.0.11 UCBKIM This would seem to be a runaway-ACK problem; however, this is a VAX, leading me to suspect a retransmission-timeout problem (set way too short). My intelligence reports this to be a known problem with the 4.2 distribution. 21:54:11 006 ?TRAP-I-ICMP 004 000 [128.32.0.11] -> [128.5.32.1] ... 124 duplicate(s) ... 23:45:20 006 ?TRAP-I-ICMP 004 000 [128.32.0.11] -> [128.5.32.1] 14.0.0.12 RICE Trying to pet a fuzzy too briskly. Probably not significant. 22:00:51 006 ?TRAP-I-ICMP 004 000 [14.0.0.12] -> [128.4.0.6] 18.26.0.37 MIT smallfry IBM PC at MIT. These mutts are known to read the DCN-GATEWAY clock frequently. This one probably got surprised by a source-quench in response to the UDP request because somebody else was beating (runaway ACK?) on the gateway! 23:20:07 006 ?TRAP-I-ICMP 004 000 [18.26.0.37] -> [128.4.0.1] 23:20:09 006 ?TRAP-I-ICMP 004 000 [18.26.0.37] -> [128.4.0.1] Lessons learned deptartment: 1. The runaway-ACK problem continues to spasmatize the gateway system. At least two TOPS-20 hosts, COLUMBIA-20 and SU-SCORE, appear to have this bug, which apparently has been identified and fixed by the ISI system staff. 2. There is some evidence that the 4.2 distribution may have (initial) TCP retransmission timeouts set way too low. We have found five seconds to be a reasonable compromise for use over almost any existing path (see RFC889). 3. Implementors should expect source-quench in just about any situation, even using low-rate datagram protocols like UDP and EGP, and even when the sender is not at fault. When using TCP, the appropriate behavior in the case of one-way transmissions when the receiver gets one of these in response to an ACK it sent is an interesting case (should it shrink the window?). 4. The dumb-gateway table inertia seems uncomfortably high. The rash of misrouted net-128.8 traffic above (and the relatively minor level of misrouted traffic for other nets) suggests problems with old or conflicting table information. Net 128.8 is one of the nets advertised by DCN-GATEWAY in the GATEWAY portion of the NIC tables as reachable via that gateway. However, at least for the present, net 128.8 is wired in the core system as reachable via a dumb gateway (MARYLAND) on MILNET. However, DCN-GATEWAY does not currently advertise itself as a path to that net, either in EGP or GGP. I suspect that some of the dumb gateways on ARPANET may have wired in the old path and are failing to utilize redirect information. I suspect this problem may be happening elsewhere in the system. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984021202031700> Return-Path: <@DCN6.ARPA:mills@dcn6> Received: from DCN6.ARPA by SRI-NIC with TCP; Sat 11 Feb 84 18:07:12-PST Date: 12-Feb-84 02:03:17-UT From: mills@dcn6 Subject: Re: Another nastygram report To: CharlesHedrick, Mills@DCN6.ARPA, TCP-IP@SRI-NIC.ARPA In-reply-to: Your message of 11 Feb 84 19:59:25 EST Charles, Thanks for the info. The detective hunt continues. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984021222092200> Return-Path: <@DCN6.ARPA:Mills@dcn6> Received: from DCN6.ARPA by SRI-NIC with TCP; Sun 12 Feb 84 14:17:06-PST Date: 12-Feb-84 22:09:22-UT From: Mills@dcn6 Subject: Gateway system performance To: TCP-IP@nic Folks, As long as I have been banging on gateway issues, you might be interested in a capsule evaluation of how well the existing system works and how it has improved over the last several months. Following is an extract of gateway traffic information collected on a weekly basis by Eric Rosen of BBN. .. Searching from Mon Jan 30 00:02:12 1984 until Sun Feb 5 23:59:59 1984 (EST) A total of 19295 throughput messages were received from 30 gateways GWY GWY RCVD RCVD IP % IP DEST % DST NO. NAME DGRAMS BYTES ERRORS ERRORS UNRCH UNRCH TOTALS 79,068,588 3,748,292,651 22,989 0.03% 329,104 0.42% GWY GWY SENT SENT DROPPED % DROPPED NO. NAME DGRAMS BYTES DGRAMS DGRAMS TOTALS 80,874,600 3,977,797,017 485,184 0.60% 60.90% of all received packets are addressed to a gateway 62.61% of all sent packets originate at a gateway 57.56% of all sent packets are forwarded to another gateway .. Last August I analyzed similar data on 19 gateways in order to determine the protocol overhead and effectiveness of the system. The result was pretty dismal, showing that, of the traffic transiting the gateway system, less than one packet in five represented real user data and almost half the packets were misrouted. Following is a more detailed summary of these results. Note that all values have been normalized on a per-gateway, per-hour packet basis. (I'll describe the assumptions and methods for calculation separately if there is sufficient interest.) Totals - received 11591 sent 12406 difference 815 Received addressed to a gateway 8345 to a host 3246 Sent originating at a gateway 9304 at a host 3102 Sent forwarded to another gateway 7567 to a host 4839 Redirects sent to hosts 959 GGP pings sent/received 6608 Host pings sent/recieved 1737 Host traffic received 2287 Host traffic sent 2143 Efficiency .197 Misroutes .419 Last week I analyzed the data shown at the beginning of this message and obtained the following reults: Totals - received 15674 sent 16051 difference 377 Received addressed to a gateway 9545 to a host 6129 Sent originating at a gateway 10047 at a host 6004 Sent forwarded to another gateway 9245 to a host 6806 Redirects sent to hosts 502 GGP pings sent/received 8743 Host pings sent/recieved 802 Host traffic received 5627 Host traffic sent 5502 Efficiency .359 Misroutes .089 In spite of the growth from 19 to 30 gateways, more than one packet in three is real user data and less than one packet in ten is misrouted. A casual inspection of the data reveals three reasons for the improvement in performance: 1. Host pinging has diminished. 2. Hosts are paying closer attention to redirects. 3. Host traffic has grown faster than GGP traffic. The principal reason for the low efficiency is the overhead due to the gateways pinging each other, which is hardly news to anybody. However, many of the 30 GGP gateways now in the core system are used to splice relatively low-traffic local nets to the ARPANET and could be converted to EGP without significant loss of service. This would dramatically reduce the pinging din, as well as reduce the impact of up/down spasms. We could even split the core into two or more cliques of gateways, each running GGP between themselves and connected to the others by EGP. Since the deployment of "operational" EGP gateways is now being discussed, I suggest an interesting experiment might be to set up and test this idea. DCN-GATEWAY is in fact set up and instrumented to do this. The test would involve merely configuring one or more existing GGP gateways to include only each other and DCN-GATEWAY in their neighbor tables. DCN-GATEWAY would then boogie with them using either GGP or EGP and with the rest of the world using EGP and the core system. In principle, this idea would work with the operational EGP gateways as well. If there is interest in such a test, please contact me directly. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984021303394300> Return-Path: Received: from SU-SCORE.ARPA by SRI-NIC with TCP; Mon 13 Feb 84 11:44:49-PST Date: Mon 13 Feb 84 11:39:43-PST From: Mark Crispin Subject: Re: TOPS-20 FTP server To: Hornig%SCRC-QUABBIN@MIT-MC.ARPA cc: tcp-ip@SRI-NIC.ARPA, bug-ftpser@MIT-XX.ARPA, lispm-networks%SCRC-TENEX@MIT-MC.ARPA In-Reply-To: Message from "Charles Hornig " of Mon 13 Feb 84 06:28:43-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) If it makes anyone feel any better, I am finishing a rewrite of the TOPS-20 FTP server which I am confident won't have this problem. However, since it uses the DEC system call interface (the primary reason for the rewrite), I fear the old FTP server won't go away for a very long time. It took Tenex TELNET several years to go away on TOPS-20. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984021304260000> Return-Path: Received: from MIT-XX by SRI-NIC with TCP; Mon 13 Feb 84 06:31:01-PST Received: from SCRC-MERRIMACK by SCRC-QUABBIN with CHAOS; Mon 13-Feb-84 09:20:20-EST Date: Mon, 13 Feb 84 09:26 EST From: Charles Hornig Subject: TOPS-20 FTP server To: tcp-ip@SRI-NIC.ARPA Cc: bug-ftpser@MIT-XX.ARPA, lispm-networks%SCRC-TENEX@MIT-MC.ARPA Message-ID: <840213092628.4.Hornig@QUABBIN.SCRC.Symbolics> I have run into a consistent problem talking to Internet TOPS-20 FTP servers from hosts on our local network. All of the ones I've tried (SRI-NIC, MIT-XX, ISIE, ECLB) do not respond to "USER ANONYMOUS" when the machine connecting is NOT in the NIC host table. When it is in the host table, everything works fine. In particular, it happened this morning connecting to SRI-NIC from SCRC-MERRIMACK (192.10.41.80) but not from SCRC-RIVERSIDE (192.10.41.21). Does anyone have any ideas on how to deal with this? Do I have to put all of our hosts in the NIC table? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984021402323600> Return-Path: Received: from aerospace.ARPA by SRI-NIC with TCP; Tue 14 Feb 84 10:37:27-PST Date: Tue, 14 Feb 84 10:32:36 PST From: Andy Sills To: TCP-IP@SRI-NIC, TCP-IP@BRL CC: perillo@SRI-NIC Subject: TCP/IP Implementation for RSX-11/M TWIMC: I would like to know how many users running RSX-11/M would be interested in getting a TCP/IP implementation for their machines? The key to doing this is a board that plugs into the Unibus and creates a virtual IBM PC running MS-DOS. The software and hardware associated with this board create the connection between the virtual file structure of RSX and the host file structure of the PC. Tasks started under this program appear to be running on a PC even though they are under RSX. Here's the trick. If there really were a PC, there would be an Ethernet board plugged into the mother board, and TCP/IP code that already exists and would talk to that board. In an RSX machine, there would be an Ethernet board for networking, AND this virtual PC emulator board. What remains to be done is to write the code for having the virtual PC talk to the RSX machine's Ethernet board as if that board were actually mounted in a real PC. This job can be done as a special project (very expensive) or as a developed product by a comnpany that is willing to try. They would like to assess the interest of the RSX community. Aerospace has two users interested. Are there any others? Please reply to sills@AEROSPACE if you are. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984021405441600> Return-Path: Received: from USC-ISID.ARPA by SRI-NIC with TCP; Tue 14 Feb 84 13:49:41-PST Date: 14 Feb 1984 13:44:16 PST From: MILLS@USC-ISID Subject: Re: TCP/IP Implementation for RSX-11/M To: sills@AEROSPACE, TCP-IP@SRI-NIC, TCP-IP@BRL cc: perillo@SRI-NIC, MILLS@USC-ISID In response to the message sent Tue, 14 Feb 84 10:32:36 PST from sills@AEROSPACE Folks, While this appears to be an exotic and wonderful can of worms, there is at least one alternative. COMSAT is distributing IP/TCP code that runs under RSX to support the international INTELPOST electronic-mail network. The code happens to be a spinoff of the infamous Fuzzball code used here for Internet research for some years. Further information from Dave Jupin at COMSAT Laboratories (301) 428-4571. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984021406000000> Return-Path: Received: from SRI-KL.ARPA by SRI-NIC with TCP; Tue 14 Feb 84 14:03:53-PST Date: 14 Feb 1984 14:00-PST Sender: BILLW@SRI-KL Subject: Re: TCP/IP Implementation for RSX-11/M From: BILLW@SRI-KL To: sills@AEROSPACE Cc: TCP-IP@SRI-NIC, TCP-IP@BRL, perillo@SRI-NIC Message-ID: <[SRI-KL]14-Feb-84 14:00:52.BILLW> In-Reply-To: The message of Tue, 14 Feb 84 10:32:36 PST from Andy Sills Well, there is a company ("ExceLAN", San Jose), who manufatcures an ethernet board with an onboard 8088 processor and TCP/IP software. All I have around is a blurb on their multibus board, But I think they also have a unibus version. I dont know anything else about the product: their phone number is 408 945-9526 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984021406500000> Return-Path: Received: from BBNA.ARPA by SRI-NIC with TCP; Tue 14 Feb 84 08:56:11-PST Date: 14 Feb 1984 11:50-EST Sender: CLYNN@BBNA Subject: Re: TOPS-20 FTP server From: CLYNN@BBNA To: Hornig%SCRC-QUABBIN@MIT-MC Cc: tcp-ip@SRI-NIC, bug-ftpser@MIT-XX Cc: lispm-networks%SCRC-TENEX@MIT-MC Message-ID: <[BBNA]14-Feb-84 11:50:55.CLYNN> In-Reply-To: <840213092628.4.Hornig@QUABBIN.SCRC.Symbolics> I tried to repeat your problem by logging into SRI-NIC, MIT-XX, and ISIE from one of the BBN terminal concentrators (which are not listed in the NIC's host tables). They all accepted the USER ANONYMOUS, PASS ... sequence. What are we doing differently? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984021420433500> Return-Path: Received: from BRL-VGR by SRI-NIC with TCP; Fri 17 Feb 84 04:17:41-PST Date: Wed, 15 Feb 84 1:43:35 EST From: Ron Natalie To: Andy Sills cc: TCP-IP@sri-nic, TCP-IP@brl, perillo@sri-nic Subject: Re: TCP/IP Implementation for RSX-11/M Putting TCP/IP on RSX-11M is a good idea. Your suggestion on how to do it is a little bazaar. IBM-PC's are hardly an effective network interface. If you've already got an ethernet or IMP interface for your Machine, why not just implement the TCP/IP directly on the PDP-11 (this is practical if you are using one of the larger 11's eg. 44,45,55,70). Try contacting my former employer, Martin Marritta. They seem to have FTP and TELNET at least on their RSX machines (MARTIN and MARTIN-ED). Also a few other hosts including NRL-ARCTAN and NSWC-DL claim to be up with TCP on RSX. These are 11/40's. All the RSX signons I've seen say "SAMNET" if that's any help. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984021420462700> Return-Path: Received: from BRL-VGR by SRI-NIC with TCP; Fri 17 Feb 84 04:17:51-PST Date: Wed, 15 Feb 84 1:46:27 EST From: Ron Natalie To: BILLW@sri-kl cc: sills@aerospace, TCP-IP@sri-nic, TCP-IP@brl, perillo@sri-nic Subject: Re: TCP/IP Implementation for RSX-11/M The EXCELAN people seem to have a very nice implementation of TCP on their board. Unfortunately we are still waiting for the UNIBUS board to be announced although they claim it is in the work. We are looking forward to using the EXCELAN's on our smaller machines (23's and 34's). It's got a really nice interface. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984021503064600> Return-Path: <@DCN6.ARPA:Mills@dcn6> Received: from DCN6.ARPA by SRI-NIC with TCP; Tue 14 Feb 84 19:09:22-PST Date: 15-Feb-84 03:06:46-UT From: Mills@dcn6 Subject: The babble diminishes To: TCP-IP@nic Folks, Digging in the muck is paying off - the trash heap continues to diminish. After discussions with individual implementors and fixes kindly supplied by ISI and BBN, the primary law-benders mentioned in my previous messages have been fixed. Like smallpox, the excitement now is to try to kill all the beasties off. The following hosts are suspected of some traffic violations still, although the wholesale destruction which prompted my recent messages has tapered off a lot. SRI-NIC: suspect runaway-ACK 15:59:23 006 ?TRAP-I-ICMP 004 000 [10.0.0.51] -> [128.5.32.1] ... 44 duplicate(s) ... 16:24:53 006 ?TRAP-I-ICMP 004 000 [10.0.0.51] -> [128.5.32.1] 00:56:07 006 ?TRAP-I-ICMP 004 000 [10.0.0.51] -> [128.5.33.1] 00:56:08 006 ?TRAP-I-ICMP 004 000 [10.0.0.51] -> [128.5.33.1] COLUMBIA-20: excessive source quench 01:55:25 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] ... 4 duplicate(s) ... 19:01:23 006 ?TRAP-I-ICMP 004 000 [10.0.0.89] -> [128.5.32.1] COLUMBIA-20: excessive redirects for net 128.8 00:13:28 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] ... 50 duplicate(s) ... 23:43:27 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.2] 00:01:48 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4] ... 45 duplicate(s) ... 23:03:21 006 ?TRAP-I-ICMP 005 000 [10.0.0.89] -> [128.8.0.4] CMU-GATEWAY: excessive misroutes 14:25:39 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [128.42.1.1] 00:06:19 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [128.42.1.6] ... 2 duplicate(s) ... 21:25:03 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [128.42.1.6] 18:31:49 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [128.7.0.1] 00:13:30 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [14.0.0.12] 16:50:48 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [192.5.19.1] 16:51:01 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [192.5.21.4] 16:49:13 006 ?TRAP-I-ICMP 005 000 [10.2.0.14] -> [26.7.0.50] 01:28:32 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [3.1.0.5] ... 7 duplicate(s) ... 19:30:24 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [3.1.0.5] CMU-GATEWAY: Martian attacks 17:21:52 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [1.128.2.251] 15:41:46 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [19.0.0.0] 16:09:15 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.11.194] ... 2 duplicate(s) ... 16:17:19 006 ?TRAP-I-ICMP 003 000 [10.2.0.14] -> [97.128.11.194] The log scanned is for something over two days and has been culled to remove the occasional redirect or unreachable for J. Random Host. If this is evidence for similar behavior throughout the gateway system, things may be in much better shape than I first feared. Unless the situation deteriorates I will shut my mouth in this forum and go beat up the individual hosts directly. Charlie Lynn's recent fix for the TOPS-20 "window whapper," in which arriving TCP segments overrun the receiver window, almost exhausts my encrustated punch list of outstanding performance-related issues. The list still contains apparent connection-close problems noted at MIT-MULTICS, as well as known TOPS-20 FTP server connection-close problems and suspected 4.2 initial TCP timeout problems. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984021509010000> Return-Path: Received: from CISL-SERVICE-MULTICS.ARPA by SRI-NIC with TCP; Wed 15 Feb 84 11:33:37-PST Date: Wed, 15 Feb 84 14:01 EST From: "Benson I. Margulies" Subject: martians indeed To: tcp-ip@SRI-NIC.ARPA Message-ID: <840215190112.471281@CISL-SERVICE-MULTICS.ARPA> Who will fix the "runaway duplicate long mail bug?} " ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984021510540000> Received: from SCRC-RIVERSIDE.ARPA by SRI-NIC with TCP; Wed 15 Feb 84 12:52:29-PST Received: from SCRC-MERRIMACK by SCRC-RIVERSIDE via CHAOS with CHAOS-MAIL; Wed 15-Feb-84 15:50:27-EST Return-path: Date: Wed, 15 Feb 84 15:54 EST From: Charles Hornig Subject: Re: TOPS-20 FTP server To: CLYNN@BBNA.ARPA cc: tcp-ip@SRI-NIC.ARPA, bug-ftpser@MIT-XX.ARPA, lispm-networks%SCRC-TENEX@MIT-MC.ARPA In-Reply-To: <[BBNA]14-Feb-84 11:50:55.CLYNN> Message-ID: <840215155437.3.Hornig@QUABBIN.SCRC.Symbolics> Date: 14 Feb 1984 11:50-EST From: CLYNN@BBNA I tried to repeat your problem by logging into SRI-NIC, MIT-XX, and ISIE from one of the BBN terminal concentrators (which are not listed in the NIC's host tables). They all accepted the USER ANONYMOUS, PASS ... sequence. What are we doing differently? We have found the problem. It is our fault. One of our gateways had a very obscure bug involving Ethernet packets of length 3 mod 4. The TOPS-20 response for our hosts which weren't in the table was long enough to set it off. Sorry to bother you all. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984021617233300> Return-Path: <@DCN6.ARPA:Mills@DCN6> Received: from DCN6.ARPA by SRI-NIC with TCP; Thu 16 Feb 84 09:55:52-PST Date: 16-Feb-84 17:23:33-UT From: Mills@DCN6 Subject: Fuzzball throughputs To: TCP-IP@SRI-NIC cc: Byard@DCA-EMS, CAK@PURDUE, Clausen@USC-ISID, Fuzzball@USC-ISID, Gross@DCN7, Jay@FORD1, Louie@CVL, Mike.Accetta@CMU-CS-IUS, Mike@UMD9, Milazzo@RICE, Patrick@FORD-WDL1, Spilling@NTARE1 Folks, You may be interested in the following overall performance data on the fuzzball implementation. The data reveal the total processing times for ordinary user interaction using a local terminal and for various network processing functions. These particular data were collected on an LSI-11/23 system using 256 Kbytes of memory, a 30-Mbyte Winchester disk and Interlan Ethernet interface. The processing times were determined from a number of statistical counters and timers maintained by the system itself and, in the case of interrupt times, by outboard electronic instrumentation. The worst-case interrupt CPU time was measured for the Winchester disk controller as about 800 microseconds - the times shown below for other devices were based on prior measurements corrected for the actual configuration. Per-process times are obtained by counting the number of 60-Hz timer interrupts when the process is active. Thus, if an interrupt occurs while the process is active and does not result in a context switch, the interrupt time is charged to the process. Also note that most processes are rescheduled withing only a few milliseconds, so that this method is accurate only if (a) the rescheduling event is not correlated with the timer event and (b) a large number of events are averaged. Fuzzballs are built using a pair of link-level processes which does the internal packet switching for each network interface, a network-level process which does the kernel-space IP and TCP processing, and an application process for every local user or network server. A pair of terminal processes is associated with each local terminal in the system. All except the application processes are run in kernel space. Each application (user) process is run in a separate user space as an emulated RT-11 background job. Local terminal input/output times were measured by simply banging on a key and watching the counters. Most of the processing in the user process is due to RT-11 EMT emulation. For output-only this process burns only about 1100 microseconds per character. Note that character input is necessarily character-at-a-time; however, character output is buffered several characters per interprocess message. The link-level process input/output times were measured using an ACC 1822 (DMA) interface connected to an ARPANET IMP. About two-thirds of the output time is burned in the ARPANET 1822 leader code, which can result in a table search to find gateway addresses. The network-level process handles all datagrams landing at the host. The times include reassembly queue processing, header validation, connection matching and protocol module processing. For raw datagrams the protocol processing is minimal, since the datagram is simply mapped into the appropriate user process virtual space. For TCP datagrams the processing includes reassembly, retransmission and copying to and from user virtual space. In both cases the times include a mixture of short and long packets up to 576 octets. Following is a summary of the data: Terminal input/output (per character) DLV11 PI interfaces Input interrupt 500 est Terminal input process 2429 Output interrupt 300 est Terminal output process 816 User process 3893 ---- Total 7938 microseconds/character Link input/output (per packet) ARPANET 1822 DMA interfaces Link input interrupt 300 (est) ARPANET net input process 2167 Link output interrupt 300 (est) ARPANET net output process 1876 ---- Total 4643 microseconds/packet Network process (per packet) Raw datagrams 3280 TCP datagrams (segments) 13620 One way of looking at these figures is that the LSI-11/23 becomes CPU bound at an aggregate data rate of 125 characters per second or 200 packets per second (assuming the characters and packets pass right through the system). The maximum aggregate character input rate is 150 characters per second and the maximum aggregate output rate is 400 characters per second. For datagrams landing at the host, the maximum raw-datagram rate is 125 packets per second, assuming equal input and output rates, while the maximum TCP rate is 50 576-octet packets per second, exclusive of user processing. Finally, an FTP disk-to-disk between a pair of fuzzies on an Ethernet is about 8000 characters per second. Obviously, the fuzzball performance can be improved, especially in the user process. The overhead for RT-11 emulation is severe, as is the requirement for character-at-a-time input. Packet processing can be improved by hashing the net table, which has lately grown to over 60 entries. TCP processing can be improved in the area of buffer management (every implementation can make that statement). Hopefully, this information will be useful in evaluating the performance of other implementations using LSI-11 or similar horsepower. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984021619243900> Return-Path: Received: from BRL-VGR by SRI-NIC with TCP; Fri 17 Feb 84 04:26:07-PST Date: Fri, 17 Feb 84 0:24:39 EST From: Ron Natalie To: tcp-ip@sri-nic cc: nic@sri-nic, rnj@brl-vgr Subject: TACNEWS The "@n" doesn't seem to give the TAC-NEWS host. Just says destination host unreachable. Telnet-ing to the TAC-NEWS address (8.7.0.4) yields the host but the old tacnews and anonymous/guest logins no longer work. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984021702312000> Return-Path: Received: from EGLIN-VAX by SRI-NIC with TCP; Fri 17 Feb 84 06:33:04-PST Date: Fri, 17 Feb 84 08:31:20 CST From: george@EGLIN-VAX Subject: RSX TCP/IP To: tcp-ip@sri-nic Cc: george@afsc-hq In light of the recent RSX / TCP discussions I will add another message to the Bulletin Board. My apologies to those who are aware or could care less about the following: AIR FORCE SYSTEMS COMMAND has supported a project called SAMNET which implemented ARPANET protocols ( TCP/IP, FTP, and TELNET) on PDP11 RSX11M as a network front end to CDC (NOSBE) mainframes. This software has been released to several DOD and other govt agencies. Any request for this software should be placed through AFSC/ACDT ANDREWS AFB, Wash. D.C. 20334 telephone (301) 981-3137 AV 858-3137 Any technical questions to Calvin George AD/KRESS EGLIN AFB, Florida 32548 (904)882-2276 or AV 872-2276 George at AFSC-HQ or George at Eglin-VAX The SAMNET software package uses RSX11M V3.1. TCP/IP and 1822 is provided as an RSX11M ACP. Network I/O drivers are avialable for DEC 1822 interfaces, IMP11A and IMP11B. The ACC LHDH/11 could be supported with slight mods to the IMP11A driver. User and Server FTP and TELNET are available. NVT is supported via substantial modifications to the RSX terminal driver. Hence, the problem of upgrading to RSX 4.x. The TCP/IP package does not support full internet support, no fragmentation/ reassembly, and no gateway messages. In short, it only works to HOSTs on the same network. The software package ( TCP/IP, TELNET, FTP, and PDP to CDC software) uses approximately 96Kwords (16bit) of a 128Kword system. Individual TELNET and FTP tasks use shared code ( part of the 96K) plus additional memory for buffers and non-reentrant code. Currently the I/O drivers do not support 22bit addressing ( 11/44 and 11/70 ). This should not be difficult to do. z ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984021706261500> Return-Path: Received: from bbnccs by SRI-NIC with TCP; Fri 17 Feb 84 08:31:09-PST Date: Fri, 17 Feb 84 11:26:15 EST From: Andrew Malis Subject: Re: TACNEWS In-Reply-To: Your message of Fri, 17 Feb 84 0:24:39 EST To: Ron Natalie Cc: tcp-ip@sri-nic, nic@sri-nic, rnj@brl-vgr, malis@BBN-UNIX Ron, The tac-news service has moved to SRI-NIC. Typing "@n" opens a connection to SRI-NIC, which then accepts the command (without needing to log in) "tacnews". Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984022007210200> Mail-From: FEINLER created at 20-Feb-84 15:21:02 Date: Mon 20 Feb 84 15:21:02-PST From: Jake Feinler Subject: Re: TACNEWS To: ron@BRL-VGR, tcp-ip@SRI-NIC cc: nic@SRI-NIC, rnj@BRL-VGR In-Reply-To: Message from "Ron Natalie " of Fri 17 Feb 84 04:27:13-PST Ron, et al, The NIC machine was experiencing problems and was down at the time. Also there was work being done on our IMPS. Not sure which one of these you hit. Sorry for the inconvenience. Jake ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984022012400000> Return-Path: Received: from MIT-MULTICS.ARPA by SRI-NIC with TCP; Mon 20 Feb 84 14:50:18-PST Date: Mon, 20 Feb 84 17:40 EST From: Schiller@MIT-MULTICS.ARPA (Jeffrey I. Schiller) Subject: Re: SRI-NIC tinygram fever To: mills@DCN6.ARPA cc: tcp-ip@SRI-NIC.ARPA, jbn@FORD-WDL1.ARPA In-Reply-To: Message of 20 Feb 84 12:24 EST from "mills at DCN6" Message-ID: <840220224035.384490@MIT-MULTICS.ARPA> We have been experiencing the same problem with SRI-NIC here at MIT-MULTICS. The problem here is that the large number of retransmissions causes the our IMP to clog and malfunction (we are connected via message mode HDH which has problems handling large amounts of traffic). We have been forced to use FTP to get our host table updates. -Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984022017244400> Return-Path: <@DCN6.ARPA:mills@dcn6> Received: from DCN6.ARPA by SRI-NIC with TCP; Mon 20 Feb 84 09:41:12-PST Date: 20-Feb-84 17:24:44-UT From: mills@dcn6 Subject: SRI-NIC tinygram fever To: tcp-ip@nic cc: jbn@facc Folks, Acting on a tip from John Nagle of Ford Aerospace, I traced the TCP segments sent by SRI-NIC in response to a connection request to the host-name server (port 101) and sending the ALL command. Presto, the reason for the alleged fire-hose behavior on the part of SRI-NIC has been explained. Remember, SRI swears on a stack that the runaway-ACK problem has been f*i*x*e*d; however, an uncomfortably high incidence of buffer congestion and resulting source-quench continue to be observed. From the trace, excerpted below, it is apparent the host-name server packetizes in rather small 64-octet segments and assumes an unrealistically small value for its retransmission timer. Following is an excerpt from the log of DCN6, which is connected via 4.8-Kbps line to the DCN-GATEWAY, itself connected to the Mitre IMP via 56-Kbps line. The Stamp column shows the arrival timestamp (milliseconds), IP Seq the IP sequence number, LWE the position relative to the current RCV.NXT, Size the size (octets) and Window the receive window after the segment has been stored. A minus sign in the LWE column indicates an old (duplicate) segment, while a minus sign in the Size column indicates the PUSH bit is set. Time (UT) Stamp IP seq LWE Size Window ---------------------------------------------------------------------- 16:45:37 002 ?TRAP-I-TCP rcv 44044 53164 -384 -62 450 16:45:37 002 ?TRAP-I-TCP rcv 44327 53173 0 -62 388 16:45:37 002 ?TRAP-I-TCP rcv 44644 53165 -384 -64 450 16:45:38 002 ?TRAP-I-TCP rcv 44994 53174 0 -64 386 16:45:38 002 ?TRAP-I-TCP rcv 45178 53175 0 2 448 16:45:38 002 ?TRAP-I-TCP rcv 45428 53166 -386 2 450 16:45:38 002 ?TRAP-I-TCP rcv 45778 53167 -384 -62 450 16:45:39 002 ?TRAP-I-TCP rcv 46078 53176 0 -62 388 16:45:39 002 ?TRAP-I-TCP rcv 46378 53168 -384 -64 450 16:45:39 002 ?TRAP-I-TCP rcv 46728 53177 0 -64 386 16:45:40 002 ?TRAP-I-TCP rcv 46928 53178 0 2 448 16:45:40 002 ?TRAP-I-TCP rcv 47228 53169 -386 2 450 16:45:40 002 ?TRAP-I-TCP rcv 47578 53170 -384 -62 450 16:45:41 002 ?TRAP-I-TCP rcv 47911 53179 0 -62 388 16:45:41 002 ?TRAP-I-TCP rcv 48245 53171 -384 -64 450 16:45:41 002 ?TRAP-I-TCP rcv 48578 53180 0 -64 386 16:45:42 002 ?TRAP-I-TCP rcv 48778 53181 0 2 448 16:45:42 002 ?TRAP-I-TCP rcv 49011 53172 -386 2 450 Note that half of the arriving segments are duplicates, indicating NIC is shooting itself in the foot with an unrealistically small value for its retransmission timer. Second, almost all segments have the PUSH bit set, which seems not a particularily good idea for this type of bulk data transfer, since the receiver cannot safely aggregate ACKs. The real problem is the use of rather small segments (tinygrams), which clog up gateway buffers when hosts advertise reasonably large windows. John and I have observed the results many times when one of his hosts attempts to update its host tables this way and DCN-GATEWAY instantly contracts a case of bufferitis. I suspect this contagion infects the ARPANET/MILNET gateways as well. The disease is not terminal, however, and can be treated by (a) using FTP, (b) fixing the host-name server packetizer to favor larger segments. I suspect the design choice of small segments here may be due to antibodies made after infection by the "window-smasher" bug which gave us all the "individually pushed 50-octet" fever. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984022100191400> Return-Path: <@DCN6.ARPA:mills@dcn6> Received: from DCN6.ARPA by SRI-NIC with TCP; Mon 20 Feb 84 16:27:34-PST Date: 21-Feb-84 00:19:14-UT From: mills@dcn6 Subject: Re: SRI-NIC tinygram fever To: mills@dcn6, tcp-ip@nic, jbn@facc In-reply-to: Your message of 20-Feb-84 17:24:44-UT Folks, The ink was hardly dry on my message when Ken Herrenstien fixed the NIC host-name server to favor larger packets. Now it packs about 200 octets per segment and no duplicates at all are observed. Good show! I bet if the PUSH were removed from those segments, TOPS-20 TCP would pack up to 576 octets in those 'grams like in the case of FTP. It looks from the slightly unstable segment sizes that the packetizer is still quite delay sensitive. I have seen this before in the case of NIFTP, which was changed to avoid the PUSH with the result that the segments were positively stuffed. Gee, the TOPSes are pretty well tamed just now. Maybe it's time to go beat up the VAXen. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984022217570000> Return-Path: Received: from JPL-VLSI.ARPA by SRI-NIC with TCP; Thu 23 Feb 84 02:03:26-PST Date: 23 Feb 1984 0157 PST From: Eric P. Scott Subject: Please don't laugh... To: TCP-IP@SRI-NIC Reply-To: EPS@JPL-VLSI I'm interested in any information regarding TCP/IP software and LAN interfaces for Data General MV/series processors running AOS/VS. Failing that, I'll settle for any good free/public domain TCP/IP implementations written in a transportable language (C, PL/1). BTW, these are 32-bit machines with lots of memory. -=EPS=- ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984022311370200> Return-Path: Received: from mitre by SRI-NIC with TCP; Thu 23 Feb 84 13:56:55-PST Date: 23 Feb 1984 16:37:02 EST (Thursday) From: John Swanson Subject: Commercially available Unix To: tcp-ip@sri-nic Cc: jswanson@mitre I am trying to compile a list of commercially supported UNIX systems for VAX hardware. The limiting factor would be that they have TCP/IP and an IMP interface. Anyone that can give me pointers please send them to jswanson@mitre. Thanks John Swanson ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984022321420000> Return-Path: Received: from JPL-VLSI.ARPA by SRI-NIC with TCP; Fri 24 Feb 84 05:51:11-PST Date: 24 Feb 1984 0542 PST From: Eric P. Scott Subject: A "Not Yet" on Data General To: TCP-IP@SRI-NIC Reply-To: EPS@JPL-VLSI Date: 23-Feb-84 06:26 PST From: Bill Barns Subject: Re: Please don't laugh... To: EPS@JPL-VLSI Message-ID: <[OFFICE-2]TYM-WWB-463J4> In-reply-to: EXT-EPS-4637Z If you refer to the Washington Post, Feb. 12 issue, page G15 (I'm sure you have this constantly by your side), you will observe a 1/6 page DG help-wanted ad looking for all kinds of software types. There is a sentence "Projects in the following areas: [lots]..., ARPANET TCP/IP..." The inference seems clear but I have no further information about it. The same ad has probably run all over the country. From the text of the ad I gather that the work is being done in Westboro, Mass. If for some reason you actually want a copy of the ad, I could probably throw one in the US Snail to you... however I imagine that a help-wanted ad will be a poor substitute for an executable implementation... -b ------- Received: by NYU.ARPA; Thu, 23 Feb 84 11:02:51 est Date: Thu, 23 Feb 84 11:02:51 est From: salkind@nyu (Lou Salkind) Message-Id: <8402231602.AA06150@NYU.ARPA> To: EPS@JPL-VLSI Subject: Re: Please don't laugh... Interlan sells an Ethernet board for AOS/VS. I don't know of any TCP/IP implementations, but it is rumored a group in North Carolina is working on it. I would be curious to hear what you find out. ------- Date: Thu, 23 Feb 84 11:13 EST From: Dennis Rockwell Subject: Re: Please don't laugh... To: Eric P. Scott The BBN TCP/IP implementation is public domain (the Feds financed it), is written in C, and is available without a UNIX license. If you're interested, send your USMail address to abreau@bbn-unix, and she'll send you our license forms. ------- Date: 23 Feb 1984 1225-PST From: Chris Subject: Re: Please don't laugh... To: EPS@JPL-VLSI.ARPA Phone: (213) 743-5520 Office: PHE-220 In-Reply-To: Your message of 23-Feb-84 0157-PST Could you send me what ever responses that you get that dont go back to the list (either to the list or me individually is fine). Thanks. Chris. ------- Date: Thu 23 Feb 84 17:29:32-PST From: Francine Perillo Subject: Re: TCP/IP for 32-bit DGC systems To: EPS@JPL-VLSI cc: PERILLO@SRI-NIC In-Reply-To: Message from "Eric P. Scott " of Fri 17 Feb 84 11:28:00-PST Hi Eric, I spoke with a fellow from Data General in Westboro, MA earlier this month and he claims that they are working on developing TCP/IP for the AOS/VS operating system for the MV and Eclipses. He said that it would be a year before it would be available as a product. He would be glad to talk with you, as I asked him if I could send anyone his way. James Hirni Data General 4400 Computer Drive Westboro, MA (617) 366-8911 ext. 6173 -Fran ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984022404285400> Return-Path: Received: from UCB-VAX.ARPA by SRI-NIC with TCP; Fri 24 Feb 84 13:06:25-PST Received: by UCB-VAX.ARPA (4.22/4.25) id AA23224; Fri, 24 Feb 84 12:39:59 pst Received: from phoenix.sun.uucp by sun.uucp (4.24/3.14) id AA27102; Fri, 24 Feb 84 12:28:19 pst Received: by phoenix.sun.uucp (4.24/3.14) id AA00938; Fri, 24 Feb 84 12:28:54 pst Date: Fri, 24 Feb 84 12:28:54 pst From: sun!rusty@phoenix (Russel Sandberg) Return-Path: Message-Id: <8402242028.AA00938@phoenix.sun.uucp> To: tcp-ip@sri-nic.ARPA Subject: UNIX 4.2 FIN_WAIT_2 bug fix Folks, As the new babysitter of the Berkeley UNIX 4.2 TCP/IP code here at Sun, I was asked to look at the "hanging FIN_WAIT_2" problem. For those of you who haven't heard about this one it works like this: an established connection is closed by the process on the receiving end during data transfer; the sender goes into LAST ACK and tries to send out its data; meanwhile, the receiver has thrown away its socket structure, which includes the receive buffers, and in the process closed its receive window; the sender probes the zero window which the receiver can't open; and both ends stay around forever because of the probe-ack exchange. The obvious solution is for the receiver to accept the data and drop it on the floor, since there is no one to deliver it to. This is hard. It involves faking the receive window, special casing data received on a fake window, and in fact, in a sense it violates the protocol because it makes the sender think its data got delivered intact. My solution is to sent an RST when data is received on a connection for which there is no process to deliver to. The sending side should also be fixed because not all sites will have the receive side fix installed. The sender should not persist forever probing a zero length window (at least when it is in LAST ACK state). The changes to the UNIX kernel to implement these two fixes are minimal. In fact, on the sending side, the code already exists but it is never executed. Please let me know if you think this violates the TCP specification. Russel Sandberg sun!rusty@berkeley ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984022407160100> Return-Path: Received: from SU-SCORE.ARPA by SRI-NIC with TCP; Fri 24 Feb 84 15:24:22-PST Date: Fri 24 Feb 84 15:16:01-PST From: Joseph I. Pallas Subject: Re: UNIX 4.2 FIN_WAIT_2 bug fix To: "sun!rusty@phoenix"@SRI-NIC.ARPA cc: tcp-ip@SRI-NIC.ARPA In-Reply-To: Message from "sun!rusty@phoenix (Russel Sandberg)" of Fri 24 Feb 84 13:35:36-PST The problem you're describing arises from not mapping concepts correctly. First, there is no receiving end of a TCP connection; TCP connections are full-duplex. Second, neither side of a TCP connection can close the connection, it can only close its half of the connection, which means to announce that it will not SEND any more data on the connection. If the operation you are calling close results in the entire socket structure being thrown away without receipt and acknowledgment of a FIN and without sending a FIN and waiting for it to be ACKed, then the operation is really an abort. The protocol specifies clearly that a reset should be sent immediately and the control block deleted, leaving the connection in the closed state (any more incoming data on the connection will be answered by resets). As for "fixing" the sending side, IF IT AIN'T BROKEN, DON'T FIX IT! ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984022409560000> Return-Path: Received: from JPL-VLSI.ARPA by SRI-NIC with TCP; Fri 24 Feb 84 17:58:33-PST Date: 24 Feb 1984 1756 PST From: Eric P. Scott Subject: The evil CCITT/ISO monster slobbers on... To: TCP-IP@SRI-NIC Reply-To: EPS@JPL-VLSI I just received my "1984 Spring DECUS U.S. Symposium Registration Information Kit." One particular Pre-Symposium Seminar description caught my eye: "Networks Communications & Protocols: A Comprehensive Survey." The abstract begins: This seminar is a must for entry-level and intermediate- level network users and managers. This fast paced seminar is designed to bring you immediately up to date in both local area and global networking concepts. The seminar is designed for both the newcomer to networking as well as those who haven't been briefed on new developments even in the last few months. Attendees will gain a real sense of being on top of new developments. Wow! The networking environment is emphasized in this seminar, beginning with a definition of communications, its history, and requisites. Communications standards and Open Systems Interconnect are discussed in respect to structures, processes, systems, and architecture. This leads into protocol evolution and a discussion of the session, presentation, and application layers. I have a bad feeling about this, kid. The seminar next enters a wide-ranging exploration of contemporary networking strategies, global network structures, and transports which use X.25. A general comparison is made between the capabilities of Baseband structured networks and Broadband networks. The seminar concludes with a glimpse into the future of communications. I think the seminar title is deceptive. Topics to be covered include: I. The Electronic Tower of Babel 1. Communications: A Definition 2. Communications Requisites 3. History of Agreement 4. EIA Conformity 5. ISO Draft Standards 6. IEEE Resolutions 7. Recent NBS Decisions 8. Future Standards Forcast II. Open Systems Interconnect 1. Layered Structures 2. Layered Processes 3. Layered Systems 4. OSI Layered Architecture A. Physical B. Link C. Network D. Transport E. Session F. Presentation G. Application 5. Peer Structure 6. Peer Protocols 7. Intermediate Nodes III. Protocol Evolution 1. Origins of Protocol 2. ASCII Organization 3. Character Structure and Parity 4. VRC and LRC Checking 5. CRC Error Detection 6. Character Protocols 7. Character Oriented Link Protocols 8. Character Protocol Message Structures 9. DDCMP Block Format 10. Major Bit Oriented Protocols 11. Frame Definition 12. Logical Station Configurations 13. Shared Resources IV. Session Layer 1. Administrative Services 2. Binding and Unbinding Connections 3. Dialog Services 4. Control Data Exchange 5. Interaction and Synchronization 6. Exception Reporting V. Presentation Layer 1. Interpretation of Data 2. Data Transformation 3. Data Formatting 4. Syntax Selection 5. Structure of Data VI. Application Layer 1. Highest Layer 2. Serves as Window to OSI 3. Identification 4. Availability of Resources 5. Authority 6. Authentication 7. Agreement of Syntax VII. Facilitating Various Networks 1. Contemporary Networking Strategies A. Shared Resources B. Interconnected Networks C. Distributed Network Facilities VIII. Global Network Structures 1. X.24 Architecture 2. X.25 Physical Layer 3. X.25 Link Layer 4. Packet Frame Relationships 5. Logical Channel Assignment IX. Transports Using X.25 1. CCITT X.3/X.28 PAD 2. 3270 and 2780 PAD 3. GTE TELENET 4. TYMNET 5. American Bell Net One X. General Purpose Network Interface 1. Architectural Relationships to OSI/NBS Models 2. Domain of Local Area Networks 3. Topology 4. Basebound [sic] Bus 5. Single-Cable Broadband Bus 6. Dual-Cable Broadbad Bus 7. Cambridge Ring 8. Star 9. LAN Access Methods 10. LAN Standard Options 11. Local Area Network Protocols 12. File -- File Transfer XI. Physical Layer Mediums 1. RS232 Characteristics 2. RS449 Characteristics 3. RS422 Characteristics 4. Networking Mediums A. 50 Ohm Coax Cable B. Twisted Wire Pair C. Satellite Channel D. Fiber-Optics XII. Applications Studies 1. Implementation Examples from Industry 2. Emerging Technology in Product Design XIII. Conclusions And Discussions Prerequisites: It is recommended that the attendees have some familiarity with communica- tions devices Instructor: Ken O'Mohundro is the President of ABLE Computer, a dynamic and rapidly expanding company devoted to network enhancements. His list of credits is long, having worked as an engineer at McDonnell Douglas and Interstate Electronics, and then as a computer designer and engineering manager for Microdata. When the opportunity to become Director of Marketing operations at California Data Processing appeared in 1972, he took it and was grateful for the challenge, for it led him to found his own company in 1975. A frequent speaker at DECUS and DEXPO symposia, he is also a regular contributor to the DEC Professional. Registration fee: $175.00 Gag. -=EPS=- ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984022607304100> Mail-From: ROODE created at 26-Feb-84 15:30:41 Date: Sun 26 Feb 84 15:30:41-PST From: David Roode Subject: Re: The evil CCITT/ISO monster slobbers on... To: EPS@JPL-VLSI, TCP-IP@SRI-NIC In-Reply-To: Message from "Eric P. Scott " of Fri 24 Feb 84 17:56:00-PST Location: EJ286 Phone: (415) 859-2774 There is a significant body of people for whom both CCITT/ISO and TCP/IP are unknowns. Coming from that perspective, I think that the most striking impression would be one of similarity rather than of difference, since the two share underlying principles of layered network architecture. X.25 is linked to TCP/IP in an interesting way that has never been documented in an RFC. For CSNET, software has been developed under Unix to utilize X.25 as a transport layer beneath TCP/IP. This was reported in: Comer, D. The Computer science research network CSNET: A history and status report. Comm. ACM, 26, 10(Oct. 1983), 747-753. and Comer, D.E. and Korb, J.T. CSNET protocol software: The IP-to-X.25 Interface. Proc. Symp. Data Comm. ACM SIGCOMM (March 1983), 154-159. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984022706435700> Return-Path: Received: from bbnccq by SRI-NIC with TCP; Mon 27 Feb 84 09:03:25-PST Date: Mon, 27 Feb 84 11:43:57 EST From: Jonathan Dreyer Subject: Re: The evil CCITT/ISO monster slobbers on... In-Reply-To: Your message of Sun 26 Feb 84 15:30:41-PST To: David Roode Cc: EPS@JPL-VLSI, TCP-IP@SRI-NIC The encapsulation of IP into X.25 is described in RFC 877 by Tim Korb. Besides the Unix implementation running at CSNet sites, there is an IBM implementation developed at the University of Wisconsin, an implementation running on a PDP11 (?) at University College London, and the BBN VAN gateway running on an LSI-11. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984022707353200> Mail-From: KLH created at 27-Feb-84 15:35:33 Date: Mon 27 Feb 84 15:35:32-PST From: Ken Harrenstien Subject: Re: ARPANET error messages for MTI-ML To: mills@DCN6 cc: KLH@SRI-NIC, tcp-ip@SRI-NIC In-Reply-To: Message from "mills@dcn6" of Mon 27 Feb 84 11:32:39-PST I'm not sure I understand what the problem is. If DCN-GATEWAY is forwarding a datagram from some non-ARPA net to the ARPANET, this seems like something to be expected. If it is forwarding a datagram from the ARPANET back out to the ARPANET, why isn't DCN-GATEWAY generating an ICMP redirect? (If it is, then we can ask why the source host isn't paying attention to the redirect!) Anyway, you presumably have the ability to track this down your very own self (and I don't see how anyone else can help you). Just trap any datagram which is bound for MIT-ML, and log the source address of the IP header. For extra veracity, log the source host/imp from the 1822 leader as well. Then we'll have something to work on... ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984022713334600> Return-Path: Received: from ddn1 by SRI-NIC with TCP; Mon 27 Feb 84 15:37:01-PST Date: 27 Feb 84 18:33:46 EST From: dca-pgs @ DDN1 Subject: Query: TCP/IP for Zenith Z-100 To: tcp-ip@sri-nic CC: dca-pgs @ DDN1 Date: 27 Feb 84 18:11:31 EST Text: Is anyone out there working on a TCP/IP implementation for the Z-100? Proteon Corp. offers a package for the IBM PC which can play into a BBN/Arpa gateway and thence interface DDN or Arpanet, but I haven't heard of anything similar for the Z-100. Would love to find such a thing, especially since, if you are Navy or Air Force, Zenith has got you with that big contract. All replies appreciated. Best, Pat Sullivan DCA/DDN/PMO ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984022719124100> Return-Path: <@DCN1.ARPA:mills@dcn6> Received: from DCN1.ARPA by SRI-NIC with TCP; Mon 27 Feb 84 11:32:18-PST Date: 27-Feb-84 19:12:41-UT From: mills@dcn6 Subject: ARPANET error messages for MTI-ML To: tcp-ip@nic cc: ncc@bbnu Folks, Since sometime before 1700 UT on 25 February DCN-GATEWAY (10.3.0.17) has been receiving destination-dead messages from host MIT-ML (10.3.0.6); however, there is no record of any process in that machine generating such a message. There is no gateway or host anywhere in the DCN-GATEWAY tables with that address. I conclude that some outside host is sending an 1822 packet with ARPANET leader address 3/17 and including an IP datagram with destination address 10.3.0.6. Following is a trace showing the octal dump of the error messages returned to DCN-GATEWAY from the ARPANET IMP in apparent response to sending the IP datagram. The first line shows a "destination dead" message with sub-type 1 (destination host not up), while the second shows a "dead host status" message with sub-type 3 (destination host does not exist). The remaining lines are duplicates of these two. I sent an ICMP Echo message to 10.3.0.6 with the same result. 17:00:14 006 ?TRAP-I-Leader error 000017 003400 001400 003000 000633 17:00:14 006 ?TRAP-I-Leader error 000017 003000 001400 003000 160777 17:00:18 006 ?TRAP-I-Leader error 000017 003400 001400 003000 000633 17:00:18 006 ?TRAP-I-Leader error 000017 003000 001400 003000 160777 17:00:26 006 ?TRAP-I-Leader error 000017 003400 001400 003000 000633 17:00:26 006 ?TRAP-I-Leader error 000017 003000 001400 003000 160777 17:00:42 006 ?TRAP-I-Leader error 000017 003400 001400 003000 000633 17:00:42 006 ?TRAP-I-Leader error 000017 003000 001400 003000 160777 17:01:12 006 ?TRAP-I-Leader error 000017 003400 001400 003000 000633 17:01:12 006 ?TRAP-I-Leader error 000017 003000 001400 003000 160777 17:01:42 006 ?TRAP-I-Leader error 000017 003400 001400 003000 000633 17:01:43 006 ?TRAP-I-Leader error 000017 003000 001400 003000 160777 17:02:12 006 ?TRAP-I-Leader error 000017 003400 001400 003000 000633 17:02:13 006 ?TRAP-I-Leader error 000017 003000 001400 003000 160777 This sequence has been repeating at precisely half-hour intervals since then. Notice the backoff on retransmissions, leading me to suspect the original datagram was a TCP segment, that the connection was opened for mail and that it timed out after two minutes. Your help in isolating this phenomenon would be appreciated. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984022820531700> Return-Path: <@DCN6.ARPA:mills@dcn6> Received: from DCN6.ARPA by SRI-NIC with TCP; Tue 28 Feb 84 12:59:20-PST Date: 28-Feb-84 20:53:17-UT From: mills@dcn6 Subject: Re: ARPANET error messages for MTI-ML To: KenHarrenstien, mills@DCN6, tcp-ip@SRI-NIC In-reply-to: Your message of Mon 27 Feb 84 15:35:32-PST Ken, The offending datagram is apparently coming from the ARPANET and is destined for an ARPANET host. It further apperaas thre is no other net involved, so net-level redirects ae not called for. Your comment on tracing packets is well taken; however, trapping datagrams by address is not presently implemented, so cooperation from my friends, especially since this may be a generic problem,] would be appreciated. Such trapping will be implemented, probably soon, in any cxase. Dave ------- ----MESSAGE-END----