RE: engineering --> ddos and flooding
On Mon, Jun 04, 2001 at 02:08:52PM -0400, Matt Zito wrote:
Sorry but IMESHO null routing a /32 during a DoS attacck doesn't exactly strike me as engineering. It is more like dealing with the attack in real-time. To mean engineering would mean desinging networks to be resistant to DDoS and flooding in the first plsce.
Giving the customer the option to have their announced prefix null routed internally is a powerful value add that fits in right along side giving them other controls like preference and prepending. Usually this is passed as a community tag, and good networks give their customers these controls.
To that end no NSP should ever allow spoofed IP addresses outside of their network. (not just RFC 1918 addresses but valid IPs that don't belong to that NSP)
This guarantees nothing.
Two NSPs should rate limit DoS traffic (ICMP & SYNs) within their networks in such a way that it can never DoS a T-1 (or E-1 if you are not in the US). [note: I'm not sure if ciso's are up for this workload since I primarily work with Juniper.]
Bad plan. Then a single t1 worth of attack can effectively stop all icmp or syns from passing through.
Rate-limiting ICMP is not so difficult - rate-limiting SYNs is basically useless. Syn floods work not because the amount of traffic they do, but because they fill up state tables or make them so horribly inefficient as to make the box cease responding on that port. Given that, say, a linux box has a default queue depth of 128, I can send 128 spoofed SYNs at a rate of one a second, and in two minutes that box will stop responding. The larger you make the queue, the longer it will stand up to a slow SYN attack, but the more costly each incoming SYN and SYN+ACK becomes, as the data structures become more and more unwieldy.
Wrong, and very much out of date. I didn't write all this down to waste my breath... http://www.e-gerbil.net/ras/projects/dos/dos.txt -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
participants (1)
-
Richard A. Steenbergen