Date: Sat, 6 Nov 93 04:30:06 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #288
To: tcp-group-digest
TCP-Group Digest Sat, 6 Nov 93 Volume 93 : Issue 288
Today's Topics:
FP_OFF/SEG on Borland vs. Microsoft
Info
need NOS with PPP
Re- TCP broadcast storm
TCP/IP Probs
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Fri, 5 Nov 93 11:50:56 PST
From: myers@pongo.West.Sun.COM (Dana Myers )
Subject: FP_OFF/SEG on Borland vs. Microsoft
To: tcp-group@ucsd.edu
Though it may be against the rules, I'm currently building NOS
(the base KA9Q code) using Microsoft C/C++ 8.0. I'm starting to
wonder if the behaviour of FP_OFF and FP_SEG differ in the two
compilers. In particular, I'm wondering about the parameter that
is passed to the macros.
Can anyone explain to me exactly how Borland defines these macros?
Thanks!
Dana KK6JQ
Dana.Myers@West.Sun.Com
------------------------------
Date: Fri, 5 Nov 93 19:11:02 EST
From: "G.U.I. Valladolid" <amiga@hp9000.uva.es>
Subject: Info
To: tcp-group@ucsd.edu
Information
------------------------------
Date: Fri, 5 Nov 1993 10:35:37 -0600 (CST)
From: dave@holl.com (David Vrona)
Subject: need NOS with PPP
To: tcp-group@ucsd.edu
Hi all,
I need to setup a simple DOS based router. I need PPP capability. Would
someone please recommend something I can ftp fro ucsd.edu?
There are so many NOS variants on ucsd.edu that I find my head swimming.
thanks much,
dave
--
David Vrona N9QNZ +1 708 680 2829 (voice)
Hollister Incorporated +1 708 918 3860 (fax)
2000 Hollister Drive Internet: dave@hp1.holl.com
Libertyville, IL 60048-3781 UUCP: {well connected}!genesis!hp1!dave
Opinions expressed are my own and not those of Hollister Incorporated.
------------------------------
Date: Fri, 5 Nov 1993 14:33:28 -0800
From: braden@ISI.EDU (Bob Braden)
Subject: Re- TCP broadcast storm
To: TCP-Group@ucsd.edu, MGauthier@iit.nrc.ca
*> From MGauthier@iit.nrc.ca Thu Oct 28 05:06:04 1993
*> Date: 27 Oct 1993 17:45:00 U
*> From: "MGauthier" <MGauthier@iit.nrc.ca>
*> Subject: Re- TCP broadcast storm
*> To: TCP-Group@ucsd.edu
*> Cc: "Robert Braden" <braden@ISI.EDU>
*> Content-Length: 7357
*> X-Lines: 156
*>
*> Subject: Re: TCP broadcast storm
*> [To R. Braden: there is a question (or observation) at the end of this
*> message asking why RFC 1122 doesn't explicitly say that TCP should
*> always ignore and never generate broadcast/multicast packets, instead
*> of just mentioning SYN packets.]
Marc,
The reasoning was this: the IP addresses of the endpoints of a TCP
connection are bound when a connection is opened. A multicast address
appearing in a data or ACK segment must be ignored by the normal TCP
demux machinery, unless that address occurred in a SYN segment when the
connection was opened. Hence, it is only necessary to make a special
test for multicast address at open time.
*>
*> |From: "Ray Abbitt" <treab@chevron.com>
*> |SUBJECT: Kind of interesting problem.
*> |
*> |>From: Glenn Davis <davis@alien.vax.syncrude.com>
*> |>Subject: TCP broadcast storm
*> |>I am troubleshooting a particularly devilish network problem. About two
*> |>days ago I started seeing very high TCP broadcast traffic on our internal
*> |>TCP/IP network. After taking a network sniffer to the problem I discovered
*> |>packets like:
*> |>
*> |>13-OCT-1993 02:59:09.76 02-60-8C-A5-4F-BD FF-FF-FF-FF-FF-FF 08-00 len= 46
*> |>IP: vers=4 hdrlen= 5 lngwrds, svc:Routine
*> |> total len= 40 ID=%X967E frag ofs= 0
*> |> TTL= 30 prot= 6 TCP (Transmission Control), cksum=%X3B1E
*> |> src=255.255.255.255 dest=255.255.255.255
*> |>TCP:port:src=31876 dest=132 seq#=523398 ack#=523398
*> |> window=0 len=5 Lwrds,ACK,RST cksum=39AD urgentptr=0
*> |>FFFFFFFF 3B1E061E 0000967E 28000045 E..(~......;.... 0000
*> |>86FC0700 86FC0700 8400847C FFFFFFFF ....|.....|...|. 0010
*> |> 4646 45434620 0000AD39 00001450 P...9Z.. FCEFF 0020
*> |>
*> |>Approximately 35 network stations (PC's running Netmanage TCP/IP) were
*> |>sending out these packets as fast as their network adapters would allow!
*> |>
*> |>What seemed to happen is: each station would see a packet like the one
*> |>above, and send out a RST (reset) response (ie this packet not for me).
Your analysis later is correct. The Host Requirements RFC 1122 says
(4.2.3.10) that "A TCP implementation MUST silently discard an incoming
SYN segment that is addressed to a broadcast or multicast address".
Here "silently" means don't send a RST!
*> |>This would repeat itself ad-nauseum, dragging the network down with all
*> |>the broadcast traffic!
*> |>[...]
*> |>The only thing that stopped the beast was to shut down the entire network!
*> |
*> |I ran this by one of the other guys at work and got this reply:
*> |
*> |FROM: FRANK H. COLETTI(FRCO@CHEVRON.COM)
*> |Subject: Kind of interesting problem.
*> |Ray: This is a known bug in TCP traffic and was probably started by some-
*> |one who intentionally wanted this to happen. As far as I understand it
*> |you can start it by custom making an ARP packet, or some other such packet,
*> |and instead of putting your MAC address in the source field, you put the
*> |broadcast address. This causes other machines that get the packet via the
*> |broadcast to respond and automatically put in the original packet's
*> |source address-in this case, the broadcast address again. This causes
*> |a "Broadcast Storm" and what you saw is exactly what happens. It brings
*> |the network to its knees. In one of the classes I attended they said
*> |that some college guy did it on the Internet a couple of years ago and
*> |promptly brought the Internet down.
*> |[...]
No way. A broadcast storm like this could have clogged the local
Ethernet, but not the Internet as a whole. Perhaps he was referring to
the infamous Morris Worm, which was a far more subtle attack (and did
bring down a signficant part of the Internet).
*>
*> I don't think this is a "known bug in TCP traffic", but rather a bug
*> in that particular TCP implementation (unless you mean that particular
*> bug is known to be present in a number of TCP implementations).
*> A TCP should NEVER reply to a RST packet.
Right. I suppose 1122 could say this more explicitly, since 793 was
not direct about it. But anyone who has ever implemented a protocol
would realize that sending a RST for a RST is a bad idea!!
Although it's a bit spread
*> out, this is rather clear from RFC 793 ("SEGMENT ARRIVES", pages 65-76),
*> and from this explicit paragraph on page 36:
*> 1. If the connection does not exist (CLOSED) then a reset is sent
*> in response to any incoming segment except another reset. In
*> ^^^^^^^^^^^^^^^^^^^^
*> particular, SYNs addressed to a non-existent connection are rejected
*> by this means.
*>
*> Generally speaking, a proper TCP/IP implementation should NOT be prone
*> to broadcast storms. There are many discussions in the RFCs on steps
*> that must be taken to avoid such possibilities. If you find software
*> that generates broadcast storms, then most likely the software itself
*> is the culprit. I know of no way for IP or TCP to be subject to broadcast
*> storms, **when properly implemented according the the latest RFCs**.
Well, we hope so. The Host Requirements group spent a lot of energy
trying to make things robust against broadcast storms -- but of course
we might have overlooked something.
*> (Please correct me if you know full details of a valid counterexample.)
*> I don't claim that most implementations are fully conformant :-)
*>
*> The above TCP/IP implementation has a second bug, the removal of which
*> would avoid this broadcast storm. Simply said, IP packets with broadcast
*> or multicast source addresses MUST be discarded.
*>
*> RFC 1122 says (for TCP and UDP):
*>
*> 4.2.3.10 Remote Address Validation
*>
*> A TCP implementation MUST reject as an error a local OPEN
*> call for an invalid remote IP address (e.g., a broadcast or
*> multicast address).
*>
*> An incoming SYN with an invalid source address must be
*> ignored either by TCP or by the IP layer (see Section
*> 3.2.1.3).
*>
*> A TCP implementation MUST silently discard an incoming SYN
*> segment that is addressed to a broadcast or multicast
*> address.
*>
*> 4.1.3.6 Invalid Addresses
*>
*> A UDP datagram received with an invalid IP source address
*> (e.g., a broadcast or multicast address) must be discarded
*> by UDP or by the IP layer (see Section 3.2.1.3).
*>
*> When a host sends a UDP datagram, the source address MUST be
*> (one of) the IP address(es) of the host.
*>
*> It is clear from the above that broadcast and multicast addresses are
*> not allowed as source addresses in IP datagrams, and that such datagrams
*> should be discarded. This is also stated explicitly in section 3.2.1.3
*> of RFC 1122, on IP addressing:
*>
*> 3.2.1.3 Addressing: RFC-791 Section 3.2
*> [...]
*> When a host sends any datagram, the IP source address MUST
*> be one of its own IP addresses (but not a broadcast or
*> multicast address).
*>
*> [I believe there is an exception to the above for IP-level IP address
*> discovery protocols such as BOOTP, in which case 0.0.0.0 is used as
*> a source address by the BOOTP client. -MEG]
*>
*> A host MUST silently discard an incoming datagram that is
*> not destined for the host. ...
*> [...]
*> A host MUST silently discard an incoming datagram containing
*> an IP source address that is invalid by the rules of this
*> section. This validation could be done in either the IP
*> layer or by each protocol in the transport layer.
*> [...]
*>
*>
*> I propose that the stated TCP/IP implementation has yet a third bug,
*> removal of which would also prevent a broadcast storm. It is simply that
*> TCP should never respond to broadcast or multicast packets. TCP is not a
*> broadcast/multicast protocol, and should never generate (or respond to)
*> such traffic. (I'm ignoring the ARP mechanisms, which operate at the
*> network level; ARP has / should have its own mechanisms to avoid
*> broadcast storms.) However, I couldn't find any explicit statement of
*> this more general that what is found in section 4.2.3.10 of RFC 1122
*> (see above quote). Why isn't this clearly pointed out in RFCs?
*> Looks like an omission...
*>
*>
*> So the solution to Glenn's problem (other than shutting down the net for
*> a short term fix) would be to contact the suppliers/writers of the
*> TCP/IP software and tell them how buggy their software is. You could
*> quote the above.
Right!
Bob Braden
*>
*> 73,
*>
*> -Marc VE2SOR
*> --
*> Marc E. Gauthier Software Eng. Lab, IIT, National Research Council Canada
*> mgauthier@iit.nrc.ca Building M-50, Ottawa ON, Canada K1A 0R6
*> +1 613 991 6975 fax: +1 613 952 7151 home: +1 819 777 5841 (Hull QC)
*> NCFreeNet: aj313@freenet.carleton.ca Disclaim: I speak for myself only
*>
*>
*>
------------------------------
Date: Fri, 05 Nov 93 22:59:47 PST
From: cyberman@cyberworld.gun.de (Thomas Levin)
Subject: TCP/IP Probs
To: tcp-group@ucsd.edu
Hi there,
maybe someone can help me. I use the TCP/IP Program KA9Q. I have to use
this Program because this is the only way to get online to internet the
node i use.
But when i typed my username, pw then a message follows "start your slip"
What do i have to do? Please help me. I'm new to internet and very
interrested to see the things online.
Greetings from germany
Thomas
P.S.: I use the install version from nos
------------------------------
End of TCP-Group Digest V93 #288
******************************
******************************