nanog mailing list archives
Re: smurf, the MCI-developed tracing tools (was Re: Bogus announcement)
From: Karl Denninger <karl () mcs net>
Date: Sun, 28 Dec 1997 12:05:33 -0600
On Sat, Dec 27, 1997 at 11:10:55PM -0500, Ken Leland wrote:
Karl wrote:However, if a forged-source data stream IS traced to one of your customers, expect a harsh response from the general network community. This attack is well-enough known by now that I consider anyone unable to immediately and permanently deal with such an incident to be somewhere beneath contempt.Well, it is going to take more education and pain, apparently. I've got 3 national backbones upstream and they all have a hell of a time just getting icmp-echo-reply filters in within hours of attack onset, and usually get nowhere with tracing this to an end perp. Granted, its a difficult, cooperative problem. One of the better respected of them, told me that their philosophy was to deliver all packets to me regardless of the source/type. This corker, is the type of logic one can apparently come up with when ones routers at Pensaulken are near fall-over. This upstream did install the filter, after escalation, fortunately.
You don't want to filter ICMPs. What you want to filter is ANYTHING which came from an invalid source address *at your entrance* from your customer connections. Now, for backbone<>backbone connections, this is impossible - granted. But for end-user<>backbone connections, it is not only not impossible, it is virtually a REQUIREMENT.
a problem where backbones have to choose between expensive filtering of ICMP-echo-replies for very long periods of time or allowing customer connections to be randomly swamped (rendered useless) for hours by bored 13 year olds, from virtually anywhere on the net. The latter is of, essentially, zero economic value to us, at least.
Well, yes.
The current cost of per link filtering is apparently causing the backbone networks major grief.
That's because people are doing it on the packet TYPE. If you filter on the source *address*, at the ingres point to your network, it causes much less pain.
This problem, is disrupting the service of every isp in our region on a frequent basis and it is getting worse week by week.
Yes.
A, sometimes seen, tendency to suggest that only a few ISP's with problem attracting users are affected by this does not recognize the breath or depth of the problem, nor where it is heading. Ken Leland Monmouth Internet
Correct. The fix is to deny inbound traffic from any connection which has an invalid source address. You *KNOW* what the valid addresses are if you connect someone - if I give someone 205.164.6.0/24, then anything with a source address outside of that /24 is INVALID by definition and I should refuse to accept it. This is NOT difficult to do, nor is it expensive. Until it becomes a standard part of end-user connections this problem is going to remain extremely difficult to trace. -- -- Karl Denninger (karl () MCS Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex support on ALL modems Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost
Current thread:
- Re: smurf, the MCI-developed tracing tools (was Re: Bogus announcement), (continued)
- Re: smurf, the MCI-developed tracing tools (was Re: Bogus announcement) Karl Denninger (Dec 27)
- Re: smurf, the MCI-developed tracing tools (was Re: Bogus announcement) Ken Leland (Dec 27)
- Re: smurf, the MCI-developed tracing tools (was Re: Bogus announcement) Adrian Chadd (Dec 27)
- Re: smurf, the MCI-developed tracing tools (was Re: Bogus announcement) Ken Leland (Dec 27)
- Re: smurf, the MCI-developed tracing tools Dax Kelson (Dec 28)
- Re: smurf, the MCI-developed tracing tools Karl Denninger (Dec 29)
- Re: smurf, the MCI-developed tracing tools (was Re: Bogus announcement) Karl Denninger (Dec 28)
- Re: smurf, the MCI-developed tracing tools (was Re: Bogus announcement) Adrian Chadd (Dec 28)
- Re: smurf, the MCI-developed tracing tools (was Re: Bogus announcement) Bradley Reynolds (Dec 28)
- Re: smurf, the MCI-developed tracing tools (was Re: Bogus announcement) Adrian Chadd (Dec 28)
- Re: smurf, the MCI-developed tracing tools (was Re: Bogus announcement) Karl Denninger (Dec 28)
- Re: smurf, the MCI-developed tracing tools (was Re: Bogus announcement) Paul Ferguson (Dec 28)
- Re: smurf, the MCI-developed tracing tools (was Re: Bogus announcement) Ken Leland (Dec 28)
- Re: smurf, the MCI-developed tracing tools (was Re: Bogus announcement) Dalvenjah FoxFire (Dec 28)
- Re: smurf, the MCI-developed tracing tools (was Re: Bogus announcement) Alex P. Rudnev (Dec 31)
- Re: smurf, the MCI-developed tracing tools (was Re: Bogus announcement) Phil Howard (Dec 29)
- Re: smurf, the MCI-developed tracing tools (was Re: Bogus announcement) Alex P. Rudnev (Dec 31)
- Re: smurf, the MCI-developed tracing tools (was Re: Bogus announcement) Dale Drew (Dec 27)
- Re: Bogus announcement of 205.164.62.0/24 by AGIS - CLEARED Reid B. Fishler (Dec 27)
- Re: Bogus announcement of 205.164.62.0/24 by AGIS - CLEARED Phil Howard (Dec 27)
- Message not available
- Re: Bogus announcement of 205.164.62.0/24 by AGIS - CLEARED Jay R. Ashworth (Dec 28)