This morning Sprint dropped the icmp echo reply filter in their link (t1) to my network in mid "smurf" attack. The link was immediately swamped to the point of multi-hundred ms average transit times, normally 12ms. I removed this link from service (temporarily, I was thinking) and called the Sprint Noc to try to resolve this problem. I was informed of the following, by the manager that indicated that he handles backbone-to-customer filter policy: 1.) they will not continue to try to trace this. (they had made some previous unsuccessful efforts) 2.) they will no longer filter icmp echo reply for me, even though they understand that my link is now useless without that. They do not have cpu cycles to spare for this purpose. 3.) they do not see this type of attack very often and don't consider it much of a problem. I find this rather perplexing to say the least. Comments? This attack is an ongoing problem so I hope it is seen as an operational issue. It is beginning to be a chronic problem (4 day duration). The US Secret Service, Computer Crime Division is apparently having resource problems. I should also commend UUnet and Agis for their excellent assistance in working with me to keep my network operational. Ken Leland Monmouth Internet