Mills@UDEL.EDU (10/24/87)
Folks, It so happens that two of the five NSFNET gateways to ARPANET are broken just now (PSNs seem to be down), so the remaining three have to carry the load. At one of them (linkabit-gw) the traffic is so heavy that source-quench messages are being sent regularily (see my recent note on how the fuzzballs now do selective-preemption and source-quench generation). Looking through the logs I see the single most persistent abuser is host 128.220.2.1, which is sending gobs of packets to 128.220.0.0, evidently the broadcast address on net 128.220. I did not capture the data portion of these packets, but I strongly suspect they are Unix rhos that never, never, never should be allowed outside of that net. Now, not only are broadcasts considered rude to the max outside the local net, but in this case those broadcasts are severly impacting service for many other users. At one point 35 packets were queued with the source and destination addresses shown. If it were not for their selective-preemption policy, the fuzzballs would be choked with these things and nobody would be getting good service at all. While host 128.220.2.1 might be considered borderline bogus, the 128.220 gateway must be considered clearly over the edge. Why did it allow any traffic for local-net destinations outside that net at all, much less allow 128.220.0.0 bogons to escape to ARPANET? I suspect the problem is a mixture of subnetted 4.2 and 4.3 Unix systems with different broadcast addresses. In any case, RFC-1009 clearly advises the all-zeros and all-ones variant of local addresses to be drop-kicked at the gateway. Will the operator of that gateway reveal the vendor so we can send the gongfermers after them? Better yet, compile a list of vendors known to be noncompliant with RFC-1009 and post at the upcoming INENG meeting and TCP/IP conference. RFC-1009 expresses a significant amount os sweat, experience and gong and was not intended to be taken lightly. Has anybody incorporated it as part of an RFP? Has any vendor claimed compliance? If the lessons therein are not taken seriously, we will continue to see problems as above and an inexorable decline in service quality throughout the Internet community. Dave
brescia@PARK-STREET.BBN.COM (Mike Brescia) (10/26/87)
Dave, I see 'jhu' net, 128.220 reachable via macom1 (10.0.0.111) which tells
me that it's somewhere in the NSF topology. Is there any place where further
live routing info can be gotten, so as to trace the bogus gateway, or do we
wait for them to 'fess up.
Re: broadcasts, I frequently see them being forwarded by a 'host' to a
'gateway' "because it is not for me". This is with no subnetting, either.
The particular hosts sometimes have the gateway switch turned on even when
they have only one interface.
MikeMills@UDEL.EDU (10/26/87)
Mike, Routing tables do bristle on the NSFNET gateway critters. Scott Brim at Cornell is the brushman. Hans-Werner Braun has many cans of paint for the brush as well. Bruised linkabit-gw is not the only stalwart for the flood - cu-arpa, psc-gw and the twin Maryland gatekeepers also stem the flood. Should you ask them for routing details, I suspect they would volunteer at least 76 trombones. Hosts that gratuitously offer to function as gateways are probably the single most dangerous and destructive animal that the Internet has ever seen. I can't even begin to boggle on the waves of destruction 4.2/4.3 systems have caused in the name of that disease. This is not to impune 4.2/4.3 systems themselves, just the wisdom, or lack of it,' of gratuitous packet transport without care for the awful damage that can occur. Dave
lekash@ORVILLE.NAS.NASA.GOV (10/26/87)
> Hosts that gratuitously offer to function as gateways are probably the > single most dangerous and destructive animal that the Internet has > ever seen. yeah, and its all due to a random decision to make the default distribution under 4.2/4.3 be ipforwarding and sendredirects on. Every vendor doesn't bother to change them. Here, I have instilled in our operations people the need to always turn these off by default on every machine that comes in, and only those machines that are gateways get it enabled. Along with tcpnodelack, and other default options that cause grave annoyance value. A few slip through the cracks, but quick action by the TCP/IP police stomps on such offenders. john
karels%okeeffe@UCBVAX.BERKELEY.EDU.UUCP (10/28/87)
Please, check your facts before sending flames to mailing lists! 4.3BSD does NOT do IP forwarding on singly-homed hosts, although the ipforwarding variable is not cleared. Only hosts with multiple hardware interfaces with IP addresses need to be configured consciously to avoid packet forwarding; such hosts need to be configured carefully in any case. 4.2's forwarding behavior was different, of course. Neither decision was random. The recent comments about escaped broadcast packets had a number of inaccuracies. In particular, unrecognized broadcast messages wouldn't be treated any differently than a host on the same network as the broadcast; thus, they wouldn't be sent using a default route unless there were no route to the destination network. This is very unlikely for a directly- connected network. 4.2 didn't recognize many current broadcast addresses; 4.3 recognizes most attempts to concoct broadcast addresses on the local networks. Of course, broadcasts for nonexistent subnets (or packets for hosts on nonexistent subnets) are sent using the default route. That's one reason that gateway that are advertised as defaults within subnetted networks should never use default routes themselves. (However, Kirton's EGP probably doesn't check for net 0, the "default" net, on input.) Mike
Mills@UDEL.EDU (10/28/87)
Mike, Your scenario about unrecognized broadcast packets and sneak paths via default gateways is exactly what happened in the recent case where net 128.220 RIP packets crashed and burned at linkabit-gw. Fortunately, the RIP packets did not survive the airspace to NSNET client networks, where the collateral damage might have been spectacular. The recent turbulence when net 0.0.0.0 was accidently sqwawked to the corespeakers and evidently was squawked right back to the Kirton code on one or more systems seems to confirm your suspicion that a "default" sneaked via EGP can run amok on the local net. This should be fixed. My comment about RFC-1009 compliance was also intended for you. Can you remark on the compliance of 4.3, lack of it or reasons wherefore? Dave
lekash@ORVILLE.NAS.NASA.GOV.UUCP (10/28/87)
> Please, check your facts before sending flames to mailing lists! > 4.3BSD does NOT do IP forwarding on singly-homed hosts, although > the ipforwarding variable is not cleared. Only hosts with multiple > hardware interfaces with IP addresses need to be configured consciously > to avoid packet forwarding; such hosts need to be configured carefully > in any case. 4.2's forwarding behavior was different, of course. > Neither decision was random. Sorry, I didn't feel very flame like. Yes, I know BSD only forwards on multiply homed hosts. Perhaps random was a poor random word choice, you may substitute carefully considered. Please do not consider what a said as a condemnation of 4.3BSD. Of the operating systems we have here, it is the most reliable and useful for my work. I thank you for this, very much. As you say, only hosts with multiple interfaces need to be carefully configured in that fashion. I interpret this to mean gateways, since a host with two network interfaces is only 1 line in /etc/rc.local more difficult than a host with only one. When the aforementioned decision was made, you probably had not envisioned the kind of things that are occuring at sites like here. Every workstation comes with an ethernet, and then has a hyperchannel added for performance to/from a supercomputer. So we have about 50 hosts that have multiple interfaces, and many more on the way. I believe that a system should have a minimum amount of default rope with which to hang oneself. And so, since gateways need the careful configuration, a default of not being a gateway seems appropriate. I did in fact configure many of them correctly, but after a time one turns such things over to others. New distributions come out of vendors, and someone just mangles their workstation, to bring it up a rev. Of course, the vendor has distributed it as they got it, and the aforementioned careful configuration is wiped out, despite written instructions that manage to disappear, and aren't necessary, because 'it works'. The brokenness is then only found the next time I happen to spend a half hour groveling with netwatch, one of the lesser exciting tasks. I happen to have noted difficulties because of some degree of perceived inconsistency. There exists the options GATEWAY kernel configuration parameter, which I would think a useful mnemonic hook to hang enabling ipforwarding and sending of redirects, which it wasn't last I looked. It does control sending destination unreachable. It is fairly common for people to do the minimum necessary to configure something, thus will forget to set IPFORWARDING and IPSENDREDIRECTS, as well as setting GATEWAY. I will admit it is annoying to have to deal with possible modes of screwing up, but it then means less work for me later on. john
karels@OKEEFFE.BERKELEY.EDU (Mike Karels) (11/01/87)
On RFC-1009 compliance of 4.3: I haven't looked at the RFC nearly as closely after it was issued as before, and I'm not sure what changes were made after the last draft. (Not as many as I would have liked, I guess; I sent in almost 10 pages of comments on the last draft.) However, 4.3 comes fairly close to compliance. As a host (esp. singly-homed), it is quite conservative about what it will respond to, and it won't forward packets. As a gateway, it does nearly everything as the RFC specifies, with some minor exceptions. For example, it uses both host and net redirects, with host redirects used for if the route used is for a host or subnet and net redirects otherwise; the RFC says to use only host redirects. (Or was that for unreachables? The opposite conclusion was drawn for the two.) Nearly all of the IP and ICMP options and types are supported, with the exceptions of security and TOS (but who knows what to do with these?). I should make a pass over the RFC soon; we plan to release a current copy of the networking code soon with Van's TCP changes as well as the bug fixes since the first release. Most things are automatically configured. John Lekashman mentioned various options controlling forwarding, gateway function, and generation of redirects; these are set only for performance reasons (more buffers and bigger hash tables for gateways) or to cause unusual combinations, such as machines that forward packets but won't send redirects. Hosts with one interface won't forward; hosts with multiple interfaces assume that they are gateways unless ipforwarding is disabled (either at compile time, or by patching a variable). Sorry, John, but I have to disagree that configuring multi-homed hosts is only one line different in the startup file; multi-homed hosts *have* to be more carefully configured, if only because some form of routing needs to be done to choose the correct outgoing interface. Mike
Mills@UDEL.EDU (11/02/87)
Mike, Thanks very much for thie information. I (and Bob Braden, I'm sure) will be looking forward to your definitive statements on how 4.3+ conforms, as well as any comments you have on what should be changed for the next draft of the document. Dave