Actions to quiet the Smurf amplifiers?


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

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

Last time I checked with them they didnt do regular checks of all nets. I
believe that there might be a larger portion of the net being fixed than
what the SAR reflects because of this.

On the other hand, update checks might have been implemented the past 2
months that I dont know about...

Finding some way to deny them routing until the problem is fixed, is the
most effective means I can think of. (I dont mean a DoS attack, I mean
some way of ignoring their route announcements).

The last site I dealt with took _3 weeks_ to close their amplifiers once
they were notified. And this was a multimillion dollar publishing company.