On Mon, 25 Sep 2000, Patrick W. Gilmore wrote:

At 02:01 PM 9/24/2000 -0700, Bill Woodcock wrote:

...

It's sounding like what we're working our way around to is that two separate BGP feeds would be needed:

<SOAPBOX> OK... In typical engineer fashion, we're all over-engineering this. Even if we do manage to set up a RBL style BGP feed, all this will do is limit OUR ability to reach the SMURF-friendly networks. That's the wonderful thing about BGP. You can limit what you accept but, once you hand an announcement to someone, there is no real way to say "announce this to everyone but the SMURF-friendly networks." So, what we end up doing is limiting the damage done by a smurf attack. Unless you're running CEF, your router is going to pass traffic destined for networks you're announcing to those networks. I have yet to find an easy way to implement CEF on the border that doesn't break something in some funky way or another. What needs to happen (and most likely won't... I'll grant you that) is that we need to begin dropping peering sessions with those ASNs that host smurf amplifiers and refuse to do anything about it. Networks who host stub sites who refuse to do anything about their smurf activities need to flat out DROP those customers! When the smurf sites can no longer connect to anyone because either they or their transit provider has been dropped by the rest of the world, they can't cause any damage to anyone else. Like I said above, I doubt this will happen because there are far too many pointy-head types and bean-counter types vs engineer types. Since we _know_ that the obvious solution will _NOT_ happen on a large enough scale to really make any impact, there is something that we can ALL do to prevent the problem from getting any worse. 1) If someone is connecting to your network for transit, make sure that, at a minimum, their router is configured for no ip directed broadcast. 2) Make sure that your AUP has provisions for disconnecting a customer who is causing network disruptions AND DISCONNECT THEM WHEN THEY ARE!!! 3) Make sure your AUP has provisions to drop a customer like a bad habbit if they have multiple "accidental misconfigurations" that cause network disruptions. 4) Make sure that there is room in your bi-lateral peering agreements for you to drop the session when you're seeing SMURF traffic from a peer and KEEP IT DOWN until they fix their problem. DON'T TAKE THEIR WORD FOR IT! TEST IT YOURSELF! When someone has to buy transit to you to smurf you via a free/inexpensive bi-lateral peering session, it WILL get their attention. Folks, we build and run the internet in North America and parts unknown. I'm NOT advocating that we adopt an elitist attitude. We do however have the power to make it painful/expensive for those who don't play by the rules. It's time for us to USE IT! Simply blocking crap at our borders does not prevent it from makeing it to our borders and clogging the pipe/cpu at the borders. If collectively we refuse to put up script kiddies and networks that provide safe havens for them, we will no longer have to deal with them. Tell me... Has anyone heard of anyone from the US "tagging" in Singapore? Hell no. They made an example. They don't put up with that crap. I would MUCH rather someone spraypaint the front of our NOC than throw 300Mb/s of ICMP towards us. Perhaps if we all started hiring an "enforcer" for our AUPs who "visited" problem clients, they would go away. It's time to take a tough stand against SMURF-haven networks/clients. We DON'T want their business and we DON'T want to peer with them. We DO want them to get their act together and fix their networks/customers. It's just that simple. Like most things in life, I'm sure that this is far too simple to catch on. Something has to be complicated for people to appreciate the beauty generally. </SOAPBOX> --- John Fraizer EnterZone, Inc