From: Daniel Senie [mailto:dts@senie.com] Sent: Tuesday, September 26, 2000 8:45 AM

"Henry R. Linneweh" wrote:

...

John;

...

"The SMURF problem is years old. People who don't look for this on their own networks and prevent it before it starts are AS MUCH if not MORE a part of the problem as the script kiddies".

Implementing RFC 2827 (ingress filtering) and RFC 2644 (disabling directed broadcast) is more than just a nice idea. These are both BCPs, since they both represent methods for limiting damage to the Internet.

I've been following this thread since the first time it came around. In the last round, the point was made that 0 and 255 weren't the ONLY b'cast addrs in a /24. In fact they aren't, over here (MHSC.NET). Our /24 is so sub-netted. In fact, one can have up to 64 b'cast addrs in a /24. I know that all of you are aware of this. Granted, each subsequently smaller subnet also limits the maximum number of hosts that will respond to the smurf trigger. The point is that, the web-site ONLY tests 0 and 255 and y'all are discussing filtering on ONLY those values. This is inadequate for what you are trying to do. A /25 can still yield 127 host respnses and a /26 will yield 63 host responses, and so on... Discovering these b'cast addrs isn't difficult either and I'm sure that the script-kiddees already have a means to do so. Had I the time, I could write the code, the algorithm is trivial. The last time this came around I suggested a means that would work. It involves making entries in your in-addr.arpa file that lables each base and b'cast addr. As an example, I have done this to my own file and have been maintaining it for years. Once put in place, it is simple to maintain. Generally, subnet assignments don't change that much (scale = years). The upstream should filter any and all packets going to those addrs, at the gateway. This can be made a part of the contract, with downstreams that manage their own IP and DNS space (like MHSC does). I've actually considered a script that reads the ARPA file and generates ipchains commenads to automagically put the proper filters in place. Again, it isn't that hard. The specific file I am talking about is "175.108.199.inaddr.arpa", dig at your local BIND for the auth server NS1.MHSC.NET. Base addrs are labeld "base" and b'cast are labeled "bcast" (duh). There are various means to implement this, I can think of 1-2 others without really trying. The point is that, if you're going to do this, do it right. Defense is a lot less socially antagonistic than offensively BGP black-holing antire IP-blocks (which can get you seriously sued) and creating more outages than we already have to suffer through.