Who *does* do ingress filtering? I have it on our border routers and customer connect ports. We have transit from MCI and UUNET. Neither has ingress filters -- see below message from MCI on this.

I have dealt with this in a different way. I have been figuring out interesting things to do with netflow data for a while now. I recently debugged a program which uses a file which has what looks like access lists associated with particular ports on my 7500's. The program then looks at the netflow data and dumps any record which is explicily denyed or implicitely denyed (implied deny any at end, like Cisco). It looks at the source addresses, uses the supplied mask and applies it only to the interface(s) in question. So I look at data from our backbone providers and see if there is any data being sent with my networks source address ranges. I look for packets from the backbones destined for x.x.x.255 to look for smurf type attacks. I have it looking at my customers data to make sure that they are only sending from address ranges that I expect and they aren't spoofing data against someone else. The nice thing about this is that it doesn't slow down the router by causing it to do compares on potentially long access lists real time while the data is comming in. I have netflow turned on and I dump the data to my unix host for the analysis. My sun workstation seems to have no problem keeping up with the traffic load. Since most data is legitimate, the workstation doesn't need to dump that much data. For interfaces on my router I have no concern for spoofed data I build no access lists for the netflow analysis program and it just ignores data comming in those interfaces. If I see something particularly henious I can put in an explicit filter to clobber it, in the router when it hits the router. Netflow records are still cut even if I do filter the stuff too. I can then complain to my service provider saying kill that spoof attack comming from your network. Or to my customers I can tell them cut out that spoof attack or I'll have to turn your line down. I can then monitor the progress to see if it has stopped yet. Great stuff and all at no extra work to the router. If there is enough interest I can write up some documentation on it and make it available via ftp. It again is based on the example tools Cisco built to demonstrate netflow capablities like the last tool I posted. Walt Prue Los Nettos