North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: smurf, the MCI-developed tracing tools (was Re: Bogus announcement)
- From: Ken Leland
- Date: Sun Dec 28 01:28:56 1997
> But this way, people can only spoof IPs from their own block, and not
> random addresses. It would kill smurf attacks, make tracing a tad(?)
> easier, etc, etc. And as I've mentioned before, not all types of floods
> are ICMP attacks. If you filter ICMP, then I'll start flooding with
> spoofed source addresses TCP packets with random sequence numbers and from
> IPs. What, you're going to ask routers to track all the TCP connections
> going through them now for validation? Erm, how many CPUs more are we
> going to need..? :)
Well, its that 200+ to 1 amplification thats readily available to spoofed
ICMP echo packets that is really causing this problem to get out of hand.
Any kid with a 28.8 link can effectively take down a T1.
Without icmp broadcast amplification, someone who has to source 4megs to
swamp a T1 for long periods of time will be easier to trace and will be far
fewer in number.
I regularly see attacks on our T3 that exceed 15Mbs. For the time
being we are keeping up with this. Other providers in the area are
being overrun. Our backup (smaller) links are often rendered useless.
> I haven't looked at the MCI tools but my opinion is that if people start
> putting filters in, you would find the instances of flooding decline. All
> that needs to be done now is to discuss the best ways to do it (eg setting
> up a filter on a cisco which uses AS path regexps, so you can filter per
> interface on what people are announcing to you via BGP. That way, your
> downstreams can only send traffic with FROM IPs that they announce, and
> anyone who wants to spoof has to be speaking BGP. )
Granted, limiting source address spoofing will stop this and other
problems. We have done this, to be net-friendly and in an attempt to avoid
our 15 minutes of infamy. If this is generally doable then great. If not,
in many cases, then we need rapid-onset/long-duration icmp-echo-reply
filtering in our upstream/backbone connections for the forseeable future.
Without this capability T1 net connections will become useless and
T3 connections will become increasingly endangered. (If high availability
is needed for the connection as it is for ours).
This problem has been building here for over 4 months. Perhaps, we have
a local holiday maximum this week, but in general I believe this
situation will continue to worsen long term.