Mills@UDEL.EDU (10/21/87)
Folks, A couple of days ago, while working on modifications to some intricate routing algorithms, a bogus squawk for net 0.0.0.0 escaped our swamps and landed at the core gateways. The squawker got plugged pretty quick, but may have uncorked some pretty strange bogons in the process. First, some hosts, in particular a UTexas dude, began believing the squawker 10.2.0.96 was the gateway to Oz and other wondrous places, so began sending mail, domain-name requests and other stuff to that address. All this wouldn't have mattered much, since the squawker should advise all squawkees via ICMP Unmentionable messages to do otherwise. Alas, the squawker had a bug which simply accepted all traffic landing there, rather than refuse or redirect it. That was caught very quick, you might surmise, but not before a lot of domain-name requests to the BRL rootservers appeared (!!) and were in fact dutifully answered correctly. A few mail messages landed also, but were automatically forwarded to the correct destinations (some recipients are not going to believe the return path!). All this was pretty embarassing, but inexplicable, unless the bogon released and then contained a couple of days ago were implicated and the implication that 0.0.0.0 was "default to anywhere" persisted for a surprisingly long time. Now the good part. Today I say an RWHOm (UDP port 513) appear at the squawker with source address 1.1.1.1 and destination 1.0.0.0. Er, ah. Yoboy. Please send in the UFO team. I though you might get a chuckle out of this. Me, I'm somewhere between hilarity and catatonic shock. Dave
narten@PURDUE.EDU (Thomas Narten) (10/22/87)
Couple of observations. 1) Default routes tend to suck up everything, both valid and invalid. First, there are obvious things like permutations of various broadcast addresses. In subnetted environments, they also suck up packets for subnetted networks that "don't exist". For instance, Suppose that gateway A-GATE is on the ARPANET and fronts as a gateway to a subnetted network A-NET. A-GATE runs EGP and has full routing tables, and all machines on A-NET have a default route pointing to A-GATE. Now suppose someone starts sending packets to machine BOGUSHOST. BOGUSHOST is on a nonexistent subnet. Normally, these packets get forwarded to A-GATE via the default route. A-GATE doesn't have a default route, so the packet is discarded. Now, if j-random core gateway X advertises a default route, we get a routing loop. Instead of dropping packets for BOGUSHOST, A-GATE forwards them to X. X, knowing nothing about subnets, forwards the packet back to A-GATE. The problem is, gateway A and gateway X don't have a consistent view of A-NET. X sees it as one network, A doesn't view A-NET as a single network. In my experiences with subnetting, these homeless packets appear from time to time, much like invalid broadcasts that should never appear either. In fact, invalid broadcasts in particular get sucked up by default routes. >All this wouldn't have mattered much, since the squawker should advise >all squawkees via ICMP Unmentionable messages to do otherwise. 2) ICMP Unmentionable messages have little effect on some UDP oriented protocols in 4.3. Errors can only be returned to sockets that have a foreign address bound into them via connect(). Typically, UDP based query/response servers send response messages by including the destination address as an argument to the write call. When ICMP errors get returned to the server, the OS has no way of matching the error message with the socket it goes to. Named is my favorite scapegoat in this regard. 3) The distributed version of 4.3 does not pass ICMP Unreachable errors back to the TCP layer. It does process src quench and redirects though. Machine's relying heavily on default routes almost always have connections time out (after several retransmissions), as apposed to having the connection attempt abort quickly with a "host unreachable" error. The fix for this is less than a dozen lines of code, I have not seen Berkeley send out a fix for it (though in fairness, I may have missed it). This is all rather disturbing considering the heavy dependence placed on default routing, and the recognized need for network applications to better respond to network feedback. Thomas