RE: engineering --> ddos and flooding

> 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...