Actions to quiet the Smurf amplifiers?

Sat Oct 17 17:40:38 UTC 1998

Hi,

a few months ago there was quite a bit of talk about publishing
known Smurf amplifier networks.  I've been exchanging a few
e-mails with one of the guys maintaining the smurf amplifier
registry at

	http://www.powertech.no/smurf/

He tells me that since they started, several thousand entries
have been fixed.  However, the list is still quite a moutful
(860KB in dense format, approx. 11.000 entries, no less!).

It would appear that we (collectively) are not doing a sufficient
job to remove this at times quite bothersome problem.

One thing is that there's been lots of talk about preventing
source IP address spoofing, but apparently not enough has
happened there.

Going after the networks being abused as amplifiers is quite a
bit easier since they can be easily identified.

Massaging the condensed list mentioned above and adding up the
entries for the origin the route was seen with at the time the
prefix was bound to an AS, the top of the (rather long!) list
comes out as something like this:

AS#           Ampl. %ampl  AS name

AS174         6427   6.24  PSINet Inc.
AS3561        4337   4.21  Cable & Wireless USA
AS701         4152   4.03  UUNET Technologies, Inc.
AS1239        2545   2.47  Sprint
AS1           2372   2.30  BBN Planet
AS568         2149   2.09  DISO-UNRRA
AS2551        1721   1.67  NETCOM On-Line Communication Services, Inc.
AS2548        1710   1.66  Digital Express Group, Inc.
AS1785        1549   1.50  Sprint, Government Systems Division
not-analyzed  1478   1.44
AS7018        1420   1.38  AT&T
AS2900        1244   1.21  Arizona Tri University Network
AS268          983   0.95  Uniformed Services University of the Health Sciences

"Ampl." is the sum of the amplification factor for the amplifier
	nets that were announced with this AS number as the home
	AS in BGP when each prefix was bound to a BGP route.
"%ampl." is the percentage of the total sum of the amplifier
	factors for all the networks in the list.

Folks, it would seem that there's ample work left to inform your
customers that they should take the necessary precautions to
prevent their networks from being inundated with traffic by being
exploited as an amplifier in a "Smurf" denial-of-service attack.

It might be a good idea to point out that doing the work to prevent
this from happening is also in their own best self-interest.

Lastly, I'd like to get some idea as to how best to attack this
problem -- the present method of "public list of shame" of the
providers with the amplifiers as "local sources" is one method, but
I'm far from certain that it will be effective.

Comments appreciated.

- Håvard