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