Re: Router modifications to deal with smurf
There is no noise, only signal. There is no signal, only noise. On Apr 26, 3:35pm, Craig A. Huegen wrote: *On Sat, 25 Apr 1998, Rusty Zickefoose wrote: * *==> We requests that your routers be configurable, at the interface *==>level, to prevent the forwarding of an ICMP echo-request packet through an *==>interface that has a broadcast or wire address that matches the *==>destination address of that packet. We also request that the default *==>configurations of your routers be modified to prevent said forwarding. * *This is against RFC 1812. * *RFC 1812, "Requirements for IP Version 4 Routers", Section 5.3.5, *specifies: * *--- * A router MAY have an option to disable receiving network-prefix- * directed broadcasts on an interface and MUST have an option to * disable forwarding network-prefix-directed broadcasts. These options * MUST default to permit receiving and forwarding network-prefix- * directed broadcasts. *--- Yes, well, the fact that most vendors do NOT have a knob to turn this off is also against RFC 1812 (same paragraph, previous sentence) and that's a big part of the smurf problem. *Someone has stated before that editor(s) of said RFC are aware of this and *have discussed the change in default. No, jhawk said the editor(s) are "certainly aware" of the fact that the RFC could use some updating. No one said that they actually are aware, nor whether anyone is making an effort to update the document. If anyone originally associated with the document IS in fact working to change RFC 1812, I'd really like to hear about it. Privately or publicly. Please feel free to forward this note to the relevant parties if you know them. I have a keen interest in the topic. Thank you. *Note that I'm not arguing that it *should* be the default, I'm just *arguing that vendors have implemented it this way because that's the way *they were told to in the RFC. If after reading *http://www.quadrunner.com/~chuegen/smurf.txt, you think that I believe *directed-broadcasts should be on by default, go back and read agian. =) The point is that forwarding directed broadcasts should be off by default and that: 1. RFC 1812 should be changed to reflect this and 2. Vendors should modify their code to reflect this Whether these two things happen in parallel or serial is relevant only inasmuch as the vendor doth protest that they one must come before the other. They should both occur. And if a vendor wants to argue that they are in keeping with RFC 1812 by having the forwarding of directed broadcasts on by default BUT do not have a knob built in to turn it off, then that looks a bit hypocritical and they open themselves up to all sorts of taunting. *Now, since this has been beaten past the jelly stage, can we please put *the topic to sleep? Thank you. I seriously doubt that this topic is going to die until Smurf attacks get quite a bit smaller or go out of vogue. Just to be clear, Rusty asked whether requesting that the various vendors in the world create a knob to turn off the forwarding of directed broadcasts combined with requesting that it is configured off as a default setting would meet with approval by most of the readers of NANOG, not whether it was feasible or in keeping with the RFC. It is a known thing that this type of request doesn't meet the criteria of the RFC and lots of different folks are hoping that the RFC will change. I'm wondering whether there's any duplication of effort to that end (or any effort at all) going on. Kelly J. -- Kelly J. Cooper - Internet Security Officer GTE Internetworking - Powered by BBN - 800-632-7638 150 Cambridge Park Drive Fax - 617-873-5508 Cambridge, MA 02140 http://www.bbn.com
On Mon, 27 Apr 1998, Kelly J. Cooper wrote:
And if a vendor wants to argue that they are in keeping with RFC 1812 by having the forwarding of directed broadcasts on by default BUT do not have a knob built in to turn it off, then that looks a bit hypocritical and they open themselves up to all sorts of taunting.
Or they could have a knob for each interface, and a knob which sets the default for each interface which doesn't have its own setting. Then the default for the global default parameter could be RFC1812 compliant, yet allow a user to easily change it without having to update every interface. That would still mean that someone who started using the router without setting that parameter would be contributing to the problem, but they have to configure the box anyway to use it. As it is, it is easy to forget to set it on a new interface (although typically those are point-to-point links which only have a 2x factor anyway), at least until you have been burned once. John Tamplin Traveller Information Services jat@Traveller.COM 2104 West Ferry Way 205/883-4233x7007 Huntsville, AL 35801
On Mon, 27 Apr 1998, Kelly J. Cooper wrote:
It is a known thing that this type of request doesn't meet the criteria of the RFC and lots of different folks are hoping that the RFC will change. I'm wondering whether there's any duplication of effort to that end (or any effort at all) going on.
Nose around here http://www.ietf.org/ID.html and see if you find anything. If not, gather one or two other folks and write up a revised RFC or better yet, just write up a document describing the old paragraph, your proposed change, and why you think it needs to be changed. Read this ftp://ftp.ietf.org/ietf/1id-guidelines.txt for formatting guidlines and when it is written submit it to internet-drafts@ietf.org Then hang out on the IETF discussion list http://www.ietf.org/maillist.html and answer questions. Since this is a standards track RFC you'll need to do more than this to actually get the RFC changed but this should start the ball rolling. Technically, RFC 1812 is only a proposed standard which is the lowest of the three positions on the standards track. According to RFC 2026: A Proposed Standard ... has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. It also says: Implementors should treat Proposed Standards as immature specifications. It is desirable to implement them in order to gain experience and to validate, test, and clarify the specification. However, since the content of Proposed Standards may be changed if problems are found or better solutions are identified, deploying implementations of such standards into a disruption-sensitive environment is not recommended. So basically, you can stop this RFC in its tracks by clearly stating your objections in the form of an Internet draft and it might even be possible to get vendors to change this before the RFC is revised because the Internet IMHO qualifies as a disruption sensitive environment. -- Michael Dillon - Internet & ISP Consulting http://www.memra.com - E-mail: michael@memra.com
participants (3)
-
John A. Tamplin -
Kelly J. Cooper -
Michael Dillon