peha@SPAM.ISTC.SRI.COM (Jon Peha) (03/09/88)
Can any one tell me any thing about "remote broadcasts" in TCP/IP. By that I mean having a packet broadcast on a network other than the one to which you are directly attached. I am quite aware of the dangers of such packets. One caused a broadcast storm on our ethernet effectively bring down the net. As far as I know there is no defence against one of these packets coming in from the Internet. On the other hand, if the packet were a UDP packet that did not engender a response (i.e. network monitoring info, routing tables, etc.), it could be a valuble tool, which may even prove useful in some of my present work. Is there any attempt in the Internet to regulate or block such packets. If so, where and how? If not, has any one considered it? I would think that if there is any control over remote broadcasts, it must take place in the gateway attached to the destination network, but perhaps the overhead would be too great. Jon Peha
deering@PESCADERO.STANFORD.EDU (Steve Deering) (03/09/88)
Jon, Concerning "remote broadcast" (also known as "directed broadcast"), you wrote: I am quite aware of the dangers of such packets. One caused a broadcast storm on our ethernet effectively bring down the net. As far as I know there is no defence against one of these packets coming in from the Internet. Could you explain in more detail what that one broadcast packet contained that effectively brought down your network, and why the fact that it came from another network was significant? I realize that there are lots of bugs out there in the way hosts handle broadcasts (and multicasts), but surely it's time to fix the bugs and make our hosts a little more robust in the face of unwanted packets, rather than imposing arbitrary gateway controls to protect the hosts from their own stupidity. As you observed, multi-destination datagrams can be a valuable tool; rather than imposing gateway controls, I suggest that the right defence is: 1) Fix hosts to ignore (i.e., silently discard) packets that they are not equiped to handle properly. 2) Insist on the use of multicast, rather than broadcast, so that unwanted packets can be ignored efficiently. Steve Deering
Mills@UDEL.EDU (03/09/88)
Jon, I thought it would be cute if the fuzzball implementation exploded letter bombs to the broadcast address and they do that. Great fun and a good headscratcher to figure out what happens when you do that to a bunch of TCPs. However, it sure turned out to be a Real Bad Idea to allow that to happen past a gateway. Thus, the fuzzballs carefully nuke any broadcast-apparent packet that attempts to transit from one net to another. See RFC-1009. Dave
eshop@saturn.ucsc.edu (Jim Warner) (03/09/88)
There is no guarantee that any particular (sub)net that you're sending to supports broadcasting. This topic is discussed in RFC1009, mostly in appendix A. Briefly, the local gateway may forward a "directed broadcast datagram", but not through the interface that it came in. A local gateway is permitted to black hole a directed broadcast. Presumably, there should be a software switch. It may be useful to remember that intermediate gateways may not be able to determine if a particular IP address is a broadcast address unless they know the local subnet mask. Thus disgarding directed broadcasts is always done by the gateway guarding the destination net.
barmar@think.COM (Barry Margolin) (03/10/88)
In article <88.03.08.2044.910@pescadero.stanford.edu> deering@PESCADERO.STANFORD.EDU (Steve Deering) writes: >Could you explain in more detail what that one broadcast packet contained >that effectively brought down your network, and why the fact that it came >from another network was significant? I don't know what the original poster's answer will be, but my answer to this is that one generally has some control over the systems on the local net. If they start abusing broadcasts we can remove the programs that are causing trouble. But if broadcasts can come from anywhere there's not much that you can do to prevent them, and instead you must defend against them. While it is a good idea for systems to be resilient, it's also harder to implement. Barry Margolin Thinking Machines Corp. barmar@think.com uunet!think!barmar
brunner@SPAM.ISTC.SRI.COM (Thomas Eric Brunner) (03/14/88)
Steve, Jon, list, Jon wrote that a directed broadcast "caused a broadcast storm on our ethernet effectively bring down the net." In the 18 months that I've had a largish part of SRINET to watch, storms have come and gone due to local broadcast address mismatches, and broken cable. I have on occasion seen directed broadcasts, which didn't do as Jon describes - trigger a broadcast storm. ...I've just spoken to Jon, it appears that the directed broadcasts I saw here (SRI) from UCSC some many moons ago, were mentioned to him by our hardware facility manager as the/a cause of one-or-more of our network failures in the winter. This is wrong, so I'll make the informational corrections locally. Unless anyone has anything else to add, the "directed causes network meltdowns" discussion is at its end. Eric