North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
RE: engineering --> ddos and flooding
- From: Richard A. Steenbergen
- Date: Mon Jun 04 15:11:21 2001
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...
Richard A Steenbergen <firstname.lastname@example.org> 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)