|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Fixing RFC's WAS Re: SMURF amplifier block list
On Sun, 12 Apr 1998, Forrest W. Christian wrote: > My opinion is that we need to fix some RFC's to help eliminate the SMURF > problem and other problems. Look closely. I already posted this mentioning RFC 2267 If anyone at an educational institution tells you that send them to UCLA http://www.math.ucla.edu/misc/smurf.html or Simon Fraser University http://www.cs.sfu.ca/CC/Hypermail/cmpt-471/0008.html or the RFC archive at USC's Information Sciences Institute ftp://ftp.isi.edu/in-notes/rfc2267.txt or the Computer Emergency Response Team at Carnegie Mellon University http://www.cert.org/advisories/CA-98.01.smurf.html Here's an excerpt from a message I posted to another list with a good URL: > I'm STILL lost. How am I going to "localize the effect" of my downstream - > who have not set "no ip directed broadcast" - being used as a SMURF > amplifier? As for helping them fix it, how does that relate to "DEMANDING" > the upstream fix the upstream's config? Here is a URL with some info http://www.quadrunner.com/~chuegen/smurf.cgi Here is what I mean. -------------*-*-*-*- * - * - * * the void... :-) | FFF UUUUU OBOBOB | F = Fred's Network FFF----UUUUU---OBOBOB-- P = Patrick's Network FFF UUUUU OBOBOB U = Upstream provider for Fred and Patrick | | OB = Other Backbone provider PPP VVV V = Victim of the Smurf attack PPP VVV PPP VVV Now some mean guy out there in the void decides to attack the poor victim network by sending spoofed source packets to the broadcast address of Fred's network. The spoofed source address is that of the victim so that all the echo replies from the machines on Fred's network go to the victim's network. Now why should Patrick care? Why should he be demanding that his upstream do something about it? Because if the Upstream does nothing, people out there on the net may well start to block all of Upstream's address blocks. So Patrick can demand that his upstream take action to make sure that no SMURF amplifiers are downstream of them. Patrick has no business relationship with Fred but both have a business relationship with the Upstream. The Upstream could remind Fred that he must fix his routers according to their TOS or AUP. Or they could help Fred fix his routers. Or they could disconnect Fred. Or they could block all traffic to ?.?.?.255 in Fred's network. In fact, Upstream could regularly scan all of its address space to find misconfigured routers and help them fix this problem. If you have some time for code hacking maybe you could hack smurf or fraggle to create a program that does this. > Is there a review of the Router and Host requirements RFC's in the works? > Specifically, to review those areas which could be changed to fix some of > these problems. RFCs take a long time to change, especially standards track RFCs. But it isn't that hard to get an informational RFC like 2267 published. > For example, the directed broadcast stuff should be written to basically > say that the DEFAULT must be for the directed broadcasts to be off. There are no guns in the IETF. Basically the RFCs should say exactly what they do say because that's the best consensus that people could reach. Maybe you could convince them to revise the RFC but you'll need to fully understand the entire scope of the protocol design, not just current operational issues. But that's something that needs to be discussed elsewhere. http://www.ietf.org Might be worthwhile for someone to spend a half hour explaining the directed broadcast issues at the next NANOG meeting? -- Michael Dillon - Internet & ISP Consulting http://www.memra.com - E-mail: [email protected]
|